tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: extended attributes and lsextattr/extattr_list_file


> Hello
> I implemented extattr_list_file for UFS1. The thing works fine, but I
> notice the data expected by lsextattr(8) is not in the same shape as
> described in NetBSD documentation and in FUSE and Linux.
> In FUSE and Linux, listing extended attributes returns a buffer with NUL
> separated extended attribute names. NetBSD's extattr_list_file(2) says
> we do that.
> In NetBSD's lsextattr(8) the expected data is a buffer with NUL
> separated extended attribute names, each with a one-byte string length
> prepended. I made a kernel implementation that matches what lsextattr(8)
> expects. My kernel implementation therefore works with existing
> lsextattr(8) but it does not match extattr_list_file(2) man page.
> Beside the need to update the documentation, here are two problems
> 1) having to convert FUSE LISTXATTR output to extattr_list_file(2)
> format is a pain
> 2) we also provide a lsxattr(2) Linux-like system call, and this is just
> a wrapper to extattr_list_file(2), without conversion. Therefore our
> lsxattr(2) is broken. 
> I therefore propose to modify lsextattr(8) so that it expects data that
> match what extattr_list_file(2) is supposed to send in the
> documentation, and rework my UFS1 extattr_list_file implementation to
> behave just like advertised in the documentation.
> That breaks backward compatibility with non UFS1 filesystems
> implementing extattr_list_file, but as far as I know that does not
> exists. That could also make more dificult the task of importing future
> extended attribute code from FreeBSD.

i strongly object against being api incompatible with freebsd for this.

IMO linux-compatible api should have been in compat_linux.
(and libc if desirable)


> Opinions?
> -- 
> Emmanuel Dreyfus

Home | Main Index | Thread Index | Old Index