24 May
2006
24 May
'06
1:24 p.m.
On 5/25/06, Wolfgang Woehl <tito(a)rumford.de> wrote:
Wednesday 24 May 2006 02:01, Lee Revell:
One is a mechanism, useful in many domains. The other controls
who has access to that mechanism. Some systems don't care (yours
pehaps?), others care very much.
There is nothing wrong with this as a system design concept. What
you and many of us are suffering from is the balkanized implementation
of Linux kernels and distributions. The kernel group made some
implementation choices a year ago. While those choices were OK,
they did not worry about all the peripheral pieces needed to gather
them into a useable end-user package. That is not their job.
The required components are now available, and are being provided
by a few leading-edge distributions. Had you installed Ubuntu Dapper
Drake (which is not yet officially released), you would not have seen
any problem. They chose to include the PAM patches and authorize
all users to start realtime threads be default. That is a reasonable
choice for them (given their goals), but would not be appropriate for
most other distributions.
--
joq
On Thu, 2006-05-25 at 01:55 +0200, Wolfgang Woehl
wrote:
Err, no. I doubt the need for this restriction. A campus server kernel
wouldn't be configured for preemption, a dedicated workstation would be. Why
put another roadblock in the way? Damn, it doesn't make sense to me. If I can
configure the kernel to be
or not to be preemptible then what is the separation good for? Isn't
overhead because of preemption the only price tag?
You are confusing preemption (which improves the performance of realtime
processes) with the permission to run realtime processes at all
(addressed by the realtime LSM, pam, or set_rtlimits).