Date: Sun, 8 Jul 2012 20:07:52 -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: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> In-Reply-To: <CACqU3MVh6shncm2Vtqj9oe_HxowWscCZ1eJf0q2F%2B=t_xKKBfQ@mail.gmail.com> References: <CACqU3MVh6shncm2Vtqj9oe_HxowWscCZ1eJf0q2F%2B=t_xKKBfQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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 =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 =
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31A0DCE7-3B93-41BC-805A-E0B163892112>