Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/iofunc_open_default Memory Ownership/List of Posts
Forum Topic - iofunc_open_default Memory Ownership: (6 Items)
   
Update
Mark Dowdy(deleted)
03/26/2010 8:50 PM
post50613
iofunc_open_default Memory Ownership   
The documentation for iofunc_open_default doesn't mention memory 'ownership' for the structured passed in the attr 
parameter. Can anyone help with the memory requirements for the attr parameter? Are the values in the passed in 
structure copied to a resource manager control structure or is the memory pointed to by attr expected to remain valid 
for the duration of the session (i.e. attr should not be automatic or reused for multiple 'files/directories')?

I ask because I'm attempting to create a resource manager to provide access to the registers on a number of devices 
connected to our product. Each device has over 250 registers and there can be from one to twenty devices on the bus. 
That's a lot of attr structures if they have to be unique. FWIW,  I'm looking at a directory hierarchy along the lines 
of [mount point]/device/[device number]/[register number]. I need to dynamically populate the 'device' directory because
 the number of devices is discovered and varies depending on system configuration. A directory listing of the 'device' 
directory should show all devices currently running. All devices have the same register set.

Thanks.

Mark
David Sarrazin
03/29/2010 11:59 AM
post50706
RE: iofunc_open_default Memory Ownership   
Mark,

The iofunc_attr_t structure has to be unique for each unique named
entity that is opened in the resource manager, so the memory
requirements will be based on how many open FD there are, and not how
many total "files" exist, assuming you are passing _RESMGMR_FLAG_DIR to
the resmgr_attach() call.  The iofunc_attr_t will need to be allocated
on IO_OPEN, or if you detect that the file is already opened, you can
just iofunc_ocb_attach() a new OCB to the existing attr structure.

However, you could save some memory by making the "register" files
psuedo files, which don't really exist, and don't get their own
iofunc_attr_t.  Just extend the iofunc_attr_t to also hold the
information about number of registers, and anything else required from
the "register" level.  Then in the IO_OPEN handler, strip off the
register portion of the pathname, and use that as a flag in the OCB to
indicate which register the operations are really targetted at.

David

> -----Original Message-----
> From: Mark Dowdy [mailto:community-noreply@qnx.com] 
> Sent: March 26, 2010 8:50 PM
> To: ostech-core_os
> Subject: iofunc_open_default Memory Ownership
> 
> The documentation for iofunc_open_default doesn't mention 
> memory 'ownership' for the structured passed in the attr 
> parameter. Can anyone help with the memory requirements for 
> the attr parameter? Are the values in the passed in structure 
> copied to a resource manager control structure or is the 
> memory pointed to by attr expected to remain valid for the 
> duration of the session (i.e. attr should not be automatic or 
> reused for multiple 'files/directories')?
> 
> I ask because I'm attempting to create a resource manager to 
> provide access to the registers on a number of devices 
> connected to our product. Each device has over 250 registers 
> and there can be from one to twenty devices on the bus. 
> That's a lot of attr structures if they have to be unique. 
> FWIW,  I'm looking at a directory hierarchy along the lines 
> of [mount point]/device/[device number]/[register number]. I 
> need to dynamically populate the 'device' directory because 
> the number of devices is discovered and varies depending on 
> system configuration. A directory listing of the 'device' 
> directory should show all devices currently running. All 
> devices have the same register set.
> 
> Thanks.
> 
> Mark
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post50613
> 
>
Mark Dowdy(deleted)
03/29/2010 4:00 PM
post50751
Re: RE: iofunc_open_default Memory Ownership   
Thanks for the clarification. I started heading down the path of allocating iofunc_attr_t structures when IO_OPEN 
messages are received but it's not as easy as I'd hoped. I created an 'enhanced' OCB that I allocate and free using my 
ocb_calloc and ocb_free functions. The 'enhanced' OCB contains a flag indicating if the attr structure needs to be freed
 when the OCB is freed. Unfortunately, my allocate/free functions aren't called in all cases. For example, if I 'ls -l 
