linux-kernel - Re: module builds need improvement / top Makefile not good enough

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 Mar 2007 08:47:27 -0800
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	"FN" <zzzz444@....net>
Cc:	"Oleg Verych" <olecom@...wer.upol.cz>, linux-kernel@...r.kernel.org
Subject: Re: module builds need improvement / top Makefile not good enough

On Mon, 05 Mar 2007 05:53:14 -0800 FN wrote:

> That's not for you to decide.
> Just pass down all variables that may be relevant to my module builds 
> and let me take it from there, for example
> chdir $(M)
> $(MYMAKE) CC="..." LD="..." AR="..." CFLAGS="..." MODFLAGS="..."
> INCL="..."
>           WHATHAVE_YOU="whatever"  modules
> 
> Currently I face the following situation -- I try to build 2 drivers
> from the same Makefile
> -----------
> CWD := $(shell pwd)
> obj-m := driver1.o driver2.o
> driver1-y := d1/d2/d3/f1.o d1/d2/f2.o
> driver2-y := d1/d5/file1.o d1/d6/file2.o
> # ill conceived kbuild framework doesn't allow me to reduce granularity
> # of EXTRA_FLAGS
> $(addprefix $(CWD)/,d1/d2/d3/f1.o d1/d5/file1.o: EXTRA_CFLAGS :=
> -DMASK=0x123
> $(addprefix $(CWD)/,d1/d2/f2.o d1/d6/file2.o) : EXTRA_CFLAGS :=
> -DMASK=0x456
> # fine grained scope for EXTRA_CFLAGS (supported by gnu make) doesn't
> work
> ----------
> There are 2 problems here
> 1) kbuild is forcing me to declare EXTRA_CFLAGS in global scope and 
>    I can't build my drivers properly because the MASKs are incompatible. 
> 2) assuming that modules are buildable, if I do "make clean" there is
> leftover
>    junk in all of these places d1/d2/d3 d1/d5 d1/d2 d1/d6.
>    There is a danger associated with that junk (or state), dependency
>    generation
>    may be broken which it provably is in some cases (remember -Iinc_dir1
>    -Iinc_dir2
>    vs. -Iinc_dir2 -Iinc_dir1 example I gave earlier) and I can't rely on
>    it.
>    So then I need to be able to clean all, but the "clean:" target can't
>    clean
>    inexpensively in multiple directorie, i.e. must do recursive
>    traversal to clean.
> 
> No, you can't send me off to some little kbuild mailing list.
> I've raised concerns that probably affects hundreds of module builders.
> kbuild works well only in the simplest of build scenarios but doesn't
> scale and that's a deficiency that should be urgently addressed.
> The leadership of the linux kernel is going to have to make
> a decision and possibly hire a competent contractor to fix these
> problems.
> Are you guys perfectionists or what?

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 ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/