[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] bug in COMMAND_COMPLETE and COMMAND_STATUS events processing




Hi Oliver,

Only the process calling the HCI command will be blocked. This will not be different than today where the calling process is put to sleep with interruptible_sleep_on and woken by wake_up_interruptible. Other applications can call the same HCI command but will be blocked until their response arrives.
An interrupt with an incoming connection request (or whatever) can occur at any time and interrupt whatever we are doing for the moment. This isn't blocked by an application sleeping on a wait_queue.

HCI is a bit special since it can take a while to finish. Therefore it has its own wait queue.

We don't see a need for non-blocking HCI commands but you are welcome to motivate why they should be so. It would however require major changes in the code.


Regards,
Johan

Axis Bluetooth Team


-----Original Message-----
From: Oliver Kasten [mailto:kasten@xxxxxxx.ch]
Sent: Monday, December 04, 2000 4:06 PM
To: Johan Zander
Cc: bluetooth-dev@xxxxxxx.com
Subject: Re: [bluetooth-dev] bug in COMMAND_COMPLETE and COMMAND_STATUS
events processing


Johan Zander wrote:
> 
> Oliver, thanks!
> 
> We are currently working on HCI and this is fixed for the upcoming
> release. We are also fixing several possible race situations which
> might occur when running multipoint.
> 
> We want all hci commands that are triggered from btd to block, but

hmm, i'm not an outspoken friend of blocking calls. will the stack
itself be able to handle events (e.g. incoming data, etc.) during a
blocking user call?
have you considered the multipoint scenario with arbitrary apps using
the stack? for example, the inquiry command may take up to 62 seconds
(if i remember correctly). other devices may send during that time. will
there be a (non-)blocking "recevive" in the layers above l2cap?

actually, i want all commands (hci and l2cap) to be non blocking in
callback style. do you see any chance on integating both approaches or
will we be working on different source branches?

> since the Ericsson modules (since P9A) sends the reply on the new
> baudrate we can't have set_ericsson_baudrate() to block. We now it's
> ugly but we don't have a better solution but to bypass the command
> queue.

how about this? insert the set baudrate command into the command queue
as a regular command through send_cmd(). after sending the command to
the bt-device through bt_write_lower_driver() in send_cmd() check if it
was a set-ericsson-baudrate cmd, and if so call a function in user space
that sets the baudraute of the host uart accordingly (e.g. a
user-registered callback or exported function in btd). proceed with
send_cmd()...

olli*

-- 
Oliver Kasten                                phone: +41/ 1/ 63-2 06 63
ETH-Zurich                                     fax: +41/ 1/ 63-2 16 59
Haldeneggsteig 4, IFW D48.1                  email: kasten@xxxxxxx.ch
CH-8092 Zuerich, Switzerland           http://www.inf.ethz.ch/~kasten/
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com