>
>
> Now, some comments about the small behaviors of the filesystem hooks.
>
> * netfs_check_open_permissions ought to do an fshelp_access check.
> In fact, you ought to make it refuse if O_READ or O_WRITE is set;
> then it will be impossible to reach the netfs_attempt_{read,write}
> hooks and you can make those call abort or use assert.
What error should be returned?
> * Most of the node operations (chfoo) you should pass through to the
> underlying node when they are on the root node (like trivfs does).
> Start by using io_stat on the underlying node to set flags, mode&~S_IFMT,
> nlink, uid, gid, author.
> That said, I'd have netfs_validate_stat reflect the node stats (mode,
> uid, etc) of the root node on each leaf node.
What do you recommend happen when one does a chown part/1? How about
a chown part? Should they effect the entire tree?
> * I'm not sure I want to have libdiskpart as a first-class library in the
> Hurd package. Maybe that code should just live in the translator. Or, if
> the code is really shared with grub, it should be made its own package
> and the source not live in the hurd at all.
The code is hardly shared with grub -- I stole a few constants. Also, the
partinfo utility might prove useful.
> * I'd like to see partition handling that is a bit more generic. e.g.,
> look for partition tables within partitions and make hierachical
> pseudo-directories, etc.
PCBIOS partition table are a linked list, so I am not sure it makes
sense in this context. It might be useful with BSD partitions, then one
might have:
/dev/sd0/1
/dev/sd0/2
/dev/sd0/3
/dev/sd0/4/a
/dev/sd0/4/b
/dev/sd0/4/d
With openbsd partition tables, one might have repetition of partitions,
however, I assume this would make sense.
> * The whole notion of producing pseudo-nodes that don't do i/o is kind of
> bogus. It's true that you can make reasonable things by making nodes
> that use storeio with a partition pseudo-node as the store. But that is
> a bit convoluted. The pseudo-nodes ought to behave like storeio nodes.
> You could do this by incorporating code like storeio has directly, or you
> could do this by automagically starting storeio translators when someone
> opens a pseudo-node for i/o (i.e. O_READ or O_WRITE is set).
Maybe merging this code with storeio is a better idea? Then if no
partition table was found, it would act as a normal storeio, otherwise,
the root would continue to be the entire disk and disk/* would be
partitions.
> * A feature: why not have an entry in the virtual directory that refers to
> the entire underlying store? You could also make i/o operations work on
> the root node, so that it is both a device file and a directory; that
> seems kind of natural if it's /dev/sd0 and you get /dev/sd0/1, etc.
> OTOH, it would be way easier to make "partition 0" the whole device and
> leave it at that.
The root already does, however, we should do this also.
> And finally, the most deep and important question for any program: the name.
> I think we should call it partitionfs.
I choose diskpart as the empty directories were already present in CVS.
PGP signature