Date: Thu, 7 Jun 2007 17:56:39 -0700 From: "Eric Lemar" <eric.lemar@isilon.com> To: "Roman Divacky" <rdivacky@freebsd.org> Cc: arch@freebsd.org Subject: RE: *at family of syscalls in FreeBSD Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Obviously I prefer the wrapping, but I'm just a tad biased :) =20 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.=20 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@freebsd.org] Sent: Thu 6/7/2007 2:03 PM To: Eric Lemar Cc: arch@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?896DB1FBFFD5A145833D9DA08CA12A85051A87>