From: Anant Narayanan <anant@kix.in>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Re: 9P, procedure calls, kernel, confusion. :(
Date: Tue, 5 Feb 2008 19:13:47 +0530 [thread overview]
Message-ID: <0B8E2530-036F-406C-88D7-02624436ABD1@kix.in> (raw)
Hi,
> One more point, I googled a lot on "kernel resident file systems and
> non kernel resident file systems", but I could not find a single
> useful link. It would be great if you could specify the difference
> between the two. I wish that eases up the situation a bit.
I don't claim to know much about how 9P or Plan 9 work, but I will
attempt to answer.
9P is very much like Linux's VFS. It defines how user-space
applications can access files; whether they are stored locally, or on
the network, or whether the information is generated on-the-fly by the
kernel from its internal data-structures is of no consequence - 9P
abstracts all that.
Accessing files from within the kernel is a different ball-game
(that's true for every kernel). Since you don't have the 9P style
access anymore - The 'Dev' structure essentially replaces it. These
structures point to methods are quite analogous to the 9P operations.
The methods do the work of implementing the file operations - and
these would all be different for files depending on whether they are
stored on local disk, produced synthetically or accessed over a
network. This makes it easier to work with files in the kernel since
all the operations are delegated further to the 'Dev' structures, each
one doing what it knows best; quite similar to what happens with 9P in
user-space.
Charles mentions one such 'Dev', the mount driver, which merely passes
on the received request as 9P messages to the file descriptor
(possibly connected to a remote 9P server).
"Kernel resident filesystem" in this context simply means a filesystem
which was created for use by the kernel; this may or may not be
visible to user-space applications - I'm not too sure. To sum up, you
use the 9 primitive operations provided by each 'Dev' when you work
with kernel-resident filesystems, while all other filesystems are
dealt with using regular 9P.
I hope I'm right, and that this helps.
--
Anant
next reply other threads:[~2008-02-05 13:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 13:43 Anant Narayanan [this message]
2008-02-05 14:22 ` erik quanstrom
2008-02-05 15:18 ` roger peppe
-- strict thread matches above, loose matches on Subject: below --
2008-02-05 9:56 [9fans] " Siddhant
2008-02-05 12:59 ` [9fans] " Siddhant
2008-02-05 16:41 ` Charles Forsyth
2008-02-05 16:35 ` erik quanstrom
2008-02-06 9:45 ` Siddhant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0B8E2530-036F-406C-88D7-02624436ABD1@kix.in \
--to=anant@kix.in \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).