From: "Øyvind Harboe" <oyvind.harboe@zylin.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] memory saving scheme for stacks
Date: Mon, 02 Aug 2004 08:05:00 -0000 [thread overview]
Message-ID: <1091433941.12336.14.camel@famine> (raw)
In-Reply-To: <20040801205249.GA9839@lunn.ch>
On Sun, 2004-08-01 at 22:52, Andrew Lunn wrote:
> > If you have the ram, then obviously SST threads make no sense.
>
> It seems to me that nearly everything you have been doing for the last
> couple of months has been to do with shoehorning your code into a
> system with too little RAM. eCos is meant to be small, but it also has
> to be clean, maintainable and efficient.
>
> It might be time to take a step back and take a look at your problem
> from a wider angel. Consider how much time you have spent so far,
> consider how much more time you would need to implement SST. Consider
> the maintainance of such a system. Its always difficult to get a
> stable system when you have extreamly tight memory since unexpected
> things will happen in the field causing hard to reporduce bugs.
Squeezing more out of the current system must of course be held up
against the costs of a redesign. At some point, doing a redesign is
cheaper.
> Talk to your hardware people and component supply people. It might
> turn out cheaper in the long run to put bigger RAMs on the board and
> save a huge amount of time and money on the software side of the
> project.
If they add DRAM(megabytes), word is we'll be switching to uCLinux.
Hence the energy barrier(from a high-level perspective) to be crossed is
new board layout(which entails more than just the CPU) + switching OS.
So far eCos has yielded to my efforts to squeeze a bit more out of the
system.
My current thinking on the SST stuff is that it is over the top.
> Andrew
--
Øyvind Harboe
http://www.zylin.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
prev parent reply other threads:[~2004-08-02 8:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-23 9:55 Øyvind Harboe
2004-07-23 10:20 ` Nick Garnett
2004-07-23 10:29 ` Øyvind Harboe
2004-07-23 11:41 ` sandeep
2004-07-23 12:27 ` Øyvind Harboe
2004-07-23 10:22 ` sandeep
2004-07-23 11:23 ` Øyvind Harboe
2004-07-23 12:40 ` sandeep
2004-07-23 13:31 ` Øyvind Harboe
2004-07-23 14:21 ` [ECOS] Fis & JFFS2 David Lewin
2004-07-23 14:44 ` [ECOS] memory saving scheme for stacks Øyvind Harboe
2004-07-23 15:09 ` Øyvind Harboe
2004-08-01 20:52 ` Andrew Lunn
2004-08-02 8:05 ` Øyvind Harboe [this message]
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=1091433941.12336.14.camel@famine \
--to=oyvind.harboe@zylin.com \
--cc=andrew@lunn.ch \
--cc=ecos-discuss@sources.redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).