<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - hppa can't handle SIGRTMIN+29" href="https://bugs.freedesktop.org/show_bug.cgi?id=84931#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - hppa can't handle SIGRTMIN+29" href="https://bugs.freedesktop.org/show_bug.cgi?id=84931">bug 84931</a> from <a class="email" href="mailto:lennart@poettering.net" title="Lennart Poettering <lennart@poettering.net>"> Lennart Poettering</a> <pre>(In reply to Mike Gilbert from <a href="show_bug.cgi?id=84931#c2">comment #2</a>) > (In reply to Lennart Poettering from <a href="show_bug.cgi?id=84931#c1">comment #1</a>) > > Hmm, did I get this right? SIGRTMAX-SIGRTMIN is different for Linux on hppa > > than for Linux on all other archs? > > Yes. > > > What's the last SIGRTMIN+n that works on hppa? Or in other words, what is > > SIGRTMAX-SIGRTMIN? If you let me know we'll just skip all signal assignments > > beyond this value on #ifdef __hppa__ > > From the Gentoo bug that Pacho linked, it seems that SIGRTMIN is 39 on hppa. > I assume SIGRTMAX is still 64, so that would make the difference 25. ok, will ifdef out all the signals beyond SIGRTMIN+25 then. > > Note that the signals we expose are kinda API, hence we cannot dynamically > > assign them. Hence checking things against SIGRTMAX and shifting things > > around is really not a good idea. And normally this wouldn't be a problem as > > on Linux/glibc the number of rt sigs should be stable and fixed. Apparently > > though with the exception of Linux/hppa... > > You are probably familiar, but signal(7) says: > > "... programs should never refer to real-time signals using hard-coded > numbers, but instead should always refer to real-time signals using the > notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n > does not exceed SIGRTMAX." > > Ideally, systemd would just use a smaller range of signals, without gaps. Well, this is supposed to be a fallback interface, in case only "kill" is available. It's a safety net for the admin, not more than that. As such, it matters that the assigned signals are not dynamic, but fixed and documented. Now, I assumed that Linux would always have the same SIGRTMAX-SIGRTMIN, apparently I was wrong. This isn't too bad though, we can just ifdeff out the upper ones, the safety net is then gone on hppa, but given how exotic that platform is it shouldn't really matter.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>