[9fans] Dir->type & Dir->dev

[9fans] Dir->type & Dir->dev

[Eric Van Hensbergen]

The main pages are a little unclear as to the convention for
assignment of dir->type & dir->dev, particularly with respect to
synthetic file servers.  For devices I gather that type is the device
id (ie. 'c' for cons) and that dev is the instance (ie. #I2 for an
alternate IP stack).  Their use seems a bit more slippery when
implementing user space file servers -- particular since type,dev,qid
must(?) be unique per namespace.  Is there a best practices convention
that folks follow or is this something which most ignore and we are
just lucky most of the time?

             -eric

Re: [9fans] Dir->type & Dir->dev

[erik quanstrom]

On Sun Nov 30 10:12:00 EST 2008, ericvh@gmail.com wrote:
> The main pages are a little unclear as to the convention for
> assignment of dir->type & dir->dev, particularly with respect to
> synthetic file servers.  For devices I gather that type is the device
> id (ie. 'c' for cons) and that dev is the instance (ie. #I2 for an
> alternate IP stack).  Their use seems a bit more slippery when
> implementing user space file servers -- particular since type,dev,qid
> must(?) be unique per namespace.  Is there a best practices convention
> that folks follow or is this something which most ignore and we are
> just lucky most of the time?
>
>              -eric

there is a dir.type and a dir.qid.type.  i believe these are different.
the comment above dir.type in /sys/include/libc.h says that it's
system modified.  and, e.g. /mail/fs shows up as from the mount
driver.  the instance is typically pretty big.  the mount driver is
pretty careful to count instances.

; ls -l /mail/fs
--rw-rw-rw- M 105920 quanstro quanstro 0 Nov 30 10:17 /mail/fs/ctl
d-r-xr-xr-x M 105920 quanstro quanstro 0 Nov 30 10:11 /mail/fs/mbox

- erik

Re: [9fans] Dir->type & Dir->dev

[Eric Van Hensbergen]

On Sun, Nov 30, 2008 at 9:18 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>
> there is a dir.type and a dir.qid.type.  i believe these are different.
> the comment above dir.type in /sys/include/libc.h says that it's
> system modified.  and, e.g. /mail/fs shows up as from the mount
> driver.  the instance is typically pretty big.  the mount driver is
> pretty careful to count instances.
>
> ; ls -l /mail/fs
> --rw-rw-rw- M 105920 quanstro quanstro 0 Nov 30 10:17 /mail/fs/ctl
> d-r-xr-xr-x M 105920 quanstro quanstro 0 Nov 30 10:11 /mail/fs/mbox
>

That makes sense - any user space synthetic will have to be addressed
via mnt(3), so mnt(3) will assign/override type and instance data for
user space file servers as well as remote file servers.  Thanks.

               -eric

Re: [9fans] Dir->type & Dir->dev

[Charles Forsyth]

Qid.type is defined to be equal to the top 8 bits of mode (see stat(5))
and type and dev are defined to be for kernel use (also stat(5))
which is fine if you're not in the kernel.
but what if you are? type is just the device [unicode] letter,
and dev is assigned by the device, and might be the index of an instance
(eg, #I0 has dev 0, and #I1 has dev 1).  once exported and
mounted elsewhere such distinctions vanish because the mount driver
rewrites them, more or less thoroughly (ie, in both stat and read-on-directory).