Network config issue

[Charles-Antoine Gauthier]

Joel Sherrill wrote:
> 
> Jake Janovetz wrote:
> >
> > How would the configuration be changed after compile, then?
> > Are you saying that once you build the application, you're stuck
> > with that network configuration?  If this is the case, then I
> > strongly disagree.  It would kinda suck if Red Hat shipped
> > Linux with one network configuration.
> 
> No it would be a default configuration used normally just
> to satisfy linking.  You can't tell it now but there is
> already one in librtems.  See c/src/libmisc/dummy.

Exactly. Each app should then be able to override the config info. I am
trying to not supply the config info for each possible board in each
test. I want to centralize the info, so the end user can edit a single
location before building the test suite.

> 
> > Same goes with an embedded OS that may go into devices that
> > should be reconfigurable.  I must be misunderstanding something,
> > though.
> 
> This does not diminish the reconfigurability.  It just sets things
> up so it is easier to build tests and run autoconf checks.
> 

BTW, my BSPs get their network config from NVRAM by default, not from
the built-in image. Still, the linker wants something... Beside, by
setting jumpers on the MVME167, the end-user can always revert to the
built-in values.

> Charles... this has not been merged for 1 very important reason.
> If you have a default network configuration, then the autoconf test
> for select() will pass and believe RTEMS' select works for ALL
> cases.  The RTEMS select() implementation only works on sockets
> so this would be broken.  I know this impacts TCL.
> 

OK. But I am not sure this applies. What I need is access to some
end-user supplied config info to stuff into the network config
structures. The structures are only included for those tests that need
it. I don't see why autoconf would detect them during configuration of
rtems (or am I missing something?) 

> Ignoring the above breakage, I think it is the right thing to do.
> 
> Also .. I would like to see some automated networking tests and
> if we had a loopback configuration that was sufficient to run
> TCP/IP on a non-networked device, then we could have these.
> 
> --joel
> 
> >    Jake
> >
> > On Mon, Sep 25, 2000 at 09:29:47AM -0400, Charles-Antoine Gauthier wrote:
> > > Has there been any work done to move the network config info into the
> > > RTEMS main source tree somehow?
> > >
> > > I am trying to build a new library to support running the libgcj/mauve
> > > tests using the dejagnu framework. This library is basically a C stub
> > > that calls a C function emitted by jvgenmain, which in turns calls the
> > > main Java function. My problem is that I am now introducing a new
> > > library in RTEMS, and that the tests need to have the network
> > > configuration defined. Hence, I would like to have a mechanism by which
> > > the network configuration is defined at the time RTEMS is build.
> > >
> > > I believe that Eric Norum was thinking about integrating the networking
> > > tests into the main tree. The same issue would occur in that situation.
> > >
> > > How about putting the network config info in the bsp-specific config
> > > files in rtems/make/custom in the form of preprocessor constants? The
> > > structures to initialize the network can then be initialized with these
> > > constants.
> > >
> > > --
> > > Charles-Antoine Gauthier
> > > Institute for Information Technology   Institut de technologie de
> > > l'information
> > > National Research Council of Canada    Conseil national de recherches du
> > > Canada
> >
> > --
> >    janovetz at uiuc.edu    | How can it be that mathematics, being after all a
> >  University of Illinois | product of human thought independent of experience,
> >                         | is so admirably adapted to the objects of reality?
> >         PP-ASEL         |                                  - Albert Einstein
> >
> > Disclaimer: The policies of this University certainly do not reflect my
> >             own opinions, objectives, or agenda.
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985

-- 
Charles-Antoine Gauthier
Institute for Information Technology   Institut de technologie de
l'information
National Research Council of Canada    Conseil national de recherches du
Canada