[Ksummit-discuss] Topic: Removal of code that is still in use by users but there is a better code.

James Bottomley James.Bottomley at HansenPartnership.com
Wed Jun 11 22:17:54 UTC 2014

On Wed, 2014-06-11 at 15:01 -0700, Andy Lutomirski wrote:
> On Wed, Jun 11, 2014 at 2:53 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> > Hi Bjorn,
> >
> > On Wed, 11 Jun 2014 13:43:18 -0600 Bjorn Helgaas <bhelgaas at google.com> wrote:
> >>
> >> all did our jobs perfectly, we would never add a change to Linux that
> >> broke compilation of anything.  So if there's a file that doesn't
> >> compile anymore, I think of that as a result of a mistake somewhere
> >> along the line.  We can use that mistake to deduce that nobody cares
> >> anymore, but it'd be a lot nicer to have a scheme that didn't depend
> >> on people making random mistakes.
> >
> > We could start making nonrandom mistakes? ;-)
> How about adding CONFIG_DELETED_THINGS.  If you enable it, you get a
> message asking you to speak up if you actually need anything in there.
> CONFIG_DELETED_THINGS would default to n, and the new (and temporary)
> things under it would also default to n.
> Think feature-removal-schedule, but with teeth.

This would eventually become like CONFIG_EXPERIMENTAL before somebody
put it out of its misery: a pointless thing which everybody enables.

Could we just step back and ask what the burning need to do this (at
least for drivers; I understand the ABI deprecation headache) is?  Most
driver code for obsolete things harmlessly compiles; why bother trying
to hunt them down and shoot them when they're not really causing


More information about the Ksummit-discuss mailing list