Re: dentry_operations vs inode_operations

Linus Torvalds (torvalds@transmeta.com)
Mon, 25 Aug 1997 16:29:01 -0700 (PDT)


On Mon, 25 Aug 1997, Benjamin C R LaHaise wrote:
>
> I've begun to look at rewriting my loopback filesystem to take advantage
> of dentries, but they haven't help at all yet, and here is my idea/plan
> for making them useful (smbfs, ncpfs and such should benefit too). I'd
> like to move most of the inode operations that operate on directory
> entries into the dentry_operations. This will give lofs the advantage of
> not having to duplicate any inodes of the underlying filesystem, but
> still be able to provide say read only functionality on top of a rw fs.

I already sent email to some other people stating that this is what I want
to do anyway..

> A quick glance suggests that all operations except for
> (read|writ|updatee)page, bmap, truncate, smap and revalidate will have to
> move. If there's no great objection to this, I'll put together a patch
> that does this.

Wait for my pre-patch to show up on ftp.kernel.org. I've changed
"lock_parent()" to move us into this direction (ie the "parent" is no
longer the inode, it's really the parent dentry). That should make your
patches smaller too.

> Sorry if it seems an enourmous change, but it's the only way I can see
> for us to get the usefulness of a dentry-centric system that allows us to
> implement filesystems without underlying indoes. Hey, ideally
> directories wouldn't *need* an inode resident in memory for networks
> filesystems.

It's not an enormous change - the naming code conceptually is a "dentry"
issue, not an inode issue.

Obviously for historical reasons all the operations were inode operations
simply because we didn't _have_ any dentries..

Linus