GP2X Temporary Files

[RiX0R]

Hey everyone, I have a bit of a dilemma.

I want my menu to store a bit of state in a temporary file, to provide consistent behaviour across launching child apps. Where do you reckon I should best store this state?

The natural candidate seems /tmp, and that's where I'm writing it now. However, this may cause shortened NAND life. Now, this may not be as bad as it sounds, since disk access will be cached in memory to preserve NAND life, so it would not be re-flashed each time the file was ritten.

Another option is storing it on the SD card; this would have the benefit that IF the flash memory got to its maximum amount of duty cycles, it would be more easily replaced than the NAND. It would also mean the files would be visible to the user (which seems ugly to me).

And can someone clue me in on how long we could expect the flash to last? All this talk of "duty cycles" may seem bad, but if we've got a few million of them to burn, there's not really much cause for alarm.

 

[xafier]

I take it I'm not being dumb here, but this temporary file is meant to be stored after the GP2X has been switched off correct so its available when its next switched on?

Personally I would store the config/temporary file on the SD card as I'd avoid the NAND as if I broke someones NAND with my program I'd feel a hell of a lot worse than an SD card problem =\

 

[slygamer]

Avoid writing temporary files to NAND or SD completely. Use some of the upper 32MB of RAM as a shared memory block. Your apps will look at this block and use what is in there. Before they exit, they update the memory block for the next app to use.

Of course, if you run other apps they may trash the memory block, but your code should be able to handle that, e.g. signature bytes, CRCs, etc.

 

[gfoot]

It's a bit dodgy, but if you want to write data that persists until the next reboot, you might be able to put it on /dev. It's a devfs, which is a virtual filesystem used for kernel drivers to provide device nodes automatically, but you can write to it as well. I'm not totally sure how that works, or even whether you're allowed to write files (as opposed to device nodes), but if you are then it would behave effectively like a ramdisk.

Actually I think the kernel may have tmpfs support (based on evidence of abortive attempts at using tmpfs to get variable data off the nand) so you could just mount a tmpfs somewhere and use that.

 

[Squidge]

/dev is for device nodes only, you'll get an error if you try and write a file there.

However, tmpfs is alive and kicking, just as GPH don't bother to use it..

eg.

bash-2.05a# mkdir /fooble
bash-2.05a# mount -t tmpfs fooble /fooble
bash-2.05a# echo Mooose! >/fooble/mytemp
bash-2.05a# df /fooble
Filesystem 1k-blocks Used Available Use% Mounted on
fooble 15240 4 15236 0% /fooble
bash-2.05a#

 

[RiX0R]

Well I guess using memory is the safest choice, and using tmpfs I can actually write and execute script files (part of what I was going to use it for).

Persistence after switch-off is a nice-to-have feature, but not really required.

 

[Titousensei]

It would be nice to have a ramdisk mounted by default (on /tmp, for instance), but the kernel needs to be compiled with this option. Did somebody try to mount a ramfs?

 

[gfoot]

There are some old backups of scripts in /etc, with commands to mount a couple of tmpfs, but it looks like DignSys changed their minds. Maybe they'll enable it again at some point.