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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]