From owner-freebsd-arch@FreeBSD.ORG Fri Jun 8 16:13:26 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 DD68416A400 for ; Fri, 8 Jun 2007 16:13:26 +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 6335513C465 for ; Fri, 8 Jun 2007 16:13:25 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D56198BDCB9; Fri, 8 Jun 2007 18:13:24 +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 ZHgnY1kKI12L; Fri, 8 Jun 2007 18:13:23 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 93CC68BD7CA; Fri, 8 Jun 2007 18:13:23 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l58GDM8a027868; Fri, 8 Jun 2007 18:13:22 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 8 Jun 2007 18:13:22 +0200 From: Roman Divacky To: Eric Lemar Message-ID: <20070608161322.GA27624@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> <20070607210313.GA603@freebsd.org> <896DB1FBFFD5A145833D9DA08CA12A85051A87@seaxch07.desktop.isilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <896DB1FBFFD5A145833D9DA08CA12A85051A87@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: Fri, 08 Jun 2007 16:13:26 -0000 On Thu, Jun 07, 2007 at 05:56:39PM -0700, Eric Lemar wrote: > Obviously I prefer the wrapping, but I'm just a tad biased :) well.. unless I hear some strong voice to change what I have I am not changing it. it can always be changed in future. > 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. I don't understand now. you are saying that if the path is relative and the fd is invalid we should do what? we have to fail somehow... > 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. linux implements flags too. I think we want them. the current practice is that we have for example kern_chown and and kern_lchown. I implemented it like this for a few syscalls (from the top of my head - [l]stat and l[chown]) > 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. well, I think we are confusing two things here. in-kernel API and syscalls API. I think it makes perfect sense to have kern_rmdirat() and in ulinkat() do something like if (flags->AT_REMOVEDIRAT) kern_rmdirat(...); else kern_unlinkat(....); note that I didnt implement ANY syscall only the kern_fooat() functions.