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.