linux-kernel - Re: [PATCH 05/11] android: ram_console: split out persistent ram

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]

Message-ID: <CAMbhsRRDmH47r_s_-H+tnZ62c9HdE3VqeTn5Qp4kwe5EOjJ4jw@mail.gmail.com>
Date:	Wed, 7 Mar 2012 19:06:42 -0800
From:	Colin Cross <ccross@...roid.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	John Stultz <john.stultz@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH 05/11] android: ram_console: split out persistent ram

On Wed, Mar 7, 2012 at 6:42 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Wed, Mar 07, 2012 at 05:34:32PM -0800, John Stultz wrote:
>> From: Colin Cross <ccross@...roid.com>
>>
>> Split ram_console into two halves.
>>
>> persistent_ram is a set of apis that handle a block of memory
>> that does not get erased across a reboot.  It provides functions
>> to fill it as a single buffer or a ring buffer, and to extract
>> the old data after a reboot.  It handles ecc on the data to
>> correct bit errors introduced during reboot.
>
> That's a nice idea, but why are you rolling your own interface here and
> not using the built-in one that the kernel already provides?  Is there
> something lacking with what we have today that requires you to create
> something different?  If so, why not just modify the existing interface
> to make it work for you, that way the tools already created will work
> automatically, and you will not have problems later ripping this out and
> porting it to the in-kernel api.

What interface are you referring to, pstore?  As I explained in the
email John quoted to you, pstore would be a client of this, and
ramconsole could be moved on top of pstore.  This patch is just a
refactoring that splits ramconsole and the persistent storage apart
without significantly changing the api between them, and only makes it
easier to insert pstore between them.  As for tools, we've had tools
that use ram_console since 2008.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/