linux-kernel - Re: [PATCH 1/4] strip: move driver to 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: <4AE6B094.90505@s5r6.in-berlin.de>
Date:	Tue, 27 Oct 2009 09:34:28 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	david@...g.hm
CC:	Greg KH <gregkh@...e.de>,
	"John W. Linville" <linville@...driver.com>,
	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] strip: move driver to staging

david@...g.hm wrote:
> On Mon, 26 Oct 2009, Greg KH wrote:
>> A person "claiming maintainership" would then be responsible for keeping
>> the API up to date and ensuring that the driver worked.  To do that,
>> hardware would probably need to be present.
> 
> actually, I understood that the person changing the API was responsible
> for making the changes. when did this change?

I'm not sure what the procedure with drivers/staging/ is, which is a
middle ground between in-tree and out-of-tree.  For in-tree code, last
time I watched the procedure was thus:
  - Those who change an infrastructure are responsible to /code/ the
necessary changes in all infrastructure using subsystems.
  - Usually they are also responsible to submit those changes upstream;
if the change is done in a source-compatible manner during a transition
period, then those API changes in dependent subsystems are sometimes
submitted via the respective subsystem maintainers instead, but that's
not typical.
  - Those who introduce such changes usually cannot be expected to
runtime-test except with one or few subsystems for which they happen to
have matching hardware.  Thus, a small but real danger of regressions
remains.  Usually only the subsystem maintainer or users can detect and
fix such regressions.

But remember, there are no formal rules, there are only "best
practices".  (And sometimes new procedures are tried out in order to
find out whether they work or not, such as the 2.4+2.5 -> 2.6 switch of
development models, the merge window, linux-next, drivers/staging/ as a
way in for out-of-tree drivers, drivers/staging as a way out for broken
or obsolete drivers...)
-- 
Stefan Richter
-=====-==--= =-=- ==-==
http://arcgraph.de/sr/
--
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/