Date: Sun, 8 Jul 2012 22:39:03 -0600 From: Warner Losh <imp@bsdimp.com> To: Arnaud Lacombe <lacombar@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: newbus' ivar's limitation.. Message-ID: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> In-Reply-To: <CACqU3MWpBNYgMJ-9Cm5_5udLZynraWCP_TTAaBdV4py1xqt%2BXQ@mail.gmail.com> References: <CACqU3MVh6shncm2Vtqj9oe_HxowWscCZ1eJf0q2F%2B=t_xKKBfQ@mail.gmail.com> <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <CACqU3MWpBNYgMJ-9Cm5_5udLZynraWCP_TTAaBdV4py1xqt%2BXQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 8, 2012, at 9:59 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
>> 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
> ok, I think I got it now. You and I are exactly saying the same thing,
> just in different terms; there is no way to currently specify multiple
> independent (/overlapping) ivars in a child...
There's no way to support overlapping IVAR keys, yes. However, if you =
are designing the ivars for multiple inheritance, then you'll need to =
make them non-overlapping. Thankfully, this is trivial to do.
Warner
Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4>