Re: 2.6.11-rc3-mm2

[Matt Mackall <mpm@selenic.com>]

On Thu, Feb 10, 2005 at 10:41:28PM -0500, Paul Davis wrote:
>   [ the best solution is .... ]
> 
>   [ my preferred solution is ... ]
> 
>   [ it would be better if ... ]
> 
>   [ this is a kludge and it should be done instead like ... ]
> 
> did nobody read what andrew wrote and what JOQ pointed out?
> 
> after weeks of debating this, no other conceptual solution emerged
> that did not have at least as many problems as the RT LSM module, and
> all other proposed solutions were also more invasive of other aspects
> of kernel design and operations than RT LSM is.

Eh? Chris Wright's original rlimits patch was very straightforward
(unlike some of the other rlimit-like patches that followed).
I haven't heard the downsides of it yet.

simple rlimits:
 logical extension of standard, flexible interface
 fine-grained per-process access to nice levels and priorities
 managed with standard tools
 fairly broad possible applications
 clean enough to be added unconditionally
 already doing mlock this way!

RT LSM:
 new, narrow magic group interface (module parameters!)
 boolean granularity of access to all RT levels and maybe mlock
 potential interesting interaction with other LSMs
 not orthogonal to mlock
 not appropriate for every box out there
 requires lsm and (sysfs or modprobe)

-- 
Mathematics is the supreme nostalgia of our time.