netdev - Re: [PATCH net-next 1/2] rtnetlink: add new RTM

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: <20160315082417.GC2263@nanopsycho.orion>
Date:	Tue, 15 Mar 2016 09:24:17 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	roopa <roopa@...ulusnetworks.com>
Cc:	netdev@...r.kernel.org, jhs@...atatu.com, davem@...emloft.net
Subject: Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to
 dump link stats

Tue, Mar 15, 2016 at 09:08:44AM CET, roopa@...ulusnetworks.com wrote:
>On 3/15/16, 12:52 AM, Jiri Pirko wrote:
>> Tue, Mar 15, 2016 at 08:38:51AM CET, roopa@...ulusnetworks.com wrote:
>>>
>[snip]
>>> how does it matter if we have reached an agreement that the struct is required ?.
>>> unlike other messages, a filter_mask is an important and must attribute for
>>> stats. If you are worried about us running out of bits in u32, the netlink attribute you will
>>> define for the filter_mask will also be u32 to begin with.
>> No, you are missing the point:
>
>I understood what you meant the first time...(to which i did comment if you really wanted a u8 for every filter attribute).

You mentioned "u32 attr" in last reply and that is clearly something I
didn't suggested and wasn't talking about at all, so I had to make
things clear.


>
>>
>> enum {
>> 	IFLA_STATS_UNSPEC,
>> 	IFLA_STATS_FILTER, /* nest */
>> 	IFLA_STATS_LINK64,
>> 	IFLA_STATS_INET6,
>> 	__IFLA_STATS_MAX,
>> };
>>
>> #define IFLA_STATS_MAX (__IFLA_STATS_MAX - 1)
>>
>> enum {
>> 	IFLA_STATS_FILTER_UNSPEC,
>> 	IFLA_STATS_FILTER_LINK64, /* flag */
>> 	IFLA_STATS_FILTER_INET6, /* flag */
>> 	...
>> 	IFLA_STATS_FILTER_WHATEVER, /* flag */
>> 	__IFLA_STATS_FILTER_MAX,
>> };
>>
>> #define IFLA_STATS_FILTERMAX (__IFLA_STATS_FILTER_MAX - 1)
>
>Apart from the usability concern i have described earlier, this just seems an overkill ...having to redefine every attribute.

I don't hear the usability concern. User knows how to compose/parse
attrs, no problem there.

You just add flag attr as if you add bit in u32 mask. The same thing.

I don't understand why you say this is an "overkill". I believe that
this is the correct way to do.