From owner-freebsd-arch@FreeBSD.ORG  Wed Jul 21 12:20:36 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 07F7616A4CE; Wed, 21 Jul 2004 12:20:36 +0000 (GMT)
Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 1CCCB43D31; Wed, 21 Jul 2004 12:20:33 +0000 (GMT)
	(envelope-from dfr@nlsystems.com)
Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2])
	by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i6LCKWkM074167;
	Wed, 21 Jul 2004 13:20:32 +0100 (BST)
	(envelope-from dfr@nlsystems.com)
Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8])
	i6LCKVON069164;	Wed, 21 Jul 2004 13:20:31 +0100 (BST)
	(envelope-from dfr@nlsystems.com)
From: Doug Rabson <dfr@nlsystems.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
In-Reply-To: <82178.1090409870@critter.freebsd.dk>
References: <82178.1090409870@critter.freebsd.dk>
Content-Type: text/plain
Message-Id: <1090412431.7114.13.camel@builder02.qubesoft.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Wed, 21 Jul 2004 13:20:31 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter
	version '0.60p'
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
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2004 12:20:36 -0000

On Wed, 2004-07-21 at 12:37, Poul-Henning Kamp wrote:
> In message <1090408854.7114.8.camel@builder02.qubesoft.com>, Doug Rabson writes
> :
> 
> >> 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.
> >
> >The device_busy() counter is still simplest (as long as there is a
> >device_t at all). The implementation of devclass_delete_driver() will
> >automatically veto the unload (when its called from
> >driver_module_handler()).
> 
> The problem is that I cannot find the device_t without dereferencing
> the struct cdev (either for si_driver[12] or the dev_t) and by then
> it is too late.  There is no way we can avoid refcounting on the cdev.

Ok, so you are going to handle this in specfs (or whatever replaces
specfs)? That makes sense. Any ideas on how network interfaces should
work in this?