On 18.10.2021 17:28, Juergen Gross wrote: > On 18.10.21 14:58, Jan Beulich wrote: >> On 15.10.2021 14:51, Juergen Gross wrote: >>> Instead of repeating similar data multiple times use a single source >>> file and a generator script for producing prototypes and call sequences >>> of the hypercalls. >>> >>> As the script already knows the number of parameters used add generating >>> a macro for populating an array with the number of parameters per >>> hypercall. >> >> Isn't that array intended to go away? > > I thought so, yes, but on Arm there is a case where it is needed. > > So generating it from the available data is the sensible thing to do > IMO.
Absolutely, if such a table continues to be needed. >>> @@ -466,6 +468,14 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h: asm-offsets.s >>> echo ""; \ >>> echo "#endif") <$< >$@ >>> >>> +quiet_cmd_genhyp = GEN $@ >>> +define cmd_genhyp >>> + awk -f scripts/gen_hypercall.awk <$< >$@ >>> +endef >>> + >>> +include/xen/hypercall-defs.h: include/hypercall-defs.i >>> scripts/gen_hypercall.awk FORCE >>> + $(call if_changed,genhyp) >> >> As per patch 5 there are quite a few sources including xen/hypercall.h >> and hence (in one of the next patches) the header generated here. If >> this one gets re-generated for a benign reason (i.e. without changing >> the header), all dependents will get rebuilt for no reason. Use >> $(move-if-changed ...)? > > The reasons for re-generating are quite limited. The most probable case > is a .config change, which will trigger quite some rebuild anyway. Oh, good point - I should also have considered the dependencies here, which are pretty limited. Please disregard my remark then. Jan
