lkml.org 
[lkml]   [1998]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans