implicit declaration of function 'rtems_rpc_task_init'

[mdavidsaver]

With RTEMS 5 for pc686 with the libbsd (aka. "new") network stack I get:

In file included from ../../asyn/vxi11/drvVxi11.c:41:0:
../../asyn/vxi11/drvVxi11.c: In function 'vxiConnectPort':
../../asyn/vxi11/osiRpc.h:25:21: error: implicit declaration of function 'rtems_rpc_task_init'; did you mean 'rtems_task_exit'? [-Werror=implicit-function-declaration]
 #define rpcTaskInit rtems_rpc_task_init
                     ^
../../asyn/vxi11/drvVxi11.c:908:12: note: in expansion of macro 'rpcTaskInit'
         if(rpcTaskInit() == -1) {
            ^~~~~~~~~~~

It appears that libbsd provides a different rpc/rpc.h, which doesn't contain anything RTEMS specific. I guess some different initialization will be needed?

@hjunkes @mrippa fyi.

[tboegi]

I think that we can add code/ifdefs
for rtems and the "new network stack"
here:
asyn/vxi11/osiRpc.h

(Do we have a #define for "the new network stack" ?

I have the same problem on FreeBSD, but that box is powered off
for the moment.

[mdavidsaver]

(Do we have a #define for "the new network stack" ?

I don't believe that the RTEMS devs. have an "official" solution. Practically, there are a number of headers and macros which don't appear with the original/old IP stack. eg. one test would be:

#ifdef __has_include
#  if __has_include(<netinet6/in6.h>)
#    define USE_RTEMS_LIBBSD_NETWORKING
#  endif
#endif

(imo. something like this should properly appear in osdSock.h in Base)

[hjunkes]

At the moment I am using a definition in the configure.
if old (legacy) stack:
CONFIG.Common.RTEMS:OP_SYS_CFLAGS_NET_yes = -DRTEMS_LEGACY_STACK

[tboegi]

I don't have RTEMS.
A possible solution is here:

#153

Does anyone @hjunkes @mdavidsaver wants to test or has a better fix ?

[hjunkes]

You missed another
#endif (#ifdef rtems).

--- a/asyn/vxi11/osiRpc.h
+++ b/asyn/vxi11/osiRpc.h
@@ -22,7 +22,11 @@
#ifdef rtems
#include <rpc/pmap_clnt.h>
#include <rtems.h>
+#ifdef RTEMS_LEGACY_STACK
#define rpcTaskInit rtems_rpc_task_init
+#else
+#define rpcTaskInit() 0
+#endif
#endif

#ifdef APPLE

And then I run into the next problem:

/home/rtems/MVME6100_WORK/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: /home/rtems/EPICS_TST/epics-support/asyn/lib/RTEMS-beatnik/libasyn.a(drvVxi11.o): in function vxiConnectPort': /home/rtems/EPICS_TST/epics-support/asyn/asyn/O.RTEMS-beatnik/../../asyn/vxi11/drvVxi11.c:930: undefined reference to clnttcp_create'
collect2: error: ld returned 1 exit status
Unfortunately, I have not yet understood the connections. I have received this information from the RTEMS community:

There is no call. The user land NFS RPC negotiation is handled in the mount call
and the NFSv4 client is a kernel land implementation and directly handles the
RPC side of things.

Chris

I don't have it yet and still need to take a look at it.

[tboegi]

thanks @hjunkes for reporting the missing #endif:
My patch should be fixed now.

Reading your comment about Vxi11:
You may be able to ifdef away vxi11 in asyn/Makefile ?

[MarkRivers]

I'd like to fix this in asyn R4-33, which will be released soon. I don't have any RTEMS systems, so I can't work on it or test it.

Can someone make a PR that others can test on RTEMS?

[mrippa]

Hi Mark, We can test on our mvme PPC systems like 2700, beatnik or 3100. You're asking for RTEMS 5.1 or 4.10.2?

…

-Matt

On Sun, Sep 11, 2022, 1:01 PM Mark Rivers ***@***.***> wrote: I'd like to fix this in asyn R4-33, which will be released soon. I don't have any RTEMS systems, so I can't work on it or test it. Can someone make a PR that others can test on RTEMS? — Reply to this email directly, view it on GitHub <#150 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC45DD756BDGU22P5FKMVBTV5ZQFBANCNFSM5UI5ABFQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mrippa]

Hi Mark, I just read more context in the thread. There's some ongoing work with the rtems 5 and 6 integrations, including choice network stack. I've passed this on to our rtems devs. We have the hardware to test things when the time comes.

…

-Matt

On Sun, Sep 11, 2022, 1:24 PM Matt Rippa ***@***.***> wrote: Hi Mark, We can test on our mvme PPC systems like 2700, beatnik or 3100. You're asking for RTEMS 5.1 or 4.10.2? -Matt On Sun, Sep 11, 2022, 1:01 PM Mark Rivers ***@***.***> wrote: > I'd like to fix this in asyn R4-33, which will be released soon. I don't > have any RTEMS systems, so I can't work on it or test it. > > Can someone make a PR that others can test on RTEMS? > > — > Reply to this email directly, view it on GitHub > <#150 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AC45DD756BDGU22P5FKMVBTV5ZQFBANCNFSM5UI5ABFQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[kiwichris]

Hi @hjunkes and @mdavidsaver,

The change from the legacy networking stack to libbsd has exposed some issues and this is one. I have recently invested some time looking at EPICS and RTEMS integration and there are some interfaces in use that are difficult to replace or migrate. This is one (the legacy NTP support is another). EPICS's integration to the legacy stack was closer than we understood and RTEMS has moved on partly because we did not know or understand how EPICS used some interfaces and some pieces of code in the legacy stack.

The legacy NFSv2 support from Till followed the Unix model of the time where RPC was a separate subsystem. The latest LibBSD NFSv4 build (6-freebsd-12 branch) uses the FreeBSD kernel resident NFS client and that code uses the kernel resident RPC client code. Better performance has been gained having RPC and NFS reside in the kernel. RTEMS is a single address space however LibBSD still has a separation between the FreeBSD kernel and user code. As a result the NFS client and the FreeBSD kernel support automatically handle the RPC side of things. As a result mounting a remote NFS export automatically handles the RPC side of things for us.

RTEMS 5 has a configure option to build the legacy stack. RTEMS 6 does not because the legacy network stack has been removed from the RTEMS kernel sources and made a separate package. We intend to maintain the legacy stack as well as libbsd.

Chris

[hjunkes]

I have announced a talk at next week's EPICS Collaboration Meeting to address the current developments RTEMS and EPICS and ask for feedback on what is needed. I'm trying to put together slides for the talk by this weekend and would send those to you for additions and comments.

[kiwichris]

Great. I was going to register something but I think two talks on the same topic would not work.

How can I help?