Re: a joint letter on low latency and Linux

[Richard Gooch]

Cort Dougan writes:
> I think this allows (and encourages) a bad programming model.  Imagine the
> glee a RT programmer experiences when they think they get all of libc for
> free in a RT application.
> 
> I've had a bit of experience with the ugliness and not clearly defined
> behavior that mixing RT and non-RT code gives.  I believe that decoupling
> the two needs into separate pieces of code, as with RTLinux, is the way to
> go.
> 
> } I'd still prefer the scheme I suggested a while back: run Linux
> } processes on the RT scheduler if they have RT priority, and switch
> } between RT and Linux scheduler whenever going between user-space and
> } kernel-space.
> } 
> } This would mean you get complete access to all system calls and user
> } libraries within a RT process, without having to bloat the kernel with
> } a pile of pseudo-RT hacks.
> } 
> } It would also mean we could consider ripping out SCHED_FIFO and
> } SCHED_RR from the Linux scheduler, hence simplifying it.
> } 
> } Somebody please find the time to implement this :-)

You can't legislate against stupidty. And I know giving that power to
people will be seductive. But it's their problem if they fuck up.
Others will use it wisely, and it's a much cleaner solution overall
than chasing our tails trying to get better soft-RT for Linux.

As this discussion has shown, there are some algorithms that have to
run in user-space (audio FX, any advanced filtering), and which have
to run promptly. Every time. And such algorithms often depend on math
and DSP libraries. Forcing people to port their support libraries to
an RTLinux RT process is just not an option.

Like any tool, it can be used and abused. But it can be used wisely,
and it avoids the other hackery that is being proposed.

If you take your position to the next step in a logical progression,
we should disallow device drivers, since they can be abused. I've had
to discourage people (who's minds have been polluted from writing VMS
drivers way back when, and think that they know all about how to write
drivers) from putting everything into a Linux device driver. Left to
their own devices (sic), some people will abuse the device driver
interface just as they would abuse hard-RT user-space processes.

				Regards,

					Richard....
Permanent: [e-mail]
Current:   [e-mail]