From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31755 invoked by alias); 11 Sep 2007 14:22:24 -0000 Received: (qmail 31747 invoked by uid 22791); 11 Sep 2007 14:22:23 -0000 X-Spam-Check-By: sourceware.org Received: from gum.itee.uq.edu.au (HELO gum.itee.uq.edu.au) (130.102.66.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Sep 2007 14:22:15 +0000 Received: from filter2.itee.uq.edu.au (filter2.itee.uq.edu.au [130.102.66.22]) by gum.itee.uq.edu.au (8.13.1/8.13.1) with ESMTP id l8BEM9ZC005750; Wed, 12 Sep 2007 00:22:09 +1000 Received: from g5099368 (g509-9368.itee.uq.edu.au [130.102.64.130]) by filter2.itee.uq.edu.au (8.13.1/8.13.1) with SMTP id l8BEM8P7007728; Wed, 12 Sep 2007 00:22:09 +1000 Message-ID: <001401c7f47f$22ef98e0$82406682@itee.uq.edu.au> Reply-To: "Yi Tang" From: "Yi Tang" To: "Andrew Lunn" Cc: "eCos-discuss" References: <000501c7f10a$81073a50$82406682@itee.uq.edu.au> <20070907093158.GK32192@lunn.ch> Date: Tue, 11 Sep 2007 14:22:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook Express 6.00.2900.3138 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/msg00056.txt.bz2 Hi Andrew and all, Thanks for your reply. I'm trying to build a custom scheduler which is OSEKtime compliant (a first in last out (stack) queue based scheduler). I use the lottery scheduler as prototype and create the new scheduler. The new kernel is complied successfully. The test is also built good. However, in the execution, some other part of the kernel behave strangely. In the thread creation part, the function went wrong somehow. According to the code, the thread_list should be a circular queue. During the execution, in the function (attach_stack) called at the start of thread creation, the pointer "thread_list->list_next" is modified into a new value and broke the circular queue. I don't quite understand why this will happen. I didn't touch anything in kernel except change the scheduler implementation file. I guess it can be the kernel's size is changed or the complier's problem. I have tried to use the bitmap to run the same code. That runs well. I totally have no idea about it and hope someone kind enough to help me. Thanks and regards, Yi Tang ----- Original Message ----- From: "Andrew Lunn" To: "Yi Tang" Cc: "eCos-discuss" Sent: Friday, September 07, 2007 7:31 PM Subject: Re: [ECOS] ecos kernel modification and kapidata > 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 > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss