Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp9331959imu; Sat, 29 Dec 2018 16:44:49 -0800 (PST) X-Google-Smtp-Source: ALg8bN6mKq8ffakxKpiEdgkMj2OMb+HZ6npFXAVIDZZ9h6cBUlTlewbcROzqIPWNFL4Zadl/LleL X-Received: by 2002:a17:902:298a:: with SMTP id h10mr33048703plb.312.1546130689745; Sat, 29 Dec 2018 16:44:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546130689; cv=none; d=google.com; s=arc-20160816; b=sMSbiJXEelxemzs2ITe8IxUx8btuirQjUcXaoJSq8bhkxJcojNErjnxgpDxVXeXrf7 pqpOuAq0oYGlnse+nB48EEP0+gUyJnhhsbKzI4a1PKrfgRbU5dbMbaLXHFuZfKkpqIpS w3o+2f6DyZY1HNpROUXFmy9c1T/dCci3NW08LULANhmjxp/xKNP1zt46O9TMBbXgn7Cv 7FLqzXbqHWrVsAoUb24Jeu3A8vs2oc4T2lNN2JZ+ITUmnq5+SR1+uP6BVYoMxb3ZhslR plBhbUo/L43vNMrXIVb3S4J6RqwJXWH25anYCR9brJW6yVk7hVttdS8vC8K5oDIWm0em 0Mjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=ZD7XmWWYiK7f4fv/vt+vMSWVReCNqzZRp/zZ/RQP4Mk=; b=wKg5p1Xyt/ANkcga3G/IKBxB+79HLBsR9C8skI5vCysUHpcr01PAWI4Rpjjx2KjXIK fVNMtfvH4bXt56sgDwvMNx2vVW9RQaBBvILcyNaxtWinGt5pL5XWUfDuWFHi94BKf6oI cq6WBljstGBIdZtQkSONocTF83mDQWUEPVUMDK6fJlnM1khLmms7zIbsrvdoTiHiNAXS pcJi+Nkk+A2D7p1UiIBJZCkLltiZ6fovq0k3+Oc5TOuhLi9fL8Jqgj0IMMBJcXtWzmpL 75xSRJXMpQkZHWkEYZpEr4Cvg+liaTcO1+FDqY4BKOomkeC4yVTLrks7Dsjvc7XzS7ry EYkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 j1si22524364plk.342.2018.12.29.16.44.34; Sat, 29 Dec 2018 16:44:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728040AbeL3AIy (ORCPT + 99 others); Sat, 29 Dec 2018 19:08:54 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:47848 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726960AbeL3AIx (ORCPT ); Sat, 29 Dec 2018 19:08:53 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 8F5CC29798; Sat, 29 Dec 2018 19:08:50 -0500 (EST) Date: Sun, 30 Dec 2018 11:09:13 +1100 (AEDT) From: Finn Thain To: Arnd Bergmann cc: Greg Kroah-Hartman , Linux Kernel Mailing List , linux-m68k , linuxppc-dev Subject: Re: [PATCH v8 00/25] Re-use nvram module In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 29 Dec 2018, Arnd Bergmann wrote: > I had a look at the complete series now, and I think this is a great > cleanup. I replied with a couple of minor comments that you may or may > not want to address first. > Thanks for reviewing this. > The one thing I would like to see resolved (I hope this doesn't bring > back an old discussion you had already concluded) is regarding the use > of a global exported structure of function pointers, as opposed to using > either directly exported functions (with a consistent interface) or a > boot-time selectable structure like dma_map_ops or ppc_md. > If I understand correctly, /dev/nvram was made obsolete by the nvmem subsystem (?). If so, there won't be new /dev/nvram users, and the refactoring here only has to be sufficiently flexible to meet the needs of existing users. I'm not opposed to exported functions in place of a singleton ops struct. Other things being equal I'm inclined toward the ops struct, perhaps because I like encapsulation or perhaps because I don't like excess generality. (That design decision was made years ago and I don't remember the reasoning.) All the arch_nvram_ops structs that I've defined in these patches have the 'const' properly: const struct nvram_ops arch_nvram_ops = { .read_byte = nvram_read_byte, .write_byte = nvram_write_byte, .read = nvram_read, .write = nvram_write, .get_size = nvram_get_size, .set_checksum = nvram_set_checksum, .initialize = nvram_initialize, }; EXPORT_SYMBOL(arch_nvram_ops); This is because there's no need to do any run-time reconfiguration. Is a collection of exported functions a better fit here? -- > Arnd >