qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] boards: add a 'none' machine type to all platfo


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] boards: add a 'none' machine type to all platforms
Date: Thu, 23 Aug 2012 14:03:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0

Am 23.08.2012 00:42, schrieb Anthony Liguori:
> Peter Maydell <address@hidden> writes:
> 
>> On 22 August 2012 21:24, Anthony Liguori <address@hidden> wrote:
>>> This allows any QEMU binary to be executed with:
>>>
>>>   $QEMU_BINARY -qmp stdio
>>
>> ...presumably you mean -qmp stdio -M none ?
>>
>>>
>>> Without errors from missing options that are required by various boards.  
>>> This
>>> also provides a mode that we can use in the future to construct machines
>>> entirely through QMP commands.
>>
>> How about documenting this machine (and its purpose) somewhere?
> 
> Okay, but where?  I don't know an obvious place.
> 
>>> Cc: Daniel Berrange <address@hidden>
>>> Cc: Markus Armbruster <address@hidden>
>>> Signed-off-by: Anthony Liguori <address@hidden>
>>> ---
>>>  hw/Makefile.objs  |    2 ++
>>>  hw/null-machine.c |   40 ++++++++++++++++++++++++++++++++++++++++
>>>  2 files changed, 42 insertions(+), 0 deletions(-)
>>>  create mode 100644 hw/null-machine.c
>>>
>>> diff --git a/hw/Makefile.objs b/hw/Makefile.objs
>>> index 7f57ed5..6dfebd2 100644
>>> --- a/hw/Makefile.objs
>>> +++ b/hw/Makefile.objs
>>> @@ -134,6 +134,8 @@ hw-obj-$(CONFIG_DP8393X) += dp8393x.o
>>>  hw-obj-$(CONFIG_DS1225Y) += ds1225y.o
>>>  hw-obj-$(CONFIG_MIPSNET) += mipsnet.o
>>>
>>> +hw-obj-y += null-machine.o
>>> +
>>>  # Sound
>>>  sound-obj-y =
>>>  sound-obj-$(CONFIG_SB16) += sb16.o
>>> diff --git a/hw/null-machine.c b/hw/null-machine.c
>>> new file mode 100644
>>> index 0000000..69910d3
>>> --- /dev/null
>>> +++ b/hw/null-machine.c
>>> @@ -0,0 +1,40 @@
>>> +/*
>>> + * Empty machine
>>> + *
>>> + * Copyright IBM, Corp. 2012
>>> + *
>>> + * Authors:
>>> + *  Anthony Liguori   <address@hidden>
>>> + *
>>> + * This work is licensed under the terms of the GNU GPL, version 2 or 
>>> later.
>>> + * See the COPYING file in the top-level directory.
>>> + *
>>> + */
>>> +
>>> +#include "qemu-common.h"
>>> +#include "hw/hw.h"
>>> +#include "hw/boards.h"
>>> +
>>> +static void machine_none_init(ram_addr_t ram_size,
>>> +                              const char *boot_device,
>>> +                              const char *kernel_filename,
>>> +                              const char *kernel_cmdline,
>>> +                              const char *initrd_filename,
>>> +                              const char *cpu_model)
>>> +{
>>> +}
>>> +
>>> +static QEMUMachine machine_none = {
>>> +    .name = "none",
>>> +    .desc = "empty machine",
>>> +    .init = machine_none_init,
>>> +    .max_cpus = 0,
>>> +};
>>> +
>>> +static void register_machines(void)
>>> +{
>>> +    qemu_register_machine(&machine_none);
>>> +}
>>> +
>>> +machine_init(register_machines);
>>
>> We seem to be about evenly split about whether machine_init()
>> should have a trailing semicolon (it doesn't need one
>> but it doesn't hurt either...)
> 
> It's obviously superior to use a semicolon...  C is completely
> consistent synactically about the usage of semicolons afterall :-)

I disagree. This macro does not turn into a statement but a full
function definition. Neither our Coding Style nor any other that I know
does

void foo(bar baz)
{
};

with a trailing semicolon. For type_init() I cleaned this up, and I
attribute the existing semicolons to people's ignorance of what these
macros actually do.

You might remember that Eduardo and I wanted to QOM'ify machines so that
machine_init() would get replaced with type_init() but you stopped us at
the time, leaving it untouched. So there's no strict need to go through
and change existing users, but I believe in setting good examples.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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