All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Born <futur.andy@googlemail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: Grub version variable in shell
Date: Sun, 11 Mar 2012 12:52:45 +0100	[thread overview]
Message-ID: <4F5C920D.7070808@googlemail.com> (raw)
In-Reply-To: <4F5C1321.1050403@gmail.com>

Am 11.03.2012 03:51, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 11.03.2012 03:40, Andreas Born wrote:
>> Hi,
>>
>> it would be great to have a variable like version or grub_version in
>> the shell. Sorry, if there is already such an option and I didn't find
>> it. But I only saw cpu and platform as well as the feature variables.
>>
>> This is useful, if you want to use some new feature or don't want to
>> use some ugly workaround anymore, which you needed for an older version.
> We don't use grub_version because it would give only very approximate
> idea of features supported and so only marginally useful and is likely
> to make devs use suboptimal method. Instead we define variables like
> feature_foo. Good example is from root setting code:
> if [ x$feature_platform_search_hint = xy ]; then
>    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt10
> --hint-efi=hd0,gpt10 --hint-baremetal=ahci0,gpt10  UUID
> else
>    search --no-floppy --fs-uuid --set=root UUID
> fi
Thank you, I get your point.
Still I think version can be useful to exclude versions with bugs (or 
features) they do/(don't) have. For example on 1.98 I had to reexport 
all variables in every configfile. This was dirty and hard to maintain 
so I do not want to maintain this anymore. Instead of silently failing, 
I'd like to provide users of older versions with a very simple menu 
combined with a warning. (Usually in normal boot scenarios they're using 
my grub build anyway.) I don't see how this should be possible without 
my 'if keymap' hack. I think neither checking for a command existence 
nor a feature is a reliable method to always ensure a minimum version. 
Of course if you have a better idea, that's even more welcome.
Maybe something like a grub_version_min command? And possibly *_max?

Apart from that I guess it would be nice to have such a variable to 
display the version someplace or to check it. Yes, I know it is already 
displayed in multiple places, but I don't think in gfxmenus.

Did those feature variables even exist in 1.99?
>
>> Currently, I'm doing a check like 'if keymap' to show a minimal menu
>> to pre-1.99 users with a warning that they're version is too old
>> instead of giving them garbage if at all. But that check does not feel
>> really reliable nor clean. ;)
>> Especially given the recent discussion regarding backwards
>> incompatible changes, this would be a really big help even if they're
>> only small changes. But I imagine there are other uses too. The early
>> there is such a variable the more useful it is, but I wouldn't
>> consider it critical.
>>
>> On the other hand it's quite hard to parse a version string on the
>> grub shell, especially if distributions choose to change it to some
>> Brainf**k imitation. Or they give the code a major revamp and then
>> don't change it. Well, maybe grub could get a Brainf**k parser at
>> least. :D
>>
>> For completeness two-line patch attached. (Untested)
>>
>> Andreas Born
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



  reply	other threads:[~2012-03-11 11:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-11  2:40 Grub version variable in shell Andreas Born
2012-03-11  2:51 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 11:52   ` Andreas Born [this message]
2012-03-11 12:47     ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 13:55       ` Andreas Born
2012-03-11 14:07         ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 14:17           ` Andreas Born
2012-03-11 14:20             ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 14:58               ` Andreas Vogel
2012-03-11 21:13                 ` Seth Goldberg
2012-03-11 12:52     ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 14:39       ` Andreas Vogel

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=4F5C920D.7070808@googlemail.com \
    --to=futur.andy@googlemail.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.