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