The reason was that a struct loop_info as returned by the kernel
has a different size from what one gets when it is compiled under glibc:
the kernel makes dev_t an unsigned short, while glibc makes it long long.
For the time being this probably means that one has to do
sed 's/dev_t/unsigned short/'
when using kernel include files that will be compiled with glibc.
I expect that the kernel will soon (this year :-)) have a
kdev_t that is a pointer, and a dev_t that is 64 bits.
Then kernel and glibc will agree again on what dev_t means,
but we will have a different problem: structs like loop_info
will have become larger, and old-fashioned programs will crash
when the kernel overwrites more memory than expected when
executing an ioctl.
This means that all relevant ioctl numbers will have to change.
Maybe it would be nice for security if there were a guarantee
about the amount of memory written by the kernel, so that it
would be impossible to crash a well-written application on a
more recent kernel. Perhaps something like
linuxioctl( int ioctl, int *version, int *length, void *data );
Andries