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. 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. I would like to avoid that
someone thinks about RTEMS as a micro kernel which would be totally wrong.
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.
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.
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"? I would
definitely not call it "kernel repo" or "executive repo". The "OS repo"
is also good.
I think we should rename rtems-kernel-*.cfg to rtems-os-*.cfg in the RSB.
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
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.
--
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
