Linux Might Better Plan Its Code/Hardware Obsolescence From The Kernel
One of the many interesting discussions for this week's virtual Linux Plumbers Conference is on planning code obsolescence moving forward. While this is about kernel features too, it's also about the steps and when to phase out old hardware support.
Arnd Bergmann got the discussion started this week at LPC 2020 for something that will surely be discussed more on the mailing lists in the weeks ahead over planning code obsolescence.
This long time kernel developer is seeking to have upstream work on better documentation that tracks kernel features considered potentially "obsolete". The documentation would include detailing the Kconfig switches / knobs for toggling the functionality, how long upstream plans to maintain the existing support, any justifications for keeping the code around, points of contact for said code, and the benefits of removing the "obsolete" code.
By better keeping track of the potentially obsolete kernel code and if any users are still relying upon the features or hardware in question with the latest upstream kernel releases, it will hopefully be easier and more clear about when such functionality should be phased out as well as having the documentation that formally outlines their plans for discontinuing the support possibly in the future.
A benefit in getting rid of the obsolete code is lowering the maintenance burden of the kernel and making it easier for future code improvements and new features without risking the regressing of the old support or having to update that code that potentially has no real users left. One example is that two years ago Arnd dropped several outdated CPU architectures from the kernel that ended up not having any active users and in doing so allowed cleaning up cross-architecture kernel code that otherwise would have otherwise been much more difficult and time consuming.
The YouTube video from the LPC2020 discussion should be available shortly while for now is the PDF slide deck about the code obsolescence discussion.
Arnd Bergmann got the discussion started this week at LPC 2020 for something that will surely be discussed more on the mailing lists in the weeks ahead over planning code obsolescence.
This long time kernel developer is seeking to have upstream work on better documentation that tracks kernel features considered potentially "obsolete". The documentation would include detailing the Kconfig switches / knobs for toggling the functionality, how long upstream plans to maintain the existing support, any justifications for keeping the code around, points of contact for said code, and the benefits of removing the "obsolete" code.
By better keeping track of the potentially obsolete kernel code and if any users are still relying upon the features or hardware in question with the latest upstream kernel releases, it will hopefully be easier and more clear about when such functionality should be phased out as well as having the documentation that formally outlines their plans for discontinuing the support possibly in the future.
A benefit in getting rid of the obsolete code is lowering the maintenance burden of the kernel and making it easier for future code improvements and new features without risking the regressing of the old support or having to update that code that potentially has no real users left. One example is that two years ago Arnd dropped several outdated CPU architectures from the kernel that ended up not having any active users and in doing so allowed cleaning up cross-architecture kernel code that otherwise would have otherwise been much more difficult and time consuming.
The YouTube video from the LPC2020 discussion should be available shortly while for now is the PDF slide deck about the code obsolescence discussion.
24 Comments