From: Kedar Sovani <kedars@gmail.com>
To: Sam Ravnborg <sam@ravnborg.org>, linux-kernel@vger.kernel.org
Subject: Re: Kbuild trick
Date: Sat, 21 May 2005 16:29:35 +0530 [thread overview]
Message-ID: <5edf7fc905052103593ea75abf@mail.gmail.com> (raw)
In-Reply-To: <20050520193706.GA8225@mars.ravnborg.org>
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@ravnborg.org> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2005-05-21 10:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-17 21:46 sparse error: unable to open 'stdarg.h' Timur Tabi
2005-05-17 20:11 ` Christopher Li
2005-05-18 14:08 ` Timur Tabi
2005-05-18 12:38 ` Christopher Li
2005-05-18 15:51 ` Timur Tabi
2005-05-18 13:24 ` Christopher Li
2005-05-18 16:45 ` Timur Tabi
2005-05-18 18:22 ` Sam Ravnborg
2005-05-18 18:23 ` Timur Tabi
2005-05-20 19:37 ` Kbuild trick Sam Ravnborg
2005-05-20 23:43 ` Joel Becker
2005-05-21 5:12 ` Sam Ravnborg
2005-05-21 5:48 ` randy_dunlap
2005-05-21 20:41 ` Joel Becker
2005-05-21 10:59 ` Kedar Sovani [this message]
2005-05-22 7:28 ` Sam Ravnborg
2005-05-17 22:39 ` sparse error: unable to open 'stdarg.h' Timur Tabi
2005-05-18 18:22 ` Sam Ravnborg
2005-05-18 22:14 ` Timur Tabi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5edf7fc905052103593ea75abf@mail.gmail.com \
--to=kedars@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome