2006-10-05 21:41:33

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 00/14] UML: simple changes for 2.6.19

This is the first set of patches for UML for 2.6.19 I send - I have various
other patches to merge but I'm sending them in separate batches to avoid
flooding.

This first batch consists of:
* compilation/linking correction to merged patches (both from Jeff and from me)
in different configurations (including fixing up Pcap and crypto-modules
compilation)
* some longly needed changes to Kconfig entries (deprecate TT mode, update some
comments, add HOST_VMSPLIT config option to match host's VMSPLIT option).

--
Paolo 'Blaisorblade' Giarrusso
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com


2006-10-05 21:41:37

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 01/14] uml: fix compilation options for USER_OBJS

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Again, move inclusion of arch's Makefile after CFLAGS setting - I remember
merging the same patch eons ago in 2.6, so I added a comment.

I discovered this because debug info weren't enabled for USER_OBJS - they're
compiled with USER_CFLAGS which is calculated from CFLAGS (the whole thing is a
bit of an hack but fixing it is not easy, so we're leaving it as-is).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

Makefile | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index adb2c74..fc05890 100644
--- a/Makefile
+++ b/Makefile
@@ -489,8 +489,6 @@ else
CFLAGS += -O2
endif

-include $(srctree)/arch/$(ARCH)/Makefile
-
ifdef CONFIG_FRAME_POINTER
CFLAGS += -fno-omit-frame-pointer $(call cc-option,-fno-optimize-sibling-calls,)
else
@@ -518,6 +516,10 @@ CFLAGS += $(call cc-option,-Wdeclaration
# disable pointer signed / unsigned warnings in gcc 4.0
CFLAGS += $(call cc-option,-Wno-pointer-sign,)

+# After setting CFLAGS correctly, read in arch's Makefile. UML needs to receive the
+# correct value of CFLAGS.
+include $(srctree)/arch/$(ARCH)/Makefile
+
# Default kernel image to build when no specific target is given.
# KBUILD_IMAGE may be overruled on the command line or
# set in the environment
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:42:12

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 02/14] uml: revert wrong patch

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Andi Kleen pointed out that -mcmodel=kernel does not make sense for userspace
code and would stop everything from working, and pointed out the correct fix for
the original bug (not easy to do for me).

Reverts part of commit 06837504de7b4883e92af207dbbab4310d0db0ed.

Cc: Andi Kleen <[email protected]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/Makefile-x86_64 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/um/Makefile-x86_64 b/arch/um/Makefile-x86_64
index 11154b6..87d6373 100644
--- a/arch/um/Makefile-x86_64
+++ b/arch/um/Makefile-x86_64
@@ -4,7 +4,7 @@ # Released under the GPL
core-y += arch/um/sys-x86_64/
START := 0x60000000

-_extra_flags_ = -fno-builtin -m64 -mcmodel=kernel
+_extra_flags_ = -fno-builtin -m64

#We #undef __x86_64__ for kernelspace, not for userspace where
#it's needed for headers to work!
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:41:54

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 06/14] uml: make UML_SETJMP always safe

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

If enable is moved by GCC in a register its value may not be preserved after
coming back there with longjmp(). So, mark it as volatile to prevent this; this
is suggested (it seems) in info gcc, when it talks about -Wuninitialized. I
re-read this and it seems to say something different, but I still believe this
may be needed.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/include/longjmp.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/um/include/longjmp.h b/arch/um/include/longjmp.h
index e93c6d3..e860bc5 100644
--- a/arch/um/include/longjmp.h
+++ b/arch/um/include/longjmp.h
@@ -12,7 +12,8 @@ #define UML_LONGJMP(buf, val) do { \
} while(0)

#define UML_SETJMP(buf) ({ \
- int n, enable; \
+ int n; \
+ volatile int enable; \
enable = get_signals(); \
n = setjmp(*buf); \
if(n != 0) \
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:42:51

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 09/14] uml: declare in Kconfig our partial LOCKDEP support

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Declare UML partial support for LOCKDEP - however IRQFLAGS tracing requires some
coding which nobody did yet, so we cannot run full lockdep on UML. Grep for
CONFIG_TRACE_IRQFLAGS on i386 code to find their implementation.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/Kconfig | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index d753075..450547a 100644
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -25,6 +25,19 @@ config PCI
config PCMCIA
bool

+# Yet to do!
+config TRACE_IRQFLAGS_SUPPORT
+ bool
+ default n
+
+config LOCKDEP_SUPPORT
+ bool
+ default y
+
+config STACKTRACE_SUPPORT
+ bool
+ default y
+
config GENERIC_CALIBRATE_DELAY
bool
default y
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:42:33

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 08/14] uml: fix uname under setarch i386

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

On a 64bit Uml, if run under "setarch i386" (which a user did), uname()
currently returns the obtained i686 as machine - fix that. Btw, I'm quite
surprised that under setarch i386 a 64-bit binary can run.

Cc: Andi Kleen <[email protected]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/os-Linux/util.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/um/os-Linux/util.c b/arch/um/os-Linux/util.c
index 3f5b151..56b8a50 100644
--- a/arch/um/os-Linux/util.c
+++ b/arch/um/os-Linux/util.c
@@ -80,11 +80,18 @@ void setup_machinename(char *machine_out
struct utsname host;

uname(&host);
-#if defined(UML_CONFIG_UML_X86) && !defined(UML_CONFIG_64BIT)
+#ifdef UML_CONFIG_UML_X86
+# ifndef UML_CONFIG_64BIT
if (!strcmp(host.machine, "x86_64")) {
strcpy(machine_out, "i686");
return;
}
+# else
+ if (!strcmp(host.machine, "i686")) {
+ strcpy(machine_out, "x86_64");
+ return;
+ }
+# endif
#endif
strcpy(machine_out, host.machine);
}
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:43:11

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 13/14] uml: deprecate CONFIG_MODE_TT

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Deprecate TT mode in Kconfig so that users won't select it, update the MODE_SKAS
description (it was largely obsolete and misleadin) and btw describe advantages
for high memory usage with CONFIG_STATIC_LINK.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/Kconfig | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index 450547a..78fb619 100644
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -50,13 +50,15 @@ config IRQ_RELEASE_METHOD
menu "UML-specific options"

config MODE_TT
- bool "Tracing thread support"
+ bool "Tracing thread support (DEPRECATED)"
default n
help
This option controls whether tracing thread support is compiled
- into UML. This option is largely obsolete, given that skas0 provides
+ into UML. This option is largely obsolete, given that skas0 provides
skas security and performance without needing to patch the host.
- It is safe to say 'N' here.
+ It is safe to say 'N' here; saying 'Y' may cause additional problems
+ with the resulting binary even if you run UML in SKAS mode, and running
+ in TT mode is strongly *NOT RECOMMENDED*.

config STATIC_LINK
bool "Force a static link"
@@ -69,6 +71,9 @@ config STATIC_LINK
for use in a chroot jail. So, if you intend to run UML inside a
chroot, and you disable CONFIG_MODE_TT, you probably want to say Y
here.
+ Additionally, this option enables using higher memory spaces (up to
+ 2.75G) for UML - disabling CONFIG_MODE_TT and enabling this option leads
+ to best results for this.

config KERNEL_HALF_GIGS
int "Kernel address space size (in .5G units)"
@@ -85,10 +90,13 @@ config MODE_SKAS
default y
help
This option controls whether skas (separate kernel address space)
- support is compiled in. If you have applied the skas patch to the
- host, then you certainly want to say Y here (and consider saying N
- to CONFIG_MODE_TT). Otherwise, it is safe to say Y. Disabling this
- option will shrink the UML binary slightly.
+ support is compiled in.
+ Unless you have specific needs to use TT mode (which applies almost only
+ to developers), you should say Y here.
+ SKAS mode will make use of the SKAS3 patch if it is applied on the host
+ (and your UML will run in SKAS3 mode), but if no SKAS patch is applied
+ on the host it will run in SKAS0 mode, which is anyway faster than TT
+ mode.

source "arch/um/Kconfig.arch"
source "mm/Kconfig"
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:42:51

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 10/14] uml: allow using again x86/x86_64 crypto code

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Enable compilation of x86_64 crypto code;, and add the needed constant to make
the code compile again (that macro was added to i386 asm-offsets between 2.6.17
and 2.6.18, in 6c2bb98bc33ae33c7a33a133a4cd5a06395fece5).

Cc: Herbert Xu <[email protected]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/Makefile-x86_64 | 2 +-
arch/um/include/common-offsets.h | 1 +
arch/um/include/sysdep-i386/kernel-offsets.h | 1 +
arch/um/include/sysdep-x86_64/kernel-offsets.h | 1 +
4 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/um/Makefile-x86_64 b/arch/um/Makefile-x86_64
index 87d6373..d278682 100644
--- a/arch/um/Makefile-x86_64
+++ b/arch/um/Makefile-x86_64
@@ -1,7 +1,7 @@
# Copyright 2003 - 2004 Pathscale, Inc
# Released under the GPL

-core-y += arch/um/sys-x86_64/
+core-y += arch/um/sys-x86_64/ arch/x86_64/crypto/
START := 0x60000000

_extra_flags_ = -fno-builtin -m64
diff --git a/arch/um/include/common-offsets.h b/arch/um/include/common-offsets.h
index 356390d..39bb210 100644
--- a/arch/um/include/common-offsets.h
+++ b/arch/um/include/common-offsets.h
@@ -15,3 +15,4 @@ DEFINE_STR(UM_KERN_DEBUG, KERN_DEBUG);
DEFINE(UM_ELF_CLASS, ELF_CLASS);
DEFINE(UM_ELFCLASS32, ELFCLASS32);
DEFINE(UM_ELFCLASS64, ELFCLASS64);
+DEFINE(crypto_tfm_ctx_offset, offsetof(struct crypto_tfm, __crt_ctx));
diff --git a/arch/um/include/sysdep-i386/kernel-offsets.h b/arch/um/include/sysdep-i386/kernel-offsets.h
index 2c13de3..2e58c4c 100644
--- a/arch/um/include/sysdep-i386/kernel-offsets.h
+++ b/arch/um/include/sysdep-i386/kernel-offsets.h
@@ -1,6 +1,7 @@
#include <linux/stddef.h>
#include <linux/sched.h>
#include <linux/elf.h>
+#include <linux/crypto.h>
#include <asm/mman.h>

