Re: newbus' ivar's limitation..

On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:

> 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.

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.

Warner

> - Arnaud
>=20
>> The problem, more basically, is that the ivar keys are not unique.  =
Currently, there's no bits used in the key to define the values to be =
non-overlapping.  For example:
>> enum pci_device_ivars {
>>    PCI_IVAR_SUBVENDOR,
>>    PCI_IVAR_SUBDEVICE,
>>    PCI_IVAR_VENDOR,
>> ....
>> };
>>=20
>> We could easily reserve the upper 16-bits of this field to be that =
key.  This value could then be used to differentiate them.  But this =
wouldn't scale too well.  Given that there's only about a dozen or two =
in the tree, that's right at the moment, it wouldn't be hard to do =
something like:
>>=20
>> enum ivar_namespace {
>>        IVAR_PCI =3D 1,
>>        IVAR_PCCARD,
>>        IVAR_USB,
>> etc
>> };
>> #define IVAR_SHIFT 16
>>=20
>> and the above could be changed to:
>>=20
>> enum pci_device_ivars {
>>    PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT,
>>    PCI_IVAR_SUBDEVICE,
>>    PCI_IVAR_VENDOR,
>> ....
>> };
>>=20
>> and then we'd have an unambiguous key, and the bus could easily =
implement multiple interfaces.
>>=20
>> but then again, most of the existing interfaces in the kernel are =
mutually exclusive, so you could implement this just for your new =
interfaces.
>>=20
>>> Unless I am mistaken, ivar are the only way for a parent can =
transmit
>>> information to a child. I can not simply implement a new METHOD to =
get
>>> that ivar as the device implements multiple time the same function
>>> (actually, up to 4 time for one, 3 for the other, with possible
>>> crossovers...), each one physically distinct. Each child is being =
tied
>>> to a pair. Thus, I need to pass each child discriminator(s) for each
>>> interfaces right after having been *created*, which cannot be done
>>> later on. Of course, it is out-of-question to have crossover in the
>>> interfaces definitions.
>>=20
>> ivars are but one way to communicate this.  However, they are the =
generic way to convert a key to a value and store a key on a value.  I =
don't really understand what you are trying to say here, perhaps an =
example would help illustrate what you are trying to do, since I don't =
quite understand the problem here.
>>=20
>>> The best way I could achieve this currently is to pass the child's
>>> device to its parent, and do a lookup based on that pointer to get
>>> information I need, but erk....
>>=20
>> That doesn't make any sense.  The child's parent already sets that =
child's ivar when the child is created.  The child's parent already gets =
a pointer to the child when asked to do the key to value translation.  =
Again, perhaps an example would help here.
>>=20
>> 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"