Hesham,
[sorry for the slight delay, there were some mailing list snafus on this
end]
On 24/02/15 15:38, Hesham Moustafa wrote:
> I was trying to compile/build Rump Kernel (POSIXy hypercall + Rump
> kernel) as a library to run above RTEMS/POSIX. So, this POSIXy
> Hypercall expects the host (which is RTEMS here) to provide the
> required POSIX implementation.
As background to everyone especially on the rtems list, rump kernels run
on top of a "hypercall" interface, which is essentially a high-level,
minimal('ish) codification of what is required to run kernel drivers.
One existing implementation of this hypercall interface is for POSIX
userspace.
I suggested you start your RTEMS + rump kernels experiments with the
POSIX hypercalls, since code readily exists on both sides, and it's just
a matter of getting existing code to work with existing code. I assume
that ultimately it's a nonsensical approach with RTEMS, since I assume
that POSIX is just an few additional layers of overhead to wrap things
into the RTEMS "kernel". But, since you gotta get your feet wet at some
end of the pool, might as well pick the perceivably shallow one.
(I assume a lot. If some assumptions are not entirely correct, please
set me straight.)
> When I tried to build hypercall + Rump Kernel [1] as a library, the
> configure script tries to search and compile the corresponding POSIX
> functions in order to make sure they really exist, so the headers are
> not enough, and thus the build fails because I couldn't make it refer
> to RTEMS/POSIX implementation.
>
> I don't know what are the proper solutions here. What I can do is to
> copy hypercall source to RTEMS, add it to the cpukit/rump for example,
> and build it there, so it can find the required RTEMS/POSIX
> implementation when it tries to link.
>
> The other solution may be modify Rump kernel configure so that it
> knows about RTEMS/POSIX source (or discard this configure checking),
> Antti, does this make sense?
>
> [1] https://github.com/rumpkernel/buildrump.sh
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'd prefer 1 or 3. Personally, I'd go for 3, but then again my feet are
already positively soaked. You can always do the feet-wetting on a
"big" OS, the concepts will be more or less the same regardless of platform.
- antti
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
