hi, > 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>
python xattr library contains some #ifdef __FreeBSD__ code. i don't know if it works or not. > 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>. my guess is that the code was put in kernel so that it can be used by compat_linux. i can be wrong. > > 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. having two set of syscalls for the same thing is at least ugly. honestly speaking, i tend to prefer linux api. :-) at least it has better chances to be supported by 3rd party applications. i'm curious why thorepej chose freebsd's in the first place. YAMAMOTO Takashi > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org
