*at family of syscalls in FreeBSD

[Eric Lemar]

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.

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.

Eric Lemar

________________________________

From: Roman Divacky [mailto:rdivacky at freebsd.org]
Sent: Thu 6/7/2007 2:03 PM
To: Eric Lemar
Cc: arch at freebsd.org
Subject: Re: *at family of syscalls in FreeBSD



On Thu, Jun 07, 2007 at 12:31:56PM -0700, Eric Lemar wrote:
> I certainly don't want to hold anything from getting into the release.  I
> haven't had a chance to compare all the details of your patch and ours,
> but I've spent a bit of time looking through yours, and I'd say
> (not surprisingly) that what we've done is much more similar than not and
> this is certainly a nice API to have even aside from the linux compatibility
> reasons.
>
> At least conceptually, most of the differences are relatively minor
> stylistic differences.  We've done the same NDINIT/namei() changes.

nice....

> Rather than have a set of kern_common_* functions, kern_open(), for
> instance, just calls kern_openat() using AT_FDCWD.  kern_openat() has all
> the actuall implementaiton.  This lets us avoid adding a seperate
> kern_common_open() and the associated clutter with no real downside that I
> can see.

well. its marginally faster :) and I had this OKed by rwatson and pjd. I don't
have any strong opinion on this and the fact is that changing it from the model
I use to the you suggest is a few minutes job.... I agree that consistency is a
strong argument (in favour of your model).

> Basic pattern is:
>   *kern_open() - calls kern_openat() with AT_FDCWD
>   *kern_openat() - calls a funtion at_getwd() similar to your kern_get_at
>   *at_getwd() - In addition to your parameters, we also pass in the flags
>    and path.  The flags let us do an isilon specific VOP to get a vp for
>    the subfile container if the user passed in O_XATTR (solaris uses this
>    to access subfiles and I know linux has at least talked about if not
>    implemented it).  We include the path largely to avoid doing work if
>    the path is absolute since the fd is supposed to be ignored in that
>    case.  Depending on how tightly you want to tat, you could
>    argue whether it is valid to return an error due to an invalid
>    fd if you pass in an absolute path (I haven't looked at draft posix
>    or actual implementations to see what they do, but we just
>    plain don't touch the fd at all in that case).

now we need some strong opinion what to do. can anyone step up and tell "do this and
that"? I am willing to adjust my patch with either the wrapping idea and/or the flags thing.

I just need someone to tell me what is the preferred way.

thnx

roman