From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17865 invoked by alias); 7 Nov 2003 10:00:59 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 17851 invoked from network); 7 Nov 2003 10:00:56 -0000 Received: from unknown (HELO londo.lunn.ch) (80.238.139.98) by sources.redhat.com with SMTP; 7 Nov 2003 10:00:56 -0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1AI3Q3-0006t9-00; Fri, 07 Nov 2003 11:00:43 +0100 Date: Fri, 07 Nov 2003 10:00:00 -0000 To: Peter Lister Cc: Andrew Lunn , ecos-discuss Message-ID: <20031107100043.GA25725@lunn.ch> Mail-Followup-To: Peter Lister , Andrew Lunn , ecos-discuss References: <1068078698.5094.351.camel@localhost.localdomain> <20031106093854.GB20673@lunn.ch> <1068165203.5812.537.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1068165203.5812.537.camel@localhost.localdomain> User-Agent: Mutt/1.5.4i From: Andrew Lunn Subject: Re: [ECOS] Newbie feedback and braindump. X-SW-Source: 2003-11/txt/msg00083.txt.bz2 Again pruned... On Fri, Nov 07, 2003 at 12:33:24AM +0000, Peter Lister wrote: > On Thu, 2003-11-06 at 09:38, Andrew Lunn wrote: > > > A technical point first. Be careful of your terminology. You are > > mixing up the words targets and templates. > > I am very, very careful with my terminology, often to the point where > I'm accused of pedantry. One of things I am trying to convey is that the > help for newcomers is poor at pointing out the target / template > distinction, making it harder than necessary to perceive decisions. I try to understand your POV i went back to the documentation. And you are right! The GUI tool appear to me to be using the terminology at least inconsistently and possibly wrongs. Its hard for me to be sure. Im definitely a CLI guy and don't even have the ConfigTool installed. But looking at http://ecos.sourceware.org/docs-latest/user-guide/using-configtool-windows-linux.html The label say "Figure 11-2 Template Selection". But the dialog box allows you to select much more than the template. A much better name would be "Basic configuration Selection". The section of the dialog box called "Hardware" allows you to select the target. The section "Packages" appears to allow you to select templates. Like i said, i don't know the ConfigTool too well. Hopefully somebody like John will jump in here and correct/confirm what im says. As an aside. My POV is from using ecosconfig and looking at the actual sources. This very clearly uses the terminology as i defined it. eg look a the help information for ecosconfig. lunn@londo:~/eCos/work$ ecosconfig --help Usage: ecosconfig [ qualifier ... ] [ command ] commands are: list : list repository contents new TARGET [ TEMPLATE [ VERSION ] ] : create a configuration target TARGET : change the target hardware template TEMPLATE [ VERSION ] : change the template add PACKAGE [ PACKAGE ... ] : add package(s) or read ecos.db, the database of packages and targets. > > You mistake here is mixing up template and target. You selected a > > target, not a template. > > I selected a template. Sorry, but that's how the GUI presents the > ability to build a working library for a target. Now i understand how this has happened...... > > > Well, the instructions say: > > > > $ cd > > $ mkdir synth_build > > $ cd synth_build > > > > This will result in an new empty directory. Always. > > "somewhere suitable" is not clearly defined or even hinted at, so I > *had* to interpret what the docs would have me do. I now realise that > the intention was to suggest that a newcomer should work in a new > directory. But the doc didn't *say* that (we can argue forever about > what was *meant*, but I can only go by what I *read*). Please suggest some text which would help explain this. Better still, a patch to the SGML would be great. You can find it in packages/hal/synth/arch/current/doc/synth.shml. > While we're here, I'd suggest that using "angle brackets" > is not a good way to represent a name substitution on a Unix command > line. This is something that is consistent though out the documentation. Its also not a Unix issue. M$ would act in a similar way if you left in the < or > characters. > > I think it depends on what direction you are coming from, Unix or > > Windows. If you are a M$ Windoze person, i'd suggest trying to use the > > GUI to start with. If you are a Unix person, use ecosconfig. > > Here we do agree, so I suggest that this sentence appears right at the > top of the build docs, along with the simple ecosconfig scripts to build > "Hello World" from the MLB web pages. I will add some comments to Chapter 11. > > > I happen to be fairly motivated to investigate eCos, and I do know that > > > it actually works, so I persevered, but blimey it was uphill work. It > > > wouldn't be hard to make the ecos-install.tcl ask "would you like to > > > build the Synthetic Linux demo" and run Hello World out of the packet, > > > > It could do that, but its a bad idea. > > I'm happy to discuss this, but you are making an undefensible assertion, > since I must observe that this just isn't true. I am by definition > right, since it would have been a good idea FOR ME. I really am 100% > authoritative in the area of what I find useful. :) I think you need to look back at this in a couple of months time when you have some more experience with eCos. Ask the question "Did i learn something useful during the time spent installing eCos which i would not have learnt if it was all pre-installed?" It might not seem useful now, but i think it will be once you learn more and start doing some real work. > I *definitely* see some point in have a "run-time" eCos kit. If someone > develops a neat utility that many people would like to put on a target > system, then it's fairly clear that end-users will need to be able to > build and install a target specific version on whatever they happen to > have available. Embedded systems don't work like that. Each embedded system is different. I doubt you could produce a neat utility which is totally independent of what system it runs in. Also, ask the question, who are the end-users of embedded systems? Its the house(wife/husband) programming his washing machine for 40C degree wash, its an officer worker pressing a button to select the floor she want the lift to take her to. Its a music lover listening to there MP3 player? How many of these end users know how to put new software into there washing machine, lift or MP3 player? eCos is for the highly educated software engineer, not the end user. > > They need to know all the inside details so they can modify it to > > there own needs. > > Really? That's an interesting comment about a code tree which is fairly > heavily object oriented, and I'd sort of thought the idea of things like > HAL was *precisely* so that one does NOT need to know the details on the > other side of the abstraction... Abstractions are two sided. If you port eCos to a new target, you probably have to write a new HAL or at least modify an existing HAL. The abstraction allows you to do this without having to know about the kernel. But some people need to modify the kernel to meet there needs. eg add functionality to how POSIX signals are delivered is a recent example. People have modifying existing serial drivers to make them more responsive at the cost of CPU load, or the exact opposite, less CPU and less responsive. This has come from application requirements. You have the sources to eCos and can make it do what you need it to do. Its not a black box you have no control over. > Well, amongst other things, I'd have been able to look at a guaranteed > working RPM install script and I'd have known that all the right pieces > were in place. I've yet to see an introductory course where the first > step required much more than "gcc hello.c"; certainly not a requirement > to - say - recompile libc. On a desktop system or server you have no need to recompile libc. For embedded system, especially configurable embedded systems, recompiling libc is normal practice. I might want to trade speed for code size because i have a small FLASH? Or my application may be running a little too slow, so i recompile libc for speed. eCos has default settings, but every embedded system will probably need tuning to match the requirements of the application and hardware. You need to know how to do this and its a fundamental part of eCos. Thats what the C in eCos stands for, Configurable. > > Now, eCos is open source. This includes the documentation and the > > installation scripts. If you can make them better, please do send us > > patches. > I may very well do so if eCos will do what I'm after, but this does beg > the question of whether my patches would be accepted - and it does seem > that you (one of the maintainers, right?) wouldn't necessarily agree > with my POV. Yes, im a maintainer. As to if i would accept your patches, the answer is probably yes. Look in the ecos-patches archive. See how many contributed patches i've commit and how many i've rejected. Andrew -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss