>> The problem is, /proc *does* have a procfs mounted on it.  Is ps
>> perhaps doing a getfsstat to see if a procfs is mounted there?  My
>> kernel/user version skew is large enough that getfsstat() appears to
>> be returning trash.
> Mmm, strange. statfs() or struct statfs didn't change in ages, did it
> ?

It did.  f_flags turned into f_oflags, with f_flags changing from a
short to a long (thereby growing the struct).

> Yes, ps's procfs fallback uses statfs() to be sure it's really
> talking to procfs filesystem.

>> Since the main use of the /proc fallback is dealing with
>> kernel/userland version skew, I submit that this is at best
>> suboptimal behavior; the fallback should be as robust as possible,
>> which in particular means that if it looks even vaguely like a
>> procfs it should be used, even if it seems dubious.
> Is there any other safe way to find out if the filesystem is really
> procfs without using statfs() ?

Does it matter?  Why not use it anyway?  If not having evidence it's a
procfs really bothers you, then print a warning that if it isn't really
a procfs there then the output is meaningless....

Offhand, I'd say that if it has a curproc link that readlink()s to the
current PID in decimal, it's close enough to be worth attempting.

> How old is your userland ?

Anything from before the struct statfs change will do. :)  On the
system I noticed this on, I think most of userland dates from 1.4; I
think my 1999-08-13 source tree has a pre-change struct statfs too.

					der Mouse

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