From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14496 invoked by alias); 7 Sep 2007 12:57:13 -0000 Received: (qmail 14481 invoked by uid 22791); 7 Sep 2007 12:57:11 -0000 X-Spam-Check-By: sourceware.org Received: from anchor-post-36.mail.demon.net (HELO anchor-post-36.mail.demon.net) (194.217.242.86) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Sep 2007 12:57:04 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1ITdOL-000PZR-K2; Fri, 07 Sep 2007 12:56:58 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 6DB3B138713; Fri, 7 Sep 2007 13:56:56 +0100 (BST) To: "Paul D. DeRocco" Cc: "'ecos-discuss'" References: <00a701c7f142$b4e60ee0$887ba8c0@PAULD> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Fri, 07 Sep 2007 12:57:00 -0000 In-Reply-To: <00a701c7f142$b4e60ee0$887ba8c0@PAULD> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00035.txt.bz2 "Paul D. DeRocco" 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