From mboxrd@z Thu Jan 1 00:00:00 1970 From: viro@parcelfarce.linux.theplanet.co.uk Subject: Re: silent semantic changes with reiser4 Date: Sun, 29 Aug 2004 17:20:27 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040829162027.GN21964@parcelfarce.linux.theplanet.co.uk> References: <20040828170515.GB24868@hh.idb.hist.no> <4131074D.7050209@namesys.com> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Linus Torvalds Cc: Hans Reiser , Helge Hafting , Rik van Riel , Spam , Jamie Lokier , David Masover , Diego Calleja , christophe@saout.de, vda@port.imtp.ilyichevsk.odessa.ua, christer@weinigel.se, Andrew Morton , wichert@wiggy.net, jra@samba.org, hch@lst.de, linux-fsdevel@vger.kernel.org, Kernel Mailing List , flx@namesys.com, reiserfs-list@namesys.com On Sat, Aug 28, 2004 at 10:01:23PM -0700, Linus Torvalds wrote: > > > On Sat, 28 Aug 2004, Hans Reiser wrote: > > > > I object to openat()..... > > Sound slike you object to O_XATTRS, not openat() itself. > > Realize that openat() works independently of any special streams, it's > fundamentally a "look up name starting from this file" (rather than > "starting from root" or "starting from cwd"). Linus, openat() is trivial to implement in userland *IF* we are talking about stuff already in namespace. Proof: int openat(int fd, char *path, int flags, mode_t mode) { int len = snprintf(NULL, 0, "/proc/self/%d/%s", fd, path); char name[len + 1]; sprintf(name, "/proc/self/%d/%s", fd, path); return open(name, flags, mode); } 7 lines. Replace VLA with alloca() or malloc() in pre-C99 environment. In other words, there's nothing magical about syscall itself - compatibility with Solaris is not an issue here. And basic functionality (i.e. what you've described above) can be trivially achieved with no extra primitives at all. Now, if you want to use that puppy as explicit indicator of magic steps taken, fine, but that again says nothing about the primitives we want to express the magic steps in question - reproducing openat() as one of the libc functions won't be hard anyway. So I have to agree with Hans on that one - I believe that as a fundamental primitive it's wrong choice. Convenient to have in libc - sure, why not?