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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.1.10.0806190117090.4593@jikos.suse.cz>
Date:	Thu, 19 Jun 2008 01:20:15 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Benny Halevy <bhalevy@...asas.com>
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 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.

-- 
Jiri Kosina
SUSE Labs
--
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/