On Thursday 01 November 2001 11:30, Vijay Ananth.K wrote:
> Hello Friends,
>
> I have few doubts:
>
> (1) Which is the best method for transferring data between User space
> and rt-space/kernel space. I have used FIFO, MEM Buf etc. But I am not
> still clear which one should I use. Somebody Please advice.
There is no single "best" method - what is best for a particular
application depends on bandwidth, buffer size requirements, which
synchronization constructs you can use in the implementation, and
possibly various other things.
In short, use shared memory interfaces for high bandwidth transfers. Use
some kind of FIFO like construct for everything else, except low
bandwidth, out-of-band stuff - use the ioctl() API for that.
As to implementation, there aren't all that many ways to use shared
memory, on the raw interface level. (The differences are in what kind of
data is shared, or rather, the interaction "protocol" used.) Either use
Linux kernel calls directly (as most Linux kernel drivers with mmap()
support do), or use mbuff() to set the shared buffers up.
When it comes to data copying interfaces, there's of course the "raw"
Linux kernel calls and macros (copy_to_user() and co), and then there are
RTL FIFOs, QNX style message API implementations and whatnot.
Regardless of which way you go, keep in bind that RTL is *not* Linux, so
you can't use normal Linux synchronization constructs (as done in normal
Linux drivers) - they won't keep your RTL threads from colliding with
your driver API syscalls!
> (2) I want to develop a complete POSIX RT-DRIVER. When I found the
> details of implementing it, I got lost in so many things. (I am trying
> In RT-Linux 3.0) I found that rtl_fifo is using functions from
> rtl_posixio. rtl_fifo is registering the device two ways. (i.e.) with
> register_chrdev(...) and rtl_register_chrdev(...). Why is it
> registering like this.
Because it provides one interface to Linux user space (through
register_chrdev()) and *two* interfaces to RTL threads; the old "direct"
calls, and the newer "rtl_posixio" interface (through
rtl_register_chrdev). The last one has nothing to do with Linux user
space.
> If I want to develop a RealTime-driver with
> POSIX Standard, should I register the same way or shall I use
> rtl_register_chrdev. If I use rtl_register_dev alone, my normal
> application is not able to open the device using
> open("/dev/sampdrv",0);.
Exactly - and that's intentional, as you can't (easilly) use the same
driver callbacks to deal with requests from both Linux and RTL. (Those
synhronization constructs, and the fact that the callbacks will be
preempting Linux when called from RTL threads...)
> (3) I want to use IOCTL based communication apart from FIFO and MEM
> buf. How should I do this.
You implement the driver calls as usual for Linux drivers, but using RTL
IRQ spinlocks (that disable the *real* interrupts on the local CPU) or
similar, to keep RTL threads from interfering with your callback code.
Do note that the Linux driver calls are running at Linux priority (lowest
priority RTL thread) - no priority promotion is done! (That's why you
have to use the RTL IRQ disabling versions - if you use standard
spinlocks, or *any* kind Linux spinlocks, the RTL scheduler may come in
and switch your callback out while holding the spinlock, and BANG! - your
RTL driver ISR or thread hangs your system, waiting for that spinlock to
be released...)
> (4) From the beginning of my development I can see information about
> comedi. Should I use comedi for implementing my driver or can I have my
> own method of implementing.
You *can* do anything you like ;-) - but the best way is to use the right
tool for the job. If your driver fits in the "driver model" and scope of
Comedi, sure, it might be the right tool. If not, you can probably still
learn a lot by looking at the code.
> (5) Is there a specific standard for developing RT-Linux driver.
Not really; probably even less of a standard than there is for standard
Linux drivers. Standard Linux drivers basically come in only one form;
kernel space drivers to be used from user space, via the
open()/close()/mmap()/read()/write()/ioctl()/... interface. For RTL
drivers, there are many more ways, for example
* RTL driver for use via direct calls from RTL threads
* RTL driver for use via rtl_posixio
* RTL driver for use from Linux user space via mbuff() and/or RTL fifos
* RTL driver for use via standard Linux user space driver API
* RTL driver with custom userspace syscall API
* Linux driver (or wrapper) with (non-blocking) rtl_posixio API
* Any combination of the above.
//David Olofson --- Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
-- [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/
