All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Cc: 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 15:37:54 -0800	[thread overview]
Message-ID: <20030127233754.GR20972@ca-server1.us.oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0301271648360.18686-100000@chaos.physics.uiowa.edu>

On Mon, Jan 27, 2003 at 05:08:50PM -0600, Kai Germaschewski wrote:
> Well, I suppose arguing about that without a concrete example is kinda 
> pointless.

	Fair enough.
 
> You ignored the fact that I said you will be able to use separate
> src/objdir, which means you can have your source read-only.

	Yes.  That still doesn't change the fact that in 2.4 I need the
headers.  In 2.5 I need all 200MB of source + 60MB per different .config
of built tree.  And that's per user using that source.

> Yes, all you really need is the checksums. Then again, you also want a way 
> to verify a way that the checksums match the ABI as determined by the 
> current .config. I mean, just using the previously recorded checksums 
> without verifying is kinda pointless, they'll just always match and not 
> fulfill their function.

	You'd obviously have to have a way in the readonly /usr/src bits
to make sure that autoconf.h and the checksums match.  That would have
to be enforced (as Red Hat does now with their method).

> Yup, I now looked into what Redhat does. It's an obvious sign that there
> is work to be done, in particular making the build system work in a way
> that vendors don't need to kludge around it would definitely be nice.

	Maybe a way to track the differnet builds.  I'm not sure.  But
say you had a way of keeping multiple autoconf.h files in a tree.  If
the kernel sources could be smart enough to figure out the version.h and
modversions locations from that path, then you could have an external
module create a kbuild makefile for itself and run something like:

make KERN_CONF=/usr/src/linux-2.6.1/include/autoconf/build-smp/autoconf.h modules

where kbuild figures out from KERN_CONF that modversions stuff is in
autoconf/buid-smp/modversions/ and version.h is in
autoconf/build-smp/version.h, etc.  Something like that (I can beef with
this example, so no one tell me exactly why this specific example is bad
:-)

> which needs serious thinking and improvement. However, I think I need to
> finish the current work first, i.e. make sure the module versions actually
> work and then the separate obj / src dir stuff.

	Yes, I understand that there are priorities.
 
Joel

-- 

"The cynics are right nine times out of ten."  
        - H. L. Mencken

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

  reply	other threads:[~2003-01-27 23:28 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 [this message]
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
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=20030127233754.GR20972@ca-server1.us.oracle.com \
    --to=joel.becker@oracle.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.