* Valdis.Kletnieksat_private (Valdis.Kletnieksat_private) wrote: <details trimmed> > CONFIG_MODVERSIONS > > So it looks like if you say 'N' here, the work's already done for us. > Unfortunately, there's that "non-kernel sources" that we *already* > had a nice flame-fest about (with GNU licenses and all that). actually, as confusing as it seems, the modversions tries to warn you when interfaces change by mangliing the interface name. saying no means you get straight symbols, nothing else, and with the exception of the const string __module_kernel_version, you have nothing other than "runtime linking" to determine whether your module is compatible[1]. so you acutally get more "compatibility" checking with modversions enabled, not disabled. of course, in practice, mocdversions is the source of many a headache, and is often disabled by people compiling their own kernel ;-) however, as greg pointed out, nearly all distros _enable_ modversions to try and get the binary compatibility right. the problem with our interface is that it is not really defined and used in a way that modversions will help. our exported interface is very small: register_security, unregister_security, mod_reg, mod_unreg, capable (used in drivers), and security_ops (i don't believe this is referenced outside of kernel core any longer). the _real_ interface, of course, is the security_ops. this is the value passed to the register_security function, and i'm not sure what help, if any modversions adds here. [1] of course, -f should ignore kernel version on module load... -chris _______________________________________________ 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 : Tue Oct 30 2001 - 10:56:40 PST