Ksummit-Discuss Archive on lore.kernel.org
 help / color / Atom feed
* [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
@ 2020-07-31 15:00 Arnd Bergmann
  2020-07-31 21:27 ` josh
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Arnd Bergmann @ 2020-07-31 15:00 UTC (permalink / raw)
  To: ksummit, Mike Rapoport, linux-arch, Linux Kernel Mailing List

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?
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
  2020-07-31 15:00 [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence Arnd Bergmann
@ 2020-07-31 21:27 ` josh
  2020-07-31 21:57   ` Bird, Tim
  2020-08-05 17:26 ` Pavel Machek
  2020-08-16 12:53 ` Michael Ellerman
  2 siblings, 1 reply; 9+ messages in thread
From: josh @ 2020-07-31 21:27 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arch, Linux Kernel Mailing List, ksummit

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".
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
  2020-07-31 21:27 ` josh
@ 2020-07-31 21:57   ` Bird, Tim
  2020-07-31 22:47     ` josh
  0 siblings, 1 reply; 9+ messages in thread
From: Bird, Tim @ 2020-07-31 21:57 UTC (permalink / raw)
  To: josh, Arnd Bergmann; +Cc: linux-arch, Linux Kernel Mailing List, ksummit

> -----Original Message-----
> From: josh@joshtriplett.org
> 
> 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

_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
  2020-07-31 21:57   ` Bird, Tim
@ 2020-07-31 22:47     ` josh
  0 siblings, 0 replies; 9+ messages in thread
From: josh @ 2020-07-31 22:47 UTC (permalink / raw)
  To: Bird, Tim; +Cc: linux-arch, ksummit, Linux Kernel Mailing List

On Fri, Jul 31, 2020 at 09:57:41PM +0000, Bird, Tim wrote:
> > -----Original Message-----
> > From: josh@joshtriplett.org
> > 
> > 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?
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
  2020-07-31 15:00 [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence Arnd Bergmann
  2020-07-31 21:27 ` josh
@ 2020-08-05 17:26 ` Pavel Machek
  2020-08-05 18:50   ` Geert Uytterhoeven
  2020-08-16 12:53 ` Michael Ellerman
  2 siblings, 1 reply; 9+ messages in thread
From: Pavel Machek @ 2020-08-05 17:26 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arch, Linux Kernel Mailing List, ksummit

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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
  2020-08-05 17:26 ` Pavel Machek
@ 2020-08-05 18:50   ` Geert Uytterhoeven
  2020-08-05 19:30     ` Pavel Machek
  0 siblings, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2020-08-05 18:50 UTC (permalink / raw)
  To: Pavel Machek; +Cc: linux-arch, ksummit, Linux Kernel Mailing List

Hi Pavel,

On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek <pavel@ucw.cz> 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 -- geert@linux-m68k.org

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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
  2020-08-05 18:50   ` Geert Uytterhoeven
@ 2020-08-05 19:30     ` Pavel Machek
  2020-08-10 19:39       ` Olof Johansson
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Machek @ 2020-08-05 19:30 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: linux-arch, ksummit, Linux Kernel Mailing List

[-- Attachment #1.1: Type: text/plain, Size: 1052 bytes --]

On Wed 2020-08-05 20:50:43, Geert Uytterhoeven wrote:
> Hi Pavel,
> 
> On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek <pavel@ucw.cz> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 186 bytes --]

_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
  2020-08-05 19:30     ` Pavel Machek
@ 2020-08-10 19:39       ` Olof Johansson
  0 siblings, 0 replies; 9+ messages in thread
From: Olof Johansson @ 2020-08-10 19:39 UTC (permalink / raw)
  To: Pavel Machek; +Cc: linux-arch, Linux Kernel Mailing List, ksummit

On Wed, Aug 5, 2020 at 12:30 PM Pavel Machek <pavel@denx.de> 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 <pavel@ucw.cz> 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
  2020-07-31 15:00 [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence Arnd Bergmann
  2020-07-31 21:27 ` josh
  2020-08-05 17:26 ` Pavel Machek
@ 2020-08-16 12:53 ` Michael Ellerman
  2 siblings, 0 replies; 9+ messages in thread
From: Michael Ellerman @ 2020-08-16 12:53 UTC (permalink / raw)
  To: Arnd Bergmann, ksummit, Mike Rapoport, linux-arch,
	Linux Kernel Mailing List

Arnd Bergmann <arnd@arndb.de> 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-31 15:00 [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence Arnd Bergmann
2020-07-31 21:27 ` josh
2020-07-31 21:57   ` Bird, Tim
2020-07-31 22:47     ` josh
2020-08-05 17:26 ` Pavel Machek
2020-08-05 18:50   ` Geert Uytterhoeven
2020-08-05 19:30     ` Pavel Machek
2020-08-10 19:39       ` Olof Johansson
2020-08-16 12:53 ` Michael Ellerman

Ksummit-Discuss Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/ksummit-discuss/0 ksummit-discuss/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ksummit-discuss ksummit-discuss/ https://lore.kernel.org/ksummit-discuss \
		ksummit-discuss@lists.linuxfoundation.org ksummit-discuss@lists.linux-foundation.org
	public-inbox-index ksummit-discuss

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linuxfoundation.lists.ksummit-discuss


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git