RE: [ECOS] Re: Any shell available?

["Zimman, Chris" <czimman at bloomberg dot com>]

We've actually written a small shell for eCos that we use internally.
There's no objloader support for our platform yet (AFAIK), but we use
something similar to the RedBoot_cmd() syntax to bring in commands to
the shell.  There's a "ps" clone, mount/unmount for the filesystems, ls,
etc.
There's no scripting support, but there's no reason it couldn't be
added.

If anyone is interested, let me know and I'll see if I can pack it up
into something exportable.

--Chris

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Anthony
Tonizzo
Sent: Wednesday, May 31, 2006 12:43 PM
To: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Re: Any shell available?

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

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