Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262203AbVBKG63 (ORCPT ); Fri, 11 Feb 2005 01:58:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262204AbVBKG63 (ORCPT ); Fri, 11 Feb 2005 01:58:29 -0500 Received: from waste.org ([216.27.176.166]:36562 "EHLO waste.org") by vger.kernel.org with ESMTP id S262203AbVBKG60 (ORCPT ); Fri, 11 Feb 2005 01:58:26 -0500 Date: Thu, 10 Feb 2005 22:57:53 -0800 From: Matt Mackall To: Paul Davis Cc: Peter Williams , Nick Piggin , Chris Wright , "Jack O'Quin" , Andrew Morton , Christoph Hellwig , linux-kernel@vger.kernel.org, Con Kolivas , rlrevell@joe-job.com, Ingo Molnar Subject: Re: 2.6.11-rc3-mm2 Message-ID: <20050211065753.GE15058@waste.org> References: <420C25D6.6090807@bigpond.net.au> <200502110341.j1B3fS8o017685@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502110341.j1B3fS8o017685@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1592 Lines: 43 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/