[haiku-development] fs API: get_vnode limitation
- From: Lucian Adrian Grijincu <lucian.grijincu@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 11 Jul 2010 07:29:38 +0300
Hi,
I'd like to know why get_vnode
(http://api.haiku-os.org/fs__interface_8h.html#2cfcf01bba17eee0ad3f84115051b281)
doesn't give the caller a reference to the fs_vnode of that vnode.
fs_vnode is pretty simple:
struct fs_vnode {
void* private_node;
fs_vnode_ops* ops;
};
The get_vnode users can retrieve the value of private_node (just the
value, not a reference to it) through a call to get_vnode, and the
fs_vnode_ops should be the same for all fs_vnodes of a file system
instance.
== Problem ==
To identify nodes in my file system driver, I keep in the private_node
the full path to that node relative to the file system's root. I have
to know this full path to any node (file) to be able to interact with
LKL.
Interaction with LKL is done through the system call API, and that API
only accepts full paths.
The problem is: I can't write the path into the fs_node->private_node
because when I know the path (in the lookup() hook) I can't get a
reference to the fs_node, and when I have a reference to the fs_node,
I don't have the path.
To be more explicit:
In the lookup hook I have the full path:
static status_t lklfs_lookup(fs_volume* volume, fs_vnode* dir,
const char* name, ino_t* _id)
The full path is concat(dir->private_vnode, name).
I now want to write it into the fs_vnode corresponding to this file's ino_t.
Calling get_vnode won't help as it will not provide a reference to the fs_vnode.
The get_vnode() hook will be useless too:
static status_t lklfs_get_vnode(fs_volume * volume, ino_t id,
fs_vnode * vnode, int * _type, uint32 * _flags, bool reenter)
Here I have the vnode, I can write into vnode->private_vnode, but I no
longer have access to the full path to that file.
I see three solutions:
A) add a get_vnode_xxx into Haiku, that provides access to the
fs_vnode, or at least a **reference** to the vnode's private_vnode.
This is trivial to implement, but means exporting a new function.
B) add a hashmap inside my driver. The lookup() hook would insert
(ino_t, full_path) entries in the hashmap, and the get_vnode() hook
will access this hashmap to retrieve the corresponding full_path. All
the locking involved would
C) simplest, least scalable solution: have a mutex protected global
variable to hold the path. Entering lookup, I take the mutex, set the
path in the global var, call, get_vnode, which will call my get_vnode
hook. In the get_vnode hook I setup the fs_vnode->private_node field
and return. In the lookup hook I unlock the mutex and go on.
Do you think that the A) solution can be implemented to extend a what
seems to me a limited file system interface? I'm not sure about what
it means from a global locking standpoint, the time of life of the
fs_vnode structure.
Do you have any comments about the other two, or other suggestions?
--
.
..: Lucian
Other related posts:
