From owner-freebsd-new-bus@FreeBSD.ORG Thu Mar 18 01:13:46 2004 Return-Path: Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE10616A4CE; Thu, 18 Mar 2004 01:13:46 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25B4943D31; Thu, 18 Mar 2004 01:13:46 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2I9DY9L084857; Thu, 18 Mar 2004 09:13:34 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-new-bus@freebsd.org Date: Thu, 18 Mar 2004 09:13:33 +0000 User-Agent: KMail/1.6.1 References: <20040318080230.GA87270@gvr.gvr.org> In-Reply-To: <20040318080230.GA87270@gvr.gvr.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403180913.33873.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: Guido van Rooij cc: new-bus@freebsd.org Subject: Re: ppbus probe problem X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 09:13:47 -0000 On Thursday 18 March 2004 08:02, Guido van Rooij wrote: > As the newbus gurus, I hope you can shed a light on the following: > I am trying to resurrect tw.c into current. While modifying it, > I came across a weird problem. If you load/unload a ppbus > driver (if at all possible), each additional load/unload > leads to an additional probe the next time you load that driver. > E.g, if you add a printf to the probe function in vpo.c, you see: > > command: dmesg > beck# kldload ./vpo.ko vpo probe called > beck# kldunload ./vpo.ko > beck# kldload ./vpo.ko vpo probe called > vpo probe called > beck# kldunload ./vpo.ko > beck# kldload ./vpo.ko vpo probe called > vpo probe called > vpo probe called > > etc. > > Someone suggested that the identify function was responsible for > this: > static void > vpo_identify(driver_t *driver, device_t parent) > { > > BUS_ADD_CHILD(parent, 0, "vpo", -1); > } > > Nowhere is the child removed from the parent at detach (also there is > no BUS_REMOVE_CHILD method). You can use device_delete_child(). The reason BUS_ADD_CHILD exists is to give the parent a chance to initialise child instance variables. > > What is the correct way to fix the probe call incrementing problem? I would use something like: static void vpo_identify(driver_t *driver, device_t parent) { device_t dev; dev = device_find_child(parent, "vpo", 0); if (!dev) BUS_ADD_CHILD(parent, 0, "vpo", -1); }