Messages in this thread | | | Date | Sun, 25 Jul 1999 00:51:44 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
Arvind Sankar wrote: (...) > which was exactly Xymoron's point, I thought. > RT requires no disk hits > vidcapture requires lots of disk access > hence, can't have both.
Can't have both? With RTL you can do that kind of things right now, with timing precision better than 50 microseconds. Rock solid. Never ever a missed deadline, no matter the load on any part of the standard Linux system.
People are doing it already, so it's possible all right. In theory, there's nothing stopping you from doing it with SCHED_FIFO tasks instead of RTL tasks, but it would probably be a very big hack.
My suggestion would be to keep hard real time a separate part of the system, but integrating it better with standard Linux, so that it doesn't mean a completely new environment for the developer. (There's a pthreads API, but it's still kernel modules.) I'm working on a driver API that will make drivers work with both RTL and standard Linux (same code, runtime selection of sync methods), and this might be usable for all kinds of drivers that can be of interest to hard real time apps.
Scheduling mlock()ed user space tasks directly from RT context would be the next step towards making hard realtime completely transparent to most existing RT applications, at least on the source code level.
Comments?
//David
- 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/
| |