Re: fdisk

[Roland McGrath]

> What are the thoughts on the Correct Way to do fdisk?  I can now,
> using device_read, find the partition information on the entire disk
> (including past 4GB, however, I imagine that this is limited to either
> 2G*512=1TB or 4G*512=2TB).

Theoretically 2TB should be the limit imposed by the device_read RPC
protocol (i.e. the recnum_t type).  I wouldn't really bet that there is no
truncation in the Linux driver code or the gnumach glue driver code.

> If using device_read and device_write is the Correct Way, how
> does one cause the kernel to reinitialize the storeios (or is this
> even necessary)?  

The kernel doesn't have anything to do with a "storeio", whatever it is you
mean by that.  I don't think there is any way to get gnumach to reread the
partition table without rebooting, but I only checked briefly.

> Also, is there a way to find out is a device is currently open (e.g. by
> another process, such as, a storeio) and is there a way to ask it to
> shutdown?

I don't think there is a way to find out if an open device port exists or
not.  In gnumach, device_close will shut down access to the device
regardless of outstanding send rights to an open device port; but in
oskit-mach, device_close is a no-op and the kernel only shuts down the
internal state when the last send right is released.  At any rate, what you
want to do is just get all relevant Hurd translators to close the device
and reopen it (or restart the translators).  I think that in the case of
storeio and the filesystems, you need to restart the translators because
they provide no way to force them to close and reopen the store; the
friendly way to do this is with fsysopts -g.

> If adding an rpc to libstore is the Right Way, where should this be
> added?  Is there anything in particular it should look like?  What
> should a device do that has no geometry?  How about when, e.g., hd0 is
> modified and the changes need to be propagated to, e.g., hd0s1.

I don't understand what you mean by "adding an rpc to libstore".  RPCs are
things in protocols.  libstore is a library of code.  I can't think of
anything directly libstore should have to do with this, except perhaps make
it easier to close and reopen a store so as to refresh anything that changed.

In the longer term, the proper thing is to have partition handling done
altogether at the Hurd level rather than the kernel level, and then
naturally it would be handled through libstore.  But rather than libstore
knowing anything about partitions, it makes more sense to have a translator
similar to storeio that understands partition table formats and uses the
existing remap store type to implement partitioning of an underlying store.