* jmjonesat_private (jmjonesat_private) wrote: > > Per This Discussion... > Things I'd Like To See As a Module Maintainer: > > 1) Add a single pointer to the structure that is registered, near the top > (just for convenience), that is the "default/unsupported" function. This means that the framework would automagically code hooks you didn't know about with a default. This is not acceptable. Also, hooks have different prototypes, at least return void or return int. I don't like this proposal. > 2) Have the module pass the length of the structure it is registering when > it registers the structure (most likely as "number of hooks".) This could > be simply another integer in the registration function call, since the > registration code would probably know the size of a pointer. This is possible, but sounds like it may not be useful. I suspect the simple fallback is something like using sizeof, which when compiled against a new header would give the right size according to the framework and the wrong size according to the module. Just what we don't want. Anything more manual seem too tedious to me. > 3) Copy the default pointer to all the pointers in the internal structure > before doing anything else. see 1. > 4) Copy the specified structure into the functional structure, based on > the number of hooks specified. Hooks are initialized by labelled elements. Linear order is not important. This makes it simple to change the structure without needing to worry about ordering. I prefer labelled elements. > This would allow the MODULE to trap kernel calls that it doesn't handle, > and notify the developer or the errant admin (who is loading an obsolete > module) without a kernel panic. Module developers who don't want to > manage all of the hooks could just register hooks to a "don't care" in the > original structure within their module, and know the difference. It already works like this. If you pass a structure with an empty hook, you will find out w/out a panic. Your module won't load. 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 : Wed Jul 03 2002 - 14:02:27 PDT