Hi Andrew, > > > > This is not correct. The queuing mechanism in USB2 guarantees that the > > last queued command is last executed: > > There are a few options, > > - coalesce on a single task (on,off,on = on), the off never happened. > - drain the task first then resubmit > > Those cover both scenarios, (1) you dont care about previous state or > (2) you do care so ensure the previous state has executed. >
"2" is not an option. MPSAFETTY cannot sleep! And there is no IOCTL to drain the DTR command, if I'm not mistaken. > If for some reason those are not sufficient then the driver is free to > implement its own queue. We don't want per-driver queues. We want one queue mechanism for USB. Like I've pointed out, last queued is last executed is a good requirement. For simple things like DTR, sure you could coalesque state changes, but again, that is not optimal, because it is unpredictable. Also see my other e-mail with same subject to Warner. It's like with queues. There is SLIST, LIST, TAILQ, STAILQ. Different need needs different macro. The same should be the case with taskqueues. I have looked at the internals of the taskqueue and the only reordering mechanism is a priority mechanism. To some extent my implementation is about dynamic and efficient priority re-ordering of messages. The taskqueue_enqueue() can have a complexity of X squared, X*X, given the iteration accross the messages already queued, in some cases. Mine has a complexity of 1. What do you think? Is it impossible to add another queue function to the taskqueue system? > The current implementation in usb is quite > clever but its important not to complicate the internals for situations > that dont happen in real life. I would argue that the taskqueue approach is too simple for USB. --HPS _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
