Re: [ECOS] eCos build fails when INET support is disabled

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Jifl" == Jonathan Larmour <jifl at eCosCentric dot com> writes:

    Jifl> Gary D. Thomas wrote:
    >> 
    >> A long time ago, in the mists of eCos' birth, we had plans (and even
    >> some attempts at implementing) randomized, full coverage of all 
    >> configuration options.

    Jifl> Actually some pointy hairs had those plans and we kept
    Jifl> trying to hit them with a clue stick ;-).

    >> As eCos grew this became an exponentially large problem and
    >> over time was allowed to wither. If one wanted to attempt this
    >> today, we'd enjoy seeing the results :-)

    Jifl> The problem is that many of the options _can't_ sensibly be
    Jifl> tested unless you have either valid hardware support or an
    Jifl> appropriate application. Take the option to enable an
    Jifl> external kernel instrumentation buffer for example.

    Jifl> The most anyone ever proposed as a sensible solution to this
    Jifl> was some annotation in CDL that marked whether a config
    Jifl> option could be changed for testing, but I recall even that
    Jifl> was rejected as too burdensome.

Actually, these ideas were not entirely restricted to the pointy
haired ones. Building and running pseudo-random configurations is a
way of testing the CDL, especially the "requires" constraints, as well
as testing the eCos code itself. It would be in addition to, not
instead of, testing a number of fixed permutations. Of course it would
only ever cover a tiny percentage of all possible configurations, but
would still be an improvement.

Most of the benefits could be achieved by only using one or a small
number of targets, perhaps just the synthetic target. Re.
hardware-specific options, another approach would be to define an
option "default hardware setup" which requires various other settings,
Users would first have to disable this option before they could start
manipulating hardware-specific stuff - that might prove a generally
useful safeguard anyway. The script that generates random
configurations would only need special knowledge of this one option
rather than of all special hardware-specific options. There will be a
small number of other special cases, like the external kernel
instrumentation buffer, but the number should be manageable.

Initially there could be a fairly high failure rate because of missing
constraints in the CDL data, but those should be fixed anyway.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss