Re: extended attributes and lsextattr/extattr_list_file

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost> 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
> manu%netbsd.org@localhost