Re: [MiNT] SIGPWR

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

On Sun, Oct 24, 1999 at 01:55:50PM +0300, Martin-Eric Racine wrote:
> I never bothered checking the Linux signal list, so perhaps you
> can answer something for our common benefit:
> 
> 1) Which signals are different between Linux and MiNT?
>    Any signals that Linux has but MiNT doesn't (or vice versa)?

Surprise, surprise, I have recently compared the lists. ;-)
In the following I assume SIGPWR to be signal number 32 in MiNT.  
Signals that Linux has and MiNT hasn't:

	SIGSTKFLT
	(SIGLOST)
	SIGUNUSED (actually not a signal).

Actually SIGLOST is not official in Linux (commented out in signal.h).  If
it is used it is the same as SIGIO resp. SIGPOLL.

Signals that MiNT has and Linux hasn't are:

	SIGEMT/SIGPRIV (the same in MiNT)
	SIGSYS 	

The numbering matches where it matters (so that "trap 1 2 3 15" will work
in shell scripts).  Both in Linux and MiNT SIGIOT/SIGABRT and
SIGPOLL/SIGIO are the same.
 
> 2) Is there anything that prevents us from switching to the same
>    signal list?  Would it be simply a matter of recompiling utils
>    or would it break compatibility, in regards to documented MiNT
>    errors (e.g. Atari Compendium)?

Signal lists are architecture dependent (in fact the list above is taken
from linux-i386, other platforms for Linux may have different signals with
different numerical values).  Except for the missing SIGPWR I have never
come across any portability problems with MiNT's signal list (and SIGPWR
is honestly speaking a System V signal).

> PS:  I recall your preliminary tests showed SIGPWR could safely
> replace SIGSYS (or whichever signal it was), but my question is
> really, how far can we safely go into using the Linux list?

You have answered that yourself a while ago.  You cannot just remap
signals.  If you change something you have to take care.  Signals have
certain properties:

- Which is the default action for that signal?  Will it terminate the
process? Will it cause a core dump (generally true for program errors)?
Will it stop the process?  Or is the default simply to ignore it?

- Can the signal be blocked or ignored? Not true for SIGKILL, SIGSTOP.

If you simply change the name (SIGSYS is now called SIGPWR) then this will
probably cause no problems although in that particular case: SIGSYS should
actually dump core whereas SIGPWR shouldn't.  But MiNT knows no core
dumps...

Another aspect is that the kernel will print out a message when certain
fatal signals are not handled by the program, more or less a
mini-coredump.  Basically applications and the kernel should therefore
have the same notion of the signals in use.

Anyway, with regard to signals, MiNT is already very standard, no need to
change IMHO.  SIGSTKFLT would be nice but it probably never gets raised
since there is no detection of a stack overflow.

If we really think some day that we need more signals we can still define
a 64 bit interface to the signal handling and we have another 32 slots.
Old programs that do not know these signals will then be happy with the
default action.  I see no big compatibility problems with that.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:gufl0000@stud.uni-sb.de