Name of the primary network interface, how to find in bsp header files?

Sun Aug 9 00:44:40 UTC 2020

On 9/8/20 6:51 am, Joel Sherrill wrote:
> On Sat, Aug 8, 2020 at 7:09 AM Heinz Junkes <junkes at fhi-berlin.mpg.de
> <mailto:junkes at fhi-berlin.mpg.de>> wrote:
> 
>     Hallo Chris,
>     I think there's been a misunderstanding.

This is more than likely. I do not know what EPICS requires for network
initialisation.

Is it possible for you describe what is needed or point me to some documentation
or existing EPICS code for the legacy stack?

>     I have implemented the following in the EPICS rtems_init.c :

For libbsd?

>     ...
>     sc = rtems_bsd_initialize();
>     assert (sc == RTEMS_SUCCESSFUL)
>     /* Let the callout timer allocate its resources */
>     sc = rtems_task_wake_after(2);
>     assert (sc == RTEMS_SUCCESSFUL)

With DHCP and the default route the normal FreeBSD timeout is 30seconds.

Have you looked into the rc.conf support in libbsd? See below. I encourage all
users of libbsd to look at this approach.

>     rtems_bsd_ifconfig_lo0();
> 
>     /* lookup primary network interface */
>     char ifnamebuf[IF_NAMESIZE];
>     char *prim_ifname;
>     prim_ifname = if_indextoname(1, &ifnamebuf[0]);

Why 1?

>     assert(prim_ifname != NULL);

For libbsd I create an `/etc/rc.conf` file ....

#
# LibBSD Configuration
#
hostname="foobar"
ifconfig_cgem0="DHCP rxcsum txcsum"
ifconfig_cgem0_alias0="ether 10:10:10:10:10:10"
dhcpcd_priority="200"
dhcpcd_options="--nobackground --timeout 10"

then call...

bool network_start_network(int timeout, bool trace)
{
  int  r;
  if (timeout == 0)
    timeout = 30;
  sleep(2);
  r = rtems_bsd_run_etc_rc_conf(timeout, trace);
  if (r < 0)
    printf("error: loading BSD /etc/rc.conf failed: %s\n", strerror(errno));

  /* start any other services */

  return true;
}

If the critical information for the rc.conf could be captured so it can be a
system specific configuration then it would help.

> Speaking from a standard perspective, this is the right thing to do.
> Assuming the code is correct. :)

Is the valid interface index in the call to if_indextoname a 1, 2 or something else?

> I agree that  RTEMS_BSP_NETWORK_DRIVER_NAME is problematic.
> It wasn't reliable on anything but embedded boards with strict and 
> unchanging configuration. And likely only one NIC.

Agreed and it works for a testsuite to some extent. Network tests are hard
because you need a very controlled network set up to make then work.

> It was used in the network demos for the legacy stack so if we want to
> eliminate it completely, it would be good to find a recommended way to
> look up the interface name and put it into the legacy configuration
> tables.
> 
> https://git.rtems.org/network-demos/tree  
> 
> Yes... I know we all want to see it removed and everyone move to
> libbsd. But I don't think that is realistic to expect. The more realistic
> solution is to move it to its own build tree and freeze it. It is there
> and we encourage people to use libbsd. But it does offer a solution
> for older target boards. The old stack is also all that is supported by
> many EPICS boards. Outside of EPICS users, even the SPARC BSPs 
> haven't been converted yet.

Yes we should move it out of the main tree and have it becomes an available
optional package. It can be maintained by those with an active interest in it.

It has some bugs ... we found one last year with the arp cache and Windows. The
solution was a hack to set the arp aging timer to a very large number.

> Anyway... I'd love to see RTEMS_BSP_NETWORK_DRIVER_NAME
> killed completely but we need to address filling in the legacy network
> stack table before the stack is initialized enough to even know the 
> interface names.

Yes, but Heinz is working on libbsd support for EPICS or have I missed something?

> Perhaps this turns into an application provided method for the legacy
> stack? Just a thought.

Yes that works.

Chris

>     > On 8. Aug 2020, at 03:50, Chris Johns <chrisj at rtems.org
>     <mailto:chrisj at rtems.org>> wrote:
>     >
>     > On 8/8/20 5:12 am, Heinz Junkes wrote:
>     >>
>     >> it works great with the libbsd-stack.
>     >
>     > I do not think it is a good idea rely on the RTEMS_BSP_NETWORK_DRIVER_NAME
>     > setting in libbsd. I have not questioned it before now as it has been used
>     > internally in the tests but exporting it as an interface is something else. It
>     > works for a specific case of target but it does not for others, for
>     example the
>     > Xilinx Zynq has 2 MACs (cgem0, cgem1), a PC has a wide range of interfaces.
>     >
>     >> That is then also definitely the way to go.
>     >
>     > How would cgem1 on a Zynq be specified if RTEMS_BSP_NETWORK_DRIVER_NAME is
>     > cgem0? Also there is nothing stopping me changing
>     RTEMS_BSP_NETWORK_DRIVER_NAME
>     > to cgem1 so how does that get handled?
>     >
>     > After 25 years doing this I have learnt to be careful about what we export and
>     > depend on.
>     >
>     >> I just remembered in the legacy stack that the network driver name
>     >> was set in some BSPs. But this was probably not continuous. And with the
>     new ones, it is no longer possible.
>     >
>     > As a default it may be OK however it would be nice or important to allow
>     this to
>     > be changed.
>     >
>     > How does an EPICS build for Linux on a PC deal with this given there is a
>     large
>     > number of possible interface names?
>     >
>     > Chris
> 
>     _______________________________________________
>     devel mailing list
>     devel at rtems.org <mailto:devel at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/devel
> 