On Sun, 12 Mar 2000, Hans Reiser wrote:
> I understand you are upset that we have not closely tracked your recent code and
Recent??? Hans, excuse me, but _recent_ changes have nothing with that.
Changes in question happened (roughly) from November 1998 to March 1999.
Either you are kidding or you really got very strange idea of time.
> I say this because it seems that our 2.3.51 port is now stable, we fixed several
> bugs this weekend, and I am quite pleased by how our team came together for it.
> Thanks to your points we will now also be able to increase our speed by several
> thousandths of a percent.
I couldn't care less about the speed of your code. Sorry if it sounds
rude, but that's it. I _do_ care about the cost of maintaining it during
the VFS changes. Sorry, if your idea of recent changes is
2.1.130--2.2.5... See the problem? It means that large sections of code
are unmaintained for _long_. Do you have anybody who would understand what
and how can be called by VFS? Yes or no? I went to look at rename() for
one reason - it's the trickiest part of the namespace interface. And you
have it wrong _for_ _2.2_. Want something simpler? Tell me please, what
kind of call did you expect when you placed the following
+ else if (S_ISDIR(inode->i_mode)) {
+ inode->i_op = &reiserfs_dir_inode_operations;
+ if (dir->i_mode & S_ISGID)
+ inode->i_mode |= S_ISGID;
+ }
+ else if (S_ISLNK(inode->i_mode))
+ inode->i_op = &reiserfs_symlink_inode_operations;
into ->mknod()? Not to mention the fact that first chunk would royally
screw you up if it would ever be called (check the code above - you don't
set the directory in proper way), but what on the earth could be done by
the latter? Let's see - if VFS would ever pass such call, what would you
do? You see that there is a missing piece of information, don't you?
Sorry, but do you actually have a single person in the team who would
understand WTF code in reiserfs/namei.c does? I mean, just on the API
level... And I have a nasty feeling that ->truncate() has a bunch of
problems too.
> By the way, I have heard a rumor that RedHat is going to bundle VxFS as a
> proprietary kernel module. Is this true? Does RedHat envision VxFS becoming a
No idea. This is the first time I hear about such idiocy and if this
information is accurate that's one hell of a stupid thing. If that will
happen I'll just bitbucket bug reports on the systems with such module
loaded _and_ ignore its existance in patches. If binary module breaks it
breaks. Period. Its authors are free to fix the bloody thing - it's Not My
Problem(tm). Just as reiserfs is Not My Problem until it gets into the
tree. And that's the reason why I _really_ want you to clean this stuff up
before it goes anywhere near the official tree. That's the point where I
start to care.
> defacto industry standard if there are no journaling file system in 2.4, and it
> bundles VxFS onto its CDs? Do you have access to the source code for VxFS
> personally, perhaps under NDA? I imagine it will be quite interesting if major
Negative and _violent_ negative. Like fsck I'll sign such thing.
> kernel functionality starts going into closed source kernel modules. I think
> none of us really believed that anything of consequence would ever go into a
> closed source kernel module back when the issue first came up. The social
> consequences of some folks having source code access, and others being excluded,
<Shrug> Let me put it that way: if somebody has a question about
VFS functionality and cares to ask me - I'll answer (if I didn't killfile
the person in question, etc.). I'm not going to sign any sort of NDA and
(AFAIK) none of VxFS people ever asked me such questions. How serious
those rumors are?
-
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:24 EST