From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <0B8E2530-036F-406C-88D7-02624436ABD1@kix.in> From: Anant Narayanan To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [9fans] Re: 9P, procedure calls, kernel, confusion. :( Date: Tue, 5 Feb 2008 19:13:47 +0530 Topicbox-Message-UUID: 46bb217e-ead3-11e9-9d60-3106f5b1d025 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