Regarding Filesystem Handler Table Functions

[Joel Sherrill]

Is there any chance he is seeing a manifestation of PR1516?

Bharath.. clean up what you have now and submit it.  You
have to be close.  This way the community can trace this
one case and see what is happening.

--joel

On 05/14/2010 06:26 AM, Bharath Suri wrote:
> On Thu, May 13, 2010 at 11:26 PM, Chris Johns<chrisj at rtems.org>  wrote:
>    
>> On 13/05/10 11:53 PM, Bharath Suri wrote:
>>      
>>> I am right now facing some difficulty wrt Filesystem Handler functions.
>>>
>>> Following is the setup.
>>>
>>> /imfs exists, /tmp/test exists
>>>
>>> A filesystem is mounted at /imfs, with the
>>> rtems_filesystem_operations_table argument mostly same as IMFS_ops,
>>> except that the evalformake_h = NULL and rename_h = NULL.
>>>
>>> /imfs/test is created.
>>>
>>> When node info ( rtems_filesystem_location_info_t) of /tmp/test is
>>> seen, mt_entry is that of the root file system and ops is the IMFS_ops
>>> (OK)
>>> When node info ( rtems_filesystem_location_info_t) of /imfs/test is
>>> seen, mt_entry is that of the new file system mounted, but ops is
>>> IMFS_ops, instead of the modified one.
>>>
>>> I am assuming that the ops should be the modified one, which was
>>> provided during the mount.
>>>
>>>        
>> It should be if the mount is successful. Is it ? Are you checking for errors
>> ?
>>
>>      
> Errors are being checked for and the mount was successful in this case.
>
>    
>>> Mount operation was performed in the below manner:
>>>
>>> rtems_filesystem_operations_table  IMFS_ops_no_evalformake = IMFS_ops;
>>> IMFS_ops_no_evalformake.evalformake_h = NULL;
>>> mount(&mt_entry,&IMFS_ops_no_evalformake,
>>> RTEMS_FILESYSTEM_READ_WRITE, NULL, "/imfs");
>>>
>>> Please let me know if the assumption is wrong or about any mistakes in
>>> the procedure I am following.
>>>        
>> I think you are being detected in 'Is_node_fs_root' as being a root fs and
>> attempting to mount it twice. Check the mount code in libcsupport.
>>      
> The mount was successful, and Is_node_fs_root returned a FALSE.
>
> Following are some observations with respect to the ops of the
> temp_mt_entry (which later becomes the mt_entry)
>
> The location info of the mount point is obtained and in this case if
> would be of the /imfs. The ops for this would be IMFS_ops. This is
> assigned to temp_mt_entry->ops.
>
> Later, a call to
>
> fs_ops->fsmount_me_h( temp_mt_entry ), fs_ops being the ops as sent to
> mount function
> (in this case, fs_ops->evalformake_h = NULL)
>
> fs_ops->fsmount_me_h = IMFS_initialize which will further call
> IMFS_initialize_support (with ops = IMFS_ops)
> So, now the temp_mt_entry->mt_fs_root.ops is set to IMFS_ops (NOK)
>
> In the end, the temp_mt_entry is copied to mt_entry, and this has the
> ops as IMFS_ops
>
> IMO, the implementation is in a way that the ops assigned to mt_entry
> is decided by the (requested_ops)->fsmount_me_h
> i.e, if (requested_ops)->fsmount_me_h = IMFS_Initialize, ops assigned
> to mt_entry is IMFS_ops.
> Same is the case with dosfs
> if (requested_ops)->fsmount_me_h = msdos_Initialize, ops assigned to
> mt_entry is msdos_ops.
>
> Although, I am not sure if this is the way it is supposed to be.
>
> /Bharath
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>