public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Sergei Gavrikov <sergei.gavrikov@gmail.com>
To: Richard Rauch <rrauch@itrgmbh.de>
Cc: eCos Discuss <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] Re: is eCos dying?
Date: Wed, 14 Oct 2015 23:05:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1510150204010.27578@sg-laptop> (raw)
In-Reply-To: <00d901d1000b$cadebbd0$609c3370$@itrgmbh.de>

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

  parent reply	other threads:[~2015-10-14 23:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-06  7:51 Richard Rauch
2015-10-06 12:59 ` Mikhail Matusov
2015-10-07  9:59   ` AW: " Richard Rauch
2015-10-12 23:57 ` Jonathan Larmour
2015-10-13 12:31   ` David Fernandez
2015-10-14  0:57     ` Frank Pagliughi
2015-10-13 17:20   ` Grant Edwards
2015-10-13 19:38 ` Alex Schuilenburg
2015-10-14 23:05 ` Sergei Gavrikov [this message]
     [not found] <349750926.354427.1443800101065.JavaMail.yahoo@mail.yahoo.com>
2015-10-03  8:15 ` John Dallaway
2015-10-04  8:30   ` Stanislav Meduna
2015-10-04 15:00     ` Grant Edwards

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=alpine.DEB.2.00.1510150204010.27578@sg-laptop \
    --to=sergei.gavrikov@gmail.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=rrauch@itrgmbh.de \
    /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).