* Jan Kiszka <[email protected]> [2017-06-08 20:24:23 +0200]: > On 2017-06-08 19:27, Gustavo Lima Chaves wrote: > > * Jan Kiszka <[email protected]> [2017-06-08 19:13:20 +0200]: > > > >> > >>> > >>> 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 :).
Ack. > > > > 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? I think so. Zephyr is Apache 2—it seems it's a new trend at least for some, due to patent clauses, etc, etc (IANAL)—but I'd guess they're compatible. > > >> > >> 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. OK, I'll sure let you know. > > > > > 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. I'm not touching ARM, no idea. If it's possible on x86, then great, folks we accept patches fine for that. Not a thing that know much, though. > > 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.
