Feature Removals for 2.6.25

Feature Removals for 2.6.25

[Harvey Harrison]

The following are entries in feature-removal-schedule.txt that have
come due.  Please change the subject when replying to specific items.

Where I've gotten responses from the named person in the file, I've
included their comment.

---------------------------

What:	MXSER
When:	December 2007
Why:	Old mxser driver is obsoleted by the mxser_new. Give it some time yet
	and remove it.
Who:	Jiri Slaby <jirislaby@gmail.com>

Jiri says probably not for 2.6.25, likely 2.6.26
Patch in mm:
http://userweb.kernel.org/~akpm/mmotm/broken-out/char-mxser-remove-it.patch
---------------------------

Ping?
What:	dev->power.power_state
When:	July 2007
Why:	Broken design for runtime control over driver power states, confusing
	driver-internal runtime power management with:  mechanisms to support
	system-wide sleep state transitions; event codes that distinguish
	different phases of swsusp "sleep" transitions; and userspace policy
	inputs.  This framework was never widely used, and most attempts to
	use it were broken.  Drivers should instead be exposing domain-specific
	interfaces either to kernel or to userspace.
Who:	Pavel Machek <pavel@suse.cz>

---------------------------

What:	old NCR53C9x driver
When:	October 2007
Why:	Replaced by the much better esp_scsi driver.  Actual low-level
	driver can be ported over almost trivially.
Who:	David Miller <davem@davemloft.net>
	Christoph Hellwig <hch@lst.de>

DaveM: Likely one more release with this, perhaps delete 2.6.26
---------------------------
Ping?
What:	PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When:	November 2005
Files:	drivers/pcmcia/: pcmcia_ioctl.c
Why:	With the 16-bit PCMCIA subsystem now behaving (almost) like a
	normal hotpluggable bus, and with it using the default kernel
	infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA
	control ioctl needed by cardmgr and cardctl from pcmcia-cs is
	unnecessary, and makes further cleanups and integration of the
	PCMCIA subsystem into the Linux kernel device driver model more
	difficult. The features provided by cardmgr and cardctl are either
	handled by the kernel itself now or are available in the new
	pcmciautils package available at
	http://kernel.org/pub/linux/utils/kernel/pcmcia/
Who:	Dominik Brodowski <linux@brodo.de>

---------------------------

What:  a.out interpreter support for ELF executables
When:  2.6.25
Files: fs/binfmt_elf.c
Why:   Using a.out interpreters for ELF executables was a feature for
       transition from a.out to ELF. But now it is unlikely to be still
       needed anymore and removing it would simplify the hairy ELF
       loader code.
Who:   Andi Kleen <ak@suse.de>

