In <199701151910.NAA09252@solutions.solon.com> Peter Seebach <seebs@solon.com> writes:

>I've been fighting this recently.  I have three 680x0 machines.

>My 68040 (the primary builder) works fine.
>My 68030 (also an Amiga), ps works fine, but w gets proc size mismatch.
>My 68020 (Sun 3/60), nothing works.

>I've rebuilt everything many times.  Can anyone help me grok this?

I can't when you really, really typed 'make includes' in /usr/src and
this also installed the include files in /usr/src/sys...

>1.  What is mismatching?  What is the "proc size", and what changes so
>constantly that it mismatches easily?

The size of kinfo_proc (/usr/include/sys/sysctl.h). If there were changes
in the port's vm system it is likely that the vmspace structure changed
for instance.

>2.  What are all of the inputs to this?  What changes that causes a proc
>size to be different?  I have a new kernel, new libc, new libkvm, and
>new ps, all built from the same source, booted off the new kernel, and ps
>doesn't work... (Also a new kvm_mkdb, and new kvm.db.)

The major inputs are include files...

>In the long run, why on earth can ps ever fail?  Shouldn't it be like
>binpatch, which works on executables made years after the original design?
>(At least, it does for me.)  Shouldn't it be able to look up all, not just
>some, of the information?  (Well, obviously not *all*, but I'd think within
>reason...)

Because ps(1) uses data structures from the kernel, it is hard to make
this work for years. We would still have pid's limited to shorts right
now... Binpatch(1) on the other hand 'just' grovels the a.out format
which isn't as dynamically changing as the kernel.

Leo.