[uml-devel] UML-patches to prepare UML/s390

[uml-devel] UML-patches to prepare UML/s390

[Bodo Stroesser]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

Here are the patches (tarball attached), that I've applied to
UML 2.6.11 + incrementals, before adding s390-files.
These patches are tested a bit on x86, but not on x86_64.

s390 implementation is *not* included in tarball, this will
be posted later, when thing are more stable.

Please see patches and commented series-file for further
information.


	Bodo

[-- Attachment #2: patches-2.6.11-prepare-s390.tar.gz --]
[-- Type: application/x-gzip, Size: 28084 bytes --]

[uml-devel] Re: UML-patches to prepare UML/s390

[Jeff Dike]

On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
> Here are the patches (tarball attached), that I've applied to
> UML 2.6.11 + incrementals, before adding s390-files.
> These patches are tested a bit on x86, but not on x86_64.

I merged these, except for the restartnointr one because I don't have
ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.

				Jeff


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: UML-patches to prepare UML/s390

[Bodo Stroesser]

Jeff Dike wrote:
> On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
> 
>>Here are the patches (tarball attached), that I've applied to
>>UML 2.6.11 + incrementals, before adding s390-files.
>>These patches are tested a bit on x86, but not on x86_64.
> 
> 
> I merged these, except for the restartnointr one because I don't have
> ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.
> 
> 				Jeff
That's bad. Do you have any suggestions how to solve this?

	Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Blaisorblade]

On Wednesday 06 April 2005 20:57, Bodo Stroesser wrote:
> Jeff Dike wrote:
> > On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
> >>Here are the patches (tarball attached), that I've applied to
> >>UML 2.6.11 + incrementals, before adding s390-files.
> >>These patches are tested a bit on x86, but not on x86_64.
> >
> > I merged these, except for the restartnointr one because I don't have
> > ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.
> >
> >     Jeff
>
> That's bad. Do you have any suggestions how to solve this?
Add it to the compilation-generated header files (the output of mk_constants, 
mk_thread and such), so we catch it from the definition given by ourselves 
and expose to the whole of UML.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Bodo Stroesser]

Blaisorblade wrote:
> On Wednesday 06 April 2005 20:57, Bodo Stroesser wrote:
> 
>>Jeff Dike wrote:
>>
>>>On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
>>>
>>>>Here are the patches (tarball attached), that I've applied to
>>>>UML 2.6.11 + incrementals, before adding s390-files.
>>>>These patches are tested a bit on x86, but not on x86_64.
>>>
>>>I merged these, except for the restartnointr one because I don't have
>>>ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.
>>>
>>>    Jeff
>>
>>That's bad. Do you have any suggestions how to solve this?
> 
> Add it to the compilation-generated header files (the output of mk_constants, 
> mk_thread and such), so we catch it from the definition given by ourselves 
> and expose to the whole of UML.
Yeah, tx, that would be possible.
But the reason for using /usr/include/linux/errno.h was to have the host's
definition, not the one from guest.
Currently they are the same for 2.4 and 2.6, but worst case that might change in
future versions. Only debugger could note this, as ERESTART_XXXX is unvisible
to user programs.
So, when implementing your idea, maybe I should add a further test, that
our ERESTARTNOINTR *does* trigger a syscall restart on the host.

	Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Blaisorblade]

On Wednesday 06 April 2005 21:26, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Wednesday 06 April 2005 20:57, Bodo Stroesser wrote:
> >>Jeff Dike wrote:
> >>>On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
> >>>>Here are the patches (tarball attached), that I've applied to
> >>>>UML 2.6.11 + incrementals, before adding s390-files.
> >>>>These patches are tested a bit on x86, but not on x86_64.
> >>>
> >>>I merged these, except for the restartnointr one because I don't have
> >>>ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.
> >>>
> >>>    Jeff
> >>
> >>That's bad. Do you have any suggestions how to solve this?
> >
> > Add it to the compilation-generated header files (the output of
> > mk_constants, mk_thread and such), so we catch it from the definition
> > given by ourselves and expose to the whole of UML.
>
> Yeah, tx, that would be possible.
> But the reason for using /usr/include/linux/errno.h was to have the host's
> definition, not the one from guest.

> Currently they are the same for 2.4 and 2.6, but worst case that might
> change in future versions.
Yes maybe in principle, however the errno values are part of the ABI.
> Only debugger could note this, as ERESTART_XXXX 
> is unvisible to user programs.
Well, the debugger is a user program, so even this one, which is almost 
internal, is part of the ABI. Actually, you might ask on LKML if you want.
> So, when implementing your idea, maybe I should add a further test, that
> our ERESTARTNOINTR *does* trigger a syscall restart on the host.

Well, maybe adding a runtime test is worth, however let's start by fixing it 
compile-time as I say below. I don't know if adding a test now is "excessive 
planification and over-coding", but I feel like this (especially even for the 
above ABI reasons).

A simpler idea:

get our value as I said
get the host value if defined (it's a macro so no problem)

#ifdef HOST_ERESTARTNOINTR
#define ERESTARTNOINTR HOST_ERESTARTNOINTR
#else
#define ERESTARTNOINTR KERN_ERESTARTNOINTR
#endif

Or, actually:

#ifndef ERESTARTNOINTR
#define ERESTARTNOINTR KERN_ERESTARTNOINTR
#endif

Btw, we currently solved this for PTRACE_SYSEMU, SETOPTIONS and many similar 
things by copying the value we provide. It wouldn't be bad, when applicable 
(not PTRACE_SYSEMU since mainline hasn't the SYSEMU patch), to use the above 
construct (i.e. taking the fallback value from the kernel instead of 
specifying it and copying it - they aren't supposed to change, but anyway).

However, I'll have to merge the refactoring of the userspace programs sooner 
or later. Don't let this stop you, anyway.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Bodo Stroesser]

Blaisorblade wrote:
> On Wednesday 06 April 2005 21:26, Bodo Stroesser wrote:
>>Currently they are the same for 2.4 and 2.6, but worst case that might
>>change in future versions.
> 
> Yes maybe in principle, however the errno values are part of the ABI.
I agree.
> 
>>Only debugger could note this, as ERESTART_XXXX 
>>is unvisible to user programs.
> 
> Well, the debugger is a user program, so even this one, which is almost 
> internal, is part of the ABI.
I agree.

> #ifndef ERESTARTNOINTR
> #define ERESTARTNOINTR KERN_ERESTARTNOINTR
> #endif
This is the solution, I like.
Here is, what strace programmers do, to decode ERESTARTXXXXX
results (from syscall.c):

... snip ...
#include <errno.h>
... snip ...
#ifdef LINUX
#ifndef ERESTARTSYS
#define ERESTARTSYS     512
#endif
#ifndef ERESTARTNOINTR
#define ERESTARTNOINTR  513
#endif
#ifndef ERESTARTNOHAND
#define ERESTARTNOHAND  514     /* restart if no handler.. */
#endif
#ifndef ENOIOCTLCMD
#define ENOIOCTLCMD     515     /* No ioctl command */
#endif
#ifndef ERESTART_RESTARTBLOCK
#define ERESTART_RESTARTBLOCK 516       /* restart by calling sys_restart_syscall */
#endif
#ifndef NSIG
#define NSIG 32
#endif
#ifdef ARM
#undef NSIG
#define NSIG 32
#undef NR_SYSCALL_BASE
#define NR_SYSCALL_BASE __NR_SYSCALL_BASE
#endif
#endif /* LINUX */
... snip ...

So, I'll modify my patch as you suggested.

	Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: UML-patches to prepare UML/s390

[Bodo Stroesser]

Jeff Dike wrote:
> On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
> 
>>Here are the patches (tarball attached), that I've applied to
>>UML 2.6.11 + incrementals, before adding s390-files.
>>These patches are tested a bit on x86, but not on x86_64.
> 
> 
> I merged these, except for the restartnointr one because I don't have
> ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.
> 
> 				Jeff
And sorry, I forgot: Thank you for merging most of them!

	Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Bastian Blank]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On Wed, Apr 06, 2005 at 04:35:58PM -0400, Jeff Dike wrote:
> I merged these, except for the restartnointr one because I don't have
> ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.

2.6.11 shows:

| $ grep ERESTARTNOINTR -r .
| ./linux/errno.h:#define ERESTARTNOINTR  513

And it is there since 2.5.

Bastian

-- 
No one wants war.
		-- Kirk, "Errand of Mercy", stardate 3201.7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Blaisorblade]

On Wednesday 06 April 2005 21:16, Bastian Blank wrote:
> On Wed, Apr 06, 2005 at 04:35:58PM -0400, Jeff Dike wrote:
> > I merged these, except for the restartnointr one because I don't have
> > ERESTARTNOINTR in my
Please note:
> > /usr/include

> > , inside a #ifdef KERNEL or not.  

>
> 2.6.11 shows:
> | $ grep ERESTARTNOINTR -r .
> | ./linux/errno.h:#define ERESTARTNOINTR  513
>
> And it is there since 2.5.
Yes, what you say is true, but non significant. He's speaking about the host 
include (and there are good reasons to do so) and we cannot rely on 2.6 host 
kernel headers.

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Bodo Stroesser]

Bastian Blank wrote:
> On Wed, Apr 06, 2005 at 04:35:58PM -0400, Jeff Dike wrote:
> 
>>I merged these, except for the restartnointr one because I don't have
>>ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.
> 
> 
> 2.6.11 shows:
> 
> | $ grep ERESTARTNOINTR -r .
> | ./linux/errno.h:#define ERESTARTNOINTR  513
> 
> And it is there since 2.5.
> 
> Bastian
> 
TX for the info, but sorry, I guess you missunderstood. We were not talking
about kernel's include/linux/errno.h, but about host's /usr/include/linux/errno.h,
included in a user-obj in UML. Even kernel 2.4 defines ERESTARTNOINTR,
but there seem to be some distros, that don't have it in /usr/include/linux/errno.h.
And I really wanted to have host's ERESTARTNOINTR!

	Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Bastian Blank]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Wed, Apr 06, 2005 at 09:33:56PM +0200, Bodo Stroesser wrote:
> Bastian Blank wrote:
| Mail-Followup-To: user-mode-linux-devel@lists.sourceforge.net 

Please fix your MUA.

> TX for the info, but sorry, I guess you missunderstood. We were not talking
> about kernel's include/linux/errno.h, but about host's 
> /usr/include/linux/errno.h,
> included in a user-obj in UML. Even kernel 2.4 defines ERESTARTNOINTR,
> but there seem to be some distros, that don't have it in 
> /usr/include/linux/errno.h.
> And I really wanted to have host's ERESTARTNOINTR!

Since when does glibc support building itself against anything else than
the Linux headers? But anyway, this errno is internal.  So there exists
no "host's ERESTARTNOINTR".

Bastian

-- 
Insufficient facts always invite danger.
		-- Spock, "Space Seed", stardate 3141.9

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Blaisorblade]

On Wednesday 06 April 2005 22:02, Bastian Blank wrote:
> On Wed, Apr 06, 2005 at 09:33:56PM +0200, Bodo Stroesser wrote:
> > Bastian Blank wrote:
> >
> | Mail-Followup-To: user-mode-linux-devel@lists.sourceforge.net
>
> Please fix your MUA.
>
> > TX for the info, but sorry, I guess you missunderstood. We were not
> > talking about kernel's include/linux/errno.h, but about host's
> > /usr/include/linux/errno.h,
> > included in a user-obj in UML. Even kernel 2.4 defines ERESTARTNOINTR,
> > but there seem to be some distros, that don't have it in
> > /usr/include/linux/errno.h.
> > And I really wanted to have host's ERESTARTNOINTR!
>
> Since when does glibc support building itself against anything else than
> the Linux headers?
The outdated ones, for instance? (I.e. 2.4)?
> But anyway, this errno is internal.  So there exists 
> no "host's ERESTARTNOINTR".
>
> Bastian

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: UML-patches to prepare UML/s390

[Bodo Stroesser]

Bastian Blank wrote:
> But anyway, this errno is internal.  So there exists
> no "host's ERESTARTNOINTR".
As Blaisorblade pointed out, ptrace interface also is
part of the ABI. User programs using ptrace *can* see
ERESTARTNOINTR and all the other ERESTARTXXXX.
So there exists "host's ERESTARTNOINTR", but sometimes it's
missing in the headers.
See, what strace-programmers do in syscall.c to define the
possibly missing ERESTARTXXXX macros.
We will have to do something similar in UML.

	Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: UML-patches to prepare UML/s390

[Bodo Stroesser]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

Jeff Dike wrote:
> On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
> 
>>Here are the patches (tarball attached), that I've applied to
>>UML 2.6.11 + incrementals, before adding s390-files.
>>These patches are tested a bit on x86, but not on x86_64.
> 
> 
> I merged these, except for the restartnointr one because I don't have
> ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not.
> 
> 				Jeff
Here is a revised patch, that solves the problem according to
Blaisorblade's suggestion, to use kernel's definition of
ERESTARTNOINTR, if host headers do not provide it.
So UM_ERESTARTNOINTR is added to kern_constants.h and used
depending on what host's errno.h gave us.

	Bodo

[-- Attachment #2: check-restart-skipping.patch --]
[-- Type: text/x-diff, Size: 19675 bytes --]


From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

s390 normally doesn't support a method, that allows us to force
the host to skip its syscall restart handling.
I implemented a new method in the host, which also is posted to
LKML to hopefully be inserted in s390 mainline.
To check availability of this change, I added a new check, which
is done in a slightly different way for the other arches, too.
Success in check_ptrace() and success in the new check are
absolutely necessary for UML to ru in any mode.
So I changed the sequence of checks to:
1) check_ptrace() being called at startup very early
2) check_ptrace() calls the new check, too
3) can_do_skas() is called after check_ptrace()
check_ptrace() will never return, if it failes, but it now uses
printf() and exit() instead of panic().

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---


diff -puN arch/um/os-Linux/start_up.c~check-restart-skipping arch/um/os-Linux/start_up.c
--- linux-2.6.11/arch/um/os-Linux/start_up.c~check-restart-skipping	2005-04-06 14:44:05.000000000 +0200
+++ linux-2.6.11-root/arch/um/os-Linux/start_up.c	2005-04-07 17:12:35.000000000 +0200
@@ -48,6 +48,18 @@
 #include "mem_user.h"
 #include "kern_constants.h"
 
+/* In some cases, host's headers don't provide ERESTARTNOINTR.
+ * If so, we use the definition from our own kernel headers.
+ * As kernel headers must not be included in this user-obj, we
+ * provide kernel's ERESTARTNOINTR as UM_ERESTARTNOINTR in
+ * kern_constants.h.
+ * Here we trust in ERESTARTNOINTR being a part of the ABI for
+ * strace and debuggers, so it shouldn't change.
+ */
+#ifndef ERESTARTNOINTR
+#define ERESTARTNOINTR UM_ERESTARTNOINTR
+#endif
+
 static int ptrace_child(void *arg)
 {
 	int ret;
@@ -74,9 +86,19 @@ static int ptrace_child(void *arg)
 		ret = 2; /*Serious trouble! This could be caused by a bug in
 			   host 2.6 SKAS3/2.6 patch before release -V6, together
 			   with a bug in the UML code itself.*/
+			 /*In ckeck_skas_restart_skip, this is the expected
+			   case, if everything works fine. (see below for
+			   additional info)*/
 	_exit(ret);
 }
 
