*at family of syscalls in FreeBSD

Daniel Eischen deischen at freebsd.org
Fri Jun 8 01:59:06 UTC 2007


On Thu, 7 Jun 2007, Eric Lemar wrote:

> Obviously I prefer the wrapping, but I'm just a tad biased :)
>
> Decided to do a little digging in POSIX-world since (unless others disagree)
> getting parameters/behavior right seemed a little more useful than preparing
> a patch of another very similar implementation.  Unfortunately I didn't come away
> that much more enlightened.
>
> openat() - Looks like POSIX mentions the use of O_XATTR but doesn't
> standardize it.  On the other hand, it does say that it should fail with
> EBADF if the path isn't an absolute path AND the fd is invalid, so it
> seems like it might be safer to check for an absolute path and not try to
> access the fd/fail if the path is absolute.
>
> There are a number of functions such as fchownat(), chmodat(), fstatat(),
> linkat() that are sometimes described as taking a flag field  mainly for
> SYMLINK_FOLLOW/NOFOLLOW or faccessat() that takes an AT_EACCESS
> to specify effective user/group id.  Not clear to me that the question of which
> do/don't take flags is actually standard across existing implementations or
> necessarily stable in the standard.  It's not even completely clear to me that
> the naming of some of these (an f prefix or not) is completely standardized.
> I haven't really been following this, so if anyone else has I'd be interested to know.
> None of these behaviors are particularly hard to change but its not immediately
> clear to me what the correct call is on all these at least as far as the end user
> API is concerned.

If we add these functions, we should add them as specified in the
latest draft.  I doubt the interfaces will change, but perhaps the
behavior will change slightly.  We _don't_ want to add interfaces
that will most likely be incompatible with POSIX.  By interfaces,
I mean the API.

The latest draft I'm looking at is draft 2, issue 7, 31 Oct 2006.
You can download a PDF version of the system interfaces draft by
registering and logging in here:

   http://www.opengroup.org/austin/

It looks like draft 3 will be released June 15, 2007 (in 10 days).

> unlinkat(), rmdirat() -
>  POSIX doesn't seem to have rmdirat (yes, Isilon has
>  this too).  Looks like POSIX just overloads unlinkat() with a new flags parameter
>  and an AT_REMOVEDIRAT flag for directories.  Can't say that's my favorite API,
>  but if that's where POSIX is going I don't know it's worth bucking the trend.

Yes, please let's stick the the POSIX API for our own (non-Linux)
interfaces.

-- 
DE


More information about the freebsd-arch mailing list