#define DEFINE(sym, val) \
diff --git a/arch/um/include/sysdep-x86_64/kernel-offsets.h b/arch/um/include/sysdep-x86_64/kernel-offsets.h
index 91d129f..4cbfbb9 100644
--- a/arch/um/include/sysdep-x86_64/kernel-offsets.h
+++ b/arch/um/include/sysdep-x86_64/kernel-offsets.h
@@ -2,6 +2,7 @@ #include <linux/stddef.h>
#include <linux/sched.h>
#include <linux/time.h>
#include <linux/elf.h>
+#include <linux/crypto.h>
#include <asm/page.h>
#include <asm/mman.h>

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:44:21

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 11/14] uml: asm offsets duplication removal

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Unify macros common to x86 and x86_64 kernel-offsets.h files.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/include/common-offsets.h | 10 ++++++++++
arch/um/include/sysdep-i386/kernel-offsets.h | 4 ----
arch/um/include/sysdep-x86_64/kernel-offsets.h | 4 ----
3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/um/include/common-offsets.h b/arch/um/include/common-offsets.h
index 39bb210..461175f 100644
--- a/arch/um/include/common-offsets.h
+++ b/arch/um/include/common-offsets.h
@@ -1,9 +1,16 @@
/* for use by sys-$SUBARCH/kernel-offsets.c */

+DEFINE(KERNEL_MADV_REMOVE, MADV_REMOVE);
+#ifdef CONFIG_MODE_TT
+OFFSET(HOST_TASK_EXTERN_PID, task_struct, thread.mode.tt.extern_pid);
+#endif
+
OFFSET(HOST_TASK_REGS, task_struct, thread.regs);
OFFSET(HOST_TASK_PID, task_struct, pid);
+
DEFINE(UM_KERN_PAGE_SIZE, PAGE_SIZE);
DEFINE(UM_NSEC_PER_SEC, NSEC_PER_SEC);
+
DEFINE_STR(UM_KERN_EMERG, KERN_EMERG);
DEFINE_STR(UM_KERN_ALERT, KERN_ALERT);
DEFINE_STR(UM_KERN_CRIT, KERN_CRIT);
@@ -12,7 +19,10 @@ DEFINE_STR(UM_KERN_WARNING, KERN_WARNING
DEFINE_STR(UM_KERN_NOTICE, KERN_NOTICE);
DEFINE_STR(UM_KERN_INFO, KERN_INFO);
DEFINE_STR(UM_KERN_DEBUG, KERN_DEBUG);
+
DEFINE(UM_ELF_CLASS, ELF_CLASS);
DEFINE(UM_ELFCLASS32, ELFCLASS32);
DEFINE(UM_ELFCLASS64, ELFCLASS64);
+
+/* For crypto assembler code. */
DEFINE(crypto_tfm_ctx_offset, offsetof(struct crypto_tfm, __crt_ctx));
diff --git a/arch/um/include/sysdep-i386/kernel-offsets.h b/arch/um/include/sysdep-i386/kernel-offsets.h
index 2e58c4c..97ec9d8 100644
--- a/arch/um/include/sysdep-i386/kernel-offsets.h
+++ b/arch/um/include/sysdep-i386/kernel-offsets.h
@@ -18,9 +18,5 @@ #define OFFSET(sym, str, mem) \
void foo(void)
{
OFFSET(HOST_TASK_DEBUGREGS, task_struct, thread.arch.debugregs);
- DEFINE(KERNEL_MADV_REMOVE, MADV_REMOVE);
-#ifdef CONFIG_MODE_TT
- OFFSET(HOST_TASK_EXTERN_PID, task_struct, thread.mode.tt.extern_pid);
-#endif
#include <common-offsets.h>
}
diff --git a/arch/um/include/sysdep-x86_64/kernel-offsets.h b/arch/um/include/sysdep-x86_64/kernel-offsets.h
index 4cbfbb9..a307237 100644
--- a/arch/um/include/sysdep-x86_64/kernel-offsets.h
+++ b/arch/um/include/sysdep-x86_64/kernel-offsets.h
@@ -19,9 +19,5 @@ #define OFFSET(sym, str, mem) \

void foo(void)
{
- DEFINE(KERNEL_MADV_REMOVE, MADV_REMOVE);
-#ifdef CONFIG_MODE_TT
- OFFSET(HOST_TASK_EXTERN_PID, task_struct, thread.mode.tt.extern_pid);
-#endif
#include <common-offsets.h>
}
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:43:22

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 14/14] uml: allow finer tuning for host VMSPLIT setting

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Now that various memory splits are enabled, add a config option allowing the
user to compile UML for its need - HOST_2G_2G allowed to choose either 3G/1G or
2G/2G, and enabling it reduced the usable virtual memory.

Detecting this at run time should be implemented in the future, but we must make
the stop-gap measure work well enough (this is valid in _many_ cases).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/Kconfig.i386 | 49 ++++++++++++++++++++++++++++++++++---------------
1 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/arch/um/Kconfig.i386 b/arch/um/Kconfig.i386
index f6eb72d..f191a55 100644
--- a/arch/um/Kconfig.i386
+++ b/arch/um/Kconfig.i386
@@ -16,23 +16,42 @@ config SEMAPHORE_SLEEPERS
bool
default y

