Is anyone working on creating a ram-based storage block device
for linux (not a "ramfs" )?
For example, under Windows CE on the iPaq, you can assign a certain
(by default half) amount of RAM as storage and the other amount as
"Program Memory". When you reset Windows CE, or crash it, the program
files that you loaded in this RAM-based storage are still there.
I assume the iPaq keeps electricity running to the RAM, even during
reboots, and the Window CE kernel most know not to assign this RAM for
memory usage. It seems that the only way it's erased is if you let your
battery die all the way down, or turn the iPaq off using the physical
switch.
So, here's my idea on how to proceed:
(If anyone has ideas/knows the answer to these questions, let me know)
1. Write a pattern to all available memory
Note: Assuming that when a program ends, glibc only frees the memory
to be reused and doesn't clear it.
2. reboot and check to see if the pattern is still in memory anywhere
Note: Assuming that the linux kernel doesn't clear the memory when it
detects/initiallizes it.
3. At this point, I feel that in theory this is possible. If step 1
doesn't work, find another way to do it. seek /dev/mem? If step 2
doesn't work disable the kernel from clearning the memory, look for
adverse effects.
4. Come up with a way for the section of code that detects how much memory
is available to lie to the kernel's mem mngr (linuxargs mem=16M) yet
still tell
the block device where the beginning of it's memory starts. May have to
just map it out statically at 1st, just tell the block device that
memory starts at given location (after 1st 16M) and tell
kernel's memory manager that it only have 16M to work with.
5. Create a RAM-based block device, using z2ram.c, and flash_mem.c as
reference seems to be a start
Ideas? Suggestions? Links to previous work appreciated.
What made me interested in doing this, is when I read that a sector
of flash memory can only be written to 100,000 times. Yikes. Sounds like
a terminal sentence for my iPaq.
-Jared H.
Received on Mon Oct 23 14:32:45 2000
This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:43:44 EDT