From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>,
"Thomas Huth" <thuth@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>,
"qemu-ppc@nongnu.org list:PowerPC" <qemu-ppc@nongnu.org>,
"Alistair Francis" <alistair.francis@xilinx.com>
Subject: Re: [Qemu-devel] [PATCH 4/5] configs: Add a CONFIG_UNIMP switch for the "unimplemented-device"
Date: Sat, 20 Oct 2018 21:57:48 +0200 [thread overview]
Message-ID: <004ec9ef-8568-c645-627d-f7cc2b4df3f6@redhat.com> (raw)
In-Reply-To: <CAFEAcA9QtLnFhPfgRgeduB+avJcC9X8Tea1Hi-2q3p9GtU_j8g@mail.gmail.com>
On 19/10/2018 18:54, Peter Maydell wrote:
> On 19 October 2018 at 17:44, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 19/10/2018 18:25, Philippe Mathieu-Daudé wrote:
>>>
>>> First because I'm using it heavily on MIPS and PPC boards, when no
>>> datashits are available.
>>> I'll submit that during the next merge window, although the MIPS tree
>>> seems now reluctant to that kind of hobbyist work.
>>>
>>> Second, because it is very clean when you implement a SoC to first
>>> start with an empty UNIMP region and a cpu core,
>>> then declare the mmio regions for each device (still UNIMP), then you
>>> can slowly add devices one at a time.
>>> This let you (me, so far) push at most a dozen of tiny patches in a
>>> working series, instead of a small series of a dozen of huge patches,
>>> or a series of 100 tiny patches.
>>
>> I don't see however why it's a problem to add/remove CONFIG_UNIMP to
>> default-configs though (in the Kconfig world the board would "select
>> UNIMP").
>
> Well, it's extra friction for people writing new board models,
> and the benefit of having CONFIG_UNIMP is all to downstream
> redistributors, not to upstream...
>
> I'm not vetoing this patchset, but I do think that if RedHat
> wants to distribute significantly-cut-down binaries then
> it would be worth working on a mechanism for making that
> more conveniently doable, rather than just hacking up
> the very creaky default-configs/ stuff.
Yes, we are going to meet the NEMU guys at KVM Forum and talk about the
"mini-Kconfig" stuff; in the meanwhile, default-configs/ is what we
have, it was enough while we were caring basically only about x86 and
thus we only needed to disable PCI devices, but now it's showing its age.
Paolo
next prev parent reply other threads:[~2018-10-20 19:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-19 13:14 [Qemu-devel] [PATCH 0/5] Add more CONFIG switches to make the build more modular Thomas Huth
2018-10-19 13:14 ` [Qemu-devel] [PATCH 1/5] configs: Add a CONFIG_OR_IRQ switch for the or-irq device Thomas Huth
2018-10-19 13:58 ` Peter Maydell
2018-10-19 13:14 ` [Qemu-devel] [PATCH 2/5] configs: Add a CONFIG_SPLIT_IRQ switch for the split-irq device Thomas Huth
2018-10-19 14:44 ` Peter Maydell
2018-10-19 13:14 ` [Qemu-devel] [PATCH 3/5] configs: Add a CONFIG_REGISTER switch for the "register" device Thomas Huth
2018-10-19 14:44 ` Peter Maydell
2018-10-19 13:14 ` [Qemu-devel] [PATCH 4/5] configs: Add a CONFIG_UNIMP switch for the "unimplemented-device" Thomas Huth
2018-10-19 13:57 ` Peter Maydell
2018-10-19 14:40 ` Thomas Huth
2018-10-19 14:43 ` Peter Maydell
2018-10-19 15:59 ` Paolo Bonzini
2018-10-19 16:25 ` Philippe Mathieu-Daudé
2018-10-19 16:44 ` Paolo Bonzini
2018-10-19 16:54 ` Peter Maydell
2018-10-20 19:57 ` Paolo Bonzini [this message]
2018-10-19 13:14 ` [Qemu-devel] [PATCH 5/5] configs: Add a CONFIG_SMC37C669 switch for the "smc37c669-superio" device Thomas Huth
2018-10-19 14:46 ` Peter Maydell
2018-10-19 16:35 ` Philippe Mathieu-Daudé
2018-10-19 16:38 ` Peter Maydell
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=004ec9ef-8568-c645-627d-f7cc2b4df3f6@redhat.com \
--to=pbonzini@redhat.com \
--cc=alistair.francis@xilinx.com \
--cc=edgar.iglesias@xilinx.com \
--cc=f4bug@amsat.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/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).