[Buildroot] What's up with the kernel names? (Again)

["Thiago A. Corrêa" <thiago.correa@gmail.com>]

On Thu, Feb 12, 2009 at 3:16 PM, Ulf Samuelsson
<ulf.samuelsson@atmel.com> wrote:
>
>>
>> Hi,
>>
>> Ulf> Just for fun, I checked my OpenSuSE /boot directory
>>
>> Ulf> Guess what I found:
>>
>> Ulf> "vmlinuz" which happens to be a LINK to
>>
>> Ulf> ??vmlinuz-$(KERNEL_VERSION)-$(REV)-$PROJECT)
>> Ulf> ?
>> Ulf> There was also a:
>> Ulf> vmlinux-$(KERNEL_VERSION)-$(REV)-$PROJECT).gz file
>>
>> Ulf> Looks like the guys doing OpenSuSE are as "odd" as I am.
>>
>> And guess what the kernel outputs? A simple arch/x86/boot/bzImage, as
>> platform/distribution specific naming convention doesn't belong in the
>> mainline kernel.
>>
>
> No but it belongs in the distribution created by buildroot.
> Try making a remote upgrade when the old kernel and the new kernel has the
> same name.

Hardly any embedded device contains just a linux system without any
custom software made by the manufacturer of the product, which is
usually closed source.

Had the upgrade been motivated by changes in that closed source part,
the kernel would probably be the same.

Also, even if the kernel names had unpredictable entrophy in it, the
upgrade program has to handle it, removing the old binary, otherwise
you would fill up all the flash space.

> Your argument smells of
> "we have always done it in a certain way, and therefore we should always do
> it in the same way".
> There are some reasons why you may want to have a simple name,
> and all these reasons are covered by generating a symlink.

Actually, it looks like you are trying to come up with any sort of
argument against. Last one you could think of was that the ls *had* to
list files in a specific order. But even that could be done with
addition of a prefix. Now, 5 days later you come up with upgrading
problems.
The current solution does allow you to do the exact same thing, while
still giving the flexibility of opting not to use it at all. We are
not limiting your options, but rather giving more, why can't we just
let this thread go?

Even the u-boot patches could be made to work: Either look for a date
by strstr, or, adopt a template for the command to work, and set that
into the suffix. Same as before, except that instead of
linux-version-date, it would be uImage-version-date.

Then you could set the at91*_defconfig to that default, instead of
setting it into Config.in or makefiles.
It would be best implemented as the first solution, but the second one
is easiest.

> It is a good idea to make things as simple as possible, you are trying to
> make things simpler than that.
>

Hard coded prefix, suffix and extension plus symlink is much closer to
overcomplicated than current solution is to over simplification.

Kind Regards,
    Thiago A. Correa