On Thu, Oct 01, 2020 at 05:57:14PM +0200, Philippe Mathieu-Daudé wrote: > On 10/1/20 5:37 PM, Eduardo Habkost wrote: > > On Thu, Oct 01, 2020 at 05:27:32PM +0200, Philippe Mathieu-Daudé wrote: > >> On 10/1/20 5:14 PM, Paolo Bonzini wrote: > >>> On 01/10/20 16:41, Philippe Mathieu-Daudé wrote: > >>>> The feature-words properties are not used in user-mode emulation, > >>>> restrict it to system-mode. > >>>> > >>>> Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com> > >>> > >>> This seems a bit pointless honestly. It's going to be a few KBs of code > >>> at most. I would end the work with the patches that have already been > >>> queued. > >> > >> I'll let Eduardo and you discuss that, as he suggested the #ifdef > >> instead of the stub. The two options are on the list, whichever > >> you guys prefer :) > > > > Having neither the stub or the #ifdef is even better. :) > > > > I assumed the stub was necessary as a means for an end, but now I > > don't understand why the stub was necessary in the first place. > > x86_cpu_get_feature_words() calls QAPI-generated > visit_type_X86CPUFeatureWordInfoList(). > > Since "Only qemu-system-FOO and qemu-storage-daemon provide QMP > monitors", this code is unreachable on user-mode.
This is true, but you are shaving a tiny fraction of target/i386/cpu.c code unreachable in user-mode. I agree with Paolo that it's pointless. > > I tried to get a "no ifdef/no stub" codebase by not removing the > QAPI uses from user-mode code, and build it without QAPI-generated > files. I could only start the work and realized it is a huge effort. > In particular since nobody sees the point of doing this cleanup... I don't see the point of removing QAPI-generated files from user-mode. Long term, I'd expect to see more QAPI usage in QEMU, which will probably include code used by user-mode. -- Eduardo
