Re: nnpfs/xfs tutorial

Kristaps Johnson <[email protected]> writes:
> I've made the documentation and sources available here:
> http://sysjail.bsd.lv/xfsskel
> 
Great! I'll take a look.

>   - Precise definition of tokens & their purpose?
>
Well, I'm not totally sure what the original intent was, but they are used
by nnpfs to ask for "rights" to operate on data/attributes -- normal read,
normal write.  The daemon then tells nnpfs it's current authority, and
occasionally that it has been revoked (due to a callback for example).
 
Some tokens are never used (lock, attr_w, shared read, etc) and are not
implemented.  In practice, ATTR_R means we have valid attributes, DATA_R
means we have a valid data handle, and DATA_W means we also are allowed to
modify the data depending on user rights etc.

>   - Precise definition of pag/cred and its purpose?
>
A PAG is a "process authentication group", we use it as a number
identifying the set of credentials to use for the operation.  You start off
with a default one.  Later on, a process may create a new PAG which all its
children inherit (until they possibly create new PAGs).

Anyway, for each PAG you may have different sets of credentials, allowing
you to work as [email protected] in one terminal and as [email protected] in another. Both
with the same local account "kristaps" :)

>   - struct installdata.offset and its purpose?
>
We have valid data from the beginning of the file and up to offset.
Command like `head' and `file' are fast, `tail' still has to fetch the
entire file.

>   - xfs_message_create.mode vs. xfs_message_create.attr.mode?
>
xfs_message_create.mode is not used.  Maybe it was meant to be used as open
mode (or token)?  I dunno.

>   - NNPFS_MSG_UPDATEFID?
>
"The node you think is `old_handle' really has `new_handle', change it."

We have an option to defer the (expensive) lookup of mountpoints, we just
lie about them (including the fid) until the user asks for the truth.  It
can also be used for disconnected operation.  If you "create" a file while
offline you won't get the real fid until the file is created for real when
network access is back up.

> NNPFS_MSG_WAKEUP_DATA?
>
A wakeup with a data buffer. Think pioctl replies.

(In my hacking branch I removed it).

>  NNPFS_MSG_COUNT?
>
"Number of valid message opcodes", the highest opcode + 1.

>   - xfs_message_bulkgetnode?
>
Hm.  I don't have that.  Could be useful for windows readdir where you need
the statinfo for all the nodes, too.  Or color-ls...

Is it an OpenBSD invention, or did it use to be in mainline?  I know people
have talked about it.

/t