Re: Directory Structures - was: Re: [realtime] Re: [rtl] RTAI experiences, or: The Cathedral and the Baazar, part #2

[Jochen Kuepper <jochen@uni-duesseldorf.de>]

On Mon, 20 Dez 1999 Bernhard Kuhn wrote:

>I would even go a step further and like to discuss the following idea:

Well, I am not sure I am entirely happy about that.

>IMHO, it would be a good thing to split the RT-package (both, rtl or rtai)
>into packages:
>
>1) one package for the basic stuff, like schedulers, fifos, etc.
>   that should be entirely be a patch to the standard linux
>   source tree ...that's the way things are usualy
>   done ... (have a look at MOSIX, ReiserFS, etc.)

Well, actually the patch should be as small as possible. And fifos,
schedulers aren't part of that base-package in your definition :-O

>   Sorry, Paolo. I know, you don't like patches ... but it is
>   realy only one shell-command needed to generate a diff!

It doesn't actually matter wether it is called patch or copyto.
I personally prefer the "diff -u" output because to me its simple to read.
But then I don't see any other disadvantage of the copyto besides it not
being common usage.

>   We could have a structure like this:
>
>   /usr/src/linux/Documentation/rt/   
>   /usr/src/linux/include/linux/rt/
>   /usr/src/linux/arch/i386/rt/
>   /usr/src/linux/arch/ppc/rt
>   /usr/src/linux/arch/m68knommu/rt/
>   /usr/src/linux/rt/schedulers/
>   /usr/src/linux/rt/fifos/
>   /usr/src/linux/rt/semaphores/

That would be a big change to standard linux ! And we agreed to keep the
Linux kernel changes as small as possible, didn't we ?
I would suggest to keep as much as possible outside /usr/src/linux !

>   "rt" isn't yet occupied in these directories, and may
>   stand for "rt-linux" and "rtai" as well :-)
>   also, it isn't necessary to have a "linux" after "rt"
>   as Jochen suggested it, as, in this case, "linux" is
>   already included in the full path :-)

Yep. But then I have seen way to much FORTRAN code to like that
two-character variable. Probably call it "realtime" :-!

>   Additionaly, many of the auxiliary subdirectories could be
>   unified for both, rtl and rtai (i.e. mbuff, rtl_rtai_fifos, etc.)

Absolutely - if everybody agrees to use the portable fifos, ... .
Probably we should simply let anybody use whatever he uses, let
everybody put into /usr/src/realtime/ whatever he wants, but simply define
an _interface_ in /usr/include/realtime (or whatever directory).

The /usr/src/realtime/realtime.h could define what system is running
(NMT, RTAI, ...), as well as define what schedulers, fifos, IPC,
POSIX, ... stuff is available. Depending on that other includes are
available or not. And that would define the whole API !
No need to tell the application where the source code is - or does your
"Hello World" care where it can find libc sources ?

>2) one or more package for demos and related detailed documentation, i.e.
>
>   /opt/src/rtapps/sound
>   /opt/src/rtapps/hello
>   ...
>
>   Ok, maybe a native speaker has a better namen then "rtapps" :-)

Well, not native, but I would suggest
"/usr/src/realtime/rt_posix/examples/" (v.i.:-)

>   Anyway. Based on Zentropix's efforts to have a POSIX-wrapper on
>   top of rtai, this demo-package could be fully unified.

No ! There definitely must be simple-API examples !!!
Oh, I see. Yes, we can provide an unified POSIX example package,
still let's put it into /usr/src/realtime/rt_posix/examples/ :-)

>   Stuff, that is strictly based on the rtai-native API should
>   go into a seperate tree:
>   /opt/src/rtaiapps

Agreed, but put it into /usr/src/realtime/rtai/examples.

>   or whatsoever. Examples and apps for RTLinux V1.x could have their own
>   /opt/src/rtlapps

/usr/src/realtime/rtl/examples

>   or the native APIs of RTL1.x and RTAI could be unified to only have a
>
>   /opt/src/rtapps_np

Well, let'sstill put them into each directory, even at the cost of
possible duplication :-)

>   or similar (RTL1.x shouldn't be forgotton, since many companies
>   prefer linux-2.0 for developing embedded systems due to
>   a slightly smaller memory footprint)

And less bugs :-)

>> Of course people have to
>> realise that the resolution of the (8254) timer is 1/1193180 so you
>> don't get exactly what you ask for.  Hopefully when other ports appear
>> on platforms with better timers the discrepancy between nanoseconds
>> asked and actual will be far less.
>
>We really should only stick to nanoseconds, especialy when
>there will be RT-ports to non-86x-CPUs. Fiddling around with
>different clock speed on different architectures will
>drive you crasy :-)

It was pointed ut before that there is something like a get_resolution in
POSIX, IIRC. That does help - if it is made well-public.

Please reconsider that I put all stuff underneath a common
/usr/src/realtime/ directory - my /usr/src needs some kind of garbage
collection already !

Cheers,
-- Jochen
        Heinrich-Heine-Universit”t, Institut f¸r Physikalische Chemie I
        Universit”tsstr. 1, Geb. 26.43.02.29, 40225 D¸sseldorf, Germany
phone 02118113681 fax 02118115195  --  www-public.rz.uni-duesseldorf.de/~jochen
Jochen@Uni-Duesseldorf.de -- Jochen.Kuepper@FernUni-Hagen.de -- Kuepper@ACM.org
--- [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/