Hi,
Doesn't make sense. The list is not about *creating* default devices, but
about *not* creating them.
Why do we need a negative list? Wouldn't it be a lot more useful to have
positive lists? Maybe I'm just missing the whole point of your patchset though.
Probably the latter ;)
The situation we have right is (with the serial lines as example, the
same applies to some other devices as well):
(1) If you start qemu without any arguments, it will automagically
create a chardev for the serial line (serial_hds[]), which then
will be used by machine->init() to create the (board-specific)
serial lines.
(2) If you start qemu with -serial <something> the specified chardev
will be created and assigned to serial_hds[], which again will be
used by machine->init() ...
Worked fine before qdev appeared. Now we also can create serial lines
like this:
(3) Start qemu with '-device isa-serial,...'.
Problem is this clashes with (1) and qemu will attempt to create the
serial port twice. So this patchset introduces default_serial
(+friends) to fix this issue. The new workflow is:
* default_serial defaults to enabled, when qemu finds it still enabled
after processing all command line the automagic default serial line
is actually created.
* If qemu finds '-serial <something>' it clears default_serial.
* If qemu finds '-device isa-serial,...' it clears default_serial.
- this fixes the conflict mentioned above.
- other serial drivers can be added to the list if needed to solve
the same conflict for them.
* If qemu finds '-nodefaults' it clears default_serial (and the
others).
- new feature, figured this could be useful.
What we could do on top of the above is:
* If the board has the machine->no_serial flag set, clear
default_serial.
s390 could set that flag then and qemu would stop creating a chardev for
a serial line nobody will ever use because s390 has no serial ports.
/me hopes the whole picture is more clear now.
cheers,
Gerd