On Feb 5, 3:35 pm, [EMAIL PROTECTED] (Charles Forsyth) wrote: > you can see the structures themselves in /sys/src/9/port/portdat.h > > inside the kernel, the traditional integer file descriptor indexes an array > of pointers to (possibly shared) > instances of the channel data structure, Chan, which contains the integer > fid, an open mode, a current offset, > and most important a pointer (or an index into a table of pointers) > to the Dev structure for the device driver associated with the Chan. each > device driver implements its > own name space (ie, operations such as walk, dirread, stat) including the > file i/o > operations (eg, open, read, write). most drivers use a small library > (/sys/src/9/port/dev.c) > to make implementing simple name spaces mainly a matter of defining a table > and some conventional calls for walk, stat, wstat, open, and dirread (which > is handled as a special > case inside the device's read operation, not as a separate entry in Dev). > > all open files have a Chan, but not all Chans correspond to open files (they > can mark > current directories, or more interesting the current location in a walk of a > name space). > > inside the kernel, operations are done by > Chan *c = p->fgrp->fd[fd]; > devtab[c->type]->walk(c, ...); > devtab[c->type]->read(c, va, n, offset); > and so on. fairly obvious stuff, really. > > >Q. Does it mean that every RPC message essentially has to end up being > >implemented via that procedural interface? > > one interesting driver (ie, one Dev) is the `mount driver' > (/sys/src/9/port/devmnt.c). its implementations > of walk, open, stat, read, write, etc build 9P messages representating the > corresponding operations and > exchanges them on any given file descriptor (ie, Chan) using > devtab[...]->write and devtab[...]->read > so it doesn't care what sort of file descriptor is used (pipe, network, ...). > > (an alternative might be to use 9P messages throughout.) > > >>>"A table in the kernel provides a list of entry points corresponding one > >>>to one with the 9P messages for each device." > >Q. Can I relate this 'table in the kernel' to the 'representation in a > > it's the devtab[] that lists pointers to the Dev structures representing > configured devices.
Thanks a lot for the reply. For whatever I could make out, does it work like the following? 9P is used universally in plan9 to deal with files. If the file is present in the kernel resident file system, then a direct procedure call is enough, else, the mount driver comes into picture. If its in the kernel resident file system, then the channel of the file is looked up for the Dev structure (the device driver corresponding to the file being referred to by the channel) , which defines all those procedures, that may be finally executed. If its not.... then....? 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. Thanks once again.
