linux-kernel - Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)

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: <20091014183657.GB5133@elte.hu>
Date:	Wed, 14 Oct 2009 20:36:57 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Joe Perches <joe@...ches.com>, Greg KH <gregkh@...e.de>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Theodore Tso <tytso@....edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jing Huang <huangj@...cade.com>, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for
	2.6.32-rc3)

* Stefan Richter <stefanr@...6.in-berlin.de> wrote:

> Ingo Molnar wrote:
> > * Joe Perches <joe@...ches.com> wrote:
> > 
> >> On Tue, 2009-10-13 at 21:45 -0700, Greg KH wrote:
> >> > How about when it was scheduled to be removed, we put it in staging and
> >> > I'll add it to my announcements about the staging tree every release?
> >> > Unless you can think of a better way?
> >> 
> >> staging/to_be_removed_unless_fixed_by/v.x.y ?
> > 
> > Yes, that's a real worry. Some time ago i suggested:
> > 
> >   drivers/staging/good/
> >   drivers/staging/bad/
> >   drivers/staging/ugly/
> 
> How well do "git am", "quilt import" and friends cope with ever 
> changing directories?

Once a driver is in a tree it's in Git and git mv is easy. People 
working with Linux better familiarize themselves with Git workflow - the 
sooner the better.

If it's not in tree then it will adopt to whatever layout there is once 
it gets into Greg's tree. I dont see the problem.

> How about using drivers/staging/this_driver/TODO and (or) its Kconfig 
> help text to leave a note about the plans for this driver?

Well, the answer is obvious i think. Tell me, at a glance, if you see a 
patch on lkml, which one is for a staging driver to be obsoleted, and 
which one is the one going upstream real soon? The patches say:

 +++ a/drivers/staging/foo/x.c

 +++ a/drivers/staging/bar/y.c

Then tell me the same at a glance if you see patches for:

 +++ a/drivers/staging/wip/x.c

 +++ a/drivers/staging/bad/y.c

> The worry that these will be ignored like 
> Documentation/feature-removal-schedule.txt is being ignored may apply 
> to the path name based solution too, I'm afraid.

It wont be 'ignored', as it's in every patch, it's in every commit, it's 
in every substantial communication about that driver.

The problem with feature-removal-schedule.txt is that it's too much out 
of sight and not part of the regular patch workflow. Same goes for any 
TODO file. Experience has shown that the actual _path_ were drivers end 
up does matter quite a bit, to general visibility and to mindset.

That's one of the reasons why we have _half a thousand_ directories in 
drivers/ to begin with. The directory namespace is very powerful, and we 
use it to convey all sorts of information about the logical category a 
driver is in.

Using it in drivers/staging/ instead of the current flat hierarchy would 
thus be pretty natural.

	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/