[Buildroot] Redundant kernel patches in the snapshot from 20070718

[Buildroot] Redundant kernel patches in the snapshot from 20070718

[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.

AFAICT this is redundant, what is the need to put the same patches in a
board specific folder? Should the target/linux/Makefile.in first do the
patches in toolchain/kernel-headers and then
$(BR2_BOARD_PATH)/kernel-patches if it exists?

-- 
Mvh
Hans-Christian Egtvedt

[Buildroot] Redundant kernel patches in the snapshot from 20070718

[Ulf Samuelsson]

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.
* Cannot apply architecture specific patches, since
  you may have conflicts between several patch-set's.
* Cluttered directory
* Multiple instances of the same patch with different names.
* Limited number of kernel versions supported.

[CONFLICTS]
Both the kernel headers and the target/linux/Makefile.in
work with $(BUILD_DIR) and it only works when the kernel
and headers are the same. The shared targets cause all
kinds of problems. We need to separate the two makes.

I think that the kernel-new-headers should actually
be moved to the target/linux/Makefile.in to avoid
the current confusion.

Generating the kernel headers is part of the toolchain build
and it makes much more sense to me to generate the headers
in the $(TOOLCHAIN_BUILD_DIR) like it is done for the 2.4 kernels
I have tested building the kernel-headers in this directory
while building the kernel in the $(PROJECT_BUILD_DIR)
and this seems to work without any problems for x86 and ARM,
regardless if the kernel version and kernel headers are the same
or not.

[PATCH NAMING]
If you want to support a specific $(LINUX_VERSION),
the "linux-$(LINUX_VERSION)*.patch" files are applied.

When you check the kernel-header patches, it shows that there are
several patches with identical contents but different names.

This means that you cannot select kernel version at random.
You HAVE to select a supported version 
(2.6.x where x is {8, 9, 11, 12, 20.4, 21.5, 22.1}).

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.

[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.
It probably does not make sense to 

If we select a kernel, we may still want to keep the toolchain
even if we bump the version of the kernel to the next minor number.

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.

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 it therefore better to have a list of broken out patches that can be
applied, than full patchsets for each kernel version.
Result is more flexibility and no need to have duplicated patches
in the patch directory.

[ARCHITECTURE/BOARD SPECIFIC PATCHES]
On top of the kernel header patches, we should be able to 
add the board specific patches.

We know that you normally cannot apply the std AT91 patches and the
AVR32 patches at the same time, so you cannot just copy these to the
kernel-headers directory. I assume that there are similar
problems with patches for different ARM processors etc.

The current method. using $(BR2_BOARD_PATH)/kernel-patches on
top of the kernel-headers would work for me.

[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.
If they are of different versions, then there is no duplication
and then it actually works. It does not do so today.

If this proposal is implemented, then each user can select kernel
version at random, and can actually very easy compile multiple kernels
in the tree, by just generating a new project.
You do not have to recompile all the applications to introduce
a new kernel.


> 
> AFAICT this is redundant, what is the need to put the same patches in a
> board specific folder? Should the target/linux/Makefile.in first do the
> patches in toolchain/kernel-headers and then
> $(BR2_BOARD_PATH)/kernel-patches if it exists?
> 

[Buildroot] Redundant kernel patches in the snapshot from 20070718

[Bernhard Fischer]

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").

>* Cannot apply architecture specific patches, since
>  you may have conflicts between several patch-set's.
>* Cluttered directory

hm? Please explain.

>* Multiple instances of the same patch with different names.
>* Limited number of kernel versions supported.
>
>[CONFLICTS]
>Both the kernel headers and the target/linux/Makefile.in
>work with $(BUILD_DIR) and it only works when the kernel
>and headers are the same. The shared targets cause all
>kinds of problems. We need to separate the two makes.
>
>I think that the kernel-new-headers should actually
>be moved to the target/linux/Makefile.in to avoid
>the current confusion.

I think that kernel-headers-old should be wiped.
>
>Generating the kernel headers is part of the toolchain build
>and it makes much more sense to me to generate the headers
>in the $(TOOLCHAIN_BUILD_DIR) like it is done for the 2.4 kernels

kernel headers are installed to toolchain_build_$arch/linux/ for a
matter of fact (for src==headers).
Is this FUD or does TOOLCHAIN_BUILD_DIR point to somewhere else? If the
latter, (which would be very cunfusing) then why doesn't
TOOLCHAIN_BUILD_DIR point to the toolchain_build dir? 

>I have tested building the kernel-headers in this directory
>while building the kernel in the $(PROJECT_BUILD_DIR)
>and this seems to work without any problems for x86 and ARM,
>regardless if the kernel version and kernel headers are the same
>or not.
>
>[PATCH NAMING]
>If you want to support a specific $(LINUX_VERSION),
>the "linux-$(LINUX_VERSION)*.patch" files are applied.
>
>When you check the kernel-header patches, it shows that there are
>several patches with identical contents but different names.
>
>This means that you cannot select kernel version at random.

This conclusion is wrong.
This really means that the patch works for several versions of the
kernel, which is a good thing.

>You HAVE to select a supported version 
>(2.6.x where x is {8, 9, 11, 12, 20.4, 21.5, 22.1}).

This is not correct either.
a) you can only select versions which are in the Config system, yes.
b) if you choose to use another kernel then this kernel is *not* patched
with random patches (this is a feature. Patching can fail).
>
>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.)
>
>[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.

>It probably does not make sense to 
>
>If we select a kernel, we may still want to keep the toolchain
>even if we bump the version of the kernel to the next minor number.

You may, sure. There's that external-toolchain thing for *** like this.
>
>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.
>
>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.

>
>It it therefore better to have a list of broken out patches that can be
>applied, than full patchsets for each kernel version.

You're aware that at least "my" patches _are_ broken out (as opposed to
the ATMEL stuff.

>Result is more flexibility and no need to have duplicated patches
>in the patch directory.
>
>[ARCHITECTURE/BOARD SPECIFIC PATCHES]
>On top of the kernel header patches, we should be able to 
>add the board specific patches.

heh. There we agree for once ;)

