From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Date: Wed, 13 May 2020 11:45:39 -0700 Subject: [Ocfs2-devel] remove kernel_setsockopt and kernel_getsockopt In-Reply-To: <20200513062649.2100053-1-hch@lst.de> References: <20200513062649.2100053-1-hch@lst.de> Message-ID: <2c9a28f7-4268-2295-0d64-ada9178a5553@grimberg.me> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Christoph Hellwig , "David S. Miller" , Jakub Kicinski Cc: Marcelo Ricardo Leitner , Eric Dumazet , linux-nvme@lists.infradead.org, linux-sctp@vger.kernel.org, target-devel@vger.kernel.org, linux-afs@lists.infradead.org, drbd-dev@lists.linbit.com, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, linux-rdma@vger.kernel.org, cluster-devel@redhat.com, Alexey Kuznetsov , linux-block@vger.kernel.org, ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org, Neil Horman , Hideaki YOSHIFUJI , netdev@vger.kernel.org, Vlad Yasevich , linux-kernel@vger.kernel.org, Jon Maloy , Ying Xue , ocfs2-devel@oss.oracle.com > 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 - counter to that a few kernel > drivers just set the fields directly already. > > Nevertheless the diffstat looks quite promising: > > 42 files changed, 721 insertions(+), 799 deletions(-) For the nvme-tcp bits, Acked-by: Sagi Grimberg