Duplicating QNX 4's qnx_ioctlmx().

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Hi. I’m in the process of porting a vehicle simulator from QNX 4 to
Neutrino. This simulator includes many different executables and
subprograms. While attempting to port one of the I/O managers, I’ve run
into what feels like a conceptual difference between the two OS’s.

Under QNX 4, we had implemented an I/O manager that communicated with
clients using ioctl’s. It was possible for a client to send up to the
maximum message size (65500 bytes, as I recall) worth of data to the
manager; furthermore, this data was scattered around in the client’s
memory space, and was transmitted using qnx_ioctlmx().

I’ve found the Neutrino documentation to be less-than-clear on many
details, but the impression I’ve gotten is that:

  1. Use devctl() to replace qnx_ioctl() and qnx_ioctlmx().
  2. The maximum amount of data that can be translated using devctl() is
    2^14, or 16 Kbytes.
  3. All of the examples I’ve found only transmit contigous blocks of
    memory using devctl(); I haven’t seen any examples of duplicating the
    functionality of qnx_ioctlmx(). For that matter, I can’t visualize how
    it would work, and I suspect it might not be possible.

So my questions boil down to these:

  1. Is it possible to duplicate the gather-scatter capabilities of a
    qnx_ioctlmx() using devctl()?
  2. And, if not, would it be easiest if I would, as part of the port,
    make the new resource manager handle custom messages and eliminate
    devctl() entirely?

Thanks for any guidance.

Josh Hamacher
FAAC Incorporated

2

Josh Hamacher <hamacher@faac.com> wrote:

  1. Use devctl() to replace qnx_ioctl() and qnx_ioctlmx().
  2. The maximum amount of data that can be translated using devctl() is
    2^14, or 16 Kbytes.

Yup.

  1. All of the examples I’ve found only transmit contigous blocks of
    memory using devctl(); I haven’t seen any examples of duplicating the
    functionality of qnx_ioctlmx(). For that matter, I can’t visualize how
    it would work, and I suspect it might not be possible.

I don’t think it exists.

So my questions boil down to these:

  1. Is it possible to duplicate the gather-scatter capabilities of a
    qnx_ioctlmx() using devctl()?

Not that I know of.

  1. And, if not, would it be easiest if I would, as part of the port,
    make the new resource manager handle custom messages and eliminate
    devctl() entirely?

Probably easier – you could look at using message_attach() or IO_MSG
type messages for what you previously sent with devctl(). The advantage
of IO_MSG type messages over message_attach() is that you have the OCB
information available in your callback – so it makes more sense for things
that will also be doing fd (read/write etc) type work, while message_attach()
makes more sense when all of the communication will be, effectively,
non-standard.

-David

QNX Training Services
dagibbs@qnx.com

3

Ok guys,
This info was a wakeup call for me since I have stuff that does massive
data transfers to/from DSP’s and the mx stuff and large buffers are
used extensively in some of my stuff.

So:

  1. Where is this 2^14 limit defined since I can’t seem to find it? There
    is nothing in the iomsg.h or devctl.h headers - all sizes are _Uint32t.
    It states that the upper 16 bits -2 in the dcmd are a hint but that
    nbytes is the actual length. What you pass the the macros must
    not exceed 2^14 but like I said that is a hint and not the actual length.

  2. devctl.h has a devctlv() function that uses iovec structures for
    scatter/gather operations… ???

Am I missing something?

Jay

David Gibbs wrote in message <9kpkdj$nnf$1@nntp.qnx.com>…

Josh Hamacher <> hamacher@faac.com> > wrote:

  1. Use devctl() to replace qnx_ioctl() and qnx_ioctlmx().
  2. The maximum amount of data that can be translated using devctl() is
    2^14, or 16 Kbytes.

Yup.

  1. All of the examples I’ve found only transmit contigous blocks of
    memory using devctl(); I haven’t seen any examples of duplicating the
    functionality of qnx_ioctlmx(). For that matter, I can’t visualize how
    it would work, and I suspect it might not be possible.

I don’t think it exists.

So my questions boil down to these:

  1. Is it possible to duplicate the gather-scatter capabilities of a
    qnx_ioctlmx() using devctl()?

Not that I know of.

  1. And, if not, would it be easiest if I would, as part of the port,
    make the new resource manager handle custom messages and eliminate
    devctl() entirely?

