From owner-freebsd-arch@FreeBSD.ORG Thu Jun 7 21:03:17 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FB4116A400 for ; Thu, 7 Jun 2007 21:03:17 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 19D0313C455 for ; Thu, 7 Jun 2007 21:03:16 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 42D128BDCA9; Thu, 7 Jun 2007 23:03:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZP2x6XoKStS; Thu, 7 Jun 2007 23:03:14 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 385878BDCA0; Thu, 7 Jun 2007 23:03:14 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l57L3DH2000765; Thu, 7 Jun 2007 23:03:13 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 7 Jun 2007 23:03:13 +0200 From: Roman Divacky To: Eric Lemar Message-ID: <20070607210313.GA603@freebsd.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <896DB1FBFFD5A145833D9DA08CA12A85051A84@seaxch07.desktop.isilon.com> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: *at family of syscalls in FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2007 21:03:17 -0000 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