[ECOS] kernel API
Tue Apr 22 21:32:00 GMT 2003
Koeller, T. wrote:
> 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 ;-).
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
More information about the Ecos-discuss