From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 16:25:15 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA8A2106566B for ; Wed, 7 Jul 2010 16:25:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 874FB8FC0C for ; Wed, 7 Jul 2010 16:25:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o67GHv17032815; Wed, 7 Jul 2010 10:17:57 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 07 Jul 2010 10:18:12 -0600 (MDT) Message-Id: <20100707.101812.18550985261476284.imp@bsdimp.com> To: Alexander@leidinger.net From: "M. Warner Losh" In-Reply-To: <20100707173536.14541wa0krsmogcg@webmail.leidinger.net> References: <20100707145634.13925yt8ztdkz4is@webmail.leidinger.net> <20100707.084213.353672579433544368.imp@bsdimp.com> <20100707173536.14541wa0krsmogcg@webmail.leidinger.net> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: ObsoleteFiles and TARGET_ARCH X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 16:25:16 -0000 In message: <20100707173536.14541wa0krsmogcg@webmail.leidinger.net> Alexander Leidinger writes: : Quoting "M. Warner Losh" (from Wed, 07 Jul 2010 : 08:42:13 -0600 (MDT)): : : > In message: <20100707145634.13925yt8ztdkz4is@webmail.leidinger.net> : > Alexander Leidinger writes: : > : Quoting "M. Warner Losh" (from Tue, 06 Jul 2010 : > : 17:49:19 -0600 (MDT)): : > : : > : > I'm wondering... : > : > : > : > Why do we use TARGET_ARCH so much inside of ObsoleteFiles? It : > seems : > : > like it should be used only when we obsolete files on some : > : > architectures, but retain them on others. Instead, it seems to be : > : > used to obsolete files that normally exist on a specific : > : > architecture. This seems backwards. : > : : > : As the person who wrote this initially: : > : : > : The goal was to only delete stuff which was not available anymore on : > : one architecture but where still available on others (as in the : > : 20040130 entry, IIRC at this time the rename was specific to sparc64 : > : and other architectures still had this lib). If it is not used like : > : this, it is a bug. : > : > Then we have a lot of bugs. About 45 of the 49 instances are : > definitely wrong from my quick inspection. : : If those 45 instances are covering just one or two files, I agree. If : those instances cover a huge number of files, it should be : investigated if it makes a speed difference on architectures where : those files never where. I do not expect it would make a significant : speed difference in this case, but as I haven't measured it... Worst case: deleting 45 extra files will make no speed difference on the list that's well over 5000 files in length (wow! that many) : > : > Also, we need to change this, but I don't (yet) define a : > : > TARGET_CPUARCH. : > : > : > : > Also, why is this TARGET_ARCH and not MACHINE_ARCH? That suggests : > : > we're invoking it wrong if this is "needed" for the cross build : > case : > : > to "work". : > : : > : The goal was to have something which can be used like "make : > : DESTDIR=/... XXX=arch_of_dest delete-old" where DESTDIR is either a : > : remote FS for a system of architecture as specified by XXX, or a : > local : > : mount of something with the same properties like in the remote FS : > : case. Without the XXX on the command line it shall behave like the : > : architecture is the same as the current system. If TARGET_ARCH is : > not : > : the correct XXX in the sense as described before, feel free to : > change : > : it to something better. I think I used TARGET_ARCH after looking at : > : what make universe is/was doing. : > : > The TARGET_ARCH=foo on the command line is correct. However, the : > environment that these commands operate in should be the target one, : > not the host one. ru@ appears to have changed MACHINE_ARCH to : : I'm not sure I understand what you want to tell (due to lack of enough : knowledge what those *_ARCH are supposed to do). As long as your : description matches the following use case, I'm ok with any change you : want to make in this regard: : : Assume your system is running with an amd64 world and kernel, and you : have a world for FOO128 available at /import/foobar which is at the : same revision than what you have in /usr/src. You want to run "make : DESTDIR=/import/foobar XXX=FOO128 delete-old" to delete the old files : for FOO128 in /import/foobar. Right, the current interface will be unchanged. The implementation will need to change a little. Warner : Bye, : Alexander. : : > TARGET_ARCH to, according to the comments, work in a cross-build : > world. However, I think he fixed that bug incorrectly, so I'll try to : > fix it properly as part of my general cleanup of TARGET_ARCH abuses in : > the tree. : > : > Warner : > : > : : : : -- : First law of debate: : Never argue with a fool. People might not know the difference. : : http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 : http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 : :