linux-kernel - Re: [PATCH v8 00/25] Re-use nvram module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 29 Dec 2018 23:45:36 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Finn Thain <fthain@...egraphics.com.au>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v8 00/25] Re-use nvram module

On Wed, Dec 26, 2018 at 1:43 AM Finn Thain <fthain@...egraphics.com.au> 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