bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proc changes for rusage


From: Roland McGrath
Subject: proc changes for rusage
Date: Sun, 5 Aug 2001 15:29:43 -0400 (EDT)

Please test the changes I've just checked into proc.
(If you don't know how to test a changed proc server, then don't try.)

The main thing is to be sure I didn't break anything, which I shouldn't have.
Existing code was changed very little.

The change is that proc_wait (i.e. wait3/wait4) can now return a nonzero
struct rusage.  The values will always be inaccurate (see comments in
proc/wait.c) and can never be relied upon.  But that's not as inaccurate as
always reporting zero, as it did before.

Also this information is tallied in the parent's proc structure to record
the aggregate usage of its dead children.  There is no way to extract the
tallied usage data.  That requires either a new proc RPC or a change of the
proc_getprocinfo data format, so it becomes possible to implement
getrusage(RUSAGE_CHILDREN).

Previously all reports about dead-child usage were consistent: that is, the
two places that can report about dead children are wait[34] and getrusage,
and both always returned zero.  Right now those two will report
contradictory data.  I don't know of any user for which this would be a
(new) problem.

It's also the case that previously things like autoconf checks could notice
that wait[34] always returned zero rusage and accordingly adapt to a system
that doesn't provide that information.  Now, the Hurd provides some
information so such a check will decide the facility is available, but the
information is still not reliable or trustable for security/accounting
purposes.  But I'm not aware of anything in particular that would be
adversely affected by this.


As I noted, the results here are always inaccurate.  For correct results,
we need to add a feature in the microkernel (this has already been
discussed on this list).  I've done these changes now with half-assed data
collection because these changes (plus adding the new RPC and finishing the
getrusage implementation) fill in all other the missing pieces for this
functionality to work.  That is, when the microkernel feature gets added,
we will only have to change proc to use it internally, and then everything
else falls into place without needing any recompilations or anything.


Enjoy,
Roland



reply via email to

[Prev in Thread] Current Thread [Next in Thread]