Date: Wed, 08 Sep 2004 23:10:44 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb ugen.c Message-ID: <47831.1094677844@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 08 Sep 2004 14:58:46 MDT." <20040908.145846.71090050.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20040908.145846.71090050.imp@bsdimp.com>, "M. Warner Losh" writes: >It turns out that Brian's change typically is the same as the old >code. However, there are a few cases where it isn't: > >(1) Where the application doesn't close the device when it gets an > error. Stupid application, I know, but in this case the device > never detaches. This is one of the things that caused our > appliction to die with the new code, but not the old code. phk's > work with deadfs and dev_t ref counting may help here. The intent is that devfs will act as isolator for drivers which disintegrate, in other words, even if the application does not close and go away, devfs will make it go away from the drivers point of view. The refcounting necessary is not in place currently, I ran into a funky detail and got derailed. Problem is that we can't just declare that destroy_dev() will evict all threads because we do not know what they might be sleeping on/for while they are inside the driver. A two phase scheme is necesary where the driver first blocks future entry, then evicts any threads already in there and then calls destroy_dev(). I've done some work on this based on the phk_tty branch in p4, but it was pretty exploratory. The challenge with ttys is that the struct tty might referenced as controlling tty even after the last close. Once I get this sorted out, I'll aim at getting phk_tty MFP4'ed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47831.1094677844>