lkml.org 
[lkml]   [2000]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: patch: reiserfs for 2.3.49


On Tue, 14 Mar 2000, Hans Reiser wrote:

> Mr. Viro, I suggest the following plan.
>
> A) You tell us what you think is broken in detail.

Ouch. To start with: you are guaranteed that directory is locked when you
create/remove/lookup/readdir on it. You are guaranteed that the only
caller of {create,mknod,link,symlink,mkdir,rmdir,unlink,rename} is
vfs_<method_name>() (in fs/namei.c) (IOW, tests there had passed). During
the rmdir() and directory-killing rename() you can use d_unhashed() to
learn whether you are the sole owner of the reference to potential victim.
You are guaranteed that mknod() got sane type - device, FIFO or socket.
Start with removing unneeded tests (considering the above) and let's see
what will remain there. The rest will require additional attention.

> B) We fix it and test it.
>
> C) You review it to see if it looks fixed enough that you can ignore us, and we
> take responsibility for whether it is fixed as far as the users are concerned.
>
> We have no desire to have you work on our filesystem, don't worry about that.
>
> Presumably telling us what you think is broken should suffice to put the code to
> where it is not somehow a burden to you.
>
> Alexei, I don't want you to use ext2 code, I want you to write code that is your
> code that has no flaws that Viro can point to. If it is not practical to write
> your own, then be very careful to indicate whose it is in the comments. I
> understand that sometimes there is only one way to code an interaction with a
> fixed interface.

WTF? It's total lunacy - take into account the guarantees described above
and do equivalence transformation of your code that would remove unneeded
tests. Then see if the results are OK with you. If there will remain
non-trivial things - let's look at them and decide what they are.
Filesystem should be almost ignorant about VFS - the less work goes there
the less chances to screw up. Yes, sometimes additional stuff _is_ needed,
but if that's the case - fine, let's make sure that we know what it is and
why it is there. Folks, it's not a bloody school and it's not a homework.
ext2 is (to my knowledge) more or less decent. I don't know about races
in directory-related code there (anymore ;-). If your result will look
different - fine, that's the reason to additionally check _both_.

[snip]

> I am ignoring your flame, except to note that my use of the term namespace is
> consistent with the CS subculture I grew up in at Berkeley.

Sigh... Hans, it is not a flame. Really. I'm not interested in insulting
you. Literally. BTW, I don't hate you - I simply don't care. I have to
point out that in all academical cultures I'm aware of if one refers to a
specific work _for_ _explanation_ _of_ _a_ _term_ he is supposed to be
using the meaning of the term used in refered work. I rather doubt that
UCB differs in that respect. That's exactly my problem with your text -
you explicitly refer to Pike et.al. wrt namespaces and then proceed to
talk about the stuff that has nothing with the thing you refered to. Which
is just going to bring us a lot of disrespect from those who know what
Pike et.al. had designed and written about.


-
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.tux.org/lkml/

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