Re: Header files and interfaces

Martin Mares (mj@atrey.karlin.mff.cuni.cz)
Tue, 23 Jun 1998 20:16:23 +0200


> There's two ways of dealing with ioctls which are present on only newer
> kernels:
>
> (a) at runtime, deal with the error that occurs when you try to run a
> missing ioctl,
>
> (b) at compile time (or design time) leave out support for such ioctls.
>
> Most of the time (a) is a superior approach (if the ioctl had any value
> at all), however (b) has a rather elegant simplicity.

In some cases, ioctls are being replaced in an incompatible way. This
is for example the case of network firewalling which has changed at least
twice in this way. And in such cases, the includes cannot contain
definitions of all such mechanisms as they are mutually exclusive, but
you occasionally need (well, at least I do) to build programs using
different version of that API to the one you currently run.

> Probably the best approach to (b), though, is documentation which
> includes for each ioctl a bit of its history (when it first appeared,
> historically similar mechanisms).
>
> Also, remember that even if you're not doing any development, and are
> compiling programs only for your personal machine, you may eventually
> upgrade your kernel.

Yes, but then I can either install new headers or run a script which
generates them. But I should be able to do this without rebuilding
or reinstalling (g)libc.

Have a nice fortnight

-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"IBM = Inferior, But Marketable"

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu