From: Thomas Huth <thuth@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Cc: Alistair Francis <alistair.francis@xilinx.com>,
Laurent Vivier <laurent@vivier.eu>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] hw/core/null-machine: Add the possibility to instantiate a CPU, RAM and kernel
Date: Tue, 17 Jan 2017 14:02:24 +0100 [thread overview]
Message-ID: <bbf5a7e6-8ba9-c3e7-ed5d-17f88f99f146@redhat.com> (raw)
In-Reply-To: <20170117123625.GG3491@thinpad.lan.raisama.net>
On 17.01.2017 13:36, Eduardo Habkost wrote:
> On Tue, Jan 17, 2017 at 09:29:19AM +0000, Peter Maydell wrote:
>> On 16 January 2017 at 19:44, Eduardo Habkost <ehabkost@redhat.com> wrote:
>>> On Mon, Jan 16, 2017 at 07:27:21PM +0000, Peter Maydell wrote:
>>>> On 16 January 2017 at 19:25, Eduardo Habkost <ehabkost@redhat.com> wrote:
>>>>> On Mon, Jan 16, 2017 at 10:53:07AM -0800, Alistair Francis wrote:
>>>>>> On Sun, Jan 15, 2017 at 11:59 PM, Thomas Huth <thuth@redhat.com> wrote:
>>>>>>> But I think the users also expect the "-kernel" parameter to be working,
>>>>>>> so I think we should add the loader code in null-machine.c anyway.
>>>>>>
>>>>>> I agree that uses probably expect the '-kernel' option to work as well.
>>>>>
>>>>> So, is it possible to write a generic load_kernel() function that
>>>>> simply reuses the generic-loader code?
>>>>
>>>> No, because users expect -kernel to actually load a Linux kernel
>>>> (meaning with the calling conventions etc the kernel requires),
>>>> whereas generic-loader is just "load a binary blob and start there".
>>>
>>> I don't mean a generic function that works for all machines and
>>> architectures, but a generic function that is good enough for
>>> "-machine none". Isn't "load a binary blob and start there"
>>> exactly what machine_none_load_kernel() in this patch does?
>>
>> If you just want "load a blob and start it" then we already
>> have -device loader. Making -kernel have yet another set of
>> semantics that this time depends on the machine being selected
>> seems like a bad idea. If -kernel doesn't do what it does
>> for the other machines of the same architecture then we should
>> just not accept it.
>
> Good point. In this case, implementing -kernel on "-machine none"
> will require calling an arch-specific hook from the beginning.
> I'm not sure if it's worth the effort, but I won't object if
> somebody really wants to implement that.
The -kernel parameter is not just only dependent on the target
architecture, it is even dependent on the machine type, e.g. on ppc it
is quite different between embedded (e500.c) and server (spapr.c)
variants. So an arch-specific hook might not make too much sense and
using the generic loader is likely the best we can do - if that does not
work, you likely can't use the "none" machine anyway.
> While this is not implemented, I suggest we make "-machine none"
> reject -kernel instead of silently ignoring it.
I'd prefer to use the generic loader for "-kernel" as a shortcut to
"-device loader,file=..." here, but if the common sense is rather to
refuse the -kernel option on the "none" machine, that's OK for me, too.
Anybody else got an opinion on this?
Thomas
next prev parent reply other threads:[~2017-01-17 13:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-14 6:51 [Qemu-devel] [PATCH] hw/core/null-machine: Add the possibility to instantiate a CPU, RAM and kernel Thomas Huth
2017-01-14 11:03 ` Laurent Vivier
2017-01-16 7:59 ` Thomas Huth
2017-01-16 18:53 ` Alistair Francis
2017-01-16 19:25 ` Eduardo Habkost
2017-01-16 19:27 ` Peter Maydell
2017-01-16 19:44 ` Eduardo Habkost
2017-01-17 9:29 ` Peter Maydell
2017-01-17 12:36 ` Eduardo Habkost
2017-01-17 13:02 ` Thomas Huth [this message]
2017-01-16 17:25 ` Eduardo Habkost
2017-01-16 19:52 ` Thomas Huth
2017-01-16 20:07 ` Eduardo Habkost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bbf5a7e6-8ba9-c3e7-ed5d-17f88f99f146@redhat.com \
--to=thuth@redhat.com \
--cc=alistair.francis@xilinx.com \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jcmvbkbc@gmail.com \
--cc=laurent@vivier.eu \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).