Peter Memishian writes: > > > > instance, I was suggesting making it so that the conn_t could have at > > > most exactly one ill_t in its set, not multiple. Yes, that'd nail > > > dhcpagent down so that we could never use the single-socket approach. > > > > Well, at least until someone comes up with an improved SIOCSLIFDHCPINIT > > ;-) I think I can make this work; I'll give it a shot shortly and send > > out a new webrev. > > I spent some more time on this, and I think the semantics we'd both like > for SIOCSLIFDHCPINIT's are more naturally modeled as a socket option > (e.g., IP_DHCPINIT_IF). In particular: > > * A socket option's lifetime is clearly tied to the socket itself. > Thus, when the socket is closed (through whatever means) the > setting is lost, which is what we'd like. > > * A socket option can only assume one value at a time. That is, > the behavior of doing two consecutive IP_DHCPINIT_IF's for > different ifindexes is clear and logical -- unlike multiple > SIOCLIFDHCPINIT ioctls for different lifr_names. > > * By changing ill_dhcpinit from a bitfield to a counter (and > recording conn_dhcpinit_ill in the conn_t) it is simple to > support multiple conn_t's calling IP_DHCPINIT_IF on the same > ifindex. So there are no issues requiring all consumers of > the API to know about one another. > > What do you think?
That sounds like a clean solution to me. -- 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
