On Mon, Jun 06, 2016 at 07:14:00 -0400, John Ferlan wrote:
On 06/06/2016 03:23 AM, Peter Krempa wrote:
> On Fri, Jun 03, 2016 at 06:52:51 -0400, John Ferlan wrote:
>> Rather than open coding, follow the secinfo code and use the common
>> secret object build/generate sequence.
>
> The main reason to do this was to have a single code path that generates
> properties both for adding the object to qemu via commandline and via
> monitor. Is this going to be used on the monitor? If not there's no
> reason to do this.
>
The main reason to do this was to have the commandline code generating
the master secret perform the same virJSON* call that the code for
generating the AES secret uses.
Well that is useful only if you are going to use the same code
generating the properties to be used via monitor too. Otherwise the code
will waste quite a few cycles to parse the strings and generate the JSON
structure just to iterate it and format it back to strings.
Not sure what the reference for via monitor is all about.
The idea behind qemuBuildObjectCommandlineFromJSON or
virQEMUBuildObjectCommandlineFromJSON as of 1/5 was to have a common
place that generates properties for objects (namely memory device
backends at the time I wrote that fucntion) so that we don't need to
implement it twice. Once for the command line and once for the monitor.
As the monitor json property can be converted to the commandline it's
desired to use the JSON format then.
If using common code isn't desire, then I can drop it.
It is desire if the code will be used both when generating the command
line and when talking on the monitor. The master key is not the case
since we will not be setting the master key using the monitor.
Additionally since we consider that the monitor is secure from prying
eyes we can pass the secrets directly that way so generating the JSON
props is just a waste of compute time.