On 05/29/2018 12:08 PM, Peter Maydell wrote: > On 28 May 2018 at 07:11, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: >> The create_unimplemented_device() function is very useful to >> register unimplemented devices to the SysBus 'absolute' address. >> >> Some devices are modelled as container of memory subregions, >> the subregions being mmio-mapped relatively to the container >> base address. >> >> With these container devices, the current create_unimplemented_device() >> does not work. >> Add a function to remove the current limitation, and allow >> containerized devices to use the helpful UnimplementedDevice. >> >> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> >> --- >> I don't like the function name much, I first tried with >> create_unimplemented_device_mr() :( Would it be cleaner renaming current >> create_unimplemented_device() -> create_unimplemented_sysbus_device()? >> >> Also, is this useful to have this code inlined? > > My experience has been that devices that want to map the > unimplemented device into some other container probably > also want to do in-place initialization rather than using > qdev_create() -- eg hw/arm/iotkit.c which directly creates > TYPE_UNIMPLEMENTED_DEVICEs which are embedded in its state > struct. > > It was always the intention that you can create a > TYPE_UNIMPLEMENTED_DEVICE directly; create_unimplemented_device() > is just a convenience wrapper.
OK. > I'm not opposed to having another convenience wrapper here; > but I'm not sure this is the right API for one (ie if it > would be used in very many places). Fair enough. Thanks, Phil.
