From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27590 invoked by alias); 31 May 2006 16:42:54 -0000 Received: (qmail 27581 invoked by uid 22791); 31 May 2006 16:42:53 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.183) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 May 2006 16:42:50 +0000 Received: by py-out-1112.google.com with SMTP id c63so28344pyc for ; Wed, 31 May 2006 09:42:48 -0700 (PDT) Received: by 10.35.112.3 with SMTP id p3mr423593pym; Wed, 31 May 2006 09:42:48 -0700 (PDT) Received: by 10.35.116.9 with HTTP; Wed, 31 May 2006 09:42:48 -0700 (PDT) Message-ID: Date: Wed, 31 May 2006 16:42:00 -0000 From: "Anthony Tonizzo" To: ecos-discuss@ecos.sourceware.org In-Reply-To: <447D8356.6060804@inf.ufsc.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060531083743.GD2478@lunn.ch> <447D8356.6060804@inf.ufsc.br> 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: Re: [ECOS] Re: Any shell available? X-SW-Source: 2006-05/txt/msg00275.txt.bz2 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