Probably easier – you could look at using message_attach() or IO_MSG
type messages for what you previously sent with devctl(). The advantage
of IO_MSG type messages over message_attach() is that you have the OCB
information available in your callback – so it makes more sense for things
that will also be doing fd (read/write etc) type work, while
message_attach()
makes more sense when all of the communication will be, effectively,
non-standard.

-David

QNX Training Services
dagibbs@qnx.com

4

Jay Hogg (Jay.Hogg@t-netix.com.r-e-m-o-v-e) wrote:
: Ok guys,
: This info was a wakeup call for me since I have stuff that does massive
: data transfers to/from DSP’s and the mx stuff and large buffers are
: used extensively in some of my stuff.

: So:
: 1) Where is this 2^14 limit defined since I can’t seem to find it? There
: is nothing in the iomsg.h or devctl.h headers - all sizes are _Uint32t.
: It states that the upper 16 bits -2 in the dcmd are a hint but that
: nbytes is the actual length. What you pass the the macros must
: not exceed 2^14 but like I said that is a hint and not the actual length.

: 2) devctl.h has a devctlv() function that uses iovec structures for
: scatter/gather operations… ???

: Am I missing something?

Hi Jay,

why don’t you construct your own messages using _IO_MSG? You can then
put an os-independent wrapper function around your use of _IO_MSG if you
need portability, and then you can transfer whatever lengths you want in
whatever MX (IOV) organizations you want…

Cheers,
-RK

: Jay

: David Gibbs wrote in message <9kpkdj$nnf$1@nntp.qnx.com>…
: >Josh Hamacher <hamacher@faac.com> wrote:
: >
: >> 1. Use devctl() to replace qnx_ioctl() and qnx_ioctlmx().
: >> 2. The maximum amount of data that can be translated using devctl() is
: >> 2^14, or 16 Kbytes.
: >
: >Yup.
: >
: >> 3. All of the examples I’ve found only transmit contigous blocks of
: >> memory using devctl(); I haven’t seen any examples of duplicating the
: >> functionality of qnx_ioctlmx(). For that matter, I can’t visualize how
: >> it would work, and I suspect it might not be possible.
: >
: >I don’t think it exists.
: >
: >> So my questions boil down to these:
: >
: >> 1. Is it possible to duplicate the gather-scatter capabilities of a
: >> qnx_ioctlmx() using devctl()?
: >
: >Not that I know of.
: >
: >> 2. And, if not, would it be easiest if I would, as part of the port,
: >> make the new resource manager handle custom messages and eliminate
: >> devctl() entirely?
: >
: >Probably easier – you could look at using message_attach() or IO_MSG
: >type messages for what you previously sent with devctl(). The advantage
: >of IO_MSG type messages over message_attach() is that you have the OCB
: >information available in your callback – so it makes more sense for things
: >that will also be doing fd (read/write etc) type work, while
: message_attach()
: >makes more sense when all of the communication will be, effectively,
: >non-standard.
: >
: >-David
: >–
: >QNX Training Services
: >dagibbs@qnx.com


\

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 & Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade books!

5

Interesting.

I hadn’t actually gone spelunking in the header files or tried things
experimentally; all of my observations were based on reading the
documentation (doesn’t that figure, the one time I did read the manual
it led me astray). :slight_smile: When I tried devctlv(), it did seem to function
as expected. I am curious, however, as to why it didn’t make it into
the documentation.

I’ll probably have a chance to play with larger data transmissions later
today. Thanks.

Josh

6

Jay Hogg <Jay.Hogg@t-netix.com.r-e-m-o-v-e> wrote:

Ok guys,
This info was a wakeup call for me since I have stuff that does massive
data transfers to/from DSP’s and the mx stuff and large buffers are
used extensively in some of my stuff.

So:

  1. Where is this 2^14 limit defined since I can’t seem to find it? There
    is nothing in the iomsg.h or devctl.h headers - all sizes are _Uint32t.
    It states that the upper 16 bits -2 in the dcmd are a hint but that
    nbytes is the actual length. What you pass the the macros must
    not exceed 2^14 but like I said that is a hint and not the actual length.

This probably needs to be better documented, it was my understanding
that this is the actual maximum.

  1. devctl.h has a devctlv() function that uses iovec structures for
    scatter/gather operations… ???

Yes, but it isn’t a documented function. Using functions that are in
header files but undocumented can result in unpredictable and instable
results.

-David

QNX Training Services
dagibbs@qnx.com

7

Josh Hamacher <hamacher@faac.com> wrote:
: Interesting.

