RTEMS Executive vs. Kernel

[Sebastian Huber]

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

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

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

Old and new constantly change, but there is just one main repository, 
the one that contains the RTEMS executive.

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

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

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