The reason for this is that they're different in the kernel. So far it
seems impossible to explain to folks that you can't reliably use both
termio and termios in the same .c file, nor can you pass termio
structs to termios calls and vice versa...No amount of #define fakery
or userlevel code is going to make the problem go away, it needs to be
fixed in the kernel. (Why it was decided to use the same macro names
for both termio and termios is beyond me...and why people mix termio
and termios code is an even greater mystery.)
NB: I may have termio and termios swapped below, because I don't
remember now if the kernel's emulating OSF/1 termio or termios (and
I'm at work so I can't get at my machine.)
The Linux/Alpha kernel currently is emulating the OSF/1 (er, Digital
Unix) termio calls, and also using the standard Linux termios calls.
The values for the VKILL, VERASE, etc. #defines are different in OSF/1
from the traditional Linux termios values.
The standard Linux termio and termios #defines for the common VKILL,
VERASE, etc. defines happen to be the same, so it's possible to
include both termio.h and termios.h in the same file and have
everything work. But, this can't work with the way things currently
are set up in the Linux/Alpha kernel--if you include termio.h, you'll
get the termio #defines. If you then include termios.h, you'll get the
termios #defines, and since they're different from what termio wants,
termio calls will fail.
The fix is to modify the kernel to swap the VKILL, VERASE, etc. array
entries around for the termios calls so they're the same as the OSF/1
termio values. The easiest fix would be to add a new set of ioctl
values for the "fixed" termios calls, so that existing programs would
continue to function while new programs will work "properly".
Otherwise, there will be some existing binaries that will break...
An alternative fix is to intercept the calls in libc and fix things
there, but this fix would be a lot uglier.
Bob