This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Notes on static configuration of an eCos network interface


>>>>> "Huge" == Hugo 'NOx' Tyson <hmt@cygnus.co.ukx> writes:

    Huge> Bart Veer <bartv@redhat.com> writes:
    >> >>>>> "Huge" == Hugo 'NOx' Tyson <hmt@cygnus.co.ukx> writes:
    >> >> and _not_ "server", which is a meaningless idea in the absence of
    >> >> BOOTP. 
    >> 
    Huge> Indeed it is meaningless BUT several of our test programs
    Huge> use the server address as "someone to talk to" so it's worth
    Huge> IMHO having it settable in static configurations. Eg. ftp
    Huge> test, tftp test, ping tests and the like expect the "server"
    Huge> to be a nice freindly chap.
    >> 
    >> That is horrible (IMHO). Setting up such addresses should be handled
    >> by the test harness, e.g. by updating a suitable variable via gdb, and
    >> not by configuration options. Not possible right now, but it will have
    >> to be addressed as the test harness progresses.

    Huge> I was under the impression that we aimed to let customers
    Huge> test their own configurations, by providing test programs
    Huge> which will work correctly in such a configuration. What you
    Huge> suggest may be cleaner, but it directly defeats the goal of
    Huge> being able to automatically run at least *some* of the
    Huge> network tests.

Configuring the host-side environment (which host serial port gets
used to talk to the target board, what local machines can be used for
network operations, how to access the webcam so that the test harness
can check that LEDs flash when they are supposed to, ...) should be
separate from configuring the target-side. At the point that a test
case is run there should be a suitable transfer of information. A
change in the host-side setup should not require any target-side
configury or rebuilding.

For example, if a technical support customer were to send in a
configuration savefile that is causing problems then we should be able
to rebuild directly from that savefile, with no need to edit the
target-side configuration to match our host-side setup.

This is not possible right now because we do not do a very good job of
host-side setup configury yet. Until then ad hoc approaches such as
server address config options may have to be used, but long term there
are better solutions.

Bart

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]