Since this hook seems to be purely informational, and passes only the pointer to the inode to the module that is inherent in the function in which it is imbedded, could not the module maintain a list of "significant" inodes and implement the same function on the first non-match to the list? Admittedly, it may be computationally intensive, but it seems to me it's reasonably possible. In other cases, this sort of "information only" call has been questioned as being 1) expensive and 2) invasive (another hook is, after all, another hook.) To support its inclusion, could you make a case for the generality of its usefulness (um, please. :))? One the other hand, if lots of developers can save "potentially computationally intensive solutions" with this hook, I've no objection, except it co-exists with a more authoritative solution I'm working with, and is therefor duplication (for me.) Is this sort of informational hook for a single project's purpose within the scope of LSM, or does it require 2 or 3 projects to find it useful? Supportively, J. Melvin Jones Getting to know what is and isn't within LSM's scope, and hoping I can make use of it where appropriate. |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 Oct 01 2001 - 17:28:29 PDT