Re: Mounting a in-ROM filesystem efficiently

From: Bradley D. LaRonde (
Date: Fri Dec 14 2001 - 10:27:13 EST

----- Original Message -----
From: "David Woodhouse" <>
To: "Bradley D. LaRonde" <>
Cc: "Thomas Capricelli" <>; <>
Sent: Friday, December 14, 2001 4:45 AM
Subject: Re: Mounting a in-ROM filesystem efficiently

> 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:
> >
> + 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

> 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
> 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. :-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:28 EST