[Top] [All Lists]


To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: IFF_PROMISC bug?
From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Wed, 13 Feb 2002 03:44:57 -0500
Cc: ak@xxxxxxx, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, kuznet@xxxxxxxxxxxxx
Organization: MandrakeSoft
References: <> <> <> <>
Sender: owner-netdev@xxxxxxxxxxx
"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     |             -

<Prev in Thread] Current Thread [Next in Thread>