On Wed, Aug 08, 2007 at 10:29:02PM +0100, Calum Mackay wrote:
>     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.

ZFS recently started to use TSD, so I needed to implement something
similar for the FreeBSD kernel, but because there are more places that
need object specific data (in FreeBSD: threads, jails, network
interfaces, maybe vnodes in the future), I just generalized the idea to
avoid code duplication and called it Object Specific Data. In case you
would like to see the actual code, here it is:

http://perforce.freebsd.org/fileDownLoad.cgi?FSPC=//depot/user/pjd/zfs/sys/sys/osd.h&REV=1
http://perforce.freebsd.org/fileDownLoad.cgi?FSPC=//depot/user/pjd/zfs/sys/kern/kern%5fosd.c&REV=1

Maybe this is a better way to go?

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: 
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070810/4a391c7a/attachment.bin>

Reply via email to