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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list