[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support |
Date: |
Tue, 8 Jun 2010 15:30:19 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.3; x86_64; ; ) |
> > I'm undecided how much parameterisation it's worth trying to support in
> > the device tree. IMO the current code has way too much magic, because
> > creating a new variant involves hacking and rebuilding pc.c.
>
> See patch 22/22. There is really no magic involved, even though the
> compat machines are not yet as config files.
The magic I'm preferring to is precisely things like pci="on".
This is an artifact of only having a hardcoded single device tree (defined by
pc_init), so we need magic parameters to pick between different variants.
If this were just a cleanup of how we implement the various machines that
would be harmless. However these are now a user-visible interface.
It implies that qemu is expected to know how to add/remove PCI capabilities
from a machine. Once you eliminate machine_register_core that knowledge has
somehow got to come from your device tree description file. Having a single
device tree that can morph into significantly different machines seems like
unnecessary complexity given this is a user-specified file.
> > I'm extremely tempted by the extreme approach of punting everything to an
> > external device tree builder. i.e. remove automagical device reation
> > altogether.
>
> I think this should have been raised when the -readconfig/-writeconfig
> scheme was proposed and committed. I don't think it's reasonable to
> block this patch series (or something very much like it) on the grounds
> that a better device tree description model than QemuOpts can be designed.
I don't see how the introduction of QemuOpts is relevant. That's just a
flexible commandline option handling system, which makes a lot of sense.
What I'm objecting to is making machine construction be controlled by an
arbitrary set of hardcoded parameters. One of the goals of the qdev work is
that you don't need to have hardcoded all the interesting ways a machine can
vary. Instead you can directly specify how to construct the machine.
My argument is that in the short term this parameterization provides limited
benefit, and longer term it's going to be obsolete and probably painful to
support.
Paul
- Re: [Qemu-devel] [PATCH 21/22] machine: convert pc machines to split core vs machine API, (continued)
- [Qemu-devel] [PATCH 20/22] machine: introduce machine core and split qemu_register_machine, Anthony Liguori, 2010/06/07
- [Qemu-devel] [PATCH 18/22] machine: final conversion to pure QemuOpts, Anthony Liguori, 2010/06/07
- Re: [Qemu-devel] [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/07
- [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paolo Bonzini, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support,
Paul Brook <=
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paolo Bonzini, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Alexander Graf, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/09