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
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
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
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
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
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
6 matches
Mail list logo
