Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels- Question regarding...

[Arnd Bergmann]

On Dinsdag 11 Oktober 2005 09:09, spereira wrote:
> If I have understood correctly the following would be the changes I
> would have to make in the kernel...Please correct me if I am wrong.
> 
> It seems to me step (d) would be as you say a little tricky but I
> could attempt it
> depending on the amount of time I have in the project I am on at the moment.
> Proposed modifications...
> a) Struct file_operations(include/linux/fs.h) has a compat_ioctl hook for file
> ioctls. Include a compat_proto_ioctl hook in proto_ops(include/net.h) for
> modular socket ioctls.

Yes, but the hook would be called 'compat_ioctl' by convention, not
'compat_proto_ioctl'.

> b) socket.c has a 'file_operations' type struct socket_file_ops where the
> .compat_ioctl member is currently not used. Define compat_sock_ioctl in
> socket.c and assign to .compat_ioctl member of socket_file_ops
> This is ifdef'd with CONFIG_COMPAT

Yes
 
> c) compat_sock_ioctl will by default call the protocol's ioctl
>  currently supporting the socket interface when handling modular
>  socket ioctls, like so. socket->ops->compat_proto_ioctl(...)
> which in this case is x25_compat_ioctl.

Yes, and return -ENOIOCTLCMD if there is no socket->ops->compat_ioctl()
handler installed. That will cause the current mechanism to be used as
a fallback.

> d)If compat_sock_ioctl has to perform a function similar to
> sock_ioctl(socket.c)
> where in SIOC* commands are handled, then introduce a newly defined
> compat_dev_ioctl that would have stuff like dev_ifsioc that would have
> previously
> been removed from fs/compat_ioctl.c.
> Then the protocol's ioctl (called by default in the step c above) would itself
> default to compat_dev_ioctl ensuring other socket layer
> ioctls are handled by the device layer function, compat_dev_ioctl

I realized that it's even more complicated than this. For the ipv4 and ipv6
protocols, there is also an ioctl operation in struct proto, not only one
in struct proto_ops, so that one would also need a compat_ioctl that can
be called from inet{,6}_ioctl in the default path before calling dev_ioctl.
Similarly, the struct net_device contains a do_ioctl method that would
need a new compat_do_ioctl companion.

Maybe you can leave the current dev_ifsioc in place for now (though
I believe it should go away eventually) and just put the infrastructure in
place to have compat_ioctl functions in struct proto_ops, struct proto and 
struct net_device that are called when !NULL or otherwise return -ENOIOCTLCMD.

	Arnd <><
-
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/