> No, it's not a hypothetical future; it's a which we've been living in
> some cases. Take a look at serial.h, from Linux 1.2, 2.0, and Linux
> 2.1.latest. An old setserial will compile using the latest serial.h,
> and vice versa --- the latest setserial will work with an 1.2 serial.h,
> thanks to a very carefully designed header file. It might work with
> Linux 1.0 as well, but I don't have Linux 1.0 sources easily around to
> check....
The situation Ted is describing is very much the same as what I have
with autofs.
-hpa
Yes, but why do you say this?
The question is: what should an application do in view of the
changing kernel sources.
My answer is: have a private copy of the kernel include files.
Ted says: if we are disciplined, then things will be OK.
I disagree: we are not disciplined as experience shows,
and even if we were then things would still not be OK.
I'll show a little more below.
But you mention autofs - of which you are the maintainer,
that was introduced in 2.0.31 and never changed in 2.0.*,
and in 2.1.31, changed by you in 2.1.37 and no further
changes happened. Of course, if the kernel includes do
not change then there are no problems.
Problems arise only in dynamic parts of the kernel.
[Nevertheless I expect you'll see problems sooner or later
since <linux/auto_fs.h> includes the notorious <linux/fs.h>.
Also, I wonder what you did in your user-space sources.
When nfs version 3 was introduced I changed nfsmount in
such a way that it could use nfs version 3 when the kernel
present at run time supported it, even if perhaps the
kernel present at compile time did not.
Of course this can only be achieved by not using the kernel includes.]
Now let us look at setserial:
> It might work with Linux 1.0 as well
# make
gcc -O2 -s setserial.c -o setserial
In file included from /usr/include/linux/tty.h:8,
from setserial.c:23:
/usr/include/linux/termios.h:79: warning: `NCCS' redefined
/usr/include/termbits.h:27: warning: this is the location of the previous definition
/usr/include/linux/termios.h:158: warning: `CBAUD' redefined
/usr/include/termbits.h:109: warning: this is the location of the previous definition
/usr/include/linux/termios.h:188: warning: `CIBAUD' redefined
/usr/include/termbits.h:144: warning: this is the location of the previous definition
In file included from /usr/include/linux/fs.h:12,
from setserial.c:21:
/usr/include/linux/types.h:11: warning: redefinition of `ssize_t'
/usr/include/sys/types.h:53: warning: `ssize_t' previously declared here
/usr/include/linux/types.h:16: warning: redefinition of `time_t'
/usr/include/time.h:78: warning: `time_t' previously declared here
...
Hmm. Not a great success.
That was linux 1.0. Linux 1.2 gives similar output.
Let us try 2.0.36.
# make
gcc -O2 -s setserial.c -o setserial
setserial.c: In function `get_serial':
setserial.c:323: `TIOCGSERIAL' undeclared (first use this function)
setserial.c:323: (Each undeclared identifier is reported only once
setserial.c:323: for each function it appears in.)
setserial.c: In function `set_serial':
setserial.c:387: `TIOCGSERIAL' undeclared (first use this function)
setserial.c:464: `TIOCSSERIAL' undeclared (first use this function)
setserial.c:468: `TIOCSERCONFIG' undeclared (first use this function)
setserial.c: In function `do_wild_intr':
setserial.c:516: `TIOCSERSWILD' undeclared (first use this function)
setserial.c:520: `TIOCSERGWILD' undeclared (first use this function)
make: *** [setserial] Error 1
#
Yes - sorry, Ted, this was glibc. With libc5 things are much better.
But one notices two things:
(i) setserial includes <linux/fs.h>, which leads to lots of conflicts.
(ii) setserial needs TIOCGSERIAL, a nonstandard define, and should
include <ioctls.h> these days.
Yes, such is life with the changing kernel includes.
First things were in <linux/termios.h>, now things are in <asm/ioctls.h>,
so one needs #include <ioctls.h>.
Annoying.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/