From: Christoph Hellwig <hch@lst.de>
To: David Miller <davem@davemloft.net>
Cc: hch@lst.de, kuba@kernel.org, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] ipv6: symbol_get to access a sit symbol
Date: Mon, 18 May 2020 08:30:43 +0200 [thread overview]
Message-ID: <20200518063043.GA19046@lst.de> (raw)
In-Reply-To: <20200516.135548.2079608042651975047.davem@davemloft.net>
On Sat, May 16, 2020 at 01:55:48PM -0700, David Miller wrote:
> From: Christoph Hellwig <hch@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.
next prev parent reply other threads:[~2020-05-18 6:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 14:50 use symbol_get to create the magic ipv4/ipv6 tunnels Christoph Hellwig
2020-05-14 14:50 ` [PATCH 1/4] ipv4: streamline ipmr_new_tunnel Christoph Hellwig
2020-05-14 14:50 ` [PATCH 2/4] ipv4: consolidate the VIFF_TUNNEL handling in ipmr_new_tunnel Christoph Hellwig
2020-05-14 14:51 ` [PATCH 3/4] ipv4: use symbol_get to access ipip symbols Christoph Hellwig
2020-05-14 14:51 ` [PATCH 4/4] ipv6: symbol_get to access a sit symbol Christoph Hellwig
2020-05-15 0:53 ` David Miller
2020-05-15 6:33 ` Christoph Hellwig
2020-05-16 20:55 ` David Miller
2020-05-18 6:30 ` Christoph Hellwig [this message]
2020-05-19 0:36 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200518063043.GA19046@lst.de \
--to=hch@lst.de \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.