Update.

2001-04-05  David S. Miller  <davem@redhat.com>

	* elf/elf.h (HWCAP_SPARC_ULTRA3): Define it.
	* sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h: Add it to
	capability flags table and HWCAP_IMPORTANT, increase
	_DL_HWCAP_COUNT to 6.
	* sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h: Likewise.

6 files changed, 113 insertions, 14 deletions

diff --git a/ChangeLog b/ChangeLog
index 5a8426c..ccc0794 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2001-04-05  David S. Miller  <davem@redhat.com>
+
+	* elf/elf.h (HWCAP_SPARC_ULTRA3): Define it.
+	* sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h: Add it to
+	capability flags table and HWCAP_IMPORTANT, increase
+	_DL_HWCAP_COUNT to 6.
+	* sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h: Likewise.
+
 2001-04-04  David Mosberger  <davidm@hpl.hp.com>
 
 	* sysdeps/unix/sysv/linux/ia64/makecontext.c (__makecontext): Fix
diff --git a/FAQ b/FAQ
index 955cc54..addc014 100644
--- a/FAQ
+++ b/FAQ
@@ -184,6 +184,8 @@ please let me know.
 4.8.	The conversion table for character set XX does not match with
 what I expect.
 4.9.	How can I find out which version of glibc I am using in the moment?
+4.10.	Context switching with setcontext() does not work from within
+	signal handlers.
 
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
@@ -1853,12 +1855,56 @@ int main (void) { puts (gnu_get_libc_version ()); return 0; }
 This interface can also obviously be used to perform tests at runtime if
 this should be necessary.
 
+
+4.10.	Context switching with setcontext() does not work from within
+	signal handlers.
+
+{DMT} The Linux implementations (IA-64, S390 so far) of setcontext()
+supports synchronous context switches only.  There are several reasons for
+this:
+
+ o UNIX provides no other (portable) way of effecting a synchronous
+   context switch (also known as co-routine switch).  Some versions
+   support this via setjmp()/longjmp() but this does not work
+   universally.
+
+ o As defined by the UNIX '98 standard, the only way setcontext()
+   could trigger an asychronous context switch is if this function
+   were invoked on the ucontext_t pointer passed as the third argument
+   to a signal handler.  But according to draft 5, XPG6, XBD 2.4.3,
+   setcontext() is not among the set of routines that may be called
+   from a signal handler.
+
+ o If setcontext() were to be used for asynchronous context switches,
+   all kinds of synchronization and re-entrancy issues could arise and
+   these problems have already been solved by real multi-threading
+   libraries (e.g., POSIX threads or Linux threads).
+
+ o Synchronous context switching can be implemented entirely in
+   user-level and less state needs to be saved/restored than for an
+   asynchronous context switch.  It is therefore useful to distinguish
+   between the two types of context switches.  Indeed, some
+   application vendors are known to use setcontext() to implement
+   co-routines on top of normal (heavier-weight) pre-emptable threads.
+
+It should be noted that if someone was dead-bent on using setcontext()
+on the third arg of a signal handler, then IA-64 Linux could support
+this via a special version of sigaction() which arranges that all
+signal handlers start executing in a shim function which takes care of
+saving the preserved registers before calling the real signal handler
+and restoring them afterwards.  In other words, we could provide a
+compatibility layer which would support setcontext() for asynchronous
+context switches.  However, given the arguments above, I don't think
+that makes sense.  setcontext() provides a decent co-routine interface
+and we should just discourage any asynchronous use (which just calls
+for trouble at any rate).
+
 
 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
 
 Answers were given by:
