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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2014-06-11 at 15:26 -0700, Roland Dreier wrote:
> On Wed, Jun 11, 2014 at 3:17 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > This would eventually become like CONFIG_EXPERIMENTAL before somebody
> > put it out of its misery: a pointless thing which everybody enables.
> 
> Probably so.
> 
> > 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
> > offence?
> 
> Every time a developer wants to change a core API, that developer
> needs to patch every driver that uses the API.  Every old, unused,
> bitrotten driver we have in the tree is 100% wasted work, and often a
> substantial amount of work because it's really hard even to understand
> how those drivers are (mis)using the API being changed.

Well how often do we do that?  It's not like it's the most common
activity.

Even when we do it, mostly the changes are mechanical and no-one really
notices.  On the odd occasion we have to change the call properties of
the API (usually because of locking or layering problems) it forces the
question of whether the driver is in use or not.  Mostly you don't
change the API and put the driver under CONFIG_BROKEN to see if anyone
turns up to claim it.

In fact, we could document the above and call it our driver deprecation
process.  I've done this occasionally in SCSI, but the fact it's so rare
tends to make me think we don't really have that much of a problem.

James