>
>We know that you normally cannot apply the std AT91 patches and the
>AVR32 patches at the same time, so you cannot just copy these to the

yea, which usually means that there is something really, really broken
with patches like these, but that may be just my notion of how a
configurable software-package should work.

>kernel-headers directory. I assume that there are similar
>problems with patches for different ARM processors etc.
>
>The current method. using $(BR2_BOARD_PATH)/kernel-patches on
>top of the kernel-headers would work for me.
>
>[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.

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.

>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).

>If this proposal is implemented, then each user can select kernel
>version at random, and can actually very easy compile multiple kernels
>in the tree, by just generating a new project.
>You do not have to recompile all the applications to introduce
>a new kernel.
>
>
>> 
>> AFAICT this is redundant, what is the need to put the same patches in a
>> board specific folder? Should the target/linux/Makefile.in first do the
>> patches in toolchain/kernel-headers and then
>> $(BR2_BOARD_PATH)/kernel-patches if it exists?

[Buildroot] Redundant kernel patches in the snapshot from20070718

[Ulf Samuelsson]

> 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.
Then the linux source is decompressed to "build_<arch>/linux-2.6.21.3"
while the headers are generated from    "build_<arch>/linux-2.6.21.5"

"package/linux/Makefile.in" does *not* apply the linux-headers patches
so "build_<arch>/linux-2.6.21.3" does not have the kernel-header patches applied.

If you use the same kernel version as the kernel headers (2.6.21.5), then 
the kernel headers will decompress the source into
"build_<arch>/linux-2.6.21.5" and when "package/linux/Makefile.in"
is activated, it will work on the the "build_<arch>/linux-2.6.21.5" 
directory and thus will have the kernel patches applied.

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.

Once it does so, then you should be able to build the linux in any directory.
Building in "project_build_<arch>" is thus but a symptom.

>>* 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.
The linux support is developed by two teams.

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.
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.


