Re: [rtl] RTAI experiences, or: The Cathedral and the Baazar, part #2

[Stuart Hughes <sehughes@zentropix.com>]

Hi Bernhard, 

See inline for my impressions

Bernhard Kuhn wrote:
> 
> Hi!
> 
> I just tried RTAI0.8 and maybe somebody is interested
> in the experiences i have made ... :-)
> 
> Installation:
> -------------
> 
> Not very complicate, although the source-tree
> looks a little bit "dearranged". After unpacking
> the .tgz, you have just to do "./copyto" within the
> rtai-0.8/linux-2.2.13 directory.
> It's a little bit confusing, that the README
> says that "irq.c" will not copied (although it is).
> 

Agreed, the doc should be updated.


> Also i wouldn't recomend that the installation-script
> is copying the stuff straight to /usr/src/linux-2.2.13/...,
> since the usual way is to have a link from "linux" to
> the approporate directory, i.e. "linux-2.2.13-RTAI0.8".

This is a diffult one, as copying to /usr/src/linux may mess up another
linux source tree that happens to be pointing somewhere else.  The main
thing is that some check is made to where you are copying to to make
sure that 

a/ it is the right version
b/ it has not already been patched.

One possibility is to do a diff before the copy to make sure that the
file to be overwritten is exactly the one you expect.

> 
> I realy suggest to invent a kernel-patch instead
> if copying whole files.

A patch does certainly have some advantages (as it helps avoid
re-patching), but the copyto method also has the advantage that is is
easier to see the files effected in whole.  I think it would be easy to
provide a patch with the distribution as well as the copyto. 

 With that, it would be
> possible to add the "EXTRAVERSION=-RTAI0.8" in
> the toplevel-Makefile automaticaly (prevents you
> from overwriting the moduels in "/lib/modules/2.2.13" -
> they should preferably be copied to "/lib/modules/2.2.13-RTAI0.8").

Agreed, apart from the points you make, I want to have some means of
identifiying what flavour I have so I can write portable applications
that can work on RTL or RTAI.  Currenly I look for /usr/src/rtl/rtai,
which is far from safe.


> 
> Additionally, it is a little bit disturbing, that
> the Makefiles included in RTAI don't have an "install"
> option, so that the modules are not copied to i.e.
> "/lib/modules/2.2.13-RTAI0.8/misc" automaticaly.

On this point, I would like to propose that we do the following for
installation:

1/ Make all installations via links rather than copying (although this
is less important for modules).

2/ Until we have an approved localtion in /lib/modules/.../ put the rt
modules in the misc directory (like in RTL V2).  This means that you
just have to request insmod <modulename> without worrying about the
location

3/ I would like to see all modules have the .o extention, inline with
all other linux modules.

4/ I would like to see access to the include files be through
/usr/include/realtime (or any other name that is acceptable to both
Victor and Paolo).  I believe that this should be a link, and not a real
directory.  This is importand so that it is easy to switch between
different installations, in the same way that people move their
/usr/src/linux link.

> 
> But not to be nitpicking, at least, it only took me one
> hour to get the things going (running the simple sound-demo) ...

This is purely a question of familiarity, the first time you do anything
it can be slow.

> 
> BTW: is it mandatory to do the cpu and latency
> calibrations? It did seem to work well for me without
> performing that ...


The CPU calibration is mandatory, but it can be done simply by typing
'make calibrate' in the RTAI base directory, this uses the value of CPU
frequency for /proc/cpuinfo, which is adequate for most users.  For more
precision you can use the module in cpu_freq_calibration directory.

Personally, I would like to see the CPU calibration be automatic at run
time, in a similar way to RTL,  I run my installations on a variety of
machines, and this would allow me to run without doing a 'make clean,
make calibrate, make all'



> 
> Porting from RTL to RTAI
> ------------------------
> 
> At a first look, the "Name-Spaces" of the
> RTAI-functions seem to be a little confusing,
> but you get used to it, very fast.
> 
> After playing around with the basic task-functions
> (start, stop, sleeping etc.) for an hour or so, it took me
> only an additional hour to port the pcmsound-demo to RTAI.
> 
> Since the FIFO-functions of RTAI and RTL are exactly
> the same (except the name of the header-file to include),
> you don't have to care about that.
> 
> Conclusion:
> -----------
> 
> RTL and RTAI are not that wide appart that an "unification"
> is impossible. But i have the impression, that both
> projects have contrary philosophies, like they are
> described in "the cathedral and the bazaar"
> (written by Eric Remond?)

I would like to see a unification on at least the level of RTL V1/RTAI
API.  This should be discussed.  My first comment would be that I would
like to see the timing services simplified so that everything can be
specified in nanosecond without the user having to worry about clock
ticks.

> 
> RTL: Victor Yodaiken is going the "cathedral"-way, means,
> you have a centralized code merging institution that
> strictly doesn't accept what doesn't fit into
> the predefined model (here: Posix-compliance)
> and what wasn't intensivly peer-reviewed.
> Advantage: well defined API, high stability
> Disadventage: progresses need more time to occour.
> 
> RTAI: Paolo Montegazza is doing the "bazaar"-method, means,
> he puts everything into the source-tree, that might
> be usefull for somebody (but also having a deep look
> into it).
> Advantage: fastly increasing functionality
> Disadventage: everything looks a little bit "dearranged".
> 

With the help of the community, the mechanics of layout, installation
etc can be made cleaner.  I believe there is a will by many to help with
this effort.


> Now, lets have a look at the history:
> IMHO, RTL compared to RTAI is a little bit like GNU-HURT
> compared to Linux. We all know, that GNU-HURT doesn't get
> the respect that it should have. That is because their
> inventors (R. Stallman??) didn't payed much attention
> to the needs (functionality) of the community, but wanted
> to do it perfectly. L.T. acted more like Paolo is doing it
> nowerdays.
> 
> Question: which of the two - GNU-HURT or Linux - is going
> mainstream these days? ...
> 
> just my 0.02 Euro
> 
> Bernhard



Regards, Stuart

--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/