Date: Sat, 1 Sep 2001 01:27:32 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Peter Wemm <peter@wemm.org> 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: <200109010827.f818RW370778@earth.backplane.com> References: <20010901074325.28AE13807@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
: 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.
:
: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.
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.
-Matt
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?200109010827.f818RW370778>