From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3427 invoked by alias); 31 May 2006 01:02:49 -0000 Received: (qmail 3405 invoked by uid 22791); 31 May 2006 01:02:48 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 May 2006 01:02:30 +0000 Received: by py-out-1112.google.com with SMTP id c63so650966pyc for ; Tue, 30 May 2006 18:02:28 -0700 (PDT) Received: by 10.35.34.18 with SMTP id m18mr4446034pyj; Tue, 30 May 2006 18:02:28 -0700 (PDT) Received: by 10.35.116.9 with HTTP; Tue, 30 May 2006 18:02:28 -0700 (PDT) Message-ID: Date: Wed, 31 May 2006 01:02:00 -0000 From: "Anthony Tonizzo" To: ecos-discuss@ecos.sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: Any shell available? X-SW-Source: 2006-05/txt/msg00259.txt.bz2 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