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: Colin Watson
Subject: Re: Breakage from grub-mkconfig changes for grub-file
Date: Tue, 24 Dec 2013 01:27:41 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Dec 24, 2013 at 01:38:18AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 24.12.2013 01:34, Colin Watson wrote:
> > On Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' 
> > Serbinenko wrote:
> >> 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.

Well, OK, but is there really no possible grub.cfg code that would be
non-idempotent?  Besides, people already complain about generated
grub.cfg files being noisy. :-)

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

Nor I, normally, but they seem like a reasonable option 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?

Hmm.  Maybe GRUB_OS_KERNEL_TYPE or GRUB_EXPECTED_KERNEL or something?
(We would also want to avoid confusion with the GRUB kernel.)

-- 
Colin Watson                                       address@hidden



reply via email to

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