On Fri, Oct 06, 2023 at 01:23:08AM +0100, Mark Brown wrote: > On Thu, Oct 05, 2023 at 06:03:23PM +0000, Oliver Upton wrote: > > > Wiring up the build infrastructure necessary to generate the sysreg > > definitions for dependent targets (e.g. perf, KVM selftests) is a bit of > > an undertaking with near zero benefit. Just take what the kernel > > generated instead. > > > > Cc: Mark Brown <broonie@xxxxxxxxxx> > > Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx> > > --- > > tools/arch/arm64/include/asm/sysreg-defs.h | 6806 ++++++++++++++++++++ > > 1 file changed, 6806 insertions(+) > > create mode 100644 tools/arch/arm64/include/asm/sysreg-defs.h > > If we're going to go with this approach we should probably script the > syncing of the generated file and ideally have something that detects if > there is a generated copy in the main kernel build with differences to > what's here. There are regular syncs which I'm guessing are automated > somehow, and I see that perf has some tooling to notice differences in > the checked in files alraedy. Yeah, I see no reason why this can't plug in to the check-headers script to look at the output from the kernel side of the show. > That said I'm not 100% clear why this isn't being added to "make > headers" and/or the perf build stuff? Isn't 'make headers' just for UAPI headers though? Also, perf is just an incidental user of this via cputype.h, KVM selftests is what's taking the direct dependency. > 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. -- Thanks, Oliver
