* Greg KH (gregat_private) wrote: > > But I think you are thinking of a module that manages different security > modules, right? If so then your stacking module's call would look > something like this: > > stacker_sys_security (unsigned int id, unsigned int call, unsigned long *args) > { > struct list_head *list; > struct stacked_modules *module; > int retval = -ENOSYS; > > lock_the_list(); > list_for_each(list, &security_module_list) { > module = container_of (list, struct stacked_modules, module); > retval = module->ops->sys_security (id, call, args) > if (retval != -ENOSYS) > goto exit; > } > unlock_the_list(); > > exit: > return retval; > } > > Either way, you don't need to know the ids of the modules. This is how I'd do it as well (of course, with the unlock bug that Greg pointed out fixed ;-). I know Crispin doesn't find this elegant, but the overhead is not critical, and it's consistent with other bits of the kernel (for example, binfmt handlers) and even other projects (apache module handling is done this way). If this polling style leaves a sour taste you could certainly create a stacker protocol that does more efficient dispatching. The mod_reg_security() interface (which the subordinate modules will use to register with the stacker) contains the parts necessary to do this. The name string could be required (by stacker protocol) to be one of two things: 1) the string used by the module when generating the md5sum'd ID; 2) the string version of the ID. You get the idea... thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ 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 : Mon Aug 26 2002 - 15:57:32 PDT