[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Breakage from grub-mkconfig changes for grub-file
From: |
Andrey Borzenkov |
Subject: |
Re: Breakage from grub-mkconfig changes for grub-file |
Date: |
Tue, 24 Dec 2013 06:56:43 +0400 |
В Вт, 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 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.
>