"Serge E. Hallyn" <hallyn@private> writes:
> I was thinking of a simpler approach
>
Ok. I still think it may be a good approach if we want smth generic.
> struct inode {
> - void *i_security;
> + void *i_security[NUM_LSM_MODULES];
> }
>
Nice one.
> This way, changes to the rest of the kernel are very minimal. Change
> some void * to void *[], and add a compile or boot-time option to set
> NUM_LSM_MODULES.
>
boot-time won't work unless you kmalloc. I'd say it's a good candidate for
a config option.
> You can't count on alloc and free.
>
Ok. Any guesses about the actual usage statistics? If we look at the
modules out there that use blobs, do they use all the blobs or just some,
how often are the blobs accessed or updated, etc. I know hard numbers are
hard to get, but some indication might be helpful to identify our needs.
Thanks
/Tomas
This archive was generated by hypermail 2.1.3 : Wed Jul 07 2004 - 15:05:25 PDT