Patch in mm.
---------------------------
Ping?
What:	remove EXPORT_SYMBOL(kernel_thread)
When:	August 2006
Files:	arch/*/kernel/*_ksyms.c
Check:	kernel_thread
Why:	kernel_thread is a low-level implementation detail.  Drivers should
        use the <linux/kthread.h> API instead which shields them from
	implementation details and provides a higherlevel interface that
	prevents bugs and code duplication
Who:	Christoph Hellwig <hch@lst.de>

---------------------------

What:	CONFIG_FORCED_INLINING
When:	June 2006
Why:	Config option is there to see if gcc is good enough. (in january
        2006). If it is, the behavior should just be the default. If it's not,
	the option should just go away entirely.
Who:    Arjan van de Ven

Patch submitted to Arjan, maybe 2.6.25?
---------------------------
Ping?
What:   eepro100 network driver
When:   January 2007
Why:    replaced by the e100 driver
Who:    Adrian Bunk <bunk@stusta.de>

---------------------------
Ping? Possibly remove this from feature-removal-schedule?

What:	Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
	(temporary transition config option provided until then)
	The transition config option will also be removed at the same time.
When:	before 2.6.19
Why:	Unused symbols are both increasing the size of the kernel binary
	and are often a sign of "wrong API"
Who:	Arjan van de Ven <arjan@linux.intel.com>

---------------------------
Ping?
What:	USB driver API moves to EXPORT_SYMBOL_GPL
When:	February 2008
Files:	include/linux/usb.h, drivers/usb/core/driver.c
Why:	The USB subsystem has changed a lot over time, and it has been
	possible to create userspace USB drivers using usbfs/libusb/gadgetfs
	that operate as fast as the USB bus allows.  Because of this, the USB
	subsystem will not be allowing closed source kernel drivers to
	register with it, after this grace period is over.  If anyone needs
	any help in converting their closed source drivers over to use the
	userspace filesystems, please contact the
	linux-usb-devel@lists.sourceforge.net mailing list, and the developers
	there will be glad to help you out.
Who:	Greg Kroah-Hartman <gregkh@suse.de>

---------------------------
Ping?
What:	vm_ops.nopage
When:	Soon, provided in-kernel callers have been converted
Why:	This interface is replaced by vm_ops.fault, but it has been around
	forever, is used by a lot of drivers, and doesn't cost much to
	maintain.
Who:	Nick Piggin <npiggin@suse.de>

---------------------------
Should this be removed?
What:	/proc/acpi/button
When:	August 2007
Why:	/proc/acpi/button has been replaced by events to the input layer
	since 2.6.20.
Who:	Len Brown <len.brown@intel.com>

LenB: we try to remove them, but every time we do, people scream.
---------------------------
Should this be removed?
What:	/proc/acpi/event
When:	February 2008
Why:	/proc/acpi/event has been replaced by events via the input layer
	and netlink since 2.6.23.
Who:	Len Brown <len.brown@intel.com>

LenB: we try to remove them, but every time we do, people scream.
---------------------------

What:	'time' kernel boot parameter
When:	January 2008
Why:	replaced by 'printk.time=<value>' so that printk timestamps can be
	enabled or disabled as needed
Who:	Randy Dunlap <randy.dunlap@oracle.com>

RDunlap: Adrian Bunk sent a patch for it.  I acked it.
Andrew merged it into -mm according to a commits email.
---------------------------
Ping, although Adrian is pretty good about this.
What:  drivers depending on OSS_OBSOLETE
When:  options in 2.6.23, code in 2.6.25
Why:   obsolete OSS drivers
Who:   Adrian Bunk <bunk@stusta.de>

---------------------------
Ping?
What:   sk98lin network driver
When:   Feburary 2008
Why:    In kernel tree version of driver is unmaintained. Sk98lin driver
	replaced by the skge driver. 
Who:    Stephen Hemminger <shemminger@linux-foundation.org>

Cheers,

Harve

Re: Feature Removals for 2.6.25

[Arjan van de Ven]

> 
> ---------------------------
> 
> What:	CONFIG_FORCED_INLINING
> When:	June 2006
> Why:	Config option is there to see if gcc is good enough. (in january
>         2006). If it is, the behavior should just be the default. If it's not,
> 	the option should just go away entirely.
> Who:    Arjan van de Ven
> 
> Patch submitted to Arjan, maybe 2.6.25?

Ingo picked it up, but no rush for .25, .26 is fine for this as well

> 
> What:	Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
> 	(temporary transition config option provided until then)
> 	The transition config option will also be removed at the same time.
> When:	before 2.6.19
> Why:	Unused symbols are both increasing the size of the kernel binary
> 	and are often a sign of "wrong API"
> Who:	Arjan van de Ven <arjan@linux.intel.com>

this is an ongoing work; symbols get marked unused and then garbage collected
when they're due; for example akpm has several of that kind in his pile right now

Re: Feature Removals for 2.6.25 (USB driver api)

[Greg KH]

> ---------------------------
> Ping?
> What:	USB driver API moves to EXPORT_SYMBOL_GPL
> When:	February 2008
> Files:	include/linux/usb.h, drivers/usb/core/driver.c
> Why:	The USB subsystem has changed a lot over time, and it has been
> 	possible to create userspace USB drivers using usbfs/libusb/gadgetfs
> 	that operate as fast as the USB bus allows.  Because of this, the USB
> 	subsystem will not be allowing closed source kernel drivers to
> 	register with it, after this grace period is over.  If anyone needs
> 	any help in converting their closed source drivers over to use the
> 	userspace filesystems, please contact the
> 	linux-usb-devel@lists.sourceforge.net mailing list, and the developers
> 	there will be glad to help you out.
> Who:	Greg Kroah-Hartman <gregkh@suse.de>

This is queued up in my tree to go to Linus, see my previous post on
lkml and the linux-usb mailing list about this topic.

thanks,

greg k-h

Re: Feature Removals for 2.6.25

[Harvey Harrison]

On Thu, 2008-01-31 at 20:53 -0800, Arjan van de Ven wrote:
> > 
> > ---------------------------
> > 
> > What:	CONFIG_FORCED_INLINING
> > When:	June 2006
> > Why:	Config option is there to see if gcc is good enough. (in january
> >         2006). If it is, the behavior should just be the default. If it's not,
> > 	the option should just go away entirely.
> > Who:    Arjan van de Ven
> > 
> > Patch submitted to Arjan, maybe 2.6.25?
> 
> Ingo picked it up, but no rush for .25, .26 is fine for this as well
> 

OK, it shouldn't be any change from what's there now, but no rush.

> > 
> > What:	Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
> > 	(temporary transition config option provided until then)
> > 	The transition config option will also be removed at the same time.
> > When:	before 2.6.19
> > Why:	Unused symbols are both increasing the size of the kernel binary
> > 	and are often a sign of "wrong API"
> > Who:	Arjan van de Ven <arjan@linux.intel.com>
> 
> this is an ongoing work; symbols get marked unused and then garbage collected
> when they're due; for example akpm has several of that kind in his pile right now

How do they get marked?  As this is an ongoing effort, should this be
moved to the top of the file, and the actual symbols+date be listed?
That would make it easy to figure out what's going away.

Something like the following (grep found me two example symbols)

Harvey

---
From: Harvey Harrison <harvey.harrison@gmail.com>
Subject: [PATCH] feature-removal: document symbols going away

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
 Documentation/feature-removal-schedule.txt |   25 +++++++++++++++----------
 1 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 3a46d1f..0c418e6 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -5,6 +5,21 @@ the work.  When the feature is removed from the kernel, it should also
 be removed from this file.
 
 ---------------------------
+What:	Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
+	(temporary transition config option provided until then)
+	The transition config option will also be removed at the same time.
+Why:	Unused symbols are both increasing the size of the kernel binary
+	and are often a sign of "wrong API"
+Who:	Arjan van de Ven <arjan@linux.intel.com>
+
+When: 2.6.25
+fs/open.c:sys_open
+fs/read_write.c:sys_read
+
+When: 2.6.26
+
+
+---------------------------
 
 What:	MXSER
 When:	December 2007
@@ -137,16 +152,6 @@ Who:    Adrian Bunk <bunk@stusta.de>
 
 ---------------------------
 
-What:	Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
-	(temporary transition config option provided until then)
-	The transition config option will also be removed at the same time.
-When:	before 2.6.19
-Why:	Unused symbols are both increasing the size of the kernel binary
-	and are often a sign of "wrong API"
-Who:	Arjan van de Ven <arjan@linux.intel.com>
-
----------------------------
-
 What:	USB driver API moves to EXPORT_SYMBOL_GPL
 When:	February 2008
 Files:	include/linux/usb.h, drivers/usb/core/driver.c
-- 
1.5.4.rc4.1142.gf5a97

Re: Feature Removals for 2.6.25

[Arjan van de Ven]

Harvey Harrison wrote:
> Something like the following (grep found me two example symbols)

to be honest, nobody reads this file with such detail; the actual UNUSED marking
is a lot more louder and people are more likely to notice those.... for all I care
we nuke the entire entry from the removals file.

Re: Feature Removals for 2.6.25

[Harvey Harrison]

On Thu, 2008-01-31 at 22:33 -0800, Arjan van de Ven wrote:
> Harvey Harrison wrote:
> > Something like the following (grep found me two example symbols)
> 
> to be honest, nobody reads this file with such detail; the actual UNUSED marking
> is a lot more louder and people are more likely to notice those.... for all I care
> we nuke the entire entry from the removals file.

Well, if there is interest in having an up-to-date file, I'm willing to
do the bookkeeping to make this usable and try to keep it up to date.

Anybody think this is worthwhile?

Harvey

Re: Feature Removals for 2.6.25

[Stephen Hemminger]

> Ping?
> What:   sk98lin network driver
> When:   Feburary 2008
> Why:    In kernel tree version of driver is unmaintained. Sk98lin driver
> 	replaced by the skge driver. 
> Who:    Stephen Hemminger <shemminger@linux-foundation.org>
> 

Sent a removal patch to Jeff, it probably was too big for the mailing list.
-- 
Stephen Hemminger <stephen.hemminger@vyatta.com>

Re: Feature Removals for 2.6.25

[Nick Piggin]

On Thu, Jan 31, 2008 at 05:38:42PM -0800, Harvey Harrison wrote:
> ---------------------------
> Ping?
> What:	vm_ops.nopage
> When:	Soon, provided in-kernel callers have been converted
> Why:	This interface is replaced by vm_ops.fault, but it has been around
> 	forever, is used by a lot of drivers, and doesn't cost much to
> 	maintain.
> Who:	Nick Piggin <npiggin@suse.de>

Well the in-kernel callers have not all been converted yet. I have
actually done the work, but it needs testing and merging by maintainers.
Getting it done during this merge window would be nice, I'm going to
try to make that happen after I get back from LCA. Otherwise probably
2.6.26.

Re: Feature Removals for 2.6.25 - old NCR53C9x driver

[Boaz Harrosh]

On Fri, Feb 01 2008 at 3:38 +0200, Harvey Harrison <harvey.harrison@gmail.com> wrote:
> The following are entries in feature-removal-schedule.txt that have
> come due.  Please change the subject when replying to specific items.
> 
> Where I've gotten responses from the named person in the file, I've
> included their comment.
> 
> ---------------------------
> 
> What:	old NCR53C9x driver
> When:	October 2007
> Why:	Replaced by the much better esp_scsi driver.  Actual low-level
> 	driver can be ported over almost trivially.
> Who:	David Miller <davem@davemloft.net>
> 	Christoph Hellwig <hch@lst.de>
> 
> DaveM: Likely one more release with this, perhaps delete 2.6.26
> ---------------------------
This has been done and is currently in scsi-misc awaiting for a pull.

Re: Feature Removals for 2.6.25

[Bill Davidsen]

Harvey Harrison wrote:
> What:	CONFIG_FORCED_INLINING
> When:	June 2006
> Why:	Config option is there to see if gcc is good enough. (in january
>         2006). If it is, the behavior should just be the default. If it's not,
> 	the option should just go away entirely.
> Who:    Arjan van de Ven
> 
> Patch submitted to Arjan, maybe 2.6.25?
> ---------------------------

The "good enough" of gcc may be architecture dependent. Taking the 
option away where it works because somewhere else it doesn't may not be 
the optimal solution.


> Ping?
> What:   eepro100 network driver
> When:   January 2007
> Why:    replaced by the e100 driver
> Who:    Adrian Bunk <bunk@stusta.de>
> 
> ---------------------------

The last time we discussed this the team working on e100 said there were 
still issues (IIRC). Have they all been resolved?


> Ping?
> What:   sk98lin network driver
> When:   Feburary 2008
> Why:    In kernel tree version of driver is unmaintained. Sk98lin driver
> 	replaced by the skge driver. 
> Who:    Stephen Hemminger <shemminger@linux-foundation.org>
> 
> ---------------------------

We have been over this several times, and I thought someone had taken 
over the driver and was providing patches to put it in. Both skge and 
sky2 have been proposed as the replacement, people have reported 
problems with each. Suggest leaving this alone until the sk98lin 
actually needs work, then take it out. Problems in my problem system 
have been intermittent, take 4-40 hours to show and generate no errors, 
other than the driver thinks it's sending packets and the sniffer doesn't.


-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: Feature Removals for 2.6.25

[Stephen Hemminger]

> 
> > Ping?
> > What:   sk98lin network driver
> > When:   Feburary 2008
> > Why:    In kernel tree version of driver is unmaintained. Sk98lin driver
> > 	replaced by the skge driver. 
> > Who:    Stephen Hemminger <shemminger@linux-foundation.org>
> > 
> > ---------------------------
> 
> We have been over this several times, and I thought someone had taken 
> over the driver and was providing patches to put it in. Both skge and 
> sky2 have been proposed as the replacement, people have reported 
> problems with each. Suggest leaving this alone until the sk98lin 
> actually needs work, then take it out. Problems in my problem system 
> have been intermittent, take 4-40 hours to show and generate no errors, 
> other than the driver thinks it's sending packets and the sniffer doesn't.

The vendor sk98lin driver will continue it's happy life out of tree.
The version in 2.6.25 is ancient and unmaintained and only supports older
hardware. There are no outstanding issues with skge driver (sky2 is 
prone to hardware problems, but then so is vendor driver).

Unfortunately, removing sk98lin seems to be the only way to make die
hard users report problems. The last time we removed it, some user's of
old Genesis boards showed with issues, but those are now fixed.

Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably 
be gone from -mm before that). 

Re: Feature Removals for 2.6.25

[Bill Davidsen]

Stephen Hemminger wrote:
>>> Ping?
>>> What:   sk98lin network driver
>>> When:   Feburary 2008
>>> Why:    In kernel tree version of driver is unmaintained. Sk98lin driver
>>> 	replaced by the skge driver. 
>>> Who:    Stephen Hemminger <shemminger@linux-foundation.org>
>>>
>>> ---------------------------
>>>       
>> We have been over this several times, and I thought someone had taken 
>> over the driver and was providing patches to put it in. Both skge and 
>> sky2 have been proposed as the replacement, people have reported 
>> problems with each. Suggest leaving this alone until the sk98lin 
>> actually needs work, then take it out. Problems in my problem system 
>> have been intermittent, take 4-40 hours to show and generate no errors, 
>> other than the driver thinks it's sending packets and the sniffer doesn't.
>>     
>
> The vendor sk98lin driver will continue it's happy life out of tree.
> The version in 2.6.25 is ancient and unmaintained and only supports older
> hardware. There are no outstanding issues with skge driver (sky2 is 
> prone to hardware problems, but then so is vendor driver).
>   

And those of us who are using it *have* old hardware. Old hardware that 
perhaps the people forcing other driver on us don't have.
> Unfortunately, removing sk98lin seems to be the only way to make die
> hard users report problems. The last time we removed it, some user's of
> old Genesis boards showed with issues, but those are now fixed.
>   

I guess I have a real problem with the "make die hard users report 
problems" thing, because it assumes that there is nothing wrong with 
*causing* us problems. Understand, this is not "change is bad" but 
"change is expensive." Because it means a change in kernel config, 
modules.conf, and possibly rc.local or initrd or similar. A per-machine 
effort which is small in ones, and large in sum.
> Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably 
> be gone from -mm before that). 
>
>   
If this were a case of the sk98lin driver needing work, I wouldn't be 
making the argument. But to make work for users in a case where there is 
no saving in effort for developers, sounds as if the developers place no 
value at all on the time of the people who build their own kernels, and 
if the vendors are good with it, that's all that matters.

Note that because the hardware is old, it's highly likely that most of 
it will be retired before that sk98lin driver needs a change. I can't 
see anyone using sk98lin on a new system, so it would be less 
contentious to let the hardware (or users) die of natural causes if you can.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 

Re: Feature Removals for 2.6.25

[Arjan van de Ven]

Bill Davidsen wrote:
> Note that because the hardware is old, it's highly likely that most of 
> it will be retired before that sk98lin driver needs a change. I can't 
> see anyone using sk98lin on a new system, so it would be less 
> contentious to let the hardware (or users) die of natural causes if you 
> can.
> 

the problem is that the new one DOES NOT GET FIXED.
THAT is a huge problem; it means we have a buggy driver...

Re: Feature Removals for 2.6.25

[Christoph Hellwig]

On Thu, Feb 14, 2008 at 10:24:43AM -0800, Arjan van de Ven wrote:
> Bill Davidsen wrote:
> >Note that because the hardware is old, it's highly likely that most of 
> >it will be retired before that sk98lin driver needs a change. I can't 
> >see anyone using sk98lin on a new system, so it would be less 
> >contentious to let the hardware (or users) die of natural causes if you 
> >can.
> >
> 
> the problem is that the new one DOES NOT GET FIXED.
> THAT is a huge problem; it means we have a buggy driver...

It's also utterly missing the point.  The skge driver supports all the
hardware that sk98lin supports.  If it doesn't work bug Stephen who's
a very responsive maintainer.

Re: Feature Removals for 2.6.25

[David Newall]

Arjan van de Ven wrote:
> Bill Davidsen wrote:
>> Note that because the hardware is old, it's highly likely that most
>> of it will be retired before that sk98lin driver needs a change. I
>> can't see anyone using sk98lin on a new system, so it would be less
>> contentious to let the hardware (or users) die of natural causes if
>> you can.
>>
>
> the problem is that the new one DOES NOT GET FIXED.
> THAT is a huge problem; it means we have a buggy driver...

If the old one works and the new one is buggy, it begs the question of
why anybody bothered writing a new one in the first place.  "If it ain't
broke, don't fix it," might have been good advice to follow.

Re: Feature Removals for 2.6.25

[Rene Herman]

On 15-02-08 00:20, David Newall wrote:

> Arjan van de Ven wrote:
>> Bill Davidsen wrote:
>>> Note that because the hardware is old, it's highly likely that most
>>> of it will be retired before that sk98lin driver needs a change. I
>>> can't see anyone using sk98lin on a new system, so it would be less
>>> contentious to let the hardware (or users) die of natural causes if
>>> you can.
>>>
>> the problem is that the new one DOES NOT GET FIXED.
>> THAT is a huge problem; it means we have a buggy driver...
> 
> If the old one works and the new one is buggy, it begs the question of
> why anybody bothered writing a new one in the first place.  "If it ain't
> broke, don't fix it," might have been good advice to follow.

Not generally. A usual scenario is the new driver working on newer hardware 
versions than the old one supports but not necessarily on all the old ones 
the previous driver supported if only due to to availability of the older 
hardware for testing.

Rene.