On Sat, May 16, 2020 at 01:55:48PM -0700, David Miller wrote: > From: Christoph Hellwig <h...@lst.de> > Date: Fri, 15 May 2020 08:33:24 +0200 > > > My initial plan was to add a ->tunnel_ctl method to the net_device_ops, > > and lift the copy_{to,from}_user for SIOCADDTUNNEL, SIOCCHGTUNNEL, > > SIOCDELTUNNEL and maybe SIOCGETTUNNEL to net/socket.c. But that turned > > out to have two problems: > > > > - first these ioctls names use SIOCDEVPRIVATE range, that can also > > be implemented by other drivers > > - the ip_tunnel_parm struture is only used by the ipv4 tunneling > > drivers (including sit), the "real" ipv6 tunnels use a > > ip6_tnl_parm or ip6_tnl_parm structure instead > > Yes, this is the core of the problem, the user provided data's type > is unknown until we are very deep in the call chains. > > I wonder if there is some clever way to propagate this size value > "up"?
As far as I can tell the only information vectors is the net_device structure or its op vector. But even then we have the problem that other devices use the SIOCDEVPRIVATE range for something else. I'll look into implenenting the tunnel_ctl method just for kernel callers (plus maybe a generic helper for the ioctl), and we'll see if you like that better.