Commit graph

4 commits

Author SHA1 Message Date
Andi Kleen
1bb4996bce [PATCH] Move compiler check for modules to ia64 only
Apparently IA64 needs it, but i386/x86-64 don't anymore
since gcc 2.95 support was dropped.  Nobody else on linux-arch
requested keeping it generically

Cc: tony.luck@intel.com
Cc: kaos@sgi.com

Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26 10:52:37 +02:00
Sam Ravnborg
63104eec23 kbuild: introduce utsrelease.h
include/linux/version.h contained both actual KERNEL version
and UTS_RELEASE that contains a subset from git SHA1 for when
kernel was compiled as part of a git repository.
This had the unfortunate side-effect that all files including version.h
would be recompiled when some git changes was made due to changes SHA1.
Split it out so we keep independent parts in separate files.

Also update checkversion.pl script to no longer check for UTS_RELEASE.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-07-03 23:30:54 +02:00
Paolo 'Blaisorblade' Giarrusso
5ac90c9f78 [PATCH] module support: record in vermagic ability to unload a module
An UML user reported (against 2.6.13.3/UML) he got kernel Oopses when
trying to rmmod (on a kernel with module unloading enabled) a module
compiled with module unloading disabled.  As crashing is a very correct
thing to do in that case, a solution is altering the vermagic string to
include this too.

Possibly, however, the code should not crash in this case, even if the
module didn't support unloading - it should simply abort the module
removal.  In this case, fixing that bug would be a better solution.  I've
not investigated though.

(akpm: a bit marginal - root screwed up and shot himself in the foot).

Cc: Hayim Shaul <hayim@post.tau.ac.il>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 06:18:45 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00