linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: Move attribute flags into non __KERNEL__ space
Date: Fri, 16 Dec 2011 23:30:42 +0000	[thread overview]
Message-ID: <20111216233041.GU2203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1324071040.29432.3.camel@sasha>

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 <linux/net/9p/9p.h>:
> 
> 	/**
> 	 * 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.

  reply	other threads:[~2011-12-16 23:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16  7:47 [PATCH] fs: Move attribute flags into non __KERNEL__ space Sasha Levin
2011-12-16 19:23 ` Christoph Hellwig
2011-12-16 21:30   ` Sasha Levin
2011-12-16 23:30     ` Al Viro [this message]
2011-12-17 13:44       ` Aneesh Kumar K.V
2011-12-17 18:29         ` Al Viro
2011-12-18 17:33           ` Eric Van Hensbergen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111216233041.GU2203@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=hch@infradead.org \
    --cc=levinsasha928@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).