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

[Samuel Thibault]

Vladimir 'φ-coder/phcoder' Serbinenko, le Wed 25 Apr 2012 00:31:26 +0200, a 
écrit :
> On 25.04.2012 00:21, Samuel Thibault wrote:
> > 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:
> >>>>>> I'm surprised that Hurd doesn't offer a way to just ask "What does this
> >>>>>> filesystem translator consume?"
> >>>>> 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 I said: currently we assume that image is for VM use, so nothing
> needs to be specifically mounted. Just return image filename.

That would work with only one layer.  See my example above, it has
several layers, and you'd have to know the image filename at each layer.

I'm not saying that GRUB should implement all these layers.  I'm just
explaining why the "what does this translator consume?" is not a trivial
question at all in the Hurd, and thus does not have any interface for
it, and we have to define one that would only work for the trivial
cases.

> > 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.
> Yes it will, just we need comprehensive error messages on failure and a
> comment in code that it's not complete solution.

Sure.

> >>>>> 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.
> It's more of it not being stable. You could access all the files by
> blocklists but it would fail very quickly

Yes, because it's too precise, and thus not stable.

Samuel