>
>
> On Wed, 17 Feb 1999, Alexander Viro wrote:
> > >
> > > Umm.. We _never_ use "." and ".." in filesystems. Never.
> >
> > Linus, please take a look at knfsd.
>
> Are you talking about
[snip]
Nope. I'm talking about the stuff in fs/nfsd/nfsfh.c: lookup_inode() and
get_parent_ino(). And yes, there is quite an interesting comment between
them ;-)
> then yes, there is lots of historical stuff in there. knfsd was originally
> written for older kernels. But note the comments.
>
> That's kind of my argument: we _used_ to need to have "." and ".." and for
> filesystems that didn't have them (like the iso9660 CD-ROM filesystem) we
> went to a fair amount of trouble to try to handle them correctly (and
> there were still special cases where we didn't, as far as I can tell).
> With the dentries, that just went away, but we still have cruft there.
Oh, yes. We have all sorts of cruft in fs/*/*, no doubt. Stats on last
variant of rename patch - 388 lines in, 757 lines out. And that's after
similar stats from the previous runs. And much more can be cleaned up.
Lots of filesystems check for directory being directory. All of them
(except AFFS, damnit) check for the target of link() being non-directory
(instead of VFS doing that). nfsd/vfs.c duplicates namei.c big way.
Dealing with mknod() is duplicated in all filesystems that do it. Minixfs
and sysvfs do very interesting things in rename() and truncate(). Don't
get me started on FAT-dervied filesystems - wait for patch (when rename
stuff will stabilize). Let's not go into the amount of cruft included from
fs.h (embedded foo_inode_info and foo_sb_info).
ObFoo_inode_info: would you object against defining FOO_I(x) as
&((x).u.foo_i) and doing corresponding replacements in filesystems' code?
I mean 1-to-1 replacement, giving the identical text after cpp. That alone
would make transition to externally allocated fs-specific parts much
easier when we'll finally go for it (there *is* a need for light-weight
inodes). I'm not talking about rename patch, indeed - it's completeley
separate story.
Al
-
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/