This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ecos kernel modification and kapidata


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]