Stephen Smalley <sdsat_private> said: >IMHO, we should omit the comment from security.h. We can mention it >as an optional convention in separate documentation, along with >documentation of the other hooks. As the documentation author, I believe we _should_ mention this convention in a comment with the call. I intend to write a stacking module that will be harder to use if the convention isn't followed. Besides, I'm a big believer in documentation -- if there's a "funny" parameter, it's very helpful to make sure its intended uses are clearly documented where the function is defined. If there's a separate document, that'd be okay, but that means someone will have to write it (presumably it would be in the kernel's documentation directory). Once that document is written, this comment could be changed to "see document XYZ for the suggested convention for modid." But until that document is ready to go, it'd better to have it clearly documented there. >Also, does it really matter >whether modid and call are signed or unsigned? The attached >patch is what is currently in my tree. I just added an int magic >parameter and changed the dummy and capability hook functions to >return -ENOSYS. No - I think it should be left unsigned. Values with their high bits set in an int get sign extended in certain cases in C, and as a result, it's easy to get really bizarre bugs where the constant is changed due to sign extension during the function call. The same problem happens when signed chars are promoted into ints or unsigneds. Besides, I know of no one planning to use the sign of the modid, so even thinking abstractly about it, it's unsigned. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Aug 23 2001 - 08:47:57 PDT