RE: [ECOS] kernel API

RE: [ECOS] kernel API

[Koeller, T.]

The current C API appears to be a 1:1 mapping of the C++
interfaces onto C functions, it does not provide much
abstraction anyway. I also cannot see how it would do this.
Imagine a thread class were extended to require an additional
constructor argument. This could be hidden by the C API
function by changing cyg_thread_create() to provide a
default value for the new parameter, preserving te original
function signature, and adding a new function named
cyg_thread_create_ex() that takes an additional argument.
However, C++ provides much more elegant mechanisms to
achieve this without namespace pollution (arguments with
default values, overloading), so the 'abstraction' provided
by the C API would in fact make things more difficult, not
easier.

I do not want to overly stress this point. I will continue to
use the C++ API, as will others. I guess the probability of
the C++ interfaces being removed and replaced by something
entirely different is rather low anyway, so it is probably
not all that important...

tk
----------------------------------------------- 
Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 
Germany 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390

mailto:Thomas.Koeller@baslerweb.com 
http://www.baslerweb.com 




> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
> Sent: Tuesday, April 22, 2003 11:28 PM
> To: Koeller, T.
> Cc: ecos-discuss (E-Mail)
> Subject: Re: [ECOS] kernel API
> 
> 
> Koeller, T. wrote:
> > [snip]
> > For all the reasons listed above, I am raising the
> > topic again. My proposal is to award the status of
> > an officially supported API to the C++ kernel API, too.
> 
> The problem is that we have to have flexibility to change how 
> the kernel 
> _implementation_ works, even if the _interface_ has to say 
> the same. Right 
> now the C++ stuff is just directly what is required by the 
> implementation. 
> Defining the internal API to be "official" will tie our hands 
> unreasonably 
> in the future if the API is to have any stability (and 
> stability is one of 
> the defining features of an API really!).
> 
> If there was a C++ API, it would have to be a separate veneer 
> over the 
> internal C++ API. In the first instance, using inline 
> functions etc. this 
> could be pretty much a  burden-free veneer over the internal 
> C++ API, but 
> if sensibly designed would give us the flexibility to change the 
> implementation without worrying about messing up the interface.
> 
> So that _could_ be a slight improvement over the C API by 
> removing some of 
> the overhead. But no-one has yet done such a thing of course 
> :-), and it 
> _isn't_ just a case of defining one to the other since there 
> does have to 
> be some level of abstraction in order to hide the internals.
> 
> Given that people are either happy with the C API, or not too worried 
> about using the internal C++ API directly, this hasn't been a 
> priority for 
> any of the main developers in the past. Personally I would have no 
> objections to a sensibly designed C++ API that fulfilled the 
> requirements 
> above. Nick G obviously might have a little bit more to say in how it 
> should be done of course ;-).
> 
> Jifl
> -- 
> eCosCentric    http://www.eCosCentric.com/    The eCos and 
> RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- 
> Opinions==mine
> 

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] kernel API

[Jonathan Larmour]

Koeller, T. wrote:
> The current C API appears to be a 1:1 mapping of the C++
> interfaces onto C functions, it does not provide much
> abstraction anyway.

It does because things like cyg_handle_t's and cyg_thread's are opaque (if 
people try and use the definitions in kapidata.h it's on their own head!).

The same thing would apply to a C++ API. The individual members from the 
underlying implementation would not be exposed - in fact C++'s access 
control would do this better than the C API could.

But we wouldn't be providing any more functionality than the C API really 
- just making it more efficient for C++ users, and making it fit into the 
OO paradigm better.

> I do not want to overly stress this point. I will continue to
> use the C++ API, as will others. I guess the probability of
> the C++ interfaces being removed and replaced by something
> entirely different is rather low anyway, so it is probably
> not all that important...

Well that's indeed one of the reasons why we are where we are today :-). 
But if someone wants to come up with a serious proposal for a C++ API 
(with the intention of implementing whatever results from the discussion 
:-)), naturally it will be considered!

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] kernel API

[Sergei Organov]

