[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090624105336.GO8633@ZenIV.linux.org.uk>
Date: Wed, 24 Jun 2009 11:53:36 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Howells <dhowells@...hat.com>,
Miklos Szeredi <miklos@...redi.hu>, alan@...rguk.ukuu.org.uk,
hch@...radead.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, adilger@....com,
akpm@...ux-foundation.org
Subject: Re: [RFC] O_NOACC: open without any access
On Tue, Jun 23, 2009 at 10:34:49AM -0700, Linus Torvalds wrote:
> That said, I do _not_ like the notion of
>
> > Add a new inode->i_filesystem_fop pointer
>
> regardless of whether it's in inode->i_op or wherever. I think we should
> just handle this in the regular "inode->f_op->open" routine, the same way
> we handle FMODE_EXCLUSIVE (O_EXCL), FMODE_NDELAY (O_NONBLOCK) and lack of
> access rights (O_NOACCESS) in the driver open routines that currently
> handle those specially (O_NDELAY is spe
>
> Al?
i_filesystem_fop is certainly bogus, but why do we want to bother with
file_operations at all?
Unless you really insist on unlimited use of ioctl(2) on such beasts (and
any users will be non-portable for obvious reasons anyway), there's no need
to go anywhere near ->open() *or* ->f_op in general.
Just add new methods to ->i_op (and we already have that coming from
fs code) and teach do_filp_open() to
* call permission() with new flag (MAY_TALK_TO_FS_NODE) for such
open()
* do not die with -ELOOP on symlinks if we have O_NOFOLLOW + your flag
* do not call ->f_op->open() at all for such open()
and we are all set. Hell, we can even teach sys_ioctl() that given set
of ioctls maps to calls of our new methods. Taken from ->i_op...
If we want full-blown ->ioctl() coming from the fs code on such opens, we
will need distinct file_operations, no matter what we do with ->open().
It's also doable (we'd need ->i_fop pointing to new foofs_special_file_ops
and its ->open() to be a boilerplate that would replace file->f_op with
the normal one in case of normal open()), but it's more boilerplate patches
and I really don't see what would it buy...
Comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists