Re: 2.1.118 Tons of oopes

Richard Gooch (rgooch@atnf.csiro.au)
Mon, 31 Aug 1998 21:33:09 +1000


wingel@t1.ctrl-c.liu.se writes:
> 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.

Yup.

> >Richard Gooch wrote:
> >> However, if there was some compiler trickery we could employ such that
> >> a VFS change doesn't require source code to be touched, it would be a
> >> good idea. Being able to strip those method existence tests would make
> >> code a bit more readable and would also save a few cycles. But I don't
> >> see how to do it without making drivers not distributed with the
> >> kernel much harder to maintain.
>
> One way of "fixing" this for most cases might be to let register_chrdev
> call a function fixup_fops() like this:
>
> void fixup_fops(struct file_operations *fops)
> {
> if (!fops->llseek) fops->llseek = dummy_llseek;
> if (!fops->read) fops->llseek = dummy_read;
> if (!fops->write) fops->llseek = dummy_write;
> ...
> }

That idea has some appeal. We can't rely on it, though, because there
are plenty of drivers which substitute the methods structure at some
point, and then sometimes later restore the methods.

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