lkml.org 
[lkml]   [2001]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH] VFS interface for extended attributes
    Hello Al,

    On Mon, 12 Nov 2001, Alexander Viro wrote:
    >
    > [Cc'd to Linus since API changes on that level definitely require his
    > approval]
    >
    > On Mon, 12 Nov 2001, Nathan Scott wrote:
    >
    > > +static long
    > > +extattr_inode(struct inode *i, int cmd, char *name, void *value, size_t size)
    >
    > Broken.
    > a) passing inode is an obvious mistake. dentry or vfsmount/dentry.

    There are curently two paths by which the extended attribute inode
    operations can be invoked: (a) from a system call, (b) from the
    permission() inode operation, when checking the access ACL of a file. We
    could trivially use a dentry in (a), but unfortunately we don't have a
    choice in (b), as permission() itself is not passed a dentry.
    It's planned that all inode operations use dentries somewhen in 2.5.
    This would be the proper time to move to dentries in the EA code as well.

    > b) for crying out loud, what's that with SGI and ioctl-like abortions?
    >
    > Rule of the tumb: if your function got a "cmd" argument - it's broken.
    > ioctl(2). fcntl(2). prctl(2). quotactl(2). sysfs(2). Missed'em'V IPC
    > syscalls. Enough, already.

    There is one difference between the interfaces you are complaining about
    above and the proposed EA interface for EA's: In those interfaces you have
    wildcard parameters that are used for who-knows-what, depending on a
    command-like parameter, including use as a value, use as a pointer to a
    value/struct, etc.

    In the EA interface we have clear semantics of what the parameters' types
    and sizes are, so many of the problems there are with ioctl() and friends
    don't occur here. You could as well call the `cmd' parameter a `flags'
    parameter here, then you're pretty close to the open() syscall.

    It would be possible to split the EA syscalls in a set for retrieving and
    aonther set for setting EA's, and perhaps still a third set for listing
    the EA's that are present. Those syscalls would only differ in their
    names. I would consider it much more useful to provide functions in a
    library for dealing with EA's in user space, which in turn would use the
    syscalls, though.


    Cheers,
    Andreas.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:13    [W:0.026 / U:121.748 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site