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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160314202202.GB23419@nanopsycho.orion>
Date:	Mon, 14 Mar 2016 21:22:02 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	David Miller <davem@...emloft.net>
Cc:	roopa@...ulusnetworks.com, netdev@...r.kernel.org, jhs@...atatu.com
Subject: Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to
 dump link stats

Mon, Mar 14, 2016 at 08:56:40PM CET, davem@...emloft.net wrote:
>From: Jiri Pirko <jiri@...nulli.us>
>Date: Mon, 14 Mar 2016 20:04:35 +0100
>
>> I believe that using *any* structs to send over netlink is a mistake.
>> Netlink is capable to transfer everything using attrs. Easy to compose,
>> easy to parse. easy to extend. Couple of more bytes in the message? So what?
>> For newly introduced things, I suggest to do this properly.
>
>It is not so straight-forward.
>
>What to put into the header is a tradeoff.
>
>The most basic use cases should be as efficient as possible, and if we
>can put reasonable knobs into the base commend header we should do that
>as avoiding attribute processing makes things faster.

Faster in which matter? Regarding the user app complexicity, I think that
processing attrs is very simple and straightforward. I might be missing
something very obvious, but I don't think that processing header struct
is that much easier that it advocates for the unclean approach.

I personally believe that introducing possibility to pass Netlink
headers was a mistake from the very beginning. If we have clean Netlink
interface, why to pollute that with ioclt-like struct approach. Okay,
the mistake was done. But as I said, for the future usage, I believe
that it should be avoided.

>
>And I think in this case it is reasonable to put the mask in there.
>
>The only problem I see with this series is the naming of the netlink
>command (it isn't a "new" operation, and the "del" is unused).
>
>Maybe the suggestion to use just "GET" as the name is ok.

+1