Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/11/16 19:28, Julien Grall wrote:
>
>
> On 23/11/16 15:47, Andrii Anisov wrote:
>> Hello Julien,
>
> Hi Andrii,
>
>>> The ACPI support is pretty much contained in a single file and I am
>>> not sure you will win much space.
>>> Can you explain why the ACPI guest support should be optional?
>> This would increase the system configurability and would let one
>> shrink a system to a minimal footprint with required functionality
>> only. Such possibility is very useful in embedded applications.
>>
>> Unfortunately I don't know the exact space impact of this particular
>> feature 'cause I can't build it. From other hand I do not need it in
>> my system. So I would like to have a way to drop not needed
>> functionality easily.
>
> I agree with this argument however...
>
>> BTW, excessive functionality reduction is also a way to get more
>> stable and predictable system.
>
> this statement is not entirely true. There is no automatic test on all
> the possible configurations, although we have travis to test build
> (and not booting) a random Kconfig. Even if we try our best to see any
> problem when reviewing code, we cannot guarantee an error when using a
> different configuration.
>
> And this is becoming a problem as today we have no way to know the
> configuration used when a problem is reported. This is because the
> Kconfig is not embedded in the Xen binary.
>
> I got bitten quite a few times in my development because I had a
> binary but not the Kconfig. It was re-written because I forgot to add
> XEN_CONFIG_EXPERT on the command line.
>
> I might be more inclined to make more feature optional when we will
> have a way to track the configuration of a hypervisor binary.

+10 to this idea.

It isn't hard to compress .config and stash it in .rodata during
compilation, offering it back to the toolstack via a hypercall.  We
already do similar things for the XSM policy.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel