I have submitted the below as a topic for the linux/arch/* MC that Mike
and I run, but I suppose it also makes sense to discuss it on the
ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well
even if we don't discuss it at the main ksummit track.
Arnd
8<---
The majority of the code in the kernel deals with hardware that was made
a long time ago, and we are regularly discussing which of those bits are
still needed. In some cases (e.g. 20+ year old RISC workstation support),
there are hobbyists that take care of maintainership despite there being
no commercial interest. In other cases (e.g. x.25 networking) it turned
out that there are very long-lived products that are actively supported
on new kernels.
When I removed support for eight instruction set architectures in 2018,
those were the ones that no longer had any users of mainline kernels,
and removing them allowed later cleanup of cross-architecture code that
would have been much harder before.
I propose adding a Documentation file that keeps track of any notable
kernel feature that could be classified as "obsolete", and listing
e.g. following properties:
* Kconfig symbol controlling the feature
* How long we expect to keep it as a minimum
* Known use cases, or other reasons this needs to stay
* Latest kernel in which it was known to have worked
* Contact information for known users (mailing list, personal email)
* Other features that may depend on this
* Possible benefits of eventually removing it
With that information, my hope is that it becomes easier to plan when
some code can be removed after the last users have stopped upgrading
their kernels, while also preventing code from being removed that is
actually still in active use.
In the discussion at the linux/arch/* MC, I would hope to answer these
questions:
* Do other developers find this useful to have?
* Where should the information be kept (Documentation/*, Kconfig,
MAINTAINERS, wiki.kernel.org, ...)
* Which information should be part of an entry?
* What granularity should this be applied to -- only high-level features
like CPU architectures and subsystems, or individual drivers and machines?
On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> The majority of the code in the kernel deals with hardware that was made
> a long time ago, and we are regularly discussing which of those bits are
> still needed. In some cases (e.g. 20+ year old RISC workstation support),
> there are hobbyists that take care of maintainership despite there being
> no commercial interest. In other cases (e.g. x.25 networking) it turned
> out that there are very long-lived products that are actively supported
> on new kernels.
>
> When I removed support for eight instruction set architectures in 2018,
> those were the ones that no longer had any users of mainline kernels,
> and removing them allowed later cleanup of cross-architecture code that
> would have been much harder before.
>
> I propose adding a Documentation file that keeps track of any notable
> kernel feature that could be classified as "obsolete", and listing
> e.g. following properties:
>
> * Kconfig symbol controlling the feature
>
> * How long we expect to keep it as a minimum
>
> * Known use cases, or other reasons this needs to stay
>
> * Latest kernel in which it was known to have worked
>
> * Contact information for known users (mailing list, personal email)
>
> * Other features that may depend on this
>
> * Possible benefits of eventually removing it
We had this once, in the form of feature-removal-schedule.txt. It was,
itself, removed in commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7.
I *do* think there'd be value in having policies and processes for "how
do we carefully remove a driver/architecture/etc we think nobody cares
about". That's separate from having an actual in-kernel list of "things
we think we can remove".
> -----Original Message-----
> From: [email protected]
>
> On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> > The majority of the code in the kernel deals with hardware that was made
> > a long time ago, and we are regularly discussing which of those bits are
> > still needed. In some cases (e.g. 20+ year old RISC workstation support),
> > there are hobbyists that take care of maintainership despite there being
> > no commercial interest. In other cases (e.g. x.25 networking) it turned
> > out that there are very long-lived products that are actively supported
> > on new kernels.
> >
> > When I removed support for eight instruction set architectures in 2018,
> > those were the ones that no longer had any users of mainline kernels,
> > and removing them allowed later cleanup of cross-architecture code that
> > would have been much harder before.
> >
> > I propose adding a Documentation file that keeps track of any notable
> > kernel feature that could be classified as "obsolete", and listing
> > e.g. following properties:
> >
> > * Kconfig symbol controlling the feature
> >
> > * How long we expect to keep it as a minimum
> >
> > * Known use cases, or other reasons this needs to stay
> >
> > * Latest kernel in which it was known to have worked
> >
> > * Contact information for known users (mailing list, personal email)
> >
> > * Other features that may depend on this
> >
> > * Possible benefits of eventually removing it
>
> We had this once, in the form of feature-removal-schedule.txt. It was,
> itself, removed in commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7.
>
> I *do* think there'd be value in having policies and processes for "how
> do we carefully remove a driver/architecture/etc we think nobody cares
> about". That's separate from having an actual in-kernel list of "things
> we think we can remove".
I'm not sure the documents are the same. I think what Arnd is proposing
is more of a "why is this thing still here?" document. When someone does
research into who's still using a feature and why, that can be valuable information
to share so that future maintenance or removal decisions can be better informed.
Maybe e-mails are sufficient for this, but they'd be harder to find than something in
the kernel source. But that supposes that people would look at the file, which
appears didn't happen with feature-removal-schedule.txt.
-- Tim
On Fri, Jul 31, 2020 at 09:57:41PM +0000, Bird, Tim wrote:
> > -----Original Message-----
> > From: [email protected]
> >
> > On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> > > The majority of the code in the kernel deals with hardware that was made
> > > a long time ago, and we are regularly discussing which of those bits are
> > > still needed. In some cases (e.g. 20+ year old RISC workstation support),
> > > there are hobbyists that take care of maintainership despite there being
> > > no commercial interest. In other cases (e.g. x.25 networking) it turned
> > > out that there are very long-lived products that are actively supported
> > > on new kernels.
> > >
> > > When I removed support for eight instruction set architectures in 2018,
> > > those were the ones that no longer had any users of mainline kernels,
> > > and removing them allowed later cleanup of cross-architecture code that
> > > would have been much harder before.
> > >
> > > I propose adding a Documentation file that keeps track of any notable
> > > kernel feature that could be classified as "obsolete", and listing
> > > e.g. following properties:
> > >
> > > * Kconfig symbol controlling the feature
> > >
> > > * How long we expect to keep it as a minimum
> > >
> > > * Known use cases, or other reasons this needs to stay
> > >
> > > * Latest kernel in which it was known to have worked
> > >
> > > * Contact information for known users (mailing list, personal email)
> > >
> > > * Other features that may depend on this
> > >
> > > * Possible benefits of eventually removing it
> >
> > We had this once, in the form of feature-removal-schedule.txt. It was,
> > itself, removed in commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7.
> >
> > I *do* think there'd be value in having policies and processes for "how
> > do we carefully remove a driver/architecture/etc we think nobody cares
> > about". That's separate from having an actual in-kernel list of "things
> > we think we can remove".
>
> I'm not sure the documents are the same. I think what Arnd is proposing
> is more of a "why is this thing still here?" document. When someone does
> research into who's still using a feature and why, that can be valuable information
> to share so that future maintenance or removal decisions can be better informed.
>
> Maybe e-mails are sufficient for this, but they'd be harder to find than something in
> the kernel source. But that supposes that people would look at the file, which
> appears didn't happen with feature-removal-schedule.txt.
Ah, I see. So this *isn't* about "features we want to remove", this is
"features people might think we should remove, but here's the
documentation for why we aren't"? More of an
obscure-but-still-wanted-features.txt?
Hi!
> I have submitted the below as a topic for the linux/arch/* MC that Mike
> and I run, but I suppose it also makes sense to discuss it on the
> ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well
> even if we don't discuss it at the main ksummit track.
> * Latest kernel in which it was known to have worked
For some old hardware, I started collecting kernel version, .config and dmesg from
successful boots. github.com/pavelmachek, click on "missy".
Best regards,
Pavel
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Pavel,
On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek <[email protected]> wrote:
> > I have submitted the below as a topic for the linux/arch/* MC that Mike
> > and I run, but I suppose it also makes sense to discuss it on the
> > ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well
> > even if we don't discuss it at the main ksummit track.
>
> > * Latest kernel in which it was known to have worked
>
> For some old hardware, I started collecting kernel version, .config and dmesg from
> successful boots. github.com/pavelmachek, click on "missy".
You mean your complete hardware collection doesn't boot v5.8? ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed 2020-08-05 20:50:43, Geert Uytterhoeven wrote:
> Hi Pavel,
>
> On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek <[email protected]> wrote:
> > > I have submitted the below as a topic for the linux/arch/* MC that Mike
> > > and I run, but I suppose it also makes sense to discuss it on the
> > > ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well
> > > even if we don't discuss it at the main ksummit track.
> >
> > > * Latest kernel in which it was known to have worked
> >
> > For some old hardware, I started collecting kernel version, .config and dmesg from
> > successful boots. github.com/pavelmachek, click on "missy".
>
> You mean your complete hardware collection doesn't boot v5.8? ;-)
I need to do some pushing, and yes, maybe some more testing.
But I was wondering if someone sees this as useful and wants to
contribute more devices? :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, Aug 5, 2020 at 12:30 PM Pavel Machek <[email protected]> wrote:
>
> On Wed 2020-08-05 20:50:43, Geert Uytterhoeven wrote:
> > Hi Pavel,
> >
> > On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek <[email protected]> wrote:
> > > > I have submitted the below as a topic for the linux/arch/* MC that Mike
> > > > and I run, but I suppose it also makes sense to discuss it on the
> > > > ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well
> > > > even if we don't discuss it at the main ksummit track.
> > >
> > > > * Latest kernel in which it was known to have worked
> > >
> > > For some old hardware, I started collecting kernel version, .config and dmesg from
> > > successful boots. github.com/pavelmachek, click on "missy".
> >
> > You mean your complete hardware collection doesn't boot v5.8? ;-)
>
> I need to do some pushing, and yes, maybe some more testing.
>
> But I was wondering if someone sees this as useful and wants to
> contribute more devices? :-).
There's in my opinion a big difference between "the last user of this
device sent it to Pavel and now it will be supported forever in spite
of no users" and "there's a whole group of people using mainline on
these old devices and Pavel makes sure it keeps booting for them".
-Olof
Arnd Bergmann <[email protected]> writes:
> I have submitted the below as a topic for the linux/arch/* MC that Mike
> and I run, but I suppose it also makes sense to discuss it on the
> ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well
> even if we don't discuss it at the main ksummit track.
>
> Arnd
>
> 8<---
...
>
> I propose adding a Documentation file that keeps track of any notable
> kernel feature that could be classified as "obsolete", and listing
> e.g. following properties:
>
> * Kconfig symbol controlling the feature
>
> * How long we expect to keep it as a minimum
>
> * Known use cases, or other reasons this needs to stay
>
> * Latest kernel in which it was known to have worked
>
> * Contact information for known users (mailing list, personal email)
>
> * Other features that may depend on this
>
> * Possible benefits of eventually removing it
>
> With that information, my hope is that it becomes easier to plan when
> some code can be removed after the last users have stopped upgrading
> their kernels, while also preventing code from being removed that is
> actually still in active use.
>
> In the discussion at the linux/arch/* MC, I would hope to answer these
> questions:
>
> * Do other developers find this useful to have?
Yes!
> * Where should the information be kept (Documentation/*, Kconfig,
> MAINTAINERS, wiki.kernel.org, ...)
Documentation/ seems like the obvious place. Possibly also somewhere on
wiki.kernel.org or elsewhere so that people can contribute information
without having to submit a formal patch.
> * Which information should be part of an entry?
Your list above is pretty good.
For features that relate to specific hardware I think it would be useful
to have some more information.
For example when the hardware was last manufactured, who made it, how
could it be purchased when it was available (eg. was it for sale to the
public or in limited quantities or only to certain people or internal to
a particular company).
> * What granularity should this be applied to -- only high-level features
> like CPU architectures and subsystems, or individual drivers and machines?
I think it can make sense at many levels. It probably just depends on
how much effort folks want to go to in order to track down the
information.
Looking at powerpc it would be useful to have that sort of info for
individual boards, as well as each platform, CPU families and specific
drivers.
cheers