comp.lang.ada
 help / color / mirror / Atom feed
From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
Subject: Re: Runtime Error with gnat 3.10p
Date: 1998/05/28
Date: 1998-05-28T00:00:00+00:00	[thread overview]
Message-ID: <356D33C7.42638D40@cl.cam.ac.uk> (raw)
In-Reply-To: m33edv2cff.fsf@fred.muc.de


Andi Kleen wrote:
> Of course it is possible to implement it under Linux without requiring
> privileges too, just not with the standard, unmodified LinuxThreads
> package. There are several userspace threads packages available (I
> think the GNAT runtime has its own too) that work in a single process
> context and don't need root for anything. Of course they all don't
> scale to multiple CPUs on SMP machines.

This keeps me thinking: Can we extend the Linux kernel
such that SCHED_FIFO and SCHED_RR are also available to non-root
processes at static priority 0 such that SCHED_OTHER processes
can still preempt SCHED_FIFO and system lockup is prevented?

At the moment, Linux has a static priority system with priority
levels from 0 to 99. All normal (non-realtime) Linux processes
run with the SCHED_OTHER scheduler policy under the lowest possible
priority level 0. The SCHED_RR and SCHED_FIFO (using the POSIX.1c
terminology here) run under static priorities 1 to 99. This
means that with SCHED_RR and SCHED_FIFO, you have guaranteed
deterministic scheduling behavior, all normal processes will
always have a lower priority and never interfer. The classic
Unix dynamic priorities, nice levels, etc. only organize
scheduling within this static priority 0 of the SCHED_OTHER
policy.

The original purpose of the real-time scheduler under Linux was
to provide for time-critical hardware control software to have a
guaranteed way of not being interfered by normal system processes
such as the X and mail server.

May be, we can extend the Linux scheduler easily to allow SCHED_RR
and SCHED_FIFO policies also to be used at a static priority 0.
The semantic would then be that with static priority 0, a
SCHED_FIFO process will never be preempted by another SCHED_FIFO
or SCHED_RR process, but it can very well still be preempted by a
SCHED_OTHER (i.e., normal) process. This way, we preserve the
execution order of threads that have only SCHED_FIFO and
SCHED_RR policies within this thread community, but the execution
of other SCHED_OTHER threads and processes will not be affected.
Therefore, SCHED_RR and SCHED_FIFO can be made available at
static priority 0 also to non-root users.

Is this the missing bit that is necessary to give the GNAT native
RTS the ability to fully implement Annex D as a non-root process
under Linux?

Is there any real application need for such a feature (beyond the
ability to cheat around the Annex D formal requirements in
conformance test suites)? If yes, then I'll have another look
at the Linux scheduler whether there is an efficient extention
possible.

The nice thing about the Linux kernel is that problems can easily
be fixed within a few days. You do not have to wait 4 years for
the next release like with Microsoft systems. Use the source, Luke!

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>




  reply	other threads:[~1998-05-28  0:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-26  0:00 Runtime Error with gnat 3.10p Andreas Jungmaier
1998-05-26  0:00 ` David C. Hoos, Sr.
1998-05-26  0:00   ` Markus Kuhn
1998-05-27  0:00     ` Robert Dewar
1998-05-28  0:00       ` Larry Kilgallen
1998-05-28  0:00         ` Andi Kleen
1998-05-28  0:00           ` Markus Kuhn [this message]
1998-05-28  0:00             ` Andi Kleen
1998-05-28  0:00       ` Markus Kuhn
1998-06-01  0:00         ` CHARLET Arnaud
1998-05-26  0:00   ` Simon Wright
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox