Main Linux kernel vs Ubuntu kernel
Hi All, Apologies for the dull questions, I’m noob, need to learn lot more stuff. We’ve a bunch of hardware & test systems, we started this project by opting ubuntu distro 16.04 LTS v4.4 kernel for development of device drivers, test utilities. I’d like to know, what are the differences between the main Linux kernel and the kernel being used by Ubuntu? If I need to upgrade our drivers to latest kernel v4.17, what are the best possible ways? In future, is it possible for us to use the current installed 16.04 LTS by just upgrading the Linux kernel version? Are all the Linux kernel releases are backward compatible? Even Ubuntu distro has LTS, non-LTS, GA, HWE kernels, what’s the difference between these? Which one should be the best choice for development & validating the hardware? Can someone clarify me on this? Thanks
Hi All,
Hi Subhashini
Apologies for the dull questions, I’m noob, need to learn lot more stuff.
We’ve a bunch of hardware & test systems, we started this project by opting ubuntu distro 16.04 LTS v4.4 kernel for development of device drivers, test utilities.
I’d like to know, what are the differences between the main Linux kernel and the kernel being used by Ubuntu?
Well, mainline kernel is development kernel which keeps changing everyday, and in fact every minute. Just to give you an idea This kernel is tested and a stable kernel is released by Greg, out of this mainline kernel. You can read the complete development process here: https://www.kernel.org/doc/html/v4.17/process/howto.html About releases: https://www.kernel.org/category/releases.html https://www.kernel.org/ About ubuntu kernel: The kernel developers of ubuntu fork or pull mainline kernel and customise it and release their distro kernel. You get it when you update your system. You can read about it here: https://help.ubuntu.com/community/Kernel https://wiki.ubuntu.com/KernelTeam
If I need to upgrade our drivers to latest kernel v4.17, what are the best possible ways? In future, is it possible for us to use the current installed 16.04 LTS by just upgrading the Linux kernel version?
Yes you can build mainline kernel and run in ubuntu 16.04. https://kernelnewbies.org/FirstKernelPatch If you get some issues(rare case) you can report them back to mailing list. The mailing lists are subsystem specific. For example: for networking related issues you can mail to netdev@vger.kernel.org. Find all the lists here: http://vger.kernel.org/vger-lists.html
Are all the Linux kernel releases are backward compatible? yes, except for old and obsolete hardware. They get their way out of kernel tree via staging/ directory in kernel source tree.
Even Ubuntu distro has LTS, non-LTS, GA, HWE kernels, what’s the difference between these? Which one should be the best choice for development & validating the hardware?
They are ubuntu specific. For development mainline kernel is best. You always have option to test your hardware and report issues if any. If mainline breaks for your hardware then you can choose any known stable kernel version. You can patch and test it as per your needs.
Can someone clarify me on this?
Thanks a lot, Shyam
On Sat, 09 Jun 2018 00:57:19 +0530, Shyam Saini said:
You always have option to test your hardware and report issues if any. If mainline breaks for your hardware then you can choose any known stable kernel version. You can patch and test it as per your needs.
If mainline breaks, you should at least make an attempt to either fix your driver, or call for help. If you drop back to a stable kernel and don't get the problem fixed, you're going to be stuck on that stable release (which is the single biggest reason you see so many boxes with wonky hardware that are still stuck on 3.12 or other ancient kernels - they have out-of-tree drivers that nobody ever bothered updating...) And of course, try to get your driver into the mainline kernel upstream. At that point, whenever somebody changes a kernel API, it's *their* job to fix anything in-tree that breaks - including your driver. If you are bothered by that and want some control over it, list yourself as the maintainer so patches get passed to you for putting into upstream.
My question related to backward compatibility is: If an API’s signature changed from kernel version x.y.z onwards, does the mainline tree code uses the below mentioned logic? #if LINUX_VERSION_CODE >= KERNEL_VERSION(x,y,z) #else #endif Regarding long term release kernels, what here ‘long term’ means? For e.g. v4.4 is part of long term release kernel released in 2016-01-10 and it’s projected EOL is Feb, 2022, here what’s the meaning of EOL? How to backport the bug fixes for older kernel tree (for e.g. v4.4) and what is the selection criteria for choosing which bug fixes should go for backporting? Thanks, On Sat, Jun 9, 2018 at 2:37 AM, <valdis.kletnieks@vt.edu> wrote:
On Sat, 09 Jun 2018 00:57:19 +0530, Shyam Saini said:
You always have option to test your hardware and report issues if any. If mainline breaks for your hardware then you can choose any known stable kernel version. You can patch and test it as per your needs.
If mainline breaks, you should at least make an attempt to either fix your driver, or call for help. If you drop back to a stable kernel and don't get the problem fixed, you're going to be stuck on that stable release (which is the single biggest reason you see so many boxes with wonky hardware that are still stuck on 3.12 or other ancient kernels - they have out-of-tree drivers that nobody ever bothered updating...)
And of course, try to get your driver into the mainline kernel upstream. At that point, whenever somebody changes a kernel API, it's *their* job to fix anything in-tree that breaks - including your driver. If you are bothered by that and want some control over it, list yourself as the maintainer so patches get passed to you for putting into upstream.
On Sat, Jun 09, 2018 at 05:17:45PM +0530, Subhashini Rao Beerisetty wrote:
My question related to backward compatibility is: If an API’s signature changed from kernel version x.y.z onwards, does the mainline tree code uses the below mentioned logic?
#if LINUX_VERSION_CODE >= KERNEL_VERSION(x,y,z)
#else
#endif
No, mainline kernel code does not have #ifdefs at all, it is not needed. Remember, all drivers are included in the kernel release at once, so there is no need for such checks as they all work for the kernel they are contained in.
Regarding long term release kernels, what here ‘long term’ means?
Did you read this: https://www.kernel.org/category/releases.html It should explain all of this.
For e.g. v4.4 is part of long term release kernel released in 2016-01-10 and it’s projected EOL is Feb, 2022, here what’s the meaning of EOL?
End Of Life.
How to backport the bug fixes for older kernel tree (for e.g. v4.4) and what is the selection criteria for choosing which bug fixes should go for backporting?
Did you read this: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html Also, please read the kernel development process documentation, it should have answered these questions for you and will cover lots of this type of thing. thanks, greg k-h
On Sat, 09 Jun 2018 17:17:45 +0530, Subhashini Rao Beerisetty said:
My question related to backward compatibility is: If an API’s signature changed from kernel version x.y.z onwards, does the mainline tree code uses the below mentioned logic?
#if LINUX_VERSION_CODE >= KERNEL_VERSION(x,y,z)
No, because whenever an in-kernel API is changed, the person changing it is responsible for fixing all the in-tree uses of the API. You only see the #ifdef above for out-of-tree drivers.
participants (4)
-
Greg KH -
Shyam Saini -
Subhashini Rao Beerisetty -
valdis.kletnieks＠vt.edu