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
