Hi Jim,
Would it be possible to extend vsd_create to take a key as well as
create and return a key? This way a FS can have predefined key values
for specific data elements. This might simplify the usage in some cases.
Thanks,
Rob
Calum Mackay wrote:
> I'm sponsoring the following fast-track for Jim Wahlig.
>
> The case seeks Minor binding. I have set the timer to a week today,
> Weds 15th August.
>
> cheers,
> calum.
>
>
> Vnode Specific Data
>
> Problem Description
>
> Every time a project needs to keep some data in core that is
> associated
> with a file object, it has one of two choices. 1) create a database
> or hash table to store and lookup the data using the vnode as a
> key, or
> 2) add yet another field to the vnode data structure.
> Unfortunately,
> it seems like the vnode has become a dumping ground for all kinds of
> project specific data.
>
> Proposed Solution
>
> The solution is to provide a set of interfaces which will allow the
> caller to store and retrieve data on a per vnode basis. If this
> sounds
> familiar it is because the solution is just like Thread Specific
> Data.
>
> Only one new field is added to the vnode, void *v_vsd.
> The vsd structure looks like this:
> struct vsd_node {
> struct vsd_node *vs_next; /* vnodes with VSD */
> struct vsd_node *vs_prev; /* vnodes with VSD */
> uint_t vs_nkeys; /* entries in value array */
> void **vs_value; /* array of value/key */
> };
>
> void vsd_create(uint_t *key, void (*destructor)(void *))
> This function will create a key for all subsequent calls and
> stores the destructor function associated with the data to be
> stored.
> The destructor function is optional and can be NULL.
>
> int vsd_set(vnode_t *vp, uint_t key, void *value)
> This function will store the data on the specified vnode using
> the provided key. It will return EINVAL for a key == 0.
>
> void *vsd_get(vnode_t *vp, uint_tkey)
> This function will return the data on the specified vnode for the
> given key.
>
> void vsd_destroy(uint_t *key)
> This function will "destroy" a key. It will walk the list of
> vsd's
> and call the destructor function on the data for each vsd that has
> the given key. The value field is set to NULL as is the
> destructor for
> that key. The key is also set to zero. Used by unloadable
> modules.
>
> void vsd_free(vnode_t *vp)
> This function is called to free all VSD for the given vnode. The
> destructor functions are called for each VSD and then the vsd
> structure is freed and v_vsd in the vnode is set to NULL. This
> function is called from vn_recycle() and vn_free().
>
> The first consumer of VSD will be the NFSv4 server. The server
> currently
> keeps a file state structure, one per vnode, in a database. We will
> use VSD to store the file structure with the vnode. These changes
> have been prototyped and tested.
>
> There are other fields in the vnode which could be converted to
> using
> VSD, but that is out of scope for this fast-track. However, future
> projects should use VSD instead of adding another field to the
> vnode,
> unless there is a strong justification otherwise.
>
> Exported Interfaces
>
> | |
> Interface Name | Classification | Comments
> =================================================================
> | |
> vsd_create, | Consolidation | New interfaces for creating,
> vsd_destroy, | Private | destroying,
> vsd_get, | | getting a stored value from,
> vsd_set, | | setting a value into,
> vsd_free | | and freeing vnode specific data.
