*at family of syscalls in FreeBSD
Roman Divacky
rdivacky at freebsd.org
Thu Jun 7 21:03:17 UTC 2007
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
More information about the freebsd-arch
mailing list