Re: [PATCH] macros to detect existance of unlocked_ioctl andioctl_compat

[David S. Miller]

On Thu, 6 Jan 2005 20:51:44 +0100
Andi Kleen <ak@xxxxxxx> wrote:

> DaveM can probably give you more details since he tried unsucessfully
> to make it work. I think the problem is that there is no enough
> information for the compat layer to convert everything.

When the usbfs async stuff writes back the status, we are no
longer within the original syscall/ioctl execution any more,
therefore we don't know if we're doing this for a compat task
or not.

Technically we could create a "is_compat_task()" type thing
to check but Andi has always been against that and he's given
good reasons.  I tend to agree with him, especially in that there
are valid cases where a compat task might want to make 64-bit
system calls (f.e. to support 64-bit process debugging from
a 32-bit binary, and this is not fantasy as sparc64 could support
this right now)

As mentioned in the code comment, there are also memory management
issues.  We can cons up a temporary kernel buffer in order to
convert the 32-bit structs into 64-bit ones the usbfs code
expects, but then we have the issue of whether we can keep that
buffer around during the entirety of the async operation and
if so who in the world will free it up and how will they know
to do so?

Finally there are complications wrt. using a kernel buffer in that
we have to thus use set_fs(KERNEL_DS) in order for kernel buffers
to be passed into the usbfs routine translated.  This means that
user space accesses of the actual user buffers wouldn't work, and
we thus need to use temporary kernel buffers for that as well.
This is also incompatible with the async nature of how usbfs wants
to work.

I would suggest something that had a fixed sized and fixed layout
status block.  Something that doesn't change layout or size on any
platform.

It's the pointers all over the place in the usbfs ioctl commands
that causes all of the problems.  If you split things up into,
say, user buffer pointer/len struct and status block struct, it might
be a lot easier to support this stuff.  But I'm even skeptical about
this working.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/