Re: newbus' ivar's limitation..

On Jul 11, 2012, at 9:47 PM, Arnaud Lacombe wrote:

> Hi,
>=20
> On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <lacombar@gmail.com> =
wrote:
>> Hi,
>>=20
>> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <imp@bsdimp.com> wrote:
>>>=20
>>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>>>=20
>>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <imp@bsdimp.com> =
wrote:
>>>>>=20
>>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <imp@bsdimp.com> =
wrote:
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> So I'm not sure I understand what you are saying here.
>>>>>>>=20
>>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>> 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.
>>>=20
>>> We are talking about the ivar interface.  You are just =
misunderstanding how it is used.
>>>=20
>> yes I indeed did... silly, silly me :-)
>>=20
> 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.
>=20
> I am not even sure any driver in the tree provides more than one =
interface...
>=20
> 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.
>=20
> /me pissed.
>=20
> - Arnaud
>=20
> [0]: damn, why is it even called "newbus", this stuff is 14 years old.
> It really belongs to a museum, not production code...

I'm sorry you feel that way.

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.

acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI =
interfaces.

Warner=
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"