Linux filesystem development
 help / color / mirror / Atom feed
From: Jan Hudec <bulb@ucw.cz>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: buffer cache
Date: Sun, 14 Sep 2003 13:19:00 +0200	[thread overview]
Message-ID: <20030914111859.GH31719@vagabond> (raw)
In-Reply-To: <1063535842.11431.44.camel@imladris.demon.co.uk>

On Sun, Sep 14, 2003 at 11:37:22 +0100, David Woodhouse wrote:
> Please don't drop me from the recipients when replying; it's very rude.
> 
> On Sun, 2003-09-14 at 12:03 +0200, Jan Hudec wrote:
> > > Probably as a result of hacking up his own broken makefiles instead of 
> > > 	make -C $KERNELDIR SUBDIRS=`pwd` modules
> > 
> > Well, I wrote a module to compile off-tree. The correct command to link
> > a module is:
> > ld -r -o <modname>.o <objects...>
> 
> No, that's not always correct. It's completely wrong for 2.6, of course
> -- and even for 2.4, if building modules for a 64-bit kernel, you may
> find your userspace is 32-bit by default and you need something like
> -melf64_sparc on the linker command line. The kernel makefiles get this
> right. Use them.
> 
> The kernel is also free to screw with its own internal ABI all it likes
> -- with cflags affecting global register usage, etc. You must do as it
> does in the kernel you happen to be building -- which basically means

Which I basicaly do becasue I ask kernel to give me the flags it uses.

> you must use the kernel build system.

That's what the script target is for.

> The correct way to build modules out of the kernel tree is to use the
> kernel makefiles and override SUBDIRS to point at your own directory;
> it's been that way since 2.0 if not earlier.

Well... I can't imagine compiling a project with various objects spead
all over the place (I have a driver, that has various pieces common with
various other programs) using the kernel build system. So it reduces back
to geting right flags from it.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

  reply	other threads:[~2003-09-14 11:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-13  8:51 buffer cache vadiraj c s
2003-09-13 10:27 ` Jan Hudec
2003-09-13 13:14   ` Matthew Wilcox
2003-09-13 17:25   ` Bryan Henderson
2003-09-13 17:28     ` Jan Hudec
2003-09-14  9:32       ` David Woodhouse
2003-09-14 10:03         ` Jan Hudec
2003-09-14 10:37           ` David Woodhouse
2003-09-14 11:19             ` Jan Hudec [this message]
2003-09-15 16:18             ` Bryan Henderson
2003-09-15 16:35               ` Greg KH
2003-09-15 22:41                 ` Bryan Henderson
2003-09-16  5:13                   ` David Woodhouse
2003-09-16 10:18                     ` Jamie Lokier
2003-09-16 12:16                       ` David Woodhouse

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=20030914111859.GH31719@vagabond \
    --to=bulb@ucw.cz \
    --cc=dwmw2@infradead.org \
    --cc=linux-fsdevel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox