Re: 2.1.118 Tons of oopes
Richard Gooch (rgooch@atnf.csiro.au)
Tue, 1 Sep 1998 12:46:55 +1000
Linus Torvalds writes:
> In article <19980831082313.26439.qmail@hog.ctrl-c.liu.se>,
> <wingel@t1.ctrl-c.liu.se> wrote:
> >tantalophile.demon.co.uk wrote:
> >>Richard Gooch wrote:
> >>> Yes, I can see the benefit of avoiding the NULL check. It would be
> >>> nice to be able to do this. However, that would then require every
> >>> driver to be updated on every addition of a new VFS method.
> >>
> >>It's possible, in the NULL case, that the check is faster than the
> >>function call to the default function.
> >
> >Which is a rather bogus argument, trying to call a VFS method which
> >is NULL usually indicates an error and isn't time critical.
>
> No, some functions are NULL quite normally, simply because it's
> something that the low-level driver or FS doesn't want to bother with.
>
> For example, networked filesystems often need more hooks to tell the
> system that "ok, something changed", while a local filesystem doesn't
> need that and can just let the VFS layer do whatever it wants to do
> without having to worry about anybody else doing something over the
> network.
>
> As such, NULL pointers can often be the _default_ rather than being a
> sign of error cases. And the NULL case may be the fast and
> timing-sensitive one. This is true of the dcache hashing stuff, for
> example, where there are special (and slow) routines for certain
> filesystems that want to do stupid name mangling.
OK, so requiring stubs for the dcache operations doesn't make
sense. That still leaves the file and inode operations (which also see
more frequent extensions being made). Would it make sense (shave a few
cycles and remove the ugly tests) for the file and inode ops?
Regards,
Richard....
-
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.altern.org/andrebalsa/doc/lkml-faq.html