The purpose of the LSM 2.5 tree was to prepare for Linux 2.6. The
purpose of the LSM 2.6 tree was to do initial tech transfer.
I presumed that additional changes in LSM for 2.6 would be roundly
rejected and pushed into Linux 2.7 development. But now the press on the
Linux Kernel Summit is saying that Linux 2.7 may not happen for a long
while, and development may continue in 2.6.
I don't understand this approach at all. Was anyone here at the kernel
summit 2004? Can you comment on these questions:
* How will development and stable kernel releases be distinguished
within 2.6?
* What kind of new LSM functionality would be considered for 2.6, if
any?
Greg, Chris? Got any insights?
Thanks,
Crispin
Stephen Smalley wrote:
>On Mon, 2004-07-26 at 10:22, Stephen Smalley wrote:
>
>
>>BTW, I'd advise working against the
>>mainline kernel tree, as the LSM BitKeeper tree seems dead (last updated
>>for 2.6.4 vs. current mainline of 2.6.8-rc2), and you'll have to re-base
>>anyway to submit any patches upstream due to differences in security.h
>>and elsewhere from legacy hooks.
>>
>>
>
>I thought I should raise this issue as a separate thread. My
>impression, and our practice for SELinux for some time since LSM was
>merged into mainline, is that people using LSM should just work directly
>off the mainline kernel and submit any new hooks and/or security modules
>to lkml and the appropriate subsystem maintainers (including Chris
>Wright, as the LSM maintainer), with a cc to the lsm list for general
>awareness among other LSM users/developers. At this point, the LSM
>BitKeeper tree seems to mostly just be for historical reference. If
>someone wanted to actively maintain a separate tree to allow more
>radical development in preparation for 2.7, I think that they would
>likely want to clone a new tree from mainline to ease maintenance and
>allow easier generation of diffs against mainline for submission
>upstream. Working from the LSM tree seems to suffer from 1) lagging
>behind mainline, 2) reliance on legacy hooks not in mainline (and no
>impetus to get those hooks accepted, since the security module writer
>doesn't even realize that the hook is only in the LSM tree), 3) failure
>to get any other security modules into mainline - they just get posted
>to lsm or a few are in the LSM BitKeeper tree, but they never make their
>way to lkml for general review and consideration.
>
>
>
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
This archive was generated by hypermail 2.1.3 : Sat Jul 31 2004 - 18:37:52 PDT