Xiaodan Tang(deleted)
|
Re: RE: Writing non-driver io-net modules
|
Xiaodan Tang(deleted)
06/25/2008 9:18 PM
post9689
|
Re: RE: Writing non-driver io-net modules
> 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, ....)
|
|
|