> > 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?
--
meem
