netdev - Re: Driver writer hints (was [PATCH 3/4] Add ETHTOOL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46BCD3E7.1050403@garzik.org>
Date:	Fri, 10 Aug 2007 17:08:55 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Rick Jones <rick.jones2@...com>
CC:	netdev@...r.kernel.org, davem@...emloft.net,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Driver writer hints (was [PATCH 3/4] Add ETHTOOL_[GS]PFLAGS	sub-ioctls)

Rick Jones wrote:
>> If we are getting (retrieving) flags:
>>
>>     3) Userland issues ETHTOOL_GPFLAGS, to obtain a 32-bit bitmap
>>
>>     4) Userland prints out a tag returned from ETHTOOL_GSTRINGS
>>        for each bit set to one in the bitmap.  If a bit is set,
>>        but there is no string to describe it, that bit is ignored.
>>        (i.e. a list of 5 strings is returned, but bit 24 is set)
> 
> Is that to enable "hidden" bits?  If not I'd think that emitting some 
> sort of "UNKNOWN_FLAG" might help flush-out little oopses like 
> forgetting a string.

No purpose other than attempting to define sane edge case behavior.

The bitmap interface is completely invisible to the user (who sees UTF8 
strings on the command line), and given the interface I felt the easiest 
thing to do would be to define an "ignore any garbage" default policy.

Due to the way the interface is designed, each userland user must be 
aware of the precise number of valid bits in the bitmap /anyway/, thus 
making clipping/ignoring garbage bits almost a trivial side effect.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html