public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Nick Garnett <nickg@ecoscentric.com>
To: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Cc: "'ecos-discuss'" <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] ecos kernel modification and kapidata
Date: Fri, 07 Sep 2007 12:57:00 -0000	[thread overview]
Message-ID: <m3abry3a7c.fsf@xl5.calivar.com> (raw)
In-Reply-To: <00a701c7f142$b4e60ee0$887ba8c0@PAULD>

"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

  reply	other threads:[~2007-09-07 12:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-07  4:49 Yi Tang
2007-09-07  9:19 ` Andrew Lunn
2007-09-07 11:32   ` Paul D. DeRocco
2007-09-07 12:57     ` Nick Garnett [this message]
2007-09-07  9:32 ` Andrew Lunn
2007-09-11 14:22   ` Yi Tang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3abry3a7c.fsf@xl5.calivar.com \
    --to=nickg@ecoscentric.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=pderocco@ix.netcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).