>>* Multiple instances of the same patch with different names.
>>* Limited number of kernel versions supported.
>>
>>[CONFLICTS]
>>Both the kernel headers and the target/linux/Makefile.in
>>work with $(BUILD_DIR) and it only works when the kernel
>>and headers are the same. The shared targets cause all
>>kinds of problems. We need to separate the two makes.
>>
>>I think that the kernel-new-headers should actually
>>be moved to the target/linux/Makefile.in to avoid
>>the current confusion.
> 
> I think that kernel-headers-old should be wiped.

I have no problem with that.

>>
>>Generating the kernel headers is part of the toolchain build
>>and it makes much more sense to me to generate the headers
>>in the $(TOOLCHAIN_BUILD_DIR) like it is done for the 2.4 kernels
> 
> kernel headers are installed to toolchain_build_$arch/linux/ for a
> matter of fact (for src==headers).
> Is this FUD or does TOOLCHAIN_BUILD_DIR point to somewhere else? If the
> latter, (which would be very cunfusing) then why doesn't
> TOOLCHAIN_BUILD_DIR point to the toolchain_build dir? 

OK, wrong working.
Today the source is unpacked in "build_<arch>".
It makes more sense to be to unpack in "toolchain_build_<arch>"
since the kernel headers is really part of the toolchain.

linux then needs to be unpacked in "project_build_dir"

> 
>>I have tested building the kernel-headers in this directory
>>while building the kernel in the $(PROJECT_BUILD_DIR)
>>and this seems to work without any problems for x86 and ARM,
>>regardless if the kernel version and kernel headers are the same
>>or not.
>>
>>[PATCH NAMING]
>>If you want to support a specific $(LINUX_VERSION),
>>the "linux-$(LINUX_VERSION)*.patch" files are applied.
>>
>>When you check the kernel-header patches, it shows that there are
>>several patches with identical contents but different names.
>>
>>This means that you cannot select kernel version at random.
> 
> This conclusion is wrong.
> This really means that the patch works for several versions of the
> kernel, which is a good thing.
> 
>>You HAVE to select a supported version 
>>(2.6.x where x is {8, 9, 11, 12, 20.4, 21.5, 22.1}).
> 
> This is not correct either.
> a) you can only select versions which are in the Config system, yes.
> b) if you choose to use another kernel then this kernel is *not* patched
> with random patches (this is a feature. Patching can fail).
>>
>>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.

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.

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.

You can also conceive that a user has several projects
where the main differences is the version of the linux kernel,
while the toolchain and the rootfs share the build.

>>It probably does not make sense to 
>>
>>If we select a kernel, we may still want to keep the toolchain
>>even if we bump the version of the kernel to the next minor number.
> 
> You may, sure. There's that external-toolchain thing for *** like this.

With the BSP patch it is much less need to do so.

>>
>>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

>>
>>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.

If patching a kernel with the restricted set of kernel patches fails,
then the user always have the option to patch the kernel without those patches.
There are people which has been able to build linux outside buildroot.

>>
>>It it therefore better to have a list of broken out patches that can be
>>applied, than full patchsets for each kernel version.
> 
> You're aware that at least "my" patches _are_ broken out (as opposed to
> the ATMEL stuff.
> 
>>Result is more flexibility and no need to have duplicated patches
>>in the patch directory.
>>
>>[ARCHITECTURE/BOARD SPECIFIC PATCHES]
>>On top of the kernel header patches, we should be able to 
>>add the board specific patches.
> 
> heh. There we agree for once ;)
> 
>>
>>We know that you normally cannot apply the std AT91 patches and the
>>AVR32 patches at the same time, so you cannot just copy these to the
> 
> yea, which usually means that there is something really, really broken
> with patches like these, but that may be just my notion of how a
> configurable software-package should work.
> 

No, the main reason why it fails, is that both patchsets contain identical patches
so the patches are applied twice.

