Re: [PATCH v8 00/25] Re-use nvram module
On Sun, 30 Dec 2018, I wrote: > > The rationale for the ops struct was that it offers introspection. > > [...] those platforms which need checksum validation always set > byte-at-a-time methods to NULL. > > [...] The NULL methods in the ops struct allow the nvram.c misc device > to avoid inefficient byte-at-a-time accessors where possible, just as > arch/powerpc/kernel/nvram_64.c presently does. > Hopefully my message makes more sense with the tangential irrelevancies removed. I will document these considerations in nvram.h for the next revision. --
Re: [PATCH v8 00/25] Re-use nvram module
On Sun, Dec 30, 2018 at 5:05 AM Finn Thain wrote: > > On Sun, 30 Dec 2018, I wrote: > > > > > 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.) > > The rationale for the ops struct was that it offers introspection. > > It turns out that PPC64 device drivers don't care about byte-at-a-time > accessors and X86 device drivers don't care about checksum validation. > But that only gets us so far. > > We still needed a way to find out whether the arch has provided > byte-at-a-time accessors (i.e. PPC32 and M68K Mac) or byte range accessors > (i.e. PPC64 and those platforms with checksummed NVRAM like X86 and M68K > Atari). > > You can't resolve this question at build time for a multi-platform kernel > binary, so pre-processor tricks don't help. > > Device drivers tend to want to access NVRAM one byte at a time. With this > patch series, those platforms which need checksum validation always set > byte-at-a-time methods to NULL. (Hence the atari_scsi changes in patch 3.) > > The char misc driver is quite different to the usual device drivers, > because the struct file_operations methods always access a byte range. > > The NULL methods in the ops struct allow the nvram.c misc device to avoid > inefficient byte-at-a-time accessors where possible, just as > arch/powerpc/kernel/nvram_64.c presently does. Ok, I see. That sounds absolutely reasonable, so let's stay with the structure as you proposed. Arnd
Re: [PATCH v8 00/25] Re-use nvram module
On Sun, 30 Dec 2018, I wrote: > > 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.) The rationale for the ops struct was that it offers introspection. It turns out that PPC64 device drivers don't care about byte-at-a-time accessors and X86 device drivers don't care about checksum validation. But that only gets us so far. We still needed a way to find out whether the arch has provided byte-at-a-time accessors (i.e. PPC32 and M68K Mac) or byte range accessors (i.e. PPC64 and those platforms with checksummed NVRAM like X86 and M68K Atari). You can't resolve this question at build time for a multi-platform kernel binary, so pre-processor tricks don't help. Device drivers tend to want to access NVRAM one byte at a time. With this patch series, those platforms which need checksum validation always set byte-at-a-time methods to NULL. (Hence the atari_scsi changes in patch 3.) The char misc driver is quite different to the usual device drivers, because the struct file_operations methods always access a byte range. The NULL methods in the ops struct allow the nvram.c misc device to avoid inefficient byte-at-a-time accessors where possible, just as arch/powerpc/kernel/nvram_64.c presently does. --
Re: [PATCH v8 00/25] Re-use nvram module
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
>
Re: [PATCH v8 00/25] Re-use nvram module
On Wed, Dec 26, 2018 at 1:43 AM Finn Thain wrote: > This allows for removal of drivers/char/generic_nvram.c as well as some > duplicated code in arch/powerpc/kernel/nvram_64.c. By reducing the number > of /dev/nvram char misc device implementations, the number of bugs and > inconsistencies is also reduced. > > This patch series reduces inconsistencies between PPC32 and PPC64, and > between PPC_PMAC and MAC. A uniform API has benefits for userspace. > For example, some error codes for some ioctl calls become consistent > across PowerPC platforms. The uniform API can potentially benefit > bootloaders that work across different platforms which all have XPRAM > (e.g. Emile). > > I think there are two reasonable merge strategies for this patch series. > The char misc maintainer could take the entire series. Alternatively the > m68k maintainer could take patches 1 thru 14, and after those patches > reach mainline the powerpc maintainer could take 15 thru 25 (even though > patch 21 is not powerpc-related). 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. 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. Arnd
[PATCH v8 00/25] Re-use nvram module
The generic NVRAM module, drivers/char/generic_nvram.c, implements a
/dev/nvram misc device. This module is used only by 32-bit PowerPC
platforms. Unfortunately, it isn't generic enough to be more widely used.
The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a
/dev/nvram misc device. This module is now used only by x86 and m68k
thanks to commit 3ba9faedc180 ("char: nvram: disable on ARM").
The "generic" module cannot be used by x86 or m68k platforms because it
cannot co-exist with the "CMOS" module. One reason for that is the
CONFIG_GENERIC_NVRAM kludge in drivers/char/Makefile. Another reason is
that automatically loading the appropriate module would be impossible
because only one module can provide the 'char-major-10-144' alias.
A multi-platform kernel binary needs a single generic module. With this
patch series, drivers/char/nvram.c becomes more generic and some
arch-specific code gets moved under arch/. The 'nvram' module is then
usable by all m68k, powerpc and x86 platforms.
This allows for removal of drivers/char/generic_nvram.c as well as some
duplicated code in arch/powerpc/kernel/nvram_64.c. By reducing the number
of /dev/nvram char misc device implementations, the number of bugs and
inconsistencies is also reduced.
This patch series reduces inconsistencies between PPC32 and PPC64, and
between PPC_PMAC and MAC. A uniform API has benefits for userspace.
For example, some error codes for some ioctl calls become consistent
across PowerPC platforms. The uniform API can potentially benefit
bootloaders that work across different platforms which all have XPRAM
(e.g. Emile).
I think there are two reasonable merge strategies for this patch series.
The char misc maintainer could take the entire series. Alternatively the
m68k maintainer could take patches 1 thru 14, and after those patches
reach mainline the powerpc maintainer could take 15 thru 25 (even though
patch 21 is not powerpc-related).
This patch series has been tested on m68k, powerpc32, powerpc64 and x86.
The nvram and thinkpad_acpi modules were regression tested on a ThinkPad
T43. The /dev/nvram functionality was also regression tested on a G3
PowerMac. The nvram module was also tested on a variety of m68k Macs
and an Atari Falcon. The PPC64 changes were tested on a G5 PowerMac.
AFAIK, there's been no testing on pSeries or CHRP as yet.
Changed since v7:
- Rebased.
- Dropped patch 9/26, "char/nvram: Use generic fixed_size_llseek()"
because generic_file_llseek_size() was adopted in commit b808b1d632f6.
- Reordered the m68k and powerpc patches to simplify the merge strategy.
- Addressed some trivial checkpatch.pl complaints.
- Improved some commit log entries.
- Changed the CONFIG_NVRAM default to better approximate the present code.
In particular, the CONFIG_GENERIC_NVRAM default and use of "select NVRAM".
- Added more tested-by tags.
For older change logs, please refer to,
https://lore.kernel.org/lkml/20151101104202.301856...@telegraphics.com.au/
Finn Thain (25):
scsi/atari_scsi: Don't select CONFIG_NVRAM
m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
m68k/atari: Replace nvram_{read,write}_byte with arch_nvram_ops
char/nvram: Re-order functions to remove forward declarations and
#ifdefs
char/nvram: Adopt arch_nvram_ops
x86/thinkpad_acpi: Use arch_nvram_ops methods instead of
nvram_read_byte() and nvram_write_byte()
char/nvram: Allow the set_checksum and initialize ioctls to be omitted
char/nvram: Implement NVRAM read/write methods
m68k/atari: Implement arch_nvram_ops methods and enable
CONFIG_HAVE_ARCH_NVRAM_OPS
m68k/mac: Adopt naming and calling conventions for PRAM routines
m68k/mac: Use macros for RTC accesses not magic numbers
m68k/mac: Fix PRAM accessors
m68k: Dispatch nvram_ops calls to Atari or Mac functions
char/nvram: Add "devname:nvram" module alias
powerpc: Clean up nvram includes
powerpc: Add missing ppc_md.nvram_size for CHRP and PowerMac
powerpc: Implement arch_nvram_ops.get_size() and remove old nvram_*
exports
powerpc: Implement nvram sync ioctl
powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 &&
CONFIG_PPC_PMAC && CONFIG_NVRAM
powerpc, fbdev: Use arch_nvram_ops methods instead of
nvram_read_byte() and nvram_write_byte()
nvram: Drop nvram_* symbol exports and prototypes
powerpc: Remove CONFIG_GENERIC_NVRAM and adopt
CONFIG_HAVE_ARCH_NVRAM_OPS
char/generic_nvram: Remove as unused
powerpc: Adopt nvram module for PPC64
powerpc: Remove pmac_xpram_{read,write} functions
arch/m68k/Kconfig | 3 +
arch/m68k/Kconfig.machine | 2 +
arch/m68k/atari/Makefile | 2 +
arch/m68k/atari/nvram.c| 279
arch/m68k/include/asm/atarihw.h| 6 +
arch/m68k/include/asm/macintosh.h | 4 +
arch/m68k/kernel/setup_mm.c| 100 ++-
arch/m68k/mac/misc.c | 174
