From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31314 invoked by alias); 24 Jun 2005 07:48:44 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 31296 invoked by uid 22791); 24 Jun 2005 07:48:37 -0000 Received: from smtp.e7even.com (HELO smtp.e7even.com) (83.151.192.5) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Fri, 24 Jun 2005 07:48:37 +0000 Received: (qmail 24602 invoked from network); 24 Jun 2005 07:48:33 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost with SMTP; 24 Jun 2005 07:48:33 -0000 Received: from smtp.e7even.com ([127.0.0.1]) by localhost (gateway [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 21695-09 for ; Fri, 24 Jun 2005 08:48:32 +0100 (BST) Received: (qmail 24595 invoked from network); 24 Jun 2005 07:48:32 -0000 Received: from unknown (HELO localhost.localdomain) (83.151.202.178) by smtp.e7even.com with SMTP; 24 Jun 2005 07:48:32 -0000 Date: Fri, 24 Jun 2005 07:48:00 -0000 To: ecos-discuss@ecos.sourceware.org References: <20050622182844.7476.qmail@web88210.mail.re2.yahoo.com> <200506231104.32693.sinany@beko.com.tr> <20050623090215.GF12265@lunn.ch> <200506231325.41733.sinany@beko.com.tr> <20050624000348.F2D2E49B78@rivatek.dnsalias.net> From: "Richard Forrest" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20050624000348.F2D2E49B78@rivatek.dnsalias.net> User-Agent: Opera M2/7.54 (Linux, build 955) Subject: [ECOS] Re: ECOS - MIPS X-SW-Source: 2005-06/txt/msg00230.txt.bz2 I may have given the impression that I was unhappy with eCos. That could not be further from the truth. I love its compile-time configuration system. It is a really clever concept, beautifully and cleanly implemented. Altogether it is a fantastic piece of software and I would not be wasting my time learning to use it if I thought otherwise. I am genuinely incredibly grateful to all who have contributed and released it under the GPL for us all to enjoy. You probably get fed up with newbies telling you what is wrong with eCos without putting in the effort of understanding it first. And I would agree with you there. I am not going to make any criticisms (if at all) until I am a lot more experienced with eCos than I am today. My point is that criticisms should not be discouraged. Sometimes people with different software backgrounds might see something that the eCos community might miss. Encouraging people to put forward concrete proposals for discussion (not necessarily just patches) might be a good way to sort the good ideas from those that are misguided. By submitting a concrete proposal a critic can show they understand eCos, the issue they are criticising and that they have a carefully considered and practical solution. Richard Forrest On Thu, 23 Jun 2005 19:03:48 -0500, Grant Edwards wrote: > In gmane.os.ecos.general, you wrote: > >> My initial impressions were that the coding style in eCos was >> rather old fashioned. > > Are you referring to the coding style (i.e. indentation, > variable names, etc.) or the actual architecture and design? > >> We are probably both used to the amazing things that can be >> done with STL, boost, template metaprogramming etc. However I >> realise that many of these libraries and techniques are not >> appropriate for embedded programming. > > Depends on the system. > >> On the other hand it is possible that some modern C++ >> techniques could be useful in this context. > > Like what? > > Since eCos is the only RTOS kernel i know of written in C++, it > would appear it's leading the pack in using "some modern C++ > techniques. I'm no C++ expert, but the design and > implimentation of the eCos kernel looked pretty nifty what with > those objects and classes and whatnot. > > Most of the drivers, OTOH, are pretty much what drivers always > are: nasty low-level C code. > > Embedded systems development is just plain hard compared to > many other sorts of SW development. It requires a lot of > knowlege about the platform hardware, the tools, and the > problem domain. There is no silver bullet. > >> Currently I do not have enough experience of embedded >> programming to give an opinion. >> >> Could you provide an example of how some part of eCos could be >> improved using a specific design pattern. This could form the >> basis of a more focused discussion of the benefits of what you >> are proposing. If your ideas are practical and would genuinely >> make eCos more easily configured then I am certain that the >> eCos maintainers would be very happy to help you incorporate >> them. > > I'm certain they would. > -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss