QNX4 USB Process Interface Design

Hello,

I am having problems with memory faults when using USB SDK under QNX4. My
goal is to use the IO Manager framework such that after a device enumerates
and entry in the prefix tree appears for read, write, and ioctl operations
from other processes. I was given a work around which uses an internal
frame work supplied in the iomgr.lib supplied in the beta version of the
SDK. This appears to be incompatible with the iomgr framework available on
QUICS as it implements pthread functions (determined from unresolved
references when linked against the Framework library).

I have been able to communicate with my device within the insertion callback
with no anomalies, but any attempts to communicate from outside the child
process have resulted in memory faults. I have tried to tfork the server
process but this results in the Receive function of my parent crashing in
memory fault. I have tried storing all the results from my usbd_* calls in
shared memory but this leads to a memory fault in the first call to the
stack outside of the one process.

I have another process which is now managing my prefix tree. As devices are
inserted and removed update information is sent to the other process for the
control of the available devices.

Is there an interface with /dev/usb which I am not understanding?
Is there a way to interface with the server with user implemented read,
write, and ioctl functions?

Any ideas would be appreciated.

Thank you,

Arthur Peet

The framework suggested previously is as follows:

o
o
o

if( fork() == 0) { // tfork will not work.

if( server_init( ) == -1 ) {
fprintf( stderr, “Unable to initialize server\n” );
return( -1 );


if ( status = inode_init( 10 ) ) != EOK ) {
fprintf( stderr, “Unable to init inode table (%s)\n”,
strerror( status ) );
return( -1 );
}

// Connect to the stack.
connectStatus = usbd_connect( &shm->deviceParms, &shm->connection ); //
This will not work outside of this fork.

server( &version ); // This call is different than the standard IO Lib
which accepts no parameters (void).

} else { file://Parent

while( 1 ){

Receive( …… ); // I would like to accept messages for read, write,
and ioctl operations in this process.
o
o // I have no way to access the usbd_* functions within this
fork.
o // I have tried tfork and shared memory to no avail.
o
switch( msg……){
}
}

Arthur C Peet <arthur.peet@toltecint.com> wrote:

Hello,

I am having problems with memory faults when using USB SDK under QNX4. My
goal is to use the IO Manager framework such that after a device enumerates
and entry in the prefix tree appears for read, write, and ioctl operations
from other processes. I was given a work around which uses an internal
frame work supplied in the iomgr.lib supplied in the beta version of the
SDK. This appears to be incompatible with the iomgr framework available on
QUICS as it implements pthread functions (determined from unresolved
references when linked against the Framework library).

The iomgr.lib in the USB DDK is very compatible with the iomgr framework
available on QUICS. The USB version is based on the QUICS version with
the addition of co-routines.

I have been able to communicate with my device within the insertion callback
with no anomalies, but any attempts to communicate from outside the child
process have resulted in memory faults. I have tried to tfork the server
process but this results in the Receive function of my parent crashing in
memory fault. I have tried storing all the results from my usbd_* calls in
shared memory but this leads to a memory fault in the first call to the
stack outside of the one process.

This is caused by a problem with tfork and the qnx_segment_alloc functions.
A new DDK is going through QA that has a work-around for this problem.

I have another process which is now managing my prefix tree. As devices are
inserted and removed update information is sent to the other process for the
control of the available devices.

Is there an interface with /dev/usb which I am not understanding?
Is there a way to interface with the server with user implemented read,
write, and ioctl functions?

Any ideas would be appreciated.

Have you looked at the printer class driver available in the DDK?
It supports read/write/ioctl etc…

Kevin Chiles wrote in message <99a9jj$gbs$1@nntp.qnx.com>…

Arthur C Peet <> arthur.peet@toltecint.com> > wrote:
Hello,
Thanks for your response Kevin. More details below.

I am having problems with memory faults when using USB SDK under QNX4.
My
goal is to use the IO Manager framework such that after a device
enumerates
and entry in the prefix tree appears for read, write, and ioctl
operations
from other processes. I was given a work around which uses an internal
frame work supplied in the iomgr.lib supplied in the beta version of the
SDK. This appears to be incompatible with the iomgr framework available
on
QUICS as it implements pthread functions (determined from unresolved
references when linked against the Framework library).

The iomgr.lib in the USB DDK is very compatible with the iomgr framework
available on QUICS. The USB version is based on the QUICS version with
the addition of co-routines.

I guess I should have been more specific when I said “incompatible”. The
create_dir implementation in the USB version is generating a mem fault
somewhere in the ialloc module. The d_link defines appear to be missing,
and of course, several of the functions called in the library now take
different arguments. Have there been any other reports on the create_dir
problem?

Is there a way to interface with the server with user implemented read,
write, and ioctl functions?

Any ideas would be appreciated.

Have you looked at the printer class driver available in the DDK?
It supports read/write/ioctl etc…

Thank you. I have now.

Art

Hello again,
I forgot to ask about the use and implications of the procmgr_daemon()
function call in the library.
Thanks again,
Art

Arthur C Peet wrote in message <99c8mh$jnf$1@inn.qnx.com>…

Kevin Chiles wrote in message <99a9jj$gbs$> 1@nntp.qnx.com> >…
Arthur C Peet <> arthur.peet@toltecint.com> > wrote:
Hello,
Thanks for your response Kevin. More details below.

I am having problems with memory faults when using USB SDK under QNX4.
My
goal is to use the IO Manager framework such that after a device
enumerates
and entry in the prefix tree appears for read, write, and ioctl
operations
from other processes. I was given a work around which uses an internal
frame work supplied in the iomgr.lib supplied in the beta version of the
SDK. This appears to be incompatible with the iomgr framework available
on
QUICS as it implements pthread functions (determined from unresolved
references when linked against the Framework library).

The iomgr.lib in the USB DDK is very compatible with the iomgr framework
available on QUICS. The USB version is based on the QUICS version with
the addition of co-routines.

I guess I should have been more specific when I said “incompatible”. The
create_dir implementation in the USB version is generating a mem fault
somewhere in the ialloc module. The d_link defines appear to be missing,
and of course, several of the functions called in the library now take
different arguments. Have there been any other reports on the create_dir
problem?

SNIP

Is there a way to interface with the server with user implemented read,
write, and ioctl functions?

Any ideas would be appreciated.

Have you looked at the printer class driver available in the DDK?
It supports read/write/ioctl etc…

Thank you. I have now.

Art
\

I’m also attempting to write a USB driver for QNX4 and running into the same
issue as you are with regards to the example USB SDK code making references
to undocumented library calls.

However, I found some of the definitions in the Neutrino online help files.
See support.qnx.com/support/docs/neutrino_qrp/lib_ref/p/procmgr_daemon.html
for the link to the Neutrino help page for the “procmgr_daemon” call. Note
that the help file indicates this call is classificated for Neutrino only.
FYI: I also found the “pthread*” calls defined under Neutrino as well.

The question now is what does this mean to those of us running these
Neutrino calls under QNX4? Does QNX plan to support all these Neutrino
calls under QNX4 for thier final release of ths USB? Maybe someone at QNX
could answer this question so the QNX4 USB developers can design/implement
accordingly.

“Arthur C Peet” <arthur.peet@toltecint.com> wrote in message
news:99cc4m$lmu$1@inn.qnx.com

Hello again,
I forgot to ask about the use and implications of the procmgr_daemon()
function call in the library.
Thanks again,
Art

Arthur C Peet wrote in message <99c8mh$jnf$> 1@inn.qnx.com> >…

Kevin Chiles wrote in message <99a9jj$gbs$> 1@nntp.qnx.com> >…
Arthur C Peet <> arthur.peet@toltecint.com> > wrote:
Hello,
Thanks for your response Kevin. More details below.

I am having problems with memory faults when using USB SDK under QNX4.
My
goal is to use the IO Manager framework such that after a device
enumerates
and entry in the prefix tree appears for read, write, and ioctl
operations
from other processes. I was given a work around which uses an
internal
frame work supplied in the iomgr.lib supplied in the beta version of
the
SDK. This appears to be incompatible with the iomgr framework
available
on
QUICS as it implements pthread functions (determined from unresolved
references when linked against the Framework library).

The iomgr.lib in the USB DDK is very compatible with the iomgr framework
available on QUICS. The USB version is based on the QUICS version with
the addition of co-routines.

I guess I should have been more specific when I said “incompatible”. The
create_dir implementation in the USB version is generating a mem fault
somewhere in the ialloc module. The d_link defines appear to be missing,
and of course, several of the functions called in the library now take
different arguments. Have there been any other reports on the create_dir
problem?

SNIP

Is there a way to interface with the server with user implemented
read,
write, and ioctl functions?

Any ideas would be appreciated.

Have you looked at the printer class driver available in the DDK?
It supports read/write/ioctl etc…

Thank you. I have now.

Art


\

Arthur C Peet <arthur.peet@toltecint.com> wrote:

Kevin Chiles wrote in message <99a9jj$gbs$> 1@nntp.qnx.com> >…
Arthur C Peet <> arthur.peet@toltecint.com> > wrote:
Hello,
Thanks for your response Kevin. More details below.

I am having problems with memory faults when using USB SDK under QNX4.
My
goal is to use the IO Manager framework such that after a device
enumerates
and entry in the prefix tree appears for read, write, and ioctl
operations
from other processes. I was given a work around which uses an internal
frame work supplied in the iomgr.lib supplied in the beta version of the
SDK. This appears to be incompatible with the iomgr framework available
on
QUICS as it implements pthread functions (determined from unresolved
references when linked against the Framework library).

The iomgr.lib in the USB DDK is very compatible with the iomgr framework
available on QUICS. The USB version is based on the QUICS version with
the addition of co-routines.

I guess I should have been more specific when I said “incompatible”. The
create_dir implementation in the USB version is generating a mem fault
somewhere in the ialloc module. The d_link defines appear to be missing,
and of course, several of the functions called in the library now take
different arguments. Have there been any other reports on the create_dir
problem?

Okay, I found the problem. I will fix this up and have a new ddk posted.

Arthur C Peet <arthur.peet@toltecint.com> wrote:

Hello again,
I forgot to ask about the use and implications of the procmgr_daemon()
function call in the library.
Thanks again,
Art

The function procmgr_daemon() lets programs detach themselves
from the controlling terminal and run in the background as
system daemons.

Paul Holmquist <paul.holmquist@guidant.com> wrote:

I’m also attempting to write a USB driver for QNX4 and running into the same
issue as you are with regards to the example USB SDK code making references
to undocumented library calls.

However, I found some of the definitions in the Neutrino online help files.
See support.qnx.com/support/docs/neutrino_qrp/lib_ref/p/procmgr_daemon.html
for the link to the Neutrino help page for the “procmgr_daemon” call. Note
that the help file indicates this call is classificated for Neutrino only.
FYI: I also found the “pthread*” calls defined under Neutrino as well.

The question now is what does this mean to those of us running these
Neutrino calls under QNX4? Does QNX plan to support all these Neutrino
calls under QNX4 for thier final release of ths USB? Maybe someone at QNX
could answer this question so the QNX4 USB developers can design/implement
accordingly.

No. The Neutrino calls will not be supported in QNX4. The QNX4 USB stack
uses co-routines to emulate threads. Instead of creating a new thread api,
the pthread_xxx interface was used.

The following pthread calls are supported:
pthread_mutex_init
pthread_mutex_destroy
pthread_mutex_lock
pthread_mutex_unlock
pthread_sleepon_lock
pthread_sleepon_unlock
pthread_sleepon_wait
pthread_sleepon_timedwait
pthread_sleepon_signal
pthread_sleepon_broadcast
pthread_create
pthread_mutexattr_destroy
pthread_mutexattr_init


The following are special notes for the above functions to work correctly:

  • server_init and server functions must be called prior to use
  • threads created must not run ready
  • co-routine threads should only block with pthread_mutex_lock
    and pthread_sleepon_wait.

The function procmgr_daemon() function lets programs detach themselves
from the controlling terminal and run in the background as system daemons.