-config HOST_2G_2G
- bool "2G/2G host address space split"
- default n
- help
- This is needed when the host on which you run has a 2G/2G memory
- split, instead of the customary 3G/1G.
-
- Note that to enable such a host
- configuration, which makes sense only in some cases, you need special
- host patches.
-
- So, if you do not know what to do here, say 'N'.
+choice
+ prompt "Host memory split"
+ default HOST_VMSPLIT_3G
+ ---help---
+ This is needed when the host kernel on which you run has a non-default
+ (like 2G/2G) memory split, instead of the customary 3G/1G. If you did
+ not recompile your own kernel but use the default distro's one, you can
+ safely accept the "Default split" option.
+
+ It can be enabled on recent (>=2.6.16-rc2) vanilla kernels via
+ CONFIG_VM_SPLIT_*, or on previous kernels with special patches (-ck
+ patchset by Con Kolivas, or other ones) - option names match closely the
+ host CONFIG_VM_SPLIT_* ones.
+
+ A lower setting (where 1G/3G is lowest and 3G/1G is higher) will
+ tolerate even more "normal" host kernels, but an higher setting will be
+ stricter.
+
+ So, if you do not know what to do here, say 'Default split'.
+
+ config HOST_VMSPLIT_3G
+ bool "Default split (3G/1G user/kernel host split)"
+ config HOST_VMSPLIT_3G_OPT
+ bool "3G/1G user/kernel host split (for full 1G low memory)"
+ config HOST_VMSPLIT_2G
+ bool "2G/2G user/kernel host split"
+ config HOST_VMSPLIT_1G
+ bool "1G/3G user/kernel host split"
+endchoice

config TOP_ADDR
- hex
- default 0xc0000000 if !HOST_2G_2G
- default 0x80000000 if HOST_2G_2G
+ hex
+ default 0xB0000000 if HOST_VMSPLIT_3G_OPT
+ default 0x78000000 if HOST_VMSPLIT_2G
+ default 0x40000000 if HOST_VMSPLIT_1G
+ default 0xC0000000

config 3_LEVEL_PGTABLES
bool "Three-level pagetables (EXPERIMENTAL)"
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:46:00

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH 02/14] uml: revert wrong patch

On Thursday 05 October 2006 23:38, Paolo 'Blaisorblade' Giarrusso wrote:

> Andi Kleen pointed out that -mcmodel=kernel does not make sense for userspace
> code and would stop everything from working,

did it work at all with it?

-Andi

2006-10-05 21:45:11

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 03/14] uml: correct removal of pte_mkexec

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Correct commit 5906e4171ad61ce68de95e51b773146707671f80 - this makes more sense:
we turn pte_mkexec + pte_wrprotect to pte_mkread. However, due to a bug in
pte_mkread, it does the exact same thing as pte_mkwrite, so this patch improves
the code but does not change anything in practice. The pte_mkread bug is fixed
separately, as it may have big impact.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/kernel/skas/mmu.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/um/kernel/skas/mmu.c b/arch/um/kernel/skas/mmu.c
index c17eddc..2c6d090 100644
--- a/arch/um/kernel/skas/mmu.c
+++ b/arch/um/kernel/skas/mmu.c
@@ -60,10 +60,7 @@ #ifdef CONFIG_3_LEVEL_PGTABLES
#endif

*pte = mk_pte(virt_to_page(kernel), __pgprot(_PAGE_PRESENT));
- /* This is wrong for the code page, but it doesn't matter since the
- * stub is mapped by hand with the correct permissions.
- */
- *pte = pte_mkwrite(*pte);
+ *pte = pte_mkread(*pte);
return(0);

out_pmd:
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:47:35

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 07/14] uml: fix processor selection to exclude unsupported processors and features

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Makes UML compile on any possible processor choice. The two problems were:

*) x86 code, when 386 is selected, checks at runtime boot_cpuflags, which we do
not have.
*) 3Dnow support for memcpy() et al. does not compile currently and fixing this
is not trivial, so simply disable it; with this change, if one selects MK7
UML compiles (while it did not).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/i386/Kconfig.cpu | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/i386/Kconfig.cpu b/arch/i386/Kconfig.cpu
index 21c9a4e..fc4f2ab 100644
--- a/arch/i386/Kconfig.cpu
+++ b/arch/i386/Kconfig.cpu
@@ -7,6 +7,7 @@ choice

config M386
bool "386"
+ depends on !UML
---help---
This is the processor type of your CPU. This information is used for
optimizing purposes. In order to compile a kernel that can run on
@@ -301,7 +302,7 @@ config X86_USE_PPRO_CHECKSUM

config X86_USE_3DNOW
bool
- depends on MCYRIXIII || MK7 || MGEODE_LX
+ depends on (MCYRIXIII || MK7 || MGEODE_LX) && !UML
default y

