Tue, 18 Apr 2000 Matthew Cheselka wrote:
> Hello,
>
> I seem to have some confusion about how to use RTL in my various device
> drivers. Lert's take for example a DAC. So I have the standard open,
> close, write, ioctl file_operations stuff in this driver, I load the
> driver with insmod, and then create another piece of code to actually
> write the digital values out through the DAC.
>
> Where and how do I interface RTL to this? Do I put the rtl_XXX stuff in
> the driver code, or in some outside program (that I think would also get
> loaded with an insmod)?
There are some different ways to do this...
* Write "normal" Linux drivers using RTL threads and/or ISRs instead of
the normal Linux ISRs and kernel threads, while interfacing to user
space using the normal Linux file_operations and stuff. The disadvantage
is that you can only use the interface from Linux user space threads.
(Well, there are tricks to do it from kernel space, but it's still not
RTL real time, as the driver's interface code has to use standard Linux
calls for blocking, waking up etc.)
* Write pure RTL drivers using the RTL posixio layer, and let other RTL
modules use them. This allows hard real time throughout the system,
while using a nice POSIX style file I/O API, but means that all code
have to run in kernel space. (I'm not sure if blocking is implemented
in RTL posixio now; haven't been using it actively for quite a while.)
* Use RTL FIFOs to communicate with the drivers. These can be accessed
from user space as well as kernel space. RTL FIFOs have RTL posixio
support these days, so it shouldn't be too complicated to make
applications compile for user space for debugging, and then for RTL
for the production systems, using the same API syntax.
* Hack some RTL/Standard Linux driver programming API and interface it
with RTL posixio as well as Linux' standard I/O subsystem. Slightly
nicer than using FIFOs in some ways, but the driver API seems to need
some unsexy hacks. (Check out
http://www.angelfire.com/or/audiality/downloads
for a proof-of-concept hack I did a while ago. It has driver API calls
that can sleep/wake both standard Linux threads and RTL threads and
things like that, making it possible to write drivers that behave the
same as normal Linux drivers both from user space and via RTL posixio.
I currently don't have a great need for this solution, so I haven't
worked much more on it. It could use a great deal of cleaning up, and
what I was about to do before I got into too much other stuff was to
add a compile time switch to allow pure Linux and pure RTL drivers as
well as the default runtime autodetect mode. Oh, don't look too
closely at that es1370 [AudioPCI] driver - it has some silly bugs...)
David Olofson
Programmer
Reologica Instruments AB
Scheelevägen 30
S-223 63 LUND
+46 (0)46 - 12 77 60
..- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> [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/
