> 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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
