From owner-freebsd-arch@FreeBSD.ORG Tue May 11 08:08:13 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 876B116A4CE; Tue, 11 May 2004 08:08:13 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1740E43D48; Tue, 11 May 2004 08:08:12 -0700 (PDT) (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 i4BF85kM044349; Tue, 11 May 2004 16:08:06 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i4BF7oON021084; Tue, 11 May 2004 16:08:05 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1084288070.13434.26.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 11 May 2004 16:07:50 +0100 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw 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: Tue, 11 May 2004 15:08:13 -0000 On Tue, 2004-05-11 at 15:39, Dag-Erling Smørgrav wrote: > I've found what I believe is a serious flaw in newbus. > > When a driver that has a DEVICE_IDENTIFY method is loaded, the > identify method is called. If it finds supported hardware, it uses > BUS_ADD_CHILD to notify the parent bus of the presence of that > hardware. At some later point, during a bus rescan, the attach > routine is called for each device that was identified in this manner. > > When the driver is unloaded, the device is detached, but it remains on > the bus's list of child devices. The next time the module is loaded, > its DEVICE_IDENTIFY method is called again, and incorrectly adds a > second child device to the bus, because it does not know that one > already exists. > > There is no way for DEVICE_IDENTIFY to check if a matching child > already exists on the bus, or for the module's event handler to unlist > the child when unloading. > > The first time you load the module, you get foo0; the second time, you > get foo0 *and* foo1 referencing the same physical device; the third > time, you get foo0, foo1, and foo2, etc. > > I've also seen something similar happen when multiple ndis drivers are > loaded; the first one re-attaches to the hardware when the second one > is loaded. This is a known problem. The 'right' solution is to add a new static method to the device interface which is the opposite of IDENTIFY (e.g. UNIDENTIFY). One way to get around the problem is to do something like: void foo_identify(driver_t *driver, device_t parent) { device_t child; child = device_find_child(parent, "foo", 0); if (!child) BUS_ADD_CHILD(parent, 0, "foo", 0); } Alternatively, you can add a module handler: static device_t foo; void foo_identify(driver_t *driver, device_t parent) { foo = BUS_ADD_CHILD(parent, 0, "foo", -1); } ... int foo_module_handler(struct module *mod, int what, void *arg) { if (what == MOD_UNLOAD && foo) device_delete_child(device_get_parent(foo), foo); } ... DRIVER_MODULE(foo, bar, foo_driver, foo_devclass, foo_module_handler, 0);