On Wed, Jan 28, 2015 at 02:19:11PM +0100, Yann Droneaud wrote: > But the same program (either binary or source code) might fail on > newer kernel where some bits in comp_mask gain a meaning not supported > by the program. To clarify some of this: The intention of the comp_mask scheme was to define a growing structure. The invariant is: A bigger structure allways has all smaller structures (past versions) as a prefix. So the size alone is enough for user space to know what is going on. userspace only processes structure members up to the size returned by the kernel, and there is only one structure layout. The purpose of the output comp_mask is to allow drivers to declare they do not support the new structure members, and comp_mask bits should only be used with new structure members do not have a natural 'null' value. Further, we need to distinguish cases where additional data is mandatory or optional. query_device is clearly optional, the only purpose the input comp mask serves is to reduce expensive work in the driver by indicating that some result bits are not needed. It is perfectly OK for the kernel to ignore the input comp mask, and OK for userspace to typically request all bits. (indeed, I think this is a pretty silly optimization myself, and the original patch that motivated this was restructured so it is not needed) Other verbs must be more strict, if one side does not understand the comp mask then the verb must fail in some way. Presumably the valid comp mask values are inferred in some way (eg query_device says the extended function is supported) Everything should fit in one of those two general cases.. > Thanks for the link to the presentation. If I recall the presentation is old and had some flaws that were addressed before things made it into libibverbs.. Thank you for looking at this, it is very important that this scheme is used properly, and it is very easy to make mistakes. I haven't had time to review any of these new patches myself. Regards, Jason -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
