grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Breakage from grub-mkconfig changes for grub-file


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Breakage from grub-mkconfig changes for grub-file
Date: Tue, 24 Dec 2013 01:38:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

On 24.12.2013 01:34, Colin Watson wrote:
> On Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> On 23.12.2013 23:01, Colin Watson wrote:
>>>   This should be redesigned so that there is some way to declare in a
>>>   grub.d script that it requires multi-platform support and should be
>>>   run multiple times.  (It *must* be this way round so that upgrades
>>>   work properly.)
>>
>> The idea was that platform-independent scripts were still runnable,
>> they'll just produce the same output N times and this list is just an
>> optimisations, specially to avoid running os-prober N times.
> 
> Granted, but in some cases those scripts might not be idempotent:
> consider a user-written "42_custom" (or whatever) script that adds a
> menu entry, for instance.
> 
Only one instance of it will be included on runtime.
>> The alternative will be to have something along the lines of different
>> hashbang or implementing this functionality as sh functions.
> 
> How about this simpler option: any script that needs to be run for each
> platform could have a magic comment that we grep for in grub-mkconfig.
> 
It's certainely a possibility even though I'm not a fan of magic comments.
>>>   The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen
>>>   mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the
>>>   platform names used in the GRUB build system, but yet they're exported
>>>   across the interface to /etc/grub.d/ as GRUB_PLATFORM.  This is messy
>>>   and confusing, and it's not clear what promises we make about future
>>>   changes here.
>>>
>>>   We should rationalise this before issuing anything as part of a stable
>>>   release, perhaps by adopting the same target_cpu/platform terminology
>>>   used in the build system.  Furthermore, if we made the namespaces
>>>   match up then it would be fairly straightforward to only run grub.d
>>>   scripts for platforms for which we have installed GRUB modules, which
>>>   seems as though it would be sensible.
>>
>> GRUB platform names don't match with the OS compatibility. On x86 other
>> than xen you can use the same kernel on all the platforms. On ARM, for
>> what is arm-uboot platform for us may require different kernels for
>> different hardware.
> 
> OK, but if it is a different concept then it should have a different
> name, not "platform" - otherwise it just seems confusing.
> 
Agreed. Do you have an idea for name?


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]