It has been observed kernel modules depending on these header files
may sporadically fail to build. By enforcing a build order, the
problem is solved.
MFC after: 1 week
Sponsored by: NVIDIA Networking
Differential D40191
build: Ensure assym.inc and offset.inc are generated in proper order. • hselasky on May 21 2023, 4:13 PM. Authored by Tags None Referenced Files
Subscribers
Details
Diff Detail
Event TimelineComment Actions Do you really need both? Before depend is how we do all the other ones like this... unless something has changed that I missed Comment Actions @imp : Get me right: Maybe I need to += them to a new variable? When you have "beforedepend:" inside a .if conditional, is that respected? What I meant to code is: When these files are needed, assym.inc and offset.inc, they need to happen beforedepend and beforebuild. There is no problem when using -j1 . I only saw this occasionally when using -jXX . --HPS Comment Actions Which modules need .inc files? For amd64, I cannot think about any except efirt.ko and might be linux.ko. You incur the overhead to generate the files to all modules, from my reading. Comment Actions I thought all of the modules need offset.inc: sys/systm.h: #ifdef _KERNEL ... #include <sys/kpilite.h> ... sys/kpilite.h will use them if: #if !defined(GENOFFSET) && (!defined(KLD_MODULE) || defined(KLD_TIED)) && defined(_KERNEL) #include "offset.inc" (note redundant check for _KERNEL). KLD_TIED is defined in .if defined(MODULE_TIED) CFLAGS+= -DKLD_TIED .endif which means maybe all of them if you wanted to build a tied set of modules, though MKMODULESENV+= MODULE_TIED=yes though if they are built as part of world or via some standalone route in ports they don't I'm still not sure offset.inc was a good idea, but replacing it is fraught. Comment Actions I was hoping you'd know why both were needed, since we have in bsd.dep.mk: depend: beforedepend ${DEPENDFILE} afterdepend ... beforebuild: depend which would mean that beforedepend is always done before beforebuild. If you need them both, Comment Actions I was going to say don't make beforebuild depend on depend The DIRDEPS_BUILD uses beforebuild to trigger things (like generating and staging headers) before we try to compile anything Comment Actions
FWIW bsd.dep.mk only does beforebuild: depend when MK_DIRDEPS_BUILD is "no".
Comment Actions The patch as is should work fine. genlist += assym.inc .. .if ${MK_DIRDEPS_BUILD} == "yes" beforebuild: ${genlist} .else befordepend: ${genlist} .endif the above (apart from the crappy list name) would perhaps make it more obvious why we have two possible dependencies. Another alternative would be to just add a comment Comment Actions Ok. A comment about why is good for me.. I should have looked more deeply. Thanks @sjg... Comment Actions
I also thought using a variable would be more clear. About both beforedepend and beforebuild, the reasoning was the following: Aren't dependencies created after the first compilation? In other words I concluded both targets need to depend on generating these files. --HPS Comment Actions Your conclusion is valid only for meta mode. For non-meta mode, beforedepend is always buiilt before beforebuild, even if you aren't generating the .depend files. So your logic doesn't match the code, and having an expliict comment about why both is better. And that discitnction should be explicitly called out because otherwises it looks redundant to people that know the code and they might remove it if the justistifcaion isn't there with specificity (and not the logical conclusion, but the actual implementation). It tripped me up and I've been looking at this stuf for 20 years... I'm not sure I agree an extra variable is needed here. I'm not sure what it advantge that has, but I'll see what you come up with there. |