From: Michael Ellerman <mpe@ellerman.id.au>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v8 24/25] powerpc: Adopt nvram module for PPC64
Date: Tue, 08 Jan 2019 20:27:27 +1100 [thread overview]
Message-ID: <87h8ejts74.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <alpine.LNX.2.21.1901071533060.30@nippy.intranet>
Finn Thain <fthain@telegraphics.com.au> writes:
> On Mon, 7 Jan 2019, Michael Ellerman wrote:
>
>> Arnd Bergmann <arnd@arndb.de> writes:
>> > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>> >
>> >> +static ssize_t ppc_nvram_get_size(void)
>> >> +{
>> >> + if (ppc_md.nvram_size)
>> >> + return ppc_md.nvram_size();
>> >> + return -ENODEV;
>> >> +}
>> >
>> >> +const struct nvram_ops arch_nvram_ops = {
>> >> + .read = ppc_nvram_read,
>> >> + .write = ppc_nvram_write,
>> >> + .get_size = ppc_nvram_get_size,
>> >> + .sync = ppc_nvram_sync,
>> >> +};
>> >
>> > Coming back to this after my comment on the m68k side, I notice that
>> > there is now a double indirection through function pointers. Have you
>> > considered completely removing the operations from ppc_md instead
>> > by having multiple copies of nvram_ops?
>> >
>> > With the current method, it does seem odd to have a single
>> > per-architecture instance of the exported structure containing
>> > function pointers. This doesn't give us the flexibility of having
>> > multiple copies in the kernel the way that ppc_md does, but it adds
>> > overhead compared to simply exporting the functions directly.
>>
>> Yeah TBH I'm not convinced the arch ops is the best solution.
>>
>> Why can't each arch just implement the required ops functions? On ppc
>> we'd still use ppc_md but that would be a ppc detail.
>>
>> Optional ops are fairly easy to support by providing a default
>> implementation, eg. instead of:
>>
>> + if (arch_nvram_ops.get_size == NULL)
>> + return -ENODEV;
>> +
>> + nvram_size = arch_nvram_ops.get_size();
>> + if (nvram_size < 0)
>> + return nvram_size;
>>
>>
>> We do in some header:
>>
>> #ifndef arch_nvram_get_size
>> static inline int arch_nvram_get_size(void)
>> {
>> return -ENODEV;
>> }
>> #endif
>>
>> And then:
>>
>> nvram_size = arch_nvram_get_size();
>> if (nvram_size < 0)
>> return nvram_size;
>>
>>
>> But I haven't digested the whole series so maybe I'm missing something?
>>
>
> The reason why that doesn't work boils down to introspection. (This was
> mentioned elsewhere in this email thread.) For example, we presently have
> code like this,
>
> ssize_t nvram_get_size(void)
> {
> if (ppc_md.nvram_size)
> return ppc_md.nvram_size();
> return -1;
> }
> EXPORT_SYMBOL(nvram_get_size);
>
> This construction means we get to decide at run-time which of the NVRAM
> functions should be used. (Whereas your example makes a build-time decision.)
Right, but we only need to make a runtime decision on powerpc (right?).
So it seems to me we should isolate that in the powerpc code.
> The purpose of arch_nvram_ops is much the same. That is, it does for m68k
> and x86 what ppc_md already does for ppc32 and ppc64. (And once these
> platforms share an API like this, they can share more driver code, and
> reduce duplicated code.)
> The approach taken in this series was to push the arch_nvram_ops approach
> as far as possible, because by making everything fit into that regime it
> immediately became apparent where architectures and platforms have
> diverged, creating weird inconsistencies like the differences in sync
> ioctl behaviour between ppc32 and ppc64 for core99. (Early revisions of
> this series exposed more issues like bugs and dead code that got addressed
> elsewhere.)
I just don't see the advantage of having arch_nvram_ops which is a
structure of function pointers that are always the same on a given arch,
vs some static inlines that implement the same ops for that arch.
> Problem is, as Arnd pointed out, powerpc doesn't need both kinds of ops
> struct. So I'm rewriting this series in such a way that powerpc doesn't
> have to implement both. This rewrite is going to look totally different
> for powerpc (though not for x86 or m68k) so you might want to wait for me
> to post v9 before spending more time on code review.
OK. I know you've been working on this series for a long time and I
don't want to roadblock it, so at the end of the day I don't feel that
strongly about it as long as the code works.
I'll wait for v9 and have another look then.
cheers
next prev parent reply other threads:[~2019-01-08 9:29 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-26 0:37 [PATCH v8 00/25] Re-use nvram module Finn Thain
2018-12-26 0:37 ` [PATCH v8 24/25] powerpc: Adopt nvram module for PPC64 Finn Thain
2018-12-29 22:36 ` Arnd Bergmann
2018-12-30 3:28 ` Finn Thain
2018-12-31 12:32 ` Arnd Bergmann
2019-01-01 1:38 ` Finn Thain
2019-01-04 8:45 ` Finn Thain
2019-01-06 23:36 ` Michael Ellerman
2019-01-07 4:52 ` Finn Thain
2019-01-08 9:27 ` Michael Ellerman [this message]
2019-01-08 22:51 ` Finn Thain
2018-12-26 0:37 ` [PATCH v8 07/25] char/nvram: Allow the set_checksum and initialize ioctls to be omitted Finn Thain
2018-12-26 0:37 ` [PATCH v8 22/25] powerpc: Remove CONFIG_GENERIC_NVRAM and adopt CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2019-01-03 8:05 ` Christoph Hellwig
2019-01-03 22:11 ` Finn Thain
2018-12-26 0:37 ` [PATCH v8 16/25] powerpc: Add missing ppc_md.nvram_size for CHRP and PowerMac Finn Thain
2018-12-26 0:37 ` [PATCH v8 03/25] m68k/atari: Replace nvram_{read,write}_byte with arch_nvram_ops Finn Thain
2018-12-26 0:37 ` [PATCH v8 11/25] m68k/mac: Use macros for RTC accesses not magic numbers Finn Thain
2018-12-26 0:37 ` [PATCH v8 02/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c Finn Thain
2018-12-28 16:51 ` LEROY Christophe
2018-12-29 1:16 ` Finn Thain
2019-01-02 22:29 ` Finn Thain
2018-12-26 0:37 ` [PATCH v8 21/25] nvram: Drop nvram_* symbol exports and prototypes Finn Thain
2018-12-26 0:37 ` [PATCH v8 14/25] char/nvram: Add "devname:nvram" module alias Finn Thain
2018-12-26 0:37 ` [PATCH v8 08/25] char/nvram: Implement NVRAM read/write methods Finn Thain
2018-12-26 0:37 ` [PATCH v8 15/25] powerpc: Clean up nvram includes Finn Thain
2018-12-26 0:37 ` [PATCH v8 05/25] char/nvram: Adopt arch_nvram_ops Finn Thain
2019-01-03 8:02 ` Christoph Hellwig
2019-01-03 22:08 ` Finn Thain
2019-01-04 17:56 ` Christoph Hellwig
2019-01-04 22:05 ` Finn Thain
2018-12-26 0:37 ` [PATCH v8 25/25] powerpc: Remove pmac_xpram_{read,write} functions Finn Thain
2018-12-26 0:37 ` [PATCH v8 06/25] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2018-12-26 0:37 ` [PATCH v8 12/25] m68k/mac: Fix PRAM accessors Finn Thain
2018-12-26 0:37 ` [PATCH v8 18/25] powerpc: Implement nvram sync ioctl Finn Thain
2018-12-29 22:19 ` Arnd Bergmann
2018-12-30 7:25 ` Finn Thain
2018-12-30 23:13 ` Finn Thain
2018-12-31 12:17 ` Arnd Bergmann
2018-12-31 12:16 ` Arnd Bergmann
2019-01-01 1:06 ` Finn Thain
2019-01-02 22:25 ` Finn Thain
2018-12-26 0:37 ` [PATCH v8 23/25] char/generic_nvram: Remove as unused Finn Thain
2018-12-26 0:37 ` [PATCH v8 10/25] m68k/mac: Adopt naming and calling conventions for PRAM routines Finn Thain
2018-12-26 0:37 ` [PATCH v8 17/25] powerpc: Implement arch_nvram_ops.get_size() and remove old nvram_* exports Finn Thain
2018-12-26 0:37 ` [PATCH v8 09/25] m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2018-12-26 0:37 ` [PATCH v8 04/25] char/nvram: Re-order functions to remove forward declarations and #ifdefs Finn Thain
2018-12-26 0:37 ` [PATCH v8 13/25] m68k: Dispatch nvram_ops calls to Atari or Mac functions Finn Thain
2018-12-29 22:27 ` Arnd Bergmann
2018-12-30 7:26 ` Finn Thain
2018-12-30 17:53 ` LEROY Christophe
2018-12-30 22:12 ` Finn Thain
2018-12-31 12:19 ` Arnd Bergmann
2018-12-26 0:37 ` [PATCH v8 19/25] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 && CONFIG_PPC_PMAC && CONFIG_NVRAM Finn Thain
2018-12-26 0:37 ` [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2018-12-29 17:02 ` LEROY Christophe
2018-12-29 23:43 ` Finn Thain
2018-12-31 12:29 ` Arnd Bergmann
2019-01-01 1:10 ` Finn Thain
2019-01-05 23:06 ` Finn Thain
2018-12-26 0:37 ` [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM Finn Thain
2018-12-28 16:38 ` LEROY Christophe
2018-12-29 1:06 ` Finn Thain
2018-12-29 1:33 ` Michael Schmitz
2018-12-29 2:34 ` Finn Thain
2018-12-29 2:50 ` Michael Schmitz
2018-12-29 21:37 ` Arnd Bergmann
2018-12-30 17:50 ` LEROY Christophe
2018-12-30 18:06 ` James Bottomley
2018-12-30 21:44 ` Finn Thain
2018-12-30 22:45 ` Finn Thain
2018-12-29 16:55 ` LEROY Christophe
2018-12-29 18:54 ` Michael Schmitz
2018-12-29 2:54 ` Michael Schmitz
2018-12-29 22:45 ` [PATCH v8 00/25] Re-use nvram module Arnd Bergmann
2018-12-30 0:09 ` Finn Thain
2018-12-30 4:05 ` Finn Thain
2018-12-31 12:22 ` Arnd Bergmann
2018-12-31 22:54 ` Finn Thain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h8ejts74.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=arnd@arndb.de \
--cc=fthain@telegraphics.com.au \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).