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: >>> Vladimir 'φ-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 11:55:33 +0200, a >>> écrit : >>>> They have iso9660 spanning through >>>> the whole disk but all of the disk other than the first sector is >>>> in some kind of partition table to avoid it being accidentally >>>> overwritten. So even though the file itself is inside a partition, we >>>> want the whole disk. >>> The partition itself can not be mounted? >> No, since it contains FS structures at wrong offset. > Ok. BTW sometimes partition can be mounted but contains another FS which references the same file by another name or not at all. >>> 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. But it currently always suppose that the file will be for VM and not host use. >> We don't handle loopback automatically right now since it's not clear >> whether it's a loopback for VM or loopback used on host. > You'd need to know which files to open anyway. You don't want to browse > all filesystems for that :) So the OS-specific function has to tell you. Yes. >> 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. But this problem isn't Hurd-specific. A simple GNU/Linux example is unionfs: currently we can't traverse it even if it refers to something easy. Trouble is that unionfs/translator reference "foo" can point to different files depending on circumstances and we need to follow this changes if they happen behind the grub-mkconfig back (e.g. if unionfs had kernel just in branch1 and then it was moved to branch2 we would need to handle this change without rerunning grub-mkconfig). >>> 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.
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
