Hi Everybody,
I’m writing a resource manager under Neutrino, and would like to ask a
question:
The resource manager I’m writing registers few names under /dev. Only one
set of connect_funcs and io_funcs is registered for all the pathnames. I
would like then, in my io_read and io_write, to use a “case” structure, in
order to deal with the different registered devices. To do that I need to
know which device each call to io_read()/io_write() was intended for. It
appears to me that the way to do this is to compare the id field of the
resmgr_context structure passed to the io_read()/io_write() with the id that
was returned by resmgr_attach() for each device.
Here is my question: is this the appropriate way to deal with more pathnames
in a ResMgr ? What puzzles me is that in his nice book “Getting started with
QNX Neutrino 2” pag. 270 Rob Krten says about resmgr_context.id: “You’d most
likely never use this parameter yourself”.
Am I going absolutely wrong about the structure of my ResMgr ?
Thanks a lot for any comment,
Andrea Borsic.
Andrea Borsic <aborsic@brookes.ac.uk> wrote:
Hi Everybody,
I’m writing a resource manager under Neutrino, and would like to ask a
question:
The resource manager I’m writing registers few names under /dev. Only one
set of connect_funcs and io_funcs is registered for all the pathnames. I
would like then, in my io_read and io_write, to use a “case” structure, in
order to deal with the different registered devices. To do that I need to
know which device each call to io_read()/io_write() was intended for. It
appears to me that the way to do this is to compare the id field of the
resmgr_context structure passed to the io_read()/io_write() with the id that
was returned by resmgr_attach() for each device.
Here is my question: is this the appropriate way to deal with more pathnames
in a ResMgr ? What puzzles me is that in his nice book “Getting started with
QNX Neutrino 2” pag. 270 Rob Krten says about resmgr_context.id: “You’d most
likely never use this parameter yourself”.
Am I going absolutely wrong about the structure of my ResMgr ?
It’s all lies! 
I’d generally have multiple attributes structures, one for each device.
If they are in an array, then it’s a simple pointer arithmetic operation
to compare the ocb → attr against the base of the array.
So, in your io_read()/io_write() handlers, take a look at “ocb → attr”,
which will point to one of the attributes structure in you array (let’s
call it attr_array[] here). Then, you can either extend your attr structures,
and store whatever info you want on a per-device basis within the attr
structures, (thus you can simply access the data), or you can have a parallel
structure and simply do “index = ocb → attr - attr_array;”
Cheers, and thanks for the kind words about the book!
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Dear Robert,
Thanks for the precious information,
Andrea.
“Robert Krten” <nospam88@parse.com> wrote in message
news:ad57j3$abp$1@inn.qnx.com…
Andrea Borsic <> aborsic@brookes.ac.uk> > wrote:
Hi Everybody,
I’m writing a resource manager under Neutrino, and would like to ask a
question:
The resource manager I’m writing registers few names under /dev. Only
one
set of connect_funcs and io_funcs is registered for all the pathnames. I
would like then, in my io_read and io_write, to use a “case” structure,
in
order to deal with the different registered devices. To do that I need
to
know which device each call to io_read()/io_write() was intended for. It
appears to me that the way to do this is to compare the id field of the
resmgr_context structure passed to the io_read()/io_write() with the id
that
was returned by resmgr_attach() for each device.
Here is my question: is this the appropriate way to deal with more
pathnames
in a ResMgr ? What puzzles me is that in his nice book “Getting started
with
QNX Neutrino 2” pag. 270 Rob Krten says about resmgr_context.id: “You’d
most
likely never use this parameter yourself”.
Am I going absolutely wrong about the structure of my ResMgr ?
It’s all lies! >
I’d generally have multiple attributes structures, one for each device.
If they are in an array, then it’s a simple pointer arithmetic operation
to compare the ocb → attr against the base of the array.
So, in your io_read()/io_write() handlers, take a look at “ocb → attr”,
which will point to one of the attributes structure in you array (let’s
call it attr_array[] here). Then, you can either extend your attr
structures,
and store whatever info you want on a per-device basis within the attr
structures, (thus you can simply access the data), or you can have a
parallel
structure and simply do “index = ocb → attr - attr_array;”
Cheers, and thanks for the kind words about the book!
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.