Luigi Rizzo writes: > On Wed, Feb 21, 2007 at 01:22:28PM -0500, Andrew Gallatin wrote: > > > > Luigi Rizzo writes: > ,,, > > > i am not sure i follow you here... > > > Of course when you drop the lock you risk that the underlying > > > data structure is manipulated (or in the worst case freed), > > > but usually you can avoid this with something like > > > > > > <while locked> > > > sc->flags |= LEAVE_ME_ALONE > > > UNLOCK > > > > Sorry, I hadn't noticed that iwi set a flag like that. I was > > not everywhere. i am sure that there are parts that are not protected.
That's the kind of thing I'm afraid of. > > I just think it would be safer, and less hacky to be allowed to hold > > a driver mutex while potentially sleeping in the firmware code (and in > > i am no expert here, but in some sense, the mutex argument to msleep > is there exactly for that reason. Maybe the problem is that sometimes > you need more than one mutex ? The problem is that msleep() drops the mutex when you sleep, so the lock is dropped while you sleep, and you are back to flag hacks. > In any case i think we should relabel the thread or potentially > interested people will miss the content being misled by the subject! I'm satisfied to let it drop, now that I've vented a little :) Back on, more or less, track: Can you commit my hack to the kernel linker which lets firmware(9) work from attach() without deadlock? Thanks, Drew _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
