> I'm working to create a 'proper' converter and protocol module. Although 
> they're not a protocol/converter combo, I have the nraw sources that I've used
>  as an example to create the converter module and I believe I can get the io-
> net part of the protocol module done without much trouble. What I'm missing is
>  the 'magic' that gets a resource manager connected. I say 'magic' because in 

During the init() call, a dispatch_t * is passed to a module. Feel free to resmgr_attach()  with this dpp, to hookup 
your own resource manager.

You can also create your own dpp, and hook a resource manager with it. The difference is just if you use the dpp passed 
in, you are using the thread pool created by io-net, ie, you are sharing a thread pool with others.

> nraw, it looks like the resource manager gets hooked in using the raw_open 
> function in the io_net_registrant_funcs. Without any docs for this function, 
> I'm missing how raw_open gets used to hook a resource manager to the converter
> /protocol. I guess I could use a function based interface for the protocol but
>  that doesn't seem like the QNX way. Based on everything I've read, it seems 
> like the 'right' way to include a custom protocol is to use a resource manager
>  so an open/read/write interface is available to applications. If you have 
> some better sample code, or a description of using raw_open, I'd appreciate 
> the help.

The "raw_open" is more of handling the /dev/io-net/xxx pathname. As you discovered in another post, io-net always create
 a pathname for modules it is loaded. 

But you are not limited to this /dev/io-net/xxx pathname, as mentioned above, calling resmgr_attach() yourself, you can 
attach to ANY pathname as you wish. A lot of modules doing that. (for example, qnet attach to /proc/qnetstats, pppmgr 
attach to /dev/socket/pppmgr, ....)