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: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH] machine: set default kernel_cmdline in machine_initfn()
Date: Thu, 29 May 2014 16:21:18 +0300

On Thu, 2014-05-29 at 15:08 +0200, Igor Mammedov wrote:
> 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.
Sounds fine, I can go for it.
Andreas, do you agree?

> 
> > 
> > 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]