On Thu, 2002-04-04 at 05:59, Branden Robinson wrote: > If the kernel revs in such a way as to break > ioctl numbers, there's no userland way around it, is there?
No. On the other hand, this virtually never happens. The kernel people are usually quite disciplined about not making changes that would stop old binaries from working. As far as I know you can still take old a.out executables from 1990 or so and run them under modern kernels without any problems. > Fine and dandy, but what do I do in the meantime? I can guard each of > the ioctl #defines with an #ifndef, but there's also a typedef thrown > into the mix. I can't exactly do this: About the only thing you can do is to discontinue use of the kernel headers altogether and provide your own, unconditional, definitions (with different names if there is any danger that the kernel's version of them might become visible under some conditions). This obviously sucks quite a lot, but less than the alternatives. > If the kernel headers aren't an interface, why do they exist? There > appears to be a very large philosophical gulf here. The fact that > the Linux kernel guys may long for nice low-level C libraries that > encapsulate such things doesn't mean they exist. Is this a > side-effect of some sort of "real men don't program in userspace" > dogma? Pretty much. As far as the kernel people are concerned, their headers exist solely for the kernel's own benefit. They want to be able to make changes to these files without worrying about introducing namespace pollution or anything else that will accidentally break some other random program. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]