> it's to allow the use during reset of a given driver's > standard functions that normally must qlock, to avoid requiring two copies > of them, with and without the qlock. > > after reset, it's illegal to call qlock without a process (notably > in an interrupt function), as it previously was.
I'm willing to credit the validity of this, but I believe then that it ought to be more explicit. It seems to me that having a situation where a panic can ensue if a lock is already taken is too risky. Is it possible to count the instances of such qlock() invocations in the present kernel code and find out how common the problem really is? Or should one simply treat such invocations as innocuous and just omit connecting a user process to the queue when no user process is specified, if the lock is taken? That sounds positively explosive! ++L
