*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