Date:	Tue, 14 Dec 2010 13:12:00 -0500
From:	Ben Gamari <bgamari@...il.com>
To:	ltuikov@...oo.com, Matthew Dharm <mdharm-kernel@...-eyed-alien.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Greg KH <greg@...ah.com>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH] [USB] UASP: USB Attached SCSI (UAS) protocol driver


On Tue, 14 Dec 2010 09:25:12 -0800 (PST), Luben Tuikov <ltuikov@...oo.com> wrote:
> --- On Mon, 12/13/10, Matthew Dharm <mdharm-kernel@...-eyed-alien.net> wrote:
> > Your insinuations against the character of many
> > long-standing Linux
> > developers, based on their refusal to accept your
> > submission,
> 
> No, not submission. The fact is that no one bothered to review the
> code. It was simply flat out NAK-ed it in just four minutes, fronting
> one of their co-workers with the defunct driver already in.
> 
> It would've been a different story if Greg, Alan and you and anyone
> else willing, had provided a technical review, and /then/ reject
> it--the rejection reason would've been clearer to everyone, than
> taking all this thread to get to.
> 
> Greg didn't review it and rejected it 4 minutes after posting. Alan
> didn't review it and after I posted the 18 technical reasons (my 2nd
> post in this thread replying to Greg's) said this:
> 
> > Your driver may be the best on the planet - who knows - 
> Obviously he didn't review it.

This is may be true, perhaps he didn't look at the code. This is not
because he doesn't have confidence that your driver is well-written or
holds a grudge against you. The reason for this NAK is policy: a driver
already exists. In the kernel we work with what already exists, even if
it may be more difficult than the alternative.

I looked at your code; from my uninformed perspective it looks very
nice. You clearly do have a good understanding of the stack and your
code looks refreshingly clean. That being said, a driver covering the
same devices already exists in the tree. There may be good technical
reasons why this driver is inferior, but these are merely reasons to fix
the existing code, not rip it out to be replaced wholesale.

At this point you have two options: You can continue to argue that the
world is against you, which as we seen makes neither side happy and only
makes your life as a contributor harder, or you can try to work what you
have into something that will fit with the existing codebase. I suggest
the latter. Further arguing is not going to change this policy. That
being said, your expertise is certainly needed and it is in everyone's
best interest to ensure that the UAS driver in the kernel is the best
that it can be.

> I've already stated that there had never been an agenda about uasp.c
> and Linux. The uasp.c driver was written over most of a Saturday (when
> I had time and uas.c showed itself to be defunct).  Since uasp.c is a
> working driver and correctly implemented in terms of UAS, USB, SCSI,
> the kernel and it's layers, I thought it would be *helpful* and
> *useful* to people--that's all.
> 
Improving code is very useful. History has taught us that flat-out
rewriting components just makes things messier.

> The driver was rejected flat out only after 4 minutes after submission
> claiming that there is a driver in the kernel that "does the exact
> same thing".  I then provided 18 technical reasons as to why uas.c
> does NOT in fact do the exact same thing to which Greg responded with:
> 
> > But again, this driver is not acceptable as-is, sorry.
> 
> Why would he have to apologize? Anyway, to which you responded with
> not knowing which driver is good.
> 
He apologized because he knows you put a lot of time, effort, and
thought into a piece of code which we cannot accept. It is unfortunate
that this is the case but such is the reality of large-scale software
development.

> So after such a blatant refusal to even give a technical review of the
> driver, it had me thinking: why would that be?
> 
Easy question. See above. In short, there is no sense to give a
technical review of code which we ultimately won't be able use.
Sometimes this sort of thing happens. If I were you, I would accept what
people have been telling you and try to integrate portions of your
patch into the existing UAS driver. This will cause the least pain/most
benefit to all involved.

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

Powered by blists - more mailing lists