Paul Barton-Davis wrote:
> Oh yeah ? Suppose this changes:
>
> struct rtc_time {
> int tm_sec;
> int tm_min;
> int tm_hour;
> int tm_mday;
> int tm_mon;
> int tm_year;
> int tm_wday;
> int tm_yday;
> int tm_isdst;
> };
>
> #define RTC_ALM_SET _IOW('p', 0x07, struct rtc_time) /* Set alarm time */
>
> What if the ioctl number was altered ?
>
> What if the structure changed size ? (and don't pretend that this
> hasn't happened). The binary may crash, will almost certainly have
> unintended effects, and may even cause an oops, despite the fact that
> is "compiled OK". it compiled OK because it was done with an
> out-of-date header file.
Sure the binary will crash. But even if you use <linux/*.h> header
file, your *old* binaries will crash anyway.
Old user-space binaries aren't supposed to crash.
For this reason, ioctl numbers do not change. And neither do the
structures passed to/from those ioctls.
New ioctls are created which you might want to use. Superceded ones are
deleted. To accomodate this you have to update the application source
anyway. That's the right time to copy the new structures and ioctl
definitions into your application.
> Programs which interact with hardware via device driver ioctl's and
> similar means *MUST* use the current kernel headers, and *MUST* be
> recompiled when those header files change. [...]
Not so. Because drivers do not simply change ioctl numbers or structure
layouts. They add new ioctls with new structures, and, very
occasionally, phase out old ones. Since application binaries break when
old interfaces are deleted, this is normally done after some time has
passed. And as new ioctls are only added when there's actually a new
interface, application source has to be updated to take advantage of
them. Merely recompiling the application doesn't make a difference.
> The idea of using a program that fiddles with the RTC, or any other
> h/w device on my system, but was not compiled for *and* with the
> kernel I am currently using is scary to me.
Don't you ever dual boot?
-- Jamie
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:13 EST