linux-kernel - Re: removing existing working drivers via 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]

Date:	Thu, 15 Oct 2009 12:02:28 -0700 (PDT)
From:	david@...g.hm
To:	Greg KH <gregkh@...e.de>
cc:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: removing existing working drivers via staging

On Thu, 15 Oct 2009, Greg KH wrote:

> On Thu, Oct 15, 2009 at 08:20:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> On Thursday 15 October 2009 19:49:32 Greg KH wrote:
>>> On Thu, Oct 15, 2009 at 07:42:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>>> On Thursday 15 October 2009 18:47:26 Greg KH wrote:
>>>>> On Thu, Oct 15, 2009 at 09:39:51AM -0700, david@...g.hm wrote:
>>>>>> however, what I think I saw proposed was to move drivers that need to be
>>>>>> 'cleaned up', to staging and then dropping them if they don't get cleaned.
>>>>>
>>>>> What is "proposed" is the following:
>>>>>
>>>>> 	- For drivers currently in the kernel tree, that the subsystem
>>>>> 	  maintainer, for whatever reason, feels is obsolete / broken /
>>>>> 	  needs major cleaning / wants to get rid of, can be submitted
>>>>> 	  to the staging maintainer to be moved to the drivers/staging/
>>>>> 	  directory.
>>>>
>>>> This is insanity and opens a door for various forms of abuse.
>>>
>>> What do you mean by this?  What kind of "abuse"?
>>
>> Typical situation:
>>
>> You have driver for _really_ difficult hardware used by minority of total
>> users of a given subsystem.  Said driver has no major problems except being
>> f*cking complicated (because of hardware) so it stays in the way of future
>> changes.
>>
>> With the current system people making bigger changes have to comprehend
>> that difficult stuff [*].  This is a good thing in the long-term since it
>> results in the better overall system understanding, better knowledge of
>> "DO's and DON'T's" and better users' experience.
>>
>> Now with the proposed scheme it is sufficient to throw said driver into
>> staging for few weeks and make future changes.  Before users even notice
>> and complain they are screwed already since bringing the driver back is
>> no longer possible without big effort (+ subsystem is still evolving)..
>
> But a driver in staging still has to be able to build, api changes are
> not able to be ignored in it.

a driver in staging will be able to build, but a driver that was removed 
after 6-9 months that a user discovered the removal of a year later when 
they upgraded to a new distro release (say a normal ubuntu release after 
staying on the old one for the 18 month support period) is likely to need 
significant work to catch up with kernel changes in the meanwhile.

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/