Messages in this thread | | | Date | Thu, 06 May 2004 17:49:30 +0200 | From | "Jan Beulich" <> | Subject | Re: sys_ioctl export consolidation |
| |
That's certainly another possibility, putting under question why for certain architectures sys_ioctl gets exported (by inspection I can see a valid reason only for sparc64).
Anyway, I don't have a list of drivers ready, I just ran into the issue because a driver I had to port over from 2.4 worked on all intended architectures but ia64, and I initially intended to go the route you point out until I found that most 64-bit architectures with 32-bit emulation layers actually export the symbol for appearantly this very purpose.
>>> Christoph Hellwig <hch@infradead.org> 06.05.04 16:50:08 >>> On Thu, May 06, 2004 at 01:23:24PM +0200, Jan Beulich wrote: > Since we noted that sys_ioctl is not currently being exported for ia64 > to be used in the 32-bit emulation routines I'd like to suggest the > following patch, which, instead of making this available in another > individual architecture, exports the symbol whenever CONFIG_COMPAT is > defined (legal users should be a subset of > [un]register_ioctl32_conversion users, which is scoped by the same > config option).
Should ioctl32 handlers in drivers really call sys_ioctl? Calling sys_ioctl makes sense for ioctls that are supported by a broad range of drivers, but in that case the ioctl32 translation should be in the core compat code.
Drivers using register_ioctl32_conversion should rather call their own ioctl handlers directly if you ask me.
Do you have a list of drivers currently needing sys_ioctl?
- 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/
| |