Re: newbus' ivar's limitation..

Hi,

On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <lacombar_at_gmail.com> wrote:
> Hi,
>
> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <imp_at_bsdimp.com> wrote:
>>
>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>>
>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <imp_at_bsdimp.com> wrote:
>>>>
>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <imp_at_bsdimp.com> wrote:
>>>>>>
>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>>>>>> than one interface, and one of its child has need to use more than one
>>>>>>> interface, each interfaces cannot register, concurrently, its own
>>>>>>> ivar. While I try to always have a single child per
>>>>>>> interface/resource, I need to keep some compatibility with the old way
>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and
>>>>>>> userland). So, it would have been nice if ivar had been per-interface,
>>>>>>> not global and unique to one device.
>>>>>>
>>>>>> There's one pointer for the ivars.  The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus.  So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done.
>>>>>>
>>>>>> So I'm not sure I understand what you are saying here.
>>>>>>
>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
>>>>> use both interfaces. There is no generic way for dev0 to export
>>>>> independent ivars for both interface. For now, I restricted the
>>>>> function of the second interface not to need ivar, but that's kind of
>>>>> hackish.
>>>>
>>>> Only if the IVARs for interface A and interface B have overlapping values.  If the Ivar keys don't overlap, then there's no problems at all.  Certainly less hackish than not using them at all.  Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all.  It would return the values from A from the right part of the ivar, and those from B in the right part.  Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here.
>>>>
>>> I think we should not be talking about the same API here. I have no
>>> idea what you mean by "the key to value translation", nor "Ivar
>>> numbers". What I refer to is that device_set_ivars() /
>>> device_get_ivars() acts on a single instance variables from `struct
>>> device': `ivars'. In that case, I do not really see how to set that
>>> specific field to two distinct values for each interfaces.
>>
>> We are talking about the ivar interface.  You are just misunderstanding how it is used.
>>
> yes I indeed did... silly, silly me :-)
>
Actually, no. I wasn't that silly, neither was I misunderstanding
anything beside how *you* wanted it to be used, which is, I sorry to
say, unacceptable. The last thing I want is to pollute an interface
with a single-purpose, hand-crafted, bus. I was to just throw away all
that ivar stuff and go into hinted child configuration for now,
waiting for FDT... but of course, I figured out after a few hours that
hinted child attachment requires `bus_hinted_child' to be set in the
parent, as does bus_enumerate_hinted_children() / bus_generic_attach()
to explicitly pollute my code. All this stuff should be done
implicitly to support N:1 interfaces/client relationship. N
*independent* interfaces being provided by a single driver; of course,
I'm not even going back to require those interface being provided by
multiple drivers, it is already a dead end.

I am not even sure any driver in the tree provides more than one interface...

For whatever reason, I am more and more thinking that this all
new-bus[0] stuff is *way* overkill, static, bloated at will, and
missing critical features; a huge PITA to use, for the intended
purpose.

/me pissed.

 - Arnaud

[0]: damn, why is it even called "newbus", this stuff is 14 years old.
It really belongs to a museum, not production code...