On 2019-02-13, 17:17, "[email protected] on behalf of Jan Kiszka" <[email protected] on behalf of [email protected]> wrote: 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. Hi Jan!
I understand this perfectly, and it is an important task of the maintainer to draw the line between what is covered by the scope of the project, and what is not. And what I was describing, might very well be covered by a RTOS already, and in the end the jailhouse project might only need to adopt by providing a howto or maybe modifying the build system to support multiple toolchains. Supporting these kind of setups in the long run, that would bridge the gap between more traditional micro controllers and multi-core CPUs, would definitely add value to a manufacturer's portfolio (hint to NXP and others). Cheers, Arvid -- 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.
