linux-kernel - Re: Mutli-directory module Makefiles

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:   Thu, 25 Jan 2018 22:08:34 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Jakub Kicinski <kubakici@...pl>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Mutli-directory module Makefiles

2018-01-23 6:46 GMT+09:00 Jakub Kicinski <kubakici@...pl>:
> Hi!
>
> in drivers/net/ethernet/netronome/nfp there is a module which is built
> from C sources in 4 directories.  What is the best way to handle that?
>
> Currently we just add all the objects in one Makefile:
>
> nfp-objs := \
>             nfpcore/nfp6000_pcie.o \
>             nfpcore/nfp_cppcore.o \
> etc.


I recommend you to refactor the Makefile,
adding Makefiles into nfpcore, nic, flower, bpf sub-directories.


Also, ifeq is ugly,
can you rewrite like follows?


nfp-$(CONFIG_NFP_APP_FLOWER)    += flower/
nfp-$(CONFIG_BPF_SYSCALL)       += bpf/
nfp-$(CONFIG_NFP_DEBUG)         += nfp_net_debugfs.o





> However, this makes it impossible to build a single object in subdirs:
>
> $ make drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.o
> scripts/Makefile.build:45: drivers/net/ethernet/netronome/nfp/nfpcore/Makefile: No such file or directory
> make[2]: *** No rule to make target 'drivers/net/ethernet/netronome/nfp/nfpcore/Makefile'. Stop.
>
> Documentation/kbuild/modules.txt also contains an unclear remark that
> this is not recommended (or is it about the use of $(src)?):
>
> --- 4.3 Several Subdirectories
>         ...
>         To build the module complex.ko, we then need the following
>         kbuild file:
>
>                 --> filename: Kbuild
>                 obj-m := complex.o
>                 complex-y := src/complex_main.o
>                 complex-y += src/hal/hardwareif.o
>
>                 ccflags-y := -I$(src)/include
>                 ccflags-y += -I$(src)/src/hal/include
>
>         As you can see, kbuild knows how to handle object files located
>         in other directories. The trick is to specify the directory
>         relative to the kbuild file's location. **That being said, this
>         is NOT recommended practice.**
>
> Making the include optional would work:
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> @@ -42,7 +42,7 @@ save-cflags := $(CFLAGS)
>  # The filename Kbuild has precedence over Makefile
>  kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src))
>  kbuild-file := $(if $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
> -include $(kbuild-file)
> +-include $(kbuild-file)
>
>  # If the save-* variables changed error out
>  ifeq ($(KBUILD_NOPEDANTIC),)
>
> Or we could create empty Makefiles in subdirectories...  Is there a
> better way of handling this?  Which is preferred?



-- 
Best Regards
Masahiro Yamada