back to article Linux maintainer says long-term support for 5.10 will stay at two years unless biz world steps up and actually uses it

Linux kernel maintainer Greg Kroah-Hartman has responded to complaints that the current promise of two years for 5.10 is not enough, explaining that support is not automatic but requires commercial help. Version 5.10 of the kernel was released in December and designated a "long-term maintenance" release, which generally means …

  1. Blackjack Silver badge

    Please donate

    Linux is a community effort but they could use the money, okay?

    1. Anonymous Coward
      Anonymous Coward

      Re: Please donate

      It's a long time ago since the community provided the majority of code and donations, kid. The BIG corps run the show now. Like IBM, Microsoft and so on.

      1. Alan Brown Silver badge

        Re: Please donate

        And the smaller SoC players like Broadcom or Nvidia, don't provide anything financially to kernel development - and keep dumping badly written blobs they expect to be integrated into the kernel

        Yet, it's Broadcom and Nvidia who are griping about lack of long term support

        At the same time they're telling THEIR customers that if you want long term support, you gotta pay up

        It's no coincidence that Nvidia acquired the most popular Linux-on-Network-Switch distro and that distro promptly dropped support for everything except Nvidia SoCs - it demonstrates what these people don't get about open source or communities

    2. iGNgnorr

      Re: Please donate

      "Linux is a community effort but they could use the money, okay?"

      From the article, the main gist of his request is commitment to use and test the kernel for six years. There's no point devoting resources to supporting a kernel for six years if no-one bothers to use it or test it.

      1. stiine Silver badge

        Re: Please donate

        On the other hand, there's no point in releasing an LTS kernel that no-one's going to use.

    3. Anonymous Coward
      Anonymous Coward

      Re: Please donate

      Linux *mainline* is a community effort.

      Supporting anything but mainline is basically what some maintainers do as part of their work funded by the Linux Foundation etc. because the big sponsors for those bodies want LTS kernels.

      The silly thing here was the original posting thinking telling Greg that he should actually support 5.10 for 6 years because that would be useful for them and 2 years isn't long enough would result in Greg replying "oh you're totally right, I'll bump it up to 6 years just for you!".

      If you are doing something on the hobbyist level you shouldn't be trying to use LTS kernels. You should be trying to follow mainline as closely as possible. If you are shipping products that rely on LTS kernels because tracking mainline just isn't physically possible you need to either offering the people needed to do the LTS work or sponsoring someone like Greg to do it.

  2. amacater

    Always worth reading the full thread. No, Linux doesn't necessarily need pure money - it does need devs willing to step up for the long haul. That's the hard bit: money doesn't magically produce great coders and lack of interest will eventually trump finance every time.

    1. Anonymous Coward
      Unhappy

      Plus, how many great coders want to work on maintenance of outdated and approaching end of life kernels? M$ has plenty of money and coders but I would bet that those assigned to Windows 7 at the end of it's 10 years of support were not happy.

  3. Chubango

    Put up or shut up

    GKH's arguments seems reasonable. For FLOSS to work properly, it needs to be a collaborative effort. Something for nothing doesn't really work in the long run.

  4. Anonymous Coward
    Anonymous Coward

    Linux article

    In before Jake

  5. FatalR

    Need companies using it to extend the date, but companies don't want to use it until they extend the date...

    Maybe there is a reason... "every year we go through the same thing."

    1. Uplink

      The part that's new to me is "talking to some companies". Sounds like the complainant, or even Broadcom itself, isn't in the loop about LTS.

      There should be a policy prominently displayed (like an asterisk and a footnote) that says "we can go to 6 if enough people sign up", as this exchange seems to indicate the policy isn't clearly indicated.

  6. Pascal Monett Silver badge

    How can that happen ?

    How is it that people (companies) using Linux distributions do not update their installations, thereby signalling their usage of said distribution ?

    How can you complain about support if you're not keeping up to date ?

    1. Alan Brown Silver badge

      Re: How can that happen ?

      in the case of SoC-based distributions, one good exanple is Cumulus Linux

      It was working well, until Nvidia acquired the company. Support for all non-Nvidia netwoprk switch SoCs was immediately rmeoved from the distribution

      Another example is the SoC distribution used in Huawei (HiSilicon) based NVR/DVR/IP camerakit (which is virtually all of it), written and supplied by Xiaongmai (XMeye) - the entire ecosystem here is one big GPL violation and a series of lawsuits waiting to happen

  7. jake Silver badge

    The LTS crew should ...

    ... give Broadcom exactly the same level of help that Broadcom has given the FOSS world over the years. It's only fair.

  8. Anonymous Coward
    Anonymous Coward

    Surely most of this wouldn't be a problem if Linux had a stable device driver kernel interface?

    1. Anonymous Coward
      Anonymous Coward

      The script-kiddie anarchists would never do something so boring!

      When something doesn't eork, they don't fix it, that's uncool. They write a new one. API's / KPI's and compatibility be damned... Keep up with the cool kids!

      Just look at the clusterf**k around the Linux sound system!

      1. Anonymous Coward
        Anonymous Coward

        Linux does sound? I'd not noticed...

  9. G2
    Linux

    support life?

    it's actually not just about kernel support life and more about support contracts for warranties and publishing updates for devices.

    ... or more exactly, about raking in fees for support and at the same time NOT bothering to publish updates for devices in warranty (or post warranty) while claiming that a device X is still running "current" firmware because... see.. it's still running an actively supported kernel. (*cough* f.u. TP Link *cough*)

    This is why they like the long 6-year support cycles, they get to claim that their device X is "current" when running a particular kernel version from 3 years ago that's still "supported" and that's proof that they "care" about updates and support contracts. Managers signing on those contracts don't usually check the minor versions or patch numbers, they just check the version numbers that match their contracts.

    The moment the kernel becomes obsolete, it will become much easier to reveal such scams in support contracts and the lack of support / firmware updates, by simply pointing at the kernel version.

    If it were up to me i would even trim the LTS tails of all those 6-years versions down to 2-years.

    1. stiine Silver badge

      Re: support life?

      So, you'd try to solve problem number 1 with problem number 2...oh wonderful... In a previous article we were arguing about LTS support and the uptake of a 2 year vs a 10 year kernel.

    2. Nate Amsden

      Re: support life?

      why do you care what kernel is in your TP-link device, especially if it is a supported version? I just checked one of my $100k storage arrays which is running a supported software from the vendor, Running 2.6.32 kernel(apparently built in 2017). It works fine, it's a pretty locked down system(managed to sneak my ssh key onto the system during a recent support call otherwise customers don't generally have linux level access to the system). I don't have concerns. It's by far not the most recent OS release for that platform but it is technically the most recent recommended release (Just had latest patches applied a few weeks ago) for that generation of hardware(the hardware was released in late 2012, system purchased probably 2015 I think).

      I recently reported(again) some bugs with the software(not kernel related but to the storage functionality). Support said I can upgrade to the next major version to get the fixes, though I deem that too risky myself given the engineering group has told me themselves they don't generally recommend that version for this hardware. It does work, and is supported, but I'm a super conservative person with storage so I'd rather live with these bugs which I can work around then risk different perhaps worse bugs in the newer version. Unlikely to see such bugs given my use cases but it's just not THAT important to upgrade so I will run this release of software until well past end of life (late 2022), probably not retiring this piece of equipment before 2024.

      (linux user since 1996)

  10. Steve Graham

    I've always found that embedded devices have very old kernel versions, that is, they aren't "supported" at all. The companies just keep churning them out once they have software that mostly works.

    I remember finding an open telnet port on a cheap webcam. It was running a 2.x kernel with an old version of busybox as the shell. I logged in using root/123456.

    1. Alan Brown Silver badge

      That's XiongMai(XMeye) firmware on Huawei(HiSilicon) SoCs and the entire setup is a GPL violation

      Not all software pirates are cracking adobe keys

  11. Graham 32

    Chicken and egg

    Company: "Why would anyone select a 5.10 kernel with 2 year LTS"

    Kernel maintainer: "I want to see companies using the kernel ... to know if it is worth to keep around for longer than 2 years"

  12. FIA Silver badge

    He added that he does not recommend using a single kernel version for more than 2 years "on systems that you actively support and maintain". He blamed "customer-unfriendly SoC vendors" for providing "millions of [lines of] out-of-tree code" that is specific to that kernel.

    It'll probably never get done due to the nature of Linux (It would rquire the kind of colaboration that would not only be mutually beneficial but would benefit non-contributers and people who activly disliked the GPL, so probably won't happen), but a decent, well specified driver interface would really help here.

    If, as a driver writer, I knew I could target an interface that was guaranteed stable for an amout of time that would make my life much much easier.

    However, writing and maintaining such an intereface is hard, especially in the face of many competing interests and possibly with the decentralised nature of Linux development. It would require a well defined and stable spec to be created and then adheered to; would it be in the best intrest of all parties involved to make this happen? I dunno. I suspect it would take a Google or similar to actually do it. But would they fund such a thing, knowing it was going to be available for all, or would they put the effort into something they'll control? (They do have Linux to tide them over).

    There was comment on a Windows article here once, where someone laughingly referred to the time when you had to use A FLOPPY to install the SATA drivers as part of the Windows XP setup,

    This really stuck with me though. The first SATA spec was released in 2003, Windows XP late 2001.

    So you were able to install an OS from 2001 on hardware that didn't exist when it was written, simply because of a well defined and stable driver interface. Can you imagine how much easier Android would be to upgrade if this was the case? How many more devices wouldn't be udinh olf vulnurable kernels as they could receive kernel updates in a timely manner because it would just be driver qualification needed rather than actual source code changes.

    Also, just to be clear, I'm advocating a well defined, well specified binary interface, that remains consistant and is supported. None of this precludes the GPL, the 'in tree' drivers could slowy be updated to call the interface as required. (I've often heard GPL and in tree as an argument as to why a driver binary interface is a bad thing, but the reality is it's just bloody hard to do.)

    Aside: I write all that as someone who's recently reinstalled linux to use as a PVR... and the flashbacks as I had to compile just the right version of the kernel to get just the right version of the hardware drivers to work were unpleasent. At least I only have 1 TV card in now, when I used 2 that required finding the just right kernel version that would compile against the new and old drivers.

    I was installing in a VM with hardware passthrough for the card, and I so nearly just put windows on as I suspect that would have just worked... this made the young version of me extremely sad, but the reality is, the older I get the less time I have to spend 'make menuconfig'ing for fun.

    In 1995 I put a SCSI podule in my then computer, it just worked... the drivers were on the card. In 2021 I put a TV card in my computer... 3 days later... it worked. That's the wrong way round!

    1. Anonymous Coward
      Anonymous Coward

      You want FreeBSD. That's how it's done there - Releases from the same Major number are binary compatible, and compat code is kept (can be deleted if required) for previous versions.

    2. Anonymous Coward
      Anonymous Coward

      >It'll probably never get done due to the nature of Linux

      That's all down to the vendor. There are vendors like NXP and Xilinx that are actually working on mainline trying to get all of their stuff in, there are vendors like Allwinner that seem to actively avoid mainline but there is enough hobbyist effort to reverse engineer and support their stuff to the point where it's as good as or better than the officially supported stuff...... then you have vendors that are happy to stay on some old Android kernel forever. That's not a Linux problem, that's a vendor problem.

      Stop using those vendors for your products.

      >but a decent, well specified driver interface would really help here.

      Why should mainline shoot off it's own legs to help vendors that have no intention to actually work with mainline? Linux doesn't break userland but internally it can change dramatically for example reworking entire subsystems that can't take the sort of features that people want to add to them anymore.

      What you're saying is mainline needs to maintain a lot of compat guff to allow for a windows-esque driver ABI to help vendors that have no interest in mainline? Do you not see how messed up that logic is? People that want to improve Linux should waste their time on compat bullshit for vendors that don't give a crap. Would you do that work? Maybe if you were getting paid by one of those vendors... and if that were the case it would be a properiarty layer they would not release to the community.

      FYI: those vendors already do this and the result is wifi drivers that are bigger than the rest of your kernel because of all the layers of HAL crap and reproducing of stuff that's in the kernel like mac80211

      >I knew I could target an interface that was guaranteed

      >stable for an amout of time that would make my life much much easier.

      No it wouldn't. As a driver writer you would like to have all of the new helpers and generic code that has been added to make writing drivers easier and reduces the duplication for hardware that does the same function with a slightly different hardware implementation. For example: Would you want an ABI where you can present an block disk to the OS when you're writing an SD card host driver? No. Because that would mean you now have to rewrite the whole Linux MMC layer in your driver.

      What you actually want is for someone else that actually understands the SD card spec to have come along and carved out all of the pieces needed to write an MMC layer driver for an SD host so you can write a driver by filling in the 5 or 6 callbacks it needs to drive your specific hardware. Actually having to look after your code after that is the payment for having someone else make your life easy in the first place.

      And I can't be arsed to respond to the rest of what you wrote.

      If vendors want their shit to work with mainline and LTS kernels coming off of mainline they need to work at getting their stuff upstreamed. It's simple as that. No one is going to waste time making their lives easier for the sake of it.

      1. Anonymous Coward
        Anonymous Coward

        Why should mainline shoot off it's own legs to help vendors that have no intention to actually work with mainline?

        I think the answer lies in this article. The maintainers are saying they're not going to maintain this release for more than 2 years unless people actually start using it. The people who can actually lend support / help / effort / money to the task of maintaining Linux - vendors - aren't interested in using it because they know their efforts (which focus mostly around device drivers) go to waste when the "controllers" of Linux go and bugger up the driver interface. Again.

        1. Anonymous Coward
          Anonymous Coward

          >The people who can actually lend support / help /

          >effort / money to the task of maintaining Linux - vendors

          Vendors that want to work with mainline are working with mainline. Have you actually ever looked at the LKML? You might want to before writing more nonsense.

      2. Anonymous Coward
        Anonymous Coward

        What you're saying is mainline needs to maintain a lot of compat guff to allow for a windows-esque driver ABI to help vendors that have no interest in mainline? Do you not see how messed up that logic is? People that want to improve Linux should waste their time on compat bullshit for vendors that don't give a crap. Would you do that work? Maybe if you were getting paid by one of those vendors... and if that were the case it would be a properiarty layer they would not release to the community.

        Google are currently developing a kernel module to host device drivers, with the aim of providing a stable interface for device drivers. That's a major vendor's response to the matter.

        1. Anonymous Coward
          Anonymous Coward

          >Google are currently developing a kernel module to host device drivers,

          Got a link for that? And you realise that isn't a new idea right? There have been shim modules for ages. There have even been non-vendor attempts at it like the wifi compat stuff.. Guess what; It never works out because you end up with a ton of linux in your module and you have to keep adding to that with every old kernel you want to support. You always end with what we have now: LTS kernel releases to help out when tracking mainline isn't possible and people whining that other people should do work for them for free because *reasons*.

      3. FIA Silver badge

        That's all down to the vendor. There are vendors like NXP and Xilinx that are actually working on mainline trying to get all of their stuff in, ...

        You're confusing the collaborative nature of the GPL with a decent interface. It's good that vendors are contributing, the colbaration is a good thing in general.

        However, that is not the issue. You can have everything in tree and still have a well defined interface.

        >stable for an amout of time that would make my life much much easier.

        No it wouldn't.

        Why wouldn't it? Hardware doesn't change that often, your argument seems to boil down to things change? If I have a driver for a network controller for example, why can't the underlying interfaces be kept stable or versioned? Why do I have to currently know what the kernel 'looks like', so long as I know interface version X is there, I'm good... so long as interface X is there in future then you can just load my driver... no fuss.

        NetBSD and FreeBSD provide good example of how this can be done at the kernel level. Their binary interfaces, whilst still less exposed as a windows style fixed ABI are much cleaner and well defined. (So you can just generally use the same network driver on whichever machine you're running on as the underlying bus discovery and communication is handled at a lower layer, with a well defined and consistent interace).

        As a driver writer you would like to have all of the new helpers and generic code that has been added to make writing drivers easier and reduces the duplication for hardware that does the same function with a slightly different hardware implementation.

        As a driver writer I want a consistant interface so I don't have to rewrite the driver every time a new kernel is released. If I know I need to trivially re-engineer my driver every x years as that's the life of the ABI, that's fine. Doing it every few months becomes a less practical use of my time, especially if I'm being paid, which just compounds the problem of out of date software running when it shouldn't be.

        For example: Would you want an ABI where you can present an block disk to the OS when you're writing an SD card host driver? No. Because that would mean you now have to rewrite the whole Linux MMC layer in your driver.

        I don't see your point here... I would like an ABI that I could present a block structured storage at if I'm writing a driver for one, as these are quite common and I could write a driver to support a new one easly. If I'm implementing a new class of hardware then of course I need new interfaces. But your argument would seem to suggest that supporting a new hardware and having a decent driver interface isn't possible. Windows/macOS would suggest otherwise. So in your example, I'd have a stoarge class driver that implements the MMC layer, and exposes a well defined interface to the SD card host driver.

        You could then not only be sure your drivers would work going forward, but you could swap out my MMC layer with your own if you so chose, as the interfaces would be well defined and remain consistant. This is just good software engineering, It really has absolutly nothing to do with open source or the GPL.

        It's also a lot of work that noone want to do for free.

        This goes back to my point of loading SATA drivers on Window XP, that had no concept of SATA. Can you not see how that is a good thing? Most USERS of Linux don't care about the GPL or 'upstream source' or vendors being good citizens, they just want their hardware to work, and be secure.

        Like I said, it's hard.

        What you actually want is for someone else that actually understands the SD card spec to have come along and carved out all of the pieces needed to write an MMC layer driver for an SD host so you can write a driver by filling in the 5 or 6 callbacks it needs to drive your specific hardware. Actually having to look after your code after that is the payment for having someone else make your life easy in the first place.

        Yes. That's exactly what I want, but as well as that I want STABILITY... so those interfaces are well considered and extensable and either versioned or unchanging (lets be fair, versioned...)

        (You do see that the 5 or 6 callbacks are a driver interface? JUST KEEP THEM STABLE).

        A driver layer is exactly that, it's having someone else look after the bits I don't care about and not having them change all the time. This is why I say it's hard, it _does_ require a lot of work to make other peoples lives easier.

        I can load a WDDM1.0 driver written for Windows Vista on Windows 10, I can't load a WDDM2.0 driver on Vista as it supports newer features that the Vista kernel doesn't know about.

        Don't get me wrong, I understand your point of view (I think you conflate well designed code with open source, but hey), but unfortnatly it will be the death of Linux.

        Google are writing a replacement OS for android, they're also working on a binary driver layer for Linux to SOLVE THIS EXACT PROBLEM. (I wouldn't be at all suprised if this is a Fuscia driver layer ported to Linux, that would be the smart thing to do from their point of view...)

        And I can't be arsed to respond to the rest of what you wrote.

        That's okay, I never asked you to. It's a forum on a tech news site, we're all just angrily shouting into the void really. No one cares what either of us think.

        If vendors want their shit to work with mainline and LTS kernels coming off of mainline they need to work at getting their stuff upstreamed. It's simple as that. No one is going to waste time making their lives easier for the sake of it.

        Just read that last sentance again. THAT is the problem. (Hint: Massivly reducing the workload of a lot of other developers isn't a waste of time).

        1. Anonymous Coward
          Anonymous Coward

          The reason you might think NetBSD has stable interfaces is, well, because NetBSD is basically dead at this point. To use it as an example of something people would seriously consider writing drivers for outside of the hobbyist space is hilarious.

          Anyhow, what you are asking for is a module interface that exposes raw bus interfaces.. which is already there and is already *stable* because that stuff has been in use for a long time.

          The problem is people that actually write drivers don't want to do that unless the explicitly don't want use the proper subystem for something. i.e. Nvidia shouldn't need a shim driver and their drivers would probably be smaller if they didn't use a shim but they have secrets they want to hide apparently.

          No one is mainline is going to waste their time on something that would only be used by the people that would rather maintain an awful shim than upstream.

          Your driver won't break between kernel versions if you actually upstream it because whoever makes breaking API changes will also fix your driver otherwise the changes won't go in.

          Anyhow the kernel contains a document that already covers this. I think you should try to send an email to it's author and see what happens.

          https://www.kernel.org/doc/html/v5.10/process/stable-api-nonsense.html

    3. Alan Brown Silver badge

      "It'll probably never get done due to the nature of Linux "

      Actually it's a direct shot at chinese (Taiwanese and PRC) software priates like Huawei and TPlink who think that GPL means "public domain" - and argue exactly this line as reasons for refusing to either provide source code, not pay for development and as reasons for their having stripped attributions out of the code

      Huawei's Hisilicon subgroup in particular are one of the largest linux piracy operations in the world

      1. FIA Silver badge

        Huawei's Hisilicon subgroup in particular are one of the largest linux piracy operations in the world

        I always think this is a shame, it's not like there aren't alternatives that they could use without falling foul of the GPL.

        I wonder if this will come back to bite them 10-15 years down the line? As I understand it the whole concept of 'copyright' is still fairly new in China, but as they're now starting to lead the world in various areas I suspect the concept of IP may quickly be learnt. :) :)

        It isn't just a tech problem though, the (gloriously un-ironically named) CCTV (China's state broadcaster), found itself with a very large bill recently for similar reasons.

  13. Anonymous Coward
    Anonymous Coward

    Not a company but as an end-user...

    I use the Ubuntu LTS releases for the simple fact that I don't want to reinstall the OS every 2 years. (Currently running 18.04 and ok with it.) I can see the poster's complaint - why should I bother with something that won't get supported in 2 years? And no, 2 years isn't "long term", regardless of the sophistry used to argue that it is. I understand that an EOL date can change, but I don't really expect it to, and my planning will be based on the current EOL date.

    1. Nate Amsden

      Re: Not a company but as an end-user...

      Me too, hell on my laptop I ran Ubuntu 10.04 LTS way past end of life(didn't want Unity, eventually installed Mint 17), and only in the past 3 months I think did I install Mint 20 (was on Mint 17 before so ran it a good 18 months or so past end of life). So far Mint 20 has more bugs that affect me than 17 did, but whatever no deal breakers(and really nothing new experience wise that makes me happy I upgraded). I do maintain my browsers separately(manually) from the OS so I do get updates (running Palemoon, and firefox ESR and seamonkey at the same time for different tasks).

      When I was on Mint 17 I actually locked my kernel to an older release(4.4.0-98) and ran that for a solid 3 years because I was tired of shit breaking randomly after upgrades(mainly sound not working after more than one new kernel upgrade, using a Lenovo P50 laptop). I would of probably stuck to the 3.x kernels on Mint 17 but had to upgrade to 4.x to get wifi working (something I didn't realize for the first 6 months until I traveled since I never use wifi at home with my laptop always ethernet).

      Have been annoyed for so long with Linux's lack of a stable ABI for drivers. I know it'll never get fixed I've been using linux for almost 25 years now but it still annoys me. Fortunately these days server wise most of my servers are VMs. It was so frustrating back in earlier days having to slipstream ethernet and storage drivers into Redhat/CentOS kernels to kickstart systems and having to match up drivers with the kernels(even if it was off by a small revision it would puke). I think that was the last time I used cpio.

    2. William Towle
      Linux

      Re: Not a company but as an end-user...

      > why should I bother with something that won't get supported in 2 years? And no, 2 years isn't "long term", regardless of the sophistry used to argue that it is. I understand that an EOL date can change, but I don't really expect it to, and my planning will be based on the current EOL date.

      There seems to be a blurred line between Canonical's support for its distro and the support GKH wants for the mainline kernel offshoots (and who he expects it from) here.

      The poster writes with specific regard to the kernel.org announcement having a two-year EOL statement for the 5.10 kernel at time of writing. The point he raises is that it doesn't also say "this could become longer" at the page the article quotes him as citing. Like myself he may have not found it elsewhere in a quick search either.

      As a distribution end user, you need not worry so greatly: if Canonical adopt kernel 5.10 for the next Ubuntu LTS release, GKH will get the help he needs to change the lifespan announced at kernel.org from them, and similarly Ubuntu will continue to offer the lifespans you're used to enjoying; everybody wins. If a more preferable alternative turns up or 5.10 itself doesn't permit a similar promise* it will get avoided, and you still win.

      Canonical may have statements elsewhere that elaborate; I personally see no need for end users to worry unduly over the above.

      * on a related note it's already possible that 5.11 could be the stable kernel that ends up in Ubuntu 21.04 according to https://www.debugpoint.com/2020/11/ubuntu-21-04-features/

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like