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

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:44    [W:0.071 / U:5.996 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site