RTEMS Executive vs. Kernel

[Chris Johns]

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.

Which term is the better abstraction of what the rtems.git repo is? This is the
critical piece to resolve.

I have been using kernel as the reference to the 'rtems.git' repo. Using 'rtems'
as a name to refer to the 'rtems.git' repo is not enough as the term 'rtems' has
a much broader scope these days and it's meaning is ambiguous to new users.
RTEMS OS is also too board and ambiguous. I selected the term 'kernel' because
it represents a formal set of interfaces that RTEMS provides without being
specific about a piece of provided functionality. It also follows the RSB build
set name I created years ago. The single term is strategic, it is attempting to
use a language that maps to the steps you need to take and repos you need to
access. The Executable section of the User Manual outlines the stages:

 https://docs.rtems.org/branches/master/user/exe/index.html

A key focus of this section is to show the steps a user needs to take to build
an application. They are building the tools, building the "kernel", optionally
building 3rd party packages and then building an application. I include libbsd
as a 3rd party package to be consistent and to show to users the RTEMS operating
system can also contain 3rd party packages and those packages can serve as
examples for others.

We sit in a middle state at the moment, we have things in the rtems.git repo
that could be separate packages, the legacy networking stack, parts of libmisc,
or we have packages like libbsd that could be part of rtems.git. I suspect in
time removing packages from the rtems.git repo will aid certification because
there is less code to audit or review and remove. This however means we need a
strong package builder or these packages as well as external 3rd party packages.
Hmm, maybe the term 3rd party packages is wrong and should be changed, but that
is off scope for this thread.

Joel and I have been reviewing the Eco-system and Executable section of the user
manual using both terms and in a few spots "RTEMS operating system" should be
used instead of 'kernel' so that language could be improved. In the Executable
section the use of 'executive' seems to close to 'executable'.

Note, the "Kernel" layer in the "Vertical Software Stack" figure should be
expanded to be two layers, "Services" and "Executive".

An important factor is the documentation needs to read well.

For me the executive is the runtime thread management and control, I suppose the
score set of files, and I think it would be awkward to group the shell as part
of the executive. Referring to 'rtems.git' as the 'executive' repo somehow does
not feel right.

I am not sure there is a clear answer that perfectly defines what we have. There
seems to be a lot of work to make this change including the RSB and I am
wondering if it is worth the churn.

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

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.

If we use executive is 'exec' as a shorted path ok? For example:

 /opt/work/chris/rtems/exec/rtems.git

If 'executive' is used we are again extending path names and we there can be
issues even on Linux, ie Ada builds and Windows.

Chris