Subject: Re: CVS commit: xsrc/xfree/xc/programs/xterm
To: Christos Zoulas <christos@zoulas.com>
From: Robert Elz <kre@munnari.OZ.AU>
List: current-users
Date: 09/17/2002 21:43:50
Date: Tue, 17 Sep 2002 09:45:15 -0400
From: christos@zoulas.com (Christos Zoulas)
Message-ID: <20020917134515.CB3347E04@beowulf.gw.com>
| Yes, it is not right, but there is no other way to test for the
| feature short of autoconf like methods.
Yes... that's something that perhaps should be fixed. Not only is there
no way to test, there's currently no rational way to find out which
userland version is installed, that I know of anyway (I tend to resort
to the change time of some file that is unlikely to have changed since,
and a guess based upon what was current about then).
Something similar to the __NetBSD_Version__ value from <sys/param.h>
that related to the userland setup, though perhaps it could be more of
a <featuretest.h> or something, with individual defines that relate to
userland interface changes, as one number to describe userland wouldn't
work very well. Perhaps <feature/xxxx.h> so individual features don't
have to step all over one include file, and parts of userland can be
incrementally updated without ordering constraints.
| I am just trying to provide
| a good temporal correlation of when the feature appeared.
Understood.
| Running
| a 1.6F kernel on a 1.5ZC userland will still work as long as you
| don't make your <sys/..> match your 1.6F kernel.
Unfortunately, the "as long as" is often not practical. There are (still)
enough userland processes that depend upon kernel internals, and may need
to be recompiled after a kernel update, that I generally just do
"make includes" in sys as soon as I have verified that the new kernel
functions (I don't typically recompile userland tools unless they start
to play up - which reminds me that I have one system running 1.6? with
a 1.5XX userland where netstat can't decode things properly, and I need
to recompile it... But when I notice I need something new, I don't want
that to fail because I forgot to update the kernel includes first, just
a "make && make install" in the utility directory to fix it.
| If you update your
| sys code, then you might as well update the rest of the include
| headers, otherwise other unexpected lossage can happen.
I don't think I've ever been bitten by any lossage of that kind.
Perhaps I've been fortunate - or just never actually let userland
fall that far behind the kernel.
kre