[Date Prev][Date Next] [Chronological] [Thread] [Top]

[rtl] Re: Directory Structures

Bernhard Kuhn wrote:
> 
> 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
> 

I agree with this idea, but I would like to include RTAI into this
structure.  So I would suggest (I normally use relative links, but for
clarity):

/usr/include/rt  -> /usr/src/rt/include

/usr/src/rt      -> /usr/src/rtlinux-2.0/rtl
/usr/src/rt      -> /usr/src/rta-0.7

The reason for this kind of linking for RTL is that when building
applications, there is no need to get at the top level of rtlinux-2.0
and it helps the links simple for both, e.g you can just say
-I/usr/include/rt in your make file.

Note also, that when I install RTL, I don't untar linux into the
rtlinux-2.0 directory, I prefer to have the following

linux -> ../linux-2.2.13_rtl2.0p2

This is just a preference, but so far it has enabled me to support many
differing concurrent installations.


> 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!


A patch in addition to a copy to would be a simple thing to do.  I think
one of the main points to capture is also that the minimal intrusion in
the style of RTAI RTHAL patch makes it easier to keep pace with the main
Linux kernel developments.  This is important as it may be a long time
(if ever) before the RT stuff is put into the kernel proper.  We all
acknowledge, absolutely, the work of Victor and Michael, but as a pure
matter of pragmatism, maybe this less intrusive approach could be
considered by the RTL guys.

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

I would prefer not to pollute the kernel source tree, but if it comes to
pass, I would like to see it as symbolic links and not copies.  My
reasoning is that it would make the upgrade easier as often the basic
patch does not change.


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

Agreed,  I think the adoption of a neutral rt name would be helpful.


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

Agree.


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


Sounds reasonable.

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

I agree with the thrust of the argument.  I would say that we should try
to agree a unified NMT1.0/RTAI API.  If this means changing/adding some
calls, then we need to do this.  I suggest that the way to do this is
via a common_api module that constructs the common API from the
available resources in NMT/RTAI.  As you suggest, for things that are
strictly NMT1.0 or RTAI they can have their own named directories.

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

Agreed, nanoseconds are easier to understand for most people.

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/