Date: Thu, 7 Jun 2007 21:59:04 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Eric Lemar <eric.lemar@isilon.com> Cc: arch@freebsd.org, Roman Divacky <rdivacky@freebsd.org> Subject: RE: *at family of syscalls in FreeBSD Message-ID: <Pine.GSO.4.64.0706072147440.28966@sea.ntplx.net> In-Reply-To: <896DB1FBFFD5A145833D9DA08CA12A85051A87@seaxch07.desktop.isilon.com> References: <20070604162430.GA76813@freebsd.org> <896DB1FBFFD5A145833D9DA08CA12A85051A7F@seaxch07.desktop.isilon.com> <20070606074429.GA42032@freebsd.org> <4666F0FB.8020101@FreeBSD.org> <20070607070455.GA71012@freebsd.org> <896DB1FBFFD5A145833D9DA08CA12A85051A84@seaxch07.desktop.isilon.com> <20070607210313.GA603@freebsd.org> <896DB1FBFFD5A145833D9DA08CA12A85051A87@seaxch07.desktop.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0706072147440.28966>