Date: Sun, 8 Jul 2012 23:46:51 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: newbus' ivar's limitation.. Message-ID: <CACqU3MUcbozpyqRLUS91p-%2BXANsisLoHzYpbQ8KjCr02=kMHYg@mail.gmail.com> In-Reply-To: <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> References: <CACqU3MVh6shncm2Vtqj9oe_HxowWscCZ1eJf0q2F%2B=t_xKKBfQ@mail.gmail.com> <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <CACqU3MVy65ck%2Bb8TKXwfXnBV9iuFzj%2ButRBH4Ecg6XDz3Vg5kQ@mail.gmail.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <imp@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@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 doe=
sn'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. Certai=
nly less hackish than not using them at all. Since dev0 knows the layout o=
f 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 f=
rom 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. Cur=
rently, there's no bits used in the key to define the values to be non-over=
lapping. 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 s=
cale too well. Given that there's only about a dozen or two in the tree, t=
hat's right at the moment, it wouldn't be hard to do something like:
>>>
>>> enum ivar_namespace {
>>> IVAR_PCI =3D 1,
>>> IVAR_PCCARD,
>>> IVAR_USB,
>>> etc
>>> };
>>> #define IVAR_SHIFT 16
>>>
>>> and the above could be changed to:
>>>
>>> enum pci_device_ivars {
>>> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT,
>>> PCI_IVAR_SUBDEVICE,
>>> PCI_IVAR_VENDOR,
>>> ....
>>> };
>>>
>>> and then we'd have an unambiguous key, and the bus could easily impleme=
nt multiple interfaces.
>>>
>>> but then again, most of the existing interfaces in the kernel are mutua=
lly 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 gener=
ic way to convert a key to a value and store a key on a value. I don't rea=
lly understand what you are trying to say here, perhaps an example would he=
lp 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 chil=
d's ivar when the child is created. The child's parent already gets a poin=
ter to the child when asked to do the key to value translation. Again, per=
haps an example would help here.
>>>
>>> Warner
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MUcbozpyqRLUS91p-%2BXANsisLoHzYpbQ8KjCr02=kMHYg>