What "hundreds of thousand of lines"? I think your problem is that
you think that if you use RTLinux then you have to do everything inside
RTLinux. That's not the case at all. You do the part that can't have
jitter there but the data processing is all down under Linux as it
is today.
It's true that I'm not an expert in this area so my I'm completely wrong,
educate me. My understanding is pretty basic - there are input channels
and output channels and these have to be sampled at a constant rate, with
no delays, right? And the basic issue is that if we are doing disk I/O
(or whatever) then the deadline is not met, right?
And since you are insisting that ypu do not want to run in kernel mode,
then I can assume that most of the work happens in user space, but the
sampling happens in the drivers, right?
If that's not right then please tell me how it works. If that is more or
less right, then it seems to me to be trivial to open up a pipe to a real
time process which does the sampling and away you go.
On the other hand, if you are doing all the work in the kernel or in the
drivers, then the portability argument goes away because you have to port
all that glop to Windows/whatever.
My guess is that it is close to what I think it is and that you don't realize
that the point of the RTLinux APIs is to give you a small amount of code that
does exactly what you want when you want it and then passes the results out to
exactly the same user level processing you would use today.
So educate me, tell me what I don't understand.
> - target audience : how many of the of the millions of linux desktops have
> RTLinux installed
This is the same crock of sh*t that MIS directors used against Linux
itself: "How many machines from Compaq come with Linux installed?"
Of course the standard distributions don't have it, there aren't apps that
need it yet. But you get busy and make some whizzy apps that work flawlessly
under RTLinux to give you great sound and video and watch how fast Red Hat
ships with RTLinux. Using the "it isn't shipping yet" argument is wacko -
the same can be said for every new idea. If we used your logic, nothing
new could _ever_ happen.
> The frustrating thing is that Ingo's patch although ugly, can cover
> ALL realtime multimedia needs NOW
Really? So you've done the analysis and testing to show that this is true
for "ALL realtime multimedia needs NOW"? You know what, I don't believe that.
Show me.
> - too restrictive : problems with large memory needs,
> working in kernelspace (do we really want to run COMPLEX apps within the
> kernel space (a physical modelling synth) ? ,
No, you don't, and nobody is telling you to do so. Just gather the data
you need in the RT part and send it out to Linux just as you do today.
[other complaints about young technology deleted]
> So why should I use RTLinux which can do 20-50usec when 99.99% of cases can be
> covered using and userspace app running SCHED_FIFO / mlock() because most
> apps do not need <5msec latencies.
Because RTLinux can give you what you need.
Because it doesn't require you to hack up the kernel.
Because it is far more scalable and reliable.
Because it is cool.
Because your approach is the same tired bag of mistakes that helped make
other operating systems piles of sh*t.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/