> > One thing I am just now wondering is why struct ioctl_trans defines cmd
> > as an unsigned long instead of just unsigned int. That adds an uneeded
> > bit of space to the array.
>
> Do you think so?
>
> cmd probably could be u32 (since it is ioctl32 after all), but I doubt
> it matters, as two following entries are pointers so it looks to me
> like it is going to be lost by alignment, anyway.
The thing is, on sparc64, these pointers were cast to u32's, so the
struct was only 12 bytes instead of the current 24. Dave's concern is
the doubling of this pretty large array.
What you could do is allow each architecture to define the ioctl_trans
struct, and also macros for acessing and setting each member. That would
probably satisfy this special cases.
> > As for your suggestion, sounds great, but I'll leave it to Pavel :)
>
> First things first, patch probably still breaks all other
> architectures than x86-64 and sparc64....
If you make the change that Dave suggests, it will be fixed :) Even with
this patch, sparc64 is still broken for modules (like alsa and ieee1394)
that register conversions on load.
-- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 22:00:48 EST