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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
