I’m writing a device driver, and it would be very convenient if I
could discover the OCB that is created as a result of handling an
open. In my code I do some checking, create any directory hierarchy,
and then call iofunc_open_default(…). After this point, I presume
that the OCB has been created, but the question is: how do I discover
its pointer? I want to associate data at this point with the newly
created OCB. Yes, I have extended the OCB. Any ideas?
Thanks,
Andrew
“overload” the ocb_malloc function.
“Andrew Thomas” <Andrew@cogent.ca> wrote in message
news:Voyager.010110093229.4173877D@localhost…
I’m writing a device driver, and it would be very convenient if I
could discover the OCB that is created as a result of handling an
open. In my code I do some checking, create any directory hierarchy,
and then call iofunc_open_default(…). After this point, I presume
that the OCB has been created, but the question is: how do I discover
its pointer? I want to associate data at this point with the newly
created OCB. Yes, I have extended the OCB. Any ideas?Thanks,
Andrew
Previously, Mario Charest wrote in qdn.public.qnxrtp.os:
“overload” the ocb_malloc function.
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:Voyager.010110093229.4173877D@localhost…
I’m writing a device driver, and it would be very convenient if I
could discover the OCB that is created as a result of handling an
open. In my code I do some checking, create any directory hierarchy,
[…]
I do overload the ocb_calloc, but the information I want is not
available at that point. Am I guaranteed that ocb_calloc will only be
called from open() processing? Are you suggesting that I stuff my
information into a global variable and then jam it into the ocb during
the ocb_calloc function? That seems pretty ugly to me.
Surely the ocb is available somehow once the iofunc_open_default()
finishes?
Cheers,
Andrew
“Andrew Thomas” <Andrew@cogent.ca> wrote in message
news:Voyager.010110163719.1376297A@localhost…
Previously, Mario Charest wrote in qdn.public.qnxrtp.os:
“overload” the ocb_malloc function.
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:Voyager.010110093229.4173877D@localhost…
I’m writing a device driver, and it would be very convenient if I
could discover the OCB that is created as a result of handling an
open. In my code I do some checking, create any directory hierarchy,
[…]I do overload the ocb_calloc, but the information I want is not
available at that point. Am I guaranteed that ocb_calloc will only be
called from open() processing? Are you suggesting that I stuff my
information into a global variable and then jam it into the ocb during
the ocb_calloc function? That seems pretty ugly to me.
I pass the info through the attribute structure that gets passed to
ocb_callloc
Surely the ocb is available somehow once the iofunc_open_default()
finishes?
Not to my knowledge. After looking hard and asking a few people,
I ended up using ocb_calloc.
Cheers,
Andrew
Previously, Thomas Fletcher wrote in qdn.public.qnxrtp.os:
Mario Charest <mcharest@void_zinformatic.com> wrote:
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:Voyager.010110163719.1376297A@localhost…
Previously, Mario Charest wrote in qdn.public.qnxrtp.os:“overload” the ocb_malloc function.
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:Voyager.010110093229.4173877D@localhost…
I’m writing a device driver, and it would be very convenient if I
could discover the OCB that is created as a result of handling an
open. In my code I do some checking, create any directory hierarchy,
[…]I do overload the ocb_calloc, but the information I want is not
available at that point. Am I guaranteed that ocb_calloc will only be
called from open() processing? Are you suggesting that I stuff my
information into a global variable and then jam it into the ocb during
the ocb_calloc function? That seems pretty ugly to me.
I pass the info through the attribute structure that gets passed to
ocb_calllocSurely the ocb is available somehow once the iofunc_open_default()
finishes?
Not to my knowledge. After looking hard and asking a few people,
I ended up using ocb_calloc.I think that we’ve debated this design before (I’d say search the
historical discussions … but I don’t know if that facility is
available yet through QDN).
[…]
Thanks, Mario and Thomas.
I ended up doing what Mario suggested, which is to put “carrier”
fields into the attribute structure, and then set a magic value in one
of the carriers to let the ocb_calloc know when it is being called
from an open(). I am kind of curious to know whether there is any
instance where ocb_calloc is called more than once as a result of
open() handling through the resource manager library. This could
potentially cause my carrier fields to be delivered to the wrong
ocb_calloc.
Cheers,
Andrew
Mario Charest <mcharest@void_zinformatic.com> wrote:
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:Voyager.010110163719.1376297A@localhost…
Previously, Mario Charest wrote in qdn.public.qnxrtp.os:“overload” the ocb_malloc function.
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:Voyager.010110093229.4173877D@localhost…
I’m writing a device driver, and it would be very convenient if I
could discover the OCB that is created as a result of handling an
open. In my code I do some checking, create any directory hierarchy,
[…]I do overload the ocb_calloc, but the information I want is not
available at that point. Am I guaranteed that ocb_calloc will only be
called from open() processing? Are you suggesting that I stuff my
information into a global variable and then jam it into the ocb during
the ocb_calloc function? That seems pretty ugly to me.
I pass the info through the attribute structure that gets passed to
ocb_calllocSurely the ocb is available somehow once the iofunc_open_default()
finishes?
Not to my knowledge. After looking hard and asking a few people,
I ended up using ocb_calloc.
I think that we’ve debated this design before (I’d say search the
historical discussions … but I don’t know if that facility is
available yet through QDN).
In a nutshell you have no guarantee where your ocb_calloc function
is going to be called from. The hope was that in an ideal world
you would be able to fully initialize your ocb based on the connection
information and the attribute that you created. Of course lots of
times this is awkward or impractical which is why there is an ocb
option to iofunc_open so that you can do your own ocb allocation
and then pass it it. Unfortunately iofunc_open_default() doesn’t
allows this (since it was designed to match the prototypes for
the open handler exactly) so you might have to roll your own:
lock(attr);
iofunc_open();
→ Create your ocb from the mount callouts or via iofunc_ocb_calloc.
iofunc_ocb_attach();
→ Attach extra information to your bound ocb as required.
unlock(attr);
Of course the problem now is that if an ocb gets allocated from
some other part of the resource manager framework (ie mmap) then
you have to be able to properly fill in the ocb based on the
attribute itself.
Hope that this helps,
Thomas
“Andrew Thomas” <Andrew@cogent.ca> wrote in message
news:Voyager.010111104110.1527852A@localhost…
Previously, Thomas Fletcher wrote in qdn.public.qnxrtp.os:
Mario Charest <mcharest@void_zinformatic.com> wrote:
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:Voyager.010110163719.1376297A@localhost…
Previously, Mario Charest wrote in qdn.public.qnxrtp.os:“overload” the ocb_malloc function.
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:Voyager.010110093229.4173877D@localhost…
I’m writing a device driver, and it would be very convenient if I
could discover the OCB that is created as a result of handling an
open. In my code I do some checking, create any directory
hierarchy,
[…]I do overload the ocb_calloc, but the information I want is not
available at that point. Am I guaranteed that ocb_calloc will only
be
called from open() processing? Are you suggesting that I stuff my
information into a global variable and then jam it into the ocb
during
the ocb_calloc function? That seems pretty ugly to me.
I pass the info through the attribute structure that gets passed to
ocb_calllocSurely the ocb is available somehow once the iofunc_open_default()
finishes?
Not to my knowledge. After looking hard and asking a few people,
I ended up using ocb_calloc.I think that we’ve debated this design before (I’d say search the
historical discussions … but I don’t know if that facility is
available yet through QDN).
[…]Thanks, Mario and Thomas.
I ended up doing what Mario suggested, which is to put “carrier”
fields into the attribute structure, and then set a magic value in one
of the carriers to let the ocb_calloc know when it is being called
from an open(). I am kind of curious to know whether there is any
instance where ocb_calloc is called more than once as a result of
open() handling through the resource manager library. This could
potentially cause my carrier fields to be delivered to the wrong
ocb_calloc.
I’m playing with such stuff now and i asked QSSL about this too. Thanks to
Thomas Flatcher =), he explained me
how it works.
First of all they recommend to overload IOFUNC_ATTR_T structure if you want,
and use it as carrier.
You can set up the mount structure (you have pointer in iofunc_attr_t ) to
define which function to call when you need to allocate different OCBs.
You setup the iofunc_attr_t, and now you can call open_default. and your
function will be called. (You can print out to make sure =)
And if you need to find out when they call your ocb_alloc, you can print in
dispatch loop. I did this and found some interesting things, like they love
to use subtypes and e.g. call stat handler when do open.
If you need some code i can send it to you.
Good luck
Cheers,
Andrew