>>kernel-headers directory. I assume that there are similar
>>problems with patches for different ARM processors etc.
>>
>>The current method. using $(BR2_BOARD_PATH)/kernel-patches on
>>top of the kernel-headers would work for me.
>>
>>[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?
I think you *have* to have one source tree per kernel.
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 more and  more belive in merging the kernel header stuff with the main build of linux.

>>If this proposal is implemented, then each user can select kernel
>>version at random, and can actually very easy compile multiple kernels
>>in the tree, by just generating a new project.
>>You do not have to recompile all the applications to introduce
>>a new kernel.
>>
>>
>>> 
>>> AFAICT this is redundant, what is the need to put the same patches in a
>>> board specific folder? Should the target/linux/Makefile.in first do the
>>> patches in toolchain/kernel-headers and then
>>> $(BR2_BOARD_PATH)/kernel-patches if it exists?
>


Best Regards
Ulf Samuelsson

[Buildroot] Redundant kernel patches in the snapshot from20070718

[Bernhard Fischer]

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

[Buildroot] Redundant kernel patches in the snapshot from20070718

[Bernhard Fischer]

On Mon, Jul 30, 2007 at 09:27:28PM +0200, Bernhard Fischer wrote:
[I deliberately do not correct the gazillions of typos i made]

>>>>* 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

... where this patch adds _just_ the device. Accompanying
infrastructure which may be used by a friend class of HW of course has
to be in a separate patch. This obviously prevents attempts to apply any
hunk twice, fwiw.

[Buildroot] Redundant kernel patches in the snapshot from20070718

[Ulf Samuelsson]

m?n 2007-07-30 klockan 22:02 +0200 skrev Bernhard Fischer:
> On Mon, Jul 30, 2007 at 09:27:28PM +0200, Bernhard Fischer wrote:
> [I deliberately do not correct the gazillions of typos i made]
> 
> >>>>* 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
> 
> ... where this patch adds _just_ the device. Accompanying
> infrastructure which may be used by a friend class of HW of course has
> to be in a separate patch. This obviously prevents attempts to apply any
> hunk twice, fwiw.

You make the assumption that two different groups
supplying patches actually tests their patches
against the patches for the other group.
Please don't.
Eadch group assumes that their patches are patched
on top of the kernel-patches.
It is the person trying to apply both patchsets 
in the same tree that is causing the error.
Buildroot of today encourages people to apply
patches on top of each other.
If you first build one target and then build another
target in the same tree, then the error occurs...

Your counter argument is that you should use a new tree,
but that is not desirable, so pls use other arguments.

Best Regards
Ulf Samuelsson.

[Buildroot] Redundant kernel patches in the snapshot from20070718

[Bernhard Fischer]

On Tue, Jul 31, 2007 at 01:59:14AM +0200, Ulf Samuelsson wrote:

Can we settle on the following procedure:

You provide a full patch that does the final migration to unpack and
patch a kernel for each project, install it's headers into the project
specific dir (from within target/linux/Makefile.in, if you prefer).
I'd like to review (and eventually discuss) this patch before it is
finally committed.

Whether you rm toolchain/kernel-headers or not (and how you deal with
kernel-headers-old vs. kernel-header-new) is up to you. I just want to
do this migration in one (tested) step.

Most of the needed steps do already exist, it's merely a matter of
unpacking the kernel in the project specific dir and decide how to
handle patches, i.e. whether to only apply exact patches or try to apply
them if they _could_ do the right thing.

Ok?

[Buildroot] Redundant kernel patches in the snapshotfrom20070718

[Ulf Samuelsson]

> On Tue, Jul 31, 2007 at 01:59:14AM +0200, Ulf Samuelsson wrote:
> 
> Can we settle on the following procedure:
> 
> You provide a full patch that does the final migration to unpack and
> patch a kernel for each project, install it's headers into the project
> specific dir (from within target/linux/Makefile.in, if you prefer).
> I'd like to review (and eventually discuss) this patch before it is
> finally committed.

Sounds OK with me, but I still need to do the stuff in a separate directory
from target/linux initially, because if I do it inside that directory,
then there is a high probability that I run into conflicts with other
patches during the work.
It is going to take some time obviously.

> Whether you rm toolchain/kernel-headers or not (and how you deal with
> kernel-headers-old vs. kernel-header-new) is up to you. I just want to
> do this migration in one (tested) step.
> 
I think that kernel-headers need to remain for pre 2.6.19 kernels.
Noticed that nios2 support will break without that.
For later kernels, it is better to do it in target/linux/

> Most of the needed steps do already exist, it's merely a matter of
> unpacking the kernel in the project specific dir and decide how to
> handle patches, i.e. whether to only apply exact patches or try to apply
> them if they _could_ do the right thing.
> 
> Ok?

Yes

Best Regards
Ulf Samuelsson

[Buildroot] Redundant kernel patches in the snapshot from20070718

[Ulf Samuelsson]

m?n 2007-07-30 klockan 21:27 +0200 skrev Bernhard Fischer:
> 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 ;)

