From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 03:51:09 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 BD3C21065670 for ; Tue, 31 Jul 2012 03:51:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2E68FC12 for ; Tue, 31 Jul 2012 03:51:09 +0000 (UTC) Received: by ghbz22 with SMTP id z22so6505070ghb.13 for ; Mon, 30 Jul 2012 20:51:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=sFu9+q3iJ0KvQwRqVWhzdEOuqktO2lEKgbGu99hxL3k=; b=EWeTIKwTIZj40wU/mG85Io0kX821K90BxF0JHA9OS4RWmqjljwJyuzN5DigCXWKAdP HNELp9CLCA4ivgfW8qxY0qVPXTcsZvW0grn7CMkDNGtOAdb9CiUW691x5GXZF9fvrKQ0 yBhJy9w84x7DQmMtA8x16nAYpittZ+lwefdzWqe9YnpuaQ6O7B/NhgZCvUvJsNB2z86Q mfp72OwPLiKCLbluJZHTn6C1J+4UU+RiJMNE9Ep8ncdz3mTlY6ZHzoDG5T1Dsz0tw1B8 FbTV0vmLAGMOK6KknRoryFqXBnt8oDuxsItKJa20936OJnBj/lXuUMOWPUAoA5yMy0/5 BgRw== Received: by 10.50.10.234 with SMTP id l10mr188698igb.4.1343706668439; Mon, 30 Jul 2012 20:51:08 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id dk7sm17497019igb.10.2012.07.30.20.51.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 20:51:07 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 30 Jul 2012 21:51:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201207301706.02788.jhb@freebsd.org> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkhaijfzcIXuI18OT1RANRkrgX2QTOwolhL9hgM+svuK/+FC6aaJ7MG32ujW+RKXqZml75m Cc: FreeBSD Hackers , freebsd-current@freebsd.org 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: Tue, 31 Jul 2012 03:51:09 -0000 On Jul 30, 2012, at 8:30 PM, Arnaud Lacombe wrote: > Hi, >=20 > 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, >>>=20 >>> On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe = wrote: >>>> Hi, >>>>=20 >>>> 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. >>>>>=20 >>>> I will just pass function pointers for now, if things should be = done >>>> dirty, let's be explicit about it. >>>>=20 >>>> 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() >>>>=20 >>>> this is required to be able to support dynamic loading and = attachment >>>> of hinted children. >>=20 >> I'm not sure this is a feature we want to support (to date hinted = children >> have only been created at boot time). Yes. FDT should replace hinted things as much as possible. However, = FDT is an in for a penny, in for a pound technology like acpi: you more = or less have to use it for everything. >>>> 2) have a generic bus_hinted_child method which would just add a = new >>>> child to the bus. >>=20 >> Possibly, but hinted children are intentionally opt-in and not = enabled >> by default. Yes. I made it that way on purpose because most buses are enumerated, = and things are moving that way even in the embedded world, or at least = seemed that way when I was doing it. Either the buses are enumerated, = like PCI or some of the silicon frameworks, or you used FDT, which is = also fully enumerated. >>>> 3) have bus_enumerate_hinted_children() and bus_generic_attach() >>>> always ran on device attachment. >>>>=20 >>>> There is current +100 explicit call to bus_generic_attach() in the >>>> sys/dev/ tree. This should be done always and implicitly. >>=20 >> 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(). Yes. This was specifically due to how different buses enumerate. >>>> 4) have bus_generic_detach() always ran prior to device detachment >>=20 >> Similar. >>=20 >>>> 5) have the bus_generic_* method be the default of their respective >> method >>=20 >> 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. It has been a mistake to not more aggressively investigate this line of = coding. >>>> 6) have device_delete_child() called upon device detachment. >>=20 >> 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. It is almost always horrifically wrong. >>>> 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. >>=20 >> 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). >>=20 > 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. FDT handles the enumeration problem. FreeBSD's lack of a decent gpio, = pinctl, pinmux and other infrastructure are much bigger issues. At = least those are the real issues that I'm running into working on the = Atmel SoCs and bringing FDT to them. Hinted buses really have no place = in an FDT world. None. They are an ugly hack that were intended to be = a stop-gap until something better than hints came along. If you are = trying to use them in an FDT world, you are likely doing something = horribly wrong. > I am yet to see a robust approach to the various problem I submitted. That's because you're asking us to pound screws with a hammer. For the = things you've complained about, we really need to have better GPIO = infrastructure, a better pin control and pin mux infrastructure, etc. = We lack that right now, which is why you're trying to shoe-horn the FDT = connections into a newbus world and complaining that everything sucks = because it is a poor fit. I'd suggest that different mechanisms are = necessary. >> For example: >> static void >> ipmi_isa_identify(driver_t *driver, device_t parent) >> { >> struct ipmi_get_info info; >> uint32_t devid; >>=20 >> if (ipmi_smbios_identify(&info) && info.iface_type !=3D = SSIF_MODE && >> device_find_child(parent, "ipmi", -1) =3D=3D NULL) { >> ... >> BUS_ADD_CHILD(parent, 0, "ipmi", -1); >> } >> } >>=20 > 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. Perhaps, but design patterns can be just as useful for extremely short = code snippets. Warner=