Re: [PATCH] struct loop_info64

[Andries.Brouwer@cwi.nl]

    From: Linus Torvalds <torvalds@transmeta.com>

    We should literally have the rule that any user-visible data structures 
    cannot use _any_ types other than u8/u16/u32/u64 (and _maybe_ the signed 
    ones, if there is any real reason to).

I agree very much with the statement that basic types
that occur in the kernel API should be explicitly given.
Not ino_t or __old_dev_t but int or long.

I agree less with the statement that they must be u32 instead of int.
My main reason is historical: the Unix interface is defined in terms
of char/int/long.

    > +struct loop_info64 {
    > +    int           lo_number;        /* ioctl r/o */
    > +    unsigned long long lo_device;         /* ioctl r/o */
    > +    unsigned long       lo_inode;         /* ioctl r/o */
    > +    unsigned long long lo_rdevice;         /* ioctl r/o */

    Make these be explicitly sized, and try to put the 64-bit members at the 
    beginning to avoid alignment and structure packing problems.

OK - will do.

(So far compatibility was so good that a private copy of the old
definition of struct loop_info could be used where the kernel
expects a struct loop_info64. Making more changes to struct loop_info64
diminishes compatibility, but

    Any reason to keep an "offset" as "int"?

changing the type of offset destroys compatibility anyway.)

Andries