On Wed, Sep 28, 2016 at 08:27:24AM -0400, Jamal Hadi Salim wrote: > > > > They must initialize it to zero. > > > > What if in the future actually meant to use 0 for > something?;-> For example in Cyrill's case it means PROTO_IP > Not sure if it useful to interpret or not but it is part of the > enum for protocols.
It will be perfectly fine if we start using 0 here for something, the main match key is @sdiag_proto (which will be IPPROTO_RAW for my case). If someone is to use this field for something else the main key selection remain the same, iow @sdiag_proto first and then subprotocol if needed. > Maybe we shouldnt be adding pad fields in these netlink > structure definitions then one can liberally add new ones. You know, I personally don't see much problem in defining union, especially while anonymous uninons do work for us here. > Note: inet_diag somewhere has a netlink structure that > has a hole. I pointed it out to Eric D. and he said we cant > add it now because it would break ABI. Naming holes generated by a compiler for alignment sake should not break abi (because alignments are abi by self), but I may be missing something in context of where the structure you're talking about is present. And what about non-x86 archs? They might have different members alignment requirements. > So where do we draw the line for future extensions?
