linux: Add CIP SLTS easy selection option

This patch adds an easy way to select the CIP project SLTS kernel within the kernel menu.

Signed-off-by Angelo Compagnucci <[email protected]>

Hello,

Quoted 4 lines · Angelo Compagnucci

This patch adds an easy way to select the CIP project SLTS kernel within the kernel menu.

Signed-off-by Angelo Compagnucci <[email protected]>

I personally don't think we should have explicit support for kernels other than the vanilla Linux kernel. Our kernel options already allow to select any arbitrary tarball or Git repository, which makes it possible to use this linux-cip Git repository as your kernel source if you like it.

Supporting explicitly additional kernel trees is a never-ending story. Everyone will want its own kernel tree listed in Buildroot.

And this linux-cip thing is in fact probably a lot less popular than other non-vanilla kernel trees (like the one for RaspberryPi, for BeagleoBone, the PREEMPT_RT tree, etc.).

So I apologize, but I'm personally not in favor of this patch.

Best regards,

Thomas

In addition, I have yet to meet an actual embedded system product that uses an
unpatched kernel. In practice, the CIP kernel is going to be the _base_ of a product, and not used directly.

That said, it would be useful to add a defconfig that makes use of that kernel.

Hello,

On Fri, 3 Mar 2017 23:50:54 +0100, Arnout Vandecappelle wrote:

Quoted 5 lines

In addition, I have yet to meet an actual embedded system product that uses an
unpatched kernel. In practice, the CIP kernel is going to be the _base_ of a product, and not used directly.

That said, it would be useful to add a defconfig that makes use of that kernel.

I don't really see how that would be useful. What would it bring exactly?

Quoted 2 lines

I don't really see how that would be useful. What would it bring exactly?

Advertising that this repository exists and show how it can be used with
Buildroot. The latter part is of course trivial for us but still useful for newcomers I think.

Hello,

Quoted 3 lines · Arnout Vandecappelle

Quoted 2 lines

I don't really see how that would be useful. What would it bring exactly?

Quoted 3 lines

Advertising that this repository exists and show how it can be used with
Buildroot. The latter part is of course trivial for us but still useful for newcomers I think.

But is this repository any more useful than hundreds of other vendor kernel trees? Why would this one have a defconfig, while it's not tied to handling a particular HW platform?

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Dear Thomas Petazzoni, Arnout Vandecappelle

2017-03-04 11:11 GMT+01:00 Thomas Petazzoni
<[email protected]>:

Quoted 7 lines

Hello,

Quoted 3 lines · Arnout Vandecappelle

Quoted 2 lines

I don't really see how that would be useful. What would it bring exactly?

Quoted 7 lines

Quoted 3 lines

Advertising that this repository exists and show how it can be used with
Buildroot. The latter part is of course trivial for us but still useful for newcomers I think.

But is this repository any more useful than hundreds of other vendor kernel trees? Why would this one have a defconfig, while it's not tied to handling a particular HW platform?

Probably there's some missing informations here ...

From the CIP website:

"Development will begin shortly on SLTS kernel version 4.4. Until the announcement of the next version of the SLTS kernel, which the CIP community anticipates will happen in two to three years, feature backports from the upstream Linux kernel may be merged with the CIP kernel. The CIP community plans to maintain 4.4 for security and bug fixes for more than 10 years."

So, it's a vanilla kernel? Yes
It's security patched? Yes
It's a join effort project from the Linux Foundation and other big players? Yes [1]
It's tied to a special development platform or board? No, it's a vanilla kernel after all.

So in the end I think this kernel should have a mention in buildroot.

Buildroot users are usually corporations that want to build software for their products.
If I were a corp right now, I will base my Linux product on an SLTS kernel, because it assures me that I don't have to rewrite all my kernel code for at least 10 years and the testing I do isn't trashed every time a new kernel revision is out [2].

Ironically, we could base most of our configs (the ones that use a vanilla kernel) on CIP SLTS kernel and never think again to kernel bumps for another 10 years!

I think that we should support this vanilla super long term support kernel for the benefits of our users. Choosing the right kernel for a product is a tough decision and knowing that there is a kernel I can trust for 10 years is surely something to not underestimate.

Quoted 46 lines

Dear Thomas Petazzoni, Arnout Vandecappelle

2017-03-04 11:11 GMT+01:00 Thomas Petazzoni
<[email protected]>:

Quoted 7 lines

Hello,

Quoted 3 lines · Arnout Vandecappelle

Quoted 2 lines

I don't really see how that would be useful. What would it bring exactly?

Quoted 7 lines

Quoted 3 lines

Advertising that this repository exists and show how it can be used with
Buildroot. The latter part is of course trivial for us but still useful for newcomers I think.

