Re: [MiNT] pexit, pwaitpid and return values

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Fri, 2005-10-28 at 23:15 +0000, Odd Skancke wrote:
> Hi list,
> 
>  I think we have a conflict between pexec(), pexit() and pwait().

Agreed.  Limiting the return value to 8 bits does seem like an ugly
hack.  So, the question now is which method of resolving this is the
most useful since to have a full 16 bit return code, you simply don't
have all the bits.  I think the priority here is compatibility since I
don't think very many programs are looking at the signal return codes
and not many programs will return something that conflicts anyway.  Unix
compatibility can be addressed by expanding the API for new software
since its normally easier to do that.

My suggestion:

Hope the user never uses more than 8 bits, and let things collide, so
you won't actually know if the application returned some 16 bit return
code that looks like a signal causing the exit or not .. the idea is ..
don't return something that looks like a signal! And the OS should allow
a full 16 bit return code if the application says so.  Signal values are
only returned when the process died because of a signal.

Now, to make things easier in the future, it would be nice to get all
the above information in a format that is a bit cleaner, and maybe even
get more information from the kernel!  Expanding the existing functions
is one option, or you can add a new call and deprecate the existing
calls.

Expanding the existing calls wouldn't be possible for Pwait(), but few
people using that call would be interested in detailed information
anyway.  

Now, for Pwait3() and Pwaitpid(), there are two promising features. Both
have a bitmask flag value passed that determine how the call operates,
and they both take a pointer to two LONG values for additional
information to be returned.  The flag value has unused bits!  In fact
only two are currently used.

Bit 0 = don't block waiting, just poll
Bit 1 = return information for stopped processes too

Bits 2-15 are unused and documented that they should be 0, so as long as
these bits are zero, we keep existing functionality.

So ... Make bit 2 = LONG pointer is to an extended structure/array, not
just 2 LONG values.

The new struct can start with the same two usage values that it would
normally give you, and only fill in the rest of the information when bit
2 was set.

At that point, we can add most of the information in the siginfo_t
structure from POSIX.  This structure would ideally have :

LONG user time consumed by child (same as exiting)
LONG system time consumed by child (same as exiting)
WORD PID of signal sender (0 for kernel or a normal exit)
WORD PID of the child
WORD Real UID of the process which signaled the child (0 for kernel or a
normal exit)
WORD Real UID of the process which exited
WORD code - state of the child, one of :
	CLD_EXITED - child called exit, status = exit status
	CLD_KILLED - child killed by signal, status = signal
	CLD_STOPPED - child stopped by signal, status = signal
	CLD_CONTINUED - child continues by signal, status = signal
WORD status - exit code OR signal, as above

That makes a simple structure which can be looked at easily as an array
of 5 longs (20 bytes total).

POSIX also has some additional information we can't use right now, but
might want to include for future use to reserve space for it.  Such as,
the faulting memory reference when a SIGILL, SIGFPE, SIGSEGV, or SIGBUS
kills the child.  Band and fd informtion for SIGPOLL signals, some timer
information, etc.  You could even include the IP and SP when a fault
occurs (might make debugging easier), or whatever else we think might be
useful.  Maybe make the structure 8 LONG values total, and make the last
3 dependant on the signal itself (IP, SP, and fault address for fatal
signals like SIGBUS), but use these values for other purposes if its
SIGPOLL or a TIMER, etc.  This can be expressed in C with Unions if you
like.  Thats 32 bytes for the whole struct/array.

> the upper byte of the 16 bit return code. Seeing as MiNT's pwait()
> implementation never returns the full 16 bit of a processes exit code

This seems like a bug to me, not a fix!

> signal info or just plain return value from process! I think this looks
> impossible with todays binding of pwait().

Yes, and I would say to only use Pwait() when you just want to clean up
zombies and the child processes are your own so you can guarantee there
won't be a conflict.  Restricting the return value to 8 bits for Pwait()
seems silly.

>  Anyone with ideas on this matter? Perhaps a new extended pwait()
> function is needed? As it is now, it is impossible for processes to
> communicate more than a 8 bit signed number except when Pexec modes
> where parent waits for child to finish is used. This is unacceptible. Or
> is there something I have missed?

Extend Pwait3() and Pwaitpid() as above ... it looks like it was just
waiting to be extended.  Applications that want the information can
easily use it and avoid Pwait(), leaving Pwait() as just a
"low-overhead" call to make from a SIGCHLD handler to clean up zombies.