Re: [PATCH,HURD] Fix grub-probe with userland partition support

[Samuel Thibault]

Vladimir 'φ-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 22:14:33 +0200, a 
écrit :
> On 24.04.2012 19:13, Samuel Thibault wrote:
> > Vladimir 'φ-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 15:19:25 +0200, a 
> > écrit :
> >> On 24.04.2012 14:42, Samuel Thibault wrote:
> >>> 0-sized indeed poses problems.
> >>>
> >>>> I'm surprised that Hurd doesn't offer a way to just ask "What does this
> >>>> filesystem translator consume?"
> >>> Because the whole point of the Hurd is to let the user have access
> >>> to more powerful ways.  A file can reside inside an iso file, which
> >>> is stored in an ext2fs, which is stored in a file,
> >> So much GRUB can handle.
> > But how to express that to GRUB? grub_guess_root_devices only returns
> > a series of alternative paths.  See below.
> By just giving the file in question.

That will not tell you which image has to be mounted to find it.

> >> As for the second, we're limited to what GRUB can do and so it won't be
> >> possible to have /boot on translator from hyperspace.
> > Sure.  But it can be something expressed in a complex way by the user,
> > which can actually be reached by GRUB.  That said, as I said earlier, we
> > can ask the user to refrain himself when it's about /boot.
> We can add more translators handling as-needed.

So would it be acceptable for now as a horrible-but-works solution to
use the output of sysopts:

ext2fs --writable --no-atime --no-inherit-dir-group --store-type=typed 
device:hd1

and

/hurd/ext2fs --writable --no-inherit-dir-group /dev/hd0s1

Drop the first parameter (translator path), -* options, and that leaves
only the device, with additional s_device:_/dev/_ mangling.

> >>> But we generally don't want to impose any syntax here, it could actually
> >>> be
> >>>
> >>> /opt/my/own/translator xyz
> >>>
> >>> I guess we'll have to impose some syntax anyway for whatever contains
> >>> /boot, so that grub can open it itself.
> >> There should be a standartised way to get this information for any
> >> conventional FS, otherwise it makes porting programs which use this
> >> information much more difficult and in most cases results in dirty
> >> workarounds.
> > So far, I've mostly seen GRUB really needing that information.
> I suppose that databases would want to know this for optimisations.

libstore does provide the best thing for that: the actual area on the
disk, which is what was used in the very first patch already, and which
is used for swap, etc.  But that reveals to be actually too precise for
GRUB.

Samuel