> Alexander Viro writes:
> >
> >
> > On Wed, 16 Dec 1998, Richard Gooch wrote:
> >
> > > The "clean" (or "fast", however you want to look at it) solution is to
> > > let the dentry layer do the work for you. For that you would need
> > > aliasing support for all dentries. Offhand, I don't see how you'd
> > > support a read-only option with a pure dentry scheme. In fact, I see
> > > the read-only requirement as a strong reason for doing it the "hard"
> > > way (i.e. not enhancing the VFS interface). A read-only lofs is great
> > > for securing ftp and tftp servers.
> >
> > Erm... Says who that intermediate dentries in stack can't have inodes
> > associated with them? Sure, pure vnode scheme is nice, but our one is also
> > usable.
>
> In an earlier thread hpa talked about doing it all in the dentry
> layer and not creating extra inodes at all. It would all be done by
> having aliases. I think that precludes modifying the behaviour of
> inodes.
>
> The sledgehammer approach I mentioned would use normal dentries and
> virtual inodes, and the virtual inodes would have a set of glue
Wait a bit. ALL inodes are virtual. Non-virtual part is
foo_inode_info.
> operation functions. The glue functions would in turn call the
Please don't. We'll need a _good_ bypass routine, otherwise
we'll end in deep lossage. Brute force method you've mentioned will
give you nasty overhead. We'll have to replace all
if (foo->i_op && foo->i_op->bar) foo->i_op->bar(foo,baz);
stuff to something a-la V_BAR(foo,baz) where V_{something} would bloody
better be well-optimized. Maybe we'll have to keep a pair of bitmaps in
inode - supported methods and bypass ones. Then macro stuff in V_FOO could
check those bitmaps, bypass if needed, otherwise if method is supported -
call it, otherwise - call default ones. IMHO it's a work for inline
assembler. To create a write-protector you'll need to install a layer
between lofs and ext2|ufs|whatever that would bypass everything except
->permission() and would have a ->permission() checking for MAY_WRITE set,
returning -EROFS if so, otherwise calling uderlying ->permission()/doing
the standard stuff.
> operation functions of the real inodes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/