* Jan Kiszka <[email protected]> [2017-06-08 19:13:20 +0200]: > On 2017-06-08 18:48, Gustavo Lima Chaves wrote: > >> We are currently evaluating Zephyr on Jailhouse, but that is still in a > >> too early stage to contribute to this discussion or even a decision. How > >> urgent is the topic for you? > > > > How far are you into Zephyr? I have patches doing a preliminar port, so that > > at least UART and LOAPIC timers are working from Zephyr just fine: > > > > """ > > Created cell "tiny-demo" > > Page pool usage after cell creation: mem 275/1480, remap 65607/131072 > > Cell "tiny-demo" can be loaded > > CPU 3 received SIPI, vector 100 > > Started cell "tiny-demo" > > ***** BOOTING ZEPHYR OS v1.7.99 - BUILD: Jun 8 2017 00:36:18 ***** > > Hello World! > > Hello World! > > Hello World! > > """ > > > > Hoho, good that I dropped this note - great to see this! > > I added Andreas to CC who is just starting off, maybe still a bit wet > from the first bucket of cold Jailhouse water.
:) > > > This code lies on my hard disk only, for now, but sure I want to make > > it upstream, if both parties agree on its usefulness (Zephyr and > > Jailhouse). From a licensing POV, I just used a bare minimal excerpt > > from header-32.S, and would indeed be great to have that code more > > permissive, so that I would not have to bother re-writing it myself. > > Individual files would be easier to relicense, header-32.S is only owned > by us e.g. Cool. > > > > > One thing I lost from not using the inmate lib was xAPIC access to the > > LOAPIC, so my preliminar patch does rewrite those accesses to be > > x2APIC (MSR-based). > > x2APIC is the better choice. Yeah, maybe, but the ifdefs on my patch are looking uglish (they might want to keep the xAPIC access for the MCUs, I'm afraid). > > But back to the topic, and actually there are two: writing applications > on top of a permissive runtime - inmates lib or a permissively licensed > RTOS - and providing reusable material to porting RTOSes over Jailhouse. Sure, the second approach is exactly what we'd have with my patches (and possible right after header-32.S is good WRT licensing). > When doing a relicensing, the motivation and intended usage should be > clearly defined before approaching all the copyright holders. And we > should then also think about how to (re-)structure the code when we want > to support the second case. Yeah. The 1st approach is very valid for me as well, and you got a supporter here too for making its license different than of the rest of the codebase. > > How much could Zephyr be configured down in order to become something > like the inmates lib? In fact, if it can server all existing purposes - > simple tests, benchmarks, demos - and be scaled up to a real application > platform, I would like to avoid doing work twice. Then our focus should > be enabling Jailhouse for Zephyr on all our supported archs. Like I said, it's already happening. I like that we're aligned, let me make sure the patch is massaged enough to propose upstream soonish. One thing to have in mind, though, is that Zephyr is originally a system targeted at MCUs, so we'll encounter things like hardcoded CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC (MCUs don't seem to have CPU throttling) and stuff like that—I still haven't found a value for it on my test to exactly match a 1 second timer on this corei17, hehe. > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA ITP 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. -- Gustavo Lima Chaves Intel - Open Source Technology Center -- 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.
