On Tuesday, March 09, 1999 3:35 AM, Paolo Mantegazza
[SMTP:[EMAIL PROTECTED]] wrote:
> Hi,
>
> while debating about robots it came out the concept of Hardware
> Abstraction Layer (HAL) and Venturcom/Radisys Real Time Application
> Interfaces (RTAI) to it.
>
> This suggested to me that it is perhaps the time to debate about
> RTLinux/Linux architecture. The hope is that, while keeping clear the
> primogeniture of the friends at NMT on RTLinux, RTLinux could become a
> real joint development effort in the Linux bazaar style, and not just a
> bunch of people using blindly what others gurus made available, eagerly
> waiting for patch updates when new kernel releases are made available.
> Personally I could warrant that if this was the spirit in the past, the
> RTL community would have add a working fpu support, and even a far
> better and effective oneshot scheduling, 6/8 months in advance.
>
We are dealing with real-time => a peanalty for missing responce or late
responce that is not acceptable. I support tighter controls on the code put
into the RT in RTL rather than a bazaar. Even Linux has its keeper and it
is for this reason (reliability of new code). I personally feel as if I
could submit any code to V.Y. and if it was good code that did something
usefull it would be integerated into the kernel. Please V.Y., correct me if
I am wrong on this point as I have never submitted new code to you (yet)
but I do have some to submit soon.
> With the advent of 2.2.xx people are starting to ask for the inclusion
> of RTL patches natively in Linux, and here I'm back to the HAL/RTAI
> concept and to the hope of starting a constructive debate within this
> community.
> In fact the HAL/RTAI architecture is the one to pursue. To support the
> point we started an independent development effort that is now matured
> in a prototype that works on UP and dual processors.
>
I have not looked at that standard but I also believe that OPEN standards
are worthwhile.
> To this aim, and to roughly explain what is all about, I drafted the
> text below as the introduction to a possible install file. Let's see the
> response, if any.
>
> >
> ................... This file contains the list of changes to be made to
> a few Linux files to set
> up a Real Time Hardware Abstraction Layer (RTHAL). It consists mainly in
> establishing a set of pointers to some bsic functions and data
> structures that can
> subsequently be modified by the Real Time Application Interface module
> (RTAI)
> to trap Linux interactions with the hardware, so that both can be made
> your
> slaves.
>
> The decision of making available a list of changes to the Linux kernel
> instead of a patch has been preferred as, even if at a first look this
> choice may seem less comfortable than a patch, it allows you to be in
> full knowledge of what's going on and to fully understand the RTAI
> implementation.
I like the idea of making changes my self but see that a patch could also
be distributed that would do it for me after I crash the system and wipe
out the disk for the tenth time that morning.
Stoped here on my commenting. I think that this is a great direction to
pursue but there will need to be someone to spear head it. Are you asking
to be that someone and if so what experience / contacts do you have that
make you believe that you will be able to be successful (besides my
support). I would like to see what NMT has to say on this :-).
> In this way you are made completely independent and can readily update
> to
> future kernel releases, as it has been proven by using this file from
> 2.2.0-pre1.
> It appears to be a long file but that's due only to the duplication of a
> lot of, unchanged, code to, hopefully, spot easily where and why the
> changes are made.
> Once you share this idea, without any apriori bias, it will take more
> time to read it than to implement it, i.e. about 10 minutes to carry out
> all the stuff.
> Please read it and signal any constructive comment back to me.
>
> Apart from the changes below it remains to verify if various readings of
> the 8254A timer (in timer_interrupt.c, hd.c, ide.c .....) are used by
> Linux in its current duties, and not only at boot initializations.
> For now it is sure that in timer_interrupt the 8254A is used
> continuously
> but the kernel seems to work even without making any modification. See
> the
> comments to timer_interrupt below if you feel unsafe in leaving the
> things
> unchanged.
> However this is a point to be watched out carefully, even if right now
> it seems a non problem or, at least, no arm is done to Linux by
> modifying the 8254A counter-0 pacing, as in the periodic timer available
> in this distribution.
>
> As already said rtai.c is just an example of implementation of an RTAI,
> by
> using some basic functions there you can go your own way or, if you
> want,
> reprogram them in a better way. I'm one of the amateurish c-programmer
> guys.
> You could even use it to attach some OSS real time "operating systems"
> to
> Linux.
> At the Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano
> (DIAPM) someone is thinking about using Cygnus ECOS, and RTEMS perhaps,
> as the final real time server attached to rtai.c. I'm resisting the idea
> only because I want to support my RTL variant, but it can be a very
> smart and effective one.
>
> The power of the approach is demonstrated by the easy porting of
> NMT-RTLinux
> fifos to rtai.c for UP-SMP applications, without touching the kernel,
> while
> allowing you to use any Linux task queue; instead of adding a new queue,
> tq_rtl, that does nothing but what the slowest of the available queues,
> tq_scheduler, already does.
> It is also possible to use wake_up_interruptible directly. In this way
> you'll discover that fifos are programmed very efficiently by Michael,
> can be very fast and allow to avoid using shared memory, with a minor
> efficiency loss but, bu with a far easier development work.
> (On a dual PII 350, 64 MB RAM, a real time simulation of a control
> application carries out 90Mflops, 45 on each cpu, at 1 Khz producing a
> 5MB/s log, that a front Linux process sends to a 5400 rpm disk, without
> loosing bytes under mild forground load, just using the usual, but
> modified, fifos; max jitter about 30 us).
>
> It is believed that this approach is more flexible and should be the way
> Linus-Linux goes to natively make hard real time available within the
> standard distribution, istead of taking a lot of unneeded patching in
> the basic Kernel.
> It requires just a cleaner design of some functions and related
> pointers, and it seems that 2.2.xx has already carried out a good great
> leap forward along this direction. There is space for improvements
> however.
> After all nobody will ever forbid making available many different RTAI
> modules within the official distribution, configurable with the usual
> "make config".
> Moreover the concept can be a template for easy porting of RTAIs to any
> other architecture.
>
> In fact most of the changes, from the basic interrupts handlers macros
> upward, made to the Kernel by NMT-RTLinux are believed to be unedeed, we
> change just about ten lines of the kernel while adding a few tens more,
> without any visible performance degradation with respect to NMT-RTL.
> It can be verified that most of the jitter and timing uncertainties do
> not come from short interrupts disables, the longest one in rtai.c is
> likely to be due to the mask_and_ack_8259, up to 4-5 us, while the
> actual jitter can reach 30 us under heavy Linux foreground usage and is
> mostly related to loss of cache coherency between interrupts. In fact a
> heavy load implies a wider motion through the memory with consequent
> cache misses.
> That seems to be worse in full symmetric processing as, even if Linux
> tries to schedule a process on a preferred cpu, under heavy load
> processes
> tend to continuously change the cpu on which they execute thus straining
> the
> cache more than on a UP. Another important factor seems to be the mother
> board.
> Our, maybe poor, experience seems to show that it is difficult to do
> something better, as this is the real bottleneck in using PCs for high
> frequency hard real time applications.
> So be warned that even those commercial systems that claim a few
> microsecs
> max latency in practice cannot achieve it.
>
> Clearly there is nothing new here, as the HAL concept is adopted by
> Cygnus-ECOS and MS-NT which, even if Linuxers do not like the latter,
> exploit a very good idea. I think that something similar can be found
> also on Alphas Privileged Architecture Library code (PAL). Perhaps it is
> not
> strange that MS-NT has been a native OS for Alphas.
> The plus of Linux is source code availability, that allows you to feel,
> and
> effectively be, the master of everything, so that you are fully
> empowered
> without depending upon anybody. Furthermore it is a lot of fun to crash
> your
> system, isn't it? (Someone think that it's pure madness at the highest
> levels). .................................................
> >
>
> Ciao, Paolo.
> --- [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/
--- [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/
