<div><br></div><div><div>I just used RTEMS for about 1 year, When I first met the word "executive" in the docs, It confused me. </div><div>I think "kernel" is easier to understand, although it is not like the linux kernel.<span style="background-color: rgb(239, 239, 239); font-size: 12px;"></span></div><div>From this point of view, I think "kernel" is better.</div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b> "Chris Johns"<chrisj@rtems.org>;</div><div><b>Date: </b> Wed, Jan 23, 2019 03:11 PM</div><div><b>To: </b> "Sebastian Huber"<sebastian.huber@embedded-brains.de>;"joel"<joel@rtems.org>;"Gedare Bloom"<gedare@rtems.org>;<wbr></div><div><b>Cc: </b> "RTEMS"<devel@rtems.org>; <wbr></div><div><b>Subject: </b> Re: RTEMS Executive vs. Kernel</div></div><div><br></div>On 23/1/19 5:50 pm, Sebastian Huber wrote:<br>> On 22/01/2019 23:42, Chris Johns wrote:<br>>> On 23/1/19 5:34 am, Joel Sherrill wrote:<br>>>> I don't object.<br>>> Is executive the right abstraction? Both terms are an abstraction because we<br>>> have a single address space and literal or formal interpretation breaks down. I<br>>> see the physical separation as an implementation detail.<br>> <br>> Real-Time Executive for Multiprocessor Systems or RTEMS already has executive in<br>> its name. <br><br>The name has evolved over time.<br><br>> I don't think that the kernel/user space separation and system calls<br>> are an implementation detail. It is a hardware enforced feature which<br>> characterizes a whole group of operating systems. The name kernel is quite<br>> overloaded. <br><br>It sure is.<br><br>> I would like to avoid that someone thinks about RTEMS as a micro<br>> kernel which would be totally wrong.<br><br>I think there will always be a level of confusion.<br><br>>> Which term is the better abstraction of what the rtems.git repo is? This is the<br>>> critical piece to resolve.<br>> <br>> Ok, this is a different issue. The problem is that in rtems.git is a collection<br>> of different things. It contains the RTEMS executive (everything which deals<br>> with threads, interrupts, synchronization and inter-thread communication), a<br>> legacy network stack, file systems, device drivers, memory allocators,<br>> compression libraries, hash libraries, shell, etc. I think calling this stuff<br>> "kernel" is imprecise.<br><br>It is imprecise but what is a precise single word or term to explain this?<br><br>>><br>>> I have been using kernel as the reference to the 'rtems.git' repo. Using 'rtems'<br>>> as a name to refer to the 'rtems.git' repo is not enough as the term 'rtems' has<br>>> a much broader scope these days and it's meaning is ambiguous to new users.<br>>> RTEMS OS is also too board and ambiguous. I selected the term 'kernel' because<br>>> it represents a formal set of interfaces that RTEMS provides without being<br>>> specific about a piece of provided functionality. It also follows the RSB build<br>>> set name I created years ago. The single term is strategic, it is attempting to<br>>> use a language that maps to the steps you need to take and repos you need to<br>>> access. The Executable section of the User Manual outlines the stages:<br>>><br>>>   https://docs.rtems.org/branches/master/user/exe/index.html<br>>><br>>> A key focus of this section is to show the steps a user needs to take to build<br>>> an application. They are building the tools, building the "kernel", optionally<br>>> building 3rd party packages and then building an application. I include libbsd<br>>> as a 3rd party package to be consistent and to show to users the RTEMS operating<br>>> system can also contain 3rd party packages and those packages can serve as<br>>> examples for others.<br>>><br>>> We sit in a middle state at the moment, we have things in the rtems.git repo<br>>> that could be separate packages, the legacy networking stack, parts of libmisc,<br>>> or we have packages like libbsd that could be part of rtems.git. I suspect in<br>>> time removing packages from the rtems.git repo will aid certification because<br>>> there is less code to audit or review and remove. This however means we need a<br>>> strong package builder or these packages as well as external 3rd party packages.<br>>> Hmm, maybe the term 3rd party packages is wrong and should be changed, but that<br>>> is off scope for this thread.<br>>><br>>> Joel and I have been reviewing the Eco-system and Executable section of the user<br>>> manual using both terms and in a few spots "RTEMS operating system" should be<br>>> used instead of 'kernel' so that language could be improved. In the Executable<br>>> section the use of 'executive' seems to close to 'executable'.<br>>><br>>> Note, the "Kernel" layer in the "Vertical Software Stack" figure should be<br>>> expanded to be two layers, "Services" and "Executive".<br>>><br>>> An important factor is the documentation needs to read well.<br>>><br>>> For me the executive is the runtime thread management and control, I suppose the<br>>> score set of files, and I think it would be awkward to group the shell as part<br>>> of the executive. Referring to 'rtems.git' as the 'executive' repo somehow does<br>>> not feel right.<br>>><br>>> I am not sure there is a clear answer that perfectly defines what we have. There<br>>> seems to be a lot of work to make this change including the RSB and I am<br>>> wondering if it is worth the churn.<br>> <br>> I think it is worth the churn. If you don't name the important components<br>> consistently in the documentation it is just confusing.<br><br>Sorry, of course the work is worth it if we have a term to use. I was meaning<br>for me kernel is only marginally better than executive so that change is not<br>worth it. I think it is important to keep executive for the list you have<br>provided below.<br><br>>>> However, if you go back in time to the early RTEMS days, executive and kernel<br>>>> were used interchangeably. Both were less full-featured than what was called an<br>>>> OS back in those days. Now that RTEMS has file systems, networking, etc, it is<br>>>> proper under those old conventions to use OS for RTEMS now but the concurrency<br>>>> and synchronization minimal subset is an executive/kernel.<br>>> Yes I agree we have used these terms equally over the years...<br>>><br>>> https://docs.rtems.org/releases/4.5.0/rtemsdoc-4.5.0/share/rtemsdoc/html/FAQ/FAQ00006.html<br>>><br>>><br>>> :)<br>>><br>>>> But executive is better than kernel now as a term. Executives focus on services<br>>>> related to managing a thread set.<br>>> How do we address the rtems.git repo? For example ...<br>>><br>>>   "Please refer to the code in the kernel repo"<br>>><br>>>   "Please refer to the code in the executive repo"<br>>><br>>>   "Please refer to the code in the OS repo"<br>>><br>>> For me the executive sentence seems specialised while the kernel seem boarder<br>>> but that could just be my ingrained view.<br>> <br>> What about "Please refer to the code in the RTEMS main repo"? <br><br>Words like main are not great, it is like new or old.<br><br>> I would definitely not call it "kernel repo" or "executive repo".<br><br>Sure but it leaves a hole we need to fill.<br><br>> The "OS repo" is also good.<br><br>What about "RTOS", eg RTOS repo? This leave 'OS' as the collective term of the<br>pieces we have and I think that is a good thing to have.<br><br>> I think we should rename rtems-kernel-*.cfg to rtems-os-*.cfg in the RSB.<br><br>rtems-rtos-*.cfg ?<br><br>>> If we use executive is 'exec' as a shorted path ok? For example:<br>>><br>>>   /opt/work/chris/rtems/exec/rtems.git<br>>><br>>> If 'executive' is used we are again extending path names and we there can be<br>>> issues even on Linux, ie Ada builds and Windows.<br>> <br>> The directory structure proposed in the documents is another topic. I would<br>> organize it like this:<br>> <br>> sandbox/5/ <- prefix<br>> sandbox/src/examples<br>> sandbox/src/libbsd<br>> sandbox/src/rsb<br>> sandbox/src/rtems<br><br>  sandbox/src/rtos<br><br>> I am not absolutely sure if the Ada build is affected by long path names, but it<br>> had an influence on error messages produced by a failing build.<br><br>OK. It is an issue on Windows.<br><br>Chris<br>_______________________________________________<br>devel mailing list<br>devel@rtems.org<br>http://lists.rtems.org/mailman/listinfo/devel</div>