Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Jul 2012 23:26:00 -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:  <CACqU3MVy65ck%2Bb8TKXwfXnBV9iuFzj%2ButRBH4Ecg6XDz3Vg5kQ@mail.gmail.com>
In-Reply-To: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com>
References:  <CACqU3MVh6shncm2Vtqj9oe_HxowWscCZ1eJf0q2F%2B=t_xKKBfQ@mail.gmail.com> <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 t=
he ivar looks like, because the interface is totally private to the bus.  S=
o 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.

 - Arnaud

> The problem, more basically, is that the ivar keys are not unique.  Curre=
ntly, there's no bits used in the key to define the values to be non-overla=
pping.  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 sca=
le too well.  Given that there's only about a dozen or two in the tree, tha=
t'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 implement=
 multiple interfaces.
>
> but then again, most of the existing interfaces in the kernel are mutuall=
y 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 reall=
y 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 p=
roblem 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 pointe=
r to the child when asked to do the key to value translation.  Again, perha=
ps an example would help here.
>
> Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MVy65ck%2Bb8TKXwfXnBV9iuFzj%2ButRBH4Ecg6XDz3Vg5kQ>