On Thu, May 15, 2014 at 11:30:47PM +0200, Lennart Poettering wrote:
On Thu, 15.05.14 19:37, Matthew Garrett (mjg59(a)srcf.ucam.org) 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(a)srcf.ucam.org