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 21:16:41 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	david@...g.hm
Cc:	Greg KH <gregkh@...e.de>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: removing existing working drivers via staging

* david@...g.hm <david@...g.hm> wrote:

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

Where do you get the 6-9 months from? Greg said he'll wait 3 kernel 
releases. Here's the timeline of that:

 - release x
 - [A] driver moves into drivers/staging/ in the staging tree
 - release x+1
 - drivers/staging/ change gets merged in the x+2 merge window
 - release x+2 - first kernel with the driver in staging
 - release x+3
 - release x+4
 - driver gets removed in the staging tree
 - release x+5 - 3 kernel releases passed - now it's removed
 - removal propagates upstream in the x+6 merge window
 - [B] release x+6

from the decision to move it into staging there's 4 kernel releases 
during which the information is known, and 3 full kernel releases with 
the driver is actually moved, and even in the 4th cycle there's still 3 
months to undo the removal if there's objections (i.e. it's a 
regression).

This means the timeline is 4*3 = 12 months _at minimum_. In practice it 
will be more than a year - up to 1.5 years. Well within most distros ~3 
months upstream kernel update schedule.

And if a distro does not follow the upstream kernel ... that's a self 
inflicted wound and a distro problem really.

	Ingo
--
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/