RE: *at family of syscalls in FreeBSD
- From: Daniel Eischen <deischen@xxxxxxxxxxx>
- Date: Thu, 7 Jun 2007 21:59:04 -0400 (EDT)
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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: *at family of syscalls in FreeBSD
- From: Roman Divacky
- Re: *at family of syscalls in FreeBSD
- References:
- *at family of syscalls in FreeBSD
- From: Roman Divacky
- RE: *at family of syscalls in FreeBSD
- From: Eric Lemar
- Re: *at family of syscalls in FreeBSD
- From: Roman Divacky
- Re: *at family of syscalls in FreeBSD
- From: Doug Barton
- Re: *at family of syscalls in FreeBSD
- From: Roman Divacky
- RE: *at family of syscalls in FreeBSD
- From: Eric Lemar
- Re: *at family of syscalls in FreeBSD
- From: Roman Divacky
- RE: *at family of syscalls in FreeBSD
- From: Eric Lemar
- *at family of syscalls in FreeBSD
- Prev by Date: RE: *at family of syscalls in FreeBSD
- Next by Date: Re: Updated rusage patch
- Previous by thread: RE: *at family of syscalls in FreeBSD
- Next by thread: Re: *at family of syscalls in FreeBSD
- Index(es):
Relevant Pages
|