Date: Sat, 01 Sep 2001 15:12:26 -0700 From: Peter Wemm <peter@wemm.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_prof.c kern_ntptime.c kern_xxx.c Message-ID: <20010901221226.48CC33807@overcee.netplex.com.au> In-Reply-To: <200109010827.f818RW370778@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote:
>
> : static void
> : usage()
> : {
> : /* Insert an empty line if the function has no local variables.
*/
>
> You must be joking. Who came up with that carp? A blank line if
> the function has no local variables? In my entire life as a programmer
> I have never once seen that style. It looked like a mistake. If I
> see any more I won't take out the blank line but... no, I don't want to
> know whos idea it was.
Thanks.. This is what I was asking for, to make sure you were aware of it
and to ask you to stop tweaking it..
> :
> :Just about every one of these that you have touched like this has caused
> :a conflict with the kse diff because of the following example:
> :
> :+/*
> :+ * MPSAFE (accept1() is MPSAFE)
> :+ */
> : int
> : oaccept(p, uap)
>
> The code is going to get worse before it gets better. It's taking
> long enough just slogging through this stuff, reviewing the patches
> four ways from sunday, and testing the resulting kernels on a file by
> file basis to make sure buildworld doesn't blow the kernel to bits.
> I happen to have the time to do it now, but that doesn't mean I have
> to be cheery about it. We can do plenty of cleanup later. I'm probably
> going to piss everyone off at leat once before this is over.
I was not complaining about the MPSAFE thing ot the other changes here. I'm
perfectly ok with this stuff. I included this as an example of where the
only change was removing the style(9) line which caused a conflict with the
KSE change on the other line.
> Believe me, I know these patches are breaking the P4 merge and also
> playing havoc with Alfred's and JHB's stuff. I'm not doing it on
> purpose. Frankly, I'm surprised that not one person beyond Alfred has
> done any Giant pushdown work on the syscalls since I added the MPSAFE
> flag to the syscall generator months and months ago. Well, it needs
> to be done.
And I'm fine with that too. I've been the one who is merging the conflicts
between your stuff and the KSE stuff for the last couple of days while Julian
has been busy.
> I'm also annoyed that so much incremental work is being done in P4 rather
> then in the main tree. Julian's KSE stuff is an all-or-nothing deal
> and P4 makes sense for a little while, but neither the proc lock, or
> the struct filedesc stuff, or the struct file stuff is all-or-nothing...
> it can all be done incrementally direct to the main tree as long as
> you test the resulting kernel before you commit it. Instead I'm seeing
> a kitchen-sink approach being taken when it is entirely unnecessary...
> we have Giant available, it makes taking an incremental approach
> possible!
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.
> Also, since I'm in critique mode... for gods sake, LAY OFF THE
> MULTI-LINE MACROS AND INLINES FOR COMMON PROCEDURE CALLS!! The bloat
> they are causing is unbelievable.
Amen to that! I've had enough nightmare stripping them out of the NFS
code.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?20010901221226.48CC33807>