mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Olaf Titz <olaf@bigred.inka.de>
To: linux-kernel@vger.kernel.org
Subject: Re: ANN: LKMB (Linux Kernel Module Builder) version 0.1.16
Date: Sun, 19 Jan 2003 13:55:11 +0100	[thread overview]
Message-ID: <E18aEyl-0006O0-00@bigred.inka.de> (raw)
In-Reply-To: <20030119001256.GA11575@compsoc.man.ac.uk>

> > Compiling modules is one of the things which always have been among
> > the most broken things in the kernel build systems, can this please be
> > fixed and properly documented?
>   ^^^^^
>
> Some actual bug reports would be good.

The general bug is that there is incomplete infrastructure for
building modules outside of the kernel. You see the problem when
looking at the CIPE configure scripts, or the ALSA configure scripts.
Up to kernel version 2.4, it takes considerable effort to find out
just what compiler options to use. This is information which belongs
in some easily accessed location.

The desirable situation for module developers would be that a kernel
tree after configure run contains a Makefile (or equivalent) with all
necessary definitions which can be called from an outside module
source tree and just DTRT. The 2.5 kbuild stuff is close, but not
complete.

It is a bug that Documentation/modules.txt is so outdated that it
contains little useful information any more. It is a bug that
Documentation/kbuild/makefiles.txt is at least a bit outdated.

It is a bug that the build process outside of the kernel tree changes
files inside the kernel tree when MODVERSIONS is enabled. (At least
this was the case last time I checked.) This means the kernel tree
can't be mounted read-only, or at least you would have to do dirty
tricks with symlinks.

It is a bug that the current Makefile can't compile modules in an
object directory different from the source directory. This means the
module source tree can't be mounted read-only (again, without
resorting to symlinks).

It is also a bug that parts of the development infrastructure are
installed in /lib/modules/<version> and it's somewhat documented that
compiling modules needs this /lib/modules/<version> stuff. That may be
true for the ideal, simplified Red Hat world but in reality the
machine and running OS version of the development machine is likely
different from the box it will run on. Mixing development environment
and install target only causes confusion.

I don't know if real cross-compilation (i.e. for a different
architecture than the compiler runs on) of modules is possible
yet. If not, that's a bug too.[1]

Olaf

[1] Okay, on this count I'm guilty too with CIPE (just trying to sort
that out...)


  reply	other threads:[~2003-01-19 12:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-17 12:31 Shlomi Fish
2003-01-17 12:37 ` Shlomi Fish
2003-01-17 13:12 ` David Woodhouse
2003-01-17 17:00   ` Shlomi Fish
2003-01-17 18:00     ` Sam Ravnborg
2003-01-17 18:28       ` Shlomi Fish
2003-01-18 22:37     ` Olaf Titz
2003-01-18 22:55       ` Arjan van de Ven
2003-01-20 20:03         ` Olaf Titz
2003-01-20 21:39           ` Arjan van de Ven
2003-01-21 21:16             ` Olaf Titz
2003-01-21 21:30               ` David Lang
2003-01-21 21:46               ` Sam Ravnborg
2003-01-22 11:21               ` David Woodhouse
2003-01-22 11:18             ` David Woodhouse
2003-01-22 19:16               ` Bill Davidsen
2003-01-22 22:17                 ` David Woodhouse
2003-01-19  0:12       ` John Levon
2003-01-19 12:55         ` Olaf Titz [this message]
2003-01-19 13:06           ` Arjan van de Ven
2003-01-20 20:16             ` Olaf Titz
2003-01-19 18:22           ` Sam Ravnborg
2003-01-20 20:14             ` Olaf Titz
2003-01-20 20:46               ` Sam Ravnborg
2003-01-19 21:17 Paul Zimmerman
2003-01-19 21:24 Paul Zimmerman
2003-01-23  0:20 Hal Duston

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=E18aEyl-0006O0-00@bigred.inka.de \
    --to=olaf@bigred.inka.de \
    --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 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®