On 01/22/2010 04:15 AM, Markus Armbruster wrote:
Anthony Liguori<aligu...@us.ibm.com> writes:
This option can be used to toggle whether each default device is enabled or
disabled. For character devices, the default backend can also be overridden.
For devices, we'll have to take a different approach to changing the defaults
which will be covered in the next patch.
N.B. I took special care with -nographic. Now -nographic pretty clearly acts
as a mechanism to override the default backend devices.
Signed-off-by: Anthony Liguori<aligu...@us.ibm.com>
---
qemu-config.c | 45 +++++++++++++++++++++++++++++++++
qemu-config.h | 1 +
qemu-options.hx | 7 +++++
vl.c | 75 +++++++++++++++++++++++++++++++++++++++++--------------
4 files changed, 109 insertions(+), 19 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index c3203c8..82ca399 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -242,6 +242,50 @@ QemuOptsList qemu_mon_opts = {
},
};
+QemuOptsList qemu_default_opts = {
+ .name = "default",
+ .head = QTAILQ_HEAD_INITIALIZER(qemu_default_opts.head),
+ .desc = {
+ {
+ .name = "serial",
+ .type = QEMU_OPT_STRING,
+ },
[...]
diff --git a/qemu-options.hx b/qemu-options.hx
index 57f453d..e81ecb5 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1919,6 +1919,13 @@ STEXI
Don't create default devices.
ETEXI
+DEF("default", HAS_ARG, QEMU_OPTION_default, \
+ "-default arg specify default devices\n")
Isn't this too terse?
Yes. Thanks for pointing that out.
+STEXI
+...@item -defaults
+Override builtin default devices
+ETEXI
This *is* too terse :)
Oh, and it's -default (sans 's'). Same typo in subject.
While we're talking about naming: isn't -default a bit too generic a
name for something that manipulates devices? Not sure we care, as
-nodefaults is much worse, already.
Absolutely. I'm going to split out the config loading bits because they
should be easy to commit. How to best handle defaults could use some
more thought. I think this is a key bit of functionality to get right
though because it solves a whole class of problems relating to upstream
policy vs. downstream policy.
I very much like the idea of having a qdev property 'default' to signify
that this is a default device. It means we could easily allow a user to
universally enable usb devices, etc without baking a default_usb concept
into qemu. Ideally, we could eliminate the whole default mess we have
today by doing this, provided that we can implement the right semantics.
Today, those semantics are, if we specify any device of the same
"class", do not load default devices of that class. It's unclear how to
specify the concept of a "class" though. I know Gerd brought this up
ages ago and both Paul and I were very opposed to it but I certainly
appreciate the fact that it would simplify default device handling.
It's definitely clear that each device needs to be able to be part of
multiple default-class's. We could potentially introduce a qdev
property and label every device with a class array but that's a lot of
ugliness just to support defaults. I still would prefer that there was
a more discoverable way to determine the class of a device as opposed to
explicitly labelling it.
If we need to do class tagging, I guess it's not the end of the world...
Regards,
Anthony Liguori
[...]
