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]

Message-ID: <alpine.DEB.2.00.0910150936310.22169@asgard.lang.hm>
Date:	Thu, 15 Oct 2009 09:39:51 -0700 (PDT)
From:	david@...g.hm
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Greg KH <gregkh@...e.de>
Subject: Re: removing existing working drivers via staging

On Thu, 15 Oct 2009, Stefan Richter wrote:

> david@...g.hm wrote:
>> I missed this discussion in the thread "Moving drivers into
>> staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-" and I suspect that
>> many others did as well
>>
>> for those that missed it, as I understand it the proposal is that 'ugly'
>> (working drivers that don't do things the kernel way and are perceived as
>> not being commonly used anymore) drivers will get moved into staging, and
>
> There was mention of "abandoned and unused" drivers (rather than "not
> /commonly/ used anymore"), see e.g.
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-10/msg05204.html
> (2nd to last paragraph; thread continues with Greg's follow-up).

how can you tell if a driver is "unused"? (other than leaving it broken 
for several years and getting no complaints)

>> if the driver maintainers do not clean them up within 6-9 months they will
>> be removed entirely.
>>
>> the expectation is that if there are no maintainers for the driver who
>> care enough to do the cleanup they should be removed (with interested
>> users being able to take over maintaining the drivers if there the
>> maintainers are MIA)
>>
>> I have several reactions to this
>>
>> I think that 6-9 months (2-3 releases) is _far_ too short for users to
>> notice. most users will be using a distro kernel that is on a release
>> cycle longer than this (even if they are not using a 'enterprise' distro),
>> so their first inkling of a problem will be the driver disappearing on
>> them. Yes the driver can be recovered through git, bit at that point
>> there is going to be catch-up changes to make.
>>
>> What happened to the desire that Linux would be able to use anything, and
>> once a driver was upstream changes to the kernel that would break it
>> should be fixed by whoever is introducing those changes? This seems to be
>> moving in the direction of only having drivers for fairly current, fairly
>> common hardware.
>
> AFAIU, mostly just code which is known to _not work_ anymore or has been
> functionally replaced by an alternative drops out of the mainline.  This
> idea of using drivers/staging/ in the process is surely not going to
> change that in principle; it will only raise awareness among active
> kernel developers better than feature-removal-schedule.txt can do.

I don't disagree with dropping code that has been replaced by an 
alternative. and I don't disagree much with dropping broken code.

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.

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/