Guilherme Nelson DeSouza wrote:
> Hi,
>
> I am not quoting any particular email from this thread, but
> from what I could see, most of our problems could be easily
> solved in a bar, around a table, over a few bottles of beer
> (or wine, since I for one don't like beer). :-)
>
> In fact, I am quite sure these problems will be solved during
> the Workshop that is being promoted here in this list (by Peter
> Wurmsdobler and others).
I agree. I have great respect for all the personalities, and just want
to see at a minimum a unified API. My best case scenario would be to see
the two source trees merged. One possiblity (mentioned earlier by
someone on the list) is maybe to look at the EL/IX proposed by Cygnus.
I have not looked at this but it sounds as though its an attempt to come
up with a unified API for RT/embedded based on POSIX. This may be a way
ahead on the API issue if examination shows it to be usable. Before
this I would suggest at least we resolve the differences between the
current API's (see below).
>But in the meantime, we should notice
> that from what one can tell by following this thread, each and
> every one of the members of the list, specially those devoted to
> developing and maintaining "their" softwares, have genuine good
> will. And even more important, they all seem to agree upon:
> 1) unifying the API; 2) maintaining the software under a GPL;
> 3) developing the new required (important) features (IPC, FP,
> synchronization, etc) very *efficiently*; and so on. What is
> missing now is to define a list of "TODO" things, and their
> priorities.
>
Agreed.
>
> Here it goes...
>
> ------------------------------------------------------------------------
> | | IPC | Semap. | Sched. | Posix | FP | OSource | Kernel | 486 |
> ------------------------------------------------------------------------
> | | | | | | | | v1 for | |
> | | | | oneshot| | | | 2.0.x | only |
> | RTL | n | o | | y | y | y | v2-beta | in |
> | | | | period.| | | | for | v1.x |
> | | | | | | | | 2.2.x | |
> ------------------------------------------------------------------------
> | | | | | | | | | |
> | | | | | | | | | |
> | | | | | | | | v.6 for | |
> | RTAI | y | y | oneshot| o | y | y | 2.2.x | y |
> | | | | | | | | | |
> | | | | | | | | | |
period
> ------------------------------------------------------------------------
>
> y - embeded in the RT modules
> n - not implemented
> o - optional (it can be "insmod'ed" separately)
Note, in RTL POSIX is not a separate loadable module.
>
> Please, suggest other colunms and correct any thing wrong on
> the existing ones.
>
> b.r.,
>
> Guilherme
API comparison
==============
As you will see, most of the original API is similar but different (not
better or worse). To solve this, I would ask that the calls be changed
to rt_xxx, which is neutral to keep all parties happy. Some calls are
not a 1:1 mapping, and I need input from others (Victor/Paolo) as to the
best way of bringing them in-line.
(this list is just what comes to mind, it is not complete)
set up peridic mode
------------------
RTL:
RTIME task_ticks;
task_ticks = (RT_TICKS_PER_SEC/FREQ);
rtl_set_periodic_mode(task_ticks);
RTAI:
RTIME task_ticks;
rt_set_periodic_mode(void);
task_ticks = nano2count(1000000000/FREQ)
start_rt_timer(task_ticks)
Tell Linux you will be using the FPU
--------------------------------------
RTL: ??
RTAI:
rt_linux_use_fp(1)
initialise a task
-----------------
RTL:
rt_task_init( RT_TASK *task,
void (*fn)(int),
int data,
int stack_size,
int priority )
If it uses the FPU, add:
rt_task_use_fp( RT_TASK *task, 1 )
RTAI:
rt_task_init( RT_TASK *task,
void (*fn)(int),
int data,
int stack_size,
int priority,
int uses_fpu,
void (*signal)(void) )
set a (periodic) task running
-----------------------------
RTL/RTAI:
rt_task_make_periodic( RT_TASK *task,
RTIME start_time_ticks,
RTIME period_ticks
)
suspend a running task until the next tick
-------------------------------------------
RTL:
rt_task_wait(void)
RTAI:
rt_task_wait_period(void)
cleanup/stop a task
--------------------
RTAI: stop_rt_timer(void)
RTL/RTAI: rt_task_suspend(RT_TASK *task)
rt_task_delete( RT_TASK *task)
create a fifo
--------------
RTL:
rtf_create(unsigned int fifo, int fifo_size)
RTAI:
rtf_create_using_bh(unsigned int, int size, 0)
NOTE: both can be used with the simple rtf_create, but the behaviour is
different. Under RTAI, a user task will only be woken up at the next
run of schedule (this is an intended feature). To get the same effect
of waking up as soon as possible, use the above code.
put data to a fifo
-------------------
RTL/RTAI:
rtf_put(unsigned int fifo, void *buf, int count)
get data from a fifo
----------------------
RTL/RTAI:
rtf_get(usigned int fifo, void *buf, int count)
destroy a fifo
---------------
RTL/RTAI:
rtf_destroy(usigned int fifo)
Filename comparison
===================
Another problem is the name and location of files. This means that
Makefiles and code has to be changed to locate the different include
files. I would propose having a standard path for the RTL/RTAI
location (via a link). For instance, how about under /usr/src make a
link called rt to either RTL or RTAI depending on choice. This would
allow users to always use -I /usr/src/rt to include headers.
The header file names themselves could be renamed to be common, e.g
rt_fifo.h, rt_sched.h etc.
Header names
-----------
RTL:
rtl_fifo.h, rtl_sched.h
RTAI:
rtai_fifos.h, rtai_sched.h
Note: in addition you must also include rtai.h first for RTAI.
Module Locations
---------------
Following the previous scheme, the modules could then live in
/usr/src/rt/modules. In the long run, it would be better to have them
in /lib/modules/xxx/rt and then have an entry in /etc/modules.conf to
get them to autoload.
Currently, RTAI has a modules rtai that (IMHO) should be moved down into
the modules subdirectory along with the rest.
Module Names
------------
I would like to see both RTL/RTAI follow the convention of having a .o
suffix for module names (like the regular kernel modules). I would also
like to see them have common names e.g rl_sched, rt_fifo to make the
setup of a system simple and consistent. I'm not sure what to do about
the RTAI base module.
base module
-------------
RTL: none
RTAI: rtai (in the directory above modules)
scheduler
---------
RTL: rtl_sched
RTAI: rtai_sched
rt fifos
---------
RTL: rtl_fifo
RTAI: rtai_fifos
Please add/subtract/correct where necessary.
Regard
Stuart Hughes,
Zentropix.
--- [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/
