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.
>
Further down, you say that you don't want him working with the code, but
for him to give us a detailed list of what's broken is only slightly less
work than actually fixing it. We simply need to go through all the VFS
interface functions, and make them right.
> 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.
This can't be done. You want Alexei to fix the checks to make them honor
the same boundary conditions and exceptions that ext2 does, but without
looking at or using ext2 code.
> 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.
>
> We are grateful to you for finding bugs in our code Mr. Viro. We regret not
> tracking your VFS bug fixes. We wrote a VFS compatible file system which is
> efficient for small files as the first stage of adding database functionality to
> the FS. This turned out to be quite a lot of work, and after 6 years we are now
> where I had thought we would be in 18 months. Fortunately, with the exception
> of BeFS, our competition has the same sorts of problems. The second stage will
> seek to evolve VFS, and then we will indeed focus on VFS. I am sure that once
> we do that you will truly be upset, but let's worry about that in 2.5 once my
> plans are more code than vapor shall we?
>
I'm sure we'll be able to work things out when we get there. There is no
need to start discussions about changes we might be making, especially
when you don't attempt to decribe the changes ;-)
-chris
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:28 EST