Re: [PATCH] diskpart

[Roland McGrath]

> > * 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?

Oh, I dunno.  EACCES or EROFS maybe.

> What do you recommend happen when one does a chown part/1?  How about
> a chown part?  Should they effect the entire tree?

Eh, whatever.  I think it would be ok for these to fail with EOPNOTSUPP.
Changing the root node would be ok too, but probably surprising to someone
who thought they could set the individual nodes separately.

> The code is hardly shared with grub -- I stole a few constants.  Also, the
> partinfo utility might prove useful.

I have since been reminded of GNU Parted and the library that goes with it.
Can we use that?

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

That's what I had in mind.  But there's no reason it oughtn't detect a PC
partition table within a PC partition table and behave accordingly, even if
a PC doesn't.

> With openbsd partition tables, one might have repetition of partitions,
> however, I assume this would make sense.

I'm not sure what you mean.

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

I'm not really sure what is the cleanest approach to this.  I don't think
it's appropriate to just shove this partitioning functionality directly
into storeio.

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

Oh, if the root does then that is good enough for me.

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

Heh.  Well, names change.  We have heretofore called everything that
provides a directory tree *fs, and called the single-node things *io.