> > The NetBSD version is going to reread things from swap each time,
> > whereas the FreeBSD version will cause other things to be rotated out
> > of the cache the first couple of times.  It's a trade off of whether
> > you want to allow ps(1) to be slow, or have it affect the performance
> > of other programs, and whether or not you want procfs to be required.
> 
> Many other modern systems use /proc for ps.
> Are there reasons NetBSD should not do that?
> 
> I generaly like getting away from any use of the old (crufty)
> trick of opening /dev/kmem or /dev/mem and snooping around.
> The /proc fs alternative seems nice an clean by comparison.

I have several comments on this:

	(1) no matter what you do, you need to keep the current
		interface (or an equivalent one) in place, along with
		99% of the code to dig things out of /dev/mem and
		/dev/kmem. 

	(2) making procfs mandatory adds bloat to the kernel.

	(3) if procfs _doesn't_ grovel through /dev/mem (i.e.,
		if it actually pages in swapped out processes, paged
		out args lists, etc.) then you're going to be paging
		an awful lot of 'useless' (to the system; by virtue of
		the fact that it's been paged out) data in, and also
		paging a lot of 'useful' data out.  If this doesn't
		happen, 'ps' gets no faster.  If it _does_ happen,
		then 'ps' is capable of hoarding system resources.

I'd rather avoid the bloat in the kernel, and also make users of ps
'pay' directly for the I/O's they incur.

It's also not clear to me that the security implications of a 'useful'
procfs (i.e. one that more uids than 0 can access) have been
thorougly investigated.



cgd