Forgot to answer this part on my previous message: On Wed, Apr 05, 2017 at 10:01:29PM +0300, Marcel Apfelbaum wrote: [...] > > When it was introduced, we had 54 > > cannot_instantiate_with_device_add_yet=true lines in the code. > > Today (3 years later) this number has not shrinked: we now have > > 57 cannot_instantiate_with_device_add_yet=true lines. I think it > > is safe to say it is not a temporary measure, and we won't see > > the flag go away soon. > > > > Instead of a long field name that misleads people to believe it > > is temporary, replace it a shorter and less misleading field: > > user_creatable. > > I completely agree with you. I never liked "negation" fields > and especially the ones ending with "_yet". > > I also don't understand why "user_creatable" can't be used for white-listing > *Q35*. > I do understand that on some archs we need a white-list per board, > but I don't think x86 needs it.
It's true that q35 wouldn't break if it simply used user_creatable after applying this series. But it will break if one day we link code that registers a user-creatable non-x86 device inside the qemu-system-x86_64 binary (even if by accident), or if we add a new user-creatable sysbus device for other x86 machines (e.g. isapc, xenfv, xenpv, pc-i440fx). Maybe those situations are unlikely, but if we introduce common infrastructure to let machine-types define their sysbus whitelists[1], we get the ability to define the q35 whitelist for free. [1] See "[RFC 0/4] Replace has_dynamic_sysbus with device type whitelist" -- Eduardo
