From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1832 invoked by alias); 7 Sep 2007 09:32:11 -0000 Received: (qmail 1823 invoked by uid 22791); 7 Sep 2007 09:32:10 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Sep 2007 09:32:06 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1ITaBy-0005kW-00; Fri, 07 Sep 2007 11:31:58 +0200 Date: Fri, 07 Sep 2007 09:32:00 -0000 From: Andrew Lunn To: Yi Tang Cc: eCos-discuss Message-ID: <20070907093158.GK32192@lunn.ch> Mail-Followup-To: Yi Tang , eCos-discuss References: <000501c7f10a$81073a50$82406682@itee.uq.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000501c7f10a$81073a50$82406682@itee.uq.edu.au> User-Agent: Mutt/1.5.16 (2007-06-11) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] ecos kernel modification and kapidata X-SW-Source: 2007-09/txt/msg00027.txt.bz2 On Fri, Sep 07, 2007 at 02:49:41PM +1000, Yi Tang wrote: > Hi, > > I'm currently doing some modification to ecos kernel, mainly trying to add > a custom scheduler. I have created my own scheduler implementation file and > changed some to kapi.cxx (hxx). > > I thought that's all. After finished the cdl modification to add the new > scheduler, I tried to build the library. But during the compiling, it says > I also need to do some modification to kapidata.hxx. Could you be more specific about this.... > The thing is I don't understand the role this file takes in the whole > kernel. There is a nice comment in kapidata.h Description: This file defines the structures used in the native API. The // sizes of these structures are dependent on the system // configuration and must be kept in step with their real // counterparts in the C++ headers. // IMPORTANT: It is NOT guaranteed that the fields of these // structures correspond to the equivalent fields in the // C++ classes they shadow. // // One oddity with this file is that the way many of the "mirror" // classes are defined with macros. The resulting structures // then have a "flat" layout, rather than just declaring a // member structure directly in the structure. The reason for // this is that as of GCC 3.x, the C++ compiler will optimise // classes by removing padding and reusing it for subsequent // members defined in a derived class. This affects some targets // (including PowerPC and MIPS at least) when a C++ base class // includes a long long. By instead arranging for the C structure // to just list all the members directly, the compiler will then // behave the same for the C structures as the C++ classes. // // This means that care has to be taken to follow the same // methodology if new stuff is added to this file. Even if // it doesn't contain long longs for your target, it may for // others, depending on HAL definitions. // The memory for kernel data structures, like threads, mutexes, flags etc are allocated in applications C code. However these structures are actually used as classes in the C++ code. You need to ensure that the C structure is the same size as the C++ class. If not, bad things will happen. If you have added members to a class, you also need to add extra members to the C structures. Otherwise too little memory will be allocated. > Also is there any other source file I need to modify? Hard to say. It sounds like you have made major changes to the API, so without seeing your code it is impossible to say. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss