On 03/27/2017 04:11 PM, Jan Kiszka wrote:
> On 2017-03-27 15:36, Ralf Ramsauer wrote:
>> Hi,
>>
>> a while ago, we (almost) entirely decoupled hypervisor code from inmate
>> code.  While there were several reasons for decoupling code, many of asm
>> headers could still be shared.
>>
>> Currently, the buildsystem of jailhouse already allows us to include
>> hypervisor's asm headers from inmates, we do that e.g. on ARM for
>> sysregs.h, which is a typical candidate for such kind of shared headers.
>>
>> I just noticed that there are many more duplicated macros or register
>> definitions:
>>   - ARM: GICv2/3 registers are redundantly redefined in inmate and
>>     hypervisor
>>   - Accessors for MMIO (mmio{8,16,32}_{read/write})
>>   - Memory Barrier Macros, cpu_relax
>>   - typedefs for basic types, including bool
>>
>> So my question is if it would make sense if we introduce a separate
>> directory for inmate/hypervisor shared header files and header files
>> only.  Let's call it /headers.  In my opinion, this would be prettier
>> than including hypervisor headers in inmates, and avoid redefinition of
>> hypervisor/inmate independent definitions which we currently do and
>> which tends to be error-prone.
>>
>> I'm asking this because I have some local patches that implement PSCI
>> support for inmates.  I'm already able to boot secondary CPUs on
>> bare-metal inmates, but I don't want to mainline this code, as it
>> introduces yet more duplicated definitions for PSCI commands.  I tried
>> to share those definitions, which ended up in a mess, as hypervisor's
>> asm/psci.h implements more than naming things, so this requires further
>> modification.
>>
>> And before I start fixing things at one location only I thought it could
>> be worth to spend a minute on thinking about a common header directory.
> 
> I would throw in two thoughts here:
> 
> - any inmate usage of hypervisor header should be "free of
>   interference" for the latter, not excluding simple, "harmless"
>   exceptions
In other words: leave the directory structure as it is, and - depending
if it is necessary or not - modify hypervisor headers to bring them in a
shareable shape?
> 
> - if we can continue to use common headers or even expand on this
>   depends on how we continue with the inmates
>    - as a library, possibly with a different license?
Well, the stuff that we include in inmates are mainly very basic
register definitions that name things, and some basic accessors and type
definitions.  We share headers, not code that contains /real/ IP.

So if the license of those headers could make problems in the future, we
should either immediately stop sharing *any* header, or bring those
headers in a shape that they are shareable (including licensing
regards).  I would actually like to avoid duplicated definitions and
basic macros, especially when those duplicates are under different
licenses. :-)

But: at the moment both, inmates and architectural asm headers, are
GPLv2-only. So the the license change issue exists, no matter if we
share headers or not.

  Ralf
>    - as a tool for internal purposes (testing, demos etc.)?
> 
> I don't have an answer for the latter yet, but the former should hold as
> long as we practice that reuse.
> 
> Jan
> 

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