laverman@cs.rug.nl (Bert Laverman) (12/10/90)
I posted about this problem recently, but nobody seems to be knowledgeble on this. Still, with so many people working on Minix, I find it hard to believe I'm the only one thinking about it. I'll rephrase the question. Please ANYONE working - in past or present - on this: MAIL ME. Currently Minix ST 1.5.10[.3] (and no doubt all other versions) knows about 16 (remember this number) signals. I won't repeat their names here, but you can find them in <signal.h>. Also listed there are: SIGCHLD - sent to the parent of a dead child (if catching it) SIGCONT - Causes a STOPped process to resume. SIGSTOP - Causes a process to STOP. (Cannot be caught or ignored) SIGTSTP - The same, but given from the keyboard. (E.g. with ^Z) SIGTTIN - The same, but sent when it tries to read from it's parent's tty. "Stopped for tty input". (maybe bad phrasing) SIGTTOU - "Stopped for tty output". All but the last two should be rather easy to implement. STOPped processes are already used for tracing, so destilling the pure STOP code from the trace code seems like the biggest problem here. After that, the next step is waitpid(2), and then clam(1) can do job-control... Anyway, I tried to implement SIGCHLD ... and ran into short integers :-( Because Minix started out with 16 signals, sets of signals were implemented using `unshort'. To my deepest regret the builders of 1.5.10 did not make the (seemingly trivial) extension to unsigned long. One might say `well, maybe there still was no need for more signals', but why then POSIXify the headers? Those header files contain lot's of declarations that end up in thin air! I don't mind thinking ahead, but by jove (or some other available godhead) then please DO think ahead! <signal.h> defines `sigset_t' as unsigned short. The Minix source uses... unshort, as defined in <minix/type.h>! As a result, trying to overcome this problem becomes a ghosthunt. I thought I had them all, but currently my changes in kernel and mm manage to convince the kernel that all user processes outgrow their stacks. This rather sounds like a problem in the process record definition, but I can't find it. The assembly parts don't use the changed part of the record, and the C parts have proc.h. So why doesn't it work? Pretty well please, Anyone with experience on this problem: spare me a hint gov? 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 | \----------------------------+--------------------------------/
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (12/11/90)
I think the signal names must be defined in signal.h even if they are not implemented in the OS itself. I am not sure, but I think all those signals need only be present, not implemented.