search

epics-modules / asyn

EPICS module for driver and device support
http://epics-modules.github.io/asyn/
Other
37 stars 72 forks source link

implicit declaration of function 'rtems_rpc_task_init' #150

Open mdavidsaver opened 2 years ago

mdavidsaver commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

(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 commented 2 years ago

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 commented 2 years ago

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

https://github.com/epics-modules/asyn/pull/153

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

hjunkes commented 2 years ago

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

+#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 toclnttcp_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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/epics-modules/asyn/issues/150#issuecomment-1243060760, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC45DD756BDGU22P5FKMVBTV5ZQFBANCNFSM5UI5ABFQ . You are receiving this because you were mentioned.Message ID: @.***>

mrippa commented 1 year ago

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 https://github.com/epics-modules/asyn/issues/150#issuecomment-1243060760, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC45DD756BDGU22P5FKMVBTV5ZQFBANCNFSM5UI5ABFQ . You are receiving this because you were mentioned.Message ID: @.***>

kiwichris commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

How can I help?