You asked for an example ...

> 
> >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.

You are making the wrong interpretations of my text (see below)

> 
> 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 :)

Yes it is:
Assume company X licenses a peripheral from company Z.
Assume company Y licenses the same peripheral from company Z.
A bug is found in the driver, and both company X and Y create 
a patch to workaround that patch.
Both patches are valid but affect the same part of the linux source
code.
It will not be possible to apply both.

I provide you examples.
You should not assume that the single example i give is 
the only possible example.

When I give you 2.6.21.3 + 2.6.21.5, you assume that I mean
an earlier version of the kernel.
You should assume that I mean a *different* version of the kernel.
There are plenty of good reasons why you would want to try
a different version of the kernel without having to rebuild buildroot.
I am sure that you can figure that out for yourself.


> >
> >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).

We are talking system-on-a-chip here. Not external peripherals.
As I said, you have two different groups (albeit in the same company)
which provides full patchsets for their own chips.

Earlier linux kernels did not contain the common atmel spi driver.
drivers/spi/atmel_spi.c
drivers/spi/atmel_spi.h

When this was released, it became part of 

> 
> >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.
> 

It is flawed to try to patch a single kernel source tree with 
both patches, and that is why one linux source tree per group of patches
is neccessary if you want to build support for several chips of the same
architecture within a single buildroot source tree.

Thus "build_<arch>" is the wrong place to put the linux kernel.
It should reside in "project_build_<arch>".


> []
> >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.

So how do you then build two different kernel versions in one buildroot
tree? - You can't!

> 
> >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.

No but I can see people using linux-2.6.23-rc1 with linux-2.6.22.1
headers.


> I'd call using headers from linux-in-20-years but a kernel from 2004 a
> toy application.
> >

You defined this as how the customer would use it, I didn't.
The normal customer would today want to use linux-2.6.22.1 headers
and in 20 years he would STILL like to use linux-2.6.22.1 headers
but he will not be able to do that, because you only would like to
maintain support for a few kernel headers version.
Maybe during that time, he has decided to use linux-2.6.22.2 
due to some bug fixes, but there is no support for linux-2.6.22.2
with the current buildroot.


> >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.

Not within the current buildroot.
Outside buildroot, you can of course do anything you want.
> 
> >>>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.

You can add a one line patch for an AT91 which is in conflict
with a one line patch for an XScale.
They are not broken just because they are in conflict.
The breaking occurs when you apply two patches which never
were meant to be applied on top of each other.


> >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.
> 

As I said, we should have two ways of building the linux.
The current way, and the proposed way, so that anyone
can continue without problems using the old way
and the new way can be checked out by the community.

> >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

Best Regards
Ulf Samuelsson

[Buildroot] Redundant kernel patches in the snapshot from 20070718

[Bernhard Fischer]

On Thu, Jul 26, 2007 at 04:23:18PM +0200, Hans-Christian Egtvedt wrote:
>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.
>
>AFAICT this is redundant, what is the need to put the same patches in a
>board specific folder? Should the target/linux/Makefile.in first do the
>patches in toolchain/kernel-headers and then
>$(BR2_BOARD_PATH)/kernel-patches if it exists?

yes.
as a general rant, such board-specific patches tend do break other
configurations more often than not (in my experience).

I added it for cases like a special device-driver which is not worth
downloading when building for a different arch.

HTH,