From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5329 invoked by alias); 28 Apr 2005 10:01:18 -0000 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 Received: (qmail 5243 invoked from network); 28 Apr 2005 10:01:08 -0000 Received: from unknown (HELO anchor-post-33.mail.demon.net) (194.217.242.91) by sourceware.org with SMTP; 28 Apr 2005 10:01:08 -0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-33.mail.demon.net with esmtp (Exim 4.42) id 1DR5pS-0006km-CS; Thu, 28 Apr 2005 10:01:07 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 1F369DE5B; Thu, 28 Apr 2005 11:01:06 +0100 (BST) To: "Paul D. DeRocco" Cc: "eCos Discuss" References: From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Thu, 28 Apr 2005 10:06:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] RE: eCos Loader X-SW-Source: 2005-04/txt/msg00290.txt.bz2 "Paul D. DeRocco" writes: > > > > Instead the approach described by Tony would be more appropriate: the > > application developer generates a table of just the symbols that he > > expects his loaded modules to access. This way the main application > > will be kept small. > > This is an intrinsic problem with a loader: you have to create an OS that > has an API suitable for loaded applications that haven't yet been written. > In general, the most useful OS image would include symbol table entries for > all documented functions in the included eCos subsystems. Otherwise you have > to arbitrarily constrain the writers of loaded applications, and document > those constraints. Yes, this means that the linked portion of the system may > be larger than necessary for a particular app, but that's the only way to > decouple the design of the OS from the design of the app. The things being loaded will be application specific: device drivers, video/audio codecs, protocol handlers, libraries etc. You just need to define the API that they will use and build a symbol table to match. There's no need to add stuff that they won't be calling. > Typically, the only reference _into_ a loaded module is the start address. > That is, the code is loaded, and a thread is started (or a function is > called) at the module's start address. That may be true in Linux, where the init routine then registers the module into the OS data structures with function tables and the like. This will also be the way that things like device drivers and codec will work too. However, a more general library may have a variety of interface calls. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss