On 2017-06-08 19:27, Gustavo Lima Chaves wrote: > * 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).
Sure, for bare-metal you likely need this (the Quark has no x2APIC, not even the big, I bet :). > >> >> 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. > OK, let's get serious: Claudio, you offered to go after the copyright holders. Could you prepare a reasoning email for the license change and a patch to perform it? That could be sent to those folks, collect their acks, and I could also use it for starting the process internally to add ours. Given the use case "for integration in non-GPL RTOSes", it would likely be better to go for a dual BSD-2-Clause/GPLv2, just like we already did with headers. Would this be fine for Zephyr as well? >> >> 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. Great! Once you can share anything in any form, even when not yet for upstream, please let us know. There is strong interest here. > > 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. Don't you have infrastructure for device tree on ARM or beyond already? I suppose this is not yet enabled on x86, but it would be doable and conceptually clean. I was briefly discussing this issue with Andreas already as well. 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.
