f> On Mon, 26 Jun 2000, Khimenko Victor wrote:
>> In <Pine.LNX.3.96.1000625204722.14670D-100000@tarot.mentasm.org>
>> ferret@phonewave.net (ferret@phonewave.net) wrote:
f> [snip]
>> > For applications, compiling with the same headers the C library was
>> > compiled with will prevent a possible point of failure.
>>
>> Apllications should NEVER use kernel headers. Period.
f> Specific example: Just before upgrading one of my machines, I wanted to
f> use a USB webcam with my machine. The v4l camera application (I think it
f> was w3cam, but not sure any more) wanted kernel interface to v4l
f> (/usr/include/linux/videodev.h) which of course I did not have. I
f> recompiled libc against a more recent set of headers, but I believe that
f> in turn broke other things that had been compiled previously. nntpcached
f> would no longer bind the NNTP port after this "upgrade"
Specific anwer: your application MUST include all needed info in tarball
(extracted from kernel headers, obviously). Question: what if kernel
interface will chnage ? Answer: if it'll change in incompatible way - blame
kernel developers and ask them to backup changes since it's BUG and should
be fixed. If new "improved and enhanced" interface is added then apllication
should be modified anyway and thus it's not a problem to extract info from
kernel headers one more time.
>> Linus camplained about whole idioticy of direct linux kernels usage in
>> userspace programs.
f> [snip]
>> there should be NO linux (and asm) subdirectories with copies of actual
>> kernel headers (or symlinks to actual kernel headers) in /usr/include
>>
>> Ability to use such system was stated gold of GLibC 2. It's pity that you
>> still can not do this :-(
f> How should this be brought up again?
-
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/