-{UD} Ulrich Drepper, <drepper@cygnus.com>
-{DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
+{UD} Ulrich Drepper, <drepper@redhat.com>
+{DMT} David Mosberger-Tang, <davidm@hpl.hp.com>
 {RM} Roland McGrath, <roland@gnu.org>
 {AJ} Andreas Jaeger, <aj@suse.de>
 {EY} Eric Youngdale, <eric@andante.jic.com>
@@ -1866,10 +1912,10 @@ Answers were given by:
 {MK} Mark Kettenis, <kettenis@phys.uva.nl>
 {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
 {TK} Thorsten Kukuk, <kukuk@suse.de>
-{GK} Geoffrey Keating, <geoffk@ozemail.com.au>
+{GK} Geoffrey Keating, <geoffk@redhat.com>
 {HJ} H.J. Lu, <hjl@gnu.org>
 {CG} Cristian Gafton, <gafton@redhat.com>
-{AO} Alexandre Oliva, <oliva@lsd.ic.unicamp.br>
+{AO} Alexandre Oliva, <aoliva@redhat.com>
 {BH} Bruno Haible, <haible@clisp.cons.org>
 
 Local Variables:
diff --git a/FAQ.in b/FAQ.in
index 397b62f..0da2873 100644
--- a/FAQ.in
+++ b/FAQ.in
@@ -1596,10 +1596,54 @@ int main (void) { puts (gnu_get_libc_version ()); return 0; }
 This interface can also obviously be used to perform tests at runtime if
 this should be necessary.
 
+??	Context switching with setcontext() does not work from within
+	signal handlers.
+
+{DMT} The Linux implementations (IA-64, S390 so far) of setcontext()
+supports synchronous context switches only.  There are several reasons for
+this:
+
+ o UNIX provides no other (portable) way of effecting a synchronous
+   context switch (also known as co-routine switch).  Some versions
+   support this via setjmp()/longjmp() but this does not work
+   universally.
+
+ o As defined by the UNIX '98 standard, the only way setcontext()
+   could trigger an asychronous context switch is if this function
+   were invoked on the ucontext_t pointer passed as the third argument
+   to a signal handler.  But according to draft 5, XPG6, XBD 2.4.3,
+   setcontext() is not among the set of routines that may be called
+   from a signal handler.
+
+ o If setcontext() were to be used for asynchronous context switches,
+   all kinds of synchronization and re-entrancy issues could arise and
+   these problems have already been solved by real multi-threading
+   libraries (e.g., POSIX threads or Linux threads).
+
+ o Synchronous context switching can be implemented entirely in
+   user-level and less state needs to be saved/restored than for an
+   asynchronous context switch.  It is therefore useful to distinguish
+   between the two types of context switches.  Indeed, some
+   application vendors are known to use setcontext() to implement
+   co-routines on top of normal (heavier-weight) pre-emptable threads.
+
+It should be noted that if someone was dead-bent on using setcontext()
+on the third arg of a signal handler, then IA-64 Linux could support
+this via a special version of sigaction() which arranges that all
+signal handlers start executing in a shim function which takes care of
+saving the preserved registers before calling the real signal handler
+and restoring them afterwards.  In other words, we could provide a
+compatibility layer which would support setcontext() for asynchronous
+context switches.  However, given the arguments above, I don't think
+that makes sense.  setcontext() provides a decent co-routine interface
+and we should just discourage any asynchronous use (which just calls
+for trouble at any rate).
+
+
 
 Answers were given by:
-{UD} Ulrich Drepper, <drepper@cygnus.com>
-{DMT} David Mosberger-Tang, <davidm@AZStarNet.com>
+{UD} Ulrich Drepper, <drepper@redhat.com>
+{DMT} David Mosberger-Tang, <davidm@hpl.hp.com>
 {RM} Roland McGrath, <roland@gnu.org>
 {AJ} Andreas Jaeger, <aj@suse.de>
 {EY} Eric Youngdale, <eric@andante.jic.com>
@@ -1607,10 +1651,10 @@ Answers were given by:
 {MK} Mark Kettenis, <kettenis@phys.uva.nl>
 {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu>
 {TK} Thorsten Kukuk, <kukuk@suse.de>
-{GK} Geoffrey Keating, <geoffk@ozemail.com.au>
+{GK} Geoffrey Keating, <geoffk@redhat.com>
 {HJ} H.J. Lu, <hjl@gnu.org>
 {CG} Cristian Gafton, <gafton@redhat.com>
-{AO} Alexandre Oliva, <oliva@lsd.ic.unicamp.br>
+{AO} Alexandre Oliva, <aoliva@redhat.com>
 {BH} Bruno Haible, <haible@clisp.cons.org>
 
 Local Variables:
diff --git a/elf/elf.h b/elf/elf.h
index 99503fa..eadded0 100644
--- a/elf/elf.h
+++ b/elf/elf.h
@@ -1117,6 +1117,7 @@ typedef struct
 #define HWCAP_SPARC_SWAP	4
 #define HWCAP_SPARC_MULDIV	8
 #define HWCAP_SPARC_V9		16	/* The cpu is v9, so v8plus is ok.  */
+#define HWCAP_SPARC_ULTRA3	32
 
 /* MIPS R3000 specific definitions.  */
 
diff --git a/sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h b/sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h
index 39cb841..61d9d8c 100644
--- a/sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h
+++ b/sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h
@@ -27,9 +27,9 @@
    is still ok with the given array size.  */
 static const char sparc32_cap_flags[][7] =
   {
-    "flush", "stbar", "swap", "muldiv", "v9"
+    "flush", "stbar", "swap", "muldiv", "v9", "ultra3"
   };
-#define _DL_HWCAP_COUNT 5
+#define _DL_HWCAP_COUNT 6
 
 static inline int
 __attribute__ ((unused))
@@ -68,7 +68,7 @@ _dl_string_hwcap (const char *str)
   return -1;
 };
 
-#define HWCAP_IMPORTANT (HWCAP_SPARC_V9)
+#define HWCAP_IMPORTANT (HWCAP_SPARC_V9|HWCAP_SPARC_ULTRA3)
 
 /* There are no different platforms defined.  */
 #define _dl_platform_string(idx) ""
diff --git a/sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h b/sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h
index 5833902..23bfd47 100644
--- a/sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h
+++ b/sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h
@@ -27,9 +27,9 @@
    is still ok with the given array size.  */
 static const char sparc64_cap_flags[][7] =
   {
-    "flush", "stbar", "swap", "muldiv", "v9"
+    "flush", "stbar", "swap", "muldiv", "v9", "ultra3"
   };
-#define _DL_HWCAP_COUNT 5
+#define _DL_HWCAP_COUNT 6
 
 static inline int
 __attribute__ ((unused))
@@ -69,7 +69,7 @@ _dl_string_hwcap (const char *str)
   return -1;
 };
 
-#define HWCAP_IMPORTANT (0)
+#define HWCAP_IMPORTANT (HWCAP_SPARC_ULTRA3)
 
 /* There are no different platforms defined.  */
 #define _dl_platform_string(idx) ""