From owner-cvs-src@FreeBSD.ORG Wed May 18 08:36:01 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A33416A4CE; Wed, 18 May 2005 08:36:01 +0000 (GMT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 116F743D77; Wed, 18 May 2005 08:36:00 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd22.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1DYK22-0002qL-02; Wed, 18 May 2005 10:35:58 +0200 Received: from Andro-Beta.Leidinger.net (ZXT5ecZZgeb3sELdsyQ7p4RtuvxN-ec7wAG0hBSW9Yx8AvUpU2CEkb@[217.229.212.213]) by fwd22.sul.t-online.de with esmtp id 1DYK1p-20MEJU0; Wed, 18 May 2005 10:35:45 +0200 Received: from localhost (localhost [127.0.0.1])j4I8Zixw040069; Wed, 18 May 2005 10:35:44 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Wed, 18 May 2005 10:35:44 +0200 Message-ID: <20050518103544.18i8c5w3ok8oscgw@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 18 May 2005 10:35:44 +0200 From: Alexander Leidinger To: Warner Losh References: <20050517150415.cy3vhgx864kk8w8c@netchild.homeip.net> <86ekc5ubez.fsf@xps.des.no> <20050517180454.brq1tjzo2s88g8ow@netchild.homeip.net> <20050517.123715.74710629.imp@bsdimp.com> In-Reply-To: <20050517.123715.74710629.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-ID: ZXT5ecZZgeb3sELdsyQ7p4RtuvxN-ec7wAG0hBSW9Yx8AvUpU2CEkb@t-dialin.net X-TOI-MSGID: 0d89bc22-bfaf-42cd-84bb-742c74467597 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 08:36:01 -0000 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. Changes to other subsystems which make the old or new userland incompatible with the new or old kernel are typically announced too. 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). 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. >> >> If you just change one file and you want to recompile the kernel, which >> >> procedure is faster? >> > >> > They're equally fast, though 'buildkernel' normally does 'make clean' >> > and 'make depend' every time. Use NO_KERNELCLEAN when you can get >> > away with it (which is most of the time; I have it in make.conf) and >> > NO_KERNELDEPEND when you know you haven't changed the dependency tree >> > (i.e. when you haven't changed any #include statements). All the >> > usual tricks (KODIR, NO_MODULES, MODULES_OVERRIDE) also work. >> >> The "equally fast, though ..." part is funny (at least to me, YMMV)... >> >> So I have to type "make buildkernel -DNO_KERNELDEPEND" (while having >> NO_KERNELCLEAN=yes in make.conf) instead of "make"... sorry, but I'm too >> lazy to do this (at least as long as I don't get a benefit out of using the >> new way). > > alias a "make buildkernel -DNO_KERNELDEPEND" You're cheating! ;-) Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 A baby is an alimentary canal with a loud voice at one end and no responsibility at the other.