Hello list, I am unhappy with the direction the 2.6 kernel builds have taken. Very much like Micro$loth DDKs we (linux users) are being forced to build modules by plugging into a framework that doesn't respect the fine aspects of dependency generation and analysis. Two problems I've identified 1. module builds are forcing me to use a particular make program (gnu make) Well, what if someone uses a different tool to express the DAG (dep. graph)? 2. gnu make is a somewhat dated program and can't do profound dependency generation and analysis like some newer tools. All it can do is produce .d from .c with the -MM option using an idiom like this -include f1.d f2.d %.d: %.c $(CC) -MM <whatever> But that's not good enough for 2 reasons. a) version rollback that causes timestamp rollback in time does NOT trigger regeneration of dependencies (e.g. clearcase based builds). b) dependencies on order of things can't be expressed in gnu make, for example -Iinc1 -Iinc2 causes different results from -Iinc2 -Iinc1 if you have 2 different header files that have the same name in both directories. Same goes for "ld -r -o mod.o f1.o f2.o" vs "ld -r -o mod.o f2.o f1.o" if order mattered (which it doesn't in this case). Bottom line - there exist free tools that are vastly superior to gnu make, one such example is omake, and I don't want you to force me to switch to inferior dependency analysis with gnu make. My suggestion how to solve this problem is the following. Instead of gnumake -C /lib/modules/`uname -r`/build M=`pwd` modules it's better to be able to do gnumake -C /lib/modules/`uname -r`/build M=`pwd` MYMAKE=mymake modules and then inside your gnu Makefile you'd call mymake like so chdir $(M) mymake MODFLAGS="whatever modflags" INCFLAGS="whatever incflags" modules and pass on whatever flags are necessary. You can set MYMAKE to gmake if unspecified thus ...
Patches accepted. J -
The build system for the kernel (kbuild) have a number of goals to fulfill. The most important ones was to be reliable and easy to use. The easy to use part has mandated a very simple syntax in the more than 1000 Makefiles in the kernel - and kbuild has been extended support external modules too. With the 2.6 kernel it is mandatory to use kbuild for external modules for a number of reasons: -> compiler and to some extent linker options now much more rely on the actual configuration. So a gcc commandline for a module may look different depending on the actual configuration. -> The module support code is well integrated with kbuildand when it changes (and it does so now and then) then all external modules do not need to apply the same changes. -> Same syntax for in-kernel and external modules makes it simpler. The infrastructure used to achieve the goals of simplicity and reliability rely and a great deal of the features supported by GNU make and that clearmake and others does not support. So faced with the two possibilities which is 1) to rely on less GNU make features and support other make tools 2) full feature set but rely on GNU make the choice was easy. The point here is that even if kbuild was changed slightly to allow a user to specify an alternative make program when building external modules that would not work because kbuild rely too much on the GNU make features. You can try this today. MAKE=/usr/bin/my_make_utility make M=`pwd` And see how it fails due to use of GNU make features. Sam -
see kbuild implementation to know how preparation done before GNU make I doubt this suggestion. I think, as GNU make is current good and supported stat()/clone()/exec(cc) tool, one must provide gnu-make-with-kbuild-tools independent configuration and dependency building process. And having multiple-pluging for dep-build and cc-build If you can't follow LKML yet, please find little-nice kbuild ML in the MAINTAINERS file. And IMHO, this (cc me) already must be in some kind of "how to ask questions in the smart way" or Newbie's Netiquette, as bed See you later? -- -o--=O`C #oo'L O <___=E M -
| > I am unhappy with the direction the 2.6 kernel builds have taken. | > Very much like Micro$loth DDKs we (linux users) are being forced to | > build modules by plugging into a framework that doesn't respect the fine | > aspects of dependency generation and analysis. | | Ideas in form of patches are accepted, I think that one of the bigger firms that support linux, like IBM, Redhat, Suse, ought to hire a contractor to redesign kbuild and get the linux community involved. | > Two problems I've identified | > 1. module builds are forcing me to use a particular make program (gnu | > make) | > Well, what if someone uses a different tool to express the DAG (dep. | > graph)? | | with multiple stat()/clone()/exec(cc), i.e. `make' replacement, tools | support, | | > 2. gnu make is a somewhat dated program and can't do profound dependency | > generation and analysis like some newer tools. All it can do is | > produce | > .d from .c with the -MM option using an idiom like this | > -include f1.d f2.d | > %.d: %.c | > $(CC) -MM <whatever> | | AFAIK GNU make have nothing to do with any kind of decencies, On the contrary. An attempt is made by gnu make to compute dependencies. As I pointed out earlier, it doesn't do a very good job of it. | > But that's not good enough for 2 reasons. | > a) version rollback that causes timestamp rollback in time does NOT | > trigger regeneration of dependencies (e.g. clearcase based | > builds). | > b) dependencies on order of things can't be expressed in gnu make, | > for example -Iinc1 -Iinc2 causes different results from -Iinc2 -Iinc1 | > if you have 2 different header files that have the same name in | > both directories. Same goes for "ld -r -o mod.o f1.o f2.o" vs | > "ld -r -o mod.o f2.o f1.o" if order mattered (which it doesn't in | > this case). | | see kbuild implementation to know how preparation done before GNU make | is ...
The fact that they did not so far means they are fine with Kbuild. Jan -- -
Not at all. I think you'll need to convince/show us that there is a real problem that cannot be solved by current Kbuild. E.g., instead of building 2 drivers from the same Makefile where you cannot reduce granularity of EXTRA_FLAGS, can it be done with 2 makefiles? and if not, why not? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -
CFLAGS_f1.o := -DMASK=0x123 CFLAGS_file1.o := -DMASK=0x123 CFLAGS_f2.o := -DMASK=0x456 Fixed your makefile for you. See Documentation/kbuild/modules. ..Stu -
Obviously kbuild can be better and if someone are committed to put in a month work on kbuild we would see improvements. As the kbuild maintainer I am the first to agree on this. kbuild has taken the direction where make is used not only as a simple DAG tool - be some of the other facilities has been utilised to support some of the following goals: -> Very simple Kbuild files for the simple cases - and the simple cases counts for more than 95% of the Kbuild files in the kernel. -> One kbuild file pr. directory for simplicity -> rebuild in case prerequisites OR referred CONFIG symbol changes -> rebuild if commandline arguments changes (but not order of these) -> revert back to known Makefile syntax for complex scenarios -> make kbuild infrastructure avialable for external modules to make build of these more releiable (pick up correct CONFIG) -> Last but not least - relaible. These golas are fulfilled by kbuild today. You want to add another few goals: -> Do not rely on GNU Make If you try to use Kbuild in a way it is not designed to be used then you will obviously face issues. One Kbuild file pr. directory. Use a top-level Kbuild file to specify both sub-directory Kbuild files. This structure works well for the kernel - so it should work well for your module too? I am open for specific improvement proposals - but not for 'redo from scratch proposals'. Sam -