: I hadn’t actually gone spelunking in the header files or tried things
: experimentally; all of my observations were based on reading the
: documentation (doesn’t that figure, the one time I did read the manual
: it led me astray). :slight_smile:

Woohoo! We succeeded! :slight_smile:

: When I tried devctlv(), it did seem to function
: as expected. I am curious, however, as to why it didn’t make it into
: the documentation.

This kind of exchange will help make the docs better. Thanks for raising the
question.

Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

8

David Gibbs wrote:

Jay Hogg <> Jay.Hogg@t-netix.com.r-e-m-o-v-e> > wrote:
Ok guys,
This info was a wakeup call for me since I have stuff that does massive
data transfers to/from DSP’s and the mx stuff and large buffers are
used extensively in some of my stuff.

So:

  1. Where is this 2^14 limit defined since I can’t seem to find it? There
    is nothing in the iomsg.h or devctl.h headers - all sizes are _Uint32t.
    It states that the upper 16 bits -2 in the dcmd are a hint but that
    nbytes is the actual length. What you pass the the macros must
    not exceed 2^14 but like I said that is a hint and not the actual length.

This probably needs to be better documented, it was my understanding
that this is the actual maximum.

  1. devctl.h has a devctlv() function that uses iovec structures for
    scatter/gather operations… ???

Yes, but it isn’t a documented function. Using functions that are in
header files but undocumented can result in unpredictable and instable
results.

-David

QNX Training Services
dagibbs@qnx.com

It seems to work though, David. Are you saying it may be withdrawn sometime?
That would seem strange as it would leave this as the only message-passing
function without a *v companion – not the kind of asymmetry we have come to
expect from QSSL. Or are you saying it’s still beta? If so, that’s OK, we are
doing an R&D port of our framework right now, not for production.

We do need to resolve the question of the 2^14 limit. If that’s the case, it’s
too small for what we need to do so then we’ll follow Rob’s advice. Maybe we’ll
follow Rob’s advice anyway. It just seemed logical to us that devctl was
equivalent to qnx_ioctl.

9

Dean Douthat <ddouthat@faac.com> wrote:

Yes, but it isn’t a documented function. Using functions that are in
header files but undocumented can result in unpredictable and instable
results.

-David

QNX Training Services
dagibbs@qnx.com

It seems to work though, David. Are you saying it may be withdrawn sometime?

I’m not talking about this function in particular – I don’t know what
its particular future may be. But, I’m saying that in general using
something you’ve found in a header file that isn’t documented is risky
behaviour.

That would seem strange as it would leave this as the only message-passing
function without a *v companion – not the kind of asymmetry we have come to
expect from QSSL. Or are you saying it’s still beta?

devctl() has kind of an … interesting… history. It came out of a
Posix draft – Posix saw a bunch of different ioctl() type functions in
a bunch of different OSes, and decided they create a “standard” function
of that type and call it, for some reason, devctl(). So, following the
draft standard, we created a devctl() function. Then in just about the
last revision of the standard they decided that, hey, maybe they should
go back to the ioctl() name, so the final standard function for this became
ioctl(). So, there we were, with devctl().

-David

QNX Training Services
dagibbs@qnx.com

10

Interesting. So, should Josh be using ioctl? Or just go with “private” messages?
Or will QSSL be supporting devctl[v] anyway?

David Gibbs wrote:

Dean Douthat <> ddouthat@faac.com> > wrote:


Yes, but it isn’t a documented function. Using functions that are in
header files but undocumented can result in unpredictable and instable
results.

-David

QNX Training Services
dagibbs@qnx.com

It seems to work though, David. Are you saying it may be withdrawn sometime?

I’m not talking about this function in particular – I don’t know what
its particular future may be. But, I’m saying that in general using
something you’ve found in a header file that isn’t documented is risky
behaviour.

That would seem strange as it would leave this as the only message-passing
function without a *v companion – not the kind of asymmetry we have come to
expect from QSSL. Or are you saying it’s still beta?

devctl() has kind of an … interesting… history. It came out of a
Posix draft – Posix saw a bunch of different ioctl() type functions in
a bunch of different OSes, and decided they create a “standard” function
of that type and call it, for some reason, devctl(). So, following the
draft standard, we created a devctl() function. Then in just about the
last revision of the standard they decided that, hey, maybe they should
go back to the ioctl() name, so the final standard function for this became
ioctl(). So, there we were, with devctl().

-David

QNX Training Services
dagibbs@qnx.com

