[PATCH][SAMBA3] allow VFS modules to extend files_struct

James Peach jpeach at samba.org
Mon Jun 5 23:04:03 GMT 2006

On Mon, 2006-06-05 at 06:05 -0700, Jeremy Allison wrote:
> On Mon, Jun 05, 2006 at 05:34:22PM +1000, James Peach wrote:
> > Hi all,
> > 
> > The attached patch adds an API to allow VFS modules to attach private
> > per-module data to a files_struct. This patch is against SAMBA_3_0, but
> > if it passes review, I'll commit it to trunk until 3.0.23 goes out.
> > 
> > Jeremy, I was able to get rid of specifying the payload completely, so I
> > hope this makes us both happy. If not, I can revert to supplying a void
> > * payload ...
> I still prefer a void * payload. There's no guarentee a compiler won't
> add padding to the end of the vfs_fsp_data struct... (yeah I know that'll
> be aligned). I think the code as written will work, but it's too "clever"
> for it's own good :-). That way lies tears in the end :-).

I'm quite hurt that you would call my code clever :)

I've converted 3 modules and this API turns out to be quite nice to

        SMB_OFF_T * last;
        if ((last = VFS_ADD_FSP_EXTENSION(handle, fsp, SMB_OFF_T)) {
                /* do stuff */

You don't have to worry about the case where one allocation succeeds but
the other fails, and the storage mechanism is completely hidden. I would
like to borrow talloc's use of typeof to improve the type-safety,

Actually, I just realised that I can keep this API, but convert to using
a void * and a separate allocation internally. That is,
vfs_add_extension_notype would allocate the block and attach it to a
data pointer in struct vfs_fsp_data. I'll be happy to make this change
if you want, since it contains the multiple allocations in a single

> > +   Copyright (C) 2006 Silicon Graphics, Inc. All rights reserved.
> > +	James Peach, <jpeach at sgi.com>
> > +
> Woop ! Woop ! Corporate (C) ahead... that needs changing to just
> yours :-).

Yep, it's a side-effect of the process. I can explain the gory details
offline if you really want to know (it's not that exciting though:)).

James Peach | jpeach at samba.org

More information about the samba-technical mailing list