On Sat, Jun 29, 2002 at 02:29:52PM -0400, jmjonesat_private wrote: > While my interest does work toward module stacking and multiple module > interaction, I agree with this evaluation. Can't a module find out what > version of the operating system it's operating under? Modules should really be recompiled for the kernels they are going to run on: MODERVERSIONS can sometimes help mitigate problems, but that is only effective for exported symbols, iirc. So, LSM modules really should be compiled for specific kernels they will run on. In fact, the modutils will complain if the versions don't match. > Won't LSM track the kernel on a version-per version basis? I think it > can! I really think it's a service to the community to require module > developers to track the kernel development... important stuff has > changed nearly weekly since I've been tracking this project. In fact, this is not feasible. RedHat's kernel is different from SuSE's kernel, which is different from Mandrake's kernel, which is diferent from Debian's kernel ... all of which are very different from mainline kernels. The LSM project can track 2.4, or 2.5, but anyone who modifies an LSm kernel in any way is going to be responsible for making sure their changes don't break LSM. This isn't a terrible burden, as distros must already do this for their patches with the rest of the kernel subsystems. > Could the solution be as simple as a SINGLE *definitive* version > identifier from the interface for the interface offered? While I suppose this is possib le, it isn't sufficient to think of only changes to the interface. Changes to underlying kernel code could change the semantics of some of the hooks, without necessarily changing the interface. Diligence might be the only answer. -- http://www.wirex.com/
This archive was generated by hypermail 2b30 : Sat Jun 29 2002 - 11:45:31 PDT