linux-kernel - Re: feature-removal-schedule.txt is getting out of date again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1202327803.5820.32.camel@brick>
Date:	Wed, 06 Feb 2008 11:56:43 -0800
From:	Harvey Harrison <harvey.harrison@...il.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	"Robert P. J. Day" <rpjday@...shcourse.ca>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jiri Slaby <jirislaby@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: feature-removal-schedule.txt is getting out of date again

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 <davem@...emloft.net>
>       Christoph Hellwig <hch@....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.


> 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@...e.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.

> 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@...ux-foundation.org>
> 

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
>       linux-usb-devel@...ts.sourceforge.net mailing list, and the
developers
>       there will be glad to help you out.
> Who:  Greg Kroah-Hartman <gregkh@...e.de>

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 <pavel@...e.cz>

Still some users in-tree, some discussion happening on how to get this
finished.


Cheers,

Harvey

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/