linux-kernel - Re: [2.6 patch] mark pci_find_device() as _

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: <1163955010.31358.529.camel@laptopd505.fenrus.org>
Date:	Sun, 19 Nov 2006 17:50:09 +0100
From:	Arjan van de Ven <arjan@...radead.org>
To:	Muli Ben-Yehuda <muli@...ibm.com>
Cc:	Adrian Bunk <bunk@...sta.de>, Alan Cox <alan@...hat.com>,
	Andrew Morton <akpm@...l.org>, gregkh@...e.de,
	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sun, 2006-11-19 at 17:24 +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 03:06:00PM +0100, Adrian Bunk wrote:
> 
> > unmaintained != not used
> > 
> > As an example, some people might be unhappy if the floppy driver that is 
> > unmaintained for ages and not in a good state was removed.
> 
> I understand. However, if it was slated to be removed, said people
> might be inclined to start maintaining it. We have a bar for inclusion
> of new code into the tree - why shouldn't a quality bar also be
> applied to old code in the tree?

this bypasses the convenient fact that there are 2 types of
unmaintained:

1) Drivers that barely, if at all, limp along and nobody has hw for
2) Drivers that no one person is the declared maintainer, but which do
get fixed when they break by "someone"

floppy.c is of the later kind; the hardware is widespread enough to make
that feasible I suppose; while the former kind are mostly ISA slot cards
that virtually nobody has (or only people who can't or don't want to
care about the linux kernel driver; a bunch of serial expander drivers
and a whole lot of the ISDN drivers falls in this category)

marking the category 1) drivers that limp along as "don't warn on
deprecated" is sort of fair; they're not far enough down deathrow yet
that they can be removed entirely, yet they also shouldn't clutter up
the build logs and they shouldn't prevent us from deprecating APIs that
are truely broken (*_sleep_on(), cli() etc) in 2.6 kernels...


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

-
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/