GSOC2011 project RTEMS HyperVisor

Mon Mar 21 20:39:39 UTC 2011

I see the point.

I still do not see, however, why you are advocating the BSD license, 
whereas most RTEMS code seems to be under GPL (with RTEMS exception).

The GPL-RTEMS license appears to me the much more appropriate way to go.

By the way, license matters come up quite often - also in other projects.

A question to everybody: Wouldn't it make sense to provide a document on 
the rtems.org that explains the reasoning behind these issues?

So:
What is the intention in using a GPL-based license?
Why Lesser GPL is not appropriate for kernel code.
What are friendly licenses (e.g. BSD); but also: why is BSD not the 
primary RTEMS license?
Which licenses are preferred for code that enters the tarball?

Regards,

Tobias

On 03/21/2011 07:27 PM, Gedare Bloom wrote:
> I don't know if it is formally documented about LGPL, but it was
> discussed recently, see the mailing list thread:
> http://www.rtems.com/ml/rtems-users/2010/april/thrd1.html#00066
>
> My understanding is that as long as there is (1) a linking exception,
> (2) no obligatory advertisement clauses, and (3) no requirement to
> redistribute modifications to the licensed software (e.g. source
> upstream / publish any changes made), then the license is fine.  LGPL
> requires #3 from what I can tell, and a minor version of #2 (prominent
> acknowledgement of included libraries, whatever the definition of
> prominent).
>
> Informally, the closest (safest) license is actually the FreeBSD
> (2-clause BSD) license.  The 3-clause BSD is also fine, since its
> advertisement clause is actually a restriction on using names, rather
> than an obligation.
>
> -Gedare
>
> On Mon, Mar 21, 2011 at 3:17 PM, Tobias Schoofs<Tobias.Schoofs at gmx.net>  wrote:
>> Mh. Why do you say that LGPL is insufficient for RTEMS? RTEMS is based on GPL with an exception that is similar to the "Lesser".
>>
>> Actually, for the code directly linked to RTEMS (MMU, superuser mode), the license will be the license of the modules that are changed (the SPARC-LEON BSP, for instance) and hence, the RTEMS license.
>>
>> For our own code, the plan is to use an "RTEMS-friendly" license that is widely used.
>>
>> You say "it was established" that LGPL is not sufficient. Is this documented somewhere? Is there perhaps a rationale for license-related decisions?
>>
>> Thanks,
>>
>> Tobias
>>
>> -------- Original-Nachricht --------
>>> Datum: Mon, 21 Mar 2011 12:34:39 -0400
>>> Von: Gedare Bloom<gedare at gwmail.gwu.edu>
>>> An: Tobias Schoofs<Tobias.Schoofs at gmx.net>
>>> CC: "å¼ æ–‡æ °"<157724595 at 163.com>, rtems-users at rtems.org
>>> Betreff: Re: RE: GSOC2011 project RTEMS HyperVisor
>>> I think it was established that LGPL is not sufficient for RTEMS code
>>> base. I believe this makes an AIR-based project an unlikely candidate
>>> for a GSOC project. Especially if the student used the AIR kernel as a
>>> resource.  Perhaps if the AIR kernel is released under an
>>> RTEMS-friendly license, a suitable project might be possible.
>>>
>>> Even if a "clean room" implementation of a hypervisor is the intended
>>> project, I'm not sure it is appropriate for a GSOC at this point in
>>> time.  My guess is that using RTEMS as a hypervisor requires three
>>> sub-projects that are all at or beyond the scope of a single GSOC:
>>>
>>> 1) Adding virtual memory / MMU support to RTEMS is a necessary
>>> pre-requisite to any attempt at making a true hypervisor, and it is a
>>> large project by itself.
>>>
>>> 2) Adding privileged/unprivileged distinction is also a pre-requisite
>>> to implementing a hypervisor. Each candidate target will have to be
>>> identified, and the CPU-specific context switching and interrupt
>>> handling would need some tweaking to ensure that privilege bits are
>>> properly managed. As far as I know, most processors just have full
>>> privilege for the application at all times. This is a large project by
>>> itself.
>>>
>>> 3) Implement the hypervisor itself involves primarily copying of page
>>> tables, swapping out guests, exporting a HAL (device drivers), and
>>> writing handlers for paravirtualized exceptions, hypercalls, and true
>>> guest exceptions.  This is also a large project.
>>>
>>> -Gedare
>>>
>>>
>>> On Mon, Mar 21, 2011 at 10:57 AM, Tobias Schoofs<Tobias.Schoofs at gmx.net>
>>> wrote:
>>>> 1) Yes, it does. There is a library that implements all services from
>>> ARINC 653 Part 1 and a subset of Part2. This library, however, is closed
>>> software.
>>>> 2) The AIR kernel is Lesser GPL and, as such, open source.
>>>>
>>>> 3) The code will be release very soon, i.e. in the course of the next
>>> months.
>>>> I will provide more information in an e-mail directly to you, since this
>>> is not of general interest to the mailing list.
>>>> Regards,
>>>>
>>>> Tobias
>>>>
>>>> -------- Original-Nachricht --------
>>>>> Datum: Mon, 21 Mar 2011 22:07:39 +0800 (CST)
>>>>> Von: "张文杰"<157724595 at 163.com>
>>>>> An: "Tobias Schoofs"<Tobias.Schoofs at gmx.net>
>>>>> CC: Jean-Jacques.Metge at cnes.fr, rtems-users at rtems.org
>>>>> Betreff: RE: GSOC2011 project RTEMS HyperVisor
>>>>> Dear Tobias:
>>>>> Thanks for your replay, actually i misunderstand the AIR system. And
>>> the
>>>>> work AIR system has done is what i want to implement. My thought is
>>> also
>>>>> to implement a para-virtualisation hypervisor that can run RTEMS and
>>> other
>>>>> OS.(RTEMS as a guest OS). I do not plan to implement a
>>> full-virtualisation
>>>>> hypervisor.
>>>>> I has some question about AIR:
>>>>> 1). AIR has also implement the ARINC 653 APEX on RTEMS?
>>>>> 2). All the AIR source code is released  under GPL?
>>>>> 3). When does AIR source code released? could you send me a copy of
>>> source
>>>>> code foracademic research now?
>>>>>
>>>>> Wenjie
>>>>> Best Regards
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> At 2011-03-21 21:43:52，"Tobias Schoofs"<Tobias.Schoofs at gmx.net>
>>> wrote:
>>>>>> Dear Wenjie,
>>>>>>
>>>>>> your understanding of the AIR system is not 100% correct.
>>>>>>
>>>>>> AIR is a hypervisor that uses para-virtualisation.
>>>>>>
>>>>>> RTEMS is a guest OS for this hypervisor. The guest has to be prepared
>>>>> (para-virtualised) to run on top of the hypervisor. RTEMS is currently
>>> our
>>>>> main target, but there may be other OSes as well (e.g. Linux).
>>>>>> Finally, the AIR hypervisor uses RTEMS *additionally* as hardware
>>>>> abstraction layer (HAL), i.e. the hypervisor itself is based on RTEMS.
>>> For this
>>>>> purpose, we have implemented MMU support as well as superuser/user
>>> level
>>>>> support in RTEMS.
>>>>>> The code is under Lesser GPL and will be made available to the RTEMS
>>>>> community.
>>>>> > From one of your previous e-mails, I got the impression that you plan
>>> a
>>>>> hypervisor that does run-time virtualisation. (You mentioned that you
>>> do not
>>>>> want to change the guest OS.) I am not sure that you will be able to
>>>>> provide sufficient certification/qualification evidence for such a
>>> complex
>>>>> software. At least in areas where ARINC 653 is applied,
>>>>> certification/qualification processes are very demanding. For this
>>> reason, available, commercial
>>>>> hypervirsors (VxWorks 653, PikeOS) use para-virtualisation, not full
>>> run-time
>>>>> virtualisation.
>>>>>> Regards,
>>>>>>
>>>>>> Tobias
>>>>>>
>>>>>>
>>>>>> -------- Original-Nachricht --------
>>>>>>> Datum: Mon, 21 Mar 2011 20:31:31 +0800 (CST)
>>>>>>> Von: "张文杰"<157724595 at 163.com>
>>>>>>> An: "Metge Jean-Jacques"<Jean-Jacques.Metge at cnes.fr>
>>>>>>> CC: RTEMS Users<rtems-users at rtems.org>
>>>>>>> Betreff: RE: GSOC2011 project RTEMS HyperVisor
>>>>>>> AIR/AIR IIseems that it hasimplemented ARINC 653 interface in RTEMS,
>>>>> but i
>>>>>>> do
>>>>>>> not know if these implements is opened. If it is opened we also
>>> modify
>>>>>>> their work,
>>>>>>> Because ARINC 653 interface should be based on Hypervisor
>>> architecture
>>>>>>> whereas
>>>>>>> AIR implement is based on native RTEMS. XtratuM is a independent
>>>>>>> Hypervisor which
>>>>>>> has nothing to do with other OS, but my thought is to add a
>>> Hypervisor
>>>>> to
>>>>>>> RTEMS. Just
>>>>>>> reference the implement of XtratuM
>>>>>>>
>>>>>>>
>>>>>>> At 2011-03-21 16:21:12，"Metge Jean-Jacques"
>>>>> <Jean-Jacques.Metge at cnes.fr>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>>
>>>>>>> For my information, what do you exactly intend to do in the frame of
>>>>> this
>>>>>>> GSOC, that would not have been already done, either in the frame of
>>>>> AIR/AIR
>>>>>>> II or in the frame of XtratuM ?
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Jean-Jacques METGE
>>>>>>> French Space Agency
>>>>>>>
>>>>>>>
>>>>>>> De :rtems-users-bounces at rtems.org
>>>>> [mailto:rtems-users-bounces at rtems.org]De
>>>>>>> la part de ???
>>>>>>> Envoyé : dimanche 20 mars 2011 14:57
>>>>>>> À : 张文杰
>>>>>>> Cc : RTEMS Users
>>>>>>> Objet : Re:GSOC2011 project RTEMS HyperVisor
>>>>>>>
>>>>>>>
>>>>>>> Sorry for forgetting add the reference link.
>>>>>>> [1]. http://www.rtems.com/wiki/index.php/RTEMSHyperVisor
>>>>>>> [2]. http://air.di.fc.ul.pt/air/?Home
>>>>>>> [3].http://www.xtratum.org/
>>>>>>> [4]. http://www.helenos.org/
>>>>>>>
>>>>>>>
>>>>>>> At 2011-03-20 21:50:39，"张文杰"<157724595 at 163.com>  wrote:
>>>>>>> Hi, all:
>>>>>>> I am a student who is preparing for participating the GSOC2011
>>> RTEMS.
>>>>> My
>>>>>>> interested project isRTEMS HyperVisor [1]. This
>>>>>>> project ‘s ultimate goal is to make RTEMS support to run multiple
>>>>>>> operating systems（like Linux or uclinux) and meantime RTEMS can be
>>>>>>> adapted to fullfill the requirements defined in the ARINC 653
>>> standard.
>>>>> So
>>>>>>> the project is divided into two milestone tasks: 1) add a HyperVisor
>>> to
>>>>>>> RTEMS. the design of HyperVisor is compatible with ARINC 653
>>> standard.
>>>>> 2).
>>>>>>> implement ARINC 653 interface in
>>>>>>> RTEMS which can reference the a ESA project named AIR[2].
>>>>>>> Hypervisor, also called virtual machine monitor (VMM), is one of
>>>>>>> virtualization techniqueswhich allow multiple operating systems.
>>>>>>> For embedded systems it must have real-time capability. And there is
>>>>> also
>>>>>>> a challenge to the resource-constrained embedded
>>>>>>> systems, becausesupport for virtualization requiresmemory protection
>>>>> (in
>>>>>>> the form of a memory management unit or at least a
>>>>>>> memory protection unit) and a distinction between user mode and
>>>>> privileged
>>>>>>> mode, which rules out many microcontrollers. About the implement of
>>>>>>> HyperVisor for RTEMS there are two projects we can reference. First
>>> is
>>>>> project
>>>>>>> XtratuM [3] which is a small
>>>>>>> native (bare-metal) hypervisor, now the RTEMS has been ported to
>>>>> XtratuM
>>>>>>> run as a guest OS and its design use ARINC 653 as
>>>>>>> a reference although ARINC-653 is not directly applicable to the
>>>>>>> hypervisor systems. Another project is HelenOS operating
>>>>>>> system [4] which is designed as a relatively small microkernel
>>> assisted
>>>>>>> with a set of userspace drivers and server tasks, Its kernel
>>>>>>> is a good reference candidate for the design of Hypervisor.
>>>>>>> This is just my initial thoughts, if there is any inappropriate
>>> please
>>>>>>> point out.Do not hesitate to add your comments.
>>>>>>>
>>>>>>> Wenjie Zhang
>>>>>>> Best Regards
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
>>>>>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
>>>> --
>>>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
>>>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>>
>> --
>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
>>