config X86_OOSTORE
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:47:11

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 05/14] uml: make TT mode compile after setjmp-related changes

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Make TT mode compile after the introduction of klibc's implementation of setjmp.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/kernel/tt/uaccess_user.c | 6 +++---
arch/um/os-Linux/tt.c | 1 -
2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/um/kernel/tt/uaccess_user.c b/arch/um/kernel/tt/uaccess_user.c
index 6c92bbc..ed1abcf 100644
--- a/arch/um/kernel/tt/uaccess_user.c
+++ b/arch/um/kernel/tt/uaccess_user.c
@@ -4,13 +4,13 @@
* Licensed under the GPL
*/

-#include <setjmp.h>
#include <string.h>
#include "user_util.h"
#include "uml_uaccess.h"
#include "task.h"
#include "kern_util.h"
#include "os.h"
+#include "longjmp.h"

int __do_copy_from_user(void *to, const void *from, int n,
void **fault_addr, void **fault_catcher)
@@ -80,10 +80,10 @@ int __do_strnlen_user(const char *str, u
struct tt_regs save = TASK_REGS(get_current())->tt;
int ret;
unsigned long *faddrp = (unsigned long *)fault_addr;
- sigjmp_buf jbuf;
+ jmp_buf jbuf;

*fault_catcher = &jbuf;
- if(sigsetjmp(jbuf, 1) == 0)
+ if(UML_SETJMP(&jbuf) == 0)
ret = strlen(str) + 1;
else ret = *faddrp - (unsigned long) str;

diff --git a/arch/um/os-Linux/tt.c b/arch/um/os-Linux/tt.c
index 5461a06..3dc3a02 100644
--- a/arch/um/os-Linux/tt.c
+++ b/arch/um/os-Linux/tt.c
@@ -10,7 +10,6 @@ #include <sched.h>
#include <errno.h>
#include <stdarg.h>
#include <stdlib.h>
-#include <setjmp.h>
#include <sys/time.h>
#include <sys/ptrace.h>
#include <linux/ptrace.h>
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:47:11

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 04/14] uml: readd forgot prototype

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

This was forgot in a previous patch so UML does not compile with TT mode enabled.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/include/os.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/um/include/os.h b/arch/um/include/os.h
index 120ca21..6516f6d 100644
--- a/arch/um/include/os.h
+++ b/arch/um/include/os.h
@@ -201,6 +201,7 @@ extern int os_getpgrp(void);

#ifdef UML_CONFIG_MODE_TT
extern void init_new_thread_stack(void *sig_stack, void (*usr1_handler)(int));
+extern void stop(void);
#endif
extern void init_new_thread_signals(void);
extern int run_kernel_thread(int (*fn)(void *), void *arg, void **jmp_ptr);
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-05 21:45:12

by Blaisorblade

[permalink] [raw]
Subject: [PATCH 12/14] uml: remove duplicate export

From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

The export is together with the definition, in arch/x86_64/lib/csum-partial.c,
which is compiled in by arch/um/sys-x86_64/Makefile.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

arch/um/sys-x86_64/ksyms.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/um/sys-x86_64/ksyms.c b/arch/um/sys-x86_64/ksyms.c
index 8592738..12c5936 100644
--- a/arch/um/sys-x86_64/ksyms.c
+++ b/arch/um/sys-x86_64/ksyms.c
@@ -14,6 +14,3 @@ EXPORT_SYMBOL(__up_wakeup);

/*XXX: we need them because they would be exported by x86_64 */
EXPORT_SYMBOL(__memcpy);
-
-/* Networking helper routines. */
-EXPORT_SYMBOL(ip_compute_csum);
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-06 01:00:39

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH 04/14] uml: readd forgot prototype

On Thu, 05 Oct 2006 23:38:46 +0200
"Paolo 'Blaisorblade' Giarrusso" <[email protected]> wrote:

> --- a/arch/um/include/os.h
> +++ b/arch/um/include/os.h
> @@ -201,6 +201,7 @@ extern int os_getpgrp(void);
>
> #ifdef UML_CONFIG_MODE_TT
> extern void init_new_thread_stack(void *sig_stack, void (*usr1_handler)(int));
> +extern void stop(void);

You have a global function called "stop"?

Good luck with that...

2006-10-06 21:59:31

by Blaisorblade

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 02/14] uml: revert wrong patch

On Thursday 05 October 2006 23:45, Andi Kleen wrote:
> On Thursday 05 October 2006 23:38, Paolo 'Blaisorblade' Giarrusso wrote:
> > Andi Kleen pointed out that -mcmodel=kernel does not make sense for
> > userspace code and would stop everything from working,
>
> did it work at all with it?
Guess not, I should have boot-tested it... :-(. Sorry.

--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-10 02:09:42

by Jeff Dike

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 01/14] uml: fix compilation options for USER_OBJS

On Thu, Oct 05, 2006 at 11:38:36PM +0200, Paolo 'Blaisorblade' Giarrusso wrote:
> Again, move inclusion of arch's Makefile after CFLAGS setting - I remember
> merging the same patch eons ago in 2.6, so I added a comment.
>
> I discovered this because debug info weren't enabled for USER_OBJS - they're
> compiled with USER_CFLAGS which is calculated from CFLAGS (the whole thing is a
> bit of an hack but fixing it is not easy, so we're leaving it as-is).

What's the matter with this:

Index: linux-2.6.18-mm/arch/um/Makefile
===================================================================
--- linux-2.6.18-mm.orig/arch/um/Makefile 2006-10-03 17:44:32.000000000 -0400
+++ linux-2.6.18-mm/arch/um/Makefile 2006-10-09 12:29:32.000000000 -0400
@@ -64,9 +64,8 @@ CFLAGS += $(CFLAGS-y) -D__arch_um__ -DSU

AFLAGS += $(ARCH_INCLUDE)

-USER_CFLAGS := $(patsubst -I%,,$(CFLAGS))
-USER_CFLAGS := $(patsubst -D__KERNEL__,,$(USER_CFLAGS)) $(ARCH_INCLUDE) \
- $(MODE_INCLUDE) -D_FILE_OFFSET_BITS=64
+USER_CFLAGS = $(patsubst -D__KERNEL__,,$(patsubst -I%,,$(CFLAGS))) \
+ $(ARCH_INCLUDE) $(MODE_INCLUDE) -D_FILE_OFFSET_BITS=64

# -Derrno=kernel_errno - This turns all kernel references to errno into
# kernel_errno to separate them from the libc errno. This allows -fno-common

The real problem is the use of := which assigns USER_CFLAGS from the
current value of CFLAGS, which is incomplete, as you noted.

Moving the include around seems slightly bogus, since its precise
location shouldn't matter.

If we switch to plain =, then it will be lazy-evaluated with the full
CFLAGS.

And we should check other uses of := to make sure they don't have
similar problems.

Jeff

2006-10-10 02:09:41

by Jeff Dike

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 04/14] uml: readd forgot prototype

On Thu, Oct 05, 2006 at 06:00:35PM -0700, Andrew Morton wrote:
> You have a global function called "stop"?
>
> Good luck with that...

Sorry, I've never been good at naming things :-)

Jeff

2006-10-10 02:10:07

by Jeff Dike

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 00/14] UML: simple changes for 2.6.19

On Thu, Oct 05, 2006 at 11:32:12PM +0200, Paolo 'Blaisorblade' Giarrusso wrote:
> This is the first set of patches for UML for 2.6.19 I send - I have various
> other patches to merge but I'm sending them in separate batches to avoid
> flooding.

ACK to all of these, except for the first one (moving the inclusion of
the arch Makefile), which seems wrong to me.

Jeff

2006-10-10 02:10:53

by Jeff Dike

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 13/14] uml: deprecate CONFIG_MODE_TT

On Thu, Oct 05, 2006 at 11:39:16PM +0200, Paolo 'Blaisorblade' Giarrusso wrote:
> - into UML. This option is largely obsolete, given that skas0 provides
> + into UML. This option is largely obsolete, given that skas0 provides

Nit - it is normal to have two spaces between sentences.

Jeff

2006-10-10 02:10:07

by Jeff Dike

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 06/14] uml: make UML_SETJMP always safe

On Thu, Oct 05, 2006 at 11:38:52PM +0200, Paolo 'Blaisorblade' Giarrusso wrote:
> From: Paolo 'Blaisorblade' Giarrusso <[email protected]>
>
> If enable is moved by GCC in a register its value may not be preserved after
> coming back there with longjmp(). So, mark it as volatile to prevent this; this
> is suggested (it seems) in info gcc, when it talks about -Wuninitialized. I
> re-read this and it seems to say something different, but I still believe this
> may be needed.
>
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
> ---
>
> arch/um/include/longjmp.h | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/um/include/longjmp.h b/arch/um/include/longjmp.h
> index e93c6d3..e860bc5 100644
> --- a/arch/um/include/longjmp.h
> +++ b/arch/um/include/longjmp.h
> @@ -12,7 +12,8 @@ #define UML_LONGJMP(buf, val) do { \
> } while(0)
>
> #define UML_SETJMP(buf) ({ \
> - int n, enable; \
> + int n; \
> + volatile int enable; \
> enable = get_signals(); \
> n = setjmp(*buf); \
> if(n != 0) \

I agree with this, but not entirely with your reasoning. The
-Wuninitialized documentation just talks about when gcc emits a
warning.

What we want is a guarantee that enable is not cached in a register,
but is stored in memory. What documentation I can find seems to imply
that is the case ("accesses to volatile objects must have settled
before the next sequence point").

However, given the prevailing opinion that essentially all volatile
declarations are hiding bugs, I wouldn't mind a bit of review of this
from someone holding this opinion.

Jeff

2006-10-11 11:08:36

by Blaisorblade

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 01/14] uml: fix compilation options for USER_OBJS

Jeff Dike <[email protected]> ha scritto:

> On Thu, Oct 05, 2006 at 11:38:36PM +0200, Paolo 'Blaisorblade'
> Giarrusso wrote:
> > Again, move inclusion of arch's Makefile after CFLAGS setting - I
> remember
> > merging the same patch eons ago in 2.6, so I added a comment.
> >
> > I discovered this because debug info weren't enabled for
> USER_OBJS - they're
> > compiled with USER_CFLAGS which is calculated from CFLAGS (the
> whole thing is a
> > bit of an hack but fixing it is not easy, so we're leaving it
> as-is).
>
> What's the matter with this:
>
> Index: linux-2.6.18-mm/arch/um/Makefile
> ===================================================================
> --- linux-2.6.18-mm.orig/arch/um/Makefile 2006-10-03
> 17:44:32.000000000 -0400
> +++ linux-2.6.18-mm/arch/um/Makefile 2006-10-09
> 12:29:32.000000000 -0400
> @@ -64,9 +64,8 @@ CFLAGS += $(CFLAGS-y) -D__arch_um__ -DSU
>
> AFLAGS += $(ARCH_INCLUDE)
>
> -USER_CFLAGS := $(patsubst -I%,,$(CFLAGS))
> -USER_CFLAGS := $(patsubst -D__KERNEL__,,$(USER_CFLAGS))
> $(ARCH_INCLUDE) \
> - $(MODE_INCLUDE) -D_FILE_OFFSET_BITS=64
> +USER_CFLAGS = $(patsubst -D__KERNEL__,,$(patsubst -I%,,$(CFLAGS)))
> \
> + $(ARCH_INCLUDE) $(MODE_INCLUDE) -D_FILE_OFFSET_BITS=64
>
> # -Derrno=kernel_errno - This turns all kernel references to errno
> into
> # kernel_errno to separate them from the libc errno. This allows
> -fno-common
>
> The real problem is the use of := which assigns USER_CFLAGS from
> the
> current value of CFLAGS, which is incomplete, as you noted.

Ok, at a first glance this alternative solution is ok. Make sure (run
gdb on an userspace object file and saying list <function>) that it
works and we'll be ok.

> Moving the include around seems slightly bogus, since its precise
> location shouldn't matter.
>
> If we switch to plain =, then it will be lazy-evaluated with the
> full
> CFLAGS.
>
> And we should check other uses of := to make sure they don't have
> similar problems.

Maybe, but I hope not... however if CFLAGS is used elsewhere its
occurrences must be looked for and checked.
--
Paolo 'Blaisorblade' Giarrusso

__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi
http://mail.yahoo.it

2006-10-13 20:11:34

by Jeff Dike

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 01/14] uml: fix compilation options for USER_OBJS

On Wed, Oct 11, 2006 at 01:08:27PM +0200, Paolo Giarrusso wrote:
> Ok, at a first glance this alternative solution is ok. Make sure (run
> gdb on an userspace object file and saying list <function>) that it
> works and we'll be ok.

After discovering that the original patch broke UML/i386 and broke the
UML/x86_64 build, I now have the patch below.

Listing userspace functions is fine.

Jeff


Index: linux-2.6.18-mm/arch/um/Makefile
===================================================================
--- linux-2.6.18-mm.orig/arch/um/Makefile 2006-10-13 10:20:51.000000000 -0400
+++ linux-2.6.18-mm/arch/um/Makefile 2006-10-13 10:21:50.000000000 -0400
@@ -64,9 +64,14 @@ CFLAGS += $(CFLAGS-y) -D__arch_um__ -DSU

AFLAGS += $(ARCH_INCLUDE)

-USER_CFLAGS := $(patsubst -I%,,$(CFLAGS))
-USER_CFLAGS := $(patsubst -D__KERNEL__,,$(USER_CFLAGS)) $(ARCH_INCLUDE) \
- $(MODE_INCLUDE) -D_FILE_OFFSET_BITS=64
+USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -D__KERNEL__,,\
+ $(patsubst -I%,,$(CFLAGS)))) $(ARCH_INCLUDE) $(MODE_INCLUDE) \
+ -D_FILE_OFFSET_BITS=64
+
+include $(srctree)/$(ARCH_DIR)/Makefile-$(SUBARCH)
+
+#This will adjust *FLAGS accordingly to the platform.
+include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS)

# -Derrno=kernel_errno - This turns all kernel references to errno into
# kernel_errno to separate them from the libc errno. This allows -fno-common
@@ -74,15 +79,11 @@ USER_CFLAGS := $(patsubst -D__KERNEL__,,
# errnos.
# These apply to kernelspace only.

-CFLAGS += -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask \
- -Dmktime=kernel_mktime
+KERNEL_DEFINES = -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask \
+ -Dmktime=kernel_mktime $(ARCH_KERNEL_DEFINES)
+CFLAGS += $(KERNEL_DEFINES)
CFLAGS += $(call cc-option,-fno-unit-at-a-time,)

-include $(srctree)/$(ARCH_DIR)/Makefile-$(SUBARCH)
-
-#This will adjust *FLAGS accordingly to the platform.
-include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS)
-
# These are needed for clean and mrproper, since in that case .config is not
# included; the values here are meaningless

Index: linux-2.6.18-mm/arch/um/Makefile-x86_64
===================================================================
--- linux-2.6.18-mm.orig/arch/um/Makefile-x86_64 2006-10-13 10:20:51.000000000 -0400
+++ linux-2.6.18-mm/arch/um/Makefile-x86_64 2006-10-13 10:21:50.000000000 -0400
@@ -8,8 +8,8 @@ _extra_flags_ = -fno-builtin -m64

#We #undef __x86_64__ for kernelspace, not for userspace where
#it's needed for headers to work!
-CFLAGS += -U__$(SUBARCH)__ $(_extra_flags_)
-USER_CFLAGS += $(_extra_flags_)
+ARCH_KERNEL_DEFINES = -U__$(SUBARCH)__
+CFLAGS += $(_extra_flags_)

CHECKFLAGS += -m64
AFLAGS += -m64
Index: linux-2.6.18-mm/arch/um/Makefile-i386
===================================================================
--- linux-2.6.18-mm.orig/arch/um/Makefile-i386 2006-10-10 09:10:21.000000000 -0400
+++ linux-2.6.18-mm/arch/um/Makefile-i386 2006-10-13 10:28:43.000000000 -0400
@@ -16,7 +16,6 @@ OBJCOPYFLAGS := -O binary -R .note -R
ifeq ("$(origin SUBARCH)", "command line")
ifneq ("$(shell uname -m | sed -e s/i.86/i386/)", "$(SUBARCH)")
CFLAGS += $(call cc-option,-m32)
-USER_CFLAGS += $(call cc-option,-m32)
AFLAGS += $(call cc-option,-m32)
LINK-y += $(call cc-option,-m32)
UML_OBJCOPYFLAGS += -F $(ELF_FORMAT)
@@ -25,7 +24,7 @@ export LDFLAGS HOSTCFLAGS HOSTLDFLAGS UM
endif
endif

-CFLAGS += -U__$(SUBARCH)__ -U$(SUBARCH)
+ARCH_KERNEL_DEFINES += -U__$(SUBARCH)__ -U$(SUBARCH)

# First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y.
include $(srctree)/arch/i386/Makefile.cpu
@@ -38,4 +37,3 @@ cflags-y += $(call cc-option,-mpreferred
cflags-y += -ffreestanding

CFLAGS += $(cflags-y)
-USER_CFLAGS += $(cflags-y)

2006-10-14 00:14:11

by Blaisorblade

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 06/14] uml: make UML_SETJMP always safe

On Monday 09 October 2006 20:00, Jeff Dike wrote:
> On Thu, Oct 05, 2006 at 11:38:52PM +0200, Paolo 'Blaisorblade' Giarrusso
wrote:
> > From: Paolo 'Blaisorblade' Giarrusso <[email protected]>
> >
> > If enable is moved by GCC in a register its value may not be preserved
> > after coming back there with longjmp(). So, mark it as volatile to
> > prevent this; this is suggested (it seems) in info gcc, when it talks
> > about -Wuninitialized. I re-read this and it seems to say something
> > different, but I still believe this may be needed.
> >
> > Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
> > ---
> >
> > arch/um/include/longjmp.h | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/um/include/longjmp.h b/arch/um/include/longjmp.h
> > index e93c6d3..e860bc5 100644
> > --- a/arch/um/include/longjmp.h
> > +++ b/arch/um/include/longjmp.h
> > @@ -12,7 +12,8 @@ #define UML_LONGJMP(buf, val) do { \
> > } while(0)
> >
> > #define UML_SETJMP(buf) ({ \
> > - int n, enable; \
> > + int n; \
> > + volatile int enable; \
> > enable = get_signals(); \
> > n = setjmp(*buf); \
> > if(n != 0) \
>
> I agree with this, but not entirely with your reasoning. The
> -Wuninitialized documentation just talks about when gcc emits a
> warning.
>
> What we want is a guarantee that enable is not cached in a register,
> but is stored in memory. What documentation I can find seems to imply
> that is the case ("accesses to volatile objects must have settled
> before the next sequence point").
>
> However, given the prevailing opinion that essentially all volatile
> declarations are hiding bugs, I wouldn't mind a bit of review of this
> from someone holding this opinion.

I agree with that, so I think Al (whom I cc'ed) will be able to evaluate this.
- however I think that the problem with volatile is that it does not have any
semantic wrt cache - volatile does not even work with host-to-device
operation (the thing it was thought for) if you have reasonable caches -
unless the var is in a MMIO region with disabled caches.

So relying on volatile for variables shared between threads is not useful.

Note that raw_spinlock_t counter is volatile, however - separate caches
flushes or atomic operations are needed, but it may avoid the need for a full
barrier() operation or a volatile "memory" clobber - GCC knows only the
volatile object has changed, while with barrier() it must assume everything
must be reloaded. However, at least one barrier operation is needed for a
spinlock to prevent GCC from moving code outside of critical sections.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

2006-10-26 06:08:42

by Blaisorblade

[permalink] [raw]
Subject: Re: [uml-devel] [PATCH 01/14] uml: fix compilation options for USER_OBJS

On Friday 13 October 2006 22:10, Jeff Dike wrote:
> On Wed, Oct 11, 2006 at 01:08:27PM +0200, Paolo Giarrusso wrote:
> > Ok, at a first glance this alternative solution is ok. Make sure (run
> > gdb on an userspace object file and saying list <function>) that it
> > works and we'll be ok.
>
> After discovering that the original patch broke UML/i386 and broke the
> UML/x86_64 build, I now have the patch below.
Where is it? It should go in 2.6.19. I'm going to test it locally and merge
it.
> Listing userspace functions is fine.
Good...
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com