Andrew:
Now eCos has no concept of loading a program from secondary storage and executing it. It has no concept of a program. It has no concept of a process.
I am not sure I agree 100% with this statement. eCos has both the concept of file system (and hence we can extrapolate the concept of secondary storage) as well as the concept of process, given that a process can be loaded by the objloader package and executed. I do not see anything wrong with an application (call it shell) that is capable of both accessing a file system as well as loading from that file system a file and running it. It would be a good way to test quickly a new version of the code, because the application (nimbler in size, because all the kernel is already running on the target as part of the shell) can be compiled on the host, loaded (perhaps remotely) and then run. Of course when everything is said and done, you will eventually compile your application with the kernel and drop the shell, but my point is that the former does not preclude the latter. vxWorks does it, why shouldn't eCos? Yes, the two systems are different, different customers, different design and all that goes with it, but there is nothing technical that prevents a shell to be written for eCos. Besides, the topic has come up several times already, and the answers that have been given so far for the lack a shell in eCos are, in my humble opinion, neither convincing nor conclusive. I can even envision a world in which, for those embedded systems that can tolerate the extra requirements, RedBoot itself is put out to pasture and it is replaced by a kernel with shell. Regards 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
