Mon, Mar 14, 2016 at 08:56:40PM CET, da...@davemloft.net wrote: >From: Jiri Pirko <j...@resnulli.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
