From owner-cvs-all Sat Sep 1 13:22:19 2001 Delivered-To: cvs-all@freebsd.org Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id DDED837B408 for ; Sat, 1 Sep 2001 13:22:08 -0700 (PDT) Received: (qmail 6367 invoked from network); 1 Sep 2001 20:22:08 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 1 Sep 2001 20:22:08 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200109010827.f818RW370778@earth.backplane.com> Date: Sat, 01 Sep 2001 13:22:13 -0700 (PDT) From: John Baldwin To: Matt Dillon Subject: Re: cvs commit: src/sys/kern subr_prof.c kern_ntptime.c kern_xxx Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 01-Sep-01 Matt Dillon wrote: > 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. Actually, p4 handles 3-way merges quite well. It probably won't step on my toes very much. > 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! Mostly because I haven't done more than compile my current set of proc locking changes. I'm using p4 to store work revisions of files before I can test them and commit them. Presently I'm running into a wall with a seemingly simply change wrt proc locking and sendsig causing an Alpha SMP kernel to blow up my dual Alpha test machine but work fine on my UP alpha test machine. > 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. Do take into account the difference that having debugging on makes. A debugging kernel is going to be bloated, yes, but the non-debugging one won't be. Other OS's with multithreaded kernels inline the simple first test for mutex acquire/releases to optimize for the common case. > -Matt -- John Baldwin -- 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