Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!mmdf
From: laverman@cs.rug.nl (Bert Laverman)
Newsgroups: comp.os.minix
Subject: (1) More than 16 signals, (2) c68
Message-ID: <37718@nigel.ee.udel.edu>
Date: 30 Nov 90 16:41:45 GMT
Sender: mmdf@ee.udel.edu
Lines: 48

Dear all,

(1) Recently I started hacking on Minix ST 1.5.10[.3]. What I wanted looked
    simple: To add SIGCHLD. This signal is extremely simple to integrate
    - I thought :-( - because the default action for it is ignore. This
    means that any process not knowing about there being a SIGCHLD, simply
    never notices it's existance. SIGCHLD should be sent to a process' parent
    if - and only if - that parent wants it to be caught AND the parent
    is not blocked in a wait(2) call. Sounds simple, doesn't it.
    What I didn't realise was the significance of the fact that up to now
    there were only 16 signals implemented... (The number 16 is going
    to keep hunting us for some time I'm afraid) Indeed several parts
    of the kernel and Memory Manager use this to pack signal sets in an
    unsigned short.
    Anyway, I tried to locate them. First the MM. That was simple: the process
    record needs two longs in stead of unshorts, and there were some variables.
    Result: the first dying child causes death to cascade to it's parent, and
            the execution of /etc/rc ends premature. It does end up in login
            however, but the first command you try to start bring us back
            to login. :-(
    Ok, my fault. I checked kernel/proc.h and found p_pending. proc.h warns
    about the assembly parts, but for the ST there is no sconfig.h. I couldn't
    find any references to fields beyond p_pending, nor a reference to the
    length of a record, so I let stmpx.s be.
    Result: totally zilch! printf's in mm and kernel show that any process
            with pid >= 3 gets a SIGSTKFLT. more printf's show that the kernel
            doesn't seem to be hallucinating.
    ** My question: how in the name of zvwgz can a user process run out of it's
                    stack because of changes in the kernel/mm. Remember that
                    it not knowing about SIGCHLD should be no problem...
(2) Happily I saved the new binary of c68. But appearently there were some
    library files included in the patch_4 posting. Could somebody email me a
    copy of that posting? (don't bother with the binary of c68 that came with
    it, just the other stuff)

Bert Laverman

/-------------------------------------------------------------\
| Disclaimer: Don't blame my Boss,                            |
|             He doesn't know what I'm saying either.         |
+----------------------------+--------------------------------+
|                            | laverman@cs.rug.nl             |
| The IBM-PC:                | Bert Laverman                  |
|                            | Dept. of Computing Science     |
| A mistaken standard,       | National Univ. of Groningen    |
| or a standardized mistake? | P.O.Box 800, 9700 AV Groningen |
|                            | The Netherlands                |
\----------------------------+--------------------------------/