I was about to say:
You should note that for some operations, the VFS layer does some stuff
and then calls the FS-specific op to finish the job. Or various other
combinations. For example... sys_getdents (readdir.c):
[...]
In this case, to avoid fiddling with the semaphore etc. it would be
necessary to test `if (file->f_op->readdir != default_readdir)' or
similar. On the other hand, maybe the semaphores are really cheap
anyway.
But then I noticed (1) the above is an unusual error case anyway, we
don't care about a few cycles lost; (2) all the places I saw a d_op-> or
f_op->, the only additional work that would come from a default function
entry is a down/up of a semaphore (no big deal if they're fast), and a
function call.
Two test and branches would be saved (file->f_op &&
file->f_op->function). Note that the pointers have to be fetched
anyway; it is simply two test-against-zero and
predicted-not-taken-branch instructions. Which is pretty minimal
overhead itself.
llseek is an exception -- it specifically substitutes a default function
for NULL. Also do_readv_writev looks like it could use more function
pointers to avoid the special case for sockets.
So perhaps the only notable effect would be to make the calling code
_appear_ simpler to read, though it would have to be written in tandem
with the corresponding default function, making the whole lot less
simple overall.
-- Jamie
ps. [ do_readv_writev looks a bit scary. It seems to _assume_ the existence
of file->f_op->read or file->f_op->write and just call it (no function
pointer check). Is this safe?
readv and writev also return EBADF when say, doing writev on a file
descriptor opened O_RDONLY. Shouldn't it be EPERM or something? ]
-
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