RTEMS Executive vs. Kernel
joel at rtems.org
Fri Jan 25 22:43:41 UTC 2019
On Fri, Jan 25, 2019 at 7:03 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:
> On 24/01/2019 00:24, Joel Sherrill wrote:
> > On Wed, Jan 23, 2019 at 2:01 AM Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at embedded-brains.de>> wrote:
> > On 23/01/2019 08:11, Chris Johns wrote:
> > > On 23/1/19 5:50 pm, Sebastian Huber wrote:
> > >> On 22/01/2019 23:42, Chris Johns wrote:
> > >>> On 23/1/19 5:34 am, Joel Sherrill wrote:
> > >>>> I don't object.
> > >>> Is executive the right abstraction? Both terms are an
> > abstraction because we
> > >>> have a single address space and literal or formal
> > interpretation breaks down. I
> > >>> see the physical separation as an implementation detail.
> > >> Real-Time Executive for Multiprocessor Systems or RTEMS already
> > has executive in
> > >> its name.
> > > The name has evolved over time.
> > The M had two meanings before Multiprocessor. That's the only change.
> > We shall NOT
> > discuss the previous two since those were poor choices that biased folks.
> > I found the original published paper on RTEMS. It was presented in
> > August 1990
> > and the text version is at:
> > https://archive.org/stream/DTIC_ADA247043/DTIC_ADA247043_djvu.txt
> > It is clear there that kernel and executive were considered equivalent
> > terms.
> > It is also clear that operating system is used about as many times as
> > either
> > term. I did not re-read the paper to see if we used executive/kernel
> > to refer
> > to a core set of services and OS to refer to a larger collection.
> > https://en.wikipedia.org/wiki/Kernel_(operating_system) is an
> > interesting read.
> > Kernel is a valid term for us to use per that. A couple of quotes from
> > the early
> > part of that ignoring the IO devices mentioned. This is the first
> > sentence.
> > "The kernel is a computer program that is the core of a computer's
> > operating system,
> > with complete control over everything in the system. On most
> > systems, it is one of the
> > first programs loaded on start-up (after the bootloader). "
> > The above matches my stated view that there is a core set of services
> > that support
> > others. The collective is the operating system. For the purposes of
> > this discussion,
> > the rtems.git repo unfortunately contains the kernel and some OS
> > services. So the
> > repo is not purely the kernel layer. It is the kernel plus core
> > services and libraries.
> > "The critical code of the kernel is usually loaded into a separate
> > area of memory,
> > which is protected from access by application programs or other, less
> > critical parts
> > of the operating system. "
> > The key point of the above sentence is "usually". This is in deference
> > to UNIX
> > and Windows which do have separation. The kernel is a logical
> > abstraction which
> > may have the property of separation.
> This wikipedia article clearly talks about kernels that use protection
> mechanisms and system calls.
But it starts by starting that kernels may have protection. Kernel is
an organizational construct.
> Apart from that, you all seem to favour "kernel" instead of "executive".
My gut feeling is that executive is an old term that many people won't
recognize anymore. We have to explain it because of the E in RTEMS.
But in our historical use, executive and kernel were interchangeable.
As Chris pointed out, we reviewed a few pages of the docs together
and you can't do a search and replace. Sometimes OS is better,
sometimes kernel is better. Sometimes the sentence shouldn't
> While searching on the web I found a PDF of the Real-Time Executive for
> Missile Systems C Application User's Guild.
Shh.... wrong M. :)
We have a full shelf of old reports. A few would be good to have
mirrored at ftp.rtems.org if DTIC has them.
FWIW DTIC == Defense Technical Information Center and it seems
to have a number of DoD/DARPA research efforts using RTEMS plus
a handful of the original reports.
> It doesn't look that much different to the current Classic API guide.
There is a good reason for it not looking much different. OAR wrote it. It
in Lotus Ami Pro and converted.
By 1995, Army support for the Army had been stopped for a while. RTEMS
source code was available via CVS in May 1995. But the documentation being
in a closed source tool was an issue and it bothered me. In November 1995,
Huntsville had an ice storm with 11 inches of ice. Pictures are in this
I was trapped at home even after some thaw by a huge ice wedge at bottom of
driveway. My driveway had a serious slope to it.
Anyway, I used the time trapped at home to convert the Lotus Ami Pro
to Texinfo and make it available. The Classic API hasn't changed that much.
picked an organization for each manager chapter that was good. So that's how
we got here.
> Sebastian Huber, embedded brains GmbH
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel