Selection of ethernet peripheral by application

[Chris Johns]

On 3/6/21 4:37 am, Kinsey Moore wrote:
> Hello,
> 
> From what I’ve seen of the various BSPs supported by LibBSD that have multiple
> ethernet peripherals,
> 
> only one tends to be chosen and supported. I’ve encountered a situation where
> the majority of platform
> 
> examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the only/primary
> ethernet interface and I
> 
> need to have the option of selecting a different peripheral as the primary
> interface.
> 
>  
> 
> Unfortunately, the current configuration of LibBSD/RTEMS does not allow for easy
> switching among the
> 
> available interfaces. The easy one-off option is to just create a BSP variant
> with a little bit of extra logic
> 
> to select the correct interface in LibBSD, but this problem seems more generally
> applicable than just
> 
> ethernet and just this one BSP. Is the best alternative to configure all
> available devices in
> 
> nexus-devices.h and let LibBSD figure it out?

I am not sure what the issue is. I also do not know what is "the correct
interface" means.

How many interfaces do you need to support and what are they?

If a device like the Ultrascale as 2 hard IP GEM MACs maybe LibBSD for that BSP
should enable both by default. Maybe the Zynq and Versal (when added) should be
the same. If a user adds another MAC in the PL, for example a Tri-Core LogicCore
block (and adds a driver) then there may be 3 interfaces present but that would
not be enabled by default. The same goes for the PC with the ability to plug in
NIC boards.

What happens after probing and the drivers are present is for the application to
manage via the stack's various interfaces. The rc.conf support I added uses
commands such as ifconfig to access those interfaces and provide support for
initialisation and set up. There are other ways that could be done.

I wonder if there is a misunderstanding and it could be on my part. LibBSD does
not ship with THE defined set of interfaces. It has a minimal set to allow
testing and maybe that is wrong. A lot of the testing framework is just that a
testing framework and if you wish to leverage that support in applications then
all the best because that support can and may change to suite the testing needs
of LibBSD and there is no requirement to make it backwards compatible for
application that depend on it.

Chris