linux-kernel - Re: [PATCH 1/4] strip: move driver to staging

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: <alpine.DEB.2.00.0910261013430.11504@asgard.lang.hm>
Date:	Mon, 26 Oct 2009 10:18:20 -0700 (PDT)
From:	david@...g.hm
To:	"John W. Linville" <linville@...driver.com>
cc:	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
	gregkh@...e.de
Subject: Re: [PATCH 1/4] strip: move driver to staging

On Mon, 26 Oct 2009, John W. Linville wrote:

> On Fri, Oct 23, 2009 at 06:10:06PM +0200, Pavel Machek wrote:
>> On Tue 2009-10-20 14:17:07, John W. Linville wrote:
>>> Move the strip ("Starmode Radio IP") driver to drivers/staging.  For
>>> several years this driver has only seen API "bombing-run" changes, and
>>> few people ever had the hardware.  This driver represents unnecessary
>>> ongoing maintenance for no clear benefit.
>>
>> This seems like abuse of the staging process.
>
> My mailbox has been filling-up with discussions of using staging like
> this for the past few weeks.  I'm reasonably certain those threads
> were on the public lists.
>
>> There's no TODO to say what needs to be fixed. You just don't want to
>> maintain it. Because there's nothing to fix, noone has reason to patch
>> it, and the (working, good enough) driver will just be removed.
>
> "ongoing maintenance for no clear benefit" -- that is what is wrong
> with it.

supporting existing hardware is no longer a 'clear benifit'?

is this driver broken (as in not working)?

other than the fact that you don't think many people have this hardware, 
is there anything wrong with this driver?

>> It also marks driver as broken when it is not...
>
> I didn't mark it broken, I proposed moving it to staging.  As for
> whether or not it actually is broken, how do you know?
>
> The drivers in this thread are for pre-802.11 devices -- old ones
> (e.g. ISA) at that.  If we actually have users that are willing
> to maintain them then maybe that is fine.  But I don't see the
> benefit of maintaining these simply as extra targets for API change
> "bombing runs"...
>
>> What about removing it in the regular way, that's
>> Documentation/feature-removal.txt ?
>
> This has been discussed recently as an alternative for unmaintained
> drivers.  I suspect this is better than adding a note to a file that
> no one reads...

this is exactly the type of thing I was afraid would start happening when 
I noticed the discussion. when I tried to bring it up I was told that this 
would only be used for things that were really broken or otherwise causing 
significant problems.

if this driver hasn't been changed other than for blanket API changes, how 
is it causing significant problems?

if someone were to claim 'maintainership' and then do nothing other than 
complain if someone else were to change an API but not fix this in the 
process, how would this be different than the current situation?

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