On 13.02.19 14:17, Arvid Rosén wrote:
*From: *<[email protected]> on behalf of Claudio Scordino
<[email protected]>
*Date: *Wednesday, 13 February 2019 at 13:04
*To: *João Reis <[email protected]>
*Cc: *Jailhouse <[email protected]>
*Subject: *Re: Using Erika3 with libc support
What is not currently supported by the Jailhouse build system is the possibility
of using different toolchains for the hypervisor firmware and the inmate library.
This is useful in case you want to use a bare-metal toolchain with libc (e.g.
newlib) for the inmate.
Indeed, we have successfully used a bare-metal toolchain by Linaro (with libc)
in the inmate. We have been able of even using dynamic memory allocation and C++
data structures.
You can easily patch Jailhouse's makefiles for using different compilers for the
hypervisor firmware and the inmate library (which could eventually be linked to
the ERIKA RTOS, in case of need).
Hi!
Nothing really to add here, except that I think this sounds super interesting! A
reasonable way to run self-contained C++ code for signal processing applications
is really what makes Jailhouse interesting for me, and I’ll continue to look
into that. The possibility to use newlib to run the same application on either a
i.MX RT device (bare metal) or in a jailhouse cell on a i.MX 8 chip would be
fantastic.
You are not alone with such scenarios, I also heard those wishes off-list
already. It is perfectly possibly to develop the inmate environment further
towards such requirements. But there is a point where we risk crossing the line
to a (highly configurable) RTOS that may run on Jailhouse as well. That's my
biggest concern.
It's about maintaining the balance between focusing on a bare-metal runtimes
only and adding more and more feature that RTOSes may already provide - just
like Jailhouse itself needs to refrain from becoming yet another full-featured
hypervisor.
Another aspect of making the inmate-lib stand-alone is creating a more stable
interface to Jailhouse, both technically (there are some remaining links besides
the build system) as well as API/ABI-wise (ensure inmates will find stable
interface or can at least explore revisions and features). Having everything
in-tree and committed only on testing, demos and Linux loaders makes this less
strict, though that is more of an excuse for settling on some more stable
interfaces.
In any case, we would need some folks willing to drive this topic, with
requirements, design ideas and ideally also code.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
