Am 10.08.2016 um 00:03 hat Max Reitz geschrieben: > Well, there are two things this can mean. One is that -drive should > exercise the same code path at blockdev-add, and actually it pretty much > does, at least insofar that -drive's functionality is a superset of that > of blockdev-add
You wish! :-) -drive cannot create BlockDriverStates without a BlockBackend. Which is the reason why I started to think we will get a -blockdev after all. > so it can only use blockdev-add's code for that part of > its functionality. In the future, we might want to go further than this > and actually translate -drive into a set of QMP commands, but we don't > have the full -drive functionality in QMP yet (without resorting to > HMP's drive_add, that is). I don't think translating it into QMP will be easy enough for -drive to make it worthwhile. Things may look a bit different with a new -blockdev. > Also, there's the some-parameters-are-optional issue you talked about > above. How do you translate -drive if=none,file=foo.img to a > blockdev-add command? It gets tricky because you have to specify some > format, but you actually cannot because you don't know it. That is one > reason we may introduce a probing block driver at some point or another > (i.e. you specify "probe-format" or something as the driver and this > will then cause qemu to probe the format). > > The other thing I can imagine is the idea that management tools should > (at least be able to) start a bare-bone qemu which actually doesn't have > anything on it (no hardware other than a motherboard) and then begin to > plug stuff into it at runtime instead of on the command line. > > One reason one might want to do this is "because you can". Another is > that the process of making qemu able to start without anything would > probably make it possible to reduce start-up times for light-weight VMs > by a lot. And the real reason is to get rid of duplication: Only one interface to configure block devices instead of two separate ones (QMP and command line) which have to be supported both in qemu and in management tools. > Apart from that, one could probably consider -drive legacy and > blockdev-add not-so-legacy, because the latter is effectively more > powerful (-drive and blockdev-add pretty much give you the same > features, but using the command line to construct a large BDS tree is > pretty icky, so you probably don't want to use -drive for large BDS > trees) and simpler to use by management tools. > > Finally, if we ever get to the point where we can and do translate > -drive to a set of QMP commands, there really is no difference between > whether it's qemu or the management layer which does this translation. Kevin
pgpmmyP7dfBaR.pgp
Description: PGP signature
