From owner-cvs-src@FreeBSD.ORG Wed May 18 22:07:58 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 94C1416A4CE; Wed, 18 May 2005 22:07:58 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A55B143DB6; Wed, 18 May 2005 22:07:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4IM6XvA060905; Wed, 18 May 2005 16:06:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 18 May 2005 16:06:33 -0600 (MDT) Message-Id: <20050518.160633.104091044.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <428BAC85.3070103@samsco.org> References: <20050518182150.lcak29sfts0ssgws@netchild.homeip.net> <20050518.143949.71148873.imp@bsdimp.com> <428BAC85.3070103@samsco.org> 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: Alexander@Leidinger.net cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: cvs-src@freebsd.org cc: des@des.no 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 22:07:58 -0000 > Where the traditional method is immensely useful is in customizing your > kernel immediately after doing a fresh install from CD/ftp/floppy. You > want a slimmer kernel right away without having to suffer through doing > a buildworld. There's no need to 'suffer through' a buildworld. If there are no tools in the binary tree, the tools installed on the system are used instead. I appreciate that you are trying to make things easier for people, but since buildkernel works without a built world means we should be recommending it always. There is one requirement, however, and that is that MAKEOBJDIRPREFIX has to exist. It doesn't have to have anything in it, but it must exist. If it is there, and no binaries are found, it falls back to using binaries from the system. > This is even more true on 6-CURRENT snapshots where > INVARIANTS and WITNESS are enabled and really slow things down. There > is simply no need to do a buildworld, since your sources are completely > in sync with the system. And it works without it, and has for quite some time now. Somewhere around 4.4 is when this changed. Prior to that, yes, you did have to buildworld first. However, it was for situations just like this that it was changed: Revision 1.184 Mon Jan 22 08:07:58 2001 UTC (4 years, 3 months ago) by imp As threatened in hackers@ on Friday, obviate the need for a buildworld to preceed a buildkernel. > I appreciate the effort that has happened over > the years to make the whole upgrade process smoother, but we can't > define 'work' too narrowly or else it becomes just as cumbersome as the > problems that we are trying to fix. I think this comment is misplaced. Please check your facts before taking me to task in the future. buildkernel takes exactly the same amount of time in a fresh install as does the classic method, even when no buildworld has been done, and its definition of 'works' is sufficiently wide. Warner