resmgr_attach() works in core 6.3.0,but in 6.3.2 not (?)

QNX USERS QNX6 - OS
1

I wrote “nfm-raw_eth.so” - net filter module,
that works correctly under QNX core 6.3.0;

After installing core 6.3.2
( ntocore-6.3.2-20060811628-nto.sh )
my filter stop working (?!)

I find out, that problem is in resmgr_attach() :

dev_link_ID = resmgr_attach (
resmgr_dpp, // dispatch handle //
&resmgr_attr, // resource manager attrs //
“/dev/raw_eth0”, // device name/path //
_FTYPE_ANY, // open type //
0, // flags //
&resmgr_connect_funcs, // connect routines //
&resmgr_io_funcs, // I/O routines //
&fdev_attr[0] ); // handle //

I want to know what to change,
that my filter would work under 6.3.2 and 6.3.0 ?

/I found that resmgr_attach() works good if I change parameter:
resmgr_attr.msg_max_size = 2*1024; - returns error
resmgr_attr.msg_max_size = 1024+512; - ok

2

Hi there,

I think you have to install SP2 first, and then the core update to 6.3.2:

The Neutrino Core OS 6.3.2 is part of the QNX Momentics development suite. This update contains a number of changes to the QNX Neutrino RTOS to improve virtual memory management, increase performance and ease debugging. For use with QNX Momentics 6.3.0 Service Pack 1 or 2.

What is the errno message from the failed resmgr_attach() call?

Regards,
Albrecht

3

I’ve got all SP, patches, etc - all installed in proper order;

errno is Illegal argument;

4

Hm, no sparkling idea right now. It seems that the resmgr_attr.msg_max_size must be less than 2048 in this release but that is really unthinkable. Can you leave the lower value in the code?

This value is not the maximum message size you can receive, it is the largest portion a message can have. So when you set this member to 1024 you can still receive a 25K message using resmgr_msgread().

Maybe you write directly to QNX support what the relevant changes are in 6.3.2. The error code “Illegal Argument” is not even listed in the errors section of resmgr_attach()

Alternatively, you can paste the complete code sequence for resource manager setup, maybe we can see something strange.

Regards,
Albrecht

5

I found problem! :slight_smile:

First I create null resmgr - resmgr_attach() with a NULL path
(to initialize dispatch to receive messages and create the channel)
and next I call (one or many more times) resmgr_attach() with “normal” path;

The problem was in first (NULL) resmgr_attach() call:

resmgr_attach(
resmgr_dpp, // dispatch handle //
NULL, // resource manager attrs //
NULL, // device name/path //
_FTYPE_ANY, // open type //
0, // flags //
NULL, // connect routines //
NULL, // I/O routines //
NULL );

I have to change it into:

resmgr_attach(
resmgr_dpp, // dispatch handle //
&resmgr_attr, // resource manager attrs //
…
and now next calls resmgr_attach() with the same resmgr_attr
/[…], resmgr_attr.msg_max_size = 2048
dont generate any errors! :slight_smile:

/but why in core 6.3.0 this works in two ways? :frowning:

6

Good news.

Just a question out of curiosity: What is the purpose of creating a “null” resource manager first and then one or more with real paths? The channel is created in dispatch_create() .

Regards,
Albrecht

7

What is the purpose of creating a “null” resource manager ?

ans.:
“[…] If you wish, you can do a resmgr_attach() with a NULL path.
This has the effect of initializing dispatch to receive messages
and creates the channel among other things.”