lkml.org 
[lkml]   [2013]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2013-11-03 21:01    [W:2.065 / U:1.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site