Re: grub vs st_dev (aka fsid) / st_rdev

[Samuel Thibault]

Carl Fredrik Hammar, le Tue 10 Nov 2009 13:30:30 +0100, a écrit :
> > That's not a problem since in that case the FS above it will have to be
> > restarted too. Note that a storeio can't time out while an FS is still
> > running.
> 
> The FS can use file_get_storage_info and use the store directly,
> after this it doesn't need storeio.  This is what ext2fs does.

Ah, I didn't know that. Mmf.

> > > The ideal would be to derive it from the underlying Mach device somehow.
> > 
> > Not all storage are Mach devices.
> 
> I assumed that was the case for the ones that are interesting for grub.

Yes, but then to realize unicity it's more difficult, as you have
several sources of IDs. You can of course use a prefix to identify where
it comes from etc, but it becomes clumsy.

> > It is a bug to me: it should rather return a _file_ storage type, with
> > the offsets etc. within the file. And then the caller can call storeinfo
> > on the file itself (foo), etc.
> 
> You could get this behaviour by doing:
> 
> $ settrans -c bar /hurd/ext2fs file:$PWD/foo

Along with your explanation above, I understand, ok.

> But then the new ext2fs instance will also use normal file IO,
> instead of using the Mach device directly.

Yep, understood.

That being said, it was mostly to let grub detect as soon as possible
(i.e. as soon as grub-install) that a particular FS is not on a device
but in a file.  I doubt it will really be useful in practice, and if
somebody was really putting the /boot or /hurd FS in a file, he'd
probably deserve having to understand why grub can't access it :)

> > As a parent store you mean?
> 
> This is perhaps more accurate, but in store terminology all dependencies
> to other stores are called children.

Ok.

Samuel