And just FYI, I do not know why it did not occur to us in the past, but instead of just PAUSING the framework while I run my native mode apps, I now STOP the framework, which makes 10x as much free RAM available to my apps as when the framework was hogging most of it (even while paused).
Now I think I can run optware (or debian lenny) in a loop mount on all the kindles without locking them up (as was common trying to use optware on a K5). Instead of putting that framework pig to sleep, just shoot it and bury it, and it will stay out of your way. Also, thinking of doing a pivot_root (instead of just chroot) like I did in my old OpenWRT hacking days...
On my DX, I only have about 3MB free memory after pausing the framework, but after stopping it I have over 30MB free memory. Less critical to keep that nbd swap file hanging around, eh?
EDIT: Apparently, I tried this before on the K5, and still not enough free memory:
Quote:
|
The REAL problem with optware on the touch is that there is not much free memory, even after stopping the GUI framework. I and another developer bricked their kindle touch while trying to use optware on it.
|
That won't stop me from trying it again. 
EDIT2: Hmm... From an SSH shell on a DXG that had been used a bit since the last reboot, "grep MemFree /proc/meminfo" showed about 3MB free, and after "/etc/init.d/framework stop" it showed more than 30MB free. Now I tried that right after a reboot, and with framework running it had more than 50MB free, and after a shutdown more than 60MB free. Starting the framework again with "/etc/init.c/framework start" still showed more than 40MB free, and even after launching some things with KUAL it still had more than 30MB free. I wonder if there is a memory leak somewhere in the DXG firmware and/or framework? As mentioned earlier, when the framework eats up all but a few MB of memory, stopping the framework frees up about 30MB, so there is still more than 30MB of memory gone that was there after a reboot.