From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E204C433DF for ; Thu, 23 Jul 2020 16:44:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DCA2020714 for ; Thu, 23 Jul 2020 16:44:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728109AbgGWQoi (ORCPT ); Thu, 23 Jul 2020 12:44:38 -0400 Received: from verein.lst.de ([213.95.11.211]:60887 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726621AbgGWQoi (ORCPT ); Thu, 23 Jul 2020 12:44:38 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 8C74368AFE; Thu, 23 Jul 2020 18:44:32 +0200 (CEST) Date: Thu, 23 Jul 2020 18:44:32 +0200 From: Christoph Hellwig To: Eric Dumazet Cc: Christoph Hellwig , "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Alexey Kuznetsov , Hideaki YOSHIFUJI , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , LKML , netdev , bpf , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-sctp@vger.kernel.org, linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org, bridge@lists.linux-foundation.org, linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-decnet-user@lists.sourceforge.net, linux-wpan@vger.kernel.org, linux-s390@vger.kernel.org, mptcp@lists.01.org, lvs-devel@vger.kernel.org, rds-devel@oss.oracle.com, linux-afs@lists.infradead.org, tipc-discussion@lists.sourceforge.net, linux-x25@vger.kernel.org Subject: Re: [PATCH 04/26] net: add a new sockptr_t type Message-ID: <20200723164432.GA20917@lst.de> References: <20200723060908.50081-1-hch@lst.de> <20200723060908.50081-5-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Jul 23, 2020 at 09:40:27AM -0700, Eric Dumazet wrote: > I am not sure why you chose sockptr_t for something that really seems generic. > > Or is it really meant to be exclusive to setsockopt() and/or getsockopt() ? > > If the first user of this had been futex code, we would have used > futexptr_t, I guess. It was originally intended to be generic and called uptr_t, based on me misunderstanding that Linus wanted a file operation for it, which he absolutely didn't and hate with passion. So the plan is to only use it for setsockopt for now, although there are some arguments for also using it in sendmsg/recvmsg. There is no need to use it for getsockopt. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 23 Jul 2020 18:44:32 +0200 From: Christoph Hellwig Message-ID: <20200723164432.GA20917@lst.de> References: <20200723060908.50081-1-hch@lst.de> <20200723060908.50081-5-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Bridge] [PATCH 04/26] net: add a new sockptr_t type List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Dumazet Cc: Alexei Starovoitov , linux-sctp@vger.kernel.org, Christoph Hellwig , linux-s390@vger.kernel.org, rds-devel@oss.oracle.com, Daniel Borkmann , dccp@vger.kernel.org, bridge@lists.linux-foundation.org, linux-afs@lists.infradead.org, lvs-devel@vger.kernel.org, coreteam@netfilter.org, mptcp@lists.01.org, Alexey Kuznetsov , linux-can@vger.kernel.org, Jakub Kicinski , linux-hams@vger.kernel.org, tipc-discussion@lists.sourceforge.net, linux-x25@vger.kernel.org, Hideaki YOSHIFUJI , netdev , linux-decnet-user@lists.sourceforge.net, LKML , linux-bluetooth@vger.kernel.org, netfilter-devel@vger.kernel.org, "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , bpf , linux-wpan@vger.kernel.org, "David S. Miller" On Thu, Jul 23, 2020 at 09:40:27AM -0700, Eric Dumazet wrote: > I am not sure why you chose sockptr_t for something that really seems generic. > > Or is it really meant to be exclusive to setsockopt() and/or getsockopt() ? > > If the first user of this had been futex code, we would have used > futexptr_t, I guess. It was originally intended to be generic and called uptr_t, based on me misunderstanding that Linus wanted a file operation for it, which he absolutely didn't and hate with passion. So the plan is to only use it for setsockopt for now, although there are some arguments for also using it in sendmsg/recvmsg. There is no need to use it for getsockopt. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Thu, 23 Jul 2020 16:44:32 +0000 Subject: Re: [PATCH 04/26] net: add a new sockptr_t type Message-Id: <20200723164432.GA20917@lst.de> List-Id: References: <20200723060908.50081-5-hch@lst.de> In-Reply-To: <20200723060908.50081-5-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: dccp@vger.kernel.org On Thu, Jul 23, 2020 at 09:40:27AM -0700, Eric Dumazet wrote: > I am not sure why you chose sockptr_t for something that really seems generic. > > Or is it really meant to be exclusive to setsockopt() and/or getsockopt() ? > > If the first user of this had been futex code, we would have used > futexptr_t, I guess. It was originally intended to be generic and called uptr_t, based on me misunderstanding that Linus wanted a file operation for it, which he absolutely didn't and hate with passion. So the plan is to only use it for setsockopt for now, although there are some arguments for also using it in sendmsg/recvmsg. There is no need to use it for getsockopt. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 04/26] net: add a new sockptr_t type Date: Thu, 23 Jul 2020 18:44:32 +0200 Message-ID: <20200723164432.GA20917@lst.de> References: <20200723060908.50081-1-hch@lst.de> <20200723060908.50081-5-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from verein.lst.de ([213.95.11.211]:60887 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726621AbgGWQoi (ORCPT ); Thu, 23 Jul 2020 12:44:38 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-can-owner@vger.kernel.org List-ID: To: Eric Dumazet Cc: Christoph Hellwig , "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Alexey Kuznetsov , Hideaki YOSHIFUJI , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , LKML , netdev , bpf , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-sctp@vger.kernel.org, linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org, bridge@lists.linux-foundation.org, linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-decnet-user@lists.sourceforge.net, linux-wpan@vger.kernel.org, linux-s390@vger.ker On Thu, Jul 23, 2020 at 09:40:27AM -0700, Eric Dumazet wrote: > I am not sure why you chose sockptr_t for something that really seems generic. > > Or is it really meant to be exclusive to setsockopt() and/or getsockopt() ? > > If the first user of this had been futex code, we would have used > futexptr_t, I guess. It was originally intended to be generic and called uptr_t, based on me misunderstanding that Linus wanted a file operation for it, which he absolutely didn't and hate with passion. So the plan is to only use it for setsockopt for now, although there are some arguments for also using it in sendmsg/recvmsg. There is no need to use it for getsockopt. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Thu, 23 Jul 2020 16:44:32 +0000 Subject: Re: [PATCH 04/26] net: add a new sockptr_t type Message-Id: <20200723164432.GA20917@lst.de> List-Id: References: <20200723060908.50081-1-hch@lst.de> <20200723060908.50081-5-hch@lst.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Eric Dumazet Cc: Christoph Hellwig , "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Alexey Kuznetsov , Hideaki YOSHIFUJI , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , LKML , netdev , bpf , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-sctp@vger.kernel.org, linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org, bridge@lists.linux-foundation.org, linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-decnet-user@lists.sourceforge.net, linux-wpan@vger.kernel.org, linux-s390@vger.kernel.org, mptcp@lists.01.org, lvs-devel@vger.kernel.org, rds-devel@oss.oracle.com, linux-afs@lists.infradead.org, tipc-discussion@lists.sourceforge.net, linux-x25@vger.kernel.org On Thu, Jul 23, 2020 at 09:40:27AM -0700, Eric Dumazet wrote: > I am not sure why you chose sockptr_t for something that really seems generic. > > Or is it really meant to be exclusive to setsockopt() and/or getsockopt() ? > > If the first user of this had been futex code, we would have used > futexptr_t, I guess. It was originally intended to be generic and called uptr_t, based on me misunderstanding that Linus wanted a file operation for it, which he absolutely didn't and hate with passion. So the plan is to only use it for setsockopt for now, although there are some arguments for also using it in sendmsg/recvmsg. There is no need to use it for getsockopt. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5390500759094401361==" MIME-Version: 1.0 From: Christoph Hellwig To: mptcp at lists.01.org Subject: [MPTCP] Re: [PATCH 04/26] net: add a new sockptr_t type Date: Thu, 23 Jul 2020 18:44:32 +0200 Message-ID: <20200723164432.GA20917@lst.de> In-Reply-To: CANn89iJ3LKth-iWwh0+P3D3RqtDNv4AyXkkzhXr0oSEvE_JoRQ@mail.gmail.com X-Status: X-Keywords: X-UID: 5254 --===============5390500759094401361== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Jul 23, 2020 at 09:40:27AM -0700, Eric Dumazet wrote: > I am not sure why you chose sockptr_t for something that really seems g= eneric. > = > Or is it really meant to be exclusive to setsockopt() and/or getsockopt()= ? > = > If the first user of this had been futex code, we would have used > futexptr_t, I guess. It was originally intended to be generic and called uptr_t, based on me misunderstanding that Linus wanted a file operation for it, which he absolutely didn't and hate with passion. So the plan is to only use it for setsockopt for now, although there are some arguments for also using it in sendmsg/recvmsg. There is no need to use it for getsockopt. --===============5390500759094401361==--