Re: newbus' ivar's limitation..

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.

 - Arnaud

> Warner
>
>> - Arnaud
>>
>>> 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,
>>> ....
>>> };
>>>
>>> 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:
>>>
>>> enum ivar_namespace {
>>>        IVAR_PCI = 1,
>>>        IVAR_PCCARD,
>>>        IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>>    PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT,
>>>    PCI_IVAR_SUBDEVICE,
>>>    PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces.
>>>
>>>> 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.
>>>
>>> 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.
>>>
>>>> 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....
>>>
>>> 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.
>>>
>>> Warner
>