Messages in this thread | | | Date | Sun, 3 Nov 2013 14:43:14 -0500 | From | Theodore Ts'o <> | Subject | Re: Correct parameter size for BLKSSZGET ioctl. |
| |
On Sun, Nov 03, 2013 at 02:07:56PM -0500, Jason Cipriani wrote: > > There was a bigger question hidden behind the context there that I'm > still wondering about: Are these ioctl interfaces specified and > documented somewhere? From what I've seen, and from your response, the > implication is that the kernel source *is* the specification, and not > document exists that the kernel is expected to comply with; is this > the case?
The kernel source is the specification. Some of these ioctl are documented as part of the linux man pages, for which the project home page is here:
https://www.kernel.org/doc/man-pages/
However, these document existing practice; if there is a discrepancy between what is in the kernel has implemented and the Linux man pages, it is the Linux man pages which are buggy and which will be changed. That is man pages are descriptive, not perscriptive.
> Secondly, would it not make sense to change all ints in all public > kernel interfaces to data types with a well-defined, machine- and > (mostly) compiler-independent size, e.g. int32_t (or whatever)? On one > hand, nothing seems particularly broken, per se, but on the other, > "int" is vaguely defined and it is arguably only by chance (albeit a > strong chance) that everything works (e.g. compilers used to build > applications agree with compilers used to build the kernel).
Changing the parameters would result in an ABI change, which would break programs. So in general, it's generally not worth making these changes.
For newer ioctls, in general we'll try to use specifically sized types, mainly so that we don't need to do compat_ioctl handling to support 32-bit binaries on a 64-bit kernel, but in general, it's generally not worth changing existing ioctls. - Ted
| |