[mountpoint]', my ocb_calloc is called for the mountpoint but not for the files under the mountpoint. Without a call to 
my ocb_free function, the attr structure leaks. Any idea why my ocb_calloc/ocb_free functions aren't always being called
? Thanks.

Mark
David Sarrazin
03/29/2010 4:28 PM
post50755
RE: RE: iofunc_open_default Memory Ownership   
 

> -----Original Message-----
> From: Mark Dowdy [mailto:community-noreply@qnx.com] 
> Sent: March 29, 2010 4:00 PM
> To: ostech-core_os
> Subject: Re: RE: iofunc_open_default Memory Ownership
> 
> Thanks for the clarification. I started heading down the path 
> of allocating iofunc_attr_t structures when IO_OPEN messages 
> are received but it's not as easy as I'd hoped. I created an 
> 'enhanced' OCB that I allocate and free using my ocb_calloc 
> and ocb_free functions. The 'enhanced' OCB contains a flag 
> indicating if the attr structure needs to be freed when the 
> OCB is freed.

iofunc_ocb_detach will return a set of flags.  If IOFUNC_OCB_LASTINUSE
is set, then the attr can be freed.

> Unfortunately, my allocate/free functions 
> aren't called in all cases. For example, if I 'ls -l 
> [mountpoint]', my ocb_calloc is called for the mountpoint but 
> not for the files under the mountpoint.

Are you getting a matched set of calls for the mountpoint at least?  The
IO_CLOSE_OCB handler should be invoked when ls is finished, and that
will invoke the ocb_free() handler. You'll get a connect-combine message
for the stat of each file in the directory.

> Without a call to my 
> ocb_free function, the attr structure leaks. Any idea why my 
> ocb_calloc/ocb_free functions aren't always being called? Thanks.
> 
> Mark
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post50751
> 
>
Mark Dowdy(deleted)
03/29/2010 9:25 PM
post50775
Re: RE: RE: iofunc_open_default Memory Ownership   
> iofunc_ocb_detach will return a set of flags.  If IOFUNC_OCB_LASTINUSE
> is set, then the attr can be freed.

Now you've lost me. My ocb_free() callout is never called so I'm missing how operations in iofunc_ocb_detach help me.

> > Unfortunately, my allocate/free functions aren't called in all cases. For example, if I 'ls -l 
> > [mountpoint]', my ocb_calloc is called for the mountpoint but not for the files under the mountpoint.
> 
> Are you getting a matched set of calls for the mountpoint at least?  The
> IO_CLOSE_OCB handler should be invoked when ls is finished, and that
> will invoke the ocb_free() handler. You'll get a connect-combine message
> for the stat of each file in the directory.

I am getting a matched set of calloc/free calls for the mounpoint, that part's OK.

My OCB calloc and free functions are not getting called with the connect-combine message. That's problematic. My open 
function is called, but iofunc_open_default is using some other mechanism to allocate and free the OCB so I never get 
the opportunity to free my allocated iofunc_attrib_t structure. I tried to find the source for iofunc_open_default to 
see if I could figure out why my calloc/free callouts are not being used but I couldn't find the source.

From what I could find in the "Writing Resource Managers" documentation, combine messages should look like separate open
 and stat messages to the resource manager implementer. Am I missing something? Should I be able to tell that the open 
call is the first part of a combine message? Even if I could tell, I'm not sure it helps because my ocb_free callout is 
not being called.

Mark
Mark Dowdy(deleted)
03/29/2010 9:54 PM
post50776
Re: RE: RE: iofunc_open_default Memory Ownership   
Doh. I'm only setting 'mount' in the iofunc_attr_t structure for the mountpoint. I presume I need to create 
IOFUNC_MOUNT_T and iofunc_funcs_t structures for each iofunc_attr_t I create. That begs another question, how diligent 
do I have to be with the iofunc_mount_t 'flags', 'dev' and 'blocksize' values? I zeroed these values for the mountpoint 
and it seems to be OK. Did I just get lucky? Thanks.

Mark

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems