The latest bit here is a chicken and egg problem. For various reasons
we might need to know the map between a dev_t and an instance number.
And, we might want to know that information *before* the dev_t is
actually in use, or even before the driver is attached.
The framework uses getinfo(9e) to provide this map. But Nemo's
getinfo(9e) is rather brain dead, and for dev_t's that are clone devices
just assumes ddi_get_instance() == PPA == minor - 1.
For multiport devices, this is obviously quite wrong.
I'm still refusing to give up on fixing this, because I think the need
to support multiple port devices is real, and without this there is no
method to support such devices available without using the highly
undocumented Nexus interfaces.
So we need a way fro a driver to supply its own getinfo(9e) override.
But it needs to be able to lookup the devinfo() node for an open
stream. (E.g. dld_finddevinfo()).
What I'm thinking is a simple interface that the MAC drivers can call to
determine the PPA associated with a dev_t:
mac_get_ppa(dev_t dev);
For open files, this just does dld_finddevinfo().
For clone opens (minordev = PPA + 1) it would just return (getminor(dev)
- 1).
Looking up the dev_info_t * associated with a PPA would then be left as
an exercise for the device driver.
Of course, Nemo can still supply a stock getinfo(9e) implementation. It
should be modified to warn if getinfo(9e) != NULL *and*
mregp->m_instance != ddi_get_instance(mregp->m_dip) *and*
mregp->m_instance > 0.
Thoughts?
- Garrett
Garrett D'Amore wrote:
Peter Memishian wrote:
> Not for all physical links. It is perfectly reasonable to have a
> physical link where m_instance != ddi_get_instance(). Such as
when you > have multiple PPAs per port. (I take m_instance to mean
the PPA.)
In what cases today so we have multiple PPAs per port? (The VLAN
hack is
a PPA overload and not a real PPA.)
Sorry, I should have said "per devinfo". The cases that this comes up
in are cases where the chip vendor puts multiple ethernet ports on a
single PCI function. Marvell Yukon 2 chips can do this, and so can
devices from Mellanox. I'm faced with this problem with a very real
device that has this concern.
- Garrett
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
