linux-kernel - RE: [ofa-general] Re: InfiniBand/RDMA merge plans for 2.6.25

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: <5E701717F2B2ED4EA60F87C8AA57B7CC0794FEA2@venom2>
Date:	Tue, 22 Jan 2008 17:49:12 -0600
From:	"Glenn Streiff" <gstreiff@...Effect.com>
To:	"Roland Dreier" <rdreier@...co.com>,
	"Christoph Hellwig" <hch@...radead.org>
Cc:	<linux-kernel@...r.kernel.org>, <general@...ts.openfabrics.org>
Subject: RE: [ofa-general] Re: InfiniBand/RDMA merge plans for 2.6.25


> From: general-bounces@...ts.openfabrics.org
> [mailto:general-bounces@...ts.openfabrics.org]On Behalf Of 
> Roland Dreier
> Sent: Tuesday, January 22, 2008 3:56 PM
> To: Christoph Hellwig
> Cc: linux-kernel@...r.kernel.org; general@...ts.openfabrics.org
> Subject: [ofa-general] Re: InfiniBand/RDMA merge plans for 2.6.25
> 
> 
>  > >  - Neteffect "nes" driver.  It's not terribly clean code 
> but since
>  > >    it's a new driver that is completely self-contained, I plan on
>  > >    merging it and letting cleanups happen upstream.
>  > 
>  > New code should be better quality than old code, not 
> worse.   I haven't
>  > actually seen the driver yet, but by that statement I'd be clearly
>  > against a merge.
> 
> The driver has been posted a few times; the latest code is in the
> "neteffect" branch of my tree:
> 
>     
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniban
> d.git neteffect
> 
> It's not *that* bad -- certainly there are lots of things that could
> be improved (sparse endianness annotation, too many lines that are way
> to long, strange indentation of case labeles, etc, etc) but it is a
> self-contained hardware driver.  I agree with Linus's position (stated
> at the last kernel summit) that we ought to merge hardware drivers
> early, so that users get the drivers with as little hassle as
> possible.  We lose a little leverage in getting cleanups done, but the
> number of people who see the code and are able to clean it up
> increases, so I think it's a good trade-off.
> 
>  - R.
> 

My view is the code should and will be cleaned up based upon
the feedback we've gotten from the community.  It is a priority
for me.

Several cleanup fixes are in the queue and are being worked.
Haven't slipped into complacency at the prospect of the merge.

Glenn
gstreiff@...effect.com
--
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/