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.0910271136530.11504@asgard.lang.hm>
Date:	Tue, 27 Oct 2009 11:39:54 -0700 (PDT)
From:	david@...g.hm
To:	Greg KH <gregkh@...e.de>
cc:	"John W. Linville" <linville@...driver.com>,
	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] strip: move driver to staging

On Tue, 27 Oct 2009, Greg KH wrote:

> On Mon, Oct 26, 2009 at 09:17:55PM -0700, david@...g.hm wrote:
>> On Mon, 26 Oct 2009, Greg KH wrote:
>>
>>> On Mon, Oct 26, 2009 at 10:18:20AM -0700, david@...g.hm wrote:
>>>> 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?
>>>
>>> A person "claiming maintainership" would then be responsible for keeping
>>> the API up to date and ensuring that the driver worked.  To do that,
>>> hardware would probably need to be present.
>>
>> actually, I understood that the person changing the API was responsible
>> for making the changes. when did this change?
>
> It did not.
>
>>> Do you have this kind of hardware and are willing to accept ownership of
>>> this driver?
>>
>> no, I do not have the hardware, but if there are no bugs reported against
>> this driverit would seem that having a 'maintainer' who made absolutly no
>> changes to the driver (just allowing API changes by others to be
>> implemented) would be the same thing as having no maintainer, but in the
>> first case you are willing to have the driver in the kernel, in the other
>> you want to rip it out.
>>
>> it used to be (not that long ago) that when people said that the reason
>> they didn't push their driver upstream into the kernel because there
>> wasn't that much demand for it, the response was that we wanted drivers
>> for everything, no matter how small the user base. I remember seeing posts
>> from core developers saying that we had drivers for hardware where there
>> were only single digit quantities ever built.
>>
>> now it appears that you have to have 'enough' users (an amount undefined)
>
> That amount would be 1.  This driver does not have that, so it can be
> removed.

while I definantly agree that this driver is unlikly to have many users, 
unless it is known broken (which David Miller has stated that it is, but 
had not been mentioned previously in this thread), how can you know that 
the number of users has dropped below 1?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