Re: gadget file storage with variable maxpacket

[ilya <jibberboosh@xxxxxxxxx>]

hello david, thank you for your reply. i've been trying to put together
a list of changes to make the Gadget API wireless. i'll post it here
as soon as i am done.

> > wireless usb will be introducing a lot of new control requests,
>
> Are there any that gadget drivers should be aware of?  I'd tend
> to think that key management should be invisible to them, for
> example ... WUSB peripheral controller drivers would interact
> directly with the system keystore.

you are right, when i think about it majority of new control requests
relate to the hardware and should be invisible to the gadget driver.
the only request i can think of so far is loopback read/write, which
is described in WUSB spec 1.0 section 4.8.4. basically, it is a way
for a host to test the connection by doing loopback data transfers. the
size of the transfer is determined based on the largest maxpacket of
any device's endpoint. i guess, technically, this can be transparent
to the gadget driver as well.

> > flow
> > control [ie: stalling endpoints should be the last resort because in wusb
> > you can NAK and the host will wait for a special device notification to send
> > a transfer token instead of constantly polling as in wired usb],
>
> Virtually no drivers other than g_file_storage use stalls for
> anything except reporting control transfer errors.  So if there's
> a new "wireless mass storage" spec, that's what would likely
> trigger any relevant API changes.

i don't think there is going to be a new mass storage spec 'till
USB 3. as long as the gadget provides a mechanism
to turn off the stalls, smilar to g_file_storage, everything should
be fine.

> > association, etc.
>
> In the security/session sense?  Again, I'd expect such stuff
> to be transparent to the gadget drivers.  Experience Has Shown
> that applications trying to manage authentication are as a rule
> bug-ridden security holes that only accomplish difficulty-of-use
> rather than improving security.  Maybe it could be made visible
> to drivers after the basic infrastructure works smoothly though.

so in order for a new WUSB device to connect with a host it first needs
to be "associated" with it; it is a one-time procedure that says that
in the future this specific device can connect to this specific host.

so far there are two standard mechanism for this [technically three
but i don't know how many controllers will implement near-field association]
i think the numeric association can be kept inside the driver controller;
it is based on the deiffie-hellman key exchange and requires tedious
calculations, but on the other hand it would be nice if it was implemented
inside gadget so in the future any controller driver can support it without
much work.

cable association can definitely be implemented on the gadget side
because it acts as separate wired device. i have already written a generic
cable association gadget. the only problem i am facing is that the
CBAF gadget needs to be aware of the main gadget [g_file_storage,
g_zero, ...] since it needs to provide to the host with some info, such the
device's friendly name, what language it uses, etc.

now, i think this is the most complex part... what if we have a controller
that supports both wired and wireless and maybe can even run two
separate device simultaneously, one on each side. what if when i plugin
my device i want to do cable association but also run the main gadget
wiredly [by advertising two interfaces and so forth, this is very common
among the devices i've seen so far] what if i want to run g_file_storage via
WUSB and simultaneously run g_zero on wired? i think the execution
of multiple gadgets can wait but at a minimum there should be mechanism
of advertising CBAF along with whatever gadget is running on wired and
have one aware of the other.

> > i think a lot of these things could be handled by the controller driver,
> > but there are a lot of other stuff that could be standardized and handled
> > by the "gadget" client side.
> >
> > what does david brownell think about this?
>
> I'm open to proposals.

soon i am going to post my list of what i think is crucial to make the
Gadget API wireless and what would be nice to have and we can go
from there.

again, i appreciate your participation.

-- ilya

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel