* [Xenomai] Xddp and socket: Address family not supported by protocol
@ 2014-02-06 10:58 Leopold Palomo-Avellaneda
2014-02-06 11:09 ` Philippe Gerum
0 siblings, 1 reply; 10+ messages in thread
From: Leopold Palomo-Avellaneda @ 2014-02-06 10:58 UTC (permalink / raw)
To: xenomai; +Cc: Sergi Ruiz Parra
Hi all,
we are trying to develop an application using xddp protocol. We use as base,
the xddp-label exaample that compiles and run perfectly in our system
(Xenomai-2.6.3 with Linux 3.8.13).
Our app is different from the xddp example because we have encapsulated the
realtime thread in a task, that it's in a library. We can run the task,called
from another part, and it rus.
Our task create two sockets, one to receive from the NRT and another to send.
Yes, I know that we could do it in just one socket, but by design we must do
it in the way.
Our main problem is when the RT task try to open the socket, the ipc
device isn't created. The error that appears is:"socket: Address family not
supported by protocol". I attach the real-time task code below.
The xddp works, because the examples works. We have several /dev/rtpX and when
we run the example the /proc/xenomai/registry/rtipc/xddp/xddp-label is
created.
Someone could give us some idea about what are we doing wrong?
Thanks in advance.
Leopold
-----------------------------------------------------------
RT_TASK task;
void ec_create_rt_thread(int cycleTime)
{
rt_task_create (&task, "Send PDO", 8192, 99, 0);
rt_task_set_periodic (&task, TM_NOW, cycleTime);
rt_task_start (&task, &ec_rt_thread, NULL);
}
void ec_delete_rt_thread()
{
rt_task_delete(&task);
}
void ec_rt_thread(void *unused)
{
struct rtipc_port_label plabel_in, plabel_out;
struct sockaddr_ipc saddr_in, saddr_out;
struct timespec ts;
struct timeval tv;
socklen_t addrlen;
int ret_in, ret_out, s_input, s_output, nRet;
int inputSize = 0, outputSize = 0;
int i;
for( i = 1; i <= ec_slavecount; i++)
{
inputSize = inputSize + ec_slave[i].Ibytes;
outputSize = outputSize + ec_slave[i].Obytes;
}
char * rtinputbuf = (char*) calloc(inputSize,sizeof(char));
char * rtoutputbuf = (char*) calloc(outputSize,sizeof(char));
/*need to put a lot of stuff to create
* two sockets: one to receive data from nonrt part
* and another to send data to the nonrt part
* use same option as the xenomai xddp-label example
*
* the output part came from the NRT part to the RT world
* the input part came from the RT part to the NRT world
*
*
* Get a datagram socket to bind to the RT endpoint. Each
* endpoint is represented by a port number within the XDDP
* protocol namespace.
**/
s_output = socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_XDDP);
s_input = socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_XDDP);
if (s_output < 0) {
perror("socket");
printf("socket");
}
if (s_input < 0) {
perror("socket");
printf("socket");
}
/*
* Set a port label. This name will be registered when
* binding, in addition to the port number (if given).
*/
strcpy(plabel_out.label, XDDP_PORT_OUTPUT);
ret_out = setsockopt(s_output, SOL_XDDP, XDDP_LABEL, &plabel_out,
sizeof(plabel_out));
if (ret_out)
{
perror("setsockopt");
printf("setsockopt");
}
/*
* Set the socket timeout; it will apply when attempting to
* connect to a labeled port, and to recvfrom() calls. The
* following setup tells the XDDP driver to wait for at most
* one second until a socket is bound to a port using the same
* label, or return with a timeout error.
*/
tv.tv_sec = 1;
tv.tv_usec = 0;
ret_in = setsockopt(s_input, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
if (ret_in)
{
perror("setsockopt");
printf("setsockopt");
}
/*
* Set a port label. This name will be used to find the peer
* when connecting, instead of the port number.
*/
strcpy(plabel_in.label, XDDP_PORT_INPUT);
ret_in = setsockopt(s_input, SOL_XDDP, XDDP_LABEL,&plabel_in,
sizeof(plabel_in));
if (ret_in)
{
perror("setsockopt");
printf("setsockopt");
}
/*
* Bind the socket to the port, to setup a proxy to channel
* traffic to/from the Linux domain. Assign that port a label,
* so that peers may use a descriptive information to locate
* it. For instance, the pseudo-device matching our RT
* endpoint will appear as
* /proc/xenomai/registry/rtipc/xddp/<XDDP_PORT_LABEL> in the
* Linux domain, once the socket is bound.
*
* saddr.sipc_port specifies the port number to use. If -1 is
* passed, the XDDP driver will auto-select an idle port.
*/
/*
* Output!!!!!
* from NRT to RT
*/
memset(&saddr_out, 0, sizeof(saddr_out));
saddr_out.sipc_family = AF_RTIPC;
saddr_out.sipc_port = -1;
ret_out = bind(s_output, (struct sockaddr *)&saddr_out,
sizeof(saddr_out));
if (ret_out)
{
perror("bind");
printf("bind");
}
/*
* Input!!!!!
* from RT to NRT
*/
memset(&saddr_in, 0, sizeof(saddr_in));
saddr_in.sipc_family = AF_RTIPC;
saddr_in.sipc_port = -1; /* Tell XDDP to search by label. */
ret_in = connect(s_input, (struct sockaddr *)&saddr_in,
sizeof(saddr_in));
if (ret_in)
{
perror("connect");
printf("connect");
}
/*
* We succeeded in making the port our default destination
* address by using its label, but we don't know its actual
* port number yet. Use getpeername() to retrieve it.
*/
addrlen = sizeof(saddr_in);
ret_in = getpeername(s_input, (struct sockaddr *)&saddr_in, &addrlen);
if (ret_in || addrlen != sizeof(saddr_in))
{
perror("getpeername");
printf("getpeername");
}
//rt_printf("%s: NRT peer is reading from /dev/rtp%d\n",
__FUNCTION__, saddr_in.sipc_port);
for (;;) {
/* Get packets relayed by the regular thread */
ret_out = recvfrom(s_output, rtoutputbuf, outputSize, 0, NULL, 0);
if (ret_out <= 0)
{
perror("recvfrom");
printf("recievefrom");
//nothing to do, no new data transferred
//rt_printf("%s: \"%.*s\" relayed by peer\n", __function__,
ret, buf);
}
else{
//received some data from the buffer
//traffic that data from
//rtoutputbuf to ec_slave[i].output
//copiar del outputbuf als ec_slave, tenint en compte el
OBytes de cada slave
int offSet = 0;
int i;
for ( i = 1; i<=ec_slavecount; i++)
{
memcpy (ec_slave[i].outputs, rtoutputbuf + offSet, ec_slave[i].Obytes);
offSet = offSet + ec_slave[i].Obytes;
}
}
nRet=ec_send_processdata();
//make some check of sending data
nRet=ec_receive_processdata(EC_TIMEOUTRET);
//now, we need to transmit the data outside
//from ec_slave[i].inputs
//build rtinputbuf
int offSet = 0;
int i;
for (i = 1; i<=ec_slavecount; i++)
{
memcpy (rtinputbuf + offSet ,ec_slave[i].inputs, ec_slave[i].Ibytes);
offSet = offSet + ec_slave[i].Ibytes;
}
ret_in = sendto(s_input, rtinputbuf, inputSize, 0, NULL, 0);
if(ret_in != inputSize)
{
perror("sendto");
printf("sendto");
}
rt_task_wait_period(NULL);
}
}
--
--
Linux User 152692
Catalonia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140206/a78dfa42/attachment.sig>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
2014-02-06 10:58 [Xenomai] Xddp and socket: Address family not supported by protocol Leopold Palomo-Avellaneda
@ 2014-02-06 11:09 ` Philippe Gerum
2014-02-06 11:32 ` Gilles Chanteperdrix
0 siblings, 1 reply; 10+ messages in thread
From: Philippe Gerum @ 2014-02-06 11:09 UTC (permalink / raw)
To: Leopold Palomo-Avellaneda, xenomai; +Cc: Sergi Ruiz Parra
On 02/06/2014 11:58 AM, Leopold Palomo-Avellaneda wrote:
> Hi all,
>
> we are trying to develop an application using xddp protocol. We use as base,
> the xddp-label exaample that compiles and run perfectly in our system
> (Xenomai-2.6.3 with Linux 3.8.13).
>
> Our app is different from the xddp example because we have encapsulated the
> realtime thread in a task, that it's in a library. We can run the task,called
> from another part, and it rus.
>
> Our task create two sockets, one to receive from the NRT and another to send.
> Yes, I know that we could do it in just one socket, but by design we must do
> it in the way.
>
> Our main problem is when the RT task try to open the socket, the ipc
> device isn't created. The error that appears is:"socket: Address family not
> supported by protocol". I attach the real-time task code below.
>
> The xddp works, because the examples works. We have several /dev/rtpX and when
> we run the example the /proc/xenomai/registry/rtipc/xddp/xddp-label is
> created.
>
> Someone could give us some idea about what are we doing wrong?
>
Your application is likely not wrapping POSIX symbols properly, calling
regular socket() instead of the Xenomai implementation. Check
examples/rtdm/profiles/ipc/Makefile for LDLIBS. You must have --wrap or
-Wl,@/some/path/posix.wrappers appearing in your link flags, for the
wrapping to take place properly.
--
Philippe.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
2014-02-06 11:09 ` Philippe Gerum
@ 2014-02-06 11:32 ` Gilles Chanteperdrix
2014-02-06 12:28 ` Leopold Palomo-Avellaneda
0 siblings, 1 reply; 10+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-06 11:32 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai, Sergi Ruiz Parra
On 02/06/2014 12:09 PM, Philippe Gerum wrote:
> On 02/06/2014 11:58 AM, Leopold Palomo-Avellaneda wrote:
>> Hi all,
>>
>> we are trying to develop an application using xddp protocol. We use as base,
>> the xddp-label exaample that compiles and run perfectly in our system
>> (Xenomai-2.6.3 with Linux 3.8.13).
>>
>> Our app is different from the xddp example because we have encapsulated the
>> realtime thread in a task, that it's in a library. We can run the task,called
>> from another part, and it rus.
>>
>> Our task create two sockets, one to receive from the NRT and another to send.
>> Yes, I know that we could do it in just one socket, but by design we must do
>> it in the way.
>>
>> Our main problem is when the RT task try to open the socket, the ipc
>> device isn't created. The error that appears is:"socket: Address family not
>> supported by protocol". I attach the real-time task code below.
>>
>> The xddp works, because the examples works. We have several /dev/rtpX and when
>> we run the example the /proc/xenomai/registry/rtipc/xddp/xddp-label is
>> created.
>>
>> Someone could give us some idea about what are we doing wrong?
>>
>
> Your application is likely not wrapping POSIX symbols properly, calling
> regular socket() instead of the Xenomai implementation. Check
> examples/rtdm/profiles/ipc/Makefile for LDLIBS. You must have --wrap or
> -Wl,@/some/path/posix.wrappers appearing in your link flags, for the
> wrapping to take place properly.
See also:
https://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags
--
Gilles.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
2014-02-06 11:32 ` Gilles Chanteperdrix
@ 2014-02-06 12:28 ` Leopold Palomo-Avellaneda
2014-02-06 12:48 ` Gilles Chanteperdrix
0 siblings, 1 reply; 10+ messages in thread
From: Leopold Palomo-Avellaneda @ 2014-02-06 12:28 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Sergi Ruiz Parra, xenomai
A Dijous, 6 de febrer de 2014, Gilles Chanteperdrix va escriure:
> On 02/06/2014 12:09 PM, Philippe Gerum wrote:
> > On 02/06/2014 11:58 AM, Leopold Palomo-Avellaneda wrote:
> >> Hi all,
> >>
> >> we are trying to develop an application using xddp protocol. We use as
base,
> >> the xddp-label exaample that compiles and run perfectly in our system
> >> (Xenomai-2.6.3 with Linux 3.8.13).
> >>
> >> Our app is different from the xddp example because we have encapsulated
the
> >> realtime thread in a task, that it's in a library. We can run the
task,called
> >> from another part, and it rus.
> >>
> >> Our task create two sockets, one to receive from the NRT and another to
send.
> >> Yes, I know that we could do it in just one socket, but by design we must
do
> >> it in the way.
> >>
> >> Our main problem is when the RT task try to open the socket, the ipc
> >> device isn't created. The error that appears is:"socket: Address family
not
> >> supported by protocol". I attach the real-time task code below.
> >>
> >> The xddp works, because the examples works. We have several /dev/rtpX and
when
> >> we run the example the /proc/xenomai/registry/rtipc/xddp/xddp-label is
> >> created.
> >>
> >> Someone could give us some idea about what are we doing wrong?
> >>
> >
> > Your application is likely not wrapping POSIX symbols properly, calling
> > regular socket() instead of the Xenomai implementation. Check
> > examples/rtdm/profiles/ipc/Makefile for LDLIBS. You must have --wrap or
> > -Wl,@/some/path/posix.wrappers appearing in your link flags, for the
> > wrapping to take place properly.
>
> See also:
>
https://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags
Thanks for the answers.
However, the pandora box has been open. :-(
We are using a modified version of SOEM [1][2] where the posix calls and
selected in function of a defines.
We have not used any posix skin, if not native and rtdm. Using that wrapper
have done that our lib doesn't work. All of our programs receive an SIGXCPU
(CPU time limit exceeded). It's not easy for us with that.
So, can we use the xddp protocol from native? Which functions we should use to
send/receive, etc?
Regards,
Leopold
[1] http://soem.berlios.de/
[2] https://sir.upc.edu/wikis/roblab/index.php/Development/Soem
--
--
Linux User 152692
Catalonia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140206/8b223c14/attachment.sig>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
2014-02-06 12:28 ` Leopold Palomo-Avellaneda
@ 2014-02-06 12:48 ` Gilles Chanteperdrix
2014-02-06 15:27 ` Leopold Palomo-Avellaneda
0 siblings, 1 reply; 10+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-06 12:48 UTC (permalink / raw)
To: Leopold Palomo-Avellaneda; +Cc: Sergi Ruiz Parra, xenomai
On 02/06/2014 01:28 PM, Leopold Palomo-Avellaneda wrote:
> A Dijous, 6 de febrer de 2014, Gilles Chanteperdrix va escriure:
>> On 02/06/2014 12:09 PM, Philippe Gerum wrote:
>>> On 02/06/2014 11:58 AM, Leopold Palomo-Avellaneda wrote:
>>>> Hi all,
>>>>
>>>> we are trying to develop an application using xddp protocol. We use as
> base,
>>>> the xddp-label exaample that compiles and run perfectly in our system
>>>> (Xenomai-2.6.3 with Linux 3.8.13).
>>>>
>>>> Our app is different from the xddp example because we have encapsulated
> the
>>>> realtime thread in a task, that it's in a library. We can run the
> task,called
>>>> from another part, and it rus.
>>>>
>>>> Our task create two sockets, one to receive from the NRT and another to
> send.
>>>> Yes, I know that we could do it in just one socket, but by design we must
> do
>>>> it in the way.
>>>>
>>>> Our main problem is when the RT task try to open the socket, the ipc
>>>> device isn't created. The error that appears is:"socket: Address family
> not
>>>> supported by protocol". I attach the real-time task code below.
>>>>
>>>> The xddp works, because the examples works. We have several /dev/rtpX and
> when
>>>> we run the example the /proc/xenomai/registry/rtipc/xddp/xddp-label is
>>>> created.
>>>>
>>>> Someone could give us some idea about what are we doing wrong?
>>>>
>>>
>>> Your application is likely not wrapping POSIX symbols properly, calling
>>> regular socket() instead of the Xenomai implementation. Check
>>> examples/rtdm/profiles/ipc/Makefile for LDLIBS. You must have --wrap or
>>> -Wl,@/some/path/posix.wrappers appearing in your link flags, for the
>>> wrapping to take place properly.
>>
>> See also:
>>
> https://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags
>
> Thanks for the answers.
>
> However, the pandora box has been open. :-(
>
> We are using a modified version of SOEM [1][2] where the posix calls and
> selected in function of a defines.
>
> We have not used any posix skin, if not native and rtdm. Using that wrapper
> have done that our lib doesn't work. All of our programs receive an SIGXCPU
> (CPU time limit exceeded). It's not easy for us with that.
SIGXCPU is in fact Xenomai's SIGDEBUG. See examples/native/sigdebug.c
to find out why you receive SIGDEBUG. My bet would be that you are
missing mlockall. That said, Xenomai should issue the mlockall
automatically, you simply have to take care of putting xenomai
libraries at the end of the link-edit command line, so that xenomai
libraries are loaded first.
>
> So, can we use the xddp protocol from native? Which functions we should use to
> send/receive, etc?
See:
http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__userapi.html
--
Gilles.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
2014-02-06 12:48 ` Gilles Chanteperdrix
@ 2014-02-06 15:27 ` Leopold Palomo-Avellaneda
2014-02-06 21:49 ` Gilles Chanteperdrix
0 siblings, 1 reply; 10+ messages in thread
From: Leopold Palomo-Avellaneda @ 2014-02-06 15:27 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Sergi Ruiz Parra, xenomai
A Dijous, 6 de febrer de 2014, Gilles Chanteperdrix va escriure:
> On 02/06/2014 01:28 PM, Leopold Palomo-Avellaneda wrote:
> > A Dijous, 6 de febrer de 2014, Gilles Chanteperdrix va escriure:
> >> On 02/06/2014 12:09 PM, Philippe Gerum wrote:
> >>> On 02/06/2014 11:58 AM, Leopold Palomo-Avellaneda wrote:
> >>>> Hi all,
> >>>>
> >>>> we are trying to develop an application using xddp protocol. We use as
> > base,
> >>>> the xddp-label exaample that compiles and run perfectly in our system
> >>>> (Xenomai-2.6.3 with Linux 3.8.13).
> >>>>
> >>>> Our app is different from the xddp example because we have encapsulated
> > the
> >>>> realtime thread in a task, that it's in a library. We can run the
> > task,called
> >>>> from another part, and it rus.
> >>>>
> >>>> Our task create two sockets, one to receive from the NRT and another to
> > send.
> >>>> Yes, I know that we could do it in just one socket, but by design we
must
> > do
> >>>> it in the way.
> >>>>
> >>>> Our main problem is when the RT task try to open the socket, the ipc
> >>>> device isn't created. The error that appears is:"socket: Address family
> > not
> >>>> supported by protocol". I attach the real-time task code below.
> >>>>
> >>>> The xddp works, because the examples works. We have several /dev/rtpX
and
> > when
> >>>> we run the example the /proc/xenomai/registry/rtipc/xddp/xddp-label is
> >>>> created.
> >>>>
> >>>> Someone could give us some idea about what are we doing wrong?
> >>>>
> >>>
> >>> Your application is likely not wrapping POSIX symbols properly, calling
> >>> regular socket() instead of the Xenomai implementation. Check
> >>> examples/rtdm/profiles/ipc/Makefile for LDLIBS. You must have --wrap or
> >>> -Wl,@/some/path/posix.wrappers appearing in your link flags, for the
> >>> wrapping to take place properly.
> >>
> >> See also:
> >>
> >
https://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags
> >
> > Thanks for the answers.
> >
> > However, the pandora box has been open. :-(
> >
> > We are using a modified version of SOEM [1][2] where the posix calls and
> > selected in function of a defines.
> >
> > We have not used any posix skin, if not native and rtdm. Using that
wrapper
> > have done that our lib doesn't work. All of our programs receive an
SIGXCPU
> > (CPU time limit exceeded). It's not easy for us with that.
>
> SIGXCPU is in fact Xenomai's SIGDEBUG. See examples/native/sigdebug.c
> to find out why you receive SIGDEBUG. My bet would be that you are
> missing mlockall. That said, Xenomai should issue the mlockall
> automatically, you simply have to take care of putting xenomai
> libraries at the end of the link-edit command line, so that xenomai
> libraries are loaded first.
Ok,
now it works, half work. So, it could be equivalent if I call the mlockall
function in the entry point of the lib? I mean, if I create a init function of
the lib and when I load it, mlockall is called.
> >
> > So, can we use the xddp protocol from native? Which functions we should
use to
> > send/receive, etc?
>
> See:
>
http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__userapi.html
good, done. Perfect. However we are having problems because _only_ one label
is created. I suppose that there's no limit of the number of sockets created
in the RT thread, no?
We are closing ....
Thanks for all,
Leopold
>
> --
> Gilles.
>
--
--
Linux User 152692
Catalonia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140206/999f6429/attachment.sig>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
2014-02-06 15:27 ` Leopold Palomo-Avellaneda
@ 2014-02-06 21:49 ` Gilles Chanteperdrix
2014-02-06 22:46 ` Leopold Palomo-Avellaneda
0 siblings, 1 reply; 10+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-06 21:49 UTC (permalink / raw)
To: Leopold Palomo-Avellaneda; +Cc: Sergi Ruiz Parra, xenomai
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/06/2014 04:27 PM, Leopold Palomo-Avellaneda wrote:
> A Dijous, 6 de febrer de 2014, Gilles Chanteperdrix va escriure:
>> On 02/06/2014 01:28 PM, Leopold Palomo-Avellaneda wrote:
>>> A Dijous, 6 de febrer de 2014, Gilles Chanteperdrix va
>>> escriure:
>>>> On 02/06/2014 12:09 PM, Philippe Gerum wrote:
>>>>> On 02/06/2014 11:58 AM, Leopold Palomo-Avellaneda wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> we are trying to develop an application using xddp
>>>>>> protocol. We use as
>>> base,
>>>>>> the xddp-label exaample that compiles and run perfectly
>>>>>> in our system (Xenomai-2.6.3 with Linux 3.8.13).
>>>>>>
>>>>>> Our app is different from the xddp example because we
>>>>>> have encapsulated
>>> the
>>>>>> realtime thread in a task, that it's in a library. We can
>>>>>> run the
>>> task,called
>>>>>> from another part, and it rus.
>>>>>>
>>>>>> Our task create two sockets, one to receive from the NRT
>>>>>> and another to
>>> send.
>>>>>> Yes, I know that we could do it in just one socket, but
>>>>>> by design we
> must
>>> do
>>>>>> it in the way.
>>>>>>
>>>>>> Our main problem is when the RT task try to open the
>>>>>> socket, the ipc device isn't created. The error that
>>>>>> appears is:"socket: Address family
>>> not
>>>>>> supported by protocol". I attach the real-time task code
>>>>>> below.
>>>>>>
>>>>>> The xddp works, because the examples works. We have
>>>>>> several /dev/rtpX
> and
>>> when
>>>>>> we run the example the
>>>>>> /proc/xenomai/registry/rtipc/xddp/xddp-label is created.
>>>>>>
>>>>>> Someone could give us some idea about what are we doing
>>>>>> wrong?
>>>>>>
>>>>>
>>>>> Your application is likely not wrapping POSIX symbols
>>>>> properly, calling regular socket() instead of the Xenomai
>>>>> implementation. Check examples/rtdm/profiles/ipc/Makefile
>>>>> for LDLIBS. You must have --wrap or
>>>>> -Wl,@/some/path/posix.wrappers appearing in your link
>>>>> flags, for the wrapping to take place properly.
>>>>
>>>> See also:
>>>>
>>>
> https://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags
>>>
>>>
>
Thanks for the answers.
>>>
>>> However, the pandora box has been open. :-(
>>>
>>> We are using a modified version of SOEM [1][2] where the posix
>>> calls and selected in function of a defines.
>>>
>>> We have not used any posix skin, if not native and rtdm. Using
>>> that
> wrapper
>>> have done that our lib doesn't work. All of our programs
>>> receive an
> SIGXCPU
>>> (CPU time limit exceeded). It's not easy for us with that.
>>
>> SIGXCPU is in fact Xenomai's SIGDEBUG. See
>> examples/native/sigdebug.c to find out why you receive SIGDEBUG.
>> My bet would be that you are missing mlockall. That said, Xenomai
>> should issue the mlockall automatically, you simply have to take
>> care of putting xenomai libraries at the end of the link-edit
>> command line, so that xenomai libraries are loaded first.
>
> Ok,
>
>
> now it works, half work. So, it could be equivalent if I call the
> mlockall function in the entry point of the lib? I mean, if I
> create a init function of the lib and when I load it, mlockall is
> called.
If the library uses xenomai posix skin services (through wrapping),
mlockall is not sufficient, the xenomai posix skin library has an
initialization function which must be called first. Getting a library
written for Linux implementation to work with xenomai requires several
changes (which the document posted in answer to your first question
tries to document). So, if you do not need this library to run in
primary mode, I suggest you stick to your original plan which was to
use RTDM without the posix skin wrapping.
>
>>>
>>> So, can we use the xddp protocol from native? Which functions
>>> we should
> use to
>>> send/receive, etc?
>>
>> See:
>>
> http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__userapi.html
>
> good, done. Perfect. However we are having problems because _only_
> one label is created. I suppose that there's no limit of the number
> of sockets created in the RT thread, no?
Please try and reduce the problematic program to the minimal
self-contained test case which we can run to reproduce the issue you have.
- --
Gilles.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iD8DBQFS9ANsGpcgE6m/fboRAgz9AJoDR4rwNtvZHSJUgl148FyviXQsGwCggYMr
92w+o+8nXjWXxbEMdniTSDo=
=87KQ
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
2014-02-06 21:49 ` Gilles Chanteperdrix
@ 2014-02-06 22:46 ` Leopold Palomo-Avellaneda
0 siblings, 0 replies; 10+ messages in thread
From: Leopold Palomo-Avellaneda @ 2014-02-06 22:46 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Sergi Ruiz Parra, xenomai
El Dijous, 6 de febrer de 2014, a les 22:49:32, Gilles Chanteperdrix va
escriure:
[...]
> >
> >>> (CPU time limit exceeded). It's not easy for us with that.
> >>
> >> SIGXCPU is in fact Xenomai's SIGDEBUG. See
> >> examples/native/sigdebug.c to find out why you receive SIGDEBUG.
> >> My bet would be that you are missing mlockall. That said, Xenomai
> >> should issue the mlockall automatically, you simply have to take
> >> care of putting xenomai libraries at the end of the link-edit
> >> command line, so that xenomai libraries are loaded first.
> >
> > Ok,
> >
> >
> > now it works, half work. So, it could be equivalent if I call the
> > mlockall function in the entry point of the lib? I mean, if I
> > create a init function of the lib and when I load it, mlockall is
> > called.
>
> If the library uses xenomai posix skin services (through wrapping),
no, AFAIR we don't use the posix skin. Just for the examples.
> mlockall is not sufficient, the xenomai posix skin library has an
> initialization function which must be called first. Getting a library
> written for Linux implementation to work with xenomai requires several
> changes (which the document posted in answer to your first question
> tries to document). So, if you do not need this library to run in
> primary mode, I suggest you stick to your original plan which was to
> use RTDM without the posix skin wrapping.
Ok, I will look the document. I would prefer to have a clean implementation of
pure xenomai native.
> >>> So, can we use the xddp protocol from native? Which functions
> >>> we should
> >
> > use to
> >
> >>> send/receive, etc?
> >>
> >> See:
> > http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__userapi.h
> > tml>
> > good, done. Perfect. However we are having problems because _only_
> >
> > one label is created. I suppose that there's no limit of the number
> > of sockets created in the RT thread, no?
>
> Please try and reduce the problematic program to the minimal
> self-contained test case which we can run to reproduce the issue you have.
Yes, I'm almost sure that we are doing something wrong. However, I think that
to create a modification example from the xddp-echo or label could be a good
idea. Tomorrow more,
Thanks for all,
Leopold
--
--
Linux User 152692 PGP: 0xF944807E
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
@ 2018-05-17 12:23 Libin Zhao
2018-05-17 13:18 ` Greg Gallagher
0 siblings, 1 reply; 10+ messages in thread
From: Libin Zhao @ 2018-05-17 12:23 UTC (permalink / raw)
To: xenomai@xenomai.org
Hi,
Now,I install Xenomai-3.3 In Ubuntu 3.18.20,
The latency test and cyclictest run good in my environment like that
[cid:image001.png@01D3EE1C.F980D020]
And execute the cmd :dmesg | grep -I xenomai,result like below:
[cid:image002.png@01D3EE1C.F980D020]
But when I run the demo test iddp-label , the result is error ,the error message below:
socket: Address family not supported by protocol
So ,how can I make it right, can you help me ?
Thanks very much!
BR
tony
???(????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????,?????????????????????
This email message (including any attachments) is confidential and may be legally privileged. If you have received it by mistake, please notify the sender by return email and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Envision Energy Limited and all its subsidiaries shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. Envision Energy Limited does not guarantee the integrity of this email message, nor that this email message is free of viruses, interceptions, or interference.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16729 bytes
Desc: image001.png
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180517/c086829d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 12365 bytes
Desc: image002.png
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180517/c086829d/attachment-0001.png>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Xenomai] Xddp and socket: Address family not supported by protocol
2018-05-17 12:23 Libin Zhao
@ 2018-05-17 13:18 ` Greg Gallagher
0 siblings, 0 replies; 10+ messages in thread
From: Greg Gallagher @ 2018-05-17 13:18 UTC (permalink / raw)
To: Libin Zhao, xenomai@xenomai.org
Do you have the module loaded or enabled in the kernel?
Original Message
From: libin.zhao@envisioncn.com
Sent: May 17, 2018 9:13 AM
To: xenomai@xenomai.org
Subject: Re: [Xenomai] Xddp and socket: Address family not supported by protocol
Hi,
Now,I install Xenomai-3.3 In Ubuntu 3.18.20,
The latency test and cyclictest run good in my environment like that
[cid:image001.png@01D3EE1C.F980D020]
And execute the cmd :dmesg | grep -I xenomai,result like below:
[cid:image002.png@01D3EE1C.F980D020]
But when I run the demo test iddp-label , the result is error ,the error message below:
socket: Address family not supported by protocol
So ,how can I make it right, can you help me ?
Thanks very much!
BR
tony
???(????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????,?????????????????????
This email message (including any attachments) is confidential and may be legally privileged. If you have received it by mistake, please notify the sender by return email and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Envision Energy Limited and all its subsidiaries shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. Envision Energy Limited does not guarantee the integrity of this email message, nor that this email message is free of viruses, interceptions, or interference.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16729 bytes
Desc: image001.png
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180517/c086829d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 12365 bytes
Desc: image002.png
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180517/c086829d/attachment-0001.png>
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-05-17 13:18 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-06 10:58 [Xenomai] Xddp and socket: Address family not supported by protocol Leopold Palomo-Avellaneda
2014-02-06 11:09 ` Philippe Gerum
2014-02-06 11:32 ` Gilles Chanteperdrix
2014-02-06 12:28 ` Leopold Palomo-Avellaneda
2014-02-06 12:48 ` Gilles Chanteperdrix
2014-02-06 15:27 ` Leopold Palomo-Avellaneda
2014-02-06 21:49 ` Gilles Chanteperdrix
2014-02-06 22:46 ` Leopold Palomo-Avellaneda
-- strict thread matches above, loose matches on Subject: below --
2018-05-17 12:23 Libin Zhao
2018-05-17 13:18 ` Greg Gallagher
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.