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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Tonizzo Sent: Wednesday, May 31, 2006 12:43 PM To: [email protected] 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
