On Wed, Jan 18, 2017 at 10:56 AM, Thomas Huth <th...@redhat.com> wrote: > On 18.01.2017 18:57, Alistair Francis wrote: >> On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth <th...@redhat.com> wrote: >>> Sometimes it is useful to have just a machine with CPU and RAM, without >>> any further hardware in it, e.g. if you just want to do some instruction >>> debugging for TCG with a remote GDB attached to QEMU, or run some embedded >>> code with the "-semihosting" QEMU parameter. qemu-system-m68k already >>> features a "dummy" machine, and xtensa a "sim" machine for exactly this >>> purpose. >>> All target architectures have nowadays also a "none" machine, which would >>> be a perfect match for this, too - but it currently does not allow to add >>> CPU and RAM yet. Thus let's add these possibilities in a generic way to the >>> "none" machine, too, so that we hopefully do not need additional "dummy" >>> machines in the future anymore (and maybe can also get rid of the already >>> existing "dummy"/"sim" machines one day). >>> Note that the default behaviour of the "none" machine is not changed, i.e. >>> no CPU and no RAM is instantiated by default. You have explicitely got to >>> specify the CPU model with "-cpu" and the amount of RAM with "-m" to get >>> these new features. >>> >>> Signed-off-by: Thomas Huth <th...@redhat.com> >>> --- >>> v3: >>> - Get rid of the cpu_init_def() wrapper again, make null-machine.o >>> target dependent instead and use cpu_init() directly. >>> - Omit the loader code for the "-kernel" option for now (users can >>> use "-device loader,..." instead). We can add code for the -kernel >>> parameter later (either an implementation or a warning), once we've >>> decided how it should behave for the "none" machine. >> >> I think there should at least be a warning to start with though. It >> seems confusing that no errors are reported but the argument is >> ignored. > > I'm still rather in favor of adding the hunk here that calls the generic > loader for "-kernel" ... anyway, we can add either behavior with a later > patch. So far the "none" machine never reported an error here, so this > is not a regression if we do not have this right from the start.
Your right, it isn't a regression. I still think we should try to get some sort of action in there before the next release. Reviewed-by: Alistair Francis <alistair.fran...@xilinx.com> Thanks, Alistair > > Thomas > >
