Network config issue

[Joel Sherrill]

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 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.
> 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