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); … Heinz > On 8. Aug 2020, at 03:50, Chris Johns <chr...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel