Compiling POSIX based (hypercall + Rump Kernel) to run above RTEMS/POSIX issue

[Hesham ALMatary]

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 <pooka at iki.fi> wrote:
> 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 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.

> 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



-- 
Hesham