linux-kernel - Re: [Ksummit-2008-discuss] Request for discussion on when to merge drivers

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: <485A0BE8.7020306@panasas.com>
Date:	Thu, 19 Jun 2008 10:34:00 +0300
From:	Benny Halevy <bhalevy@...asas.com>
To:	Jiri Kosina <jkosina@...e.cz>
CC:	James Bottomley <James.Bottomley@...senpartnership.com>,
	ksummit-2008-discuss@...ts.linux-foundation.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2008-discuss] Request for discussion on when to merge
 drivers

On Jun. 19, 2008, 2:20 +0300, Jiri Kosina <jkosina@...e.cz> wrote:
> On Wed, 18 Jun 2008, Benny Halevy wrote:
> 
>> Exposing the not-yet-ready-to-be-released code to linux-next will expose 
>> conflicts earlier, and hopefully in smaller, more manageable deltas.
> 
> I like the way linux-next works now, i.e. it should reflect what is going 
> into the next major kernel release. Nothing more, nothing less.
> 
> Also, when talking about entirely new drivers for hardware that hasn't 
> been supported by the kernel at all so far (this is the situation we are 
> talking about, right?), there shouldn't be a lot of conflicts to be dealt 
> with, right? Ideally, drivers should be pretty isolated standalone pieces 
> of code that don't have any business changing any code that has been 
> already there.
> 

The showcase example I have in mind is our OSD initiator for which
we pushed all dependencies already upstream, so currently it has
no conflicts with the existing code.  However, it is not ready
for the next release since it should be reviewed, documented,
and accepted by the sub-system maintainer first.

I would like it to be included in linux-next so to be alerted of any
arising conflict so I can fix it in "real time" rather than waiting
for the next release to come out.  Initially I thought it'd be a good
candidate for linux-staging, but Greg doesn't quite agree with that
(http://lkml.org/lkml/2008/6/11/225) since it's destined for linux-scsi.
Hence, a -staging branch/tree based off of James' tree makes sense.

Benny

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