Re: Kbuild trick

From: Kedar Sovani
Date: Sat May 21 2005 - 06:01:42 EST


One of the question that I haven't yet managed to solve properly is
how do we manage kernel modules which have its C files in multiple
underlying directories.

say :
/src/Makefile
/src/main.c
/src/module1/Makefile
/src/module1/module1.c
/src/module1/module_stuff.c

And the 3 C files should be built into a single module at the top level.
I tried something like this in the top level Makefile, but it does not work.

obj-m += mymodule.o
main-objs=main.o module1/

I could use,
main-objs=main.o module1/module1.o module1/module_stuff.o

But I don't think that is a good idea. I looked at
Documentation/kbuild/, but no luck.

Any suggestions?

Thanks,
Kedar.

On 5/21/05, Sam Ravnborg <sam@xxxxxxxxxxxx> wrote:
>
> Hi Timur.
> Some tricks/hints.
>
> For both kernel 2.4 and 2.6 you can split up your makefile like this:
> makefile <= all the external modules specific part
> Makefile <= the kbuild specific part
>
> Recent 2.6 kernels looks for a fine named Kbuild before Makefile
> so you can use the file Kbuild for a 2.6 compatible kbuild file, and
> Makefile for a 2.4 compatible kbuild file.
>
>
> > # Only if the Config.mk file exists will the next line include it.
> > # (Inside Ammasso, the needed information is derived differently.)
> > ifneq (${wildcard ${SOFTWARE}/../Config.mk},)
> > include ${SOFTWARE}/../Config.mk
> > endif
> -include does the same
>
>
> > # Determine the kernel version. We only really care about 2.4 vs 2.6, so
> > this
> > # simple code will work with version.h files that have multiple
> > UTS_RELEASEs.
>
> In the kbuild part of the file you can check for KERNELRELEASE.
> And a lot of what is below ought to be in the kbuild part of the file.
>
>
> > # If O= is specified on the make command line, then you must have write
> > # access to KERNEL_SOURCE, otherwise the build will fail. So we only pass
> > # O= if it is specified in Config.mk.
> O= does not require write access to KERNEL_SOURCE. Thats one one the
> main concpets. KERNEL_SOURCE may be owned by whoever.
>
>
> > # Define DO_MUNMAP_API_CHANGE if this kernel uses the version of do_unmap()
> > # that has four parameters instead of just three.
> >
> > ifneq (${shell grep -c -m 1 do_munmap.*acct
> > ${KERNEL_SOURCE}/include/linux/mm.h}, 0)
> > EXTRA_CFLAGS += -DDO_MUNMAP_API_CHANGE
> > endif
>
> A macro can simplify this:
>
> feature = $(if $(shell grep -m 1 $(1) $(srctree)/include/$(2)), $(3))
>
> Usage:
> EXTRA_CFLAGS += $(call feature, do_munmap.*acct, linux/mm.h, -DDO_MUNMAP_API_CHANGE)
> EXTRA_CFLAGS += $(call feature, remap_page_range.*vm_area_struct, \
> linux/mm.h, -DREMAP_API_CHANGE)
>
> etc..
>
> >
> > ifneq (${wildcard /proc/ksyms},)
> > SYMFILE = /proc/ksyms
> > else
> > ifneq (${wildcard /proc/kallsyms},)
> > SYMFILE = /proc/kallsyms
> > endif
> > endif
> This looks wrong. Either you shall check kernel source or running
> kernel.
> But mixing it like this is to call for troubles.
>
>
>
> > # Source files
> >
> > CFILES = \
> > devnet.c \
> > ccilnet.c \
> > devccil.c \
> > devccil_adapter.c \
> > devccil_rnic.c \
> > devccil_mem.c \
> > devccil_vq.c \
> > devccil_eh.c \
> > devccil_cq.c \
> > devccil_mq.c \
> > devccil_pd.c \
> > devccil_srq.c \
> > devccil_qp.c \
> > devccil_mm.c \
> > devccil_ep.c \
> > devccil_wrappers.c \
> > devccil_ae.c \
> > devccil_logging.c
> >
> > COMMON_CFILES = \
> > cc_cq_common.c \
> > cc_mq_common.c \
> > cc_qp_common.c
> >
> In kbuild files the usual pattern is to specify the .o files not the
> source files. So for anyone familiar with kbuild files this looks wrong.
> And be explicit. No reason to hide directories behind the addprefix
> macro below. This is not an obscufating contest.
> > # Fix the paths for the common .c files
> > CFILES += $(addprefix ../../common/, ${COMMON_CFILES})
>
> > # Generate an assembly listing for each file
> >
> > EXTRA_CFLAGS += -Wa,-aldh=$*.lst
> If needed you can use: make cc_mp_common.lst to let kbuild generate
> them. Dunno if it works for external modules btw.
>
> >
> >
> > # Linker parameters
> >
> > obj-m := ccil.o
> >
> > ccil-objs := ${CFILES:.c=.o}
> >
> > syscall:
> > @echo ${SYSCALL_METHOD}
>
> As you have noticed in another mail - this does not work.
> An untested approch would be to use:
> .PHONY: syscall
> $(obj)/ccil.o: syscall
>
> Sam
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/