Slashdot Mirror

← Back to Stories (view on slashdot.org)

XiP Filesystem Primps For Linux 2.6.28

Posted by timothy on from the primpin'-ain't-easy-but-it's-necessary dept.

nerdyH writes "The Linux-Embedded discussion list has been abuzz the last two days over a flash filesystem designed to support binary code execution (sometimes called XIP, or "execute-in-place"). When combined with forthcoming "Phase Change Memory" products from Intel/ST JV Numonyx, the "Advanced XiP Filesystem" (AXFS) could radically change Linux systems of all kinds, replacing Flash, hard drives, and even DRAM with a single chunk of low-cost, non-volatile memory that can both store files and serve as a platform for program execution."

4 of 33 comments (clear)

  1. Re:Huh? by 42forty-two42 · · Score: 5, Informative

    This filesystem is meant for embedded devices with Flash storage that presents itself as a portion of physical memory - essentially, it helps the kernel avoid the overhead of copying from Flash to RAM when you can just run it out of Flash.
    XiP has been supported in other filesystems, this is more like a small improvement - nothing to get excited about. Moreover, you won't see it in use in any desktops - this filesystem is read-only; more like an archive format understood by the kernel.
    More useful discussion can be found at kerneltrap.

  2. For people unfamiliar to XIP: by Sprite_tm · · Score: 3, Informative

    The idea of XiP is that if you have a piece of storage that's directly accessible as memory to the CPU (e.g. a piece of old-school ROM, NOR-flash, battery-backed RAM, or phase-change memory), the CPU can just execute a program directly from there instead of first copying it to RAM and executing it there. Storing programs in this memory so they can be executed is something that normal filesystems can't do per default, and that's why this is something interesting: You'll still need RAM for the data parts of the program, but the programs and libraries themselves can remain on disk without taking up precious RAM.

  3. Re:Huh? by Microlith · · Score: 3, Informative

    AXFS is read-only. The usage case tends to go as follows:

    - Build a compressed filesystem
    - Run a test case, interacting with the filesystem to generate page hits on your binaries.
    - Take the profile the filesystem generates and rebuild the filesystem.

    The article says that CramFS supports a version, but it seems as if this version may be able to work on smaller chunks of memory (a page) at a time than the CramFS version (which seems to only work on a full file at a time?).

    Precisely. CramFS works by setting the entirety of a file XIP if its sticky bit is set. AXFS runs based off a profile generated by the kernel when page faults are caused. Individual pages are then left uncompressed and executed directly from flash.

  4. Classic Palm OS by argent · · Score: 3, Informative

    It's block rather than record oriented, but this seems similar to how classic Palm OS worked. In the Handspring Visor, which had directly addressable flash memory, this was used to execute code directly out of flash.