newbus' ivar's limitation..

[Arnaud Lacombe]

Hi,

On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe <lacombar at gmail.com> wrote:
> 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...
>
could I at least get some feedback on the proposals above ?

Thanks,
 - Arnaud