public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Anthony Tonizzo" <atonizzo@gmail.com>
To: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Re: Any shell available?
Date: Wed, 31 May 2006 16:42:00 -0000	[thread overview]
Message-ID: <b437ec690605310942i76752432j89f43183c1e07708@mail.gmail.com> (raw)
In-Reply-To: <447D8356.6060804@inf.ufsc.br>

Andrew:

> However what Anthony is suggesting would allow multiple blobs of
> object code to be loaded and executed simultaniously. And the blobs
> can be loaded at any time, not just at boot time. It is more than a
> boot loader.

> However, there is no practical way to terminate all the threads
> associated with a blob, unload it, and make sure it has released all
> its resources. To do this you need processes. Without this you cannot
> have a proper shell.

Agreed. Process management is impossible, and thus a real shell
will be impossible. But something based on objloader is still better
than nothing especially if your tasks are reasonably well behaved and
are not expected to die on you all the time, leaking memory all over
the map.

A possible implementation of the "kill" command in the shell would
call the  library_close() function inside the blob, and if the user is
judicious,
it can be used to try to reclaim as many resources as possible. In other
words, you must reclaim your own garbage, do not expect the OS
to do it for you. This "thread desctructor" is not  perfect by any
stretch of the
imagination, but a first step  in the right direction, and with time we can get
to a point where the memory leaks that result  from terminating a process
might be kept reasonably low.

In the case in which the thread dies a sudden death, there is little that
can be done without an MMU and per-thread paging anyway. And we really
do not want to go there.

Also, as you correctly suggest, the ability to run a script upon startup (a la
RedBoot) could make this "poor man's shell" a good boot loader: Instead of
recompiling and reflashing the application with the kernel, you instruct the
startup script to load the application upon boot from an existing file system
(JFFS2 come to mind.) That way multiple copies of the application can be
kept, and you can boot whichever one you prefer.

Cheers
Tony

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  parent reply	other threads:[~2006-05-31 16:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-31  1:02 Anthony Tonizzo
2006-05-31  8:37 ` Andrew Lunn
2006-05-31 11:51   ` Luis Friedrich
2006-05-31 12:20     ` Andrew Lunn
2006-05-31 16:42     ` Anthony Tonizzo [this message]
2006-05-31 21:47     ` David N. Welton
2006-05-31 18:28 Zimman, Chris
2006-06-02 10:47 ` Ilija Koco
     [not found]   ` <44805E04.2040400@mindspring.com>
2006-06-02 16:19     ` Ilija Koco
     [not found] <3B530EF12E388B408ECC3162BA8C00F401BBE726@ny2526.corp.bloomberg. com>
     [not found] ` <3B530EF12E388B408ECC3162BA8C00F401BBE726@ny2526.corp.bloomberg .com>
2006-05-31 22:28   ` John Carter

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=b437ec690605310942i76752432j89f43183c1e07708@mail.gmail.com \
    --to=atonizzo@gmail.com \
    --cc=ecos-discuss@ecos.sourceware.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 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).