> > Solutions:
> > ----------
> > sys___sysctl can probably use a kernel buffer for the (hopefully few) 
> > occasions
> > where copying is not allowed to block. (And copyout from the kernel buffer
> > when it is save to do so)
> > ( I assume this is the reason for the wiring but was too lazy to verify ) 
> 
> At least for the sysctl case, we could be talking about a reasonably
> significant chunk of memory here - ps's fetching of the process table
> comes to mind.  On my home server, this is 225 processes * 608 bytes
> = 136kB right now.  It seems silly to malloc all that when the user
> program has that storage available too.

sysctl kern.proc has the process table write lock held, so must not block.

It is possible to enumerate the process table without disabling pre-emption
(which is why sysctl for ps has to lock down the user memory).
You would (probably) want to block fork and exit in order to get a
consistent view [1].

It is also (now) possible to implement a kern.nextproc.$$ which would
return the ps info for the 'next' process after the given pid (even if
that process had died), and to guarantee to get all the processes that
existed at the start of the enumeration and were still alive at the end.

The other part of sysctl that is locking a kernel structure is the code
to get the file table.  Replace the linked list through the file structures
(only used by sysctl) by a 'sysctl pass id' and you could enumerate those
from the process list.  Since this data is always stale, it is probably
less important that it be a snapshot.

	David

[1] otherwise a process could 'hide' by calling 'if (fork() > 0) exit(0);'
in a loop.

-- 
David Laight: david@l8s.co.uk