YAMAMOTO Takashi <y...@mwd.biglobe.ne.jp> wrote: > i strongly object against being api incompatible with freebsd for this.
Do we have any working program written out of there that are written to use the extattr_list_(file|link|fd) system calls we got from FreeBSD (using <sys/extattr.h>? I expect most if not all third party programs to use the Linux-like [fl]listxattr from <sys/xatttr.h> And IMO, extattr_list_(file|link|fd) has a design drawback compared to [fl]listxattr. Its way of prepending a one byte length for attribute name limits forever the maximum length of attribute names to 255. Or perhaps this is just a bug, since the documentation does not tell about this prepended one byte length. The funny thing is that glusterfs has a code section for FreeBSD that uses extattr_list_link(), but it assumes the behavior from the documentation and is therefore broken with the original extattr_list_link() implementation. But if you have programs that depends on this oddity, we could modify extattr_list_(file|link|fd) again to add it there. Do you have any real world example that needs it? > IMO linux-compatible api should have been in compat_linux. > (and libc if desirable) compat_linux is for ABI compatibility, not API compatibility. The linux-like extended attribute API really needs to be implemented in kernel or libc if you want to be able to build a program that uses [fl](get|set|list|rm)xattr from <sys/xatttr.h>. I considered doing it in libc, but [fl]setxattr() has XATTR_REPLACE and XATTR_CREATE that requires an atomic test and set. It cannot be done properly in libc and really needs to be done in kernel. Moreover, the [fl](get|set|list|rm)xattr system calls have been available for a while in the NetBSD kernel, so this was a minimal change. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
