How are the URB calls better than using the synchronous calls? (see below)
Because this makes the USB side a lot more complicated, and it would
introduce transport specific code into the core. Further, it would
involve the transport driver calling hidraw with _every_ single packet
it receives. Further, it would have to call hidraw with HANDSHAKE
protocol error packets as well.
It would make the USB transport driver and drivers/hid/hidraw much more
complicated right now, at the expense of making the BT transport driver
marginally simpler (and I'm not even convinced whether it would really
be simpler). (see below for more)
I just don't understand the objection. In each transport type, the
waiting will have to be done in a different way. USB and BT are
different enough that this is the case already, without having to
imagine future buses which use HID. In BT, you have to check each packet
which comes back from the BT network to see whether it is the response
packet that hidraw is waiting for. Further, you have to check for
HANDSHAKE packets indicating protocol error. Where better for this to be
done than in hidp? Further, how can this possibly happen in
drivers/hid/hidraw, as it doesn't know about the details of bluetooth to
make this determination, and why should it? In my last email (
http://lkml.org/lkml/2010/7/9/231 ) to which I got no response, I laid
out how doing the blocking in drivers/hid/hidraw would only make all the
parts except bluetooth more complicated (including the core, and the USB
side), and would also introduce bluetooth-specific things into the core.
Further, you're saying that using the asynchronous USB URB calls would
be a benefit. How is it a benefit to replace a single function call
which does exactly what I want, with a set of asynchronous calls and
then adding my own blocking to make it do the same thing? This sounds to
me like it would be 1: more text, 2: duplication of code, 3: error
prone. I can't understand how this is of benefit. Please explain to me
what I'm missing.
In theory, what you're saying makes sense. Making common code and logic
actually common is always good. In practice though, in this case, I
submit that there really isn't any commonality, and the only way for
there to be commonality is to do the USB side the hard way. Further,
drivers/hid/hidraw can't wait for a bluetooth packet without having code
that's bluetooth-specific. It seems just that simple to me.
I'll give it some more thought, and take another look at the code to see
if there's something obvious that I'm missing. If you know what I'm
missing in my understanding of the problem, please tell me :)
Alan.
--
