From owner-freebsd-current Tue Jul 29 18:27:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA27159 for current-outgoing; Tue, 29 Jul 1997 18:27:15 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA27154 for ; Tue, 29 Jul 1997 18:27:11 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id VAA16803; Tue, 29 Jul 1997 21:26:58 -0400 (EDT) Date: Tue, 29 Jul 1997 21:26:58 -0400 (EDT) From: Garrett Wollman Message-Id: <199707300126.VAA16803@khavrinen.lcs.mit.edu> To: Peter Dufault Cc: current@FreeBSD.ORG Subject: Re: where to put access restriction for scheduling classes In-Reply-To: <199707300033.UAA28927@hda.hda.com> References: <199707292336.TAA16191@khavrinen.lcs.mit.edu> <199707300033.UAA28927@hda.hda.com> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > "Shall I add another resource limit that requires changing all > shells, [...] or [...] shall I add a resource limit to FreeBSD and > change only that part of the FreeBSD login mechanism that is > modifying resource limits at login time while still effectively root > thus ignore this portability af shells issue, in particular ignoring > the other 4.4 derived OS's?" No shell should break as a result of defining a new resource limit. Therefore, you should update setusercontext(3) and the two system shells, and let the other shells fend for themselves. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick