Date: Sat, 01 Sep 2001 18:03:49 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, Peter Wemm <peter@wemm.org> Subject: Re: cvs commit: src/sys/kern subr_prof.c kern_ntptime.c kern_xxx Message-ID: <XFMail.010901180349.jhb@FreeBSD.org> In-Reply-To: <200109012243.f81MhJ976806@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01-Sep-01 Matt Dillon wrote: >:Yes, John's stuff could be done in the main tree. But he's using p4 as a >:tool where he commits frequent tweaks to the tree, and uses that for >:syncing his test boxes for testing after commits. As soon as there's >:enough to commit that has been tested properly he commits it to cvs. If >:you'd prefer that he commit untested stuff to cvs and then test after the >:fact, then please say the word. >: >:Cheers, >:-Peter >:-- >:Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > > It depends what you define as testing. 95% of the code modifications > related to the proc lock and the struct file and struct filedesc locking > do not require a great deal of testing because they don't actually do > anything. These all devolve into defining a few procedures (guys, please > stop using macros!) which can initially be left empty or do nothing more > then minimal ref counting to make sure things match up. 95% of the > work is inserting the locking and unlocking procedure calls wherever they > are needed throughout the codebase - but since the procs don't really > do anything, this can all be done in the main tree and all be done with > only minimal testing. > > It's the last 5% that requires the serious testing -- making the locking > and unlocking procedures actually do something real. After that it > simply > becomes a matter of removing or pushing-down the Giant wrapper in the > now-protected routines, one syscall at a time or one file at a time, > with moderate testing. It's that simple. I wish it were. I managed to break signals about 5 times in my last spree of proc lock commits in the fall and winter. I have to debug another panic on my alpha SMP box related to a sendsig() chagne (that on teh surface looks harmless) before I can commit that patch and then start testing out other patches. At the moment I'm at home on the weekend churning out occasional locking and committing the raw, untested code to p4 so it is in place that keeps up with the changes and makes it easier to back out stuff, etc. The entire reason SCM's exist. It just so happens that CVS doesn't scale well to having, oh, 4 branches off of smpng, and that being a branch off of current like p4 does. > -Matt -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010901180349.jhb>