[Top][All Lists]

[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 ...
> 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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