Hi,
I have extended OCB with my own fields as suggested in
http://support.qnx.com/support/docs/neutrino/prog/resmgr.html#DCS
In order to access the my own fields, how can I access the OCB allocated
by iofunc_open_default() within my own io_open() handler?
Regards.
-chang
Chang Im <chim@cisco.com> wrote:
Hi,
I have extended OCB with my own fields as suggested in
http://support.qnx.com/support/docs/neutrino/prog/resmgr.html#DCS
In order to access the my own fields, how can I access the OCB allocated
by iofunc_open_default() within my own io_open() handler?
You need to make a #define before you include the resource manager include file.
Warning: blatant ad follows 
If you have a copy of my book, it’s on pages 363-366
Cheers,
-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.
Robert Krten <nospam89@parse.com> wrote:
Chang Im <> chim@cisco.com> > wrote:
Hi,I have extended OCB with my own fields as suggested in
http://support.qnx.com/support/docs/neutrino/prog/resmgr.html#DCS
In order to access the my own fields, how can I access the OCB allocated
by iofunc_open_default() within my own io_open() handler?
You need to make a #define before you include the resource manager include file.
Warning: blatant ad follows >
If you have a copy of my book, it’s on pages 363-366 >
I’ve got a copy of your book…maybe the wrong edition? But there isn’t
anything in it on pages 363-366 about accessing the ocb in the
io_open handler.
The problem, is that there is an ocb allocated until after you call
iofunc_open_default(), but iofunc_open_default() doesn’t tell you which
OCB it allocated – it doesn’t return the point.
Since you’ve extended the OCB, you are over-riding the ocb allocation
function using the iofunc_mount_t structure, right?
Normally, if you have to do any manipulations/initializations of the
OCB, you’ll do them in your allocation structure. It gets past a
resmgr_context_t and a attribute structure, so you should have all
the information you need at that point.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote:
Robert Krten <> nospam89@parse.com> > wrote:
Chang Im <> chim@cisco.com> > wrote:
Hi,I have extended OCB with my own fields as suggested in
http://support.qnx.com/support/docs/neutrino/prog/resmgr.html#DCS
In order to access the my own fields, how can I access the OCB allocated
by iofunc_open_default() within my own io_open() handler?
You need to make a #define before you include the resource manager include file.
Warning: blatant ad follows >
If you have a copy of my book, it’s on pages 363-366 >I’ve got a copy of your book…maybe the wrong edition? But there isn’t
anything in it on pages 363-366 about accessing the ocb in the
io_open handler.
This was for the second edition
The problem, is that there is an ocb allocated until after you call
iofunc_open_default(), but iofunc_open_default() doesn’t tell you which
OCB it allocated – it doesn’t return the point.
You are correct; there is no clean way of accessing the newly-allocated OCB
if you use iofunc_open_default(), my mistake.
Cheers,
-RK
Since you’ve extended the OCB, you are over-riding the ocb allocation
function using the iofunc_mount_t structure, right?Normally, if you have to do any manipulations/initializations of the
OCB, you’ll do them in your allocation structure. It gets past a
resmgr_context_t and a attribute structure, so you should have all
the information you need at that point.-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
–
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.
“Robert Krten” <nospam89@parse.com> wrote in message
news:a9mr3a$7rp$1@inn.qnx.com…
David Gibbs <> dagibbs@qnx.com> > wrote:
[snipped…]
The problem, is that there is an ocb allocated until after you call
iofunc_open_default(), but iofunc_open_default() doesn’t tell you which
OCB it allocated – it doesn’t return the point.You are correct; there is no clean way of accessing the newly-allocated
OCB
if you use iofunc_open_default(), my mistake.Cheers,
-RKSince you’ve extended the OCB, you are over-riding the ocb allocation
function using the iofunc_mount_t structure, right?Normally, if you have to do any manipulations/initializations of the
OCB, you’ll do them in your allocation structure. It gets past a
resmgr_context_t and a attribute structure, so you should have all
the information you need at that point.
What if I need to copy some data such as connect.path from the io_open_t msg
passed to my io_open() handler into OCB. I don’t think this can be done in
the
OCB allocation routine.
In this case, it seems that I should not use iofunc_open_default(), instead
use
the lower level routines to do it myself:
iofunc_ocb_calloc(), iofunc_ocb_attach() and resmgr_open_bind().
-chang
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.–
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.
Chang Im <chim@cisco.com> wrote:
“Robert Krten” <> nospam89@parse.com> > wrote in message
news:a9mr3a$7rp$> 1@inn.qnx.com> …
David Gibbs <> dagibbs@qnx.com> > wrote:[snipped…]
The problem, is that there is an ocb allocated until after you call
iofunc_open_default(), but iofunc_open_default() doesn’t tell you which
OCB it allocated – it doesn’t return the point.You are correct; there is no clean way of accessing the newly-allocated
OCB
if you use iofunc_open_default(), my mistake.Cheers,
-RKSince you’ve extended the OCB, you are over-riding the ocb allocation
function using the iofunc_mount_t structure, right?Normally, if you have to do any manipulations/initializations of the
OCB, you’ll do them in your allocation structure. It gets past a
resmgr_context_t and a attribute structure, so you should have all
the information you need at that point.
What if I need to copy some data such as connect.path from the io_open_t msg
passed to my io_open() handler into OCB. I don’t think this can be done in
the
OCB allocation routine.In this case, it seems that I should not use iofunc_open_default(), instead
use
the lower level routines to do it myself:
iofunc_ocb_calloc(), iofunc_ocb_attach() and resmgr_open_bind().
That’s certainly an option. [to interested readers; some of this thread has been
moved to email]
Cheers,
-RK
-chang
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.–
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.
–
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.
Chang Im <chim@cisco.com> wrote:
“Robert Krten” <> nospam89@parse.com> > wrote in message
news:a9mr3a$7rp$> 1@inn.qnx.com> …
David Gibbs <> dagibbs@qnx.com> > wrote:[snipped…]
The problem, is that there is an ocb allocated until after you call
iofunc_open_default(), but iofunc_open_default() doesn’t tell you which
OCB it allocated – it doesn’t return the point.You are correct; there is no clean way of accessing the newly-allocated
OCB
if you use iofunc_open_default(), my mistake.Cheers,
-RKSince you’ve extended the OCB, you are over-riding the ocb allocation
function using the iofunc_mount_t structure, right?Normally, if you have to do any manipulations/initializations of the
OCB, you’ll do them in your allocation structure. It gets past a
resmgr_context_t and a attribute structure, so you should have all
the information you need at that point.
What if I need to copy some data such as connect.path from the io_open_t msg
passed to my io_open() handler into OCB. I don’t think this can be done in
the
OCB allocation routine.
It can – you have the resmgr_context_t, which includes a pointer to the
receive buffer, from which you can get to the io_open_t.
ctp->msg.open
-David
In this case, it seems that I should not use iofunc_open_default(), instead
use
the lower level routines to do it myself:
iofunc_ocb_calloc(), iofunc_ocb_attach() and resmgr_open_bind().-chang
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.–
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.
–
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Hi Chang,
Just a point, I don’t know if you need the connect.path to know which of
the paths your resmgr manages, received the open request.
In this case I think it’s not the neatest way. Prefer to use inode or
rdev in the attribute structure.
another method is to overload the attribute structure to store any ‘per
device’ informations as opposed to the ‘per open’ ocb informations.
Otherwise, as you said, allocating and doing whatever you need with your
ocb should be done in the dedicated iofunc_ocb_calloc() function.
DON’T forget to add the needed corresponding free() in iofunc_ocb_free()
in case of an alloc call in iofunc_ocb_calloc().
regards,
Alain.
Chang Im wrote:
“Robert Krten” <> nospam89@parse.com> > wrote in message
news:a9mr3a$7rp$> 1@inn.qnx.com> …David Gibbs <> dagibbs@qnx.com> > wrote:
[snipped…]The problem, is that there is an ocb allocated until after you call
iofunc_open_default(), but iofunc_open_default() doesn’t tell you which
OCB it allocated – it doesn’t return the point.You are correct; there is no clean way of accessing the newly-allocated
OCB
if you use iofunc_open_default(), my mistake.
Cheers,
-RKSince you’ve extended the OCB, you are over-riding the ocb allocation
function using the iofunc_mount_t structure, right?Normally, if you have to do any manipulations/initializations of the
OCB, you’ll do them in your allocation structure. It gets past a
resmgr_context_t and a attribute structure, so you should have all
the information you need at that point.
What if I need to copy some data such as connect.path from the io_open_t msg
passed to my io_open() handler into OCB. I don’t think this can be done in
the
OCB allocation routine.In this case, it seems that I should not use iofunc_open_default(), instead
use
the lower level routines to do it myself:
iofunc_ocb_calloc(), iofunc_ocb_attach() and resmgr_open_bind().-chang
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.–
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.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:a9nc9p$t2d$1@nntp.qnx.com…
[snipped]
What if I need to copy some data such as connect.path from the io_open_t
msg
passed to my io_open() handler into OCB. I don’t think this can be done
in
the
OCB allocation routine.It can – you have the resmgr_context_t, which includes a pointer to the
receive buffer, from which you can get to the io_open_t.ctp->msg.open
Yes, it certainly does. (minor typo: ctp->msg->open or ctp->msg->connect)
One concern is that my OCB alloc routine could be called by non open message
such as io_mmap.
For my usage, I think I can use attribute structure instead, but it would
be nice
if OCB is accessable after calling iofunc_open_default().
-chang.
Chang Im <chim@cisco.com> wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:a9nc9p$t2d$> 1@nntp.qnx.com> …
[snipped]
What if I need to copy some data such as connect.path from the io_open_t
msg
passed to my io_open() handler into OCB. I don’t think this can be done
in
the
OCB allocation routine.It can – you have the resmgr_context_t, which includes a pointer to the
receive buffer, from which you can get to the io_open_t.ctp->msg.open
Yes, it certainly does. (minor typo: ctp->msg->open or ctp->msg->connect)
One concern is that my OCB alloc routine could be called by non open message
such as io_mmap.
You can always check the msg->type, make sure it is what you wanted.
-xtang
For my usage, I think I can use attribute structure instead, but it would
be nice
if OCB is accessable after calling iofunc_open_default().-chang.
Chang Im <chim@cisco.com> wrote:
“Robert Krten” <> nospam89@parse.com> > wrote in message
news:a9mr3a$7rp$> 1@inn.qnx.com> …
David Gibbs <> dagibbs@qnx.com> > wrote:[snipped…]
The problem, is that there is an ocb allocated until after you call
iofunc_open_default(), but iofunc_open_default() doesn’t tell you which
OCB it allocated – it doesn’t return the point.You are correct; there is no clean way of accessing the newly-allocated
OCB
if you use iofunc_open_default(), my mistake.Cheers,
-RKSince you’ve extended the OCB, you are over-riding the ocb allocation
function using the iofunc_mount_t structure, right?Normally, if you have to do any manipulations/initializations of the
OCB, you’ll do them in your allocation structure. It gets past a
resmgr_context_t and a attribute structure, so you should have all
the information you need at that point.
What if I need to copy some data such as connect.path from the io_open_t msg
passed to my io_open() handler into OCB. I don’t think this can be done in
the OCB allocation routine.
In this case, it seems that I should not use iofunc_open_default(), instead
use
the lower level routines to do it myself:
iofunc_ocb_calloc(), iofunc_ocb_attach() and resmgr_open_bind().
You should always be able to fully initialize an OCB from an attribute.
You can certainly do the iofunc_* callouts yourself, but you have to
be very careful because the ocb creation is not just from an open()
callout. For example you may be asked to create an ocb from an
attribute in response to a mmap() call.
It would be better to ensure that your attribute contains all of the
information that you need about a particular resource to make per
connection (ie ocb) instantiations.
Thomas
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.–
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.
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Core OS Technology Group
(613)-591-0931 http://www.qnx.com/