linux-kernel - Re: [RFC] UASP on target

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]

Date:	Mon, 05 Dec 2011 09:55:13 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	balbi@...com
CC:	Shimrit Malichi <smalichi@...eaurora.org>,
	Tatyana Brokhman <tlinder@...eaurora.org>,
	"open list:USB GADGET/PERIPH..." <linux-usb@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>,
	target-devel@...r.kernel.org
Subject: Re: [RFC] UASP on target

On 12/05/2011 09:39 AM, Felipe Balbi wrote:
> Hi,
Hi,

> On Mon, Dec 05, 2011 at 09:23:26AM +0100, Sebastian Andrzej Siewior wrote:
>> * Sebastian Andrzej Siewior | 2011-12-05 09:20:47 [+0100]:
>>
>>> * Shimrit Malichi | 2011-12-04 21:53:09 [+0200]:
>>>
>>>> This patch implements the infrastructure for the UAS gadget driver.
>>>> The UAS gadget driver registers as a second configuration of the MS
>>>> gadet driver.
>>> hch said to use target framework and you haven't done so. This is what I
>>> have so far. It is not yet complete. What I need to do is:
>>> - wire up command processing (currently here)
>>> - wire up data processing
>>> - check it works =>  post v1
>>> - wire up command tagging =>  v2
>>> - remove hard codings and fix whatever people complained about.
>
> This is much better, indeed, but the way it is now, it's only usable by
> the gadget framework because you have put the function driver on the
> transport layer. I wonder if there wouldn't be a simple way to split the
> "SCSI Over USB" part in a more generic way which could be shared between
> gadget side UASP and host side UASP drivers ?!? Maybe ?!?
>
> The drivers/target/uasp_*.c would really be just a transport layer and
> gadget/host drivers would make calls to that "library" ? Something like
> that ??

There is very little code that is not host specific. For instance
uas_alloc_cmd_urb() is something that could be used on both side but
the host is boxing the command and I need to unbox it. So I don't see
how I could share things except for the defines.
Most of the things are usb specific. So UAS gets the commands from the
scsi framework, puts the usb layer around it and sends them.

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