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: <200910152058.33114.bzolnier@gmail.com>
Date:	Thu, 15 Oct 2009 20:58:33 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Greg KH <gregkh@...e.de>
Cc:	david@...g.hm, 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 Thursday 15 October 2009 20:46:56 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.

Sure, it will build at the of being submitted to staging..

> > This will result in a "new kernel new hardware" world that some distro
> > people have been silently trying to accomplish and in this brave new world
> > few key people have way too much advantage over everyone else.
> 
> I don't understand what you are referring to here.

See my PM.
--
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/