public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Pringlemeir <bpringle@sympatico.ca>
To: Mike Touloumtzis <miket@bluemug.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [CFT] initramfs patch
Date: 30 Jul 2001 18:16:40 -0400	[thread overview]
Message-ID: <m2ofq26p13.fsf@sympatico.ca> (raw)
In-Reply-To: <Pine.GSO.4.21.0107301646050.19391-100000@weyl.math.psu.edu> <20010730141427.E20284@bluemug.com>
In-Reply-To: Mike Touloumtzis's message of "Mon, 30 Jul 2001 14:14:27 -0700"

>>>>> "Mike" == Mike Touloumtzis <miket@bluemug.com> writes:
[snip]
 Mike> Hmmm, maybe we need ramfs-backed-by-romfs :-).  But a lot of
 Mike> people in the embedded/consumer electronics space could get by
 Mike> just fine with a read-only / and a ramfs or ramdisk on /tmp.

I am not so sure about this.  Typical flash access times are rather
long compared to SDRAM.  StrataFlash and other bursting flash are
rather new and require specific CPUs or custom logic to access the
flash in a sequential mode.

In my personal experience, code is usually compressed in flash (or
ROM) and expanded into SDRAM.  You can always use an MMU to achieve
the RO effects of flash/ROM.  The big win for flash execution is that
the power numbers are typically lower... but since it takes longer to
execute, it washes out to the same.  But some paranoid hardware people
don't like `peak drains' on a battery so they might prefer Flash
execution.  The flexibility is nice whatever the case; it might become
more of an issue if bursting/sequential flash devices become more
common.  I don't know if there is a big push for this though.  The cost
of burst flash is still greater than SDRAM afiak.

fwiw,
Bill Pringlemeir.




  reply	other threads:[~2001-07-30 22:20 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 [this message]
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
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=m2ofq26p13.fsf@sympatico.ca \
    --to=bpringle@sympatico.ca \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miket@bluemug.com \
    /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