On 5/8/23 16:19, Thomas Huth wrote:
On 08/05/2023 17.14, Paolo Bonzini wrote:
On 5/8/23 16:27, Thomas Huth wrote:
On 03/05/2023 09.23, Richard Henderson wrote:
If CONFIG_USER_ONLY is ok generically, so is CONFIG_SOFTMMU,
because they are exactly opposite.
I thought there was a difference ... at least in the past?
But looking at meson.build they seem to be handled quite equally now:
common_ss.add_all(when: 'CONFIG_SOFTMMU', if_true: [softmmu_ss])
common_ss.add_all(when: 'CONFIG_USER_ONLY', if_true: user_ss)
Paolo, do you remember whether there was a difference in the past?
No, I don't think so. Really _none_ of them are okay in general, but now that we have
softmmu_ss/user_ss there is a usecase for using them in "generic" sourcesets. So
perhaps we could have something like
/* One of these is always defined in files that can use them. */
#if !defined CONFIG_SOFTMMU && !defined CONFIG_USER_ONLY
#pragma GCC poison CONFIG_SOFTMMU
#pragma GCC poison CONFIG_USER_ONLY
#endif
That's the thing that I had in mind:
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg05269.html
... so instead of removing the poison from CONFIG_SOFTMMU, we should likely rather try to
get CONFIG_USER_ONLY poisoned, too.
A worthy goal, but a large job, just looking at "exec/cpu-common.h".
I will defer that to another patch set, and continue with non-poisoning of CONFIG_SOFTMMU
for now.
r~
