Messages in this thread | | | Date | 31 Aug 1998 08:23:13 -0000 | From | wingel@t1 ... | Subject | Re: 2.1.118 Tons of oopes |
| |
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.
>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; ... }
/Christer -- If it's tourist season, why can't we shoot them?
- 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
| |