Hi Calum,
Just curious. Why isn't this data being placed with the v_data field?
I guess I don't know
why there needs to be 2 pieces of data associated with a file object...
thanks,
max
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.
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org
>
>
