From: Martin Schlemmer <azarah@nosferatu.za.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Andreas Gruenbacher <agruen@suse.de>,
Linux Kernel Mailing Lists <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] kbuild updates
Date: Tue, 22 Jun 2004 00:33:18 +0200 [thread overview]
Message-ID: <1087857197.9639.39.camel@nosferatu.lan> (raw)
In-Reply-To: <20040621223108.GC2903@mars.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]
On Tue, 2004-06-22 at 00:31, Sam Ravnborg wrote:
> On Mon, Jun 21, 2004 at 01:51:43AM +0200, Andreas Gruenbacher wrote:
> > > But my original concern (that the only way to figure where the source
> > > are for the running kernel will be broken) is still valid.
> >
> > User-space stuff that needs access to kernel headers at build time is a
> > problem. But for those programs, depending on the running kernel instead of
> > simply looking in /usr/src/linux is an even bigger problem: What guarantees
> > that the first time the program is run, the kernel will still be the same? So
> > depending on the running kernel is definitely wrong. Depending
> > on /usr/src/linux is also wrong; ideally those programs should look
> > in /usr/include/{linux,asm}. Unfortunately these headers are not always
> > recent enough, and so recently added definitions may be missing.
>
> But Martin has a point here.
> How to figure out for example the number of arguments to remap_page_range.
> One could do some grepping in the mm.h file, or one could try to compile
> a minimal module calling this function.
> If we go for the simple version by grepping we need to figure out where
> to find the source. In the past this was simple - just follow the
> build symlink. But now kernels may be shipped with separate source
> and output directory exposing the weakness of this method.
> A much more reliable way is to build a simple module.
> If the module build succeeds that specific version
> of remap_page_range is OK.
>
> nvidia does something similar, but they take the false assumption
> that the running kernel is always the one being build for.
> So they call gcc direct.
>
> Other modules uses the grep method - which will fail when the kernel
> is build with separate output and source directories.
>
Might it help if there was some silly 'external module example toolkit'
or whatever, that shows how to figure out with kbuild how to determine
srcdir, figure out how many args remap_page_range takes, etc?
I will admit that most fixes I do to external modules is maybe not
really because their build systems is 'buggy' as such, but more because
of short-sightedness and lack of understanding kbuild. So above should
help.
Yeah, another project to maintain (in kernel if possible?). I am
willing to try at some of the tests, but my docs skills is no where
good ... :/
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-06-21 22:37 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-20 21:19 Sam Ravnborg
2004-06-20 21:21 ` [PATCH 1/2] kbuil: add deb-pkg target Sam Ravnborg
2004-06-20 21:22 ` [PATCH 0/2] kbuild updates Sam Ravnborg
2004-06-20 21:23 ` [PATCH 2/2] kbuild: Improved external module support Sam Ravnborg
2004-06-20 21:25 ` Arjan van de Ven
2004-06-20 21:31 ` Martin Schlemmer
2004-06-20 21:45 ` Sam Ravnborg
2004-06-20 21:38 ` Arjan van de Ven
2004-06-21 1:41 ` Petr Vandrovec
2004-06-21 9:01 ` Geert Uytterhoeven
2004-06-21 21:57 ` Sam Ravnborg
2004-06-20 21:30 ` [PATCH 0/2] kbuild updates Martin Schlemmer
2004-06-20 21:42 ` Arjan van de Ven
2004-06-20 21:52 ` Martin Schlemmer
2004-06-20 22:26 ` Andreas Gruenbacher
2004-06-20 22:39 ` Martin Schlemmer
2004-06-20 23:51 ` Andreas Gruenbacher
2004-06-21 22:31 ` Sam Ravnborg
2004-06-21 22:33 ` Martin Schlemmer [this message]
2004-06-21 22:50 ` Andreas Gruenbacher
2004-06-21 23:03 ` Sam Ravnborg
2004-06-20 22:03 ` Sam Ravnborg
2004-06-20 22:16 ` Martin Schlemmer
2004-06-20 22:26 ` Alistair John Strachan
2004-06-20 22:54 ` Martin Schlemmer
2004-06-21 22:46 ` Sam Ravnborg
2004-06-21 22:33 ` Sam Ravnborg
2004-06-21 22:29 ` Martin Schlemmer
2004-06-21 22:56 ` Andreas Gruenbacher
2004-06-20 22:18 ` Sam Ravnborg
2004-06-20 22:25 ` Martin Schlemmer
2004-06-21 22:48 ` Sam Ravnborg
2004-06-22 5:29 ` Jari Ruusu
2004-06-22 9:20 ` Andreas Gruenbacher
2004-06-22 18:23 ` Jari Ruusu
2004-06-22 18:44 ` Sam Ravnborg
2004-06-21 0:29 ` Hannu Savolainen
2004-06-21 1:27 ` Andreas Gruenbacher
2004-06-21 6:47 ` Arjan van de Ven
2004-06-21 8:02 ` Hannu Savolainen
[not found] <29hJN-3Jl-35@gated-at.bofh.it>
[not found] ` <29icN-42R-13@gated-at.bofh.it>
[not found] ` <29imu-4ad-31@gated-at.bofh.it>
[not found] ` <29iwc-4g7-27@gated-at.bofh.it>
2004-06-20 22:36 ` Pascal Schmidt
[not found] <539000871@toto.iv>
2004-06-22 1:39 ` Peter Chubb
2004-06-22 5:20 ` Sam Ravnborg
2004-06-22 8:36 ` Andreas Gruenbacher
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=1087857197.9639.39.camel@nosferatu.lan \
--to=azarah@nosferatu.za.org \
--cc=agruen@suse.de \
--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
all inboxes | Powered by JetHome®