[ECOS] ecos kernel modification and kapidata

[ECOS] ecos kernel modification and kapidata

[Yi Tang]

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

Re: [ECOS] ecos kernel modification and kapidata

[Andrew Lunn]

> 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

Re: [ECOS] ecos kernel modification and kapidata

[Andrew Lunn]

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

RE: [ECOS] ecos kernel modification and kapidata

[Paul D. DeRocco]

> 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

Re: [ECOS] ecos kernel modification and kapidata

[Nick Garnett]

"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

Re: [ECOS] ecos kernel modification and kapidata

[Yi Tang]

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