From owner-freebsd-arch@FreeBSD.ORG Mon Jul 5 18:56:27 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FF0F106564A for ; Mon, 5 Jul 2010 18:56:27 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 16E488FC14 for ; Mon, 5 Jul 2010 18:56:26 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 592F511BA7A for ; Mon, 5 Jul 2010 13:56:25 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id M30RC39SZR9E for ; Mon, 05 Jul 2010 13:56:22 -0500 From: Rui Paulo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Jul 2010 19:56:19 +0100 Message-Id: To: freebsd-arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: Cleaning up the CDDL import mess 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: Mon, 05 Jul 2010 18:56:27 -0000 Right now we have four locations for CDDL import code: 1) vendor-cddl 2) vendor/opensolaris 3) vendor-sys/opensolaris 4) and... HEAD itself. 1) vendor-cddl seems to be the first DTrace import and it's probably = ready to be svn rm'ed because it creates too much confusion. The first = thing someone who is looking at CDDL source is to probably look at = vendor-cddl and I would like to avoid this. But I don't know what will happen to the mergeinfo in head/cddl and = head/sys/cddl (I think no harm will be done). 2 and 3) These are the correct locations IMHO and I know that jhb did = move the code here in the past. 4) The ZFS code lives in HEAD, unfortunately. I thought the policy was = to have a vendor import for vendor code so that we could merge *from* = upstream more easily. I was told that this is being done to some extent = in Perforce, but I don't know how acceptable this to the community. I need to import some DTrace code into 2 and 3, but I would like to svn = rm vendor-cddl, if there are no objections. Regards, -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Tue Jul 6 03:46:56 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B6C1106564A; Tue, 6 Jul 2010 03:46:56 +0000 (UTC) (envelope-from gordon.tetlow@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B5BBE8FC18; Tue, 6 Jul 2010 03:46:55 +0000 (UTC) Received: by iwn35 with SMTP id 35so4633593iwn.13 for ; Mon, 05 Jul 2010 20:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=SxTB3eG8m+dqk8zgTLSWiB4DpxXE+r+cV5dpGQ28wBA=; b=F7A4tchAKw0ywN3yUgoIGvXdrCb/TFuk7hpUSkzBZkJQtw2wziwvlep6kxBQfDqSNl WGB867X5peV/GvDvDUdxEtMF71Bw+a7NGzzL2aleH0Tv2owTbLRQ/ox/hVDx2P9MPKzV Awl5sVDsFD8qqrleRunQrW9R0XeolyjxxZ1fs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=db6MNNK+M/Fe0OqGfkrFpu0JXZqtsRDdFKFSc6Y01M4WrZLcoqcqOd4UaB42NSOxak GaRJ9NKXMjTEJ6luMFwFGg30AtWiRXno/H1XdL4RtovQ1EQzjodckgjLWFZfu9cEvOoV 3hAd5Dos5HSRCDdS2Jl7f6eRK+wKY6pQrG/wg= MIME-Version: 1.0 Received: by 10.231.31.200 with SMTP id z8mr3937688ibc.90.1278386244663; Mon, 05 Jul 2010 20:17:24 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.160.205 with HTTP; Mon, 5 Jul 2010 20:17:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Jul 2010 20:17:24 -0700 X-Google-Sender-Auth: BNa8UmBbTqgw4CrMz9MlEV8nPxg Message-ID: From: Gordon Tetlow To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: Cleaning up the CDDL import mess 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: Tue, 06 Jul 2010 03:46:56 -0000 On Mon, Jul 5, 2010 at 11:56 AM, Rui Paulo wrote: > Right now we have four locations for CDDL import code: > > 1) vendor-cddl > 2) vendor/opensolaris > 3) vendor-sys/opensolaris > 4) and... HEAD itself. > > 1) vendor-cddl seems to be the first DTrace import and it's probably ready > to be svn rm'ed because it creates too much confusion. The first thing > someone who is looking at CDDL source is to probably look at vendor-cddl and > I would like to avoid this. > But I don't know what will happen to the mergeinfo in head/cddl and > head/sys/cddl (I think no harm will be done). > > 2 and 3) These are the correct locations IMHO and I know that jhb did move > the code here in the past. > > 4) The ZFS code lives in HEAD, unfortunately. I thought the policy was to > have a vendor import for vendor code so that we could merge *from* upstream > more easily. I was told that this is being done to some extent in Perforce, > but I don't know how acceptable this to the community. > > I need to import some DTrace code into 2 and 3, but I would like to svn rm > vendor-cddl, if there are no objections. > Sounds reasonable. I would clear it with cvsadm@ (is that the appropriate list these days?) on the mergeinfo question. Gordon From owner-freebsd-arch@FreeBSD.ORG Tue Jul 6 08:50:12 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C43F21065680; Tue, 6 Jul 2010 08:50:12 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3CFF78FC1D; Tue, 6 Jul 2010 08:50:12 +0000 (UTC) Received: from roadrunner.spoerlein.net (ip-83-147-137-138.dsl.digiweb.ie [83.147.137.138]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o668o4cM086253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Jul 2010 10:50:10 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1278406211; bh=XvtuGMu9o2g0xYlnYdrsKekV9GKCAleH9ZWwpJFTPpk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=P7hu6DrU2SkKeltAkwp7oT8+hbh9HAKviwgthzz8fXGqk/XjtNop+iZF11I34l51E izXQEBSTCkbYdWo6bYANSXMejIQH0dAz/qTt37RLyjnZ+g6JbBmC52lGt9IMC9Wxl4 8QHPlDLeH422xyySypsZSZjJIhTu/lh7RslmfGeg= Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.4/8.14.4) with ESMTP id o668kXdJ006291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2010 09:46:33 +0100 (IST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.4/8.14.4/Submit) id o668kVV0006290; Tue, 6 Jul 2010 09:46:31 +0100 (IST) (envelope-from uqs@spoerlein.net) Date: Tue, 6 Jul 2010 09:46:30 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Rui Paulo Message-ID: <20100706084630.GA6191@roadrunner.spoerlein.net> Mail-Followup-To: Rui Paulo , freebsd-arch@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: Cleaning up the CDDL import mess 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: Tue, 06 Jul 2010 08:50:12 -0000 On Mon, 05.07.2010 at 19:56:19 +0100, Rui Paulo wrote: > Right now we have four locations for CDDL import code: > > 1) vendor-cddl > 2) vendor/opensolaris > 3) vendor-sys/opensolaris > 4) and... HEAD itself. > > 1) vendor-cddl seems to be the first DTrace import and it's probably ready to be svn rm'ed because it creates too much confusion. The first thing someone who is looking at CDDL source is to probably look at vendor-cddl and I would like to avoid this. > But I don't know what will happen to the mergeinfo in head/cddl and head/sys/cddl (I think no harm will be done). > > 2 and 3) These are the correct locations IMHO and I know that jhb did move the code here in the past. > > 4) The ZFS code lives in HEAD, unfortunately. I thought the policy was to have a vendor import for vendor code so that we could merge *from* upstream more easily. I was told that this is being done to some extent in Perforce, but I don't know how acceptable this to the community. > > I need to import some DTrace code into 2 and 3, but I would like to svn rm vendor-cddl, if there are no objections. I don't get why we even have a vendor-sys and vendor-crypto and would like to see all of them moved into one common vendor tree. Just my two cents ... Uli From owner-freebsd-arch@FreeBSD.ORG Tue Jul 6 09:03:58 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13E18106566B for ; Tue, 6 Jul 2010 09:03:58 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id AD9218FC15 for ; Tue, 6 Jul 2010 09:03:57 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 1212D11BA75; Tue, 6 Jul 2010 04:03:56 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id 9GTPB4ESBGSQ; Tue, 06 Jul 2010 04:03:53 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Rui Paulo In-Reply-To: <20100706084630.GA6191@roadrunner.spoerlein.net> Date: Tue, 6 Jul 2010 10:03:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100706084630.GA6191@roadrunner.spoerlein.net> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1081) Cc: freebsd-arch@freebsd.org Subject: Re: Cleaning up the CDDL import mess 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: Tue, 06 Jul 2010 09:03:58 -0000 On 6 Jul 2010, at 09:46, Ulrich Sp=F6rlein wrote: > On Mon, 05.07.2010 at 19:56:19 +0100, Rui Paulo wrote: >> Right now we have four locations for CDDL import code: >>=20 >> 1) vendor-cddl >> 2) vendor/opensolaris >> 3) vendor-sys/opensolaris >> 4) and... HEAD itself. >>=20 >> 1) vendor-cddl seems to be the first DTrace import and it's probably = ready to be svn rm'ed because it creates too much confusion. The first = thing someone who is looking at CDDL source is to probably look at = vendor-cddl and I would like to avoid this. >> But I don't know what will happen to the mergeinfo in head/cddl and = head/sys/cddl (I think no harm will be done). >>=20 >> 2 and 3) These are the correct locations IMHO and I know that jhb did = move the code here in the past. >>=20 >> 4) The ZFS code lives in HEAD, unfortunately. I thought the policy = was to have a vendor import for vendor code so that we could merge = *from* upstream more easily. I was told that this is being done to some = extent in Perforce, but I don't know how acceptable this to the = community. >>=20 >> I need to import some DTrace code into 2 and 3, but I would like to = svn rm vendor-cddl, if there are no objections. >=20 > I don't get why we even have a vendor-sys and vendor-crypto and would > like to see all of them moved into one common vendor tree. Just my two > cents ... That's actually another problem that I do not want to tackle right now. = What I do want to do is get rid of vendor-cddl. Then we can think about = the others... Regards, -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Tue Jul 6 23:52:41 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 9FC0D106564A for ; Tue, 6 Jul 2010 23:52:41 +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 4D46C8FC23 for ; Tue, 6 Jul 2010 23:52:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o66Nn47r022797 for ; Tue, 6 Jul 2010 17:49:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 06 Jul 2010 17:49:19 -0600 (MDT) Message-Id: <20100706.174919.29649800801850.imp@bsdimp.com> To: arch@FreeBSD.org From: "M. Warner Losh" 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: Subject: 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: Tue, 06 Jul 2010 23:52:41 -0000 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. 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". Comments? Warner P.S. I'll be happy to provide a patch here... From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 13:13:11 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 564E9106566C for ; Wed, 7 Jul 2010 13:13:11 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id DB5828FC20 for ; Wed, 7 Jul 2010 13:13:10 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2D22F.dip.t-dialin.net [217.226.210.47]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 2B596844077; Wed, 7 Jul 2010 14:56:38 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BE2A150E4; Wed, 7 Jul 2010 14:56:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1278507394; bh=eAFaahzV8lolgg+EjifTMv/PazE/TKNlmejTo+9TrT4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=n2mqZfNDtST4e/aapu+cmwiWO7PqTzFBmqt0EBY3nt95Pz/VzWzO6aqWCKllFdyUU EuaUIEMpvtprIdI3LttNHaj2gfnD6W1uF3/u5DSpjeKP1KLEDW+6sKzzSgEwsZGgjo 5DaYVVWqXAh2dKiIfjk2zepsiVUzu35+6YWzi+ezqZSpnBhHGHwFnvJVcwHTs69axW MfOqEeD3PXj84m/MSkL+UPRJVwlAwOpphu9F5DweCZqtIiZwBj4uBnSIrVCHXoq04H C+9y9RNS3nxbb0dc0a4NQ+BRRO1UuM6G1fcXxbpxjTQiicFcl1HgeGp89o0rImz4TF gka5V4jZ4hi/A== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o67CuYeJ011155; Wed, 7 Jul 2010 14:56:34 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 07 Jul 2010 14:56:34 +0200 Message-ID: <20100707145634.13925yt8ztdkz4is@webmail.leidinger.net> Date: Wed, 07 Jul 2010 14:56:34 +0200 From: Alexander Leidinger To: "M. Warner Losh" References: <20100706.174919.29649800801850.imp@bsdimp.com> In-Reply-To: <20100706.174919.29649800801850.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 2B596844077.A6AB1 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1279112199.06007@8UfKAkjK4mvCnrBcDx9rNQ X-EBL-Spam-Status: No 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 13:13:11 -0000 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. > 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. Bye, Alexander. -- It is impossible to defend perfectly against the attack of those who want to die. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 13:19:32 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8A1D106566B for ; Wed, 7 Jul 2010 13:19:32 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC598FC0A for ; Wed, 7 Jul 2010 13:19:32 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id CFC9F582C9 for ; Wed, 7 Jul 2010 08:19:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 44zw0946ywgM for ; Wed, 7 Jul 2010 08:19:31 -0500 (CDT) Received: from wanderer.tachypleus.net (adsl-76-208-69-179.dsl.mdsnwi.sbcglobal.net [76.208.69.179]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 81E33582C5 for ; Wed, 7 Jul 2010 08:19:31 -0500 (CDT) Message-ID: <4C347EE2.6080301@freebsd.org> Date: Wed, 07 Jul 2010 08:19:30 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100627 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20100706.174919.29649800801850.imp@bsdimp.com> In-Reply-To: <20100706.174919.29649800801850.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 13:19:32 -0000 On 07/06/10 18:49, M. Warner Losh wrote: > 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. > > 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". > It mostly seems to be used to remove things from /usr/include/machine, in which case it should also probably be TARGET, not TARGET_ARCH or TARGET_CPUARCH. -Nathan From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 14:48:00 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 9387D106566B for ; Wed, 7 Jul 2010 14:48:00 +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 262018FC26 for ; Wed, 7 Jul 2010 14:48:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o67Efwxp031865; Wed, 7 Jul 2010 08:41:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 07 Jul 2010 08:42:13 -0600 (MDT) Message-Id: <20100707.084213.353672579433544368.imp@bsdimp.com> To: Alexander@leidinger.net From: "M. Warner Losh" In-Reply-To: <20100707145634.13925yt8ztdkz4is@webmail.leidinger.net> References: <20100706.174919.29649800801850.imp@bsdimp.com> <20100707145634.13925yt8ztdkz4is@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 14:48:00 -0000 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. : > 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 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 From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 14:59:30 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B082A1065674 for ; Wed, 7 Jul 2010 14:59:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 773FE8FC17 for ; Wed, 7 Jul 2010 14:59:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1A39346B53 for ; Wed, 7 Jul 2010 10:59:30 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BA8DB8A03C for ; Wed, 7 Jul 2010 10:59:28 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 7 Jul 2010 10:12:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007071012.10206.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 07 Jul 2010 10:59:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Subject: Re: Cleaning up the CDDL import mess 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 14:59:30 -0000 On Monday, July 05, 2010 2:56:19 pm Rui Paulo wrote: > Right now we have four locations for CDDL import code: > > 1) vendor-cddl > 2) vendor/opensolaris > 3) vendor-sys/opensolaris > 4) and... HEAD itself. > > 1) vendor-cddl seems to be the first DTrace import and it's probably ready to be svn rm'ed because it creates too much confusion. The first thing someone who is looking at CDDL source is to probably look at vendor-cddl and I would like to avoid this. > But I don't know what will happen to the mergeinfo in head/cddl and head/sys/cddl (I think no harm will be done). > > 2 and 3) These are the correct locations IMHO and I know that jhb did move the code here in the past. > > 4) The ZFS code lives in HEAD, unfortunately. I thought the policy was to have a vendor import for vendor code so that we could merge *from* upstream more easily. I was told that this is being done to some extent in Perforce, but I don't know how acceptable this to the community. > > I need to import some DTrace code into 2 and 3, but I would like to svn rm vendor-cddl, if there are no objections. I think it should be fine to remove vendor-cddl. It would be useful to get the ZFS bits the correspond to our current ZFS bits committed into the vendor/opensolaris and vendor-sys/opensolaris trees and to sync up the merge info. However, one caveat with the ZFS bits is that we may want to keep ZFS and DTrace independent in that you don't want to have to force an upgrade of ZFS just to get newer DTrace bits and vice versa. In that sense, it may make sense to store the vendor DTrace and ZFS bits in separate trees. I'm not sure how practical that is (e.g. if they share common code). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 15:20:50 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FCAE1065676; Wed, 7 Jul 2010 15:20:50 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8042D8FC14; Wed, 7 Jul 2010 15:20:45 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id DAF8F1CF181; Wed, 7 Jul 2010 10:20:43 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id 7X0A0C08OQMU; Wed, 07 Jul 2010 10:20:41 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <201007071012.10206.jhb@freebsd.org> Date: Wed, 7 Jul 2010 16:20:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <04991DD5-F22D-4F4E-8E33-89DE566DFB30@FreeBSD.org> References: <201007071012.10206.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1081) Cc: freebsd-arch@freebsd.org Subject: Re: Cleaning up the CDDL import mess 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 15:20:50 -0000 On 7 Jul 2010, at 15:12, John Baldwin wrote: > I think it should be fine to remove vendor-cddl. It would be useful = to get > the ZFS bits the correspond to our current ZFS bits committed into the > vendor/opensolaris and vendor-sys/opensolaris trees and to sync up the = merge > info. >=20 > However, one caveat with the ZFS bits is that we may want to keep ZFS = and > DTrace independent in that you don't want to have to force an upgrade = of ZFS=20 > just to get newer DTrace bits and vice versa. In that sense, it may = make=20 > sense to store the vendor DTrace and ZFS bits in separate trees. I'm = not sure=20 > how practical that is (e.g. if they share common code). ZFS doesn't use any code in the vendor area. It's all imported "by hand" = in Perforce and then merged to HEAD, "by hand" too. So, unless the ZFS = team wants to start using real vendor imports instead of what they have = been doing, there's no such problem as "common code". If you are advocating that we should do a vendor import of ZFS, I agree. = If you're just saying that you want to fix the mergeinfo in ZFS, that is = not going to be enough because most of the ZFS code is in HEAD, not in = the vendor branch. Regarding DTrace, a lot of it has been copied to HEAD without a proper = vendor import, but some of bits were vendor imported, as you may know. What I really wanted to see for DTrace was a real vendor import of all = the necessary DTrace code, merged all to cddl/contrib and then we would = edit cddl/contrib to port DTrace to FreeBSD (since DTrace is already = ported, we would just copy the stuff outside cddl/contrib to = cddl/contrib). As an example, consider the DTrace module. We have sys/cddl/contrib with = several headers and whatnot, but the real code lives in = sys/cddl/dev/dtrace. This is not how we have been doing vendor branches = with other external contributions.=20 Of course it may be too late now. Regards, -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 15:35:44 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 8CB38106566B for ; Wed, 7 Jul 2010 15:35:44 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC818FC1B for ; Wed, 7 Jul 2010 15:35:43 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2D22F.dip.t-dialin.net [217.226.210.47]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id CEC8684407A; Wed, 7 Jul 2010 17:35:39 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id AB67650F5; Wed, 7 Jul 2010 17:35:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1278516936; bh=C0plNL+GUuf2TmTbQZks+9/fJU71zXDtMWX3EGv6bJg=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=a+leRgJlQ0egjyXc5Ax1HNkRkLVoGUvS2vIlVM2+GHcLgGpi//NF1hCOobwID7WQE wa2BVsbJxffncrXmYHnuJwbMVZW4v+NV7FWuXLvq3sTqH7u70FIKKHL9jw3ZgZxLK9 Ae3pQ5TI/ilGj3aXXU8zdCbD/01skqa+SjDod3XfV6KHCAQHCBC8ytIrizy7FixSp8 kxDI74xc5pQnlsTY03Vst+eStonbYOkUpBzUreWaDGc33HaP76zUP/NLQbpYcYB5BU 07QF+H2sp/fTv4ZcuYYKWARnL0/1PPlMkHIRtTAslcHVoSSa+DcRt1lC+D1LCKBSPu UrL6MTJ7pURLw== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o67FZaZm047625; Wed, 7 Jul 2010 17:35:36 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 07 Jul 2010 17:35:36 +0200 Message-ID: <20100707173536.14541wa0krsmogcg@webmail.leidinger.net> Date: Wed, 07 Jul 2010 17:35:36 +0200 From: Alexander Leidinger To: "M. Warner Losh" References: <20100706.174919.29649800801850.imp@bsdimp.com> <20100707145634.13925yt8ztdkz4is@webmail.leidinger.net> <20100707.084213.353672579433544368.imp@bsdimp.com> In-Reply-To: <20100707.084213.353672579433544368.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: CEC8684407A.A6D7C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1279121741.3705@q6q/5kc8PwIOR6NRTXNZIw X-EBL-Spam-Status: No 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 15:35:44 -0000 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... > : > 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. 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 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 : : From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 21:42:53 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED0BD1065677; Wed, 7 Jul 2010 21:42:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C033B8FC0C; Wed, 7 Jul 2010 21:42:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7462B46B95; Wed, 7 Jul 2010 17:42:52 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 836948A04F; Wed, 7 Jul 2010 17:42:51 -0400 (EDT) From: John Baldwin To: Rui Paulo Date: Wed, 7 Jul 2010 16:45:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201007071012.10206.jhb@freebsd.org> <04991DD5-F22D-4F4E-8E33-89DE566DFB30@FreeBSD.org> In-Reply-To: <04991DD5-F22D-4F4E-8E33-89DE566DFB30@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007071645.50494.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 07 Jul 2010 17:42:51 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Cleaning up the CDDL import mess 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 21:42:53 -0000 On Wednesday, July 07, 2010 11:20:38 am Rui Paulo wrote: > On 7 Jul 2010, at 15:12, John Baldwin wrote: > > > I think it should be fine to remove vendor-cddl. It would be useful to get > > the ZFS bits the correspond to our current ZFS bits committed into the > > vendor/opensolaris and vendor-sys/opensolaris trees and to sync up the merge > > info. > > > > However, one caveat with the ZFS bits is that we may want to keep ZFS and > > DTrace independent in that you don't want to have to force an upgrade of ZFS > > just to get newer DTrace bits and vice versa. In that sense, it may make > > sense to store the vendor DTrace and ZFS bits in separate trees. I'm not sure > > how practical that is (e.g. if they share common code). > > ZFS doesn't use any code in the vendor area. It's all imported "by hand" in Perforce and then merged to HEAD, "by hand" too. So, unless the ZFS team wants to start using real vendor imports instead of what they have been doing, there's no such problem as "common code". > > If you are advocating that we should do a vendor import of ZFS, I agree. If you're just saying that you want to fix the mergeinfo in ZFS, that is not going to be enough because most of the ZFS code is in HEAD, not in the vendor branch. Yes, we would have to do a vendor import of ZFS and then bootstrap the mergeinfo. I am just worried that if both ZFS and DTrace live under vendor/opensolaris there may be weird issues with upgrading one part of the vendor tree and not the other, but perhaps it will work ok. > Regarding DTrace, a lot of it has been copied to HEAD without a proper vendor import, but some of bits were vendor imported, as you may know. > > What I really wanted to see for DTrace was a real vendor import of all the necessary DTrace code, merged all to cddl/contrib and then we would edit cddl/contrib to port DTrace to FreeBSD (since DTrace is already ported, we would just copy the stuff outside cddl/contrib to cddl/contrib). > As an example, consider the DTrace module. We have sys/cddl/contrib with several headers and whatnot, but the real code lives in sys/cddl/dev/dtrace. This is not how we have been doing vendor branches with other external contributions. Yes, I have noticed this as well. It should be fixed as you say that we copy the FreeBSD changes in head to the original path in the vendor source so we can do meaningful merges in the future and generate useful diffs relative to the vendor sources. I think it should be fine to fix this by simply copying our version of the file over and committing it as a change in head. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 22:16:34 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93DFB106564A for ; Wed, 7 Jul 2010 22:16:34 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 535A28FC0A for ; Wed, 7 Jul 2010 22:16:34 +0000 (UTC) Received: by vws6 with SMTP id 6so264657vws.13 for ; Wed, 07 Jul 2010 15:16:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.204 with SMTP id kh12mr4429395qcb.191.1278539297219; Wed, 07 Jul 2010 14:48:17 -0700 (PDT) Received: by 10.229.238.10 with HTTP; Wed, 7 Jul 2010 14:48:17 -0700 (PDT) In-Reply-To: <201007071645.50494.jhb@freebsd.org> References: <201007071012.10206.jhb@freebsd.org> <04991DD5-F22D-4F4E-8E33-89DE566DFB30@FreeBSD.org> <201007071645.50494.jhb@freebsd.org> Date: Wed, 7 Jul 2010 14:48:17 -0700 Message-ID: From: Peter Wemm To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch Subject: Re: Cleaning up the CDDL import mess 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 22:16:34 -0000 On Wed, Jul 7, 2010 at 1:45 PM, John Baldwin wrote: > On Wednesday, July 07, 2010 11:20:38 am Rui Paulo wrote: >> On 7 Jul 2010, at 15:12, John Baldwin wrote: >> >> > I think it should be fine to remove vendor-cddl. =A0It would be useful= to > get >> > the ZFS bits the correspond to our current ZFS bits committed into the >> > vendor/opensolaris and vendor-sys/opensolaris trees and to sync up the > merge >> > info. >> > >> > However, one caveat with the ZFS bits is that we may want to keep ZFS = and >> > DTrace independent in that you don't want to have to force an upgrade = of > ZFS >> > just to get newer DTrace bits and vice versa. =A0In that sense, it may= make >> > sense to store the vendor DTrace and ZFS bits in separate trees. =A0I'= m not > sure >> > how practical that is (e.g. if they share common code). >> >> ZFS doesn't use any code in the vendor area. It's all imported "by hand"= in > Perforce and then merged to HEAD, "by hand" too. So, unless the ZFS team = wants > to start using real vendor imports instead of what they have been doing, > there's no such problem as "common code". >> >> If you are advocating that we should do a vendor import of ZFS, I agree.= If > you're just saying that you want to fix the mergeinfo in ZFS, that is not > going to be enough because most of the ZFS code is in HEAD, not in the ve= ndor > branch. > > Yes, we would have to do a vendor import of ZFS and then bootstrap the > mergeinfo. =A0I am just worried that if both ZFS and DTrace live under > vendor/opensolaris there may be weird issues with upgrading one part of t= he > vendor tree and not the other, but perhaps it will work ok. > >> Regarding DTrace, a lot of it has been copied to HEAD without a proper > vendor import, but some of bits were vendor imported, as you may know. >> >> What I really wanted to see for DTrace was a real vendor import of all t= he > necessary DTrace code, merged all to cddl/contrib and then we would edit > cddl/contrib to port DTrace to FreeBSD (since DTrace is already ported, w= e > would just copy the stuff outside cddl/contrib to cddl/contrib). >> As an example, consider the DTrace module. We have sys/cddl/contrib with > several headers and whatnot, but the real code lives in sys/cddl/dev/dtra= ce. > This is not how we have been doing vendor branches with other external > contributions. > > Yes, I have noticed this as well. =A0It should be fixed as you say that w= e copy > the FreeBSD changes in head to the original path in the vendor source so = we > can do meaningful merges in the future and generate useful diffs relative= to > the vendor sources. =A0I think it should be fine to fix this by simply co= pying > our version of the file over and committing it as a change in head. > > -- > John Baldwin Much of this stuff is the way it is because there was no practical way to force cvs2svn into doing it a more convenient way. It needed 1:1 mappings between cvspath:branch<->namespace, so things that got 'cvs import'ed inside src/sys couldn't be coerced into sharing a common destination with other cvspath:branch trees. By all means, move it to where it does the most good. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell