> > Fixing that would require resgister_ioctl32_conversion() to have 3-rd
> > parameter "this module" and some magic inside fs/compat_ioctl.c,
> > right?
>
> That would do it. I would suggest seperating out the static translation
> handlers and the dynamically registered ones. Now that you're adding
> in module owner info, the translation tables are going to start bloating
> up like crazy.
>
> I'm still upset about going from 32-bit --> 64-bit entries on
> sparc64 :-(
So... Do you think moving common handlers from arch/*/ioctl32.c into
fs/compat_ioctl.c would do the trick?
Pavel
-- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] - 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/