"Daniel P. Berrange" <berra...@redhat.com> writes: [...] > The main problem encountered with this patch series is the > split between argv and config parameters. The qemu-config.c > file provides the information is a good data format, allowing > programatic access to the list of parameters for each config > option (eg, the 'cache', 'file', 'aio', etc bits for -drive). > There are some issues with it though > > - It lacks a huge amount of coverage wrt to the full argv > available, even simple things like the '-m' argument > don't exist. > > - It is inconsistent in handling parameters. eg it hands > off validation of netdev backends to other code, to allow > for handling of different parameters for tap vs user vs > socket backends. For chardev backends though, it directly > includes a union of all possible parameters.
The problem behind this "inconsistency" (first order approximation): there are fixed options, and several sets of variable options. One of the fixed options is the discriminator, and its value determines which set of variable options applies. You can ignore this and put all variable options right into the QemuOptsList.desc[]. qemu-option still catches "alway-invalid" options, but application code needs to check again. If the variable sets conflict, we're reduced to QEMU_OPT_STRING type, and have to leave type-checking to application code. We can also have an empty desc[], and simply leave all of the validation job to application code. Typical way to do it: get discriminator value, look up its desc[], pass it to qemu_opts_validate(). This is how -netdev works. Drawbacks: duplicates fixed options in every desc[], even fixed options are hidden fairly deep in application code. It's easy to do better for fixed options: put them in QemuOptsList.desc[], use qemu_opts_validate() only for the variable options. I hope to post a patch for that soon. Pulling the variable options out of application code is a bit harder. More so for -device than for -netdev. [...]
