mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Petr Vandrovec <vandrove@vc.cvut.cz>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>,
	Christian Zander <zander@minion.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: Mon, 27 Jan 2003 01:24:54 -0800	[thread overview]
Message-ID: <20030127092454.GD21959@vana.vc.cvut.cz> (raw)
In-Reply-To: <12104.1043658131@passion.cambridge.redhat.com>

On Mon, Jan 27, 2003 at 09:02:11AM +0000, David Woodhouse wrote:
> 
> vandrove@vc.cvut.cz said:
> > From my exprience at VMware newsgroups distros have bad troubles even
> > with delivery of basic configured kernel headers matching to kernel
> > binaries they provide (it is not unusual that for example they go from
> > 1GB to 4GB kernel without make mrproper so kmap/kunmap do not have
> > proper versions attached :-( or they even sell headers and binaries
> > with different configs).
> 
> But you _need_ the config. Even with your own makefiles, how are you going
> to get it right for all new kernels that $CRAPDISTRO ships in a broken form, 
> if you don't have the configs?

Yes, but currently you need only 3 files: autoconf.h, version.h, and, eventually
.config, as other headers are read-only and nobody managed to get them
wrong (yet).

When using kernel Makefiles there are at least two more files (main and arch Makefile), 
of which main Makefile is known to be modified by vendors to get their cloneconfig
working: they define additional rules and variables, and you may run into conflict.

> If distros ship broken crap which doesn't let you build modules, there's 
> really not a lot you can do except note their quality control for the 
> record and report it in their bug tracking system.
> 
> You are _always_ going to have problems with people shipping shite, or
> possibly even actively going our of their way to prevent out-of-tree modules
> building. It's fairly much an orthogonal problem though, isn't it?

Increasing number of files needed to build module also increases possibility
that something will go wrong :-( Ok, I'll modify modules build script to
use kernel's build system if /lib/modules/`uname -r`/build/Makefile exists,
and I'll see. 

BTW, is there any way how code outside of Makefile can detect what file was 
generated and where it was stored: whether vmmon.o or vmmon.ko? As it is now,
Makefile contains obj-y := vmmon.o, but you can end up with vmmon.ko... I
need it to make a note for uninstaller which files we added to the system
(and which we can overwrite without prompting on upgrade).

							Petr Vandrovec

  reply	other threads:[~2003-01-27  9:15 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-23 13:59 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 22:55                 ` David Woodhouse
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  0:07                   ` Christian Zander
2003-01-26 23:12                 ` Christian Zander
2003-01-27  6:17                 ` Petr Vandrovec
2003-01-27  9:02                 ` David Woodhouse
2003-01-27  9:24                   ` Petr Vandrovec [this message]
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 21:40           ` David Woodhouse
2003-01-26 22:46             ` David Woodhouse
2003-01-26 23:04               ` David Woodhouse
2003-01-26 23:56               ` Christian Zander
2003-01-26 23:28             ` Christian Zander
2003-01-26 22:08           ` Christian Zander
2003-01-26 21:29             ` Sam Ravnborg
2003-01-26 23:03               ` Christian Zander
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=20030127092454.GD21959@vana.vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=dwmw2@infradead.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=sam@ravnborg.org \
    --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

all inboxes | Powered by JetHome®