Hi,
No. What I think is that USBPacket shouldn't be required to be an actual
USB packet, but a transfer, i.e. do the splitting of larger transfers into
smaller packets in the usb driver emulation (if needed), not the host
adapter emulation.
The OHCI spec still requires us to only process one max-packet-size
worth of data from this TransferDescriptor before we move on to
the next one, though, doesn't it? (cf the flowchart in fig 6-7).
[ didn't look at specs ]
Yes, EHCI has a simliar rule, on real hardware it is needed to ensure
the available USB bandwidth is fairly splitted across all devices by
serving them in a robin-round fashion.
I don't think this makes much sense for emulation as it behaves very
different compared to real hardware. There simply is no bus with
limited bandwidth we have to care about.
It seems to me that at least some of that is likely to be
guest-visible, especially in the case where an endpoint returns an
error partway through. So it's not clear to me that you could
validly batch up everything in the TD and do it all at once.
I think the only guest-visible effect is that the guest will never ever
see an partially filled transfer block, it is either empty or completely
filled (except on short transfers).
cheers,
Gerd
