[Buildroot] target/device/Atmel kernel patches
jacmet at uclibc.org
Thu Jan 29 14:57:15 UTC 2009
>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson at atmel.com> writes:
Ulf> The first release of the product does not mean it enters
Ulf> mainteance mode. There is further active developement after the
Ulf> first release to add feature.
To their custom applications I take, rather than the cots rootfs
components of buildroot?
Ulf> At one point in development, there is a decision to freeze
Ulf> kernel version and any errors found will be handled by patching
Ulf> that kernel version, sometimes backpatching from newer kernels.
Ulf> Once that point is reached, then it becomes a very serious decision
Ulf> to move to a new kernel.
The same probably goes for buildroot?
Ulf> One of our key customer is working on a major release
Ulf> using the 2.4.x kernel version they selected in 2004.
Giggle, as long as I don't have to do it ;)
Ulf> Your approach, will automatically disqualify the use of Buildroot
Ulf> for any customers following normal behaviour.
Why? It obviously didn't disqualify the kernel.
Ulf> I have met two customers using buildroot this week, and they
Ulf> point out that the only use they find for buildroot is as a way
Ulf> to get the latest patches/build recipes, and they cannot do
Ulf> anything useful with buildroot itself due to its higly volatile
Ulf> nature. They need stability, and they do not want to make their
Ulf> own decisions.
That's why I'm doing releases.
>> For starting a new project, selecting anything else than the 2.6.28
>> (or even better, the latest 2.6.29-rcX) seems pretty silly to me, but
>> I'm even stretching it to include 2.6.27 just in case.
Ulf> I was told some time ago, that the latest version of Xenomai for
Ulf> ARM only runs on 2.6.26 kernels. I do not know if this has
Ulf> changed, but there are drawbacks on beeing too hasty.
Could be, have never used Xenomai - But that's the "joys" of using out
of tree stuff. It can handly be anyone elses fault than the Xenoami
Ulf> If you continue your thinking, then you will soon delete 2.6.27 and then
Ulf> 2.6.28 etc.
Ulf> making this something you can use for evalution but nothing more.
Again I don't see how this is. I have used buildroot for commercial
products for years, even without releases. It's just a question of
managing it, just like for the Linux kernel and U-Boot and all the
Ulf> The user interface for building linux is clean and simple
Ulf> and I think that people using old kernels, know how to come around
Ulf> any difficulty they will stumble upon and can handle that with
Ulf> custom patches, without the main buildroot team beeing involved.
Just like for Linux and all the other open source projects they are
using they have the choice between staying uptodate and get the newest
features/bugfixes or stick to an old version and backport what they
I don't see how buildroot is any different here.
>> So again, what kernel versions in arch-arm can we remove from svn?
Ulf> If we want to cover 95% of the cases, we need to keep kernel versions which
Ulf> are minium 2 years or younger, but 3 years is desirable.
That's completely unrealistic with new major upstream releases every 3
months. I think we should rather aim for something like the last 2-3
>> Of course there is, otherwise the number of configuration combinations
>> to test would grow astronomically.
Ulf> No, because the kernel is orthogonal to the file system,
Ulf> I see that we need to test kernels when they are are released
Ulf> and then the kernels should be frozen.
Those old and obsolete patches don't belong in buildroot proper (in
fact I don't think we should have ANY feature patches, just bugfixes -
But that's another discussion).
We already have a situation where more than half the size of buildroot
is patches, continuing to grow this is not a workable situation.
If people want to use an old kernel they can maintain it outside of
buildroot or in their local buildroot tree.
I do agree we should make it easier to build u-boot / linux from a
non-mainline svn/git/whatever tree, that's something I will work on
after the release.
Bye, Peter Korsgaard
More information about the buildroot