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.
