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.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
