On Wed, Jan 23, 2019 at 2:01 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> 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. > The M had two meanings before Multiprocessor. That's the only change. We shall NOT discuss the previous two since those were poor choices that biased folks. I found the original published paper on RTEMS. It was presented in August 1990 and the text version is at: https://archive.org/stream/DTIC_ADA247043/DTIC_ADA247043_djvu.txt It is clear there that kernel and executive were considered equivalent terms. It is also clear that operating system is used about as many times as either term. I did not re-read the paper to see if we used executive/kernel to refer to a core set of services and OS to refer to a larger collection. https://en.wikipedia.org/wiki/Kernel_(operating_system) is an interesting read. Kernel is a valid term for us to use per that. A couple of quotes from the early part of that ignoring the IO devices mentioned. This is the first sentence. "The kernel is a computer program that is the core of a computer's operating system, with complete control over everything in the system.[1] On most systems, it is one of the first programs loaded on start-up (after the bootloader). " The above matches my stated view that there is a core set of services that support others. The collective is the operating system. For the purposes of this discussion, the rtems.git repo unfortunately contains the kernel and some OS services. So the repo is not purely the kernel layer. It is the kernel plus core services and libraries. "The critical code of the kernel is usually loaded into a separate area of memory, which is protected from access by application programs or other, less critical parts of the operating system. " The key point of the above sentence is "usually". This is in deference to UNIX and Windows which do have separation. The kernel is a logical abstraction which may have the property of separation. Executive was used in the olden days of yore to refer to small RTOSes. http://www.drdobbs.com/a-simple-real-time-executive/184402613 presents TinyExec and uses the real-time executive term repeatedly. For those who remember it, VRTX stands for Versatile Real-Time Executive which is the Vx in VxWorks which originally meant VRTX Works. Google "real-time executive" and you will see other examples in addition to RTEMS. Executive is meant in the sense that it manages concurrency and synchronization. Nucleus and ThreadX refer to themselves as RTOS. uCos uses the term real-time kernel. Ironically, even the POSIX standard includes the terms real-time executive, kernel, and RTOS in http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/xrat/V4_xsh_chap02.html My point here is that there really is a precedent here and kernel does not automatically imply protection. > > > >> 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. > We may use it in an overloaded manner but it has a pretty solid meaning as the provider of core services in an operating system. With or without protection. > > > >> 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. > This has never been a problem in the past. > > > >>> 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. > This set of services matches what Wikipedia's definition of kernel provides. And this from Stack Overflow. https://stackoverflow.com/questions/2013937/what-is-an-os-kernel-how-does-it-differ-from-an-operating-system > > [...] > > 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. > Honestly, I almost would rather explain that historically the core set of services provided by an RTOS were called an executive but that computer science usually uses the term kernel. > > > > >>>> 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. > I don't know if I said this or not but I think I MAY use them interchangeably but after more research, I think executive has fallen out of favor generally and kernel is the more commonly accepted term for the core services of an operating system. > >>> 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. > Or kernel depending on the term. But it contains more. It also contains critical core services. If the legacy network stack were NOT in it, we would say it contained all operating system services EXCEPT the TCP/IP stack. I would say core OS services including the kernel. > > > > >> 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. > I agree with the comment that FreeRTOS uses the term RTOS but other commercial products are not afraid of the term RTOS. And we shouldn't be either. Did I hear you st-stutter? rtems-rtems... LOL It is more accurate though. :) rtems-rtos is nice > > > > >>> If we use executive is 'exec' as a shorted path ok? For example: > >>> > >>> /opt/work/chris/rtems/exec/rtems.git > For those with long memories, cpukit/ used to be c/src/exec. :) > >>> > >>> 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. > The last updates to the Kickstart class I did included an explanation of the different conventions you might encounter in the instructions. I really would like to see this reduced to one public and one ${HOME} pattern. And include a disclaimer that you can use any prefix you want but we recommend /opt/rtems... for shared installation. And you can have private per user installs in your ${HOME} directory anywhere you want. But the manuals only use the /opt and one ${HOME} pattern. It is very confusing and leads to user errors. Way more often than the esoteric kernel vs executive vs OS. FWIW this feels way more like the discussions I am used to in a standards meeting than the RTEMS list. > > -- > 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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
