Re: [MiNT] New signal SIGPWR - Power failure (restart)

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

Hi,

On Fri, Oct 15, 1999 at 01:06:30AM +0200, Thomas Binder wrote:
> Hi!
> 
> On Wed, Oct 13, 1999 at 07:50:13PM +0200, Guido Flohr wrote:
> > I would propose to "sacrifice" SIGSYS ("invalid argument to system call")
> > instead.  This signal is never generated by the kernel and I have never
> > seen it used in source code.
> 
> Erm, have you looked at bios.c, dos.c, slb.c and xbios.c? They all
> contain at least one line "raise(SIGSYS)". I wouldn't call that "never
> generated by the kernel" ;)

Ooops, I haven't seen this.
On the other hand I have never seen this signal really being raised.

> > IMHO the operating system should return EINVAL instead of raising a
> > signal when a wrong argument is given to a system call (and in fact
> > that is what MiNT does).
> 
> Well, it _is_ used, and that's mostly for things were a program tried
> something "nasty", e.g. Supexec() without the necessary priveleges,
> where continuing won't make much sense.

Would it be a problem to raise a SIGPRIV instead?

> > Anybody having problems with re-interpreting SIGSYS as SIGPWR from now
> > on?
> 
> Well, what exactly did you do when trying to use SIGPWR as signal 31?
> Increase NSIG to 32 and add SIGPWR as 31 to signals.h? That alone caused
> the kernel to crash, or what happened?

Yes, and I grepped the sources for "(31|32|NSIG)" and tried to figure out
if adding a new signal would cause problems.  I haven't seen problems but
they came.  The kernel didn't even boot and I couldn't find out why.
Well, finally I got fed up.

So I reformulate my proposal: What about putting SIGSYS and SIGPRIV into
one and replace the old SIGSYS with SIGPWR?  Or is there any other signal
that is not that important?

Ciao

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