[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: extended attributes and lsextattr/extattr_list_file
> 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.
> Emmanuel Dreyfus
Main Index |
Thread Index |