Re: [Qemu-devel] [PATCH] machine: set default kernel_cmdline in machine_initfn()

[Markus Armbruster]

Igor Mammedov <address@hidden> writes:

> On Thu, 29 May 2014 14:25:31 +0200
> Andreas Färber <address@hidden> wrote:
>
>> Am 29.05.2014 14:21, schrieb Marcel Apfelbaum:
>> > On Thu, 2014-05-29 at 12:47 +0200, Andreas Färber wrote:
>> >> Am 29.05.2014 11:47, schrieb Igor Mammedov:
>> >>> ... fixes freeing constant from vl.c by machine_finalize()
>> >>>
>> >>> Signed-off-by: Igor Mammedov <address@hidden>
>> >>
>> >> Did you check whether there are any others in need of changes? I could
>> >> imagine kernel_irqchip does, and I see that we forgot to fix the
>> >> underscore in the property name, damn. Marcel, can you please look into
>> >> fixing that? I had outlined how to.
>> > Hi Andreas,
>> > 
>> > I didn't forget to do that, I responded on the mail thread why I think we 
>> > shouldn't,
>> > even if is against QOM best practices.
>> > I'll copy-paste:
>> > 
>> > Anyway, the real problem here is that what is elegant in this solution is:
>> >     machine_opts = qemu_get_machine_opts();
>> >     if (qemu_opt_foreach(machine_opts, object_set_property, 
>> > current_machine, 1) < 0) {
>> >         object_unref(OBJECT(current_machine));
>> >         exit(1);
>> >     }
>> > It automatically fills in the machine state properties with the options 
>> > from the command line.
>> > It will work with machine sub-types that have specific properties without 
>> > the need
>> > to manually add it to vl.c. The error flow is also elegant (if a sub-type 
>> > does not have the
>> > user supplied property).
>> > 
>> > If we use machine-specific wrappers to convert "_" -> "-" we loose the 
>> > above.
>> 
>> There was nothing machine-specific in my proposal. Only the
>> implementation of object_set_property() would need to be extended or
>> copied&modified à la X86CPU and only "-"-based properties added in
>> machine_initfn().
>
> Maybe we can hack QemuOpts to do s/foo_moo/foo-moo/ ?
> Than there won't be need for an explicit conversion and it could be
> reused by others,
> including X86CPU.

'-' vs. '_' has been discussed several times in other contexts.

Command line, QMP and QOM all want '-'.  Nevertheless, '_' keep creeping
in.

There's rough consensus that we should always accept '-'.  We can either
accept '_' everywhere, or only where a previously released version
already did.  We should probably only document '-'.

I'd like us to replace '_' by '-' in the source code, to reduce
recidivism by removing all the bad examples.  Makes accepting '_'
selectively hard, so maybe we should just accept it everywhere.

Patches welcome!

>> > As an alternative we could rename the machine option to use "-"...
>> 
>> That's not been an option for command line compatibility reasons.