All of lore.kernel.org
 help / color / mirror / Atom feed
From: "P. Christeas" <p_christ@hol.gr>
To: Marc Karasek <marckarasek@ivivity.com>
Subject: Re: how to emdedded ramdisk.gz in vmlinux for linux-2.6.14?
Date: Fri, 20 Jan 2006 23:02:28 +0200	[thread overview]
Message-ID: <200601202302.29928.p_christ@hol.gr> (raw)
In-Reply-To: <1137790053.22994.58.camel@localhost.localdomain>

On Friday 20 January 2006 10:47 pm, you wrote:
> Basically due to design issues and cost issues having a flash based
> system is not possible.  Currently we have only 16MB total of flash and
> the biggest contiguous block avail in this is only 12MB.  Our current
> ramdisk (uncompressed) is running at 30MB.  Basically, memory is cheaper
> than flash.  When you have designs that are very cost sensitive (to put
> it lightly), for example adding a 50 cent part is a major event.  You
> cannot just say we need more flash...  If we are to continue to support
> the embedded market for Linux,  every decision we make as too what
> feature gets put in, which ones get dropped have to be made with
> everyone in mind.  What is good for the desktop market, may not be the
> best solution for the embedded market.  BTW: When I mean embedded I do
> not mean Ipaq or Palm.  These are small computers with a completely
> different set of requirements than a 1U pizza box headless storage
> controller/switch/etc.
>

Our discussion is quite general, I don't mean to interfere with your hardware 
design anyway. My point was just that the filesystem you mention would be 
stored in some kind of ROM anyway (either inside the kernel ELF or outside 
it). So, you wouldn't need to copy it to your RAM. That's the main feature of 
squashfs/cromfs. You can still have tmpfs for some kind of read/write 
storage.
One drawback, however, would be that the access to the ROM (in the form of 
mtd) could cost you some extra code that need to go into the kernel.

  reply	other threads:[~2006-01-20 21:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-16 14:48 how to emdedded ramdisk.gz in vmlinux for linux-2.6.14? Marc Karasek
2006-01-17  0:26 ` Kumba
2006-01-17 16:27   ` Marc Karasek
2006-01-18  1:10     ` Kumba
2006-01-19 21:07       ` Marc Karasek
2006-01-19 22:49         ` Stuart Longland
2006-01-20  4:11         ` Kumba
2006-01-20 18:43           ` Marc Karasek
2006-01-20 19:02           ` Marc Karasek
2006-01-20 19:02             ` Marc Karasek
2006-01-20 19:08             ` Stephen P. Becker
     [not found] ` <200601202129.11398.p_christ@hol.gr>
     [not found]   ` <1137786593.22994.46.camel@localhost.localdomain>
     [not found]     ` <200601202203.14325.p_christ@hol.gr>
2006-01-20 20:47       ` Marc Karasek
2006-01-20 21:02         ` P. Christeas [this message]
2006-01-20 21:03         ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2006-01-20 21:27 Marc Karasek
2006-01-20 21:27 ` Marc Karasek
2006-01-15  4:22 zhuzhenhua

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=200601202302.29928.p_christ@hol.gr \
    --to=p_christ@hol.gr \
    --cc=marckarasek@ivivity.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 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.