...while I intend to stress the disk I/O A LOT with Audiality's hard
disk recording daemon. Kind of pointless trying to avoid loading the
rest of the system, as hard disk recording is the main reason why I
started this project.
(...)
> Linux is not losing time locking/unlocking, it loses response time by not
> preempting tasks in kernel mode. But preempting tasks in kernel mode would
> be a terrible design choice for a general purpose OS and it a terrible pain in the
> ass to maintain.
Agree. While being an uggly hack, it's also quite pointless wasting
cycles on allowing this kind of real time, while most of the system
doesn't need it. Finer grained locking for improved soft real time and
overall performance is nice, but hard RT should be kept a separate
service, IMO. Easier integration with the non(/soft) real time system
would be nice, though...
BTW, while hacking the es1370 driver for RTL, I've got a set of
Linux<->RTL interfacing functions together. The driver is currently
(while I'm typing this, actually) running on an RTL interrupt, while
still looking exactly like the original driver to applications. I didn't
touch much of the driver code itself to do this; just some minor
adjustments in order to get the waitqueues under control, so that the
RTL interrupt can wake them up. (Looks a lot like the RT-FIFO code.)
I'll move those functions into a separate module and perhaps clean up
the interface a little. Anyone interested? Ideas?
So far, this driver hack turned out to be simpler than I expected. :-)
I'm not sure all drivers are that friendly, though...
Next project: interruptible_sleep_on() for RTL tasks, so that I can open
and use the driver directly from RTL, bypassing the file system, while
keeping 95% of the original driver code.
> BTW: I have never seen any serious performance numbers on BEOS. Do you have a source?
Would like to see those figures too. All I managed to find out (didn't
try all that hard, and I haven't got BeOS) is that they managed to
achieve 3 ms audio latency, but I know nothing about reliability, how it
was done, etc.
//David
PS. Thanks for filling me in on the real time stuff! :-)
-
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/