Message ID | 1488577816-19047-1-git-send-email-angelo.compagnucci@gmail.com |
---|---|
State | Rejected |
Headers | show |
Hello, On Fri, 3 Mar 2017 22:50:16 +0100, Angelo Compagnucci wrote: > This patch adds an easy way to select the CIP project SLTS > kernel within the kernel menu. > > Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> 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
On 03-03-17 23:46, Thomas Petazzoni wrote: > Hello, > > On Fri, 3 Mar 2017 22:50:16 +0100, Angelo Compagnucci wrote: >> This patch adds an easy way to select the CIP project SLTS >> kernel within the kernel menu. >> >> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> > > 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.). 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 guess they must have some kind of flagship board to run on, no? Regards, Arnout > > So I apologize, but I'm personally not in favor of this patch. > > Best regards, > > Thomas >
Hello, On Fri, 3 Mar 2017 23:50:54 +0100, Arnout Vandecappelle wrote: > 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? Thomas
On 04-03-17 00:02, Thomas Petazzoni wrote: > Hello, > > On Fri, 3 Mar 2017 23:50:54 +0100, Arnout Vandecappelle wrote: > >> 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? 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. Regards, Arnout
Hello, On Sat, 4 Mar 2017 00:43:20 +0100, Arnout Vandecappelle wrote: > > 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. 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
Dear Thomas Petazzoni, Arnout Vandecappelle 2017-03-04 11:11 GMT+01:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Hello, > > On Sat, 4 Mar 2017 00:43:20 +0100, Arnout Vandecappelle wrote: > >> > 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. > > 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. Sincerely, Angelo [1] https://www.linuxfoundation.org/news-media/announcements/2016/04/linux-foundation-launches-first-linux-based-civil-infrastructure [2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
On 04-03-17 12:31, Angelo Compagnucci wrote: > Dear Thomas Petazzoni, Arnout Vandecappelle > > 2017-03-04 11:11 GMT+01:00 Thomas Petazzoni > <thomas.petazzoni@free-electrons.com>: >> Hello, >> >> On Sat, 4 Mar 2017 00:43:20 +0100, Arnout Vandecappelle wrote: >> >>>> 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. >> >> 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! 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! > > 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
Dear Arnout Vandecappelle, 2017-03-04 13:17 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>: > > > On 04-03-17 12:31, Angelo Compagnucci wrote: >> Dear Thomas Petazzoni, Arnout Vandecappelle >> >> 2017-03-04 11:11 GMT+01:00 Thomas Petazzoni >> <thomas.petazzoni@free-electrons.com>: >>> Hello, >>> >>> On Sat, 4 Mar 2017 00:43:20 +0100, Arnout Vandecappelle wrote: >>> >>>>> 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. >>> >>> 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! > > 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! Nope, cause we point to a branch rather than a hash or a tag. >> 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. Iuppi! > 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; 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. It's the CIP team behind it that guarantees that the kernel will work as intended. Btw the major version is fixed. > - It should use a tarball from https://gitlab.com/cip-project/cip-kernel-4.4 > rather than a git clone. This is indeed a good idea! > - Configuration of BR2_CIP_KERNEL_REPO_URL is pointless, since anything else is > wrong. And where I should store the tarball url? Sincerely, Angelo. > > > 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
Hello, On Sat, 4 Mar 2017 15:08:06 +0100, Angelo Compagnucci wrote: > > 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. 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
Dear Thomas Petazzoni, 2017-03-04 15:12 GMT+01:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Hello, > > On Sat, 4 Mar 2017 15:08:06 +0100, Angelo Compagnucci wrote: >> > 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. > > 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. > 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? 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. > So no, we clearly do not want this to use the "latest release each time > a Buildroot image is compiled". This is plain wrong with CIP. What an CIP user wants is to have the latest patched version without thinking. It doesn't have any sense to say to a developer "hey, we provide CIP but our setting is useless cause it points to an older unpatched release. If you want to use it, you should manually change to the latest release." Yes, it's thinking in another way, like a super long term support rolling release. Sincerely, Angelo > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
Hello, On Sat, 4 Mar 2017 15:38:13 +0100, Angelo Compagnucci wrote: > > 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. > 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
Dear Thomas Petazzoni , 2017-03-04 15:42 GMT+01:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Hello, > > On Sat, 4 Mar 2017 15:38:13 +0100, Angelo Compagnucci wrote: > >> > 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. > >> 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. If this is an insurmountable thing, than this patch could be discarded. Obviously we can use a tag (there is v4.4.48-cip2 at this moment) but what's the point? We should educate our users about checking manually the latest release cause the one shipped with buildroot could be older and unpatched. It's nonsense. This problem is somewhat related to the standard kernel where we say "Latest version (4.9.13)" (buildroot 2017.02) when indeed the latest version at the time of writing is 4.10.1. Latest should be latest imho. Sincerely, Angelo. > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
diff --git a/Config.in b/Config.in index bd8f0d1..b089ed8 100644 --- a/Config.in +++ b/Config.in @@ -261,6 +261,26 @@ config BR2_KERNEL_MIRROR http://www.XX.kernel.org/pub (XX = country code) http://mirror.aarnet.edu.au/pub/ftp.kernel.org +config BR2_CIP_KERNEL_REPO_URL + string "CIP SLTS (SuperLong Term Support) kernel url" + default "git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git" + help + CIP launched in the spring of 2016 to address the needs of + organizations in industries such as power generation and + distribution, water, oil and gas, transportation, building + automation and more for reliable and secure Linux-based + embedded systems that can be sustained over a period of + 10 to as many as 60 years. + The project's goal is to provide an open source base layer + of industrial-grade software that permits the use and + implementation of software building blocks that meet + these requirements. + + The CIP community plans to maintain 4.4 for security and + bug fixes for more than 10 years. + + https://www.cip-project.org + config BR2_GNU_MIRROR string "GNU Software mirror" default "http://ftpmirror.gnu.org" diff --git a/linux/Config.in b/linux/Config.in index 890b848..478cb18 100644 --- a/linux/Config.in +++ b/linux/Config.in @@ -28,6 +28,9 @@ choice config BR2_LINUX_KERNEL_LATEST_VERSION bool "Latest version (4.10)" +config BR2_LINUX_KERNEL_LATEST_CIP_VERSION + bool "Latest CIP SLTS (Super Long Term Support) version (4.4.y)" + config BR2_LINUX_KERNEL_CUSTOM_VERSION bool "Custom version" help @@ -98,6 +101,7 @@ endif config BR2_LINUX_KERNEL_VERSION string default "4.10" if BR2_LINUX_KERNEL_LATEST_VERSION + default "linux-4.4.y-cip" if BR2_LINUX_KERNEL_LATEST_CIP_VERSION default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE \ if BR2_LINUX_KERNEL_CUSTOM_VERSION default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL diff --git a/linux/linux.mk b/linux/linux.mk index 7f4432e..0dd8ff0 100644 --- a/linux/linux.mk +++ b/linux/linux.mk @@ -30,6 +30,9 @@ LINUX_SITE_METHOD = hg else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_SVN),y) LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL)) LINUX_SITE_METHOD = svn +else ifeq ($(BR2_LINUX_KERNEL_LATEST_CIP_VERSION),y) +LINUX_SITE = $(call qstrip,$(BR2_CIP_KERNEL_REPO_URL)) +LINUX_SITE_METHOD = git else LINUX_SOURCE = linux-$(LINUX_VERSION).tar.xz ifeq ($(BR2_LINUX_KERNEL_CUSTOM_VERSION),y)
This patch adds an easy way to select the CIP project SLTS kernel within the kernel menu. Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> --- Config.in | 20 ++++++++++++++++++++ linux/Config.in | 4 ++++ linux/linux.mk | 3 +++ 3 files changed, 27 insertions(+)