Re: [9fans] Re: 9P, procedure calls, kernel, confusion. :( - Plan9

This is a discussion on Re: [9fans] Re: 9P, procedure calls, kernel, confusion. :( - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: [9fans] Re: 9P, procedure calls, kernel, confusion. :(

  1. Re: [9fans] Re: 9P, procedure calls, kernel, confusion. :(

    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

  2. Re: [9fans] Re: 9P, procedure calls, kernel, confusion. :(

    one thing of note, linux vfs implements a dcache. this connects the
    virtual memory system to the filesystem. (but oddly in linux network
    buffers are handled seperately.) there is no client-side caching in
    the plan 9 kernel.

    there is a notable exception. there is an executable cache.

    >> 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.


    since the devtab[] functions map 1:1 with 9p, all the mount driver
    needs to do for calls outside the kernel is to marshal/demarshal
    9p messages.

    it's important to remember that most in-kernel file servers could easily
    exist outside the kernel. the entire ip stack can be implemented from
    user space. (and it has been in the past.)

    > "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.


    every element of mounttab[] has an associated device letter. to
    mount the device, one does (typically)
    bind -a '#'^$letter /dev

    for example, to bind a second ip stack on /net.alt,
    bind -a '#I1' /net.alt

    > 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.


    all devices are accessed through devtab. it may be that that entry
    is the mount driver. the mount driver turns devtab[]->fn into
    the corresponding 9p message. (and vice versa.)

    - erik


  3. Re: [9fans] Re: 9P, procedure calls, kernel, confusion. :(

    > there is no client-side caching in the plan 9 kernel.

    *cough*, MCACHE?

+ Reply to Thread