On Wed, Sep 28, 2016 at 06:43:01AM -0400, Jamal Hadi Salim wrote: ... > > > > Someone may have set it to zero explicitly on source level, and the > > compilation will fail on new kernel then. So no, keeping the name > > is reasonable. > > > > I dont know how compilation will fail but you may be right with note: > that is not how pads have been used in the past. They are supposed to > cosmetic annotation which indicates "here's a hole; use it in the > future if you are looking to add something". And someone in the > future can claim them. I am not sure if MBZ philosophy applies.
This structure is uapi, so anyone has complete rights to reference @pad in the userspace programs. Sure it would be more clear to remove the @pad completely, but if we choose so I think it's better to do on top instead and then if someone complain we can easily revert the single trivial commit instead of this big patch. > > > > Should you not just rename it? > > > Also I notice when things like __raw_v4_lookup() are claiming it is > > > unsigned > > > short instead of a u8? > > > > The protocol is still up to 255 for a while, is it expected that IPPROTO_MAX > > will be increased in more-less near future? Of course I can drop the idea > > of using @pad here and switch to some extended reauest but prefer to stick > > with simplier solution. Hm? > > > > Ok. If i understood correctly it was already unsigned short before your > patch -so i agree it doesnt matter. Maybe just put a comment to express > that if ever protocol goes above 255 it wont be sufficient. If protocol goes over u8 then complete inet_diag_req_v2 structure will have to be reworked becaue @sdiag_protocol is u8 as well. IOW, once someone liftup IPPROTO_MAX > 255, he will notice the problem immediately because diag for such module simply stop working properly.