Jonathan Larmour <jifl@eCosCentric.com> writes:
> Sergei Organov wrote:
> > Nick Garnett <nickg@eCosCentric.com> writes:
> >>Sergei Organov <osv@javad.ru> writes:
> > [...]
> >>>Besides, the C++ stuff has a rather boring deficiency. I do use C++ stuff
> >>>directly (through my own C++ wrappers), but I still can't find any
> >>>reasonable answer to the question why condvars and mutexes have been put
> >>>into the same header 'mutex.hxx'. I don't think anybody would expect to
> >>>find a 'ConditionVariable' class in a 'mutex' header ;)
> >>>
> >>
> >>The implementations are in the same file, so they also share a header.
> > IMHO that's also a mistake though I don't care much where implementations
> > are.
> 
> > I don't like the situation when all source files that use mutexes but don't
> > use condvars are polluted with the condvars declarations.
> 
> I think you mean it might be a mistake if it was an official API ;-P.

I definitely meant it's a mistake by itself though its significance is
proportional to the number of source files that use mutexes but no condvars.
It's indeed not a big deal unless it's not an official API, so I mentioned
it in this particular thread.

> Although "polluted" is overstating it anyway.

Probably. English is not my mother's language so I may choose wrong terms
sometimes, sorry. In fact I meant I don't like unnecessary compile-time
dependencies.

> Namespacing is something unfortunately eCos has been very very lax about.
> Just try and declare "int interrupt_end;" in any application at least!

I use interruptEnd (sometimes referred to as "camel") naming convention that
doesn't interfere with most of libraries ;) though I thought eCos has been very
careful about adding cyg_/CYG_ prefix everywhere.

-- 
Sergei.


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] kernel API

[Jonathan Larmour]

Sergei Organov wrote:
> Nick Garnett <nickg@eCosCentric.com> writes:
> 
> 
>>Sergei Organov <osv@javad.ru> writes:
> 
> [...]
> 
>>>Besides, the C++ stuff has a rather boring deficiency. I do use C++ stuff
>>>directly (through my own C++ wrappers), but I still can't find any
>>>reasonable answer to the question why condvars and mutexes have been put
>>>into the same header 'mutex.hxx'. I don't think anybody would expect to
>>>find a 'ConditionVariable' class in a 'mutex' header ;)
>>>
>>
>>The implementations are in the same file, so they also share a header.
> 
> IMHO that's also a mistake though I don't care much where implementations are.
> I don't like the situation when all source files that use mutexes but don't
> use condvars are polluted with the condvars declarations.

I think you mean it might be a mistake if it was an official API ;-P. 
Although "polluted" is overstating it anyway. Namespacing is something 
unfortunately eCos has been very very lax about. Just try and declare "int 
interrupt_end;" in any application at least!

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] kernel API

[Sergei Organov]

Nick Garnett <nickg@eCosCentric.com> writes:

> Sergei Organov <osv@javad.ru> writes:
[...]
> > Besides, the C++ stuff has a rather boring deficiency. I do use C++ stuff
> > directly (through my own C++ wrappers), but I still can't find any
> > reasonable answer to the question why condvars and mutexes have been put
> > into the same header 'mutex.hxx'. I don't think anybody would expect to
> > find a 'ConditionVariable' class in a 'mutex' header ;)
> > 
> 
> The implementations are in the same file, so they also share a header.

IMHO that's also a mistake though I don't care much where implementations are.
I don't like the situation when all source files that use mutexes but don't
use condvars are polluted with the condvars declarations.

> This is because they constitute a single synchronization mechanism,
> and therefore belong together.

I'd agree if one couldn't be used without another. However, while condvars
indeed can't be used without mutexes, mutexes are pretty useful without
condvars, so IMHO the most straightforward and correct approach is to have
separate 'mutex.cxx/mutex.hxx' and 'condvar.cxx/condvar.hxx', where either
'condvar.cxx' or 'condvar.hxx' includes 'mutex.hxx'.

-- 
Sergei.


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] kernel API

[Nick Garnett]

Sergei Organov <osv@javad.ru> writes:

> Jonathan Larmour <jifl@eCosCentric.com> writes:
> 
> > Koeller, T. wrote:
> > > [snip]
> > > For all the reasons listed above, I am raising the
> > > topic again. My proposal is to award the status of
> > > an officially supported API to the C++ kernel API, too.
> > 
> > The problem is that we have to have flexibility to change how the kernel
> > _implementation_ works, even if the _interface_ has to say the same. Right
> > now the C++ stuff is just directly what is required by the implementation.
> > Defining the internal API to be "official" will tie our hands unreasonably
> > in the future if the API is to have any stability (and stability is one of
> > the defining features of an API really!).
> 
> Besides, the C++ stuff has a rather boring deficiency. I do use C++ stuff
> directly (through my own C++ wrappers), but I still can't find any reasonable
> answer to the question why condvars and mutexes have been put into the same
> header 'mutex.hxx'. I don't think anybody would expect to find a
> 'ConditionVariable' class in a 'mutex' header ;)
> 

