Main Linux kernel vs Ubuntu kernel

[Subhashini Rao Beerisetty]

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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180609/d20c1566/attachment.html>