Added support for _PC_HAS_NAMEDATTR, which is
mainly a new function called zfs_has_namedattr().

In D50140#1143762, @kib wrote:

Does Solaris use the pathconf() to report xattr existence for the specific node?

It seems to do so. Solaris calls it _PC_XATTR_EXISTS.
It seems to work for local files on Solaris, but returns random junk for an NFSv4 mount.
(Since things look correct on the wire, I think this is just a Solaris bug?)

In D50141#1143706, @ziaee wrote:

Are these Function Arguments? Can I alphabetize these?

Clarified when named attributes and named attribute
directories are created.

Replaced the copyright notice with the new recommended
short one, as suggested by ziaee@.

Removed the "." after my name in the copyright.

Added chdir(2) to the SEE ALSO section of the runat.1.

Marked inline comments as done.

Updated the copyrights, as suggested by ziaa@.

Looks fine to me, rick

Note that O_CLOEXEC is set in "fmode" near the top of main()
for the second open.

Marked inline comments as done.

Missed a couple of cases for .Ar file. Fixed now.

Updated man page with changes suggested by ziaa@.

Updated the man page to reflect the use of /bin/sh.

This version just does an execl() as suggested by kib@.

Oops, missed the last suggested change from kib@
the last time. It is here now.

Updated runat.c to apply kib@'s suggestions.
For some reason (don't know where I got it) I
thought that fchdir() directory change would
affect more than the process, which was why I
did the fork(). (I think it came from ancient
recollections of how 6th Edition worked in the
1970s. I'm gettin old;-)

Re-written to conform to the more Solaris-like
semantics of O_NAMEDATTR that is now implemented
in main.

Update runat.c to use the up to date more Solaris-like
O_NAMEDATTR flag.

I misinterpreted the Solaris documentation for O_XATTR.
It is used for an openat() where the path is for a file in
the file system's namespace, to open a named attribute
for the file, not a named attribute directory.

Cleaned up the "if" as suggested by kib@.

Added a helper function, as suggested by kib@.

I now realize that the check for non-named attribute is in
ZFS's VOP_LOOKUP(), so this patch is not really needed,
but I think it is a good "safety belt" to put in.

Oops, this is a bit embarrassing. I took another look
at the Solaris doc (which is confusing, too) and realized
I hadn't implemented what they did for their O_XATTR.

Attempt #2 at explaining the use of O_NAMEDATTR
when opening a named attribute.

Added a sentence trying to explain the use
of O_NAMEDATTR for the openat() of a named
attribute. For this case, it performs a sanity check
to ensure the successful open is that of a named
attribute.

Rework the description for O_NAMEDATTR to try
and explain how it is used to open named attributes,
as suggested by kib@.

Tried to clarify when O_NAMEDATTR is used.

I am now convinced that the check in zfs_freebsd_open()
for O_NAMEDATTR being set is not necessary at all.

Checking for VIRF_NAMEDATTR in zfs_freebsd_open()
was not needed and broke the runat(1) utility I am writing.

Add a missing '.' at the end of a statement.

Oops. I didn't see emaste@'s comment until after
doing the commit.

In D49718#1134202, @ziaee wrote:

I do really love putting the commit that the work depends on in "Fixes: " instead of the introductory sentence of the commit message. It makes me feel like the the sentence is clean and just explaining for me, and very predictable to track the tree of events related to the commit.

Removed the sentence w.r.t. the specific error, since
it is covered in the ERROR section. Also, moved the
ENOATTR entries so that they are in alphabetical order,
as suggested by ziaee@.

Moved the MNT_NAMEDATTR entry up, to maintain
alphabetical ordering, as suggested by ziaee@.

Just to clarify what the previous comment was talking about.
Without this patch:
fhopen(&fh, O_RDONLY | O_NAMEDATTR | O_PATH) works
but
fhopen(&fh, O_EXEC | O_NAMEDATTR | O_PATH) fails with EINVAL
(You can basically ignore the O_NAMEDATTR. I just did the tests with
some test code I had lying about for O_NAMEDATTR.)

Without this patch:
kern_fhopen() requires FREAD or FWRITE.
It checks for these and fails with EINVAL if neither are set.

This looks fine to me.

Cleanup up zfs_freebsd_lookup(), including adding some
comments to try and explain the named attribute case.

Fixed a bug when open'ng "." in a named attribute directory.

All looks good to me. (I am glad you did this. I would have missed
half of the places that needed to be changed.)

In D49583#1131634, @kib wrote:

Do you want me to prepare the generic patch for stat(2)? Then you would add the setting of the bits as the followup.

In D49583#1131392, @kib wrote:

In D49583#1131391, @rmacklem wrote:

In D49583#1131379, @kib wrote:

I think fhopen() should require O_NAMEDATTR to successfully open the attribute inode' handle.
BTW, given a file descriptor, is there a way to understand if this is a regular fd or namedattr fd? In particular, does fstatat(2) return some distinguishing info?

Not a fd. The code needs to get the associated vnode and look for VIRF_NAMEDDIR or VIRF_NAMEDATTR being set.
(I'll tweak fhopen(2) to do that.)

No, I don't have fstatat(2) returning anything in "struct stat" that indicates "namedattr".
(st_flags seem to be all bits that can be set/cleared by chflags and I cannot see any
other field of "struct stat" that could be used to indicate a named attribute dir/attribute.)
Any suggestions?

The regular way would be to define new S_IFMT value for named attr files, but this probably would break too much.
We have st_padding0 field that can be used for additional flags, like st_bsd_flags or similar, and we can allocate the first bit there to mean named attr file. The rename of st_padding0 and the flag definition should be a separate commit.

Change fhopen(2) so that O_NAMEDATTR is required to
open a file handle that represents a named attribute or
named attribute directory.

In D49583#1131379, @kib wrote:

I think fhopen() should require O_NAMEDATTR to successfully open the attribute inode' handle.
BTW, given a file descriptor, is there a way to understand if this is a regular fd or namedattr fd? In particular, does fstatat(2) return some distinguishing info?

Changed MNTK_NAMEDATTR to MNT_NAMEDATTR as
suggested by kib@.