From: Sam Ravnborg <sam@ravnborg.org>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: Arjan van de Ven <arjanv@redhat.com>,
Sam Ravnborg <sam@ravnborg.org>,
lkml <linux-kernel@vger.kernel.org>,
"kbuild-devel@lists.sourceforge.net"
<kbuild-devel@lists.sourceforge.net>
Subject: Re: External kernel modules, second try
Date: Sun, 7 Mar 2004 19:33:45 +0100 [thread overview]
Message-ID: <20040307183345.GA2002@mars.ravnborg.org> (raw)
In-Reply-To: <1078677922.3615.47.camel@e136.suse.de>
On Sun, Mar 07, 2004 at 05:45:22PM +0100, Andreas Gruenbacher wrote:
> All in all, in the end I changed my mind. I now think that it's better
> to build modules against a clean kernel source tree that additionally
> has the modversions file copied in. This already works when using O=.
> With the SUBDIRS= approach, the kernel source tree must include a few
> compiled files (scripts/ stuff), and it cannot be read-only.
>
> I'm still undecided whether it makes sense to disallow the SUBDIRS=
> approach completely and only allow building with O=. (Note that this
> doesn't change the modversion dump file argument.) When building with
> SUBDIRS=, you ideally want a (read-only) kernel source tree that can
> adapt to different configurations (e.g., by doing like this:
>
> make -C $KERNEL_SOURCE modules SUBDIRS=$PWD FLAVOR=bigsmp
This is already possible.
You can do:
make -C $KERNEL_SRC SUBDIRS=$PWD O=output-dir modules
or with my proposed syntax:
make -C $KERNEL_SRC M=$PWD O=output-dir
The files relevant for the module will be located in the $PWD dir, since
they use absolute paths.
>
> ), the default being the running kernel.
I do not want to have potentially distro specific solutions.
So it depends if we can find a solution that most will agree on.
Sam
next prev parent reply other threads:[~2004-03-07 18:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-07 0:44 External kernel modules, second try Andreas Gruenbacher
2004-03-07 12:53 ` Sam Ravnborg
2004-03-07 13:03 ` Arjan van de Ven
2004-03-07 13:46 ` Andreas Gruenbacher
2004-03-07 14:01 ` Arjan van de Ven
2004-03-07 14:26 ` Andreas Gruenbacher
2004-03-07 15:09 ` GPL 3 mark kandianis
2004-03-07 15:14 ` Måns Rullgård
2004-03-07 16:43 ` John Bradford
2004-03-07 16:05 ` External kernel modules, second try Sam Ravnborg
2004-03-07 16:08 ` Arjan van de Ven
2004-03-07 16:45 ` Andreas Gruenbacher
2004-03-07 16:49 ` Arjan van de Ven
2004-03-07 18:33 ` Sam Ravnborg [this message]
2004-03-07 13:32 ` Andreas Gruenbacher
2004-03-07 15:09 ` Sergey Vlasov
2004-03-07 18:37 ` Sam Ravnborg
2004-03-07 16:18 ` Sam Ravnborg
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=20040307183345.GA2002@mars.ravnborg.org \
--to=sam@ravnborg.org \
--cc=agruen@suse.de \
--cc=arjanv@redhat.com \
--cc=kbuild-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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.