From: Sam Ravnborg <sam@ravnborg.org>
To: Christian Zander <zander@minion.de>
Cc: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>,
Mark Fasheh <mark.fasheh@oracle.com>,
Thomas Schlichter <schlicht@uni-mannheim.de>,
"Randy.Dunlap" <rddunlap@osdl.org>,
Sam Ravnborg <sam@ravnborg.org>,
LKML <linux-kernel@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: no version magic, tainting kernel.
Date: Sun, 26 Jan 2003 22:29:50 +0100 [thread overview]
Message-ID: <20030126212950.GA6334@mars.ravnborg.org> (raw)
In-Reply-To: <20030126220842.GB394@kugai>
On Sun, Jan 26, 2003 at 11:08:42PM +0100, Christian Zander wrote:
> External projects may not want to use the build flags unchanged, they
> may have good reasons for using their own. It seems sensible to make
> the kernel build system available to those who wish to use it, but it
> should be optional rather than mandatory. In this specific case, there
> is no technical reason to require the use of kbuild.
Judging on the number of people that got bid by the mach- include changes,
I conclude that we better ask people to use kbuild.
The whole issues boils down to the following options:
1) The "kernel-headers" package shall be extended to include the vital
part of kbuild
2) To develop modules you need the full kernel src
3) Do-it-yourself makefiles
Can we agree on that - and take the discussion from there?
In 1) and 2) you have total freedom to change options etc.
Several architectures filter out generic options they dislike.
Adding extra options is supported by kbuild (EXTRA_CFLAGS).
In 3) you have all possibilities to screw up things. You would probarly
argue you have full flexibility.
But then I wonder what kind of flexibility you need for your module, that
is not needed for all the modules included in the kernel?
To take your argument and turn it around:
What technical reasons are there to avoid kbuild?
Please realise that you will be hit by changes in include paths,
compiler options etc.
That is visible in the number of mails seen on lkml the last couple of
months.
Sam
next prev parent reply other threads:[~2003-01-26 21:20 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-23 13:59 no version magic, tainting kernel Thomas Schlichter
2003-01-23 16:29 ` Randy.Dunlap
2003-01-23 16:52 ` Sam Ravnborg
2003-01-23 17:32 ` Thomas Schlichter
2003-01-23 18:22 ` Sam Ravnborg
2003-01-23 19:35 ` Mark Fasheh
2003-01-26 13:29 ` Christian Zander
2003-01-26 13:33 ` Keith Owens
2003-01-26 18:02 ` Kai Germaschewski
2003-01-26 17:51 ` Kai Germaschewski
2003-01-26 21:57 ` Christian Zander
2003-01-26 21:46 ` Kai Germaschewski
2003-01-26 23:12 ` Christian Zander
2003-01-26 22:55 ` David Woodhouse
2003-01-27 0:07 ` Christian Zander
2003-01-26 23:16 ` David Woodhouse
2003-01-27 0:24 ` Christian Zander
2003-01-27 16:25 ` Kai Germaschewski
2003-01-27 16:29 ` David Woodhouse
2003-01-27 16:39 ` Kai Germaschewski
2003-01-27 6:17 ` Petr Vandrovec
2003-01-27 9:02 ` David Woodhouse
2003-01-27 9:24 ` Petr Vandrovec
2003-01-27 17:59 ` Joel Becker
2003-01-27 18:31 ` Kai Germaschewski
2003-01-27 22:15 ` Joel Becker
2003-01-27 23:08 ` Kai Germaschewski
2003-01-27 23:37 ` Joel Becker
2003-01-28 15:43 ` David Woodhouse
2003-01-28 17:03 ` Joel Becker
2003-01-26 22:23 ` Christian Zander
2003-01-26 17:43 ` Kai Germaschewski
2003-01-26 22:08 ` Christian Zander
2003-01-26 21:29 ` Sam Ravnborg [this message]
2003-01-26 23:03 ` Christian Zander
2003-01-26 21:40 ` David Woodhouse
2003-01-26 23:28 ` Christian Zander
2003-01-26 22:46 ` David Woodhouse
2003-01-26 23:56 ` Christian Zander
2003-01-26 23:04 ` David Woodhouse
2003-01-28 1:58 ` Rusty Russell
2003-01-28 19:10 ` Mark Fasheh
2003-01-28 19:17 ` Kai Germaschewski
2003-01-27 18:52 ` Jerry Cooperstein
2003-01-27 19:12 ` Sam Ravnborg
2003-01-27 19:35 ` Jerry Cooperstein
2003-01-27 19:54 ` Gerd Knorr
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=20030126212950.GA6334@mars.ravnborg.org \
--to=sam@ravnborg.org \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.fasheh@oracle.com \
--cc=rddunlap@osdl.org \
--cc=rusty@rustcorp.com.au \
--cc=schlicht@uni-mannheim.de \
--cc=zander@minion.de \
/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