"David S. Miller" wrote: > That little weird thing called binary compatibility. It is possible to > support IFF_PROMISC until the end of time, because the NIC promisc bit > is similarly binary. The change I propose is to regain what we have > already lost. [sigh, I meant to have said that we can support IFF_PROMISC for SIOCGIFFLAGS -only-, until the end of time. I agree with you that SIOCSIFFLAGS+IFF_PROMISC clearly is unsupportable.] > How do we handle SIOCSIFFLAGS then? > > Do we just cancel out all the counts if we are asked to clear the > IFF_PROMISC bit? That is definitely wrong, it blows away the entire > intention of having a count in the first place. Or do we make it act > as a "decrement 1 count"? That sounds equally lousy to me. > > We can't just ignore the request by your very arguments. Right? Correct. First, a question. Is SIOCSIFFLAGS to be 100% deprecated, or just the twiddling of IFF_PROMISC bit? My preferred way would be to return -EOPNOTSUPP for SIOCSIFFLAGS. The cases for which this is returned is dependent on the answer to the question I just asked. For SIOCGIFFLAGS, my preference would be to manage the IFF_PROMISC bit at a lower level than the reference count, at the time when promisc is actually enabled or disabled. Thus IFF_PROMISC will reflect the true state of the hardware, while also maintaining binary compatibility. Jeff -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
