Date: Mon, 30 Jul 2012 17:06:02 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Warner Losh <imp@bsdimp.com>, Arnaud Lacombe <lacombar@gmail.com> Subject: Re: newbus' ivar's limitation.. Message-ID: <201207301706.02788.jhb@freebsd.org> In-Reply-To: <CACqU3MVdYwg_VriY=FgbZ20xV0Xb6CkdpZyrxRTLw60GTFJj=A@mail.gmail.com> References: <CACqU3MVh6shncm2Vtqj9oe_HxowWscCZ1eJf0q2F%2B=t_xKKBfQ@mail.gmail.com> <CACqU3MW%2BBjXu%2B2sAgbtc%2Bx-Mc4heowr9Bi6LAfFR5QYsMVf2Nw@mail.gmail.com> <CACqU3MVdYwg_VriY=FgbZ20xV0Xb6CkdpZyrxRTLw60GTFJj=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, July 17, 2012 2:03:14 am Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> > Hi,
> >
> > 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.
> >>
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207301706.02788.jhb>