linux-kernel - 2.6 Makefile replacement for VPATH

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:	Thu, 25 Jun 2009 09:39:17 -0700
From:	Kyle Hubert <khubert@...y.com>
To:	linux-kernel@...r.kernel.org
Cc:	Igor Gorodetsky <igorodet@...y.com>
Subject: 2.6 Makefile replacement for VPATH

Hi. I'm requesting information about how to handle a VPATH situation
for drivers in the 2.6 build, with the corresponding solution that we
have.

I refer to VPATH with regards to the situation where you can have
multiple Makefiles target the same source file to build different
objects. In particular, we are using the same source file recompiled
with different options to be able to support different devices.

This is where VPATH can help in the GNU Makefile tradition. Yet, the
2.6 build system has multiple stages to build driver modules, and as
such the VPATH variable is not carried forward. How do other people
handle this?

If you use an obj-m that refers via relative directories to the source
file, ie: "../src", then the two resulting object files have the same
name and the last compiled one will be listed in
.tmp_versions/drv.mod. This will be the only one linked into an
drv.ko.

If you use a multi-object, ie: drv-objs, then you can split the two
drivers into two different names. Each multi-object's parts are
compiled and linked into the multi-object's .o during the compilation
stage, and two .mod files will be created. Thus, two .kos will be
linked during the final stage. This appears to be a solution. However,
during the compilation stage, the two multi-objects will recompile the
original "../src/src.o" intermediary object. This affects the date of
the intermediary .o, and each subsequent execution of the Make command
will consider it a candidate for recompile, and the two drivers will
be rebuilt, regardless of any source code changes.

How do others handle this? Do they just move their driver outside of
the kernel Makefiles so they can iterate through the two builds via
traditional Make routines?

Thank you,
-Kyle Hubert
--
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/