+static void errout(char *str, int error)
+{
+	printf(str, error);
+	putchar('\n');
+	exit(1);
+}
+
 static int start_ptraced_child(void **stack_out)
 {
 	void *stack;
@@ -86,53 +108,52 @@ static int start_ptraced_child(void **st
 	stack = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC,
 		     MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
 	if(stack == MAP_FAILED)
-		panic("check_ptrace : mmap failed, errno = %d", errno);
+		errout("start_ptraced_child : mmap failed, errno = %d", errno);
 	sp = (unsigned long) stack + PAGE_SIZE - sizeof(void *);
 	pid = clone(ptrace_child, (void *) sp, SIGCHLD, NULL);
 	if(pid < 0)
-		panic("check_ptrace : clone failed, errno = %d", errno);
+		errout("start_ptraced_child : clone failed, errno = %d", errno);
 	CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 	if(n < 0)
-		panic("check_ptrace : wait failed, errno = %d", errno);
+		errout("start_ptraced_child : wait failed, errno = %d", errno);
 	if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGSTOP))
-		panic("check_ptrace : expected SIGSTOP, got status = %d",
-		      status);
+		errout("start_ptraced_child : expected SIGSTOP, "
+		       "got status = %d", status);
 
 	*stack_out = stack;
 	return(pid);
 }
 
 /* When testing for SYSEMU support, if it is one of the broken versions, we 
- * must just avoid using sysemu, not panic, but only if SYSEMU features are 
+ * must just avoid using sysemu, not exit, but only if SYSEMU features are
  * broken.
- * So only for SYSEMU features we test mustpanic, while normal host features
+ * So only for SYSEMU features we test mustexit, while normal host features
  * must work anyway!
  */
-static int stop_ptraced_child(int pid, void *stack, int exitcode, int mustpanic)
+static int stop_ptraced_child(int pid, void *stack, int exitcode, int mustexit)
 {
 	int status, n, ret = 0;
 
 	if(ptrace(PTRACE_CONT, pid, 0, 0) < 0)
-		panic("check_ptrace : ptrace failed, errno = %d", errno);
+		errout("stop_ptraced_child : ptrace failed, errno = %d", errno);
 	CATCH_EINTR(n = waitpid(pid, &status, 0));
 	if(!WIFEXITED(status) || (WEXITSTATUS(status) != exitcode)) {
 		int exit_with = WEXITSTATUS(status);
 		if (exit_with == 2)
-			printk("check_ptrace : child exited with status 2. "
-			       "Serious trouble happening! Try updating your "
-			       "host skas patch!\nDisabling SYSEMU support.");
-		printk("check_ptrace : child exited with exitcode %d, while "
-		      "expecting %d; status 0x%x", exit_with,
-		      exitcode, status);
-		if (mustpanic)
-			panic("\n");
-		else
-			printk("\n");
+			printf("stop_ptraced_child : child exited with "
+			       "status 2. Serious trouble happening! "
+			       "Try updating your host skas patch!\n"
+			       "Disabling SYSEMU support.\n");
+		printf("stop_ptraced_child : child exited with exitcode %d, "
+		       "while expecting %d; status 0x%x\n", exit_with,
+		       exitcode, status);
+		if (mustexit)
+			exit(1);
 		ret = -1;
 	}
 
 	if(munmap(stack, PAGE_SIZE) < 0)
-		panic("check_ptrace : munmap failed, errno = %d", errno);
+		errout("stop_ptraced_child : munmap failed, errno = %d", errno);
 	return ret;
 }
 
@@ -158,7 +179,7 @@ static void __init check_sysemu(void)
 	void *stack;
 	int pid, n, status, count=0;
 
-	printk("Checking syscall emulation patch for ptrace...");
+	printf("Checking syscall emulation patch for ptrace...");
 	sysemu_supported = 0;
 	pid = start_ptraced_child(&stack);
 
@@ -167,59 +188,61 @@ static void __init check_sysemu(void)
 
 	CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 	if (n < 0)
-		panic("check_sysemu : wait failed, errno = %d", errno);
+		errout("check_sysemu : wait failed, errno = %d", errno);
 	if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
-		panic("check_sysemu : expected SIGTRAP, "
-		      "got status = %d", status);
+		errout("check_sysemu : expected SIGTRAP, "
+		       "got status = %d", status);
 
 	n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_RET_OFFSET,
 		   os_getpid());
 	if(n < 0)
-		panic("check_sysemu : failed to modify system "
-		      "call return, errno = %d", errno);
+		errout("check_sysemu : failed to modify system "
+		       "call return, errno = %d", errno);
 
 	if (stop_ptraced_child(pid, stack, 0, 0) < 0)
 		goto fail_stopped;
 
 	sysemu_supported = 1;
-	printk("OK\n");
+	printf("OK\n");
 	set_using_sysemu(!force_sysemu_disabled);
 
-	printk("Checking advanced syscall emulation patch for ptrace...");
+	printf("Checking advanced syscall emulation patch for ptrace...");
 	pid = start_ptraced_child(&stack);
 
 	if(ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
-		panic("check_ptrace: PTRACE_SETOPTIONS failed, errno = %d",
-		      errno);
+		errout("check_sysemu: PTRACE_SETOPTIONS failed, errno = %d",
+		       errno);
 
 	while(1){
 		if(ptrace(PTRACE_SYSEMU_SINGLESTEP, pid, 0, 0) < 0)
 			goto fail;
 		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 		if(n < 0)
-			panic("check_ptrace : wait failed, errno = %d", errno);
+			errout("check_sysemu : wait failed, errno = %d", errno);
 		if(WIFSTOPPED(status) && (WSTOPSIG(status) == (SIGTRAP|0x80))){
-			if (!count)
-				panic("check_ptrace : SYSEMU_SINGLESTEP doesn't"
-				      " singlestep");
+			if (!count) {
+				printf("check_sysemu : SYSEMU_SINGLESTEP "
+				       "doesn't singlestep");
+				exit(1);
+			}
 			n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_RET_OFFSET,
 				   os_getpid());
 			if(n < 0)
-				panic("check_sysemu : failed to modify system "
-				      "call return, errno = %d", errno);
+				errout("check_sysemu : failed to modify system "
+				       "call return, errno = %d", errno);
 			break;
 		}
 		else if(WIFSTOPPED(status) && (WSTOPSIG(status) == SIGTRAP))
 			count++;
 		else
-			panic("check_ptrace : expected SIGTRAP or "
-			      "(SIGTRAP|0x80), got status = %d", status);
+			errout("check_sysemu : expected SIGTRAP or "
+			       "(SIGTRAP|0x80), got status = %d", status);
 	}
 	if (stop_ptraced_child(pid, stack, 0, 0) < 0)
 		goto fail_stopped;
 
 	sysemu_supported = 2;
-	printk("OK\n");
+	printf("OK\n");
 
 	if ( !force_sysemu_disabled )
 		set_using_sysemu(sysemu_supported);
@@ -228,7 +251,7 @@ static void __init check_sysemu(void)
 fail:
 	stop_ptraced_child(pid, stack, 1, 0);
 fail_stopped:
-	printk("missing\n");
+	printf("missing\n");
 }
 
 void __init check_ptrace(void)
@@ -236,23 +259,23 @@ void __init check_ptrace(void)
 	void *stack;
 	int pid, syscall, n, status;
 
