From: ebiederm@xmission.com (Eric W. Biederman)
To: Mike Touloumtzis <miket@bluemug.com>
Cc: Jeff Garzik <jgarzik@mandrakesoft.com>,
Alexander Viro <viro@math.psu.edu>,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@transmeta.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [CFT] initramfs patch
Date: 31 Jul 2001 00:46:32 -0600 [thread overview]
Message-ID: <m1puahzjcn.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1010730153712.7347D-100000@mandrakesoft.mandrakesoft.com> <20010730140928.D20284@bluemug.com>
In-Reply-To: <20010730140928.D20284@bluemug.com>
Mike Touloumtzis <miket@bluemug.com> writes:
> On Mon, Jul 30, 2001 at 03:50:33PM -0500, Jeff Garzik wrote:
> > On Mon, 30 Jul 2001, Mike Touloumtzis wrote:
> > >
> > > One thing that would make embedded systems developers very happy
> > > is the ability to map a romfs or cramfs filesystem directly from
> > > the kernel image, avoiding the extra copy necessitated by the cpio
> > > archive. Are there problems with this approach?
> >
> > Yes -- you need to at that point store initialized structures. Store
> > the dcache in its unpacked state on the ROM image, etc. That's the only
> > way to "map" a romfs directly. Otherwise there is ALWAYS an unpacking
> > or translation step between filesystem image and in-memory image.
> >
> > Mapping an in-memory image directly may seem like a good idea, but it is
> > really not. ESPECIALLY for embedded folks.
>
> I think you're misunderstanding what I propose. I'm talking about
> having a device in /dev that would allow access to a filesystem
> image (cramfs or romfs) that would be embedded in the in-memory
> kernel image.
The current mtd drivers allow exactly this. Having a filesystem on
your flash or rom device. I don't think any filesystem that runs on
top of them currently supports XIP but the basic infrastructure is
there.
Eric
next prev parent reply other threads:[~2001-07-31 6:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-30 6:05 [CFT] initramfs patch Alexander Viro
2001-07-30 16:25 ` Alon Ziv
2001-07-30 15:33 ` Keith Owens
2001-07-30 19:56 ` Anthony de Boer
2001-07-30 20:05 ` Alexander Viro
2001-07-30 20:29 ` Mike Touloumtzis
2001-07-30 20:49 ` Alexander Viro
2001-07-30 21:14 ` Mike Touloumtzis
2001-07-30 22:16 ` Bill Pringlemeir
2001-07-30 22:37 ` Mike Touloumtzis
2001-07-30 20:50 ` Jeff Garzik
2001-07-30 21:09 ` Mike Touloumtzis
2001-07-31 6:46 ` Eric W. Biederman [this message]
2001-08-11 0:27 ` David Woodhouse
2001-07-30 22:56 ` Jeff Garzik
2001-07-31 1:21 ` Keith Owens
2001-07-31 3:09 ` Alexander Viro
2001-08-02 22:46 ` [CFT] initramfs patch (2.4.8-pre3) Alexander Viro
2001-08-04 20:49 ` Ken Moffat
2001-08-05 7:07 ` Alexander Viro
2001-08-05 7:12 ` Alexander Viro
2001-08-05 20:39 ` Ken Moffat
2001-08-05 20:47 ` Alexander Viro
2001-08-06 20:16 ` Ken Moffat
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=m1puahzjcn.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miket@bluemug.com \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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.