ndi flavors [PSARC/2009/102 Self Review]

[James Carlson]

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