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. thanks -- PMM
