qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] machine: set default kernel_cmdline in machine_


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH] machine: set default kernel_cmdline in machine_initfn()
Date: Thu, 29 May 2014 15:08:02 +0200

On Thu, 29 May 2014 15:56:16 +0300
Marcel Apfelbaum <address@hidden> wrote:

> On Thu, 2014-05-29 at 14:40 +0200, Igor Mammedov wrote:
> > 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.
> I like this idea, but this can't be generic for all QemuOpts right? Do you
> mean adding a flag specifying we want this conversion?
Flag would be less risky than doing it for all QemuOpts unconditionally.
It would open road for conversion per a QemuOpts which probably should be
done eventually if options are translated into properties.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]