[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200520195509.2215098-1-hch@lst.de>
Date: Wed, 20 May 2020 21:54:36 +0200
From: Christoph Hellwig <hch@....de>
To: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Vlad Yasevich <vyasevich@...il.com>,
Neil Horman <nhorman@...driver.com>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Jon Maloy <jmaloy@...hat.com>,
Ying Xue <ying.xue@...driver.com>, drbd-dev@...ts.linbit.com,
linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-nvme@...ts.infradead.org, target-devel@...r.kernel.org,
linux-afs@...ts.infradead.org, linux-cifs@...r.kernel.org,
cluster-devel@...hat.com, ocfs2-devel@....oracle.com,
netdev@...r.kernel.org, linux-sctp@...r.kernel.org,
ceph-devel@...r.kernel.org, rds-devel@....oracle.com,
linux-nfs@...r.kernel.org
Subject: remove kernel_setsockopt and kernel_getsockopt v2
Hi Dave,
this series removes the kernel_setsockopt and kernel_getsockopt
functions, and instead switches their users to small functions that
implement setting (or in one case getting) a sockopt directly using
a normal kernel function call with type safety and all the other
benefits of not having a function call.
In some cases these functions seem pretty heavy handed as they do
a lock_sock even for just setting a single variable, but this mirrors
the real setsockopt implementation unlike a few drivers that just set
set the fields directly.
Changes since v1:
- use ->getname for sctp sockets in dlm
- add a new ->bind_add struct proto method for dlm/sctp
- switch the ipv6 and remaining sctp helpers to inline function so that
the ipv6 and sctp modules are not pulled in by any module that could
potentially use ipv6 or sctp connections
- remove arguments to various sock_* helpers that are always used with
the same constant arguments
Powered by blists - more mailing lists