[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bluetooth-dev] Re: hci command timers II
Ok. After considering Mats comments and reviewing the spec, here's my take on things.
There are a slew of HCI commands which will not receive Command Complete events when they finish. HCI Inquiry is only one of them. I'm assuming that all the other commands in the spec which do not have at least one Return Parameter are in this same category (all the ones I've checked so far conform to this assumption). Although we do not implement many of these right now,
someday, on some platform, we will want to.
Issue #1: Using wait queues for commands which receive status. It makes sense to use queues for this iff more than one can be pending at a time. But is it safe to assume that they will be processed in order, and the Host Controller will inform us in order? In some cases, probably not (Disconnection Complete events, for example).
Issue #2: Timeouts for commands which receive status. Obviously, we don't want to wakeup these commands when we get the Command Status. Instead we want to wake them up when we get their corresponding completion events. But we also want to have a timeout in case the completion event never comes!
Issue #3: Event masking. Related to the issue above. If we mask out a completion event, should we even let the command which waits for that event proceed? If so, should we just let it send the command and wait for its completion timeout? This would be the simplest implementation but would result in the most perplexing behaviour -- I can see the mailing list questions already ;).
Issue #4: Using wait queues for commands which receive completion. Since it is impossible for more than one of these commands to be pending at a time, do we need to use a wait queue here or could we just use a semaphore?
I'm already looking at doing some significant changes to hci.c in the interest of size reduction. So I'm willing to tackle these issues. Here are my current ideas.
Use one 'pending set' for all processes waiting on commands which receive status. I'll have to see if the kernel implements something like this. The code which handles an event will search this pending set for the process which caused it and the connection handle it was for. It will wakup this process. Likewise, it will cancel the timer associated with that particular process.
Or, if the timer fires, it will wake up the process and remove it from the set.
Alternatively, keep one semaphore (or wait_queue) and one timer for each command which waits for status. Allow only one process at a time to issue this command. This is very similar to what we already have. It's much simpler. The downside is the time processes could wait for completion. Question: is this really true? won't the Host Controller serialize the execution anyway? or
can a Host Controller run two Inquiries (for example) at the same time?
The code which handles command status and the code which handles command complete will always post the command semaphore to allow another process in to send another command. Question: isn't there a limit on the number of pending commands in the Host Controller? When processes wakeup they will not post this semaphore.
Well, this is long. But I'll appreciate your insights.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org