Re: Fixing grub-probe to work with user-space part stores

[Carl Fredrik Hammar]

Hi,

On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote:
> The first one would be to make part.c embed extra information in its
> stores and their encoded form (possibly in the "misc" fiels of a remap
> store). This would force it to create a new layer instead of reusing
> the underlying store, which could reduce performance slightly in some
> cases.

Where talking about an extra function call through a function pointer
here.  Any effect on performance is negligible.

> It would also change the existing principle by which stores and
> storage_info provide a way to access the underlying storage in the
> most direct way possible, as opposed to encoding the history of how
> the store was constructed.

This is the biggest problem with this idea.  The only way this could work
reliably is if we introduce a new RPC file_get_underlying_storage_info(),
which returns the backing store used by the filesystem.  (I'm not sure if
this should be in fs.defs or fsys.defs though.)  This would be a hurdish
analogy to st_dev thin is returned by stat(), except that it returns
a store instead of a device number.  IIRC grub-probe on other systems
matches st_dev with the st_rdev of device files, but this doesn't work
on Hurd because having stable device numbers in a distributed system is
actually quite hard.

It could also be a good idea to have a proper part store instead of just
remapping the device store.  Then, you could just look at the name of
the part store to get the partition number.

> The second one, which I favor and am working on so far, would be to
> enumerate the _grub_ devices, and use get_storage_info() on them too.
> We would compare the result with that of the file being looked up, and
> use the grub-detected partition information to deteremine on which
> _grub_ device the file resides. The result would be converted to a
> system device node path by using the device.map information. In this
> scenario, on Hurd, the device node path would be used as a name only,
> and grub-install could be made to work on, say, disk image files whose
> partitions would have been mounted using the part: store.

This is a bit hacky but could be a good intermediate solution if your
not comfortable with adding a new RPC that isn't strongly related to
your project.

Regards,
  Fredrik