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

[Bernhard Kuhn <kuhn@batian.lpr.e-technik.tu-muenchen.de>]

Stuart Hughes wrote:

[was: includes-path]

> my only extra suggestion is that the includes
> be via a link at some point (in the same way that /usr/include/linux and
> /usr/include/asm are).

I would realy appreciate a Link. Something like this, for example:

/usr/include/rt -> /usr/src/rtlinux/rtl/include
/usr/src/rtlinux -> /usr/src/rtlinux-2.0

So that it is a little bit more similar to the linux-source tree.


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


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.)

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

   "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 :-)

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


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" :-)

   Anyway. Based on Zentropix's efforts to have a POSIX-wrapper on
   top of rtai, this demo-package could be fully unified.
   Stuff, that is strictly based on the rtai-native API should
   go into a seperate tree:

   /opt/src/rtaiapps

   or whatsoever. Examples and apps for RTLinux V1.x could have their own

   /opt/src/rtlapps

   or the native APIs of RTL1.x and RTAI could be unified to only have a

   /opt/src/rtapps_np

   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)


    

> 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 :-)
For those, who need it, there should be native nano2count()- and
count2nano()-Functions like in RTAI (or were they introduced in
RTL - cannot recall).


Comments?

Bernhard
--- [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/