Messages in this thread | | | Date | Thu, 18 Jun 2009 08:35:35 +0200 | Subject | Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem | From | Marco Stornelli <> |
| |
2009/6/17 Chris Friesen <cfriesen@nortel.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 very happy that this fs has the approval of the kernel community. :)
> > 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. >
It's a trade-off between security and performance. Checksum it's a good way to understand if a data is valid or not (indeed it's used in this fs), but with this schema you can prevent the system to do something wrong. This option, however, can be enabled/disabled via kconfig.
> Also, I'd like to ensure that direct memory access to the memory area > would be available.
What do you exactly mean with this? Can you explain to me a bit deeper?
> There are some things (like the sched/exception logging mentioned above) where we want to make accesses as fast as possible. > > Chris > >
Marco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |