From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 21:14:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02374106564A; Mon, 30 Jul 2012 21:14:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B0B228FC1A; Mon, 30 Jul 2012 21:14:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0E555B944; Mon, 30 Jul 2012 17:14:58 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 30 Jul 2012 17:06:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207301706.02788.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jul 2012 17:14:58 -0400 (EDT) Cc: FreeBSD Hackers , Warner Losh , Arnaud Lacombe Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:14:59 -0000 On Tuesday, July 17, 2012 2:03:14 am Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > >> [..] > >> Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > >> > > I will just pass function pointers for now, if things should be done > > dirty, let's be explicit about it. > > > > Now, the hinted device attachment did work quite smoothly, however, I > > would have a few suggestion: > > 1) add a call to bus_enumerate_hinted_children() before the call > > DEVICE_IDENTIFY() call in bus_generic_driver_added() > > > > this is required to be able to support dynamic loading and attachment > > of hinted children. I'm not sure this is a feature we want to support (to date hinted children have only been created at boot time). > > 2) have a generic bus_hinted_child method which would just add a new > > child to the bus. Possibly, but hinted children are intentionally opt-in and not enabled by default. > > 3) have bus_enumerate_hinted_children() and bus_generic_attach() > > always ran on device attachment. > > > > There is current +100 explicit call to bus_generic_attach() in the > > sys/dev/ tree. This should be done always and implicitly. No. One of the problems is that different busses want to do it at different times. It is usually done last, but some buses may want to do additional work after the bus_generic_attach(). > > 4) have bus_generic_detach() always ran prior to device detachment Similar. > > 5) have the bus_generic_* method be the default of their respective method No. However, what would be a good idea (and one thing I've had on my list), is to create a "bus_generic" driver that uses the bus_generic_* methods for all it's methods and let bus drivers inherit from that to get the generic methods if they are appropriate. If you do this, I would also add a second "bus_generic_rl" that inherits from "bus_generic" but uses the generic resource list methods for resources. > > 6) have device_delete_child() called upon device detachment. No. This is for a bus to decide. This would be horrifically wrong for things like kldunloading a PCI device driver. Just because you unload a driver (so that it detaches from devices) does not mean those physical devices have gone away. > > As a rule of thumb, when a kld is unloaded there should not be any > > remains of anything built previously. Without device_delete_child() or > > proper singleton implementation, multiple load/unload sequence of bus > > will attempt to attach multiple version of a child, even if the single > > child was added prior to the bus_generic_attach() call. Hinted devices should perhaps be removed, yes. However, what other drivers often do is use a singleton approach instead (despite your claim that they don't). For example: static void ipmi_isa_identify(driver_t *driver, device_t parent) { struct ipmi_get_info info; uint32_t devid; if (ipmi_smbios_identify(&info) && info.iface_type != SSIF_MODE && device_find_child(parent, "ipmi", -1) == NULL) { ... BUS_ADD_CHILD(parent, 0, "ipmi", -1); } } -- John Baldwin