Re: [ECOS] Newbie feedback and braindump.

[Andrew Lunn <andrew at lunn dot ch>]

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 <somewhere suitable>
> > $ 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