[Buildroot] Redundant kernel patches in the snapshot from20070718

[Bernhard Fischer <rep.dot.nop@gmail.com>]

On Mon, Jul 30, 2007 at 05:51:49PM +0200, Ulf Samuelsson wrote:
>> On Thu, Jul 26, 2007 at 06:52:02PM +0200, Ulf Samuelsson wrote:
>>>tor 2007-07-26 klockan 16:23 +0200 skrev Hans-Christian Egtvedt:
>>>> Hello,
>>>> 
>>>> I am a bit confused to where I should put the kernel patch, there seems
>>>> to be two places expecting the same file.
>>>> 
>>>> toolchain/kernel-headers/kernel-headers-new.makefile expects them to be
>>>> in toolchain/kernel-headers.
>>>> 
>>>> target/linux/Makefile.in expects them to be in
>>>> $(BR2_BOARD_PATH)/kernel-patches.
>>>
>>>
>>>When you build the kernel-headers today you extract the kernel source
>>>to build_<ARCH> and you store the kernel headers in
>>>toolchain_build_<ARCH>/linux
>>>
>>>You have a single set of patches in toolchain header directory,
>>>This causes the following problems:
>>>* Confusion due to using same targets in two makefile fragments.
>> 
>> What two targets are you referring to? Please give an example (excluding
>> find target/ -iname "linux*mk").
>> 
>
>Try building Linux 2.6.21.3 with 2.6.21.5 headers.

"Doctor it hurts when i.."

I don't buy this sort of argument ;)

>The bug is that "package/linux/Makefile.in" does not apply the kernel
>patches when the kernel headers and the linux is not the same.

What is a legitimate scenario where you would do this?

In legacy updates, you'd backport fixes to a known and blessed version
of the kernel.

For a new release you should (or at least i would strive to) support
something recent, so there still the sane hdr==src holds true.

>>>* Cannot apply architecture specific patches, since
>>>  you may have conflicts between several patch-set's.
>>>* Cluttered directory
>> 
>> hm? Please explain.
>> 
>
>The AVR32 chips and the AT91 ARM chips uses the same peripherals,
>and therefore can use the same drivers.

fair enough.

So there is _one_ patch which is submitted upstream that is
linux-1.2.3.4-add-thisSpecificDevice.patch

>The linux support is developed by two teams.

This in in no way relevant :)
>
>If the SPI support in Linux is updated, then the same patch will be present
>both in the patchset for the AT91 and the patchset for the AVR32.

This is flawed. You're adding one device.

I my POV a board consists of components.

E.g. (just for fun) a graphic board let's say some board from S3 as an
example consists of:

Board(S3, ViRGE)
#if Data
Begin
	Vendor("S3")
	Model("ViRGE")
	Driver(chipset,	S3/ViRGE, virge_chipset)
	Driver(ramdac,	S3/ViRGE, virge_ramdac)
	Driver(clock,	S3/ViRGE, virge_clock)
End
#endif

i.e. a chipset, a ramdac and a clock.

Now if you do a board which uses a "custom" clock (or ramdac for that
matter), you just add a TI_0815_clock or TI_0815_ramdac2.

You certainly do _not_ duplicate all other components of the
board(-driver).

>If the same patch is applied twice to the kernel, it will fail the second time
>even if the patch is OK to apply once.

Yea, this exactly the reason is why it is flawed ;)
You don't even need peer-review, patch(1) will make this obvious.

[]
>linux then needs to be unpacked in "project_build_dir"

If you go down that route then yes. This is not the case today, is it?

>>>[PATCH NAMING]
[]
>>>Everytime you want to add a new kernel version, like 2.6.22.2
>>>you will have to add 770 kB to the buildroot tree, so it
>>>is not viable long term.
>> 
>> I wholeheartedly agree that it supporting several kernel-versions is not
>> viable. It doesn't make sense to keep multiple old $PATCH versions but
>> only the latest.
>> 
>> Also, it doesn't make sense to me to support more than let's say 2 or 3
>> versions per MINOR (e.g. 2.6.20.x, 2.6.22.x which is current at the time
>> of this writing.)
>
>I think we should support building any version of the kernel,
>and then we should allow the user to select which set of kernel headers
>should be applied, and if the user selects to use anything outside the
>things we have tested, then they are on their own.

indeed. Using hdr==src is fine. Certain versions of the kernel may even
have additional patches to add certain features. That's the way i
handled it up until now myself.

>I would like buildroot to be more than a toy.
>This means that we should not have built in mechanisms to obsolete stuff.
>I have customers which wants to keep products in the field for 10-20 years
>and still maintain them.

It is very unlikely that anybody will then use linux-6.7.38.2 headers
and a kernel-2.4.9. Those people will backport fixes to the blessed
version the used before (or something vaguely similar) instead.

I'd call using headers from linux-in-20-years but a kernel from 2004 a
toy application.
>
>This means that backwards compatability is very important.
>One way to handle that is to download the neccessary patches for
>old versions from a server instead of keeping them in the main buildroot tree.
>
>
>>>[PATCH SELECTION]
>>>We need to be able to build any kernel, not just the kernel
>>>currently supported by the kernel headers.
>>>It is probably desirable to be able to use the kernel headers
>>>for the same version as we are using, but also it should be
>>>possible to have kernel headers for one version of linux
>>>and use a different kernel for your target.
>> 
>> Nowadays there is no need for such a kludge anymore.
>> 
>
>Yes there is.
>If someone for some specific reason wants to use a certain version
>of Linux, and the kernel patches does not apply cleanly to that
>kernel, then you might be able to live with having kernel patches for
>a slightly off version of linux instead.

sure. If you want to use an arbitrary kernel (or package for that
matter), you can easily cross-compile it. It's not that we are removing
old toolchains or the like.

>>>I think that it should be possible in the menu system to select 
>>>which kernel to use (2.6.X.Y), and, for the kernel headers,
>>>we should have a finite number of patches which can be applied
>>>to generate the kernel headers. 
>>>These can be selectable using a "choice".
>>>A default would be selected based on the kernel version but,
>>>if the user so chooses, he can apply whatever patch he wants.
>>>
>>>This would allow you to use a 2.6.21.6 kernel while applying
>>>the kernel patches for 2.6.21.5.
>> 
>> This is very brittle.
>> Of course we can provide "generic" patches of the form
>> linux-2.6.2-this-that.patch
>> and try to apply them to linux-2.6.2[^\.]*
>> But this will fail if spots change under the patch. This is not 100%
>> robust imo.
>
>Not sure what you mean by "spots" but I

source code where a patch was ment to be applied to.

>>>Eventually the available patches will not apply cleanly,
>>>and then it is time to generate new patches,
>>>but it is likely that most of the patches will apply.
>> 
>> It may be likely across PATCH revisions but is not bullet proof.
>
>No, a guy locked to chains inside a dungeon, will not fall off a cliff.
>A guy without the chain runs the risk.

Thus we have distinct versions of sources a given premade patch is ment
to be applied against.
If you feel like not using a version for which a premade patch exists
you certainly can do this. If you do this then no pre-made patch will be
applied, which is fine, imo. Depending on the package it may even
compile and work.

>>>[PRO'S/CON'S]
>>>The main drawback of this proposal, is that if your kernel
>>>and headers are of the same version, you get a duplicated source tree.
>> 
>> This is not true. We're installing the headers into
>> toolchain_build_$arch/linux while the kernel itself is built in
>> build_$arch. The latter exists per $arch, yes.
>
>If the kernel headers and the linux are of two different versions,
>then there will be two "linux-2.6.x.y" in "build_<arch>".
>If both are of the same version, then there will be one 
>"linux-2.6.x.y" in "build_<arch>".
>
>If linux is built in "project_build_<arch>" and 
>the kernel headers are unpacked in "toolchain_build_<arch>",
>then there will be two "linux-2.6.x.y" source trees even if 
>the kernel headers and the kernel have the same version.
>This is a drawback but the overall gain if you build several 
>root file systems is monumentous.
> 
>
>> 
>> As said, we can easily unpack the kernel into one toolchain_build/ and
>> make O=/headers headers_install
>> and
>> make O=build_arch/linux-$VERSION/ all
>> 
>> if you prefer. This change is trivial.
>
>What happens if you want to apply AT91 (ARM) patches AND XScale (ARM)
>patches to the Linux tree and the patches conflict with each other?

Then those patches are broken. You're supposed to do small,
self-contained patches which are revieweable.

>I think you *have* to have one source tree per kernel.

Fortunately not. That's why we have *one* kernel tree that supports a
variety of arches and devices along a common infrastructure ;)

>There will be cases where this is overusing computer hard disk,
>but it makes the system much simpler.


>>>If they are of different versions, then there is no duplication
>>>and then it actually works. It does not do so today.
>> 
>> I don't do external-toolchains either. ;P
>> If you want that then fix it (i already said that) but make sure NOT to
>> break the common setup of using headers==src (which you broke with that
>> project stuff, no matter who checked it in).
>> 
>
>My plan is to have a gradual migration and have the old way
>of building linux and the BSP way with building linux in parallel
>until it is deemed to be ready for "production".

I'd prefer to see a working incarnation that changes this at once so it
can be reviewed.

>I more and  more belive in merging the kernel header stuff with the main build of linux.

This is trivial and should basically boil down to
(echo "### kernel header stuff" ; cat toolchain/kernel-headers/kernel-headers-new.makefile)>> \
target/linux/Makefile.in
svn rm toolchain/kernel-headers