yes, i realize i'm sounding like a broken record but, once again,
Documentation/feature-removal-schedule.txt is slipping out of date WRT
items that are now slightly, if not noticeably, behind schedule for
removal.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook: http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
========================================================================
Hi,
On Wednesday 06 February 2008, Robert P. J. Day wrote:
>
> yes, i realize i'm sounding like a broken record but, once again,
> Documentation/feature-removal-schedule.txt is slipping out of date WRT
> items that are now slightly, if not noticeably, behind schedule for
> removal.
IIRC I saw few patches addressing some items but they are not yet Linus'
tree, i.e. old mxser driver removal:
http://lkml.org/lkml/2008/1/18/235
Jiri, I see that old mxser removal has been on removal list for a long time
and that Alan has reviewed the whole patch series (+ all patches look good
for me from quick skimming through them). It also has been in the last -mm
release. Because we are going to hit 2.6.25-rc1 quite soon I think that
this patch series should find its way into Linus' tree
Andrew, are you going to push it soon (or maybe Jiri should prepare git tree
and send Linus a pull request)?
Robert, I suggest that you just send patches removing outdated items (probably
starting with the one below like you tried in the past) and be quite stubborn
about it (otherwise you can be pretty sure that nothing will happen)...
...
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
....
http://lkml.org/lkml/2007/5/1/107
Christoph, 10 months later and this method doesn't seem to work.
How's about disabling it in -mm and waiting for complaints instead
(if none come just remove the code in 2.6.26-rc1)?
[ Either this or we should just remove the item in question from
feature-removal-schedule.txt. ]
Thanks,
Bart
On Wed, 2008-02-06 at 20:54 +0100, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On Wednesday 06 February 2008, Robert P. J. Day wrote:
> >
> > yes, i realize i'm sounding like a broken record but, once again,
> > Documentation/feature-removal-schedule.txt is slipping out of date WRT
> > items that are now slightly, if not noticeably, behind schedule for
> > removal.
>
I had pinged people about a week ago on lots of these items, for the
most part patches are staged and going in through various trees, let's
wait for rc1 and see what has landed by then.
Harvey
On Wednesday 06 February 2008, Harvey Harrison wrote:
> On Wed, 2008-02-06 at 20:54 +0100, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Wednesday 06 February 2008, Robert P. J. Day wrote:
> > >
> > > yes, i realize i'm sounding like a broken record but, once again,
> > > Documentation/feature-removal-schedule.txt is slipping out of date WRT
> > > items that are now slightly, if not noticeably, behind schedule for
> > > removal.
> >
>
> I had pinged people about a week ago on lots of these items, for the
> most part patches are staged and going in through various trees, let's
> wait for rc1 and see what has landed by then.
OK, great to see that it is being dealt with.
Thanks,
Bart
On Wed, 2008-02-06 at 20:54 +0100, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On Wednesday 06 February 2008, Robert P. J. Day wrote:
> >
> > yes, i realize i'm sounding like a broken record but, once again,
> > Documentation/feature-removal-schedule.txt is slipping out of date WRT
> > items that are now slightly, if not noticeably, behind schedule for
> > removal.
A quick summary of what I've been tracking, some have already gone in,
but I'll wait for rc1 to do a pass over all this and send out a summary.
What: CONFIG_FORCED INLINING:
-removal patch being tested in x86.git, upstream unlikely for 2.6.25,
not a big deal to wait for 2.6.26
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.
> 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.
> 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]>
>
Stephen Hemminger sent a removal patch to Jeff, it probably was too big
for the mailing list.
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]>
GregKH: 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.
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]>
Still some users in-tree, some discussion happening on how to get this
finished.
Cheers,
Harvey
On Wed, 6 Feb 2008, Harvey Harrison wrote:
> On Wed, 2008-02-06 at 20:54 +0100, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Wednesday 06 February 2008, Robert P. J. Day wrote:
> > >
> > > yes, i realize i'm sounding like a broken record but, once again,
> > > Documentation/feature-removal-schedule.txt is slipping out of date WRT
> > > items that are now slightly, if not noticeably, behind schedule for
> > > removal.
> >
>
> I had pinged people about a week ago on lots of these items, for the
> most part patches are staged and going in through various trees,
> let's wait for rc1 and see what has landed by then.
ah, i had no idea that things were in the pipeline. that's always
good to know but, still, it's not a bad idea to keep the info in the
features removal file as least *vaguely* up to date. at the very
least, if something seems to be more than a year behind schedule for
removal, then a small addendum to that item in that file by way of
explanation might be in order.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook: http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
========================================================================
On Wed, 6 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
> Robert, I suggest that you just send patches removing outdated items (probably
> starting with the one below like you tried in the past) and be quite stubborn
> about it (otherwise you can be pretty sure that nothing will happen)...
>
> ...
> What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
> When: November 2005
> ....
>
> http://lkml.org/lkml/2007/5/1/107
>
> Christoph, 10 months later and this method doesn't seem to work.
>
> How's about disabling it in -mm and waiting for complaints instead
> (if none come just remove the code in 2.6.26-rc1)?
>
> [ Either this or we should just remove the item in question from
> feature-removal-schedule.txt. ]
yes, i didn't see any followup on that item. i still have the patch,
unless it's already working its way thru the system.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook: http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
========================================================================