From owner-freebsd-arch@FreeBSD.ORG Sun Jun 21 19:42:36 2015 Return-Path: Delivered-To: freebsd-arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AF89E41; Sun, 21 Jun 2015 19:42:36 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E271FB6; Sun, 21 Jun 2015 19:42:35 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-f79296d000000622-4d-558712763337 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 01.92.01570.67217855; Sun, 21 Jun 2015 15:37:26 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t5LJbP7L007930; Sun, 21 Jun 2015 15:37:26 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5LJbOXJ023941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Jun 2015 15:37:25 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t5LJbN0n002455; Sun, 21 Jun 2015 15:37:23 -0400 (EDT) Date: Sun, 21 Jun 2015 15:37:23 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Adrian Chadd cc: "freebsd-arch@freebsd.org" Subject: Re: [rfc] add MK_TELNET_SSL as a build option In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrVsm1B5qsOaqmsXerduZLGZPn8bk wOQx49N8lgDGKC6blNSczLLUIn27BK6Mw9/XsBRsY67YsmcbcwPjdaYuRk4OCQETidc7HzJD 2GISF+6tZ+ti5OIQEljMJLH/wFF2CGcjo8TBpVuYIJxDTBI3fy6EchoYJRasvcII0s8ioC2x 8HEHmM0moCbxeG8zK8RcRYnNpyYB7eDgEBFQleic7wwSZhawlFi64DxYubCAmUTrvClgJ3EK BEo0PZzMBFLOK+Ao8WuTNEhYSCBAYsnUHjYQW1RAR2L1/iksIDavgKDEyZlPWCBGakksn76N ZQKj0CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGurlZpbopaaUbmIEh60kzw7G NweVDjEKcDAq8fDeYGgLFWJNLCuuzD3EKMnBpCTKe4G/PVSILyk/pTIjsTgjvqg0J7X4EKME B7OSCC8LB1CONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCd6ogUKNg UWp6akVaZk4JQpqJgxNkOA/QcHmQGt7igsTc4sx0iPwpRl2OBT9ur2USYsnLz0uVEue9LQBU JABSlFGaBzcHlm5eMYoDvSXM6wsyigeYquAmvQJawgS05EtuG8iSkkSElFQDY2OSnGbho0X+ HexyKzJn/3oTsTd1574VP1R0zq3ca8B65PXWy/8S9a4t3NUbXHR58w4z47fPWqrjMuJt3jxm ks4tNOlft+PerxP/j7vVu1zjv/9p6emqGx2zg3fPtjl++eXtLZzJLYaPzl/0/XPXpOHkd7fz 1roLHpzg+RHZcO5ReP7FL65bNm5RYinOSDTUYi4qTgQAUU/2rBIDAAA= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 19:42:36 -0000 On Sat, 13 Jun 2015, Adrian Chadd wrote: > Hi, > > The wifi builds have a need for building telnet/telnetd without > ssl/kerberos in order to meet size constraints and to allow them to be > crunch'ed. Something of a tangent, but the kerberos support in telnet is limited to single-DES, i.e., breakable for $50 or so. I, for one, would be fine seeing it just get removed entirely. (I have no data about telnet/ssl.) -Ben From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 07:38:22 2015 Return-Path: Delivered-To: freebsd-arch@nevdull.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA4BD53C for ; Mon, 22 Jun 2015 07:38:22 +0000 (UTC) (envelope-from uebayasi@gmail.com) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97AE8BF8; Mon, 22 Jun 2015 07:38:22 +0000 (UTC) (envelope-from uebayasi@gmail.com) Received: by qgal13 with SMTP id l13so49962476qga.3; Mon, 22 Jun 2015 00:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GuOxxyQOYIjicsxrhDVTjXOJvE55z62hBX6dddjkuZk=; b=nCrBJSBpNJUFI1CbFVyCxh/tIUQSsM10n3mbMyTmxLtDDwdU3KcKHo4mpPff7wFf4S rK02UJar9VXlYRlOJylmVbBmm34NXu3GStP+XtYI/XdNUBPEsAIq0weLZYXJCWdCE/on dafTM34mSqs6U5+/L4GJCL84F8KYnZNRG+j8V28npD+hG34cHIQ+M1FfOJIrmdqvUB2S lTBFXHCwifWW4BuxrZnYPci2SGtK9ZiuOzorIvl2h12BvunpZuKxXkPH5vPpGWh59TgK XQqxtGug9HaK+FkGwGiZf3gTv1ALgdZQc9HW+T2S6gcrSUGzO7Llw07Qz+zZb0v24gvL 2yMA== MIME-Version: 1.0 X-Received: by 10.140.135.80 with SMTP id 77mr38473744qhh.8.1434958701617; Mon, 22 Jun 2015 00:38:21 -0700 (PDT) Received: by 10.96.108.70 with HTTP; Mon, 22 Jun 2015 00:38:21 -0700 (PDT) In-Reply-To: <19927.1434727307@chaos> References: <19927.1434727307@chaos> Date: Mon, 22 Jun 2015 16:38:21 +0900 Message-ID: Subject: Re: stale .depend during -HEAD builds? From: Masao Uebayashi To: "Simon J. Gerraty" Cc: Adrian Chadd , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 07:38:22 -0000 On Sat, Jun 20, 2015 at 12:21 AM, Simon J. Gerraty wrote: > Adrian Chadd wrote: >> Is this a fallout from the meta mode changes? > > Without more detail, its hard to be certain. > >> make[4]: /home/adrian/work/freebsd/head-embedded-2/src/../obj/mips//mips.mips/usr/home/adrian/work/freebsd/head-embedded-2/src/usr.sbin/praliases/.depend, >> 78: ignoring stale .depend for >> /home/adrian/work/freebsd/head-embedded-2/src/../obj/mips//mips.mips/usr/home/adrian/work/freebsd/head-embedded-2/src/lib/libsmdb/libsmutil.a >> > > Is that what your objdirs normally look like? > > The message from make is standard bmake behavior. > An unresolved and unresolvable dependency learned from .depend > is ignored, in case it is just stale data. > If it really is needed the build will fail anyway, but in 90% of cases > it is just stale data and the build sails happily on. I wish make(1) had a flag, like cc's warning level, that controls strictness, and failed when a stale depend is found. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 16:21:43 2015 Return-Path: Delivered-To: freebsd-arch@nevdull.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76CA74C5 for ; Mon, 22 Jun 2015 16:21:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DB05A81 for ; Mon, 22 Jun 2015 16:21:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iebmu5 with SMTP id mu5so118528091ieb.1 for ; Mon, 22 Jun 2015 09:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5uA0EL3fctpIIGEPwN8oGRl5fNLDmYrriKQP5K5CUaM=; b=Mg3gx7HkRpA0Wcsnyhp2pHRxHcEELgM5QsMBntLun71dfr4ZVI35+/QgSh6kfxmW3H Au6XPr0HSovX3bIc/pjzjACojOU9u7nTHyifRL7uMHaggcw9X3GI7MgsInZdrRI3t8Mj yySu5cJ+CXQzoXFLo+3WG0fHI90uqbMuXwKUUKtTxZhp4laJeYv7JxDJyQmoxRq01vQ3 tQNUwf/zIiskThwWlfnZ9ofUeBrTHHuwwHyAXDMLPOAsuoictAKfBpIyc6A9/oD+zPrp l8hAoiNUfcrMKREiiykErFShIKe2XOfXjqNXypHxgvJYiZ0n4vS0udcjV5Zc7cQlCqCe iYXA== MIME-Version: 1.0 X-Received: by 10.43.163.129 with SMTP id mo1mr26256819icc.61.1434990102458; Mon, 22 Jun 2015 09:21:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Mon, 22 Jun 2015 09:21:42 -0700 (PDT) In-Reply-To: References: <19927.1434727307@chaos> Date: Mon, 22 Jun 2015 12:21:42 -0400 X-Google-Sender-Auth: xxT05Q0E8qL6OgCbTpaTEwKbFUA Message-ID: Subject: Re: stale .depend during -HEAD builds? From: Adrian Chadd To: Masao Uebayashi Cc: "Simon J. Gerraty" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 16:21:43 -0000 That's like, 30 lines of C all up, including modifying usage(). You should totally add it. -a On 22 June 2015 at 03:38, Masao Uebayashi wrote: > On Sat, Jun 20, 2015 at 12:21 AM, Simon J. Gerraty wrote: >> Adrian Chadd wrote: >>> Is this a fallout from the meta mode changes? >> >> Without more detail, its hard to be certain. >> >>> make[4]: /home/adrian/work/freebsd/head-embedded-2/src/../obj/mips//mips.mips/usr/home/adrian/work/freebsd/head-embedded-2/src/usr.sbin/praliases/.depend, >>> 78: ignoring stale .depend for >>> /home/adrian/work/freebsd/head-embedded-2/src/../obj/mips//mips.mips/usr/home/adrian/work/freebsd/head-embedded-2/src/lib/libsmdb/libsmutil.a >>> >> >> Is that what your objdirs normally look like? >> >> The message from make is standard bmake behavior. >> An unresolved and unresolvable dependency learned from .depend >> is ignored, in case it is just stale data. >> If it really is needed the build will fail anyway, but in 90% of cases >> it is just stale data and the build sails happily on. > > I wish make(1) had a flag, like cc's warning level, that controls > strictness, and failed when a stale depend is found. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 22 18:29:22 2015 Return-Path: Delivered-To: freebsd-arch@nevdull.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DBC5E0E for ; Mon, 22 Jun 2015 18:29:22 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0140.outbound.protection.outlook.com [157.56.111.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5E96266; Mon, 22 Jun 2015 18:29:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from SN1PR0501CA0015.namprd05.prod.outlook.com (10.163.126.153) by BLUPR05MB771.namprd05.prod.outlook.com (10.141.209.26) with Microsoft SMTP Server (TLS) id 15.1.195.15; Mon, 22 Jun 2015 15:53:34 +0000 Received: from BN1AFFO11FD054.protection.gbl (2a01:111:f400:7c10::107) by SN1PR0501CA0015.outlook.office365.com (2a01:111:e400:52fe::25) with Microsoft SMTP Server (TLS) id 15.1.195.15 via Frontend Transport; Mon, 22 Jun 2015 15:53:34 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1AFFO11FD054.mail.protection.outlook.com (10.58.53.69) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Mon, 22 Jun 2015 15:53:33 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 22 Jun 2015 08:52:05 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t5MFq4D75182; Mon, 22 Jun 2015 08:52:05 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id BCCAE580AA; Mon, 22 Jun 2015 08:52:04 -0700 (PDT) To: Masao Uebayashi CC: Adrian Chadd , "freebsd-arch@freebsd.org" Subject: Re: stale .depend during -HEAD builds? In-Reply-To: References: <19927.1434727307@chaos> Comments: In-reply-to: Masao Uebayashi message dated "Mon, 22 Jun 2015 16:38:21 +0900." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Mon, 22 Jun 2015 08:52:04 -0700 Message-ID: <15953.1434988324@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD054; 1:ac39Mn/TGI3eGb++a9GXgK2t6hLvyKK99jx5/F+taN34rWygc1+yxszl2jg9tl5xt7htfbbqeVg08wpDikehHeUAbrV/GzZhhA8zG7wziAPaYif/JakdUWLjzt5mjUlB+E66GpN7dn2YaTRdxxxvs5MxowbAM6pxO0oK69KfxwUBOcklsJhLQhb+0SMsMWyUfJdt8pHKGmxKQYbmHZeYEOlKO1DEVPlteObYcA5ERbO6K0oveQHQ6W7gdkSLLqyaf++erskCvq6iYiaS9FRVvgSs2LXlZBKfRlr54m1cOtTgcuRPaXgzX+TVMtALMBmmr0ZQy3uyM1m3+UoMwCx0vw== X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(51704005)(189002)(24454002)(52314003)(199003)(50986999)(76176999)(19580405001)(62966003)(87936001)(19580395003)(117636001)(46102003)(48376002)(47776003)(77156002)(6806004)(1411001)(50226001)(86362001)(50466002)(33716001)(92566002)(105596002)(189998001)(2950100001)(97736004)(5001960100002)(77096005)(110136002)(68736005)(106466001)(57986006)(76506005)(5001830100001)(5001860100001)(4001540100001)(142923001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB771; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB771; 2:VnuaPQbeXiNl8NEwnXMcye356VEAbtuJdf7tqH4C1StdAVc2R7SZ+M70dz+Mk6QY; 3:Zh8ws8IXlKB8Zb+xCIvYPdDaD+PEn6q/Ou+R0FrlFQAiHC4aw45PWDaWT6a+VJbXinqtHPkB7pm/GDX3gj5bd1zXiw24ut0vp3JxHJ/STabguqgek9tAEPEucSh3Gz277GlaJ3qidXBW+1/28UJHxo3GcQyiYXzNwYXoDZPPUAvtMVp7qRegobXDgIAwtA1WHQzZ2c6jmy+Oy3TeOFk6TaBkXXB/omXAlPRTpcd/jI8=; 20:HSpidFWmWzNZnljXTU2A/Us4ji24SqH4IaPesr9EUO0XchSMYF3sHP/jqpPkmdWW/3v1wzeOmhS1OYZXDVg7WRoMzQvs76UxtdEmeGW+NBEwttDEyJ7CsbwpmLDxBbVzqrPvgbBiIJxwQvu+XCF/DAniBxc6sDZO0Jhhl5ND2VOIpMOULB2jhP8M36mjmWZHC13LjrYGu+LmWJ7zEtIFE4CWyC2tDfdwohAzSZUxGnV15tQEizjlhXB/oJAPyZIPh0oEaivlHKN0OO01c3kspFO/O65xEcdzTCH2IsdJRw6mnYaQsWvb4QaVB9TUjxqlSzo1nJWHZzYcxwskJwJp2M6zWiPEc2ozR+pR/1PmO5fulGrHwr1KdaWK8rz1+Anfcqat/MuE4nH9L99BzFMQXboTY+Qez7UKBCV8S8rXnjbOWQs2CXpnTbN2D2StW02QLOTJNUDBnwEGurVfASRyHHXD3Se6/xqm5n/iCvF+tCfJ8HHh1DsmN9PDeTUcqpqv X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB771; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB771; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB771; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB771; 4:IpTT9ynTe8qbDoHG7Wdprq9zRxMP00tJmcHXv9rw4AMsVF+HJ4caMuYW3tj0VHdTpvI9bPTSkoe6Uzi2knPPVuNNrhPvh6f6fMillawoDVlGr3M6ln2anvLZSxyf4cLU7YUzHXwt/Cx8vyaA//xS/DZLh667/3rf63h1wFc1/wVO4hCRtdl9JvjRTCsYceKR+u9mFeQg8LaZtS8B8xQSWUTDrtCllWGAlkmGx1G977rGsM0e2RKviOEZOZwbUNoTR4QHk09K+ApVqf6EPHf41H9MmTUKAIcrtQ7kHabZXRI= X-Forefront-PRVS: 06157D541C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB771; 23:YEDU0fQY6ae3HCkL2beyBHc0WtVYmDHbjCi5idCqCM?= =?us-ascii?Q?/bhsUGu89bFP3CSqZWHB6BMTpNa1q3ilmNXWhoS+aX3RzydZmQPWh9nZSFAJ?= =?us-ascii?Q?Roo/3XHSHpqdU4tYHKb9UXWRIk3XgaouyI3kDC+bytnqgx1tyvOvVeqfffjn?= =?us-ascii?Q?PFLEVSBbv4P9zhkE5MwNNwWqa8TrwM/cnK3DLzDt7GeeDWnRxXfcldZZQo2b?= =?us-ascii?Q?M9coiJraCedHQsBIKDEmx7D8FgRKGQgKUXb26KeQ+0AZH2NWr/6GEnAFDXtQ?= =?us-ascii?Q?r3c3F/6BC8jSUTqfbLTvh3Wj94rRBwenW/PpB6NnCi9Dp+hFGPgXbAmvP4oS?= =?us-ascii?Q?GyXQPejVcRPbaJ93c/CxkwE+Kol1wRrxLV3Khubmm6aklCLrPPZ5zlX0YGvi?= =?us-ascii?Q?ESc0rZLbLW16cP6zRN6GJA29cW2K/AV89v1Xo9BTUgfxg8IpE1/zOEtLSpns?= =?us-ascii?Q?VcOh0zToAZ7sgpX5eF/NlfDEjFTZr5jOPJt5/+cGx6ec/uVXgMDCkX6z+tuY?= =?us-ascii?Q?g4ztmNewNQMES7CJ9IRMS8CCf1dHIETgE75TeCLgX36XvA3bZKTIL7D3T+/Z?= =?us-ascii?Q?m6acGehAAfvFSdCXPXOVKS1pVuRdanDSIzwBnNNdpmCGbzm/ddZ5YC9751vv?= =?us-ascii?Q?s7VhiN2+PQYXXOj6xnXfOXIQceU95x6delkYfpBgYeuKJSmfeyajOlxmB2Ve?= =?us-ascii?Q?vesqRNDsgHDEwHOjqgyvSqZrOW0usDdTJX762dRSFqpS/TnwaLY4VyLsNK4i?= =?us-ascii?Q?nJyUZnGUSfKWYMD+T67q+BM4g2elBjay0x/anTdu8am6SA+4RVnmQPcKu8wD?= =?us-ascii?Q?aBiPBQGu2TF09Sk+YYp/ycj2IgqAJRTvRH5yOgjQBuw9FhLtXbvre0B1eKM1?= =?us-ascii?Q?W2mMYvKFkEGJxRrv3tts3uPvRlWdFez1me2y1E2vgmivO6j1TpXR2jG4nunr?= =?us-ascii?Q?Mv2kgoL1W3Iel9mZ2fgqxy2WWVJSk8AzwDwhd1gIVv8BIPXAuTdgKjQceGt/?= =?us-ascii?Q?tuZ5h7Bn93ZEYxna8Q6ENohcfuIlEqdyEecdOVVuPWR8d7IVpLpI79uheD85?= =?us-ascii?Q?rf6AXP6MSF7OdOGcGhZh8Wj3ld9oej7UyVM1BAzF5GkhvlVg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB771; 5:AoeoxTB8sZE4QecQ2buNgnn4eDiBKJ7N/BUGagWj55PN4HL5hH5r0zLgUrDEpxrNi2IU9fqIarS3UDx3I2Hu9/X3f1htSkUsMOzsM5X44apyZ2SN89qU66AoGUhx+6CrAyWSYBTkSXAI/dVje2mL+g==; 24:8GdaKXfK8Y3/Y+wGTX1H1+4dSn64GHb2LylorlmPS/l6JaYwS/xNEnVU7iB3q5lzGguLDdMrMbPoWje0S66PW7qwGtPr8g7kz9oPfJxrQ1g=; 20:vWCeIvwfekDUlZGzAlzWqf6UfU7fv8XnAz6Jm0l27PYcbYtwliGyKB7AdLJdQ9wRzlHpgukEaYw/L1y8YUX15A== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2015 15:53:33.8537 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[P-EMF03-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB771 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 18:29:22 -0000 Masao Uebayashi wrote: > > If it really is needed the build will fail anyway, but in 90% of cases > > it is just stale data and the build sails happily on. > > I wish make(1) had a flag, like cc's warning level, that controls > strictness, and failed when a stale depend is found. For this case that would force you to have to clean your tree every time someone moves/renames a header - very tedious. This particular behavior works very well in conjunction with autodep (whether via compiler flags like -M or other means) where the content of .depend actually relects the last build not the one being done. From owner-freebsd-arch@freebsd.org Thu Jun 25 00:49:58 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81BE89151D2 for ; Thu, 25 Jun 2015 00:49:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F9021BB1 for ; Thu, 25 Jun 2015 00:49:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbiq7 with SMTP id iq7so108816533igb.1 for ; Wed, 24 Jun 2015 17:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=TWmRsvKKWyqYAhQ6a3/q6/xbrrdtdKiTq2vbmgNvKqk=; b=lxpl3BBXYdFtSX3kvwcxJ76nazemM+KTaxO57d2Mf8FnWtNO6zGa/zDX1z4JB1zbXi zIHv5bmcg0rgoImhPUIsy0WUPBmzP3cC1IX35DZOhKbCead3kf2gsMGYddKZGDZD6mFC XWDU+JSFSULDhPslTf6qX4nG8MYwd1h0sQmjm3821qC/X0DZdSBdBw330TcSYnizWLYs DQLYhfMvovctcrMQ2BvD5oJHln6I5ItcqtE1a4fLJ5xE1RT8eGxIfJU1YAN7zWSuaOLB /BoTHegZV/tCT2IgwTlRZcutEjGlc1Ru+93rzJuC6pLjGkTbaXhVNkcj++RLWpzeIJll pqzA== MIME-Version: 1.0 X-Received: by 10.50.111.167 with SMTP id ij7mr599843igb.49.1435193397616; Wed, 24 Jun 2015 17:49:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Wed, 24 Jun 2015 17:49:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jun 2015 17:49:57 -0700 X-Google-Sender-Auth: AhhQ04kyCUuLMCSbQoCVMKoABo4 Message-ID: Subject: Re: CFT/CFR: NUMA policy branch From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 00:49:58 -0000 Hi, I've updated the NUMA branch again: https://github.com/freebsd/freebsd/compare/master...erikarn:local/adrian_numa_policy The main fixes: * (stas) Added short versions of options to numactl; * (stas, wblock, rpaulo) Documentation and code fixes during review; * (kib) updated the userland facing API to not include seq_t; * fixed up a couple of silly bugs that gcc-4.2 picked up; * fixed up compile issues on gcc-4.2. I've tested this on mips32, mips64, x86 non-NUMA (GENERIC) and NUMA hardware. kib@ has requested that this use the procctl() API rather than adding new syscalls. procctl() currently doesn't support P_LWPID (ie thread) based identifiers for any of its manipulation, so I'd have to go and add that. I think this is close to what I'd like to commit. I'd appreciate another review. Thanks, -adrian