Messages in this thread | | | Date | Mon, 31 Aug 1998 16:00:53 +0100 | From | Jamie Lokier <> | Subject | Re: 2.1.118 Tons of oopes |
| |
On Mon, Aug 31, 1998 at 06:33:32PM +1000, Richard Gooch wrote: > And, probably more important, the VFS code would be neater without all > those tests.
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
| |