re: CVS commit: src/sys/dev/bluetooth

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Mon, 2 Jan 2012, matthew green wrote:

> > Just dropping the lock and reaquiring it around the sc_input/sc_feature
> > call is probably not exactly the right thing to do though (as the stack
> > will not be aware that that might have happened and data structures could
> > have changed), it really should disassociate from the context, maybe doing
> > the call from a callout or separate task instead. (want that kcont(9) now
> > pretty please, gimpy :)
>
> i considered attempt to drop and allow re-taking the bt_lock like you
> have described, but i didn't know if it was safe, and there's a lot of
> code to read to check.  maybe with the above info you can suggest a
> better way to solve this problem.

Yes I think even if analysis showed it was safe currently, doing that is
not safe in the long term..  The correct thing to do is to handle the
upcall in a separate context. I can look into it later but I've got to go
catch a train in a minute (and, will be without Bluetooth keyboard for a
few days :)

iain