newbus' ivar's limitation..

Arnaud Lacombe lacombar at gmail.com
Fri Jul 13 17:56:59 UTC 2012


Hi,

On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh <imp at 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.

 2) have a generic bus_hinted_child method which would just add a new
child to the bus.

 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.

 4) have bus_generic_detach() always ran prior to device detachment

If not already the case. There is still the same +100 direct call to
bus_generic_detach is the tree.

 5) have the bus_generic_* method be the default of their respective method

 6) have device_delete_child() called upon device detachment.

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.

Also, as a rule of thumb, if the same logic is implemented in more
than a few buses, it should be made generic and implicit.

I am lazy, I hate doing the same things over and over, not to say it
raised the likelihood of bugs' introduction...

 - Arnaud


More information about the freebsd-current mailing list