Date: Fri, 3 Dec 1999 15:46:45 +0100 (CET) From: Nick Hibma <hibma@skylink.it> To: Doug Rabson <dfr@nlsystems.com> Cc: FreeBSD Newbus Mailing List <new-bus@FreeBSD.ORG> Subject: Re: PCCARD eject freeze (was Re: your mail) Message-ID: <Pine.BSF.4.20.9912031544320.268-100000@henny.jrc.it> In-Reply-To: <Pine.BSF.4.10.9912030917570.23924-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > DEVICE_DETACH called from device_delete_child wakes up all the sleepers > > and exits. The sleepers actually start running after DEVICE_DETACH has > > finished and the softc has been blown away by the device_delete_child > > that followed. > > > > I think this cries for a loop: Call detach and if EAGAIN is returned > > make sure sleepers can wake up and exit, and then try again. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I have no idea how this 'wait for sleepers to have run' could be > > implemented, but this is I think the crucial part. > > I think that the solution is probably to use the busy counter more > effectively. No, as the device is gone and the driver should detach from it. What other mechanism is there to let the driver know that the physical device is gone? We can either solve this in a generic fashion or otherwise people will do things like, call detach and remember that it was called, then start detaching and, after finishing, the driver detaches itself with DEVICE_DETACH. It gets messy. I prefer a generic mechanism to let the driver know that it should go away and a detach method to make it go away now. Or the EAGAIN solution given above. Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.9912031544320.268-100000>