From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 11:02:43 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 EB10816A4CE; Wed, 21 Jul 2004 11:02:43 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5769C43D3F; Wed, 21 Jul 2004 11:02:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LB2fon081663; Wed, 21 Jul 2004 13:02:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 11:37:50 BST." <1090406270.7114.2.camel@builder02.qubesoft.com> Date: Wed, 21 Jul 2004 13:02:41 +0200 Message-ID: <81662.1090407761@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 11:02:44 -0000 In message <1090406270.7114.2.camel@builder02.qubesoft.com>, Doug Rabson writes : >On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote: >> In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: >> >> >The original intention was that drivers use the >> >device_busy()/device_unbusy() counter to handle these things. In some >> >cases, just calling device_busy() from fooopen() and device_unbusy() >> >from fooclose() is sufficient. >> >> That is not enough. All methods in cdevsw, and things not in cdevsw >> (clone handlers, call backs, etc etc) needs to refcount. >> >> I have a lot of this working in a tree here, and will commit it once >> I have gone over it a few more times. > >Methods in cdevsw which can't be called unless the device is opened can >rely on a single counter managed by open/close in most cases. Other >callbacks may or may not need extra handling depending on whether or not >the callback can persist past close. The problem is that if you are sleeping in for instance a read, you need to wake up the thread, and you can still only hope that it will at some point in the future do a close. That is why the devsw/cdev code is designed so that you can forego your close (and do it yourself) by destroying the cdev. You still need to evict all threads of course, but you don't need to wait (potentially for ever) for them to come back and call close. >Will you use the existing device_busy() counter or will each driver use >its own counter? device_busy doesn't work well because it cannot happen until I am already inside the driver and because there is no known relationship between cdevs and device_t's. There are three parts to it, a refcount on cdevsw which tells us if any thread is inside the driver using that route, a refcount on the individual cdev and a linkage between the two. -- 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.