diff options
Diffstat (limited to 'results/classifier/118/none/1775366')
| -rw-r--r-- | results/classifier/118/none/1775366 | 56 |
1 files changed, 56 insertions, 0 deletions
diff --git a/results/classifier/118/none/1775366 b/results/classifier/118/none/1775366 new file mode 100644 index 000000000..4a01d9132 --- /dev/null +++ b/results/classifier/118/none/1775366 @@ -0,0 +1,56 @@ +device: 0.746 +performance: 0.740 +graphic: 0.730 +user-level: 0.726 +ppc: 0.646 +semantic: 0.573 +architecture: 0.554 +network: 0.546 +socket: 0.545 +arm: 0.508 +register: 0.506 +permissions: 0.480 +mistranslation: 0.479 +vnc: 0.423 +assembly: 0.406 +kernel: 0.381 +peripherals: 0.354 +debug: 0.350 +x86: 0.343 +VMM: 0.333 +i386: 0.310 +hypervisor: 0.307 +PID: 0.253 +risc-v: 0.246 +boot: 0.225 +KVM: 0.225 +virtual: 0.222 +TCG: 0.202 +files: 0.127 + + [Feature request] qemu-ga - Allow unexpected parameter + +It whould be nice if the qemu-ga allowed received messages to contain fields which is not part of the spec. In my example I have a host which sends the following request: + +{"execute":"guest-exec","arguments":{"path":"prl_nettool","capture-output":true,"execute-in-shell":false,"arg":[...]}} + +Right now this request is rejected with the following error: + +{"error": {"class": "GenericError", "desc": "Parameter 'execute-in-shell' is unexpected"}} + +My situation is the hosting provider I use does have some customized solution which sends some extra arguments. I have manually patched my qemu-ga so it accepts the "execute-in-shell" parameter but I don't think this should be necessary. + +Instead of "Error" it should just be a "warning" returned to the user of qemu-ga but the call should still be executed. + +This sounds an awful lot like your hosting provider expects you to be using a specialized version of qemu-ga which you are not using. + +It is my opinion that it's dangerous for a client to accept partial commands and try to execute them anyway, as those ignored parameters drastically change the semantics of various commands. + +We don't know what we don't know, so this doesn't sound safe. + +I see you point. Just close this issue. + +I agree with John, accepting commands that have not fully been understood is just too dangerous. So closing this as Won't-Fix. + +BTW, if you have any friendly contact with the your hosting provider, please encourage them to contribute any enhancements they have back to QEMU. It is highly desirable to *NOT* have hosting providers needing a fork of qemu-ga, as that ruins ability to run standard disk images, as you've found. + |