From: "Chris Friesen" <cfriesen@nortel.com>
To: Marco <marco.stornelli@gmail.com>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linux Embedded <linux-embedded@vger.kernel.org>,
linux-kernel@vger.kernel.org,
Daniel Walker <dwalker@soe.ucsc.edu>
Subject: Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Date: Wed, 17 Jun 2009 12:32:00 -0600 [thread overview]
Message-ID: <4A3936A0.9050709@nortel.com> (raw)
In-Reply-To: <4A33A7A2.1050608@gmail.com>
Marco wrote:
> This is a second attempt at mainlining Pramfs. The first attempt was
> back in early 2004 by MontaVista. Since then the kernel code has almost
> been completely rewritten. So my first item on the list was porting the
> code on a recent kernel version. After that I added the XIP support.
>
> Now some FAQs:
>
> What is the goal of this filesystem?
>
> Many embedded systems have a block of non-volatile RAM separate from
> normal system memory, i.e. of which the kernel maintains no memory page
> descriptors. For such systems it would be beneficial to mount a
> fast read/write filesystem over this "I/O memory", for storing
> frequently accessed data that must survive system reboots and power
> cycles. An example usage might be system logs under /var/log, or a user
> address book in a cell phone or PDA.
Nice to see something like this submitted to mainline. We use something
similar to provide persistent storage for crash recovery debug data for
boards which don't have local storage.
In many cases kdump can provide good information, but it's not
sufficient for "flight recorder" type data if the kernel gets rebooted
by a hardware mechanism (watchdog, for instance) that doesn't give a
pre-interrupt.
I'm a bit concerned about your PTE modifications on every write
though...we do things like log every exception and scheduler operation
to persistent memory, and I think the overhead of changing the
protection on every write would be a killer. Instead, we make extensive
use of checksums at various different levels so that the recovery app
can determine which data is valid.
Also, I'd like to ensure that direct memory access to the memory area
would be available. There are some things (like the sched/exception
logging mentioned above) where we want to make accesses as fast as possible.
Chris
next prev parent reply other threads:[~2009-06-17 18:32 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-13 13:20 [PATCH 00/14] Pramfs: Persistent and protected ram filesystem Marco
2009-06-13 13:41 ` Daniel Walker
2009-06-13 15:59 ` Jamie Lokier
2009-06-14 7:15 ` Marco
2009-06-14 11:08 ` Artem Bityutskiy
2009-06-15 15:51 ` Bryan Henderson
2009-06-15 17:42 ` Marco
2009-06-14 11:46 ` Jamie Lokier
2009-06-14 16:04 ` Marco
2009-06-16 15:07 ` Jamie Lokier
2009-06-16 19:15 ` Marco
2009-06-24 17:41 ` Jamie Lokier
2009-06-25 6:44 ` Marco Stornelli
2009-06-26 11:30 ` Jamie Lokier
2009-06-26 16:56 ` Marco
2009-06-24 14:21 ` Pavel Machek
2009-06-21 6:40 ` Pavel Machek
2009-06-21 17:34 ` Marco
2009-06-21 20:52 ` Pavel Machek
2009-06-22 6:33 ` Marco Stornelli
2009-06-22 17:20 ` Pavel Machek
2009-06-22 17:31 ` Tim Bird
2009-06-22 17:37 ` Pavel Machek
2009-06-22 18:07 ` Marco
2009-06-22 20:40 ` Henrique de Moraes Holschuh
2009-06-22 20:40 ` Pavel Machek
2009-06-22 21:50 ` Tim Bird
2009-06-22 21:57 ` Pavel Machek
2009-06-22 22:38 ` Pavel Machek
2009-06-22 23:26 ` Chris Friesen
2009-06-23 1:42 ` David VomLehn
2009-06-23 18:07 ` Marco
2009-06-23 18:29 ` Pavel Machek
2009-06-24 17:47 ` Jamie Lokier
2009-06-25 6:32 ` Marco Stornelli
2009-06-22 18:55 ` Tim Bird
2009-06-22 21:02 ` Pavel Machek
2009-06-22 22:02 ` Tim Bird
2009-06-22 18:08 ` Marco
2009-06-15 17:15 ` Tim Bird
2009-06-15 17:44 ` Marco
2009-06-15 17:58 ` Tim Bird
2009-06-17 18:32 ` Chris Friesen [this message]
2009-06-18 6:35 ` Marco Stornelli
[not found] <4a4254e2.09c5660a.109d.46f8@mx.google.com>
2009-06-24 16:49 ` Marco
2009-06-24 17:38 ` Marco
2009-06-24 17:59 ` Pavel Machek
2009-06-25 6:30 ` Marco Stornelli
2009-06-28 8:59 ` Pavel Machek
2009-06-28 16:44 ` Marco Stornelli
2009-06-28 17:33 ` Marco Stornelli
2009-07-09 23:42 ` Pavel Machek
2009-06-24 17:46 ` Pavel Machek
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=4A3936A0.9050709@nortel.com \
--to=cfriesen@nortel.com \
--cc=dwalker@soe.ucsc.edu \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.stornelli@gmail.com \
/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).