From owner-freebsd-current  Wed Jul 30 07:45:55 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id HAA05288
          for current-outgoing; Wed, 30 Jul 1997 07:45:55 -0700 (PDT)
Received: from labs.usn.blaze.net.au (root@labs.usn.blaze.net.au [203.17.53.30])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA05280
          for <current@FreeBSD.ORG>; Wed, 30 Jul 1997 07:45:48 -0700 (PDT)
Received: from labs.usn.blaze.net.au (davidn@local [127.0.0.1])
	by labs.usn.blaze.net.au (8.8.6/8.8.5) with ESMTP id AAA00985;
	Thu, 31 Jul 1997 00:43:47 +1000 (EST)
Message-Id: <199707301443.AAA00985@labs.usn.blaze.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
cc: Peter Dufault <dufault@hda.com>, current@FreeBSD.ORG
Subject: Re: where to put access restriction for scheduling classes 
In-reply-to: Your message of "Tue, 29 Jul 1997 21:26:58 -0400."
             <199707300126.VAA16803@khavrinen.lcs.mit.edu> 
X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P<Wc^}f75I|456ez/M
 E3OlD+ZL@c>#N+Ec~Z&@;'LL!;3?y<m[SK`'\R~Oe|(t-x+U@a%p!1_fZP0!Tb^?'%M1|"n9
 Fl{Ao~%X[Ec|bMlaN-3#x.e')nZ2/HHYSa2D[:bk#pj0(}\HpKeE}/GqUb3-1}lnUm6Et4?(
 gB5[*Z3Mu6o{Og.EJ))beY9oq9wcVU7_n}:I2JvCaa[5=&PI;x__["DL`uI}=s>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 31 Jul 1997 00:43:47 +1000
From: David Nugent <davidn@labs.usn.blaze.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  <<On Tue, 29 Jul 1997 20:33:11 -0400 (EDT), Peter Dufault
>  <dufault@hda.com> 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.

Don't forget /usr/bin/limits. :-)

Just out of curiosity, what type of resource are we actually discussing
here?

-- 
David Nugent - Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547  Data/BBS +61-3-9792-3507  3:632/348@fidonet
davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/