Re: RTEMS build issue, rtems_3c509_driver_attach

[Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>]

On 7/20/22 08:48, Andrew Johnson via Core-talk wrote:
> This issue is nothing to do with my RTEMS-uC5282 build, it's RTEMS-pc686 where the problem is. In my RTEMS-5.1 bsp.h header there is a declaration of this function that conflicts with ours:
> > *t**ux%* cd /local/anj/RTEMS-5.1/rtems-5.1
> > *tux%* ack -C3 rtems_3c509_driver_attach
> > i386-rtems5/pc686/lib/include/bsp.h
> > 95-#define BSP_DEC21140_NETWORK_DRIVER_NAME    "dc1"
> > 96-#define BSP_DEC21140_NETWORK_DRIVER_ATTACH rtems_dec21140_driver_attach
> > 97-
> > 98:*extern int rtems_3c509_driver_attach(struct rtems_bsdnet_ifconfig *config);*
> > 99-#define BSP_3C509_NETWORK_DRIVER_NAME    "3c1"
> > 100:#define BSP_3C509_NETWORK_DRIVER_ATTACH rtems_3c509_driver_attach
> > 101-
> > 102-#ifndef RTEMS_BSP_NETWORK_DRIVER_NAME
> > 103-#define RTEMS_BSP_NETWORK_DRIVER_NAME BSP_DEC21140_NETWORK_DRIVER_NAME
> > *tux%* cd /home/phoebus/ANJ/epics/base/7.0
> > *tux%* ack -C3 rtems_3c509_driver_attach
> > modules/libcom/RTEMS/rtems_netconfig.c
> > 71-    rtems_fxp_attach,                   /* attach function */
> > 72-    &ne2k_driver_config,             /* link to next interface */
> > 73-};
> > 74:// *extern int rtems_3c509_driver_attach (struct rtems_bsdnet_ifconfig *, int);*
> > 75-static struct rtems_bsdnet_ifconfig e3c509_driver_config = {
> > 76-    "ep0",                              /* name */
> > 77:    rtems_3c509_driver_attach,          /* attach function */
> > 78-    &fxp_driver_config,                 /* link to next interface */
> > 79-};
> > 80-#define FIRST_DRIVER_CONFIG &e3c509_driver_config
> I don't understand why this isn't causing similar problems with the GHA builds, presumably Michael's RTEMS installation is different somehow.
You must be building your pc686 BSP with the legacy network stack.
My builds use libbsd (and the e1000 NIC driver).

https://github.com/mdavidsaver/rsb/blob/4f53a90874ec762f173694c39ee10287b5fa2f53/.github/workflows/build-5.yml#L100


> Can we just remove the function declaration or is it more complicated than that?
This will break RTEMS with 4.x, where bsp.h lacks this declaration.


Looking into it further I find inconsistency...

In cpukit/libnetworking/rtems/rtems_bsdnet.h

> struct rtems_bsdnet_ifconfig {
> ...
> int             (*attach)(struct rtems_bsdnet_ifconfig *conf, int attaching);
rtems_3c509_driver_attach as defined in 3c509.c has the wrong prototype.
Presumably no one has ever tried to "detach" one of these NICs...

One way to accommodate this would be something like:

> diff --git a/modules/libcom/RTEMS/rtems_netconfig.c b/modules/libcom/RTEMS/rtems_netconfig.c
> index 6272d81a6..d9267ccaa 100644
> --- a/modules/libcom/RTEMS/rtems_netconfig.c
> +++ b/modules/libcom/RTEMS/rtems_netconfig.c
> @@ -54,10 +54,10 @@ static struct rtems_bsdnet_ifconfig loopback_config = {
>   */
>  #if defined(__i386__)
>  extern int
> -rtems_ne2kpci_driver_attach (struct rtems_bsdnet_ifconfig *config, int attach);
> +rtems_ne2kpci_driver_attach (struct rtems_bsdnet_ifconfig *config);
>  static struct rtems_bsdnet_ifconfig ne2k_driver_config = {
>      "ne2",                             /* name */
> -    rtems_ne2kpci_driver_attach,       /* attach function */
> +    (void*)&rtems_ne2kpci_driver_attach,       /* attach function */
>  #if RTEMS_VERSION_INT<VERSION_INT(4,11,0,0)
>      &loopback_config,                   /* link to next interface */
>  #else