linux-kernel - 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0910142213590.22169@asgard.lang.hm>
Date:	Wed, 14 Oct 2009 22:27:58 -0700 (PDT)
From:	david@...g.hm
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: removing existing working drivers via staging

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

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/