All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.