<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 8, 2020 at 7:09 AM Heinz Junkes <<a href="mailto:junkes@fhi-berlin.mpg.de">junkes@fhi-berlin.mpg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hallo Chris,<br>
I think there's been a misunderstanding.<br>
I have implemented the following in the EPICS rtems_init.c :<br>
<br>
...<br>
sc = rtems_bsd_initialize();<br>
assert (sc == RTEMS_SUCCESSFUL)<br>
/* Let the callout timer allocate its resources */<br>
sc = rtems_task_wake_after(2);<br>
assert (sc == RTEMS_SUCCESSFUL)<br>
<br>
rtems_bsd_ifconfig_lo0();<br>
<br>
/* lookup primary network interface */<br>
char ifnamebuf[IF_NAMESIZE];<br>
char *prim_ifname;<br>
prim_ifname = if_indextoname(1, &ifnamebuf[0]);<br>
assert(prim_ifname != NULL);<br></blockquote><div><br></div><div>Speaking from a standard perspective, this is the right thing to do.</div><div>Assuming the code is correct. :)</div><div><br></div><div>I agree that  RTEMS_BSP_NETWORK_DRIVER_NAME is problematic.</div><div>It wasn't reliable on anything but embedded boards with strict and </div><div>unchanging configuration. And likely only one NIC.</div><div><br></div><div>It was used in the network demos for the legacy stack so if we want to</div><div>eliminate it completely, it would be good to find a recommended way to</div><div>look up the interface name and put it into the legacy configuration</div><div>tables.</div><div><br></div><div><a href="https://git.rtems.org/network-demos/tree">https://git.rtems.org/network-demos/tree</a>  <br></div><div><br></div><div>Yes... I know we all want to see it removed and everyone move to</div><div>libbsd. But I don't think that is realistic to expect. The more realistic</div><div>solution is to move it to its own build tree and freeze it. It is there</div><div>and we encourage people to use libbsd. But it does offer a solution</div><div>for older target boards. The old stack is also all that is supported by</div><div>many EPICS boards. Outside of EPICS users, even the SPARC BSPs </div><div>haven't been converted yet.</div><div><br></div><div>Anyway... I'd love to see RTEMS_BSP_NETWORK_DRIVER_NAME</div><div>killed completely but we need to address filling in the legacy network</div><div>stack table before the stack is initialized enough to even know the </div><div>interface names.</div><div><br></div><div>Perhaps this turns into an application provided method for the legacy</div><div>stack? Just a thought.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
…<br>
<br>
Heinz<br>
<br>
<br>
> On 8. Aug 2020, at 03:50, Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br>
> <br>
> On 8/8/20 5:12 am, Heinz Junkes wrote:<br>
>> <br>
>> it works great with the libbsd-stack.<br>
> <br>
> I do not think it is a good idea rely on the RTEMS_BSP_NETWORK_DRIVER_NAME<br>
> setting in libbsd. I have not questioned it before now as it has been used<br>
> internally in the tests but exporting it as an interface is something else. It<br>
> works for a specific case of target but it does not for others, for example the<br>
> Xilinx Zynq has 2 MACs (cgem0, cgem1), a PC has a wide range of interfaces.<br>
> <br>
>> That is then also definitely the way to go.<br>
> <br>
> How would cgem1 on a Zynq be specified if RTEMS_BSP_NETWORK_DRIVER_NAME is<br>
> cgem0? Also there is nothing stopping me changing RTEMS_BSP_NETWORK_DRIVER_NAME<br>
> to cgem1 so how does that get handled?<br>
> <br>
> After 25 years doing this I have learnt to be careful about what we export and<br>
> depend on.<br>
> <br>
>> I just remembered in the legacy stack that the network driver name<br>
>> was set in some BSPs. But this was probably not continuous. And with the new ones, it is no longer possible.<br>
> <br>
> As a default it may be OK however it would be nice or important to allow this to<br>
> be changed.<br>
> <br>
> How does an EPICS build for Linux on a PC deal with this given there is a large<br>
> number of possible interface names?<br>
> <br>
> Chris<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>