[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