11

Dean Douthat <ddouthat@faac.com> wrote:

Interesting. So, should Josh be using ioctl? Or just go with
“private” messages?
Or will QSSL be supporting devctl[v] anyway?

devctl() isn’t going away – ioctl() calls devctl() if it gets an ioctl
that it doesn’t recognise as being some other particular type.

I’d suggest, though, one of the two types of private message interfaces
I mentioned earlier, either by way of _IO_MSG type messages or by way
of message_attach(). Depends on whether or not they want OCB information
available when handling the message.

-David

QNX Training Services
dagibbs@qnx.com

12

David Gibbs <dagibbs@qnx.com> wrote:

Dean Douthat <> ddouthat@faac.com> > wrote:
Interesting. So, should Josh be using ioctl? Or just go with
“private” messages?
Or will QSSL be supporting devctl[v] anyway?

devctl() isn’t going away – ioctl() calls devctl() if it gets an ioctl
that it doesn’t recognise as being some other particular type.

I’d suggest, though, one of the two types of private message interfaces
I mentioned earlier, either by way of _IO_MSG type messages or by way
of message_attach(). Depends on whether or not they want OCB information
available when handling the message.

Part of the reason I suggest these rather than ioctl/devctl is that
ioctl/devctl are, as there names suggest, primarily for control type
operations. Getting/setting parameters and stuff like that – he sounds
like he wants to move fairly extensive blocks of data, which would suggest
read/write, or if he doesn’t want to go that way, use one of the two private
message interfaces.

-David

QNX Training Services
dagibbs@qnx.com

13

Robert,

Thanks for the feedback. I was primarily responding to some of the
inconsistencies
between docs/headers/my understanding but you brought up an interesting
point:

(1) In the beginning (6 years ago) we did our own messages using the
standard
ushort/ushort ad the beginning of a message and “encapsulating” the
transport
so it was transparent…

(2) Then came the revisions 1,2,3 of the resource manager framework with a
push
to the “final” version since it was close to where stuff was going in the
future
and was “similer” to what Nto was going to have…

Now, from the application side part (2) is the most compatible… from the
resource
manager side part (1) is easier to port because while the 3rd revision was
close
there are radical changes.

In about a month I’m hoping I will have some time to move one of my T1
drivers
from QNX4 to Nto so I will be back and I will have more grey hair when I
get done :wink:

Jay

Robert Krten <nospam2@parse.com> wrote in article
<9krdut$k26$1@inn.qnx.com>…

Jay Hogg (> Jay.Hogg@t-netix.com.r-e-m-o-v-e> ) wrote:
: Ok guys,
: This info was a wakeup call for me since I have stuff that does massive
: data transfers to/from DSP’s and the mx stuff and large buffers are
: used extensively in some of my stuff.

: So:
: 1) Where is this 2^14 limit defined since I can’t seem to find it?
There
: is nothing in the iomsg.h or devctl.h headers - all sizes are _Uint32t.
: It states that the upper 16 bits -2 in the dcmd are a hint but that
: nbytes is the actual length. What you pass the the macros must
: not exceed 2^14 but like I said that is a hint and not the actual
length.

: 2) devctl.h has a devctlv() function that uses iovec structures for
: scatter/gather operations… ???

: Am I missing something?

Hi Jay,

why don’t you construct your own messages using _IO_MSG? You can then
put an os-independent wrapper function around your use of _IO_MSG if you
need portability, and then you can transfer whatever lengths you want in
whatever MX (IOV) organizations you want…

Cheers,
-RK

: Jay

: David Gibbs wrote in message <9kpkdj$nnf$> 1@nntp.qnx.com> >…
: >Josh Hamacher <> hamacher@faac.com> > wrote:
:
: >> 1. Use devctl() to replace qnx_ioctl() and qnx_ioctlmx().
: >> 2. The maximum amount of data that can be translated using devctl()
is
: >> 2^14, or 16 Kbytes.
:
: >Yup.
:
: >> 3. All of the examples I’ve found only transmit contigous blocks of
: >> memory using devctl(); I haven’t seen any examples of duplicating
the
: >> functionality of qnx_ioctlmx(). For that matter, I can’t visualize
how
: >> it would work, and I suspect it might not be possible.
:
: >I don’t think it exists.
:
: >> So my questions boil down to these:
:
: >> 1. Is it possible to duplicate the gather-scatter capabilities of a
: >> qnx_ioctlmx() using devctl()?
:
: >Not that I know of.
:
: >> 2. And, if not, would it be easiest if I would, as part of the
port,
: >> make the new resource manager handle custom messages and eliminate
: >> devctl() entirely?
:
: >Probably easier – you could look at using message_attach() or IO_MSG
: >type messages for what you previously sent with devctl(). The
advantage
: >of IO_MSG type messages over message_attach() is that you have the OCB
: >information available in your callback – so it makes more sense for
things
: >that will also be doing fd (read/write etc) type work, while
: message_attach()
: >makes more sense when all of the communication will be, effectively,
: >non-standard.
:
: >-David
: >–
: >QNX Training Services
: >> dagibbs@qnx.com


\

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 &
Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at
http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade
books!

14

David Gibbs wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
Dean Douthat <> ddouthat@faac.com> > wrote:
Interesting. So, should Josh be using ioctl? Or just go with
“private” messages?
Or will QSSL be supporting devctl[v] anyway?

devctl() isn’t going away – ioctl() calls devctl() if it gets an ioctl
that it doesn’t recognise as being some other particular type.

I’d suggest, though, one of the two types of private message interfaces
I mentioned earlier, either by way of _IO_MSG type messages or by way
of message_attach(). Depends on whether or not they want OCB information
available when handling the message.

Part of the reason I suggest these rather than ioctl/devctl is that
ioctl/devctl are, as there names suggest, primarily for control type
operations. Getting/setting parameters and stuff like that – he sounds
like he wants to move fairly extensive blocks of data, which would suggest
read/write, or if he doesn’t want to go that way, use one of the two private
message interfaces.

-David

QNX Training Services
dagibbs@qnx.com

OK, thanks David for the feedback and insight.

15

Dean Douthat <ddouthat@faac.com> wrote:


OK, thanks David for the feedback and insight.

You’re welcome.

-David

QNX Training Services
dagibbs@qnx.com

16

“Steve Reid” <stever@qnx.com> wrote in message
news:9kro36$49a$1@nntp.qnx.com…

Josh Hamacher <> hamacher@faac.com> > wrote:
: I hadn’t actually gone spelunking in the header files or tried things
: experimentally; all of my observations were based on reading the
: documentation (doesn’t that figure, the one time I did read the manual
: it led me astray). > :slight_smile:

Woohoo! We succeeded! > :slight_smile:

Steve, are you sure you have your goals straight there? ;-}

17

Steve Reid <stever@qnx.com> wrote:

Josh Hamacher <> hamacher@faac.com> > wrote:
: Interesting.

: I hadn’t actually gone spelunking in the header files or tried things
: experimentally; all of my observations were based on reading the
: documentation (doesn’t that figure, the one time I did read the manual
: it led me astray). > :slight_smile:

Woohoo! We succeeded! > :slight_smile:

: When I tried devctlv(), it did seem to function
: as expected. I am curious, however, as to why it didn’t make it into
: the documentation.

This kind of exchange will help make the docs better. Thanks for raising the
question.

FYI:

devctlv() will NOT be documented.
According to Peterv it’s deprecated, and the message functions
should be used instead.

BTW, if a function appears in a header file and isn’t documented,
you really shouldn’t be using it!


-Donna

18

In article <9kriam$ds$2@nntp.qnx.com> you wrote:

Jay Hogg <> Jay.Hogg@t-netix.com.r-e-m-o-v-e> > wrote:
Ok guys,
This info was a wakeup call for me since I have stuff that does massive
data transfers to/from DSP’s and the mx stuff and large buffers are
used extensively in some of my stuff.

So:

  1. Where is this 2^14 limit defined since I can’t seem to find it? There
    is nothing in the iomsg.h or devctl.h headers - all sizes are _Uint32t.
    It states that the upper 16 bits -2 in the dcmd are a hint but that
    nbytes is the actual length. What you pass the the macros must
    not exceed 2^14 but like I said that is a hint and not the actual length.

This probably needs to be better documented, it was my understanding
that this is the actual maximum.

As Jay has already mentioned … this is the value which is
used for the macro and serves as a hint only as to the size
of the message/data being passed. It in no way reflects
the actual size limitation of the message being passed. If
you want to pass larger messages/data structures, it must
means that you will need to come up with a different value
to put into the size field rather than just a sizeof() value.

This also happens to be mentioned in:

http://staff.qnx.com/~thomasf/nto.html
http://staff.qnx.com/~thomasf/wtf-resmgr.html

Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf