>As has been reiterated dozens of times already on this list,
>every program that includes <linux/foo.h> is broken or will break
>sooner or later, especially if one compiles them with /usr/include/linux
>pointing at a random kernel source, instead of a carefully selected
>collection of headers that works well with the current libc headers.
And no matter how many times its reiterated, I continue to think that
this is silly. Yes, in general, there are many kernel headers of which
this is true. But there are also several, perhaps even dozens, that
contain information that does NOT belong with libc and DOES have a
place in user-level programs.
>> If the suggestion is that *no* true kernel header should ever be
>> included, but that glibc should come with its own versions of them all:
>> how can this cover h/w-specific resource like the RTC etc. ?
>
>You copy linux/rtc.h to your own private file linux-rtc.h, remove the
>junk you are not interested in, and have a set of sources that compiles
>not only today but also tomorrow, when linux/rtc.h has a different content.
>
>Moreover, the binary obtained by compiling it tomorrow will have the same
>behaviour as the binary obtained today. No sudden obscure crashes of your
>application because some structure element is now declared unsigned.
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.
>Always keep your program source and your kernel source separate
>and independent.
Look, the kernel happens to contains dozens of device drivers which
export their own API via ioctl. To expect that a distribution, or a
programmer, extracts the entire contents of them is crazy. Several
don't have __KERNEL__ in them precisely because they would be more or
less useless - they define the API between the driver and userspace.
If we're talking about sched.h, I fully agree with you. But the ones
covering driver API's are in a different category.
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. Programs that use standard
POSIX/Linux API's don't need to worry about this, because (1) they
don't cause direct manipulation of h/w in a way that doesn't go
through some abstraction in the kernel and (2) the standards don't
change very often.
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.
--p
-
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