From: "Bradley D. LaRonde" <brad@ltc.com>
To: "David Woodhouse" <dwmw2@infradead.org>
Cc: "Thomas Capricelli" <orzel@kde.org>, <linux-kernel@vger.kernel.org>
Subject: Re: Mounting a in-ROM filesystem efficiently
Date: Fri, 14 Dec 2001 10:27:13 -0500 [thread overview]
Message-ID: <0ddd01c184b3$ce15c470$5601010a@prefect> (raw)
In-Reply-To: <066801c183f2$53f90ec0$5601010a@prefect> <20011213160007.D998D23CCB@persephone.dmz.logatique.fr> <25867.1008323156@redhat.com>
----- 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
next prev parent reply other threads:[~2001-12-14 15:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-13 16:02 Mounting a in-ROM filesystem efficiently Thomas Capricelli
2001-12-13 16:22 ` Bradley D. LaRonde
2001-12-13 16:41 ` Thomas Capricelli
2001-12-13 17:10 ` Bradley D. LaRonde
2001-12-13 18:02 ` Richard B. Johnson
2001-12-13 18:14 ` Bradley D. LaRonde
2001-12-13 18:34 ` Richard B. Johnson
2001-12-13 18:52 ` Bradley D. LaRonde
2001-12-13 19:41 ` Richard B. Johnson
2001-12-13 20:09 ` Bradley D. LaRonde
[not found] ` <08d701c18412/mnt/tmp/sendmee91d2c0601010a@prefect>
2001-12-18 1:27 ` Pavel Machek
2001-12-14 11:03 ` Catalin Marinas
2001-12-13 17:49 ` David Woodhouse
2001-12-13 18:06 ` Bradley D. LaRonde
2001-12-13 20:38 ` H. Peter Anvin
2001-12-13 20:52 ` Bradley D. LaRonde
2001-12-14 9:45 ` David Woodhouse
2001-12-14 15:27 ` Bradley D. LaRonde [this message]
2001-12-14 16:51 ` David Woodhouse
2001-12-14 17:02 ` Bradley D. LaRonde
2001-12-14 17:03 ` David Woodhouse
2001-12-14 17:12 ` Bradley D. LaRonde
2001-12-14 17:16 ` David Woodhouse
2001-12-14 17:27 ` Bradley D. LaRonde
2001-12-16 9:51 ` Christoph Rohland
2002-01-23 8:01 ` Eric W. Biederman
[not found] <20011214072540.D7457@duron.intern.kubla.de>
2001-12-17 13:24 ` Richard B. Johnson
2001-12-18 12:10 ` Helge Hafting
2001-12-18 14:00 ` Richard B. Johnson
2001-12-18 14:09 ` Alan Cox
2001-12-18 15:21 ` Mr. James W. Laferriere
2001-12-18 20:56 ` H. Peter Anvin
2001-12-18 16:27 ` Kent Borg
2001-12-18 17:05 ` Herman Oosthuysen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='0ddd01c184b3$ce15c470$5601010a@prefect' \
--to=brad@ltc.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=orzel@kde.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox