[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Vivien Didelot]

When using a custom kernel (custom tarball, repository or local tree),
we're using the OVERRIDE_SRCDIR internally, which means we do not apply
patches. Since this is the expected behavior, show the
LINUX_KERNEL_PATCH option only when using a vanilla kernel.

Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
---
 linux/Config.in | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/linux/Config.in b/linux/Config.in
index bf30426..9989b40 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -119,6 +119,9 @@ config BR2_LINUX_KERNEL_VERSION
 
 config BR2_LINUX_KERNEL_PATCH
 	string "Custom kernel patches"
+	depends on BR2_LINUX_KERNEL_LATEST_VERSION || \
+		  BR2_LINUX_KERNEL_SAME_AS_HEADERS || \
+		  BR2_LINUX_KERNEL_CUSTOM_VERSION
 	help
 	  A space-separated list of patches to apply to the
 	  kernel. Each patch can be described as an URL, a local file
-- 
2.2.1

[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Yann E. MORIN]

Vivien, All,

On 2015-01-06 17:25 -0500, Vivien Didelot spake thusly:
> When using a custom kernel (custom tarball, repository or local tree),
> we're using the OVERRIDE_SRCDIR internally, which means we do not apply
> patches. Since this is the expected behavior, show the
> LINUX_KERNEL_PATCH option only when using a vanilla kernel.
> 
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  linux/Config.in | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/linux/Config.in b/linux/Config.in
> index bf30426..9989b40 100644
> --- a/linux/Config.in
> +++ b/linux/Config.in
> @@ -119,6 +119,9 @@ config BR2_LINUX_KERNEL_VERSION
>  
>  config BR2_LINUX_KERNEL_PATCH
>  	string "Custom kernel patches"
> +	depends on BR2_LINUX_KERNEL_LATEST_VERSION || \
> +		  BR2_LINUX_KERNEL_SAME_AS_HEADERS || \
> +		  BR2_LINUX_KERNEL_CUSTOM_VERSION
>  	help
>  	  A space-separated list of patches to apply to the
>  	  kernel. Each patch can be described as an URL, a local file
> -- 
> 2.2.1
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Danomi Manchego]

Vivien,

On Tue, Jan 6, 2015 at 5:25 PM, Vivien Didelot
<vivien.didelot@savoirfairelinux.com> wrote:
> When using a custom kernel (custom tarball, repository or local tree),
> we're using the OVERRIDE_SRCDIR internally, which means we do not apply
> patches. Since this is the expected behavior, show the
> LINUX_KERNEL_PATCH option only when using a vanilla kernel.

Forgive me if I'm missing something obvious, but - when I look at
linux.mk, I see the LINUX_SITE_METHOD set to "local" only when
BR2_LINUX_KERNEL_CUSTOM_LOCAL is set.  Aren't the custom git and
custom hg selections setting the method to "git" and "hg"
respectively?  Patches can't be applied to the results of a tarball
gotten from somewhere other than kernel.org?

Danomi -

[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Yann E. MORIN]

Danomi, All,

On 2015-01-06 20:43 -0500, Danomi Manchego spake thusly:
> On Tue, Jan 6, 2015 at 5:25 PM, Vivien Didelot
> <vivien.didelot@savoirfairelinux.com> wrote:
> > When using a custom kernel (custom tarball, repository or local tree),
> > we're using the OVERRIDE_SRCDIR internally, which means we do not apply
> > patches. Since this is the expected behavior, show the
> > LINUX_KERNEL_PATCH option only when using a vanilla kernel.
> 
> Forgive me if I'm missing something obvious, but - when I look at
> linux.mk, I see the LINUX_SITE_METHOD set to "local" only when
> BR2_LINUX_KERNEL_CUSTOM_LOCAL is set.  Aren't the custom git and
> custom hg selections setting the method to "git" and "hg"
> respectively?  Patches can't be applied to the results of a tarball
> gotten from somewhere other than kernel.org?

Well, using a patch to a custom kernel does not really make sense.

I'll try to summraise the discussion we had with Vivien on IRC
yesterday, which ended up with this patch (sorry, it is a bit long..)

See, using a local tree or a custom git or mercurial tree, is really a
case of telling Buildroot: "look, I have my custom kernel, which has my
very customisation with what I need".

The key word here is "custom": you went to great length for having such
a kernel in the first place, so further customising with another patch
is not really meaningfull; you could just as well add that patch to your
custom linux kernel to start with.

So, that's the reasoning behind this patch: cutom tree? Apply any
supplemental patch to that custom tree, and be done with it.

Now, the issue Vivien encountered is that pointing Buildroot to a local
linux tree *and* an additional patch was not working: the patch was not
applied.

The technical reason is that, when using a local linux tree, we
internally use the same mechanism as is used for _OVERRIDE_SRCDIR.
_OVERRIDE_SRCDIR is meant for people hacking on their package (linux or
any other) and hijack Buildroot to use that instead of downloading the
package from upstream. This is to be used during the development of said
package, to avoid having to manually patch the package in output/build/
and loose all on a 'make clean'; that way, the sources you're working on
are outdside Buildroot.

Now, because this is to be used during development, we consider the user
has all the code he actually wants to be used in that _OVERRIDE_SRCDIR
tree, patches already applied if needed. Furthermore, when the user is
working on a modified version of the package, there is zero guarantee
our bundled patches would still apply; chances are even that they will
no longer.

Then the local linux tree is just a shortcut in the menuconfig for
telling Buildroot to look for an _OVERRIDE_SRCDIR, instead of having to
provide a local.mk that defines that very _OVERRIDE_SRCDIR. It is just a
courtesy to the user (and IMHO we should just completely get rid of it,
as we can not guarantee reproducible builds from such a .config file).

For all these reasons, using a cutom kernel tree (local or git or Hg) is
just not compatible with applying patches.

Hence Vivien's patch, and me hacking it.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Danomi Manchego]

Yann,

On Wed, Jan 7, 2015 at 1:35 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Danomi, All,
>
> On 2015-01-06 20:43 -0500, Danomi Manchego spake thusly:
>> On Tue, Jan 6, 2015 at 5:25 PM, Vivien Didelot
>> <vivien.didelot@savoirfairelinux.com> wrote:
>> > When using a custom kernel (custom tarball, repository or local tree),
>> > we're using the OVERRIDE_SRCDIR internally, which means we do not apply
>> > patches. Since this is the expected behavior, show the
>> > LINUX_KERNEL_PATCH option only when using a vanilla kernel.
>>
>> Forgive me if I'm missing something obvious, but - when I look at
>> linux.mk, I see the LINUX_SITE_METHOD set to "local" only when
>> BR2_LINUX_KERNEL_CUSTOM_LOCAL is set.  Aren't the custom git and
>> custom hg selections setting the method to "git" and "hg"
>> respectively?  Patches can't be applied to the results of a tarball
>> gotten from somewhere other than kernel.org?
>
> Well, using a patch to a custom kernel does not really make sense.
>
> I'll try to summraise the discussion we had with Vivien on IRC
> yesterday, which ended up with this patch (sorry, it is a bit long..)
>
> See, using a local tree or a custom git or mercurial tree, is really a
> case of telling Buildroot: "look, I have my custom kernel, which has my
> very customisation with what I need".

I certainly understand that to be the case for the local tree (which,
again, I _think_ is the only one engaging the _OVERRIDE_SRCDIR
mechanism).  But you don't think that there would be valid cases of
acquiring a kernel via git that is not customized to the project?  For
example, at work, we use a TI part, which keeps its 2.6.37+ kernel at
arago-project.org.  So I get it by setting
BR2_LINUX_KERNEL_CUSTOM_REPO_URL to
"git://arago-project.org/git/projects/linux-omap3.git", and then apply
my project's patches to it.  Sure - I guess it _a_ custom kernel in
that its modified by TI, but it does not have all the mods _I_ need
for my specific project.  Not a valid use case?

Danomi -


> The key word here is "custom": you went to great length for having such
> a kernel in the first place, so further customising with another patch
> is not really meaningfull; you could just as well add that patch to your
> custom linux kernel to start with.
>
> So, that's the reasoning behind this patch: cutom tree? Apply any
> supplemental patch to that custom tree, and be done with it.
>
> Now, the issue Vivien encountered is that pointing Buildroot to a local
> linux tree *and* an additional patch was not working: the patch was not
> applied.
>
> The technical reason is that, when using a local linux tree, we
> internally use the same mechanism as is used for _OVERRIDE_SRCDIR.
> _OVERRIDE_SRCDIR is meant for people hacking on their package (linux or
> any other) and hijack Buildroot to use that instead of downloading the
> package from upstream. This is to be used during the development of said
> package, to avoid having to manually patch the package in output/build/
> and loose all on a 'make clean'; that way, the sources you're working on
> are outdside Buildroot.
>
> Now, because this is to be used during development, we consider the user
> has all the code he actually wants to be used in that _OVERRIDE_SRCDIR
> tree, patches already applied if needed. Furthermore, when the user is
> working on a modified version of the package, there is zero guarantee
> our bundled patches would still apply; chances are even that they will
> no longer.
>
> Then the local linux tree is just a shortcut in the menuconfig for
> telling Buildroot to look for an _OVERRIDE_SRCDIR, instead of having to
> provide a local.mk that defines that very _OVERRIDE_SRCDIR. It is just a
> courtesy to the user (and IMHO we should just completely get rid of it,
> as we can not guarantee reproducible builds from such a .config file).
>
> For all these reasons, using a cutom kernel tree (local or git or Hg) is
> just not compatible with applying patches.
>
> Hence Vivien's patch, and me hacking it.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Ryan Barnett]

Danomi and Yann,

On Wed, Jan 7, 2015 at 12:53 PM, Danomi Manchego
<danomimanchego123@gmail.com> wrote:
> Yann,
>
> On Wed, Jan 7, 2015 at 1:35 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> Danomi, All,
>>
>> Well, using a patch to a custom kernel does not really make sense.
>>
>> I'll try to summraise the discussion we had with Vivien on IRC
>> yesterday, which ended up with this patch (sorry, it is a bit long..)
>>
>> See, using a local tree or a custom git or mercurial tree, is really a
>> case of telling Buildroot: "look, I have my custom kernel, which has my
>> very customisation with what I need".
>
> I certainly understand that to be the case for the local tree (which,
> again, I _think_ is the only one engaging the _OVERRIDE_SRCDIR
> mechanism).  But you don't think that there would be valid cases of
> acquiring a kernel via git that is not customized to the project?  For
> example, at work, we use a TI part, which keeps its 2.6.37+ kernel at
> arago-project.org.  So I get it by setting
> BR2_LINUX_KERNEL_CUSTOM_REPO_URL to
> "git://arago-project.org/git/projects/linux-omap3.git", and then apply
> my project's patches to it.  Sure - I guess it _a_ custom kernel in
> that its modified by TI, but it does not have all the mods _I_ need
> for my specific project.  Not a valid use case?

This should be a valid use case since I do something similar using the
Freescale's custom git repo that supports the QorIQ series of
processors. We carry a few minor patches that are on top of this git
repository that implement a few customization we need in the kernel.
It didn't really make much sense to maintain our own custom repository
since the changes done are very minimal.

I think there is a needs to be ablity to take a custom GIT repo that
comes from somewhere on the other than official mainline kernels as
there maybe features available in these kernels that haven't made it
into the mainline kernel. Other examples that I can think of would be
Xilinx's Zynq and Altera's SoCFPGA architectures in which there isn't
full featured support for these architectures yet in the mainline
kernel but are available from the vendor maintain git repositories.

Moral of the story - I disagree with this change.

Just thought of this - you would still be able to use
BR2_GLOBAL_PATCH_DIRS in order to patch the kernel when using any of
the other methods so I don't know why you wouldn't want to all this
option. I believe, it was discussed some time ago about completely
removing this option and only allow the use of BR2_GLOBAL_PATCH_DIRS.

Thanks,
-Ryan

-- 
Ryan Barnett / Sr Software Engineer
Airborne Information Systems / Security Systems and Software
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
ryan.barnett at rockwellcollins.com
www.rockwellcollins.com

[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Ryan Barnett]

All,

On Wed, Jan 7, 2015 at 4:51 PM, Ryan Barnett
<ryan.barnett@rockwellcollins.com> wrote:
> Danomi and Yann,
>
> On Wed, Jan 7, 2015 at 12:53 PM, Danomi Manchego
> <danomimanchego123@gmail.com> wrote:
>> Yann,
>>
>> On Wed, Jan 7, 2015 at 1:35 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>>> Danomi, All,
>>>
>>> Well, using a patch to a custom kernel does not really make sense.
>>>
>>> I'll try to summraise the discussion we had with Vivien on IRC
>>> yesterday, which ended up with this patch (sorry, it is a bit long..)
>>>
>>> See, using a local tree or a custom git or mercurial tree, is really a
>>> case of telling Buildroot: "look, I have my custom kernel, which has my
>>> very customisation with what I need".
>>
>> I certainly understand that to be the case for the local tree (which,
>> again, I _think_ is the only one engaging the _OVERRIDE_SRCDIR
>> mechanism).  But you don't think that there would be valid cases of
>> acquiring a kernel via git that is not customized to the project?  For
>> example, at work, we use a TI part, which keeps its 2.6.37+ kernel at
>> arago-project.org.  So I get it by setting
>> BR2_LINUX_KERNEL_CUSTOM_REPO_URL to
>> "git://arago-project.org/git/projects/linux-omap3.git", and then apply
>> my project's patches to it.  Sure - I guess it _a_ custom kernel in
>> that its modified by TI, but it does not have all the mods _I_ need
>> for my specific project.  Not a valid use case?
>
> This should be a valid use case since I do something similar using the
> Freescale's custom git repo that supports the QorIQ series of
> processors. We carry a few minor patches that are on top of this git
> repository that implement a few customization we need in the kernel.
> It didn't really make much sense to maintain our own custom repository
> since the changes done are very minimal.
>
> I think there is a needs to be ablity to take a custom GIT repo that
> comes from somewhere on the other than official mainline kernels as
> there maybe features available in these kernels that haven't made it
> into the mainline kernel. Other examples that I can think of would be
> Xilinx's Zynq and Altera's SoCFPGA architectures in which there isn't
> full featured support for these architectures yet in the mainline
> kernel but are available from the vendor maintain git repositories.
>
> Moral of the story - I disagree with this change.
>
> Just thought of this - you would still be able to use
> BR2_GLOBAL_PATCH_DIRS in order to patch the kernel when using any of
> the other methods so I don't know why you wouldn't want to all this
> option. I believe, it was discussed some time ago about completely
> removing this option and only allow the use of BR2_GLOBAL_PATCH_DIRS.

You can ignore this as I agree with the revision of this patch that
was accepted....I missed the newest version of this patch before
sending this email.

-- 
Ryan Barnett / Sr Software Engineer
Airborne Information Systems / Security Systems and Software
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
ryan.barnett at rockwellcollins.com
www.rockwellcollins.com