On Thu, May 15, 2014 at 11:30:47PM +0200, Lennart Poettering wrote: > On Thu, 15.05.14 19:37, Matthew Garrett (mjg59@xxxxxxxxxxxxx) wrote: > > Windows ends up with reduced access to the hardware. We do what OS X > > does, not what Windows does, because that's the only way to get (for > > example) working Thunderbolt. > > You are not really suggesting that having a second HFS+ ESP in place is > what turns on Thunderbolt, are you? No, but if we want Thunderbolt then the only way we can integrate with the OS X boot preferences is with the bootloader on an HFS+ partition. It's also the only way we get a reasonable recovery experience if the user ever clears the PRAM, which is still a recommended diagnostic procedure on Apple hardware. > > What's the objection to specifying a mechanism for chainloading? > > Chainloading for MBR? Well, for starters, that there is no need for it, > and clearly legacy. There clearly is a need for it, otherwise we wouldn't be talking about it. > However, more importantly: one design decision of the BLS was to not > require cross-device links. We consciously avoided all the complexities > this involves, and will rely on the kernel having identified the > ESP/boot disk, from which we read what we need. Cross-device/partition > links always get nasty, require invention of a spefication language, > involving technology-specific identifiers... On EFI the device paths > generally are ignored if a partition UUID is included, since actually > checking the device path is so error prone and broken. And then trying > to come up with a scheme that works on both EFI and on MBR is just > intensly complex. Hence: we would rather not reference anything outside > of the immedaiety boot partition. I appreciate the design goal. I just don't think it results in a broadly useful specification. > I really don't see why grub's native old config wasn't good enough for > that. THe BLS module I wrote for grub was supposed to be used in > combination with a fixed config file for any other windowses you might > have installed. Like I said, if we're changing our configuration format then there's a strong incentive not to split boot configuration between two different formats. Given the choice between adding complexity to tooling and complexity to users, it seems like we should be the ones doing the hard work. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
