Messages in this thread | | | Date | Tue, 14 Mar 2000 18:04:21 -0500 (EST) | From | Alexander Viro <> | Subject | Re: (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/
| |