On 23/03/15 14:30, Hesham ALMatary wrote:
Hi all,
Thanks Antti for your reply. I'm reviving this thread as Dr.Joel suggested.
On Thu, Feb 26, 2015 at 1:11 AM, Antti Kantee <[email protected]> wrote:
Hesham,
[sorry for the slight delay, there were some mailing list snafus on this
end]
[aaaand due the those problems, the rump kernel mailing list migrated
meanwhile. I'm sending my reply to the new list at
[email protected]. Everyone replying please use the new list.]
There are essentially 3 choices:
1) teach buildrump.sh to run ./configure like the RTEMS cross-compiler
expects it to be run (assuming it's somehow possible to run ./configure
scripts against the RTEMS xcompiler; I'm not familiar with RTEMS so I can't
comment)
2) hardcode the values for RTEMS. I don't really prefer this option, since
it adds to maintenance overhead and potential breakage; the reason I
originally added the autoconf goop was to get rid of the long-time hardcoded
values causing the maintenance load.
3) skip the POSIX hypervisor entirely and go directly for implementing the
hypercalls on the low level
I agree with this choice, however Dr. Joel sees that integrating Rump
Kernels above RTEMS/POSIX would be more stable. Antti may have some
words here.
There are actually two points you need to integrate to, since the stack
will look something like this:
RTEMS application
========1========
rump kernel
========2========
RTEMS core
By "application" I mean anything that would want to use drivers provided
by a rump kernel. It can be a regular POSIX application, in which case
"1" would be system calls, or for example the networking stack wanting
to use some NIC device driver. What "1" looks like will vary hugely
based on that. For syscalls it's nice and stable, but for any
integration point inside the kernel, not so much. For example, when
using rump kernels to run file system drivers as microkernel style
servers on NetBSD, "1" is the VFS/vnode interface. In that particular
scenario, the VFS/vnode interface changing doesn't cause trouble because
both the code using it and providing it is hosted in the NetBSD tree.
The situation would be different if you want to interface from RTEMS on
that level.
By "core" I mean anything that provides the necessary support for a rump
kernel to run. It is absolutely true that using POSIX as the interface
to the core is interface-wise more stable than hooking directly into the
RTEMS entrails -- I assume RTEMS entrails can change. However, the
interfaces required for implementing "2" (a.k.a. the rump kernel
hypercall interface) are so simple that I wouldn't consider that
stability the decisive metric.
Anyway, if we talking in the context of a summer of code project, I
don't think testing both approaches for "2" is an unspeakable amount of
work, especially given that barring the code compilation issues running
on top of POSIX should already just work. The more open-ended question
is what to do with "1".
- antti
