Christopher Horne writes:
> Associated with each device node is private data that may be
> accessed via ddi_[gs]et_private_state(9F). The meaning of that data
I can't find such a thing in Solaris, so I'm going to guess that you
actually meant ddi_[gs]et_driver_private(9F). Is that right?
> The proposal is to allow a nexus driver to declare, at attach time,
> how many flavors of children they support and to ask the DDI
> framework to create private pointer storage for any flavors beyond
> the standard vanilla flavor (which uses the existing
> ddi_[gs]et_private_state(9F) private data storage mechanism).
This may well be a silly question, but please bear with me, as I'm a
little confused by this proposal.
In the current system, I believe I would do something like this for
flavored children:
myp = ddi_get_driver_private(dip);
switch (myp->my_flavor) {
case MY_FLAVOR_A: {
my_flavor_a_t *myap = myp->my_flavptr;
...
In other words, a common structure (used with the existing private
data area mechanism) plus a discriminated type for the "flavor" part
(an enum plus either a void pointer or a union).
With this proposed new system, that code seems to become:
myp = ddi_get_driver_private(dip);
switch (ndi_flavor_get(dip)) {
case MY_FLAVOR_A: {
my_flavor_a_t *myap = ndi_flavorv_get(dip);
...
I'm thus confused about how this is a better solution, and I must be
missing something. At most, it seems like I could forgo the initial
ddi_get_driver_private call (if I don't need the common data for some
reason), but I still get two new calls in exchange. Can you explain
what the new solution does that the simpler one doesn't?
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
