qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 01/25] configure: We don't want to clean configu


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH 01/25] configure: We don't want to clean configuration files
Date: Tue, 17 Jul 2018 22:22:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Peter Maydell <address@hidden> wrote:
> On 17 July 2018 at 18:27, Juan Quintela <address@hidden> wrote:
>> On the other hand, sometimes it looks like I am the only user that use
>> this.  The original reason for this was to be able to compile out
>> drivers that downstream don't care about.  There were a couple of
>> intents to integrate with something like kernel kconfig, but I think
>> that we never end integrating anything from there.
>
> I think "be able to compile out stuff you don't want" is
> useful from a "reduce the security boundary" perspective,
> and indeed we have at least one fork of QEMU which is
> basically aimed at chopping stuff out, so there's a group
> of users who'd like to be able to do that

agreed about that.  Some of the bits are just there for historical
reasons, or it was easier to do it that way.  Case in hand, vfio-spapr,
we compile it in always, but my understanding is that it is only used on
ppc.  On the other hand, spliting things complicates things a lot, see
for instance the virtio-pci.c example that I gave on other answer.  You
can split instead of #ifdef, but need yet another registration.

>-- you're not on
> your own in that sense. But it probably does require more
> serious effort if we want to address this use case, so as
> always it comes down to whether anybody wants to do the work,
> I guess.

Completely agree.  I can justify the effort that I put to be able to
"compile less stuff and then compile faster".  Doing it properly takes
more time that I can afford right now.

I care mostly about x86_64-seftmmu with kvm, appart from the bits that I
sent, the other low hanging fruit that I can think of is:

- being able to compile only q35 or i440fx
- split CONFIG_RDMA into CONFIG_RDMA_DEVICES and CONFIG_RDMA_MIGRATION

Thing that could be clearer:
- What is the difference between CONFIG_VIRTIO_VGA and COVFIG_VIRTIO_GPU
- can we really drop/make optional isapc, yes, I know that some things
  still hang from there.
- VHOST_USER_SCSI, VHOST_USER, VIIRTIO_SCSI, VIRTIO_BLK,
  VIRTIO_DATAPLANE, VHOST_BLK and who knows what.  It is not clear to me
  which ones are the ones that I want.

Later, Juan.



reply via email to

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