Subject: Re: ps vs /proc
To: None <current-users@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: current-users
Date: 02/22/2000 13:37:40
>> It did.  f_flags turned into f_oflags, with f_flags changing from a
>> short to a long (thereby growing the struct).
> I checked the sources and the structure size has not changed after
> all.  The old u_short f_flags was really renamed to f_oflags, but
> space for three new 'long' members (f_flags, f_syncwrites,
> f_asyncwrites) were taken from f_spare[] array [...]

...oops.  Sorry for the misinformation.

> So no versioning is needed and old binaries should work just fine.

Interesting.  I wonder why df prints trash, and ps thinks /proc isn't
mounted, then.  I would suspect my private patches (I had one that
changed f_flags to long in-place, which *does* break binary
compatability), but this was a snapshot (=stock) userland and a kernel
built from sources without that patch (because it isn't needed with
these changes to struct statfs; the latest version of my patch tree
doesn't touch that struct).

But it's clearly some sort of version skew; rebuilding df makes it
work right.  (Rebuilding ps doesn't, but that's probably because I
didn't rebuild libkvm...yet.)

If I weren't under more time pressure I'd investigate and find out
what's wrong.  But I need to upgrade to this latest source tree as soon
as workable, and it doesn't help that I have more timesinks than usual
elsewhere in my life right now, so I probably won't.

I still think ps should be less stringent about what it demands of
/proc before it's willing to give it the benefit of the doubt.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B