26.02.2014 Views

Getting Started with QNX Neutrino - QNX Software Systems

Getting Started with QNX Neutrino - QNX Software Systems

Getting Started with QNX Neutrino - QNX Software Systems

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

© 2009, <strong>QNX</strong> <strong>Software</strong> <strong>Systems</strong> GmbH & Co. KG. The client’s view<br />

Both fs-nfs (the network filesystem) and your caching filesystem (fs-cache)have<br />

registered themselves for the same prefix, namely “/nfs.” As we mentioned above,<br />

this is fine, normal, and legal under <strong>Neutrino</strong>.<br />

Let’s say that the system just started up and your caching filesystem doesn’t have<br />

anything in it yet. A client program tries to open a file, let’s say<br />

/nfs/home/rk/abc.txt. Your caching filesystem is “in front of” the network<br />

filesystem (I’ll show you how to do that later, when we discuss resource manager<br />

implementation).<br />

At this point, the client’s open() code does the usual steps:<br />

1 Message to the process manager: “Who should I talk to about the filename<br />

/nfs/home/rk/abc.txt?”<br />

2 Response from the process manager: “Talk to fs-cache first, and then<br />

fs-nfs.”<br />

Notice here that the process manager returned two sets of ND/PID/CHID/handle; one<br />

for fs-cache and one for fs-nfs. This is critical.<br />

Now, the client’s open() continues:<br />

1 Message to fs-cache: “I’d like to open the file /nfs/home/rk/abc.txt for<br />

read, please.”<br />

2 Response from fs-cache: “Sorry, I’ve never heard of this file.”<br />

At this point, the client’s open() function is out of luck as far as the fs-cache<br />

resource manager is concerned. The file doesn’t exist! However, the open() function<br />

knows that it got a list of two ND/PID/CHID/handle tuples, so it tries the second one<br />

next:<br />

1 Message to fs-nfs: “I’d like to open the file /nfs/home/rk/abc.txt for<br />

read, please.”<br />

2 Response from fs-nfs: “Sure, no problem!”<br />

Now that the open() function has an EOK (the “no problem”), it returns the file<br />

descriptor. The client then performs all further interactions <strong>with</strong> the fs-nfs resource<br />

manager.<br />

The only time that we “resolve” to a resource manager is during the open() call. This<br />

means that once we’ve successfully opened a particular resource manager, we will<br />

continue to use that resource manager for all file descriptor calls.<br />

So how does our fs-cache caching filesystem come into play? Well, eventually, let’s<br />

say that the user is done reading the file (they’ve loaded it into a text editor). Now they<br />

want to write it out. The same set of steps happen, <strong>with</strong> an interesting twist:<br />

1 Message to the process manager: “Who should I talk to about the filename<br />

/nfs/home/rk/abc.txt?”<br />

April 30, 2009 Chapter 5 • Resource Managers 197

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!