Bill Studenmund wrote:

> On Mon, 17 Apr 2000, Simon Burge wrote:
> 
> > Bill Studenmund wrote:
> > 
> > > On Sun, 16 Apr 2000, Simon Burge wrote:
> > 
> > Now that we do many ps's on startup and shutdown with rc.d, having a
> > working ps on -current, no matter how up-to-date userland is, is a good
> > thing.  Also, in theory it should be possible to use a 1.5 ps on a 1.6
> > kernel (untested of course :-) and so on...
> 
> True.. rc.d makes it more important to have them working than in the past.
> 
> Though what's up with the .pid files, as I think greywolf asked about? Why
> even bother with ps if we don't have ot?

I've locally modified /etc/rc so that it does a

	run_rc_script $i faststart

I wonder why this isn't the default?!?

Changing to back to "start" and turning on process accounting in
/etc/rc.d/root showed there were 23 ps's during boot.  The existance or
not of a pid file has nothing to do with whether or not a process is
running, it just helps to check if the process is running.  You can do a
'ps -p <pid>' instead of 'ps | grep <procname>'.

> [[ lots of bits where we actually agreed deleted :-) ]]

> But since we want a backwards compatability system, as the structure
> changes, we're going to need to support more and more versions of the same
> thing. Where should we store that? In a userland library, or in the
> kernel?

Hopefully existing things shouldn't change size too often.  If they
do though, the kernel will have to do it - the userland library would
pre-date the change in the backwards compat case, especially for static
binaries.

> > Hmm, one thing occurs to me - getting a process's argv is very much
> > attached to the current vm machinery.  What would be nice here (and
> > the opposite of what you probably are thinking!) is a nice little
> > kernel interface to return the address in either physmem or swap of a
> > given process' va.  Then kvm_proc.c:kvm_uread() could be as simple as
> > (paraphrasing sysctl):
> > 	
> > 	sysctl(CTL_KERN, KERN_PROC_VA, pid, &type, &offset);
> > 	pread(type == swap ? swapfd : memfd, buf, nbpg, offset);
> 
> Actually, I'd agree with the above. It's small, unlikely to change, and
> the kernel is much more the canonical arbiter of where a process's argv is
> than anything else. :-)

Yup - I'll send a separate message with a summary of the current issues.

> Now that I understand what you're trying to do and not do, I don't think I
> mind it soooo much.

Umm, cool :-)

Simon.