Date: Tue, 10 Feb 1998 10:22:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: tlambert@primenet.com, jbryant@unix.tfs.net, freebsd-current@FreeBSD.ORG Subject: Re: merging win95 and nt filesystem changes into msdosfs Message-ID: <199802101022.DAA25240@usr05.primenet.com> In-Reply-To: <5767.887103108@time.cdrom.com> from "Jordan K. Hubbard" at Feb 10, 98 01:31:48 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > If the FS framework were logically layered to eliminate upcalls and > > > > make all VOP's reflexive, I would be willing to take on this task. > > > > > > Translation: "No." :-) > > > > Translation: "Jordan should give me the same benefit of the doubt as > > he gives to complete strangers". > > I think you misread that one. Consider the odds of "the FS framework > being logically layered to eliminate upcalls and make all VOP's > reflexive" as a prerequisite and you'll see the accuracy of my > translation emerge. :) Well, I think Poul has honestly done a lot of work in this area, and I've done most of the rest of the work, if only people would take the code without insisting on understanding how it works, so long as it does (I'm willing to be called to account when it doesn't, and I'm in the Bay Area now, so if you are interested, I can whiteboard anything that isn't obvious, and save a lot of written hand-waving; some of these problems are hard, and you can't easily explain hard problems, or they wouldn't be hard problems. Worst case, you can just back it out, like you've done with other changes). Frankly, I don't pretend to understand all of the intracacies of everything in the VM system (only the parts I care about, and the others, only enough to get me into trouble). But I've been doing FS work professionally for about 10 years now, on a large number of platforms, and I've hacked on "Oh golly" code in Veritas and NetWare UNIX Client, and locking in AIX (I don't know anyone else who can do advisory locking from AIX kernel threads), and an SMP-safe FS for SVR4 and SunOS and Solaris. I certainly don't expect everyone to understand what I understand without putting in 10 years on the subject themselves (yes, I readily acknowledge that there are people who've done this, and people who've done a hell of a lot more, but I'm willing to contribute code and fixes to FreeBSD, and they are all off working on proprietary code). There is a dearth of real architecture work that's going on right now, and I have a real problem with this fact. The NFS breakage is one example of an architectural cascade failure that's out of control, despite the best efforts of those valiantly in the path of the avalanche. FreeBSD used to be able to point to the stability of it's networking and it's NFS as being "the reference implementations", and now it's being beaten up. This *must* stop. Apparently, very recently, it was decided that the primary reason stated against incorporating my FS architecture changes, divergence from other BSD's, no longer held as much force. Certainly, the *necessary* work Elvind is doing attests to that: the need for a clean workplace finally outweighed the need to prevent divergence from other dirtier workplaces (I would be happy for them to pick up my FS code from FreeBSD, just as FreeBSD picked up my LKM code from NetBSD). FS hackers need an equivalent "clean workplace" -- me among them. It would be a shame to lose this *wonderful* momentum towards actual, and IMO, necessary to the future of FreeBSD, progress, without at least a token struggle. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802101022.DAA25240>