RTEMS Executive vs. Kernel

Wed Jan 23 06:50:32 UTC 2019

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. 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. I would like to avoid that 
someone thinks about RTEMS as a micro kernel which would be totally wrong.

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

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

I think it is worth the churn. If you don't name the important 
components consistently in the documentation it is just confusing.

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

What about "Please refer to the code in the RTEMS main repo"? I would 
definitely not call it "kernel repo" or "executive repo". The "OS repo" 
is also good.

I think we should rename rtems-kernel-*.cfg to rtems-os-*.cfg in the RSB.

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

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

I am not absolutely sure if the Ada build is affected by long path 
names, but it had an influence on error messages produced by a failing 
build.

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