<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 25, 2019 at 7:03 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 24/01/2019 00:24, Joel Sherrill wrote:<br>
><br>
><br>
> On Wed, Jan 23, 2019 at 2:01 AM Sebastian Huber <br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a> <br>
> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
><br>
> On 23/01/2019 08:11, Chris Johns wrote:<br>
> > 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<br>
> abstraction because we<br>
> >>> have a single address space and literal or formal<br>
> interpretation breaks down. I<br>
> >>> see the physical separation as an implementation detail.<br>
> >> Real-Time Executive for Multiprocessor Systems or RTEMS already<br>
> has executive in<br>
> >> its name.<br>
> > The name has evolved over time.<br>
><br>
><br>
> The M had two meanings before Multiprocessor. That's the only change. <br>
> We shall NOT<br>
> discuss the previous two since those were poor choices that biased folks.<br>
><br>
> I found the original published paper on RTEMS. It was presented in <br>
> August 1990<br>
> and the text version is at:<br>
><br>
> <a href="https://archive.org/stream/DTIC_ADA247043/DTIC_ADA247043_djvu.txt" rel="noreferrer" target="_blank">https://archive.org/stream/DTIC_ADA247043/DTIC_ADA247043_djvu.txt</a><br>
><br>
> It is clear there that kernel and executive were considered equivalent <br>
> terms.<br>
> It is also clear that operating system is used about as many times as <br>
> either<br>
> term. I did not re-read the paper to see if we used executive/kernel <br>
> to refer<br>
> to a core set of services and OS to refer to a larger collection.<br>
><br>
> <a href="https://en.wikipedia.org/wiki/Kernel_(operating_system)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Kernel_(operating_system)</a> is an <br>
> interesting read.<br>
> Kernel is a valid term for us to use per that. A couple of quotes from <br>
> the early<br>
> part of that ignoring the IO devices mentioned. This is the first <br>
> sentence.<br>
><br>
> "The kernel is a computer program that is the core of a computer's <br>
> operating system,<br>
> with complete control over everything in the system.[1] On most <br>
> systems, it is one of the<br>
> first programs loaded on start-up (after the bootloader). "<br>
><br>
> The above matches my stated view that there is a core set of services <br>
> that support<br>
> others. The collective is the operating system. For the purposes of <br>
> this discussion,<br>
> the rtems.git repo unfortunately contains the kernel and some OS <br>
> services. So the<br>
> repo is not purely the kernel layer. It is the kernel plus core <br>
> services and libraries.<br>
><br>
> "The critical code of the kernel is usually loaded into a separate <br>
> area of memory,<br>
> which is protected from access by application programs or other, less <br>
> critical parts<br>
> of the operating system. "<br>
><br>
> The key point of the above sentence is "usually". This is in deference <br>
> to UNIX<br>
> and Windows which do have separation. The kernel is a logical <br>
> abstraction which<br>
> may have the property of separation.<br>
<br>
This wikipedia article clearly talks about kernels that use protection <br>
mechanisms and system calls.<br></blockquote><div><br></div><div>But it starts by starting that kernels may have protection. Kernel is</div><div>an organizational construct. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Apart from that, you all seem to favour "kernel" instead of "executive".<br></blockquote><div><br></div><div>My gut feeling is that executive is an old term that many people won't</div><div>recognize anymore. We have to explain it because of the E in RTEMS.</div><div>But in our historical use, executive and kernel were interchangeable.</div><div><br></div><div>As Chris pointed out, we reviewed a few pages of the docs together</div><div>and you can't do a search and replace. Sometimes OS is better,</div><div>sometimes kernel is better. Sometimes the sentence shouldn't</div><div>use either.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
While searching on the web I found a PDF of the Real-Time Executive for <br>
Missile Systems C Application User's Guild.<br></blockquote><div><br></div><div>Shh.... wrong M. :)</div><div><br></div><div>We have a full shelf of old reports. A few would be good to have </div><div>mirrored at <a href="http://ftp.rtems.org">ftp.rtems.org</a> if DTIC has them.</div><div><br></div><div>FWIW DTIC == Defense Technical Information Center and it seems</div><div>to have a number of DoD/DARPA research efforts using RTEMS plus</div><div>a handful of the original reports.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<a href="https://apps.dtic.mil/dtic/tr/fulltext/u2/a276687.pdf" rel="noreferrer" target="_blank">https://apps.dtic.mil/dtic/tr/fulltext/u2/a276687.pdf</a><br>
<br>
It doesn't look that much different to the current Classic API guide.<br></blockquote><div><br></div><div>There is a good reason for it not looking much different. OAR wrote it. It was</div><div>in Lotus Ami Pro and converted.</div><div><br></div><div>By 1995, Army support for the Army had been stopped for a while. RTEMS </div><div>source code was available via CVS in May 1995. But the documentation being</div><div>in a closed source tool was an issue and it bothered me. In November 1995,</div><div>Huntsville had an ice storm with 11 inches of ice. Pictures are in this article.</div><div><br></div><div><a href="https://www.al.com/news/huntsville/index.ssf/2015/02/record_storm_coated_north_alab.html">https://www.al.com/news/huntsville/index.ssf/2015/02/record_storm_coated_north_alab.html</a><br></div><div><br></div><div>I was trapped at home even after some thaw by a huge ice wedge at bottom of my</div><div>driveway. My driveway had a serious slope to it.</div><div><br></div><div>Anyway, I used the time trapped at home to convert the Lotus Ami Pro documentation</div><div>to Texinfo and make it available. The Classic API hasn't changed that much. We </div><div>picked an organization for each manager chapter that was good. So that's how</div><div>we got here.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div></div></div>