qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] build-sys: add --disable-vhost-user


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH] build-sys: add --disable-vhost-user
Date: Fri, 28 Jul 2017 02:01:31 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 07/26/2017 02:52 PM, Michael S. Tsirkin wrote:
On Tue, Jul 18, 2017 at 06:34:37PM +0200, Marc-André Lureau wrote:
...
In the future, we may want to hide vhost-user from QAPI/introspection
with conditional compilation, although the design of this hasn't been
fully fleshed out yet and shouldn't prevent this patch from being
applied.

Signed-off-by: Marc-André Lureau <address@hidden>

After an offline discussion, looks like the idea is to be able to ship a
cut down binary with less features (and e.g. smaller attack surface?).

I think it deserves it own thread, there will be many ideas about it.

I liked this idea a first because it speeds up compilation time (so the CI build system can run more tests, cover more of less code...) but then we have this unreadable unmanageable ifdefery very hard to maintain, you end up not compiling this piece of code, then move things around, refactor a bit, change some API and zombie code survives around until someone who has this lib try to compile the obsolete code.

This is also why I now prefer to build via docker images (the qemu:debian-amd64 try to come with as many dev packages as possible to increase code coverage).

There is some dream about having one monolithic QEMU binary able to run all cpus/machines/devices. I think this way do reduce attack surface by exposing all the surface. This is a bit what is happening during release candidate testing when /master is closed, people start to use QEMU [differently than while adding features], more surface is stressed, then many issues appear and get resolved.

Thomas Huth did some effort adding more poisoned macros and move common objects to common-obj, we can do more here, we may need to split more sources to move more common code.


Another experience is I'm trying to model a 32-bit big endian ARM board then got bugged with 64-bit code this board will never use, or issue with PCI and AHCI, so I started to comment those objects using obj-$(CONFIG_X) but then CONFIG_X also depends of CONFIG_Y and so, then it become hardly scalable, see [1]:

+CONFIG_LAN9118=$(or $(CONFIG_REALVIEW),$(CONFIG_EXYNOS4),$(CONFIG_FSL_IMX31)) +CONFIG_SMC91C111=$(or $(CONFIG_PXA2XX),$(CONFIG_MAINSTONE),$(CONFIG_REALVIEW)) +CONFIG_ARM_MPTIMER=$(or $(CONFIG_A9MPCORE),$(CONFIG_ARM11MPCORE),$(CONFIG_A15MPCORE))
+CONFIG_HIGHBANK=$(and $(CONFIG_A9MPCORE),$(CONFIG_A15MPCORE))

we already have:

crypto-obj-$(if $(CONFIG_NETTLE),n,$(if $(CONFIG_GCRYPT_HMAC),n,y)) += hmac-glib.o crypto/Makefile.objs:23:crypto-obj-$(if $(CONFIG_GCRYPT),n,$(if $(CONFIG_GNUTLS_RND),n,y)) += random-platform.o

I ended dropping this branch, I was thinking about using kconfig to manage dependencies... The obj-$(CONFIG_XYZ) is useful when kept tiny, at most 1 bitwise operation.

I wanted to share my experience and thoughts about it, I hope it's still understandable because it's very late :S

Regards,

Phil.

> Besides failing build on freebsd, this patch has too much ifdefery for
> my taste. How about we patch just net/net.c?

[1] https://github.com/philmd/qemu/commit/2c1c515345d626f47d0968821980f9389d4588b2#diff-6006132695caf8d409e781fbf3d4401f



reply via email to

[Prev in Thread] Current Thread [Next in Thread]