From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76353 invoked by alias); 14 Oct 2015 23:05:05 -0000 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 Received: (qmail 76330 invoked by uid 89); 14 Oct 2015 23:05:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,MALFORMED_FREEMAIL,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-wi0-f171.google.com Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 14 Oct 2015 23:05:02 +0000 Received: by wicgb1 with SMTP id gb1so4599240wic.1 for ; Wed, 14 Oct 2015 16:04:59 -0700 (PDT) X-Received: by 10.180.12.241 with SMTP id b17mr7685513wic.55.1444863899514; Wed, 14 Oct 2015 16:04:59 -0700 (PDT) Received: from sg-laptop ([178.121.62.218]) by smtp.gmail.com with ESMTPSA id lb10sm12736186wjc.9.2015.10.14.16.04.58 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 14 Oct 2015 16:04:58 -0700 (PDT) Date: Wed, 14 Oct 2015 23:05:00 -0000 From: Sergei Gavrikov To: Richard Rauch cc: eCos Discuss In-Reply-To: <00d901d1000b$cadebbd0$609c3370$@itrgmbh.de> Message-ID: References: <00d901d1000b$cadebbd0$609c3370$@itrgmbh.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Subject: Re: [ECOS] Re: is eCos dying? X-SW-Source: 2015-10/txt/msg00013.txt.bz2 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