linux-kernel - Re: [PATCH] [USB] UASP: USB Attached SCSI (UAS) protocol driver

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: <20101213215324.GA6565@rhlx01.hs-esslingen.de>
Date:	Mon, 13 Dec 2010 22:53:25 +0100
From:	Andreas Mohr <andi@...as.de>
To:	Mark Brown <broonie@...ena.org.uk>
Cc:	Matthias Schniedermeyer <ms@...d.de>,
	Luben Tuikov <ltuikov@...oo.com>,
	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

I was just chilling down late in the evening by reading a short LKML 
overview, and then inadvertently managed to hit this bomb shell ;)

> As uas has not been in a release-kernel, by definition, there is no 
> impact either way. No regressions or anything else.

Since I've actually just been oldconfig'ing uas driver yesterday on a new 
installation, I can relate to UAS kernel support being quite new 
in its entirety.

If this is the case, then I'd also tend to believe the situation
is very different from other more painful (since longstanding) driver conflicts
(e.g. 8139, some raid drivers, and also e100 as witnessed by myself).

The author of UASP might want to adjust some of his writings
(especially the more personal parts),
however several parts of his criticism (e.g. no focus on code review)
seem valid from my POV.

If the new driver indeed is a whole lot better than the other newly
submitted/unreleased driver, then I'd fully welcome a reevaluation of the
situation.

For the author of the original submission this might of course be a
"less than positive" (to put it extreemely mildly) situation.
Still, I'd hope that there could be sufficient agreement on how to proceed
and how to make sure to have the most fitting code get into the kernel
and be maintained properly, ideally by continued interest by _both_
authors (or perhaps via "personality firewalls" ;), obviously.

Alas, I'm feeling like I'm stating obvious blathering here.

Anyway, by now you know which direction I'm tending in, despite the
not terribly warm writings by a certain author ;)

Disclaimer: no code review (comparison) performed, sorry.
Disclaimer #2: as the author of a still-outstanding kernel patch
(uhm - hi Greg ;) I'm in a sufficiently unfavourable position to comment
on this...

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