qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: julien@xen.org, masami.hiramatsu@linaro.org,
	Andre Przywara <andre.przywara@arm.com>,
	stefano.stabellini@linaro.org,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	Takahiro Akashi <takahiro.akashi@linaro.org>,
	Alistair Francis <alistair23@gmail.com>,
	stefano.stabellini@xilinx.com, stratos-dev@op-lists.linaro.org
Subject: Re: [RFC PATCH 0/4] generic loader FDT support (for direct Xen boot)
Date: Mon, 12 Oct 2020 18:11:21 +0100	[thread overview]
Message-ID: <87imbfz7wm.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA_rySOEc=AD0o79Qz=_1vXFxAEsU9SE7qsxmGUc1DZ_KQ@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 12 Oct 2020 at 17:19, Alex Bennée <alex.bennee@linaro.org> wrote:
>> So the real question is are there any other -devices that we want to be
>> able to graft FDT entries on or is the generic loader enough of a
>> special case that we keep all the logic in there?
>
> To my mind the point of the generic loader is exactly that
> it is not a special case. It works exactly the same way
> for every board, for every architecture. It shouldn't have
> special case "this makes things work for the thing I want
> to load on these boards that all have FDT and want a
> particular change to it". We already have a loader that
> has that kind of "do what I mean" behaviour (--kernel),
> and I very much do not want the generic loader device to
> go in that direction. Its whole advantage is that it is
> not that, but is just a "load the file, nothing else,
> no magic" operation.

So should we introduce a sub-classed -device guest-loader which behaves
like generic loader except that it is also aware of platform data
issues?

The other option would be to add the logic to each board that supports
dynamic platform data. It would keep the problem bounded but also lead
to a fair amount of duplicated boiler-plate.

>
> thanks
> -- PMM


-- 
Alex Bennée


  reply	other threads:[~2020-10-12 17:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 17:07 [RFC PATCH 0/4] generic loader FDT support (for direct Xen boot) Alex Bennée
2020-10-09 17:07 ` [RFC PATCH 1/4] hw/board: promote fdt from ARM VirtMachineState to MachineState Alex Bennée
2020-10-09 17:07 ` [RFC PATCH 2/4] hw/riscv: migrate fdt field to generic MachineState Alex Bennée
2020-10-09 17:07 ` [RFC PATCH 3/4] device_tree: add qemu_fdt_setprop_string_array helper Alex Bennée
2020-10-09 17:07 ` [RFC PATCH 4/4] generic_loader: allow the insertion of /chosen/module stanzas Alex Bennée
2020-10-09 17:24 ` [RFC PATCH 0/4] generic loader FDT support (for direct Xen boot) no-reply
2020-10-09 23:27 ` Alistair Francis
2020-10-12 16:02   ` Alex Bennée
2020-10-12 16:40     ` Peter Maydell
2020-10-12 17:11       ` Alex Bennée [this message]
2020-10-12 17:25     ` Edgar E. Iglesias
2020-10-13 10:11       ` Alex Bennée
2020-10-14 19:51         ` Alistair Francis

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=87imbfz7wm.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=alistair23@gmail.com \
    --cc=andre.przywara@arm.com \
    --cc=julien@xen.org \
    --cc=masami.hiramatsu@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@linaro.org \
    --cc=stefano.stabellini@xilinx.com \
    --cc=stratos-dev@op-lists.linaro.org \
    --cc=takahiro.akashi@linaro.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).