This is just as true for read(2) and write(2).
There's lots more magic numbers (commands) for ioctl than status bits
for read or write, but the underlying problem is fundamentally the same:
gcc needs to be able to compile programs that use these bits.
There's some shortcuts you maybe can take when compiling natively, with
appropriate kernel sources around, but these are shortcuts not portable
solutions.
The proper solution is probably a helper program, supplied with
glibc, which reads the appropriate kernel includes and generates
the corresponding glibc includes. Also, there should be a "linux
kernel version" supplied with these glibc includes which you can test
numerically with #if.
If Linus ever has to break the helper program, well.. that's a fairly
fixable problem (and includes from a previous kernel version can be
used in the mean time).
> And that's a good thing, considering how much trust I currently have in
> the glibc folk's ability to keep a backwards-compatible interface. :-(
Er.. yes, this is a problem. But there have been kernel versions, too,
that would corrupt a hard disk. [Generally, people are advised to
upgrade to a better version.]
-- Raul- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu