From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 03:51:09 2012
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Tue, 31 Jul 2012 03:51:09 +0000 (UTC)
Received: by ghbz22 with SMTP id z22so6505070ghb.13
for <freebsd-current@freebsd.org>; 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 <wlosh@bsdimp.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warner Losh <imp@bsdimp.com>
In-Reply-To: <CACqU3MWXKKCcoBa=94Dkte=-nxn+YVGR-pjDNTSM1hkPsxkZGA@mail.gmail.com>
Date: Mon, 30 Jul 2012 21:51:05 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <B54DE5AE-E8C1-49B1-9562-53AE00FAB6BD@bsdimp.com>
References: <CACqU3MVh6shncm2Vtqj9oe_HxowWscCZ1eJf0q2F+=t_xKKBfQ@mail.gmail.com>
<CACqU3MW+BjXu+2sAgbtc+x-Mc4heowr9Bi6LAfFR5QYsMVf2Nw@mail.gmail.com>
<CACqU3MVdYwg_VriY=FgbZ20xV0Xb6CkdpZyrxRTLw60GTFJj=A@mail.gmail.com>
<201207301706.02788.jhb@freebsd.org>
<CACqU3MWXKKCcoBa=94Dkte=-nxn+YVGR-pjDNTSM1hkPsxkZGA@mail.gmail.com>
To: Arnaud Lacombe <lacombar@gmail.com>
X-Mailer: Apple Mail (2.1084)
X-Gm-Message-State: ALoCoQkhaijfzcIXuI18OT1RANRkrgX2QTOwolhL9hgM+svuK/+FC6aaJ7MG32ujW+RKXqZml75m
Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, 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
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=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 <jhb@freebsd.org> 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 <lacombar@gmail.com> =
wrote:
>>>> Hi,
>>>>=20
>>>> On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh <imp@bsdimp.com> =
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=