All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.