On Wed, May 17, 2000 at 11:06:40AM -0700, Matt Cheselka wrote:
>
> Dave, maybe I'm really missing something here. I'm referring to the
> drivers in comedi-0.7.xx/comedi/drivers/*.c. Nothing in this source code
> makes any mention of RTL or RTAI. The only things that do are actually in
> comedi-0.7.xx/comedi/rtl.c and comedi_fops.c. The problem here is that
> stuff like comedi_rtl_init() -- which to me sounds like a pretty important
> function -- doesn't DO anything (everything is commented out)!!!
Im my opinion, a good driver should simply do what it needs to do, and
get out of the way of the operating system. The individual drivers
are also somewhat OS independent, in that anything that is different
between OSs is moved into the comedi core, and properly #ifdef'd.
> What you're saying (and please please please excuse my stupidity if this
> is wrong) is that comedi is already 'wired' to run under RTL or RTAI and
> nothing has to be done to a particular driver except to modify it so it
> becomes incorportated into comedi (attach, detach, subdevices,
> etc). Meaning, I don't need to put any rt_task_init(),
> rt_task_wait() stuff into my driver.
Yes. Drivers work automatically with RTAI and RTL, provided that they
don't do anything "RT-stupid", that is, call kernel functions that are
not real-time compatible, register interrupt correctly, don't have any
unbounded waits, etc. Hardware drivers in comedi are actually _really_
simple -- just a collection of functions that are called by the Comedi
core to do specific jobs.
Ask yourself why the driver is running a task. Is this really a driver,
or an application/driver combination? I prefer to make drivers as simple
as possible, so starting a task seems too high level. I can think of
reasons why you might want a task, but not in a data acquisition driver.
> I guess I have some confusion about what's going on in comedi/drivers and
> comedi/realtime.
comedi/realtime contains two "virtual drivers" that are actually applications
disguised as drivers. They use real-time tasks to emulate features that
exist on higher-level data acquisition boards. It's kind of cool to use
them every once and a while, but if you are doing serious work that requires
such features, it is better to buy a real board. However, they make nice
examples if you are writing applications that use Comedi.
> If the above paragraph is true, can you point me to where comedi decides
> that a driver is to be run in RTL or otherwise?
The driver is not "run in RTLinux" as you say. The application calls comedi
from RTLinux. Comedi calls the hardware driver. The driver doesn't do
anything RT-stupid. Thus, the driver works in real-time.
(I will readily admit that comedi drivers do many things RT-stupid, but it
is not generally an issue. Writing real-time drivers is a continual learning
process.)
dave...
-- [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/
