* Jan Kiszka <[email protected]> [2017-06-08 18:35:22 +0200]:

> On 2017-06-08 17:38, Claudio Scordino wrote:
> > Hi Jan,
> >
> > 2017-03-21 11:00 GMT+01:00 Jan Kiszka <[email protected]
> > <mailto:[email protected]>>:
> >
> >     On 2017-03-21 10:27, Claudio Scordino wrote:
> >     > Dear all,
> >     >
> >     > I apologize if this topic has been already discussed in list.
> >     >
> >     > I've noted that the inmate lib is licensed under GPL. Therefore, if 
> > I'm
> >     > not wrong, its license also affects the inmate binaries that get 
> > linked
> >     > to it.
> >     >
> >     > If licensing the hypervisor code under GPL is reasonable for a 
> > plethora
> >     > of reasons, I wonder if applying the same license for the inmate 
> > library
> >     > is wise or not, since it may prevent the usage of such library in an
> >     > industrial context where the inmate code must remain proprietary.
> >
> >     Correct, the inmate library in its current form is not suitable for
> >     proprietary inmate development. We only licensed interface header of the
> >     hypervisor under dual GPL/BSD, not the library.
> >
> >     I wouldn't refuse a relicensing proposal if there is a real need and
> >     someone has the time to drive it (hunt down all copyright holders), but
> >     I would also like to have a discussion about technical alternatives
> >     first, i.e. RTOSes that already come with permissive licenses. I
> >     consider Zephyr as the hottest candidate for this right now (x86
> >     support, consistent licensing, vivid and growing industrial community).
> >
> >
> > Actually, I see the problem more related to the application code (often
> > kept proprietary) rather than to the RTOS itself.
> > Even without a RTOS, in fact, the problem persists for proprietary
> > bare-metal applications.
> > Some RTOSs (e.g., ERIKA Enterprise) are open-source, but come with a
> > permissive license allowing static linking of proprieraty application code.
> >
> > "git log" extracted 14 contributors for the inmate/lib/ code.
> > If you agree, I can try to contact those developers asking for a
> > preliminary feedback.
> > As a company, we definitely need a license allowing static linking of
> > proprietary bare-metal code against the inmate library.
> > The license can be similar to the one used by the ERIKA RTOS (i.e. GPL +
> > linking exception - https://en.wikipedia.org/wiki/GPL_linking_exception)
> > or an even more permessive license (e.g., BSD, MIT).
>
> From my POV, GPL + linking exception would be the best to go when we
> really want to lift the inmates on that level. But I would have to check
> internally with our authorities anyway.
>
> 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!
"""

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.

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).

Cheers,

>
> 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.

Reply via email to