On 19/10/2018 18:54, Peter Maydell wrote: > On 19 October 2018 at 17:44, Paolo Bonzini <pbonz...@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
