Extraversion in arch/um/Makefile is not needed in mainline, but just for
separate patches; also, they should set it in the main Makefile, not elsewhere
(Jeff Garzik has just complained).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---
uml-linux-2.6.8.1-paolo/arch/um/Makefile | 9 ---------
1 files changed, 9 deletions(-)
diff -puN arch/um/Makefile~uml-no-extraversion-in-mainline arch/um/Makefile
--- uml-linux-2.6.8.1/arch/um/Makefile~uml-no-extraversion-in-mainline 2004-09-06 19:23:08.400492544 +0200
+++ uml-linux-2.6.8.1-paolo/arch/um/Makefile 2004-09-06 19:24:05.342835992 +0200
@@ -10,13 +10,6 @@ SHELL := /bin/bash
filechk_gen_header = $<
-# Recalculate MODLIB to reflect the EXTRAVERSION changes (via KERNELRELEASE)
-# The way the toplevel Makefile is written EXTRAVERSION is not supposed
-# to be changed outside the toplevel Makefile, but recalculating MODLIB is
-# a sufficient workaround until we no longer need architecture dependent
-# EXTRAVERSION...
-MODLIB := $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
-
core-y += $(ARCH_DIR)/kernel/ \
$(ARCH_DIR)/drivers/ \
$(ARCH_DIR)/sys-$(SUBARCH)/
@@ -44,8 +37,6 @@ SYS_DIR := $(ARCH_DIR)/include/sysdep-$
include $(ARCH_DIR)/Makefile-$(SUBARCH)
include $(ARCH_DIR)/Makefile-os-$(OS)
-EXTRAVERSION := $(EXTRAVERSION)-1um
-
# -Derrno=kernel_errno - This turns all kernel references to errno into
# kernel_errno to separate them from the libc errno. This allows -fno-common
# in CFLAGS. Otherwise, it would cause ld to complain about the two different
_
Could you please fix UML to not use ghash.h and remove that one before
playing with new toys? This has been requested a few times now.
On Monday 06 September 2004 20:36, Christoph Hellwig wrote:
> Could you please fix UML to not use ghash.h and remove that one before
> playing with new toys? This has been requested a few times now.
Yes, I can try - but I'd like to know the exact reason (I'm not developing UML
as long as Jeff does).
My idea is that ghash.h is just trivial boilerplate which does not deserve
generalized code, so that even rewriting the same exact code without using
those macros (and maybe embedding some assumptions about this usage) would be
a fine solution; also, there is just one user of it
(arch/um/kernel/physmem.c, with just one hash defined), so it shouldn't be
hard.
However, if the problem with ghash.h is different, I need more explainations.
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
BlaisorBlade <[email protected]> wrote:
>
> On Monday 06 September 2004 20:36, Christoph Hellwig wrote:
> > Could you please fix UML to not use ghash.h and remove that one before
> > playing with new toys? This has been requested a few times now.
> Yes, I can try - but I'd like to know the exact reason (I'm not developing UML
> as long as Jeff does).
>
> My idea is that ghash.h is just trivial boilerplate which does not deserve
> generalized code, so that even rewriting the same exact code without using
> those macros (and maybe embedding some assumptions about this usage) would be
> a fine solution; also, there is just one user of it
> (arch/um/kernel/physmem.c, with just one hash defined), so it shouldn't be
> hard.
>
> However, if the problem with ghash.h is different, I need more explainations.
Take one look at ghash.h and you'll see why we don't want it in the tree.
ghash was removed for a while and it was not intended that it come back -
it snuck back by accident. Please, rewrite that piece of UML so we can
again remove ghash.h.
[email protected] said:
> Please, rewrite that piece of UML so we can again remove ghash.h.
I am, I'll send you a patch when I'm done.
Jeff