*at family of syscalls in FreeBSD

[Roman Divacky]

On Thu, Jun 07, 2007 at 05:56:39PM -0700, Eric Lemar wrote:
> Obviously I prefer the wrapping, but I'm just a tad biased :)
  
well.. unless I hear some strong voice to change what I have I am not
changing it. it can always be changed in future.

> 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.

I don't understand now. you are saying that if the path is relative and the fd is invalid
we should do what? we have to fail somehow... 
 
> 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.


linux implements flags too. I think we want them. the current practice is that we have for
example kern_chown and and kern_lchown. I implemented it like this for a few syscalls (from the
top of my head - [l]stat and l[chown])
 
> 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.

well, I think we are confusing two things here. in-kernel API and syscalls API. I think it makes
perfect sense to have kern_rmdirat() and in ulinkat() do something like

if (flags->AT_REMOVEDIRAT)
   kern_rmdirat(...);
else
   kern_unlinkat(....);

note that I didnt implement ANY syscall only the kern_fooat() functions.