* [ECOS] ecos kernel modification and kapidata @ 2007-09-07 4:49 Yi Tang 2007-09-07 9:19 ` Andrew Lunn 2007-09-07 9:32 ` Andrew Lunn 0 siblings, 2 replies; 6+ messages in thread From: Yi Tang @ 2007-09-07 4:49 UTC (permalink / raw) To: eCos-discuss 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. The thing is I don't understand the role this file takes in the whole kernel. Why do we need it? Can't find anything related to that in ecos documents and massa's book. Also is there any other source file I need to modify? Another question is: can I directly call the c++ api of the kernel in application instead of the C KAPI? And do you have any document relative to this native C++ API? Thanks and Regards, Yi Tang -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] ecos kernel modification and kapidata 2007-09-07 4:49 [ECOS] ecos kernel modification and kapidata Yi Tang @ 2007-09-07 9:19 ` Andrew Lunn 2007-09-07 11:32 ` Paul D. DeRocco 2007-09-07 9:32 ` Andrew Lunn 1 sibling, 1 reply; 6+ messages in thread From: Andrew Lunn @ 2007-09-07 9:19 UTC (permalink / raw) To: Yi Tang; +Cc: eCos-discuss > Another question is: can I directly call the c++ api of the kernel in > application instead of the C KAPI? And do you have any document relative to > this native C++ API? There is nothing to stop you calling the C++ API, but we don't recommend it. The C API is documented and frozen. The C++ is not documented and not frozen, it can and does change. So we reserve the right to break your application if you use the C++ API :-) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [ECOS] ecos kernel modification and kapidata 2007-09-07 9:19 ` Andrew Lunn @ 2007-09-07 11:32 ` Paul D. DeRocco 2007-09-07 12:57 ` Nick Garnett 0 siblings, 1 reply; 6+ messages in thread From: Paul D. DeRocco @ 2007-09-07 11:32 UTC (permalink / raw) To: 'ecos-discuss' > From: Andrew Lunn > > There is nothing to stop you calling the C++ API, but we > don't recommend it. The C API is documented and frozen. The > C++ is not documented and not frozen, it can and does change. > > So we reserve the right to break your application if you use > the C++ API :-) Unfortunately, it's not generally possible to create synchronization objects comparable to the built-in ones without writing in C++, and the set provided is pretty limited. You need to access things like thread_queue objects, and call member functions like set_sleep_reason, get_wake_reason, etc. I think that, since eCos is written in C++, it should be documented primarily in C++, and people should be encouraged to use the C++ API. The C API should be provided as an optional layer, like Posix or uItron. -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] ecos kernel modification and kapidata 2007-09-07 11:32 ` Paul D. DeRocco @ 2007-09-07 12:57 ` Nick Garnett 0 siblings, 0 replies; 6+ messages in thread From: Nick Garnett @ 2007-09-07 12:57 UTC (permalink / raw) To: Paul D. DeRocco; +Cc: 'ecos-discuss' "Paul D. DeRocco" <pderocco@ix.netcom.com> writes: > > From: Andrew Lunn > > > > There is nothing to stop you calling the C++ API, but we > > don't recommend it. The C API is documented and frozen. The > > C++ is not documented and not frozen, it can and does change. > > > > So we reserve the right to break your application if you use > > the C++ API :-) > > Unfortunately, it's not generally possible to create synchronization objects > comparable to the built-in ones without writing in C++, and the set provided > is pretty limited. You need to access things like thread_queue objects, and > call member functions like set_sleep_reason, get_wake_reason, etc. And that's the very reason the C++ API is not standardized. If we want to add new synchronization objects, or vary the semantics of existing objects (as we do for POSIX and ITRON), or add a new scheduler, the internal interfaces may need to change to accommodate it. If you write your own extensions to the kernel, using the C++ interface, then you have to accept that sometimes it will change. Most of the changes we have made preserved old interfaces, so very little needed adjusting. But we don't want to have to guarantee that these things will never change. > > I think that, since eCos is written in C++, it should be documented > primarily in C++, and people should be encouraged to use the C++ API. The C > API should be provided as an optional layer, like Posix or uItron. C++ was used only because it allowed the configuration mechanism to work more cleanly. Inheritance and overloading meant that we could keep the sources cleaner than if we had done it in C. We don't use any of the more esoteric features of C++, or expect the user interface to operate in terms of C++ mechanisms. It's an internal implementation choice rather than the adoption of a philosophy about the form of the operating system and its interface. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] ecos kernel modification and kapidata 2007-09-07 4:49 [ECOS] ecos kernel modification and kapidata Yi Tang 2007-09-07 9:19 ` Andrew Lunn @ 2007-09-07 9:32 ` Andrew Lunn 2007-09-11 14:22 ` Yi Tang 1 sibling, 1 reply; 6+ messages in thread From: Andrew Lunn @ 2007-09-07 9:32 UTC (permalink / raw) To: Yi Tang; +Cc: eCos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] ecos kernel modification and kapidata 2007-09-07 9:32 ` Andrew Lunn @ 2007-09-11 14:22 ` Yi Tang 0 siblings, 0 replies; 6+ messages in thread From: Yi Tang @ 2007-09-11 14:22 UTC (permalink / raw) To: Andrew Lunn; +Cc: eCos-discuss 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 <add to list> 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" <andrew@lunn.ch> To: "Yi Tang" <yitang@itee.uq.edu.au> Cc: "eCos-discuss" <ecos-discuss@ecos.sourceware.org> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-09-11 14:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-09-07 4:49 [ECOS] ecos kernel modification and kapidata Yi Tang 2007-09-07 9:19 ` Andrew Lunn 2007-09-07 11:32 ` Paul D. DeRocco 2007-09-07 12:57 ` Nick Garnett 2007-09-07 9:32 ` Andrew Lunn 2007-09-11 14:22 ` Yi Tang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).