From owner-freebsd-hackers Wed Aug 11 7: 6:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 2AE5015514 for ; Wed, 11 Aug 1999 07:06:51 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id QAA27835; Wed, 11 Aug 1999 16:03:46 +0200 (MET DST) Date: Wed, 11 Aug 1999 16:03:32 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Questions on new-bus source code In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > (2) I guess that the probe process of all devices on the tree is triggered > by root_bus_configure() in subr_bus.c. It is done from top to bottom, > i.e. the probe process should be propagated down the device tree from > root_bus. Am I right? How does this tree structure achieve the dynamic > feature of device configuring (adding/removing devices on the fly)? When the loaded module registers itself as a driver in a devclass, all the non-attached devices are probed by calling the method BUS_DRIVER_ADDED (in devclass_add_driver). Devices that are already attached are not detached forcefully. There is still some discussion going on on whether a driver needs to give up a device when a better fitting driver is loaded (a stub versus a full blown driver for a device). See also the listed methods for busses (sys/kern/bus_if.m) and for devices (sys/kern/device_if.m). Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message