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>