On Fri, Oct 06, 2023 at 12:33:48PM +0100, Mark Brown wrote: > On Fri, Oct 06, 2023 at 09:23:59AM +0000, Oliver Upton wrote: > > On Fri, Oct 06, 2023 at 01:23:08AM +0100, Mark Brown wrote: [...] > > incidental user of this via cputype.h, KVM selftests is what's taking > > the direct dependency. > > If perf doesn't care perhaps just restructure things so it doesn't pull > it in and do whatever you were doing originally then? The only option would be to use yet another set of headers that are specific to KVM selftests, which I feel would only complicate things further. > > > Surely if perf is happy to peer into the main kernel source it could > > > just as well do the generation as part of the build? There's no great > > > obstacle to having a target which runs the generation script that I > > > can see. > > > That'd be less than ideal, IMO. tools maintaining a separate set of kernel > > headers from the authoritative source avoids the need to coordinate > > changes across kernel and tools. To keep things that way we either need > > to copy the script+encoding or the header output. The latter isn't that > > bothersome if/when we need an update. > > The error Stephen found was: > > | In file included from util/../../arch/arm64/include/asm/cputype.h:201, > | from util/arm-spe.c:37: > | tools/arch/arm64/include/asm/sysreg.h:132:10: fatal error: asm/sysreg-defs.h: No such file or directory > > so that's already happening - see perf's arm-spe.c. You could also fix > perf by avoiding spelunking in the main kernel source like it's > currently doing. My interpretation of that relative path is tools/arch/arm64/include/asm/cputype.h The include path in tools/perf/Makefile.config is using tools/ headers as well: INC_FLAGS += -I$(src-perf)/util/include INC_FLAGS += -I$(src-perf)/arch/$(SRCARCH)/include INC_FLAGS += -I$(srctree)/tools/include/ INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/uapi INC_FLAGS += -I$(srctree)/tools/include/uapi INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/ INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/ perf + KVM selftests aren't directly using kernel headers, and I'd rather not revisit that just for handling the sysreg definitions. So then if we must periodically copy things out of the kernel tree anyway, what value do we derive from copying the script as opposed to just lifting the generated output? We must do _something_ about this, as updates to sysreg.h are blocked until the handling of generated headers gets worked out. -- Thanks, Oliver