The implementations are in the same file, so they also share a header.
This is because they constitute a single synchronization mechanism,
and therefore belong together. 

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] kernel API

[Sergei Organov]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Koeller, T. wrote:
> > [snip]
> > For all the reasons listed above, I am raising the
> > topic again. My proposal is to award the status of
> > an officially supported API to the C++ kernel API, too.
> 
> The problem is that we have to have flexibility to change how the kernel
> _implementation_ works, even if the _interface_ has to say the same. Right
> now the C++ stuff is just directly what is required by the implementation.
> Defining the internal API to be "official" will tie our hands unreasonably
> in the future if the API is to have any stability (and stability is one of
> the defining features of an API really!).

Besides, the C++ stuff has a rather boring deficiency. I do use C++ stuff
directly (through my own C++ wrappers), but I still can't find any reasonable
answer to the question why condvars and mutexes have been put into the same
header 'mutex.hxx'. I don't think anybody would expect to find a
'ConditionVariable' class in a 'mutex' header ;)

-- 
Sergei.


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] kernel API

[Jonathan Larmour]

Koeller, T. wrote:
> [snip]
> For all the reasons listed above, I am raising the
> topic again. My proposal is to award the status of
> an officially supported API to the C++ kernel API, too.

The problem is that we have to have flexibility to change how the kernel 
_implementation_ works, even if the _interface_ has to say the same. Right 
now the C++ stuff is just directly what is required by the implementation. 
Defining the internal API to be "official" will tie our hands unreasonably 
in the future if the API is to have any stability (and stability is one of 
the defining features of an API really!).

If there was a C++ API, it would have to be a separate veneer over the 
internal C++ API. In the first instance, using inline functions etc. this 
could be pretty much a  burden-free veneer over the internal C++ API, but 
if sensibly designed would give us the flexibility to change the 
implementation without worrying about messing up the interface.

So that _could_ be a slight improvement over the C API by removing some of 
the overhead. But no-one has yet done such a thing of course :-), and it 
_isn't_ just a case of defining one to the other since there does have to 
be some level of abstraction in order to hide the internals.

Given that people are either happy with the C API, or not too worried 
about using the internal C++ API directly, this hasn't been a priority for 
any of the main developers in the past. Personally I would have no 
objections to a sensibly designed C++ API that fulfilled the requirements 
above. Nick G obviously might have a little bit more to say in how it 
should be done of course ;-).

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] kernel API

[Grant Edwards]

On Tue, Apr 22, 2003 at 05:42:16PM +0200, Koeller, T. wrote:

> Now everyone programming for eCos has a C++ compiler,
> and I am quite sure that a significant number of us
> code their applications in C++ (at least I do). In
> this case using the C API only complicates things; I
> get additional overhead and the above-mentioned
> problems, but no benefits at all.
> 
> For all the reasons listed above, I am raising the
> topic again. My proposal is to award the status of
> an officially supported API to the C++ kernel API, too.

FWIW, I know that several of my customers are using the C++
kernel API also.

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] kernel API

[Koeller, T.]

Hi,

the question of which kernel API is the one officially
supported has been discussed before. As I remember,
the result of all those discussions was that only the
C API, as defined in kapi.h, has the status of an
officially supported API, and using the C++ kernel
API directly is discouraged.

The way that kapidata.h and thread.hxx declare the
same things in different ways and require both
declarations to always be in sync contradicts just
about everything that is generally considered good
programming practice ;-) It is IMO an ugly kludge, error-
prone and has indeed caused the very problems one would
expect during the transition from gcc-2.x to gcc-3.x.

Now everyone programming for eCos has a C++ compiler,
and I am quite sure that a significant number of us
code their applications in C++ (at least I do). In
this case using the C API only complicates things; I
get additional overhead and the above-mentioned
problems, but no benefits at all.

For all the reasons listed above, I am raising the
topic again. My proposal is to award the status of
an officially supported API to the C++ kernel API, too.

tk
----------------------------------------------- 
Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 
Germany 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390

mailto:Thomas.Koeller@baslerweb.com 
http://www.baslerweb.com 



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss