Fri, 24 Mar 2000 [EMAIL PROTECTED] wrote:
> > That would be very cool. I don't mind hacking kernel/RTL drivers for the low
> > level stuff, but when the major part of the application ends up in kernel
> > space (ie needs low latency, hard RT), it starts to get scary...
>
> I'm really interested in such applications because I would like to know
> what it is that prevents modularization -- do you really have so much code
> that needs hard RT?
Well, I might get away with some "cheating" for the project I'm working on for
my employer, but that will mean more complexity and less flexibility, as
operations that should preferably be RT, aren't. The idea is that the old
application with hardcoded operating modes (that I have to update all the time,
triggering nasty bugs due to the broken "OO" structure...), should be replaced
with a generic engine that accepts measurement specifications (sent from the
Windows based GUI) and returns result data in the requested format.
As we'll be experimenting with new measurement methods, we can't assume that
some parts of the system won't need deterministic timing. There's no clear
hard/soft RT split, except for at the Windows/instrument communication. Even the
packet/command parsing should be real time, as it's up to the Windows program
to timestamp every packet. Actually, you could view the system as a real time
scripting engine with a very simple language. (I've thought about including
some basic conditional and flow control commands, but that's probably overkill.
Anyway, it's an easy hack if we should need it, provided there are no nasty
non-RT units breaking the determinism of script execution.)
As for more complex systems where you really can't tolerate code running in
unprotected kernel space; real time audio processing systems running
(third-party) plugins have to be realized more or less entirely in the hard real
time domain, as all plugins in a processing network directly depend on each
other, and everything must keep up with the audio interface. For some
applications - such as virtual synthesizers based on Csound-like designs - that
includes real time instantiation of plugins, and rebuilding and optimizing the
processing net on the fly.
That becomes quite a lot of code just for the engine, and then we've got all
those plugins people want to use... Linux not crashing because of buggy
applications (such as Netscape; Thank God I don't have to run it on Windows!),
and that's a reason as important as the latency issues why I want to get
Windows out of my studio ASAP. Emulating the "Win95/98 powers down in .1
seconds due to DirectX plugin crash" trick is something I'd like to avoid
without having NASA debug all plugins. :-)
> > Also, I'm still interested in running an audio/DSP engine under RTL (less than
> > 2 ms latency, and possibly better SMP performance), and this would eliminate
> > the need for running the plugins in kernel space. Would make an excellent RT
> > control prototyping tool as well, for those who aren't all that interested in
> > audio.
>
> We're looking at alternatives: the new LXRT seems to have some good ideas
> in it, there are Ingo's low latency patches, and I've been discussing another
> trick somewhat along the LXRT lines. Another possibility is to implement
> pseudo-Linux tasks that run in usermode in a special space.
My idea of the most important differences between the kernel space RT approach
vs. user space, protected memory:
Kernel space User space
------------ ----------------
Worst case latencies near Lowest worst case latency
the hardware limits. possible without unreasonable
overhead or kernel ugliness.
Meant for drivers and other Meant for real time user
code that's fairly simple. applications.
End-users should not need End users should be able to
to worry about services install and use applications
running here on without security hazzards or
preconfigured prohuction other unusual problems.
systems.
Code is trusted not to Nothing is trusted. Anything
intentionally break the might be a virus, trojan or
system. simply an application with a
nasty bug.
I think it's important to keep the security issues in mind for the user space
RT, as flaws here will probably prevent the solution from becoming generally
accepted, and most certainly ensure that it never becomes a part of the
official Linux kernel. Seeing it just as a hack for safer debugging and fault
tolerance is useful, but very restricted.
//David
P r o f e s s i o n a l L i n u x A u d i o
· ··-------------------------------------------------·· ·
MuCoS - http://www.linuxdj.com/mucos
Audiality - http://www.angelfire.com/or/audiality
David Olofson - [EMAIL PROTECTED]
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
