From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 7 15:17:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60DDB16A4CE; Wed, 7 Jan 2004 15:17:57 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F3DA43D45; Wed, 7 Jan 2004 15:17:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i07NHhtV065414; Wed, 7 Jan 2004 15:17:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i07NHaM9065411; Wed, 7 Jan 2004 15:17:36 -0800 (PST) (envelope-from dillon) Date: Wed, 7 Jan 2004 15:17:36 -0800 (PST) From: Matthew Dillon Message-Id: <200401072317.i07NHaM9065411@apollo.backplane.com> To: jsd@jdyson.com References: <200401062000.i06K0hSI012184@dyson.jdyson.com> cc: freebsd-chat@freebsd.org cc: Maxim Hermion cc: freebsd-hackers@freebsd.org cc: Brett Glass cc: dyson@iquest.net cc: Munden Randall J Subject: Re: Where is FreeBSD going? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2004 23:17:57 -0000 :It is INTERESTING to comment on someone whose viewpoint doesn't extend :beyond the VM system, because out of Greenman, me and even Matt Dillon, :(and the extremely respected alc), I don't know of any people :with a myopic VM viewpoint. An example of that might be Matts ability :and succes dealing with the VERY IMPORTANT NFS issues, or perhaps my implementation :of the vfs_bio merged cache, minimal-copy pipe code, kernel memory management :improvements (which aren't really VM per se), early playing with the ATA :driver, SIGNIFICANT filesystem work (e.g. the vastly improved LFS didnt' :get installed because of softupdates making it redundant), careful rework of :certain portions of low level code, and it is definitely ludicrous :to claim that Greenman was VM myopic. Currently in FreeBSD-5 there are far fewer people able to work on a wide range of subsystems due to the complexity of the SMP environment. That should be clearly obvious to everyone... I rarely see cross-disciplinary commits (though there are other reasons for that observation beyond the complexity of the SMP environment). Certainly I see far fewer such commits then occured in the 4.x days. Focus is good, but the complexity of the APIs are such that as some of the current developers move on to other things large swaths of code are going to start to become unattended through lack of understanding, and it could potentially swamp the relatively few interdisciplinary people left in the project. The SMP interactions that John mentions are not trivial... they would challenge *ME* and regardless of what people think about my social mores I think most people would agree that I am a pretty good programmer. I have no doubt that FreeBSD-5 can be stabilized with the current development crew, but the warning signs abound and if the SMP environmental interfaces are not simplified FreeBSD-5 will end up in serious trouble down the line. The idea (that some people have stated in later followups to this thread) that the APIs themselves will stabilize is a pipedream. The codebase may become reasonably stable, but there are a lot of things in there that people are going to want to rewrite in coming years, and rewriting by people other then the original authors is one of the reasons why we had so much trouble in the 2.x and 3.x days. Look at how little VFS has been touched in the intervening years despite the fact that it is obvious that it has needed a serious rewrite for the last decade. I can barely figure it out even now and I have spent hundreds of hours working on VFS. I mean, I don't think anyone can honestly say that the scheduler is 'done', or even close to done. Look at how long the original 42 scheduler was worked on after it was originally finished? Same goes for the VM system, VFS, the slab allocator, the mutex related code, the USB code (EHCI for example), and everything else. Simplifying maintainance should be of paramount concern to everyone, and the number one most complex issue in FreeBSD-5 right now are the SMP related APIs and non-deterministic scheduler side effects like preemptive cpu migration, indirect preemptive switching to non-interrupt threads due to priority borrowing, and non deterministic side effects from blocking in a mutex (because mutexes are used for many things now that spl's were used for before, this is a very serious issue). See? I didn't mention DragonFly even once! Ooops, I didn't mention DFly twice. oops! Well, I didn't mention it more then twice anyway. -Matt