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 04:07:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

On 24.12.2013 03:56, Andrey Borzenkov wrote:
> В Вт, 24/12/2013 в 00:34 +0000, Colin Watson пишет:
>> 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.
>>
>>> 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.
>>
> 
> I have a feeling that we are doing it backwards. What we actually want
> is to know file type. So what about making grub-file print it instead of
> having ever growing list of conditions? I.e.
> 
> grub-file --print {cpu|os|bits|...} 
> 
> and simply using it in every script to generate run-time condition like
> in (simplified)
> 
> cpu=$(grub-file --print cpu)
> 
> cat << EOF
> if [ \$grub_platform = $cpu ] ;  then
> menuentry ...
> EOF
> 
> And this could be wrapped in grub_mkconfig_platform_condition function.
> 
The same file can have several formats and it's actually pretty common
to squeeze several formats in the same image. Like EFI image and bzImage
in the same file.
> 
>>>>   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.
>>
> 
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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