Hi,
On 03/11/2010 01:14 AM, ext David Brownell wrote:
On Wednesday 10 March 2010, Alan Cox wrote:
It sounds like a bug that someone needs to provide a test case and
explanation for. The underlying buffering logic appears solid up to about
40MB/sec (beyond that the existing buffer settings and round trip time
for flow control would need addressing and possibly some data handling).
I don't see any real value in a char abstraction for most of the cases
where we hit performance and other problems - a packet abstraction ought
to be both a lot faster and provide a more flexible interface for
stuff where usb frame boundaries matter.
Worth clarifying. If u_char is just to provide a lower overhead byte
stream abstraction (packet/frame boundaries never matter) than TTY,
that's one thing. Last time I looked at the protocols involved, that
was the I/O model.
But there's no doubt that some protocols get built over packet streams,
a different abstraction. Reaching back to the early Ethernet days, some
folk may recall that the original XNS protocol stack included a "Sequenced
Packet Protocol" SPP, in contrast to the byte stream model of TCP.
- Dave
We want to get g_mtp upstream, and the only thing blocking it was the u_char
abstraction mechanism.
I need to know how we can proceed with this. I can see the following options
1) remove, u_char.c and merge it into f_mtp.c so that people who need character
abstraction can use the existing u_serial.c. bugs in TTY/line discipline should
be fixed.
2) change u_char.c to provide packet abstraction. I don't know how this is done.
Does this mean providing a socket interface?
Please let me know if there is any other way we can proceed. Thanks.
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
