All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Gilbert <floppym@gentoo.org>
To: grub-devel@gnu.org
Subject: Re: [PATCH] Increase flexibility of kernel naming, allow non-versioned kernels.
Date: Sun, 29 Apr 2012 16:07:06 -0400	[thread overview]
Message-ID: <4F9D9F6A.7080803@gentoo.org> (raw)
In-Reply-To: <4F9D6C1C.6040202@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

On 04/29/2012 12:28 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 29.04.2012 06:46, Mike Gilbert wrote:
>> I am relaying a patch by Robin Johnson, one of the core infrastructure
>> staff at Gentoo Linux. In the process of building some Gentoo servers
>> utilizing GRUB 2, he has made some changes to 10_linux that should make
>> grub-mkconfig "out of the box" for additional users.
>>
>> I did a little work to clean up the indentation and wrote a proper
>> changelog. Credit should go to him.
>>
>> Here is his description:
>>
>> Increase flexibility of kernel naming, allow non-versioned kernels.
>> The block that tried to find the kernels was getting unweidly long, as
>> was not
>> easily customizable by users or distributors. Refactor to introduce a new
>> variable, GRUB_KERNEL_GLOB, that allows complete control over the naming
>> used
>> to search for kernel binaries.
> It was well structured and its length is solely due to distros using
> multiple names. We can't make it shorter and this patch surely didn't.

Right. I think the intent is not to make it "shorter", just slightly
easier to manage.

> Also it looks like it actually degraded compatibility on POSIX systems.

Can you be more specific? I did not spot anything obviously incompatible
with POSIX, but I'm certainly not an expert on the subject.

> I don't consider that being able to customise the kernel naming is of
> any advantage. Saying otherwise is like saying "let's make location of
> /etc/passwd customizable". Some objects just have to be named as given.

I do not follow that analogy. In contrast to /etc/passwd, the only
program on the system that actually needs to know the path to the kernel
is the boot loader. So long as the boot loader can find it, you can put
the kernel anywhere, and name it anything.

> I don't see any advantage to renaming kernels, especially given that you
> can change versionstring as you see fit.

I agree that there is no "advantage" to these various naming schemes; it
is just something that people have done over the years due to the lack
of a standard back in the day.

We have many users on Gentoo who compile their kernel and then manually
copy the resulting bzImage to /boot with whatever name they please. This
patch is an attempt GRUB compatible with that reality.

I am respectfully asking you to merge it to save myself some work in
re-basing a disto-specific patch, or my users from having to change
their behavior due to a somewhat rigid boot loader configuration file
generator.

>> Add 'bzImage' to the list of default names to support more distribution
>> naming
>> variants.
>>
>> Adjust the default set of globs to look for unversioned kernels before
>> versioned kernels, to find symlinked kernel names.
> Additionally empty version would probably result in some quirks not
> addressed in this patch.

Could you expand on this? I do not have the knowledge you do in this
area, so I cannot predict all possible problems.

Thanks.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

  reply	other threads:[~2012-04-29 20:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-29  4:46 [PATCH] Increase flexibility of kernel naming, allow non-versioned kernels Mike Gilbert
2012-04-29 16:28 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-04-29 20:07   ` Mike Gilbert [this message]
2012-05-01 23:17     ` Vladimir 'φ-coder/phcoder' Serbinenko

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=4F9D9F6A.7080803@gentoo.org \
    --to=floppym@gentoo.org \
    --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.