From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: Breakage from grub-mkconfig changes for grub-file
Date: Tue, 24 Dec 2013 01:38:18 +0100 [thread overview]
Message-ID: <52B8D77A.8070904@gmail.com> (raw)
In-Reply-To: <20131224003444.GA28338@riva.ucam.org>
[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]
On 24.12.2013 01:34, Colin Watson wrote:
> 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.
>
Only one instance of it will be included on runtime.
>> 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.
>>> 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.
>
Agreed. Do you have an idea for name?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
next prev parent reply other threads:[~2013-12-24 0:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-23 22:01 Breakage from grub-mkconfig changes for grub-file Colin Watson
2013-12-23 22:21 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-24 0:34 ` Colin Watson
2013-12-24 0:38 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2013-12-24 1:27 ` Colin Watson
2013-12-24 2:56 ` Andrey Borzenkov
2013-12-24 3:07 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-24 12:10 ` pfsmorigo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52B8D77A.8070904@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.