Inu, jak, nejsnáz tak, že se předem vyrobí obraz adresářového stromu jako soubor, a ten se pak připojí jako loopback zařízení (nebo jak se to jmenuje). Nebo samozřejmě se dá ten obraz nahrát třeba dd-čkem na opravdové blokové zařízení.
Read-only FS sa pouzivaju hlavne pre embedded Linux systemy, napr. routery a wireless zariadenia a vsade tam, kde je cena zariadenia a velkost programovej FLASH pamate rozhodujuca.
Napalovali ste niekedy CD? Na nom je tiez len R/O fs (ak sa bavime o ISO9660). No tak je to podobne. Urcite adresar, ktory obsahuje strukturu ktoru chcete mat na to fs, alebo nejakym sposobom zoznam suborov a adresarov a pomocou napr. utilitky mkXXXXfs (za XXXX dosadit prislusny fs ;) ) vytvorite image takehoto FS, ktory sa potom "napali" do prislusneho zariadenia.
Od tej doby co sa da pamatove zariadenie na ktorom sa prislusny fs nachadza naadresovat priamo ako operacna pamat, co pri flash pamatiach, pre ktore je tento fs urceny, nieje az taky technicky problem, ked sa s tym pocita pri navrhu HW (PDA, Telefon, Router, ....).
A kdo tu pomalost flashky vyrovná? Kdyby normálně CPU při každém fetchi instrukce čekalo milisekundu, až flashka dodá data, tak by to moc rychle nejelo. (mohla by to vyrovnat L2 cache, ale ta ti zase cenu celé té krabičky prodraží).
Tím spouštěním programů pomocí filesystému se spíš IMHO myslí optimalizace pro ramdisk --- aby když máš ramdisk, tak se ta data podruhé necachovala v normální paměti.
Taduy zjevně nejde o USB flash, ale o paměť typu EEPROM, mapovanou do operační paměti. Execute in place pak značí, že se executable spustí přímo z flash paměti.
"umí spouštět binární soubory aniž by je musel celé rozbalovat" IMHO znamená, že umožní systému nahrát část souboru do paměti, tu také rozbalí, ale nerozbaluje celý soubor hned, tj. umožňuje nějaké omezené seekování v komprimovaném souboru - asi po jednotlivých sekcích ELF formátu.