lkml.org 
[lkml]   [2005]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.11-rc3-mm2
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.261 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site