> > > usr/src/uts/common/net/if.h > > > > > > 174: instead of "traditional interface," I suggest saying "any > > > interface." (The former makes it sound as if there are interfaces > > > on which the user can change some of the IFF_CANTCHANGE flags from > > > user space ... and that's not true.) > > > > Except that they can before SIOCSLIFNAME is set, but that's another matter > > :-O > > I'm not sure that using SIOCSLIFNAME is the key that makes it a > 'traditional' interface. > > The reason I suggested the wording change was that the text here is > confusing. The bits are additive; no interface can change these, and > IPMP ones have an additional set of reserved bits. "Traditional" > seems to exclude something.
I should've been more clear. I've accepted the wording change; I was just nitpicking ;-) > > > 601: is this equivalent to "gi_nv4 != 0"? > > > 602: and is to "gi_nv6 != 0"? > > > > No. Perhaps the comments are too terse but, gi_v4 and gi_v6 represent > > whether the IPMP group interface is plumbed for IPv4/IPv6, whereas the > > gi_nv4 and gi_nv6 counters represent the number of underlying IPv4 and > > IPv6 interfaces. For example, if one does "ifconfig ipmp0 ipmp", then > > gi_v4 will be B_TRUE, but gi_nv4 will be zero. > > Oh, ok. So you could not reasonably have gi_v4 set to B_FALSE when > gi_nv4 is greater than zero, but an empty set with gi_v4 set to B_TRUE > and gi_nv4 equal to zero *is* supported. Right. > > > usr/src/uts/common/sys/sockio.h > > > > > > 238: curious ... if we can remove them safely, why can we not reuse > > > them? > > > > Because we'd like any lingering consumers to fail, rather than silently > > take on new behavior. > > Actually, since the data size is part of the ioctl number, we could > reuse them in at least some cases ... but ok. Right, though most of the IP ioctls take a "struct lifreq" so it doesn't work as well as one might think. > My point here was that in order to break those lingering consumers, I > think we really had to judge that there simply weren't any to speak > of, because we try hard not to break working binaries. That makes > eventual reuse less of a problem. True, but this project had nothing to do with the SIOC*IFARP ioctls, which is the source of your comment above. -- meem
