From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 21:10:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50B5F16A4CE; Wed, 8 Sep 2004 21:10:51 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8923043D46; Wed, 8 Sep 2004 21:10:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i88LAig7047832; Wed, 8 Sep 2004 23:10:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2004 14:58:46 MDT." <20040908.145846.71090050.imp@bsdimp.com> Date: Wed, 08 Sep 2004 23:10:44 +0200 Message-ID: <47831.1094677844@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: green@FreeBSD.org cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb ugen.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 21:10:51 -0000 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.