On 12/22/21 06:36, Jason A. Donenfeld wrote: > In preparation for using blake2s in the RNG, we change the way that it > is wired-in to the build system. Instead of kconfig mazes and ifdefs, we > use weak symbols, so that an arch version can override the generic > version. Then we include the generic version in lib-y, so that it can be > removed from the image if the arch version doesn't fallback to it (as is > the case on arm though not x86). The result should be a bit simpler and > smaller than the code it replaces. > > Discussed-with: Ard Biesheuvel <ardb@xxxxxxxxxx> > Cc: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx> > --- > Hi Masahiro, > > This is a commit I'm working on as part of a change to the RNG, which > got broken out into something standalone because it wound up being a bit > more involved than originally conceived. With Ard's help, this is using > weak symbols with the generic code in lib-y, but the only way we figured > to actually include the lib.a file was via this unseemly > KBUILD_VMLINUX_LIBS line below, which doesn't seem very okay. I tried > adding `libs-y += lib/crypto/` to lib/Makefile, but it seemed like the > build system ignored it. I figure there's probably a right way to do > this, so thought I should send you this RFC to look at first. If lib-y ignores (drops) an object file (usually because it is not used), the usual way to force it to be included is to add it to obj-y instead of lib-y (see many examples in lib/Makefile). However, this may cause problems with weak symbols. I don't recall it being used in that scenario. > Alternatively, if the KBUILD_VMLINUX_LIBS trick is somehow okay, that'd > be useful to know too. > > Thanks, > Jason -- ~Randy
