Date: Sat, 1 Sep 2001 13:50:13 -0500 From: Alfred Perlstein <bright@mu.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: Peter Wemm <peter@wemm.org>, 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: <20010901135013.Y81307@elvis.mu.org> In-Reply-To: <200109010827.f818RW370778@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Sep 01, 2001 at 01:27:32AM -0700 References: <20010901074325.28AE13807@overcee.netplex.com.au> <200109010827.f818RW370778@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010901 03:27] 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. Don't complain just do it, we all have to deal with it and in fact it makes sense from a clarification perspective. > : > :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. > > 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. No, you added MPSAFE to the generated file, I fixed the generator. I remeber because awk gives me a headache: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/makesyscalls.sh?rev=1.40&content-type=text/x-cvsweb-markup > 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! > > 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. Agreed, those are really bad. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' 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?20010901135013.Y81307>