RTEMS Executive vs. Kernel

Wed Jan 23 23:24:36 UTC 2019

On Wed, Jan 23, 2019 at 2:01 AM Sebastian Huber <
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.[1] 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.

Executive was used in the olden days of yore to refer to small RTOSes.

http://www.drdobbs.com/a-simple-real-time-executive/184402613 presents
TinyExec
and uses the real-time executive term repeatedly.

For those who remember it, VRTX stands for Versatile Real-Time Executive
which
is the Vx in VxWorks which originally meant VRTX Works.

Google "real-time executive" and you will see other examples in addition to
RTEMS.

Executive is meant in the sense that it manages concurrency and
synchronization.

Nucleus and ThreadX refer to themselves as RTOS.

uCos uses the term real-time kernel.

Ironically, even the POSIX standard includes the terms real-time executive,
kernel, and RTOS in
http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/xrat/V4_xsh_chap02.html

My point here is that there really is a precedent here and kernel does not
automatically
imply protection.

> >
> >> I don't think that the kernel/user space separation and system calls
> >> are an implementation detail. It is a hardware enforced feature which
> >> characterizes a whole group of operating systems. The name kernel is
> quite
> >> overloaded.
> > It sure is.
>

We may use it in an overloaded manner but it has a pretty solid meaning
as the provider of core services in an operating system. With or without
protection.

> >
> >> I would like to avoid that someone thinks about RTEMS as a micro
> >> kernel which would be totally wrong.
> > I think there will always be a level of confusion.
>

This has never been a problem in the past.

> >
> >>> Which term is the better abstraction of what the rtems.git repo is?
> This is the
> >>> critical piece to resolve.
> >> Ok, this is a different issue. The problem is that in rtems.git is a
> collection
> >> of different things. It contains the RTEMS executive (everything which
> deals
> >> with threads, interrupts, synchronization and inter-thread
> communication), a
> >> legacy network stack, file systems, device drivers, memory allocators,
> >> compression libraries, hash libraries, shell, etc. I think calling this
> stuff
> >> "kernel" is imprecise.
> > It is imprecise but what is a precise single word or term to explain
> this?
>
> I am not looking for a precise single word to cover this whole stuff. I
> just want to get rid of kernel in the documentation which is used for
> this and that. I would like to use executive for the RTEMS component
> that deals with with threads, interrupts, synchronization and
> inter-thread communication.
>

This set of services matches what Wikipedia's definition of kernel provides.
And this from Stack Overflow.

https://stackoverflow.com/questions/2013937/what-is-an-os-kernel-how-does-it-differ-from-an-operating-system

>
> [...]
> > Sorry, of course the work is worth it if we have a term to use. I was
> meaning
> > for me kernel is only marginally better than executive so that change is
> not
> > worth it. I think it is important to keep executive for the list you have
> > provided below.
>
> I would like to use executive instead of kernel. I would also like to
> get rid of the word kernel in the RTEMS documentation set.
>

Honestly, I almost would rather explain that historically the core set of
services
provided by an RTOS were called an executive but that computer science
usually uses the term kernel.

>
> >
> >>>> However, if you go back in time to the early RTEMS days, executive
> and kernel
> >>>> were used interchangeably. Both were less full-featured than what was
> called an
> >>>> OS back in those days. Now that RTEMS has file systems, networking,
> etc, it is
> >>>> proper under those old conventions to use OS for RTEMS now but the
> concurrency
> >>>> and synchronization minimal subset is an executive/kernel.
> >>> Yes I agree we have used these terms equally over the years...
> >>>
> >>>
> https://docs.rtems.org/releases/4.5.0/rtemsdoc-4.5.0/share/rtemsdoc/html/FAQ/FAQ00006.html
> >>>
> >>>
> >>> :)
> >>>
> >>>> But executive is better than kernel now as a term. Executives focus
> on services
> >>>> related to managing a thread set.
>

I don't know if I said this or not but I think I MAY use them
interchangeably but after
more research, I think executive has fallen out of favor generally and
kernel is
the more commonly accepted term for the core services of an operating
system.

> >>> How do we address the rtems.git repo? For example ...
> >>>
> >>>    "Please refer to the code in the kernel repo"
> >>>
> >>>    "Please refer to the code in the executive repo"
> >>>
> >>>    "Please refer to the code in the OS repo"
> >>>
> >>> For me the executive sentence seems specialised while the kernel seem
> boarder
> >>> but that could just be my ingrained view.
> >> What about "Please refer to the code in the RTEMS main repo"?
> > Words like main are not great, it is like new or old.
>
> Old and new constantly change, but there is just one main repository,
> the one that contains the RTEMS executive.
>

Or kernel depending on the term. But it contains more. It also contains
critical core services. If the legacy network stack were NOT in it, we would
say it contained all operating system services EXCEPT the TCP/IP stack.

I would say core OS services including the kernel.

>
> >
> >> I would definitely not call it "kernel repo" or "executive repo".
> > Sure but it leaves a hole we need to fill.
> >
> >> The "OS repo" is also good.
> > What about "RTOS", eg RTOS repo? This leave 'OS' as the collective term
> of the
> > pieces we have and I think that is a good thing to have.
> >
> >> I think we should rename rtems-kernel-*.cfg to rtems-os-*.cfg in the
> RSB.
> > rtems-rtos-*.cfg ?
>
> Maybe just call it the "RTEMS repository" and use rtems-rtems-*.cfg.
>

I agree with the comment that FreeRTOS uses the term RTOS but other
commercial
products are not afraid of the term RTOS. And we shouldn't be either.

Did I hear you st-stutter? rtems-rtems... LOL It is more accurate though. :)

rtems-rtos is nice

>
> >
> >>> If we use executive is 'exec' as a shorted path ok? For example:
> >>>
> >>>    /opt/work/chris/rtems/exec/rtems.git
>

For those with long memories, cpukit/ used to be c/src/exec. :)

> >>>
> >>> If 'executive' is used we are again extending path names and we there
> can be
> >>> issues even on Linux, ie Ada builds and Windows.
> >> The directory structure proposed in the documents is another topic. I
> would
> >> organize it like this:
> >>
> >> sandbox/5/ <- prefix
> >> sandbox/src/examples
> >> sandbox/src/libbsd
> >> sandbox/src/rsb
> >> sandbox/src/rtems
> >    sandbox/src/rtos
>
> I think it is confusing to use a completely different directory name
> compared to the remote repository name. A shortcut like
> rtems-source-builder -> rsb and rtems-libbsd -> libbsd is something else.
>

The last updates to the Kickstart class I did included an explanation of
the
different conventions you might encounter in the instructions. I really
would
like to see this reduced to one public and one ${HOME} pattern. And
include a disclaimer that you can use any prefix you want but we
recommend /opt/rtems... for shared installation. And you can have private
per user installs in your ${HOME} directory anywhere you want.

But the manuals only use the /opt and one ${HOME} pattern.

It is very confusing and leads to user errors. Way more often than the
esoteric kernel vs executive vs OS.

FWIW this feels way more like the discussions I am used to in a standards
meeting than the RTEMS list.

>
> --
> 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...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190123/93a1d913/attachment-0002.html>