Roman,
> There are a lot of things that are endpoint specific:
(endpoint in a given config/altsetting ...)
> e.g. maxpacketsize, toggle bit, startingpoint and intervall
> of INTR transfers, queueingpoint for URBs,...
> And all that information is spread around. Some bits are in the
> device struct some bits are in the URBs pipe slot. This can cause
> a lot of inconsistency. E.g. the urb->dev field and the
> usb_pipedevice (urb->pipe) can address two different devices within
> the same URB and so on.
Yes, I suspect there's trouble lurking there somewhere.
But I suspect that phasing out the "pipe" data structure
can't be an all-at-once thing.
One could start by identifying troublesome duplication
in the "pipe", such as usb_pipedevice(), and gradually
replacing them with safer fields, urb->dev->devnum
in that example, finally removing the pipe macro.
> I think it would be better to use a more socket like approach
> (maybe in 2.5):
Major URB API cleanups, not before 2.5 for sure!
> An URB is like a socket_buffer and an endpoint is like a socket.
I think better analogies would be
URB ~= sk_buff
endpoint ~= port
pipe [usb architecture] ~= connected socket
device ~= host/peer
I'm not sure what the "pipe" in the URB API corresponds to
in either the USB architecture or the socket analogy. As you
pointed out, it's got a mix of port, host, and QOS options ...
> So the endpoint-entries would hold all that static information of an USB
> endpoint and the URBs just points to the data blocks.
That is, you're suggesting to think about replacing the "pipe" in
an URB with a pointer to the endpoint descriptor in the current
config+altsetting? I've had the same thought. But converting
all the code would be a rather large job ...
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
