From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by mail19.linbit.com (LINBIT Mail Daemon) with ESMTP id 27D594203E8 for ; Sat, 23 May 2020 09:23:18 +0200 (CEST) Date: Sat, 23 May 2020 09:23:16 +0200 From: Christoph Hellwig To: "David S. Miller" , Jakub Kicinski Message-ID: <20200523072316.GA10575@lst.de> References: <20200520195509.2215098-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200520195509.2215098-1-hch@lst.de> Cc: Marcelo Ricardo Leitner , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.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 , ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org, Neil Horman , Hideaki YOSHIFUJI , netdev@vger.kernel.org, Vlad Yasevich , Eric Dumazet , Jon Maloy , Ying Xue , ocfs2-devel@oss.oracle.com Subject: Re: [Drbd-dev] remove kernel_setsockopt and kernel_getsockopt v2 List-Id: "*Coordination* of development, patches, contributions -- *Questions* \(even to developers\) go to drbd-user, please." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, May 20, 2020 at 09:54:36PM +0200, Christoph Hellwig wrote: > 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. Hi Dave and other maintainers, can you take a look at and potentially merge patches 1-30 while we discuss the sctp refactoring? It would get a nice headstart by removing kernel_getsockopt and most kernel_setsockopt users, and for the next follow on I wouldn't need to spam lots of lists with 30+ patches again.