Re: [PATCH] diskpart

[Neal H Walfield]

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

pgpfjMPKTzPW3.pgp
Description: PGP signature