Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4879263ybi; Tue, 30 Jul 2019 09:42:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqw4AHTu/YW4Ec1BmiIZT9Erur7YDYarXCtLkjaFgHKlufNcs+6tzmqyFVR6bndLJa0BQU6h X-Received: by 2002:a65:5c02:: with SMTP id u2mr40184486pgr.367.1564504953729; Tue, 30 Jul 2019 09:42:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564504953; cv=none; d=google.com; s=arc-20160816; b=QcN4YOWxcKTRCuyIjywgwdjClX2Gj5FCMdMnraXwFTi7/Sk1eIdBVRfbtf4SGN9UI1 7TjuJzVIYaRxUoOTuP9igCJnlTR8XUETG7Bd1gZ8iAXPXkGaK9EWUwZUdaUEH2u07dCk fWJaVtBRWONX3CwEigr/xU+81bKAJiZ06Cdg0bSYvR1/fDjm468zhPKPtXX5qpELtyX0 qu4wLaoOK4Y4q4uKarIY8rJw/CfLJGp7QlleKWhyWp5xFXFhBUUFRbxAnKp3pU7JXtBi Wm89reGLKquzc8bWufQ8mToABOmmrt+kzv8QZ28zlcYOy2xFQhWEOaeQLTw/sq0rmhl4 JQNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Ao1z5H8kGUB+aVWWjs2vE59k2IzF1LJSMEmwtNfI8M4=; b=o94QEy+/FKH+0CH7QvqHhnmFINOwPJxQCExhBIvALwUsDXOELbg7yeRNpxKWbIvu/g fY5FY8BXL06Bqxvr9tIMe0P184Uesfaqkc0qUDEVcExQZW/UgMukBeJQfGiFncX3OKvC 8sNE8gawuU/v+7qNbtdlORAA1LR3gAEMcRHkxA0pV5Xm277SBt/K90/XwqG91FLf7YRa EqVZrGRORHJYfd0NarblGygkZL1CzlW7tr1DaYeUtoCXhMGKjQZUUJb5/0YaOOiPi0PX odFO3kq746bN12xWvLH422D4iQOmeyq0r3/TJ2B/8D8zVNVvpojCMXGyo//0rhwOobwT uiKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x2si29294389pfi.163.2019.07.30.09.42.19; Tue, 30 Jul 2019 09:42:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732645AbfG3PvX (ORCPT + 99 others); Tue, 30 Jul 2019 11:51:23 -0400 Received: from fieldses.org ([173.255.197.46]:41508 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbfG3PvX (ORCPT ); Tue, 30 Jul 2019 11:51:23 -0400 Received: by fieldses.org (Postfix, from userid 2815) id A51082010; Tue, 30 Jul 2019 11:51:22 -0400 (EDT) Date: Tue, 30 Jul 2019 11:51:22 -0400 From: "J. Bruce Fields" To: Olga Kornievskaia Cc: "J. Bruce Fields" , linux-nfs Subject: Re: [PATCH v4 1/8] NFSD fill-in netloc4 structure Message-ID: <20190730155122.GD31707@fieldses.org> References: <20190708192352.12614-1-olga.kornievskaia@gmail.com> <20190708192352.12614-2-olga.kornievskaia@gmail.com> <20190717211317.GM24608@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, Jul 30, 2019 at 11:48:40AM -0400, Olga Kornievskaia wrote: > Ok I'd like argue for the code to stay as is because > 1. can't move the whole function into addr.c because it created a data > structure (nfs42_netaddr) that rpc knows nothing about > 2. While the nfs42_netaddr->addr is the output of the rpc_sock2uaddr() > but we still need the switch to populate the netid . Also since > rpc_sock2uaddr returns memory than the nfs42_netaddr data structure > needs to change to store pointers (and that's shared with the client). > Thus client and server would need to add other code to free the > created netaddr. > 3. this function as is can be used by the flexfile layout as well > (they also decided not to share code with rpc_sockaddr2uaddr but use > same content). that function also doesn't want the memory to be > allocated. > > Maybe I'm wrong about all of it and it all needs to be re-written to > take dynamic memory. But to use as is I don't want to call it and then > memcpy into existing static buffers and freeing what > rpc_sockaddr2uaddr has allocated. OK, that's fine. --b.