cvs commit: src/sys/arm/xscale/ixp425 ixp425_npe.c
src/sys/dev/ipw if_ipw.c if_ipwvar.h src/sys/dev/isp
isp_freebsd.h src/sys/dev/iwi if_iwi.c if_iwivar.h
src/sys/dev/mxge if_mxge.c src/sys/kern subr_firmware.c
src/sys/sys firmware.h src/sys/tools fw_stub.awk
gallatin at cs.duke.edu
Wed Feb 21 20:27:39 UTC 2007
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?
More information about the cvs-src