qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 01/21] qdev: Replace cannot_instantiate_with_


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v2 01/21] qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable
Date: Wed, 5 Apr 2017 18:25:12 -0300
User-agent: Mutt/1.7.1 (2016-10-04)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]