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

[Joel Sherrill]

On Sat, Aug 8, 2020 at 7:09 AM Heinz Junkes <junkes at fhi-berlin.mpg.de>
wrote:

> Hallo Chris,
> I think there's been a misunderstanding.
> I have implemented the following in the EPICS rtems_init.c :
>
> ...
> 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)
>
> rtems_bsd_ifconfig_lo0();
>
> /* lookup primary network interface */
> char ifnamebuf[IF_NAMESIZE];
> char *prim_ifname;
> prim_ifname = if_indextoname(1, &ifnamebuf[0]);
> assert(prim_ifname != NULL);
>

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

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.

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.

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.

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

--joel


> …
>
> Heinz
>
>
> > On 8. Aug 2020, at 03:50, Chris Johns <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
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200808/0c80f87e/attachment.html>