[PATCH 05/11] remove sa_siginfo_sa_sigaction from open_issues.

[guy fleury iteriteka]

* open_issues/sa_siginfo_sa_sigaction.mdwn: delete file.
---
 open_issues/sa_siginfo_sa_sigaction.mdwn | 96 ------------------------
 1 file changed, 96 deletions(-)
 delete mode 100644 open_issues/sa_siginfo_sa_sigaction.mdwn

diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn 
b/open_issues/sa_siginfo_sa_sigaction.mdwn
deleted file mode 100644
index 4e1fa84..0000000
--- a/open_issues/sa_siginfo_sa_sigaction.mdwn
+++ /dev/null
@@ -1,96 +0,0 @@
-[[!meta copyright="Copyright ?? 2010, 2011, 2012 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!meta title="SA_SIGINFO, SA_SIGACTION"]]
-
-[[!tag open_issue_glibc]]
-
-Note: SA_SIGINFO has now been implemented by J??r??mie Koenig.  It will be
-uploaded in Debian eglibc 2.13-19.
-
-IRC, #hurd, August / September 2010:
-
-    <giselher> Hy, I came across SA_SIGINFO in cherokee, I have the void 
sighandler(int num) prototype but how do I add the sa_handler field?
-    <pinotree> if SA_SIGACTION is not defined, then you use sa_handler instead 
of sa_sigaction, and not add SA_SIGINFO in the sa_flags
-    <giselher> SA_SIGINFO is not defined
-    <pinotree> s/SA_SIGACTION/SA_SIGINFO/ above, yes
-    <giselher> K
-    <giselher> I am not sure if I fully understand this, there is the  line 
"act.sa_flags = SA_SIGINFO" and how do I have to change that >_>
-    <pinotree> can you paste the source in a pastebin?
-    <giselher> k
-    <giselher> http://archhurd.pastebin.com/N8BCnG6g at line 790
-    <pinotree> something along the lines of 
http://www.archhurd.pastebin.com/tdpcFD5G
-    <pinotree> note that in the handler the siginfo_t parameter is used, which 
cannot be done if SA_SIGINFO is not defined
-    <pinotree> (that code still won't compile, yet)
-    <giselher> btw: is there a reason why SA_SIGINFO is not implemented?
-    <giselher> the guildlines only say "It's not implemented"
-    <azeem> 09:43 < azeem> signal stuff is tricky :-/
-    <azeem> basically it was pending on a complete rewrite by Roland, which 
never occured
-    <youpi> I have an almost complete implementation, just not finished yet
-    <youpi> (only the siginfo part)
-    <azeem> nobody really groked that code for years until youpi showed up, 
but he added partial support AFAIK, not having much time on his hand
-    <azeem> ah, he's here
-    <azeem> :)
-    <giselher> oh, should I just wait ?
-    <youpi> no
-    <giselher> k
-    <youpi> there are OSes which don't have SA_SIGINFO
-    <youpi> just cope with them: use sa_handler instead of sa_sigaction, and 
don't set SA_SIGINFO
-    <youpi> (i.e. replace with 0 in your example)
-    <giselher> ok
-    <youpi> when SA_SIGINFO becomes available, it'll just be used
-
-IRC, freenode, #hurd, 2011-08-20:
-
-    < youpi> erf, tcpwrappers will need si_pid
-    < jkoenig> I could implement it not too far away in the future, we just
-      need a version of msg_sig_post() with a siginfo argument or something.
-    < youpi> I can also see a lot of packages using SA_SIGINFO for no reason...
-    < youpi> (probably copy/pasty code)
-    < youpi>   sa.sa_flags = SA_SIGINFO;
-    < youpi>   sa.sa_handler = parse_config;
-    < youpi> void parse_config(int)
-    < youpi> yay
-    < youpi>     if(siginf->si_signo == SIGXCPU)
-    < youpi>       fprintf(stderr, "Exceeded CPU usage.\n");
-    < youpi> ...
-    < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO
-      they request...
-    < youpi> jkoenig: si_pid should get us almost all actually used coverage
-    < youpi> I've seen only one example using si_errno
-    < jkoenig> ok
-    < youpi> oh, it's actually supported by your patch
-    < youpi> (errno)
-    < jkoenig> but I guess since implementing si_pid will require a new RPC, we
-      might as well plan for the rest
-    < youpi> jkoenig: indeed
-    < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances?
-    < youpi> ok, well, we'll see
-    < pinotree> jkoenig: if it can be of help, boost::unit_test queries various
-      fields of siginfo_t depending on the signal
-    < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting
-      memory on SIGBUS
-    < jkoenig> pinotree, oh ok good to know
-    < pinotree> *faulty
-    < youpi> jkoenig: well, I guess you had checked that the si_addr field is
-      correct in a few simple testcase :)
-    < jkoenig> hmm I think so, yes
-    < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC
-    < youpi> ok
-    < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV
-      depending on the upper bit, or something (I can't quite remember)
-    < jkoenig> but when sigsegv was generated si_addr was right.
-    < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost
-      sources)
-    < pinotree> maybe you can try the unit tests for boost::unit_tests, if any
-      :)
-    < pinotree> (while src/pulsecore/memtrap.c in PA)
-     * pinotree stops doing MrObvious???
-- 
2.20.1