From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 31 02:30:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED1EF106564A; Tue, 31 Jul 2012 02:30:20 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0FADE8FC1D; Tue, 31 Jul 2012 02:30:19 +0000 (UTC) Received: by lbon10 with SMTP id n10so4656732lbo.13 for ; Mon, 30 Jul 2012 19:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/w03AC2jsU/TVLFYBXLFpLq7Zn9yq1Gd6j7wp3hqFv0=; b=PXdKsxYRjXvb66GtUG3zmvhVOTpD0wsTbKFPAkIQTPRe508PgvROzuWhDqp7vI1qzp Jht5xFu24jksSZX19Cc7kwigofOYcD3mPSkLAd00qyW3U/PWHTn9v8xJ8WFfaRX9Un0Y RqalxVypJEEQ/ZWoh9OBJOjrqmINfaXvV/bgdme7iaNzlevp84O28+zIYkMo+XRMUdhf yHrAM45fXo4i1Ifnhp77nl+U8TTiS7j5BFRvL6SVL0t6JfsvFYItVej5s2ujmP/ik3FC SdBi4CKcXLsP6ryUnXUXnnhg1hUzSGouHgowSijxdzpWectuvGe2ODWPVikNzG7GJPMn 7APA== MIME-Version: 1.0 Received: by 10.152.103.109 with SMTP id fv13mr13341493lab.33.1343701818802; Mon, 30 Jul 2012 19:30:18 -0700 (PDT) Received: by 10.114.13.68 with HTTP; Mon, 30 Jul 2012 19:30:18 -0700 (PDT) In-Reply-To: <201207301706.02788.jhb@freebsd.org> References: <201207301706.02788.jhb@freebsd.org> Date: Mon, 30 Jul 2012 22:30:18 -0400 Message-ID: From: Arnaud Lacombe To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:30:21 -0000 Hi, On Mon, Jul 30, 2012 at 5:06 PM, John Baldwin wrote: > 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). > FreeBSD's newbus device framework already sucks (as in "too static"/"inflexible"), making it sucks even more (as in "more static"/"more inflexible") might not be the wisest approach... This is no longer the 90'. The good old enumerating-buses, tree-based, model is to be relegated to a corner-case of the computer world with profusion of embedded, non-enumerating, highly integrated, highly interconnected, highly custom SoCs. I am yet to see a robust approach to the various problem I submitted. > 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); > } > } > duplicated code doing the exact same abstract, hardcoded, function, all over the tree, absolutely unacceptable, if not a blatant proof of failure of what should be made generic, if not fully dynamic. - Arnaud