>>> pre_plug isn't part of device, it's a separate part that might vary >>> depending on machine and which might modify device properties along >>> the way and then exaggerating we would need 'prepare2()' and after >>> that 'pre_plug2()' and ... >> >> That's how two parties (device vs hotplug handler) work together to get >> results done ... Just like inititalize() -> realized() vs. pre_plug -> >> plug(). There has to be some hand shaking. > In general hotplug handler is optional, for example a board might > create initial memory wit fixed layout as: > dev = object_new(dimm) > set memdev + set addr > qdev_init_no_fail() > > generalized pc-dimm helpers for hotplug handler is just impl. detail, > a board might have other ideas how to use pc-dimm and choose to > implement wiring differently. So device model should do sanity checks > independently from whomever uses it.
In general, I am not a fan of implementing things the "what if someday ..." way. It overcomplicates code and you can be sure that usually something is missed either way (as there is no concrete use case, not even in somebodys mind). But I can see that for pc-dimms that can actually make sense (in contrast to other, more specific devices). -- Thanks, David / dhildenb
