[ECOS] Re: is eCos dying?

[Sergei Gavrikov]

On Tue, 6 Oct 2015, Richard Rauch wrote:

> It seems, they will not put any port to official open source
> repository if it could disturb commercial interests
> (eCosCentric/eCosPro...).

I am not affiliated with eCosCentric/eCosPro somehow. Nohow.

> I will give just one example when we tried to make a port public:
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001649 further
> activities, if you search for in detail:
> http://bugs.ecos.sourceware.org/buglist.cgi?quicksearch=at91sam9G45
> beside this there was email traffic as well with the maintainers, but
> finally there was no success!

Just now I looked on one issue (half-hour only). I tried the latest BUG
from the 'at91sam9G45' set, this one

  http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001796

The said:

>> One main objective of this patch is to ensure the existing ports do
>> not break because of these extensions.

Getting ahead, I must say that I never try to review any patches which
do massive changes in HAL, especially when a delta for *.S sources takes
a few screens and this is such a case, look, please

  http://bugs.ecos.sourceware.org/attachment.cgi?id=2125&action=diff

This surely does infect many (if not all) ARM targets. Why I never try?
At first I have no such competence and secondly I have no test farm for
the most infected hardware. Could you play an assembler code in a mind?
I cannot, sorry. I can try to check such a proof

>> One main objective of this patch is to ensure the existing ports do
>> not break because of these extensions.

So, I did a proper checkout and applied the patches. No build errors.
Great. I got hold eCos ARM7TDMI target, flashed "new" RedBoot image,
Redboot started. Great! Then I downloaded `tm_basic' on the target, 'go'
and the test hung. GDB session: the same (I could not even break the
test). I rolled back the changes, re-built RedBoot and eCos tests
(notice that checkout was a medium of 2012) and got all things worked.

Q: Should a maintainer take JTAG and continue to deepen in the "issue"
   in such cases when new things do break the existing things?

Do you really think such a delta (only arm/arch part)

 hg diff --stat packages/hal/arm/arch/current/
  packages/hal/arm/arch/current/include/hal_arch.h |   20 +-
  packages/hal/arm/arch/current/include/hal_intr.h |  174 +++------
  packages/hal/arm/arch/current/src/arm_stub.c     |    5 +-
  packages/hal/arm/arch/current/src/context.S      |   45 +-
  packages/hal/arm/arch/current/src/hal_misc.c     |    3 +-
  packages/hal/arm/arch/current/src/vectors.S      |  437 +++++++++-------------
  6 files changed, 291 insertions(+), 393 deletions(-)

can break nothing? I think this BUG could not found enthusiasts among
the maintainers as they even more skilled than me. Perhaps, they
understood: the patch will break important things even without a live
experiment.

I believe that Bernd Edinger (Hi Bernd!) did a herculean job and new
folks would get new horizons with new AT91 families. But what's about
old folk, old targets? When somebody ask, is eCos dying? I read, is old
folk (okay targets :-) dying? Sure, but that takes a time. Perhaps, we
have to make obsolete some targets. What criteria is? Age? Poll? I.e.
majority against maintainers?

Back to at91sam9 distribution. What I would advice? I would advise to
create EPK (eCos package) which will make obsolete "old" hardware and
offer "new" stuff. New folks be happy (no mess with patches). Why not?

What do I regret? I regret that in 2013 I have not found even a
half-hour for testing. But most likely I've seen this BUG and thought,
this work has no chance to be applied AS IS, it needs a few man-months
of work the experts and I am not big expert here.

Sergei

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