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
| ||
|
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
Powered by blists - more mailing lists