RTEMS Executive vs. Kernel

[Chris Johns]

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.

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

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

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

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.

>>> 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"? 

Words like main are not great, it is like new or old.

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

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

  sandbox/src/rtos

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

OK. It is an issue on Windows.

Chris