Messages in this thread | | | From | "Bradley D. LaRonde" <> | Subject | Re: Mounting a in-ROM filesystem efficiently | Date | Fri, 14 Dec 2001 10:27:13 -0500 |
| |
----- Original Message ----- From: "David Woodhouse" <dwmw2@infradead.org> To: "Bradley D. LaRonde" <brad@ltc.com> Cc: "Thomas Capricelli" <orzel@kde.org>; <linux-kernel@vger.kernel.org> Sent: Friday, December 14, 2001 4:45 AM Subject: Re: Mounting a in-ROM filesystem efficiently
> brad@ltc.com said: > > have maintained, on and off, a patch to crafms that supports > > traditional cramfs decompress-and-read/run-from-RAM, plus direct > > mmaping with no decompression and read/run straight out of ROM: > > > http://www.ltc.com/~brad/mips/cramfs-linear-root-xip-linux-2.4.9-2.diff > > + if (remap_page_range(vma->vm_start, KSEG0ADDR(address), length, > + vma->vm_page_prot)) > > > Cute, but not very generic.
Yes, sorry, I should have mentioned that MIPSism in there. I haven't tried, but I imagine it wouldn't be that hard to adjust for other platforms.
(In case anyone isn't familiar with KSEG0ADDR on MIPS, it takes a physical address as it's only paramter and returns a cacheable virtual address in "kernel address segment 0" (0x80000000 - 0xafffffff) which is hardwire 1:1 mapped with physical address space).
> The approach I was contemplating was to > allocate a set of 'struct page's for the pages containing XIP data, then > add those pages to the page cache manually on read_inode(). > > It's a shame that ->readpage() doesn't get to say 'actually I used my own > page for that, I didn't want one allocated for me'.
That sounds nice, but I cannot imagine how much trouble it would be to implement.
> Extending the MTD API to return a set of pages representing a particular > device, and handling the locking so that we don't try to write to the chips > while pages are mapped, will also be necessary if we want to do it with > flash chips that are used for anything else.
Actually, I've used that patch on a system that had a cramfs/xip and a jffs partition on the same flash chip where the kernel was running xip out of flash. :-)
Regards, Brad
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |