Re: About firmware facilities

[Brendan Trotter]

Hi,

On Tue, Sep 15, 2009 at 9:58 AM, Colin Watson <address@hidden> wrote:
> On Tue, Sep 15, 2009 at 09:26:55AM +0930, Brendan Trotter wrote:
>> An OS could choose to use the information provided by GRUB, or choose
>> to ignore the information provided by GRUB.
>
> Sure, but the less code that needs to go in the boot loader the better.
>
>> Assuming GRUB implements something that isn't hopelessly inadequate,
>> I'd prefer to attempt to use the information provided by GRUB (and
>> then have a fall-back). However, I may be a little unusual, in that
>> I'm willing to do a lot of extra work to avoid a little unnecessary
>> end-user configuration.
>
> Don't get me wrong, I wasn't suggesting end-user configuration - I'd
> rather have it in grub-mkconfig than in the core, that's all.
>
>> With this in mind, as an OS installer developer, what form of language
>> identifier would you consider the 'least hopelessly inadequate"? What
>> if GRUB used the exact same language identifiers that (for e.g.)
>> Ubuntu already uses?
>
> You mean glibc locale identifiers with any territory and character set
> information stripped off, and the variant stripped off unless it's
> Portuguese or Chinese since those are the only currently significant
> cases where language variants have significant enough differences to be
> worth considering as essentially separate languages?
>
> Oh, and locale configuration tends to go together with keyboard
> configuration to some extent (at least for the purpose of setting
> defaults); since text entry is possible in GRUB it makes some sense to
> be able to configure the keymap, and you want to be able to pass that on
> to the operating system as well. Language-to-keymap mapping is a
> non-trivial problem often involving dispute resolution among local users
> to figure out the most appropriate default, and, for us, the keymaps
> themselves are maintained as part of the xkeyboard-config project and
> change quite frequently.
>
> Beyond the provision of some generic core facilities such as setting a
> keymap, this honestly doesn't seem suitable for the boot loader core,
> and nor does it seem likely to be particularly portable among anything
> other than quite closely related operating systems. Of course it does
> pretty much exactly what we need, but it's far too ad-hoc to live
> outside a scripting language, IMO.
>
> If GRUB made up its own set of identifiers, then somebody would have to
> maintain the list, and my expectation would be that churn would be
> substantial and frequent. If it used some kind of generic superset, I'd
> expect that we'd end up ignoring it and doing our own thing anyway.

If GRUB 2 supports internationalization for it's own menu, etc, then
they'll need to do something to track which language and which
keyboard mapping anyway. All I'm suggesting is that (in addition to
all the work needed anyway) the multi-boot information structure
(passed to the OS/kernel) include identifiers that indicate which
language (and keyboard mapping) that GRUB used. It's probably about 6
additional lines in the code that creates the multi-boot information
structure.

I honestly don't care where GRUB gets this information from (whether
it can be modified during boot using GRUB's menu, or if it's set when
GRUB is installed or compiled, or if it's specified by some sort of
script, or whatever). I only care about the header in a multi-boot
compliant OS image and the data passed by multi-boot compliant boot
loaders to the OS (where "multi-boot compliant" includes GRUB, but
doesn't exclude any other implementations of the multi-boot
specification).


Cheers,

Brendan