OK, well I can see some patterns emerging already:
long sys_getxattr(char *path, char *name, void *value, size_t size, int flags)
long sys_setxattr(char *path, char *name, void *value, size_t size, int flags)
long sys_listxattr(char *path, char *name, void *value, size_t size, int flags)
long sys_fgetxattr(int fd, char *name, void *value, size_t size, int flags)
long sys_fsetxattr(int fd, char *name, void *value, size_t size, int flags)
long sys_flistxattr(int fd, char *name, void *value, size_t size, int flags)
Why don't I see 'delxattr'?
Why is there a need for separate 'path' and 'fd' variants?
<nit>Is there any other kind of 'attr' in the syscall interface? Why not spell
it 'attr' instead of 'xaddr'? How about geta, seta, dela, lista?</nit>
The idea of attribute class (namespace) isn't explicitly accomodated. I presume
the intention is to encode the class as part of the attribute name and have the
filesystem or vfs parse it out. Is that such a good idea? Why not pass the
class explicitly and worry about the namespace parsing in user space?
As far as listing attributes goes, is there ever a reason to list system and
user attributes at the same time? IOW, the listxattr call needs a class
parameter too. It doesn't name a 'name', at least if you accept my argument
that the class should not be parsed inside the kernel. There's no particular
reason to force all the parameter lists to be the same is there?
-- Daniel - 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/