Reputation: 4994
I received the code from a proprietary Linux driver, which has the following structure:
common/common.c
moduleA/Makefile
moduleB/Makefile
The issue is that both moduleA and moduleB contain the statement moduleX-objs += ../common/common.o
. This is obviously racy, because when doing a multithread compilation two threads are reading/writing to the file common/common.o at the same time.
What is the clean way to solve this? Create a separate module common.ko?
What is the standard way to do such things with the kernel build system?
Upvotes: 5
Views: 229
Reputation: 5301
One way is building common.o prior building the modules by making common.o a prerequisite to the modules as both modules will consider common.o up to date, though there is still a race condition if building with --always-make since the modules won't check dates then. You can prevent it from happening by making common read-only during module build, failing any attempt of --always-make (assuming module makefile doesn't override permissions, which would be a weird thing to do). You do have to keep track of common contents used by modules though. Simple solution, best performance.
If you're feeling lazy you could make a bogus dependency between modules, e.g. all modules depend on moduleA. All modules will be built multithreaded, but the module all depend on won't be built at the same time as all the others. There is build performance degradation, true, but I'd expect it to be insignificant in most cases. For better performance you could experiment depending on modules with short build time or efficient internal multithreading. Simplest solution, good performance. Doesn't work with --always-make, resort to mentioned read-only strategy.
I've had some success building in separate source trees by copying modules and common to separate (build) folders and then build from there, but it complicates other things, and build performance could be degraded is modules contain lots of files. If you decide to do it, remember to copy as hard links: cp -lr
. Least simple solution (of which I mention). Notable is that modules may want to build common with different build flags, in which case you'd need separate .o-files for each module. If that is the case, this solution will work where the others won't.
Above are designs I've learnt over time. Not pretending it's state of the art or anything.
Upvotes: 2