"David S. Miller" wrote: > > From: Jeff Garzik <jgarzik@mandrakesoft.com> > Date: Wed, 13 Feb 2002 02:01:06 -0500 > > Why must that affect SIOCGIFFLAGS reporting? > > Because it is asking for a boolean and we don't have > a boolean to give to it. > > Like I said, apps should ask for the count because that > is what it is, a count. > > it broke a security program that called that ioctl to check for unwanted > promisc users > > A program which should also be fixed to ask for the count. > > I know what you want, you want IFF_PROMISC to be > (dev->promisc_count != 0), but I'm not going to publish > that from SIOCGIFFLAGS for several reasons: > > 1) It has lousy semantics, in short it's stupid. Wrong - NIC promisc state is binary. The semantics are that it reports the true state of the hardware. It's an implementation detail that it is reference counted. And it's perfectly logical to ask if a NIC is in promisc mode or not, both IFF_PROMISC semantics and NIC promisc bit are binary in nature. > 2) If I fix change this behavior today, people will > still need to ask explicitly for the count to handle > any kernel before 2.4.19preX/2.2.2X-preX/2.5.5-preX > > So be realistic, there is nothing to gain by the change > you propose. 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. C'est la vie. I've said my peace, let's move on. Can we at least return -EOPNOTSUPPORTED, please? Otherwise you have the current situation: random binaries breaking when you run them under 2.2.x versus 2.4.x. Further, would you object to an ethtool command which returns the NIC's RX mode bits: promisc, all-multi, hash-filter or perfect match, broadcast, etc.? 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
