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 <[email protected]>
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 <[email protected]>
---------------------------
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 <[email protected]>
Christoph Hellwig <[email protected]>
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 <[email protected]>
---------------------------
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 <[email protected]>
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 <[email protected]>
---------------------------
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 <[email protected]>
---------------------------
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 <[email protected]>
---------------------------
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
[email protected] mailing list, and the developers
there will be glad to help you out.
Who: Greg Kroah-Hartman <[email protected]>
---------------------------
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 <[email protected]>
---------------------------
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
---------------------------
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 <[email protected]>
Cheers,
Harve
>
> ---------------------------
>
> 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 <[email protected]>
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
> ---------------------------
> 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
> [email protected] mailing list, and the developers
> there will be glad to help you out.
> Who: Greg Kroah-Hartman <[email protected]>
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
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 <[email protected]>
>
> 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 <[email protected]>
Subject: [PATCH] feature-removal: document symbols going away
Signed-off-by: Harvey Harrison <[email protected]>
---
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 <[email protected]>
+
+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 <[email protected]>
---------------------------
-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 <[email protected]>
-
----------------------------
-
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
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.
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
> 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 <[email protected]>
>
Sent a removal patch to Jeff, it probably was too big for the mailing list.
--
Stephen Hemminger <[email protected]>
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 <[email protected]>
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.
On Fri, Feb 01 2008 at 3:38 +0200, Harvey Harrison <[email protected]> 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 <[email protected]>
> Christoph Hellwig <[email protected]>
>
> 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.
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 <[email protected]>
>
> ---------------------------
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 <[email protected]>
>
> ---------------------------
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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
>
> > 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 <[email protected]>
> >
> > ---------------------------
>
> 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).
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 <[email protected]>
>>>
>>> ---------------------------
>>>
>> 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 <[email protected]>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
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...
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.
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.
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.