But is this repository any more useful than hundreds of other vendor kernel trees? Why would this one have a defconfig, while it's not tied to handling a particular HW platform?

Probably there's some missing informations here ...

From the CIP website:

"Development will begin shortly on SLTS kernel version 4.4. Until the announcement of the next version of the SLTS kernel, which the CIP community anticipates will happen in two to three years, feature backports from the upstream Linux kernel may be merged with the CIP kernel. The CIP community plans to maintain 4.4 for security and bug fixes for more than 10 years."

So, it's a vanilla kernel? Yes
It's security patched? Yes
It's a join effort project from the Linux Foundation and other big players? Yes [1]
It's tied to a special development platform or board? No, it's a vanilla kernel after all.

So in the end I think this kernel should have a mention in buildroot.

Buildroot users are usually corporations that want to build software for their products.
If I were a corp right now, I will base my Linux product on an SLTS kernel, because it assures me that I don't have to rewrite all my kernel code for at least 10 years and the testing I do isn't trashed every time a new kernel revision is out [2].

Quoted 3 lines

Ironically, we could base most of our configs (the ones that use a vanilla kernel) on CIP SLTS kernel and never think again to kernel bumps for another 10 years!

Well, we still would have to bump the kernel of course. If the code doesn't
change, there is no point to use that repository over any other!

Quoted 4 lines

I think that we should support this vanilla super long term support kernel for the benefits of our users. Choosing the right kernel for a product is a tough decision and knowing that there is a kernel I can trust for 10 years is surely something to not underestimate.

And this is indeed what I meant: this project is useful for our users, so it
would be nice if we advertised it somehow.

Actually, looking back to the original patch, I'm kind of warming up to it.

We
currently have a version selection for all maintained stable versions for linux-headers, but not for linux itself - why not? Probably because it is too much work to maintain that and most people will anyway not use an upstream kernel directly in their product. But with the SLTS kernel there is in fact a higher chance that you can use it directly in your product.

Note that the original patch did have a few issues:
- It should use a tag/sha rather than a branch;

- It should use a tarball from https://gitlab.com/cip-project/cip-kernel-4.4
rather than a git clone.

- Configuration of BR2_CIP_KERNEL_REPO_URL is pointless, since anything else is wrong.

Regards,
Arnout

--

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Quoted 2 lines

Note that the original patch did have a few issues:
- It should use a tag/sha rather than a branch;

Using a tag/sha will defeat the purpose of using this kernel. A developer should ever use the latest release of this kernel each time he compiles a buildroot image.

Hello,

Quoted 3 lines · Angelo Compagnucci

Quoted 2 lines

Note that the original patch did have a few issues:
- It should use a tag/sha rather than a branch;

Quoted 3 lines

Using a tag/sha will defeat the purpose of using this kernel. A developer should ever use the latest release of this kernel each time he compiles a buildroot image.

Clearly *NOT*. We want Buildroot builds to be reproducible. So if you take a given Buildroot version and configuration, it should *always* provide exactly the same output. So we need to use fixed versions of all the components.

Doing otherwise would be absolutely horrible. You do a build one day, it works. The next day, your colleague takes your Buildroot version and configuration, does a build, and the build fails? Or the build works, but it no longer boots/works on the target?

So no, we clearly do not want this to use the "latest release each time a Buildroot image is compiled".

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Quoted 4 lines

Clearly *NOT*. We want Buildroot builds to be reproducible. So if you take a given Buildroot version and configuration, it should *always* provide exactly the same output. So we need to use fixed versions of all the components.

Obviously, I know. We could exclude the CIP kernel from the reproducibility thing.

This should not happens, or if this happens, there's fault in the CIP project. Btw the project doesn't involves only a Linux kernel but all the necessary infrastructure to be sure that a new minor release doesn't brake everything.

Hello,

Quoted 7 lines · Angelo Compagnucci

Quoted 4 lines

Clearly *NOT*. We want Buildroot builds to be reproducible. So if you take a given Buildroot version and configuration, it should *always* provide exactly the same output. So we need to use fixed versions of all the components.

Obviously, I know. We could exclude the CIP kernel from the reproducibility thing.

There is nothing like "excluding feature <foo>" from the reproducibility thing.

Quoted 4 lines

This should not happens, or if this happens, there's fault in the CIP project. Btw the project doesn't involves only a Linux kernel but all the necessary infrastructure to be sure that a new minor release doesn't brake everything.

Right, but that's not the point. The point is that a given Buildroot version+configuration should always build the same thing, period. That's a very strong principle in Buildroot.

If you want to upgrade your kernel to a newer version, you change your configuration.

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com