Messages in this thread | | | From | David Woodhouse <> | Subject | Re: [patch?] Re: Do ramdisk exec's map direct to buffer cache? | Date | Wed, 09 Aug 2000 09:32:40 +0100 |
| |
alan@lxorguk.ukuu.org.uk said: > > because of lacking memory, > > we need binfmt like XIP(eXecution In Place). > > but, it's seems not to be exists. :(
> The ucLinux people at least at one point had XIP working. I believe > some of the linuxce people looked at it too. It isnt conceptually > hard. The ramdisk effectively does what you need which is to add the > ROM data (suitably aligned) to the page cache and then lock it. For > 2.4 ramfs might be a better prototype
JFFS ought to be able to do XIP. You just need to make sure that the executable data you want are page-aligned, and remain that way over garbage-collection. Then munge the page tables to point at the relevant pages directly in the flash chips.
However, for obvious reasons XIP and compression are mutually exclusive. As flash is more expensive than RAM, nobody really seems that interested in XIP any more.
Some nutter (prumpf) already implemented compression for JFFS, although it hasn't been merged yet.
Seriously, if you were looking at XIP with 1MB RAM and 2MB flash, then I'd advise you to use compression instead, and swap the numbers to 2MB RAM and 1MB flash.
(Actually, JFFS has memory usage problems which need to be addressed before we can really cut the RAM down that far. Being a log-structured filesystem, it keeps a permanent cache of data about each node on the media. This means it uses lots of RAM to cache info about inodes it's rarely going to use, and also it takes a long time to scan the flash on boot. The problem with dropping that cache and scanning on demand is that you may need to scan the _whole_ flash again every time you want to find an inode which you've previously dropped, which is _slow_.)
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |