Re: newbus' ivar's limitation..

On Mon, 2012-07-30 at 17:06 -0400, John Baldwin wrote:
> 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_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.
> 
> I'm not sure this is a feature we want to support (to date hinted children
> have only been created at boot time). 

It seems to me that the bus should be in control of calling
bus_enumerate_hinted_children() at whatever time works best for it.
Also, shouldn't it only ever be called once?

The comment block for BUS_HINTED_CHILD in bus_if.h says "This method is
only called in response to the parent bus asking for hinted devices to
be enumerated."  I think one of the implications of that is that any
given bus may not call bus_enumerate_hinted_children() because it may
not be able to do anything for hinted children.  Adding a
"hint.somedev.0.at=somebus" and then forcing the bus to enumerate hinted
children amounts to forcing the bus to adopt a child it may not be able
to provide resources for, which sounds like a panic or crash waiting to
happen (or at best, no crash but nothing useful happens either).

-- Ian