From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K.V" Subject: Re: [PATCH] fs: Move attribute flags into non __KERNEL__ space Date: Sat, 17 Dec 2011 19:14:26 +0530 Message-ID: <87vcpfjosl.fsf@linux.vnet.ibm.com> References: <1324021626-10059-1-git-send-email-levinsasha928@gmail.com> <20111216192320.GA23748@infradead.org> <1324071040.29432.3.camel@sasha> <20111216233041.GU2203@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Al Viro , Sasha Levin Return-path: Received: from e32.co.us.ibm.com ([32.97.110.150]:43478 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752165Ab1LQNox (ORCPT ); Sat, 17 Dec 2011 08:44:53 -0500 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 17 Dec 2011 06:44:52 -0700 In-Reply-To: <20111216233041.GU2203@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 16 Dec 2011 23:30:42 +0000, Al Viro wrote: > On Fri, Dec 16, 2011 at 11:30:40PM +0200, Sasha Levin wrote: > > On Fri, 2011-12-16 at 14:23 -0500, Christoph Hellwig wrote: > > > On Fri, Dec 16, 2011 at 09:47:06AM +0200, Sasha Levin wrote: > > > > Attribute flags can be useful in userspace when working with filesystems > > > > such as 9p. > > > > > > No, they aren't. They are kernel internal values and userspace has no > > > fucking business messing with them. > > > > > > > They became userspace business once they got exposed through 9p. > > > > Take a look at : > > > > /** > > * struct p9_iattr_dotl - P9 inode attribute for setattr > > * @valid: bitfield specifying which fields are valid > > * same as in struct iattr > > [...] > > > > That structure is userspace facing, and it's using iattr values. > > > > So either we expose them through fs.h, through 9p.h, or modify 9p code > > to not use them directly. But claiming that they're kernel internal > > values isn't entirely correct. > > They *are* kernel internal values and 9P is asking for trouble exposing > them. Translation: tomorrow we might reassign those as we bloody wish > and any userland code that happens to rely on their values will break. > At which point we'll handle complaints by pointing and laughing. > > It's a 9P bug; fix it there. Turning random internal constants into a part > of ABI is not going to work. I guess we would need to define them at the protocol level then. Something like f88657ce3f9713a0c62101dffb0e972a979e77b9. -aneesh