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

[Andrew Gallatin]

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