From owner-freebsd-hackers Wed Jul 30 05:07:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA26706 for hackers-outgoing; Wed, 30 Jul 1997 05:07:39 -0700 (PDT) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA26700 for ; Wed, 30 Jul 1997 05:07:34 -0700 (PDT) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id HAA00393 for hackers@freebsd.org; Wed, 30 Jul 1997 07:21:56 -0400 (EDT) From: Peter Dufault Message-Id: <199707301121.HAA00393@hda.hda.com> Subject: Re: where to put access restriction for scheduling classes In-Reply-To: <199707300126.VAA16803@khavrinen.lcs.mit.edu> from Garrett Wollman at "Jul 29, 97 09:26:58 pm" To: hackers@freebsd.org Date: Wed, 30 Jul 1997 07:21:55 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Sorry that went out on -current. Redirecting to -hackers) > 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. Shells won't break, but you won't be able to set the new resource using "limit" in unchanged shells. I'll do as you suggest - add RLIMIT_SCHEDULER and change csh and sh to support it. Then specific users can be permitted to change their process scheduler. I do have a related question - ptolemy for example uses 1003.4 process scheduling semantics for some simulations to ensure things run the way they want them to. I'd like per-process group scheduling so that one could ensure that a group of processes preempt each other without potentially hogging the CPU. This would be good both for this sort of simulation and for development of realtime systems. It is "half threaded": the process group as a whole would be fairly scheduled with other processes, but when it was readied the appropriate process would run, Does anyone have suggestions for how to specify this and how to implement this? Source should not have to be changed, so again an inherited per-process flag for real time flavor would be appropriate. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval