[haiku-development] Re: fs API: get_vnode limitation
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 11 Jul 2010 11:05:31 +0200
On 2010-07-11 at 06:29:38 [+0200], Lucian Adrian Grijincu
<lucian.grijincu@xxxxxxxxx> wrote:
[...]
> 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.
Adding a new function wouldn't worry me much, but the change of semantics of
existing functionality does. Currently after the get_vnode() FS hook returns
the fs_vnode structure is stable and usable. If I understand you correctly
you want to make the private_vnode field mutable and your get_vnode() hook
would not initialize the fs_vnode to be in a usable state. You might not be
aware of the fact that the get_vnode() hook is not only triggered by
lookup_vnode().
> 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
Assuming that you'll use artificially generated ino_t values, I guess you
won't get around implementing a ino_t -> something mapping anyway.
> 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.
That has the same problem as A); it assumes that the get_vnode() hook is
triggered only by lookup_vnode().
> 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.
I don't think it would work. I'm wondering anyway, how you think storing
absolute paths is going to work. Renaming directories will inevitably break
the paths of all of its descendants, and in case of hardlinks you'd lose
track of a node when the entry you're using is deleted.
In similar situations I've always resorted to mirroring all known file system
objects by in-memory objects. I used a class Node to represent FS nodes and a
class Directory derived from it, containing Entry objects which have a file
name and refer to a Node. Node would know all Entry objects referring to it.
With Entry knowing its containing directory, paths to nodes can be created on
the fly. It's a bit annoying to maintain all the objects, but so far I
haven't had a better idea.
CU, Ingo
Other related posts:
