[lkml]   [2005]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: reiser4 plugins
    On Sun, Jun 26, 2005 at 09:07:00PM +0400, Artem B. Bityuckiy wrote:
    > Just out of curiosity, could you please specify few exact examples with
    > specific file/function names which duplicate the existing
    > infrastructure. What do they duplicate and why? How should these
    > functions be implemented on VFS? Ho should the the other FSes
    > implement/ignore them? Why are you shure they will fit VFS well? etc.

    Right now every file/inode/etc method in reiser4 is just a trivial
    wrapper around a plugin call. It should instead just set the method
    table directly in the plugin initialization. Example:

    static int
    reiser4_permission(struct inode *inode /* object */ ,
    int mask, /* mode bits to check permissions
    * for */
    struct nameidata *nameidata)
    /* reiser4_context creation/destruction removed from here,
    because permission checks currently don't require this.

    Permission plugin have to create context itself if necessary. */
    assert("nikita-1687", inode != NULL);

    return perm_chk(inode, mask, inode, mask);

    besides a useless assert we just call into perm_chk, which is a macro
    obsfucation to call generic_permission which would be called if
    ->permission was zero. A hypothetical reiser4 "plugin" that would need
    redefine ->permission would just override it in a set inode_operations.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-26 19:32    [W:0.020 / U:1.256 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site