"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 Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com