From owner-cvs-all@FreeBSD.ORG Wed May 18 13:49:44 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23B1416A4CE; Wed, 18 May 2005 13:49:44 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4101443D90; Wed, 18 May 2005 13:49:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4IDluFs055915; Wed, 18 May 2005 07:47:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 18 May 2005 07:48:05 -0600 (MDT) Message-Id: <20050518.074805.26964549.imp@bsdimp.com> To: Alexander@Leidinger.net From: "M. Warner Losh" In-Reply-To: <20050518103544.18i8c5w3ok8oscgw@netchild.homeip.net> References: <20050517180454.brq1tjzo2s88g8ow@netchild.homeip.net> <20050517.123715.74710629.imp@bsdimp.com> <20050518103544.18i8c5w3ok8oscgw@netchild.homeip.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: des@des.no cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ata ata-queue.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 13:49:44 -0000 In message: <20050518103544.18i8c5w3ok8oscgw@netchild.homeip.net> Alexander Leidinger writes: : Warner Losh wrote: : : > From: Alexander Leidinger : >> And I haven't seen a technical reason why the classic way of doing : >> it is bad. : >> Did I missed it or do I have to say "I don't get it"? : > : > It is better because it uses tools in your build tree, rather than : > what's installed on the system. For development, the classic way is : > as good as the new way. But for upgrades and such, you can get into : > lots of trouble when config or binutils, etc change. : : Users of -current are supposed to read current@. And they are supposed to : /usr/src/UPDATING. Major changes to binutils at least provoke a HEADS-UP : message in current@ (at least they did in the past). And major changes to : config result in a message about mismatching versions if you run an old : config binary. In the past we took this attitude. However, there were *SO* many questions about why the build was broken that we introduced buildkernel/installkernel. Once we did that, the number of questions dropped to almost zero. Since I used to answer a bunch of them, and I started UPDATING to help with the FAQ, I can tell you we're running at about 10% the previous layers. It is a safe way to build the kernel that always works. And we've also seen the ability for more people in the user community to answer other people's questions. It really has been a big win. Also, most of our users, even those running current, get scared at the slightest hint of a problem. They aren't kernel experts, but like running current. When they see config mismatch, they literally do not know what to do. : Changes to other subsystems which make the old or new userland incompatible : with the new or old kernel are typically announced too. Typically? Hardly. Sometimes, yes. But not all the time. It also varies with time. Some months are good, some are bad. : So typically (updating from a not too old previos version of current) it : doesn't matter which way you use as long as you carefully use the offered : resources. And we've survived with this procedure for a long time (I survive : since ELF-day, and even when I had some hickups I always got it working again : with kernel.old, loader.old and so on). Carefully. Most of our users aren't careful. I mean no disrespect by that, but they have better things to do with their time than to bother with this week's workaround for building FreeBSD. : This is like "the telnet problem". Alot of people yell at you that you have : to use ssh and telnet is evil. But telnet is an useful tool and there are : situations where it is ok to use telnet because it can't hurt you in those : situations. I generally object to badmouthing tools in every situation, when : there are valid uses for this tool. I favour teaching the people where it is : ok and where it isn't ok to use such tools, and I show allergic reactions : when someone exhibits this "everything is evil" behavior. I hope this lets : you understand why I "promote" the old behavior here. This is a non-sequitor. The new kernel targets produced real, tangable results. If you want to use the old ways, feel free. Just don't complain when they break, which they do with far too frequency. Warner