linux-kernel - 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-next>] [day] [month] [year] [list]

Date:	Fri, 02 Mar 2007 09:14:22 -0800
From:	"FN" <zzzz444@....net>
To:	linux-kernel@...r.kernel.org
Subject: module builds need improvement / top Makefile not good enough

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 "MYMAKE ?= make"

That would make the callback into the user's build environment clean and
unbind it from gnu make.

Any replies, critique -- cc me, as I am not on this list.
-- 
  FN
  zzzz444@....net

-- 
http://www.fastmail.fm - And now for something completely different

-
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/