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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.