-	printk("Checking that ptrace can change system call numbers...");
+	printf("Checking that ptrace can change system call numbers...");
 	pid = start_ptraced_child(&stack);
 
 	if(ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
-		panic("check_ptrace: PTRACE_SETOPTIONS failed, errno = %d",
-		      errno);
+		errout("check_ptrace: PTRACE_SETOPTIONS failed, errno = %d",
+		       errno);
 
 	while(1){
 		if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
-			panic("check_ptrace : ptrace failed, errno = %d", 
-			      errno);
+			errout("check_ptrace : ptrace failed, errno = %d",
+			       errno);
 		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 		if(n < 0)
-			panic("check_ptrace : wait failed, errno = %d", errno);
+			errout("check_ptrace : wait failed, errno = %d", errno);
 		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != (SIGTRAP|0x80)))
-			panic("check_ptrace : expected (SIGTRAP|0x80), "
-			      "got status = %d", status);
+			errout("check_ptrace : expected (SIGTRAP|0x80), "
+			       "got status = %d", status);
 		
 		syscall = ptrace(PTRACE_PEEKUSR, pid, PT_SYSCALL_NR_OFFSET,
 				 0);
@@ -260,13 +283,13 @@ void __init check_ptrace(void)
 			n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_NR_OFFSET,
 				   __NR_getppid);
 			if(n < 0)
-				panic("check_ptrace : failed to modify system "
-				      "call, errno = %d", errno);
+				errout("check_ptrace : failed to modify system "
+				       "call, errno = %d", errno);
 			break;
 		}
 	}
 	stop_ptraced_child(pid, stack, 0, 1);
-	printk("OK\n");
+	printf("OK\n");
 	check_sysemu();
 }
 
@@ -314,6 +337,126 @@ __uml_setup("noptraceldt", noptraceldt_c
 "    the current skas3 patch.\n\n");
 
 #ifdef UML_CONFIG_MODE_SKAS
+
+/*
+ * check_skas_restart_skip() will check, if the host can be forced to
+ * not do syscall restarting, even if the result of a UML-syscall is
+ * -ERESTARTxxxxx. Normally the -ERESTARTxxxxx result isn't passed to
+ * the user, because UML will replace it by -EINTR or the syscall-#
+ * to restart the syscall. So, the host won't see -ERESTARTxxxx in this
+ * case.
+ * But if the syscall in UML is sys_(rt)sigreturn, *every* result may
+ * be passed to the user, because it isn't a real result, but the
+ * interrupted processes register contents. So the host might see
+ * -ERESTARTxxxxx and could do syscall-restarting. This would produce
+ * unpredictible errors in UML.
+ * Thus, we have to force the host to skip syscall-restarting.
+ * Normally, this can be done by setting the syscall-# to -1 on exit
+ * from syscall (e.g. i386, x86_64). But that wouldn't work for s390,
+ * because s390 has syscall-result and syscall-# in the same register.
+ * s390 instead has a "trap" value in host's pt_regs, to distinguish
+ * between syscall / non-syscall. Unfortunately, "trap" isn't readable
+ * or writeable via ptrace.
+ * So, I modified the s390-host in a way, that it will change "trap",s
+ * if the syscall-# is written to -1 on syscall-entry.
+ * check_skas_restart_skip() will check presence of the change in
+ * s390-host. Also, it checks the "normal" way of skipping for the
+ * other arches.
+ * If syscall restarting can't be skipped, there is no safe way to run
+ * skas, no matter if skas0 or skas3.
+ * Due to the different syscall-handling in tt, a good result from
+ * check_ptrace is enough to run tt.
+ *
+ * What does the check:
+ * When the ptraced child is stopped at syscall entry, the syscall-# is
+ * overwritten by PT_SYSCALL_NR_SKIP_RESTART, which normally is
+ * __NR_getpid, so nothing is changed. But on s390 -1 is written, what
+ * should change "trap" in the host.
+ * Then the syscall is resumed with PTRACE_SYSCALL. On syscall exit,
+ * the result is replaced by -ERESTARTNOINTR, and if syscall-# and result
+ * are in different registers, the syscall-# is written with -1 (not on
+ * s390).
+ * Then, we send a SIGUSR1 to the child, forcing the host to do signal
+ * processing, which normally would cause syscall restarting. We
+ * intercept and suppress the signal via ptrace.
+ * Now, the ptraced child is resumed and the result is checked
+ * (stop_ptraced_child). What we expect is, that -ERESTARTNOINTR is the
+ * result of the syscall. If the host would do restarting, getpid()
+ * would be done again, and the result would be the child's pid.
+ * So the expected result of the child must be 2.
+ */
+static inline int check_skas_restart_skip(void)
+{
+	void *stack;
+	int pid, syscall, n, status;
+
+	printf("Checking if syscall restart handling in host can be skipped...");
+	pid = start_ptraced_child(&stack);
+
+	while(1){
+		if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
+			errout("check_skas_restart_skip : ptrace failed, "
+			       "errno = %d", errno);
+		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
+		if(n < 0)
+			errout("check_skas_restart_skip : wait failed, "
+			       "errno = %d", errno);
+		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
+			errout("check_skas_restart_skip : expected "
+			       "SIGTRAP, got status = %d", status);
+
+		syscall = ptrace(PTRACE_PEEKUSR, pid, PT_SYSCALL_NR_OFFSET, 0);
+		if(syscall == __NR_getpid){
+			n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_NR_OFFSET,
+				   PT_SYSCALL_NR_SKIP_RESTART);
+			if(n < 0)
+				errout("check_skas_restart_skip : failed to "
+				       "modify system call, errno = %d", errno);
+			break;
+		}
+	}
+
+	if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
+		errout("check_skas_restart_skip : ptrace failed, "
+		       "errno = %d", errno);
+	CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
+	if(n < 0)
+		errout("check_skas_restart_skip : wait failed, "
+		       "errno = %d", errno);
+	if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
+		errout("check_skas_restart_skip : expected "
+		       "SIGTRAP, got status = %d", status);
+
+	n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_RET_OFFSET, -ERESTARTNOINTR);
+	if(n < 0)
+		errout("check_skas_restart_skip : failed to modify system "
+		       "call result, errno = %d", errno);
+
+	if (PT_SYSCALL_NR_OFFSET != PT_SYSCALL_RET_OFFSET){
+		n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_NR_OFFSET, -1);
+		if(n < 0)
+			errout("check_skas_restart_skip : failed to modify "
+			       "system call number, errno = %d", errno);
+	}
+
+	kill(pid, SIGUSR1);
+
+	if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
+		errout("check_skas_restart_skip : ptrace failed, "
+		       "errno = %d", errno);
+	CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
+	if(n < 0)
+		errout("check_skas_restart_skip : wait failed, "
+		       "errno = %d", errno);
+	if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGUSR1))
+		errout("check_skas_restart_skip : expected "
+		       "SIGTRAP, got status = %d", status);
+
+	n = stop_ptraced_child(pid, stack, 2, 0);
+	printf("%s\n", n ? "failed" : "OK");
+	return n;
+}
+
 static inline void check_skas3_ptrace_faultinfo(void)
 {
 	struct ptrace_faultinfo fi;
@@ -400,6 +543,9 @@ static inline void check_skas3_proc_mm(v
 
 int can_do_skas(void)
 {
+	if(check_skas_restart_skip())
+		return 0;
+
 	printf("Checking for the skas3 patch in the host:\n");
 
 	check_skas3_proc_mm();
@@ -636,7 +782,6 @@ void __init check_sigio(void)
 /*-------------------*/
 void os_check_bugs(void)
 {
-	check_ptrace();
 	check_sigio();
 	check_devanon();
 }
diff -puN arch/um/include/sysdep-i386/ptrace_user.h~check-restart-skipping arch/um/include/sysdep-i386/ptrace_user.h
--- linux-2.6.11/arch/um/include/sysdep-i386/ptrace_user.h~check-restart-skipping	2005-04-06 14:44:05.000000000 +0200
+++ linux-2.6.11-root/arch/um/include/sysdep-i386/ptrace_user.h	2005-04-06 14:44:05.000000000 +0200
@@ -15,6 +15,8 @@
 #define PT_SYSCALL_NR(regs) ((regs)[ORIG_EAX])
 #define PT_SYSCALL_NR_OFFSET PT_OFFSET(ORIG_EAX)
 
+#define PT_SYSCALL_NR_SKIP_RESTART __NR_getpid
+
 #define PT_SYSCALL_ARG1_OFFSET PT_OFFSET(EBX)
 #define PT_SYSCALL_ARG2_OFFSET PT_OFFSET(ECX)
 #define PT_SYSCALL_ARG3_OFFSET PT_OFFSET(EDX)
diff -puN arch/um/include/sysdep-x86_64/ptrace_user.h~check-restart-skipping arch/um/include/sysdep-x86_64/ptrace_user.h
--- linux-2.6.11/arch/um/include/sysdep-x86_64/ptrace_user.h~check-restart-skipping	2005-04-06 14:44:05.000000000 +0200
+++ linux-2.6.11-root/arch/um/include/sysdep-x86_64/ptrace_user.h	2005-04-06 14:44:05.000000000 +0200
@@ -18,6 +18,8 @@
 #define PT_SYSCALL_NR(regs) ((regs)[PT_INDEX(ORIG_RAX)])
 #define PT_SYSCALL_NR_OFFSET (ORIG_RAX)
 
+#define PT_SYSCALL_NR_SKIP_RESTART __NR_getpid
+
 #define PT_SYSCALL_ARG1(regs) (((unsigned long *) (regs))[PT_INDEX(RDI)])
 #define PT_SYSCALL_ARG1_OFFSET (RDI)
 
diff -puN arch/um/kernel/um_arch.c~check-restart-skipping arch/um/kernel/um_arch.c
--- linux-2.6.11/arch/um/kernel/um_arch.c~check-restart-skipping	2005-04-06 14:44:05.000000000 +0200
+++ linux-2.6.11-root/arch/um/kernel/um_arch.c	2005-04-06 14:44:05.000000000 +0200
@@ -320,6 +320,10 @@ int linux_main(int argc, char **argv)
 	}
 	if(have_root == 0) add_arg(DEFAULT_COMMAND_LINE);
 
+	/* First we check ptrace capabilities for UML's minimum need */
+	/* This won't return, if ptrace isn't sufficient */
+	check_ptrace();
+	/* Now can_do_skas tells us, whether we may run skas or not */
 	mode_tt = force_tt ? 1 : !can_do_skas();
 #ifndef CONFIG_MODE_TT
 	if (mode_tt) {
diff -puN arch/um/kernel/skas/process.c~check-restart-skipping arch/um/kernel/skas/process.c
--- linux-2.6.11/arch/um/kernel/skas/process.c~check-restart-skipping	2005-04-06 14:44:05.000000000 +0200
+++ linux-2.6.11-root/arch/um/kernel/skas/process.c	2005-04-07 16:44:19.000000000 +0200
@@ -117,7 +117,8 @@ static void handle_trap(int pid, union u
 
 	if (!local_using_sysemu)
 	{
-		err = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_NR_OFFSET, __NR_getpid);
+		err = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_NR_OFFSET,
+			     PT_SYSCALL_NR_SKIP_RESTART);
 		if(err < 0)
 			panic("handle_trap - nullifying syscall failed errno = %d\n",
 			      errno);
@@ -297,7 +298,8 @@ void userspace(union uml_pt_regs *regs)
 			interrupt_end();
 
 			/* Avoid -ERESTARTSYS handling in host */
-			PT_SYSCALL_NR(regs->skas.regs) = -1;
+			if(PT_SYSCALL_NR_OFFSET != PT_SYSCALL_RET_OFFSET)
+				PT_SYSCALL_NR(regs->skas.regs) = -1;
 		}
 	}
 }
diff -puN arch/um/util/offsets.h~check-restart-skipping arch/um/util/offsets.h
--- linux-2.6.11/arch/um/util/offsets.h~check-restart-skipping	2005-04-07 17:19:12.000000000 +0200
+++ linux-2.6.11-root/arch/um/util/offsets.h	2005-04-07 17:20:32.000000000 +0200
@@ -12,3 +12,4 @@ 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_ERESTARTNOINTR, ERESTARTNOINTR);
diff -puN arch/um/util/mk_constants.c~check-restart-skipping arch/um/util/mk_constants.c
--- linux-2.6.11/arch/um/util/mk_constants.c~check-restart-skipping	2005-04-07 17:20:47.000000000 +0200
+++ linux-2.6.11-root/arch/um/util/mk_constants.c	2005-04-07 17:21:14.000000000 +0200
@@ -26,6 +26,8 @@ int main(int argc, char **argv)
   SHOW_STR(UM_KERN_DEBUG);
 
   SHOW_INT(UM_NSEC_PER_SEC);
+
+  SHOW_INT(UM_ERESTARTNOINTR);
   printf("\n");
   printf("#endif\n");
   return(0);
_

Re: [uml-devel] UML-patches to prepare UML/s390

[Blaisorblade]

On Wednesday 06 April 2005 15:27, Bodo Stroesser wrote:
> Here are the patches (tarball attached), that I've applied to
> UML 2.6.11 + incrementals, before adding s390-files.
> These patches are tested a bit on x86, but not on x86_64.
>
> s390 implementation is *not* included in tarball, this will
> be posted later, when thing are more stable.
>
> Please see patches and commented series-file for further
> information.

add-stub-vmas has already your notes in it, and I agree with the notes.

delay-pure-arch: forgot EXPORT_SYMBOL on x86_64, also if every arch will 
provide them leave the EXPORT inside arch-independent ksyms.c. Also I don't 
like a function copied over subarchs. Move them to generic code with an ifdef 
ARCH_WANT_WHATEVER.

Copied code *always* gets out of sync (and that's not only in UML, I found by 
accident a case where ext2 was updated and ext3 wasn't and didn't use 
i_size_read, leading to possible race conditions). Btw, that's why Andi Kleen 
delayed a lot the merge of Xen, refusing that it be a separate arch/xen 
folder.

elf.h-symlink.patch: other includes also have a -generic.h file, like 
processor-generic.h, for common stuff.

insert-ARCH_SIGHDLR_PARAM.patch: this coding is very awkward (not mentioned in 
CodingStyle because they didn't think to it) - I don't know the handle's use. 
However, some commenting will be needed, as this is *not* a widespread 
construct. You'll also tell me how you'll handle the different params if the 
code stays the same...
I'd instead use a "do_alarm_handler" that takes everything as a param and an 
arch-specific caller passing the params, in general... but I don't really 
realize what will you do there. I fear a hidden param in 
ARCH_GET_SIGCONTEXT...

ptrace-subarch: forgot the "#if 0" for x86_64, possibly preventing it from 
compiling. Actually, from looking to /usr/include/sys/user.h, it will compile 
but be bogus. Keep the XXX comment but change the "addr >>= 2" to "addr >>= 
3" (because the various debug regs are each 8 and not 4 bytes long). I'll 
have to additionally check the manuals, however, this is why I ask to keep 
the comment.

rename-COMMAND_LINE_SIZE.patch: it's against an outdated part of Jeff's tree 
(i.e. code movements). I patched it in a different way in mainline - I thinl 
that code-movements patches should be merged the day they are written, or one 
day they are written. I.e. they must be rewritten when merging them, to avoid 
moving outdated code.

split-sys_call_table.patch: the current way of maintaining it has lead to too 
many problems, so I'm converting the code to a different way, i.e. including 
directly the original syscall table (with some defines, for instance

#define sys_iopl sys_ni_syscall

).
I didn't send them because I need that Jeff tests the x86_64 ones.

In i386 case, I split away the table from entry.S. In the s390 case, they 
already did this for theirselves and for us. You'll have to check if any 
function has been renamed in a strange way. I'll maybe do the check myself...

Also, the below is just bogus, 
-#ifdef CONFIG_NFSD
+#if defined(CONFIG_NFSD) || defined(CONFIG_NFSD_MODULE)
 #define NFSSERVCTL sys_nfsservctl
 #else
 #define NFSSERVCTL sys_ni_syscall
 #endif
because the correct code is this:
 #define NFSSERVCTL sys_nfsservctl

kernel/sys_ni.c will alias sys_nfsservctl (and *MANY* other syscalls) to 
sys_ni_syscall if needed, through weak symbols.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML-patches to prepare UML/s390

[Blaisorblade]

On Friday 08 April 2005 09:12, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Wednesday 06 April 2005 15:27, Bodo Stroesser wrote:
> >>s390 implementation is *not* included in tarball, this will
> >>be posted later, when thing are more stable.
>
> Thank you for all your comments!
>
> I don't wan't to give to the wide world, before it is more stable.
> But maybe this can answer some of your questions / remarks.
I assume you already sent it to Jeff, so I'm not forwarding it.

Now, some more little issues:

* arch_fixup() should be implemented but cannot cause problems currently. UML 
currently does not use the .fixup mechanism (which requires using some asm() 
inserts - maybe that can be limited to gas pseudo-instruction without real 
code), but only the fault_catcher and fault_address one, which is an inferior 
design (some runtime cost). Last time I looked there were some difficulties 
about 

* ARCH_SIGHDLR_PARAM works like I feared - you'd probably need {} (or do {} 
while (0)) around the ARCH_GET_SIGCONTEXT because you declare a var at the 
beginning... and that function will likely break if not commented (because who 
patches the code won't go checking what actually happens).

I also understand why you can't use the trick used elsewhere... I have no 
better solution than long comments.

* About ptrace_faultinfo: Jeff said that S390 "has complex fault 
informations", while they seem not very complicate inside the S390 patch (I 
was asking about the generalization of the "is_write" fault info). I want to 
know this for the purpose of working on a mergeable version of 
PTRACE_FAULTINFO (which will probably be an extension of PTRACE_SIGINFO)

Probably struct thread_struct has a more correct definition of those info... 
and arch/s390/mm/fault.c:do_exception even more. However, only some of that 
will be needed; we only need, in practise, the write/read (and maybe exec) 
type of the exception. 

Also, I've given a look and it wouldn't be difficult making PTRACE_SIGPENDING, 
just a bit long: update asm-generic/siginfo.h: struct siginfo : _sigfault 
(maybe depending on the arch), and all the callers.

* for glibc-bug.c, you might as well use an "alias, weak" attribute - see the 
below from asm-i386/unistd.h:

/*
 * "Conditional" syscalls
 *
 * What we want is __attribute__((weak,alias("sys_ni_syscall"))),
 * but it doesn't work on all toolchains, so we just do it by hand
 */
#ifndef cond_syscall
#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall");
#endif

Note that the asm code only contains pseudo-op so it should work as-is on 
s390, right?

Other issues follow, which refer to copied code going out-of-date wrt. my 
local tree (which I have snapshotted some time ago, after I started writing 
this mail). This is the problem with copying code - and you're starting 
experiencing it!

* important changes for TLS support, clone(), and so on.

* add a CHOOSE_MODE to arch_switch (since the current code is used only in TT 
mode) - I'm going to start calling it from SKAS mode and actually needing it 
for TLS support. Some changes to ptrace_user.c will also happen.

* CONFIG_64_BIT must become CONFIG_64BIT, as I'm doing for the other UML 
subarchs (the '_' is bogus, by comparison with other 64-bit archs). Also I'll 
have to clean up the Makefiles (USER_OBJS got fixed finally - they got 
dependency tracking, and the common boilerplate code is now in 
arch/um/scripts/Makefile.rules - more stuff has shifted there since when you 
did the patch). And there's no need to readd the end "Emacs" comments, we are 
gradually getting rid of them. However, I'll take care myself of all these 
trivial QA (quality assurance) issues.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML-patches to prepare UML/s390

[Bodo Stroesser]

Blaisorblade wrote:
> On Friday 08 April 2005 09:12, Bodo Stroesser wrote:
> 
>>Blaisorblade wrote:
>>
>>>On Wednesday 06 April 2005 15:27, Bodo Stroesser wrote:
>>>
>>>>s390 implementation is *not* included in tarball, this will
>>>>be posted later, when thing are more stable.
>>
>>Thank you for all your comments!
>>
>>I don't wan't to give to the wide world, before it is more stable.
>>But maybe this can answer some of your questions / remarks.
> 
> I assume you already sent it to Jeff, so I'm not forwarding it.
> 
> Now, some more little issues:
> 
> * arch_fixup() should be implemented but cannot cause problems currently. UML 
> currently does not use the .fixup mechanism (which requires using some asm() 
> inserts - maybe that can be limited to gas pseudo-instruction without real 
> code), but only the fault_catcher and fault_address one, which is an inferior 
> design (some runtime cost). Last time I looked there were some difficulties 
> about 
Yes. I saw arch_fixup() being unused, so I decided not to implement it on s390,
currently.

> 
> * ARCH_SIGHDLR_PARAM works like I feared - you'd probably need {} (or do {} 
> while (0)) around the ARCH_GET_SIGCONTEXT because you declare a var at the 
> beginning... and that function will likely break if not commented (because who 
> patches the code won't go checking what actually happens).
There is a reason for my decision, not to use "{}" here.

s390 doesn't have fields for error-address and trap_no in its sigcontext. Because
of alignment, there is an empty area in the sigcontext, that is big enough to hold
an additional pointer. But there isn't enough place for error-address and trap_no.
So I create a local struct faultinfo, write error-address and trap_no to it and add
its address to the sigcontext. Now the sigcontext containing all info can be passed
to the routine, which has to handle the signal.

If the additional struct faultinfo would be declared inside of a "{}", I guess
there would be no guarantee, that this structure still is valid outside the "{}".
But it needs to be valid at the same level, from where sigcontext is passed to
the called handler.

The current solution should be used immediately after definition of local variables.
Maybe, this should be commented, too.
> 
> I also understand why you can't use the trick used elsewhere... I have no 
> better solution than long comments.
> 
> * About ptrace_faultinfo: Jeff said that S390 "has complex fault 
> informations", while they seem not very complicate inside the S390 patch (I 
> was asking about the generalization of the "is_write" fault info). I want to 
> know this for the purpose of working on a mergeable version of 
> PTRACE_FAULTINFO (which will probably be an extension of PTRACE_SIGINFO)
> 
> Probably struct thread_struct has a more correct definition of those info... 
> and arch/s390/mm/fault.c:do_exception even more. However, only some of that 
> will be needed; we only need, in practise, the write/read (and maybe exec) 
> type of the exception. 
s390 fault information is complex to handle only regarding sighandlers / sigcontext.
Else it is even more simple than i386, as i386 has address, fault_type and trap,
while s390 has address and trap_no only.
What is the faultinfo used for in UML? First, it is used to handle pagefaults.
Second, it is used to give error-information to sighandlers of UML-user-programs.
So, PTRACE_FAULTINFO should give the caller *all* information, that a sighandler
would get. All this info should be stored in thread_struct.
Then, UML internally uses arch-specific macros to extract "is_write" and to see,
if segment violation might be fixable.
PTRACE_FAULTINFO on i386 unfortunately doesn't give UML all info. This should be
fixed in a mainline solution, as the current implementation can't distinguish
between a page-fault and a segment-fault. So a user-program in SKAS3 might loop
on a segment-fault instead of being interrupted by SIGSEGV. (See use of
PTRACE_FULL_FAULTINFO in arch/um/kernel/skas/process.c)

> 
> Also, I've given a look and it wouldn't be difficult making PTRACE_SIGPENDING, 
> just a bit long: update asm-generic/siginfo.h: struct siginfo : _sigfault 
> (maybe depending on the arch), and all the callers.
PTRACE_SIGPENDING currently is unused. I don't know, if there will be need for
it in future. IMHO, this should be removed.

> 
> * for glibc-bug.c, you might as well use an "alias, weak" attribute - see the 
> below from asm-i386/unistd.h:
> 
> /*
>  * "Conditional" syscalls
>  *
>  * What we want is __attribute__((weak,alias("sys_ni_syscall"))),
>  * but it doesn't work on all toolchains, so we just do it by hand
>  */
> #ifndef cond_syscall
> #define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall");
> #endif
> 
> Note that the asm code only contains pseudo-op so it should work as-is on 
> s390, right?
I've experimented with __attribute__((weak)) in C-code and had no success.
IIRC, the "weak" simply was ignored. So I decided to go forward and make s390
run, before clearing those "minor" problems.

> 
> Other issues follow, which refer to copied code going out-of-date wrt. my 
> local tree (which I have snapshotted some time ago, after I started writing 
> this mail). This is the problem with copying code - and you're starting 
> experiencing it!
> 
> * important changes for TLS support, clone(), and so on.
I've seen, that I'll have to implement the small support of TLS in s390. That's
on my todo

> 
> * add a CHOOSE_MODE to arch_switch (since the current code is used only in TT 
> mode) - I'm going to start calling it from SKAS mode and actually needing it 
> for TLS support. Some changes to ptrace_user.c will also happen.
Great. I also want to have arch_switch for skas, as I would like to have full
debugging support in skas.

> 
> * CONFIG_64_BIT must become CONFIG_64BIT, as I'm doing for the other UML 
> subarchs (the '_' is bogus, by comparison with other 64-bit archs). Also I'll 
> have to clean up the Makefiles (USER_OBJS got fixed finally - they got 
> dependency tracking, and the common boilerplate code is now in 
> arch/um/scripts/Makefile.rules - more stuff has shifted there since when you 
> did the patch). And there's no need to readd the end "Emacs" comments, we are 
> gradually getting rid of them. However, I'll take care myself of all these 
> trivial QA (quality assurance) issues.
Your help is very welcome. I also have to scan all the new file to add some
correct Copyright comments. This is a further reason for not publishing s390
yet.

		Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML-patches to prepare UML/s390

[Blaisorblade]

On Monday 18 April 2005 12:54, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Friday 08 April 2005 09:12, Bodo Stroesser wrote:

> > * ARCH_SIGHDLR_PARAM works like I feared - you'd probably need {} (or do
> > {} while (0)) around the ARCH_GET_SIGCONTEXT because you declare a var at
> > the beginning... and that function will likely break if not commented
> > (because who patches the code won't go checking what actually happens).

> There is a reason for my decision, not to use "{}" here.

> s390 doesn't have fields for error-address and trap_no in its sigcontext.
> Because of alignment, there is an empty area in the sigcontext, that is big
> enough to hold an additional pointer. But there isn't enough place for
> error-address and trap_no. So I create a local struct faultinfo, write
> error-address and trap_no to it and add its address to the sigcontext. Now
> the sigcontext containing all info can be passed to the routine, which has
> to handle the signal.
>
> If the additional struct faultinfo would be declared inside of a "{}", I
> guess there would be no guarantee, that this structure still is valid
> outside the "{}".
There is the guarantee that the identifier is NOT valid, and so the datas may 
be invalidated...

> But it needs to be valid at the same level, from where 
> sigcontext is passed to the called handler.

Ok...

> The current solution should be used immediately after definition of local
> variables. Maybe, this should be commented, too.

Yes, it's the minimum needed... as said we *will* get that broken by somebody 
otherwise.

> > I also understand why you can't use the trick used elsewhere... I have no
> > better solution than long comments.

> s390 fault information is complex to handle only regarding sighandlers /
> sigcontext. Else it is even more simple than i386, as i386 has address,
> fault_type and trap, while s390 has address and trap_no only.
> What is the faultinfo used for in UML? First, it is used to handle
> pagefaults. Second, it is used to give error-information to sighandlers of
> UML-user-programs. So, PTRACE_FAULTINFO should give the caller *all*
> information, that a sighandler would get. All this info should be stored in
> thread_struct.

> Then, UML internally uses arch-specific macros to extract "is_write" and to
> see, if segment violation might be fixable.

> PTRACE_FAULTINFO on i386 unfortunately doesn't give UML all info. This
> should be fixed in a mainline solution, as the current implementation can't
> distinguish between a page-fault and a segment-fault. So a user-program in
> SKAS3 might loop on a segment-fault instead of being interrupted by
> SIGSEGV.

> (See use of PTRACE_FULL_FAULTINFO in 
> arch/um/kernel/skas/process.c)
>
> > Also, I've given a look and it wouldn't be difficult making
> > PTRACE_SIGPENDING, just a bit long: update asm-generic/siginfo.h: struct
> > siginfo : _sigfault (maybe depending on the arch), and all the callers.
>
> PTRACE_SIGPENDING currently is unused. I don't know, if there will be need
> for it in future. IMHO, this should be removed.
Agreed, even Jeff confirmed it should be removed... but in the above lines I 
was really referring to PTRACE_SIGINFO.

> > * for glibc-bug.c, you might as well use an "alias, weak" attribute - see
> > the below from asm-i386/unistd.h:
> >
> > /*
> >  * "Conditional" syscalls
> >  *
> >  * What we want is __attribute__((weak,alias("sys_ni_syscall"))),
> >  * but it doesn't work on all toolchains, so we just do it by hand
> >  */
> > #ifndef cond_syscall
> > #define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x
> > ",sys_ni_syscall"); #endif
> >
> > Note that the asm code only contains pseudo-op so it should work as-is on
> > s390, right?
>
> I've experimented with __attribute__((weak)) in C-code and had no success.
> IIRC, the "weak" simply was ignored.
From my experience, it's possible that you used a declaration instead of a 
definition:

This:

int proc() __attribute__((weak));

does not work when it's actually called, but it does not give "unresolved 
symbol" when you take its address;

while this:
int proc() __attribute__((weak)) {
}
works in any case and does not give "already defined symbol" errors.

> So I decided to go forward and make 
> s390 run, before clearing those "minor" problems.

> > * important changes for TLS support, clone(), and so on.
>
> I've seen, that I'll have to implement the small support of TLS in s390.
> That's on my todo

> > * add a CHOOSE_MODE to arch_switch (since the current code is used only
> > in TT mode) - I'm going to start calling it from SKAS mode and actually
> > needing it for TLS support. Some changes to ptrace_user.c will also
> > happen.

> Great. I also want to have arch_switch for skas, as I would like to have
> full debugging support in skas.

> > * CONFIG_64_BIT must become CONFIG_64BIT, as I'm doing for the other UML
> > subarchs (the '_' is bogus, by comparison with other 64-bit archs). Also
> > I'll have to clean up the Makefiles (USER_OBJS got fixed finally - they
> > got dependency tracking, and the common boilerplate code is now in
> > arch/um/scripts/Makefile.rules - more stuff has shifted there since when
> > you did the patch). And there's no need to readd the end "Emacs"
> > comments, we are gradually getting rid of them. However, I'll take care
> > myself of all these trivial QA (quality assurance) issues.

> Your help is very welcome. I also have to scan all the new file to add some
> correct Copyright comments. This is a further reason for not publishing
> s390 yet.

> 		Bodo

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade





-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML-patches to prepare UML/s390

[Bodo Stroesser]

Blaisorblade wrote:
> Other issues follow, which refer to copied code going out-of-date wrt. my 
> local tree (which I have snapshotted some time ago, after I started writing 
> this mail). This is the problem with copying code - and you're starting 
> experiencing it!
> 
> * important changes for TLS support, clone(), and so on.
I'm going to implement TLS support in UML/s390. I could do this in
arch/um/sys-s390/syscalls.c/sys_clone() without any need to change generic
UML code.
But I guess, for i386 there will be a need for arch-specific code in copy_thread(),
maybe something like arch_copy_thread().
If so, s390 TLS support should be inserted using in the same manner.
Do you already have some code for this, that I could base on?

		Bodo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML-patches to prepare UML/s390

[Blaisorblade]

On Tuesday 26 April 2005 13:31, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > Other issues follow, which refer to copied code going out-of-date wrt. my
> > local tree (which I have snapshotted some time ago, after I started
> > writing this mail). This is the problem with copying code - and you're
> > starting experiencing it!
> >
> > * important changes for TLS support, clone(), and so on.
>
> I'm going to implement TLS support in UML/s390. I could do this in
> arch/um/sys-s390/syscalls.c/sys_clone() without any need to change generic
> UML code.
> But I guess, for i386 there will be a need for arch-specific code in
> copy_thread(), maybe something like arch_copy_thread().
> If so, s390 TLS support should be inserted using in the same manner.
> Do you already have some code for this, that I could base on?

On my web-site I've uploaded my personal devel-tree snapshot against -rc3. 
Currently I've had to add a "clear_flushed_tls()" to copy_thread(), which 
probably should be wrapped in a arch_copy_thread() (with a macro/inline in 
some header).

As a side note: the TLS code currently does not work yet, so don't rely on it. 
There are also some issues to (later?) consider, which are indicated in the 
patch itself; and there will be something to add to the host SKAS patch, 
because the current implementation would be a bit too slow probably.
-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: UML-patches to prepare UML/s390

[Jeff Dike]

On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
> Here are the patches (tarball attached), that I've applied to
> UML 2.6.11 + incrementals, before adding s390-files.
> These patches are tested a bit on x86, but not on x86_64.

The COMMAND_LINE_SIZE patch was required because this was conflicting with
the userspace s390 COMMAND_LINE_SIZE?  I think this is true because in the
kernel, asm-s390/setup.h doesn't get pulled in.

This stems from the fact that my tree had add_arg in os-Linux/util.c, which
seems wrong.  Blaisorblade had it moved to um_arch.c, which is right, and
where it is in my tree now.  So, I think UML_COMMAND_LINE_SIZE is not needed,
and I've removed it.

				Jeff


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: UML-patches to prepare UML/s390

[Blaisorblade]

On Friday 22 April 2005 03:32, Jeff Dike wrote:
> On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote:
> > Here are the patches (tarball attached), that I've applied to
> > UML 2.6.11 + incrementals, before adding s390-files.
> > These patches are tested a bit on x86, but not on x86_64.
>
> The COMMAND_LINE_SIZE patch was required because this was conflicting with
> the userspace s390 COMMAND_LINE_SIZE?  I think this is true because in the
> kernel, asm-s390/setup.h doesn't get pulled in.
>
> This stems from the fact that my tree had add_arg in os-Linux/util.c, which
> seems wrong.  Blaisorblade had it moved to um_arch.c, which is right, and
> where it is in my tree now.  So, I think UML_COMMAND_LINE_SIZE is not
> needed, and I've removed it.
The patch moving add_arg() was *before* the os-* work, so you might move (if 
needed, which I don't know) it again to os-Linux/util.c if you want (which 
didn't exist at that time). It came from arch/um/kernel/user_util.c, in fact.

Btw, many of the code movement things are just cut'n'paste things, so for them 
there is no reason to delay them. Now we are going to merge them for 
2.6.13-rc1 (for .12 it's too late), but every other delay increases the 
possibility that we fix somehow the code we are moving and forget to do the 
same on the moved code.

Finally, about the syscall table patches for s390: I'm going to merge into -mm 
the syscall table patches you can find in the last -devel snapshot I put on 
my page (the uploaded ones maybe are out-of-date, but I'll cc you on 
patches).

They entirely remove the UML syscall table to replace it with the $(SUBARCH) 
one (there is some hand-work to do for each subarch but it's much less than 
before). While doing this I also fixed various little bugs about this 
subject.
-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: UML-patches to prepare UML/s390

[Jeff Dike]

On Sun, Apr 24, 2005 at 04:44:37PM +0200, Blaisorblade wrote:
> The patch moving add_arg() was *before* the os-* work, so you might move (if 
> needed, which I don't know) it again to os-Linux/util.c if you want (which 
> didn't exist at that time). It came from arch/um/kernel/user_util.c, in fact.

Yeah, I was thinking that maybe it belonged under os, but I decided it really
should stay in kernel.  That's the kernel's version of the command line, not
what was passed in from the host.

> Btw, many of the code movement things are just cut'n'paste things, so for them 
> there is no reason to delay them. Now we are going to merge them for 
> 2.6.13-rc1 (for .12 it's too late), but every other delay increases the 
> possibility that we fix somehow the code we are moving and forget to do the 
> same on the moved code.

Yeah, that's a concern.  I'm holding onto the code movement because I want to
look at the os interface that resulted from it, and see if it can be cleaned
up.

> Finally, about the syscall table patches for s390: I'm going to merge into -mm 
> the syscall table patches you can find in the last -devel snapshot I put on 
> my page (the uploaded ones maybe are out-of-date, but I'll cc you on 
> patches).

What patch is this?  All I see is a patch which makes some small fixes to
the sys_call_table.

> They entirely remove the UML syscall table to replace it with the $(SUBARCH) 
> one (there is some hand-work to do for each subarch but it's much less than 
> before). While doing this I also fixed various little bugs about this 
> subject.

Don't send that anywhere until I've seen it.  Your description of it makes
me nervous.

				Jeff


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: UML-patches to prepare UML/s390

[Blaisorblade]

On Sunday 24 April 2005 18:51, Jeff Dike wrote:
> On Sun, Apr 24, 2005 at 04:44:37PM +0200, Blaisorblade wrote:
> > Btw, many of the code movement things are just cut'n'paste things, so for
> > them there is no reason to delay them. Now we are going to merge them for
> > 2.6.13-rc1 (for .12 it's too late), but every other delay increases the
> > possibility that we fix somehow the code we are moving and forget to do
> > the same on the moved code.

> Yeah, that's a concern.  I'm holding onto the code movement because I want
> to look at the os interface that resulted from it, and see if it can be
> cleaned up.
Happy for that.

> > Finally, about the syscall table patches for s390: I'm going to merge
> > into -mm the syscall table patches you can find in the last -devel
> > snapshot I put on my page (the uploaded ones maybe are out-of-date, but
> > I'll cc you on patches).

> What patch is this?  All I see is a patch which makes some small fixes to
> the sys_call_table.
No, I don't mean -bs, I mean the DEVEL snapshot. It's under 
patches/devel-guest/, and other will follow (when I have broad-band).

However the updated patches are flying to you (plural, since they also relate 
with s390 port).

> > They entirely remove the UML syscall table to replace it with the
> > $(SUBARCH) one (there is some hand-work to do for each subarch but it's
> > much less than before). While doing this I also fixed various little bugs
> > about this subject.
>
> Don't send that anywhere until I've seen it.  Your description of it makes
> me nervous.
I'm sending it for -mm only, and it's marked as such. Also it won't silently 
slip since it acts a bit on i386.

-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel