Network config issue

[Charles-Antoine Gauthier]

Joel Sherrill wrote:
> 
> Eric Norum wrote:
> >
> > 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.
> 
> Do you have a custom init task/configuration table for this?  If so,
> then
> Eric's proposal below is the best alternative.

I do. The stub sets the defaults for the "worst case" test. I currently
supply my own network initialization structures. I am looking for a
place to put the default values. Confdefs could be used to define the
initialization structures. I don't believe that it is the right place to
supply the default values to put in the structures.

Are we then suggesting something like
rtems/c/src/tests/support/include/networkconfig.h?

> 
> > > 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.
> > >
> >
> > No, I don't think that's the best place.  The network configuration
> > should be selectable at application-build time, not at BSP-build time.

OK. I think that this is exactly what I was advocating
(test==application). But I want the end-users default config info.

> > For the BSP-specific stuff there are macros for
> > RTEMS_BSP_NETWORK_DRIVER_NAME and RTEMS_BSP_NETWORK_DRIVER_ATTACH.
> >
> > If anything, the network configuration should be merged into confdefs.h
> > with a bunch of preprocessor macros to set the appropriate fields, eg.:
> >         CONFIGURE_RTEMS_ENABLE_NETWORKING       (0 or undefined, no network
> > configuration done)
> >         CONFIGURE_RTEMS_NETWORKING_USE_BOOTP
> >         CONFIGURE_RTEMS_NETWORKING_ENABLE_LOOPBACK      (0 or undefined, no loopback
> > interface)
> >         CONFIGURE_RTEMS_NETWORKING_TASK_PRIORITY
> > etc.
> 
> Eric .. would it make sense to include enough network/confdefs entries
> to have both a loopback and a single HW interface?
> 
> What about a 2nd interface so a router type setup is very simple?  This
> might (unfortunately) requires duplicate entries with names like
> "CONFIGURE_RTEMS_NETWORKING_USE_BOOTP_SECOND_IFACE" or some such.
> 
> ALso if you say "don't use Bootp", then what should happen if you
> don't set things like host name, domain name, gateway, etc.
> 
> I can take a swing at this if given some general guidance on
> reasonable defaults.  I can see these alternatives:
> 
>   + loopback only
>   + HW iface only
>   + loopback+HW iface
>   + (possible) 2nd HW iface
>   + Bootp enable (requires TFTP host?)
> 
> I understand the decision tree for RTEMS configuration but am
> not 100% confident in the decision tree/requirements for network
> configuration.  Eric .. do you have advice?
> 
> 
> > --
> > Eric Norum                                 eric at cls.usask.ca
> > Canadian Light Source                      Phone: (306) 966-6308
> > University of Saskatchewan                 FAX:   (306) 966-6058
> > Saskatoon, Canada.
> 
> --
> 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