Date: Mon, 25 Mar 1996 16:31:06 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidg@Root.COM Cc: pst@shockwave.com, freebsd-current@FreeBSD.ORG Subject: Re: async mounts, etc. Message-ID: <199603252331.QAA12826@phaeton.artisoft.com> In-Reply-To: <199603252002.MAA06245@Root.COM> from "David Greenman" at Mar 25, 96 12:02:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The mount of controversy is directly proportional to the amount of > non-related changes that are simultaneously submitted (mixed in with the > rest). Both John and I keep looking at Terry's stuff and asking "Hmmm, how can > we extract just the substance of this". A sure-fire way to cause the code to > not be committed is to make "single entry, single exit" changes at the same > time. I don't care to debate this subject now, but I do want to make something > clear: whether you have commit authority or not, I *strongly* encourage that > changes be localized to the task at hand - especially when the changes must > be reviewed before commit like the ones Terry almost always submits. This > *can* be done. We (john and me) know we can extract the namei/componentname > changes from one of Terry's submissions, for example, but simply haven't had > the time to do it. Yep. I tend to work on things that I want to work on, and I consider any side issue that ends up being required as support "trivial". So when someone is more interested in some of the side changes as the "valuable bits", it get confusing fast. 8-). I expect that it will take some time to piece the integration apart because I had made some kernel reentrancy changes before I started working on some of the FS code, so my code is deltas to those. Since I can't run under local source control and continue to get current bits, my deltas tend to get larger and larger. I have moved most of the SMP stuff into another branch, and like John D. said, if I had 3 days per day, I could probably catch up and part the changes out myself. My main problem is that I have some additional changes on top of all of those, and my system pretty much will not run with those changes without all of the other change piled in together. Parting them out is only an option if there's consensus on commit ordering... and unfortunately, some of the single exit is not there because of single exit, but because of failure path handling for deallocation on the path name buffer (I did everything in that class of changes while I was in there to save me trouble later -- boy was I wrong. 8-)). > Just to clarify my position on the VOP_LOCK layering...I agree in principle > with these changes (as does John D. and Kirk). If Terry is willing to > implement *just* those changes, then we will seriously consider them. I know > it's tempting to fix this or that at the same time or to implement your > personal stylistic changes or whatever. There's too much that can go wrong in > the locking, however, and I must insist that the changes be "localized to the > task". This is why I haven't done lock layering changes yet; the lock code changed significantly in the 4.4BSD-Lite2 over what was in 4.4BSD-Lite, and I didn't want to add significant overhead to the review process. I'm pretty much waiting for the Lite2 integration to blow over, and then I'll jump back in with both feet. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603252331.QAA12826>