From owner-freebsd-arch@freebsd.org Sun May 29 04:58:40 2016 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 66633B4F9DA for ; Sun, 29 May 2016 04:58:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 28048105F for ; Sun, 29 May 2016 04:58:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x241.google.com with SMTP id z123so3118511itg.2 for ; Sat, 28 May 2016 21:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=jnVNcJAHN8GZiP419r+fa3ctZomBbpVCNhVS/ClVkVo=; b=b5tJ9gsgACraVfuHS5zi0gQeH+vtAhaW00GkfSsUKBdUEn5+0PfyH52fhcwvXLanHj Fi3NVQzQCfUilxN6LPA1wupkhT9d+h/b2xUsgfKt9PeNpQkTKud6e9Pp5XbcTQBTpkn2 EXu+7OKNjCtc5fzZfH1HA2g9oTiFqNuhX8plx1XLCUIcK3BtblY1Jegirw1MLNxUWvEa B8YVn2FF0rpgrUtixOQzBjYpRFMBHJZy+gA8kTfO87FVBkPYDnm2qX4ASw0csFnQMbfj fyAeBI4JKRpkMcORS43bGE79F39rIzCYyn1LAc5a9PSHuCbOw14S4Zf/WOs7yQher/KF Lb/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jnVNcJAHN8GZiP419r+fa3ctZomBbpVCNhVS/ClVkVo=; b=E50TF+dCcwAOVb80tv6Ar9JLQI96dlvlCTP4U/YXHK5gpGDq9Hjjo4rSy9C6s8iKr+ fOCgRQ8bWso4TZY/frbYf2eZpLhnGB7sfNsXBJiDU8ZXdXokhpj9enRBtGXdcHpsej/r IAasoCXGbdNQ+5KX2sxuRISBsLtwlMcGWp0TE1jqWxGBP1On6Ag31mkJbvsrBiKAnBLF qUTc8IIr6dDR7G3t4lJc4zEKMpWUBLPb32kHS5tsY65Ad2YUnLw/FKHtD28GOzzHxauE eNxWkcTfbApub8CmbAekNu7rybwmDrniQbSvb94CjyRREQAZe06JbAptp9vprNcIObOr GazQ== X-Gm-Message-State: ALyK8tKwkBermzIPE6kC2YRlU7iy+KN+kZKWneXDktX9reizuLTyFXHYGrFLtUYa08GAlmrTCNK9P7LixNg5oQ== MIME-Version: 1.0 X-Received: by 10.36.78.67 with SMTP id r64mr3904622ita.72.1464497919482; Sat, 28 May 2016 21:58:39 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.75.68 with HTTP; Sat, 28 May 2016 21:58:39 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> References: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> Date: Sat, 28 May 2016 22:58:39 -0600 X-Google-Sender-Auth: LMno8R13gFvWvURJeBd7JYHNMgQ Message-ID: Subject: Re: [Build] Enabling automatic object directory creation From: Warner Losh To: Bryan Drewery Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 04:58:40 -0000 On Wed, May 25, 2016 at 12:20 PM, Bryan Drewery wrote: > For in-tree source builds only, I would like to make it so that 'make' > in a subdirectory would automatically create the object directory. This > would naturally extend to buildworld/buildkernel as well with some > tweaks. I already am nearly done with adding this in for buildworld and > was going to just make it happen since the 'make obj' tree-walk is a > waste of time. It is very error-prone to not automatically create an > object directory when building in a subdirectory as it may look for > files in the wrong place. So I would prefer to add it everywhere instead. > > What is the impact of this feature? > > Keep in mind this would *only affect in-tree builds, not ports*. > > We would need to move the 'default' MAKEOBJDIRPREFIX from > Makefile/Makefile.inc1 into share/mk/sys.mk. It would only be > overridable from environment and make argument, but also > /etc/src-env.conf (I think). This restriction is already in place. I > would have to move the assertion for this out of /Makefile and into > sys.mk. Now when I say sys.mk I really mean something like > src.sys.env.mk. which is hidden in a way to only impact in-tree builds. > > The feature is named 'WITH_AUTO_OBJ'. Enabling this by default means > that the only way to disable it is to add WITHOUT_AUTO_OBJ=yes to > environment, make argument or /etc/src-env.conf. I tend to think this is a good idea. However, more and more is moving into sys.mk, and it's been collecting lots of odd pebbles... > There are times when building in a directory without an object directoy > makes sense, but for the vast majority of people they likely have done a > buildworld already and are trying to build in a subdirectory to test > something further. If they pulled down new revisions then it is > possible that this new directory did not get a 'make obj' tree-walk. > > A side topic is changing the default MAKEOBJDIR such that it always uses > ${MAKEOBJDIRPREFIX}/${SRCTOP}/${TARGET}.${TARGET_ARCH}/${RELDIR}. Doing > this is far simpler if I can just use WITH_AUTO_OBJ everywhere. This is > discussed a bit in https://reviews.freebsd.org/D3711. It would give > directories such as: /usr/obj/usr/src/amd64.amd64/bin/sh. It would keep > all universe/cross-builds inside of /usr/obj/usr/src and allow more > easily cleaning up object trees with multiple checkouts. This object > tree pattern is what the DIRDEPS_BUILD uses as well and has been quite > handy. I would extend the DIRDEPS_BUILD 'make destroy' and 'make > destroy-arch', to the normal build, to cleanup the entire object tree > for the object directory and the specified target.target_arch respectively. I think this is a good idea. I've had hacks like this in the past because they are quite useful. though named differently and perhaps with different scopes. Warner From owner-freebsd-arch@freebsd.org Sun May 29 17:26:55 2016 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 B4818B54056 for ; Sun, 29 May 2016 17:26:55 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42DA61DD1; Sun, 29 May 2016 17:26:54 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dHZpvTC9Inpxg8JTYy1V5zqdBccW4BQLiLecUYIBhmU=; b=iU55FfGW/v8tIbkJncP+A2BoE8w6Km+O39mxuwG99xzO6VscGDWH/q2uUScnHvwjuo8EIEZUHUdyYFSV6XrX/xESpME4ssT8blMXrITSUOkIN7uI8e/smR3kPu9WFv9GfcDb1BxmXh+UcKREAcjDeSLTkvssWgw9hICTo542ogk= Received: from CY1PR05CA0015.namprd05.prod.outlook.com (10.166.186.153) by BN3PR05MB2449.namprd05.prod.outlook.com (10.167.3.14) with Microsoft SMTP Server (TLS) id 15.1.501.7; Sun, 29 May 2016 17:26:46 +0000 Received: from BN1AFFO11OLC004.protection.gbl (2a01:111:f400:7c10::172) by CY1PR05CA0015.outlook.office365.com (2a01:111:e400:c5a4::25) with Microsoft SMTP Server (TLS) id 15.1.506.9 via Frontend Transport; Sun, 29 May 2016 17:26:46 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; bsdimp.com; dkim=none (message not signed) header.d=none;bsdimp.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BN1AFFO11OLC004.mail.protection.outlook.com (10.58.53.75) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Sun, 29 May 2016 17:26:45 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 29 May 2016 10:26:44 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u4THQhJ22011; Sun, 29 May 2016 10:26:44 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D53EC385508; Sun, 29 May 2016 10:26:43 -0700 (PDT) To: Warner Losh CC: Bryan Drewery , "freebsd-arch@freebsd.org" , Subject: Re: [Build] Enabling automatic object directory creation In-Reply-To: References: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> Comments: In-reply-to: Warner Losh message dated "Sat, 28 May 2016 22:58:39 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96289.1464542803.1@kaos.jnpr.net> Date: Sun, 29 May 2016 10:26:43 -0700 Message-ID: <96291.1464542803@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(199003)(24454002)(9170700003)(9686002)(50986999)(11100500001)(76176999)(19580395003)(19580405001)(50466002)(92566002)(107886002)(4001430100002)(110136002)(5003600100002)(47776003)(50226002)(76506005)(53416004)(189998001)(5008740100001)(46406003)(106466001)(6806005)(2950100001)(105596002)(86362001)(2810700001)(77096005)(23726003)(586003)(1220700001)(117636001)(81166006)(8676002)(8936002)(4326007)(87936001)(2906002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2449; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11OLC004; 1:O10haw3TvlCtNe9QI8XNp3BYjyxpGS7bZKxiygUP+cIZyBDL2W9cxGDxMCu3T7N8yXXIxQW3KYfJN7kyAVPHZFGCcrBfKYfucWZ89zFNwCZPLdyZUPzAIAhG7/1LsNGHwVORbAg3HjpLcUbqrZ8n66E4TKAw+QawxAzQU+nWYhLz37uwWqkQiw+BkmZrDaGBC1yMotYodUcs1rVe1jCaXD8/T61xJCu86HB0BiwVI9jkZmHKF8Y8Zt1wHbfOm6zOJdcwnphhuqE/4N+yo78lmP+n2GXFLWvNXxKRJwRyDUukAHX1tf1VGRPcJb85iuKhSvBvVRHTycWnL0XraS8k2o/3FKe23EWb5hTHNpMgWFNTzZCYgFC+XYAapbEWX0xmJRwzFihRJw2jqQ3VttzMtkDFwG7BFYZkyad6yKzLyXxIFAThoK+YFGAh2OsS4RbaSD2IhtcZUE0d8o7YmS51igcWHl6FMYCsfbEhTEk5ghc= X-MS-Office365-Filtering-Correlation-Id: ea7052e9-6b68-43e4-99b5-08d387e668ca X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 2:9EkEeBPJoztjBoHIO0FWFWa/YXnpSEMdn6rzT1KUE3nltowK45Oygi65kFnoiAt3PEloHmS6vi69c8n26ZmyF3X3/TpsM3QNY7ggFZnv5wQLAcOal/ATSD39N7dMzuch5BWIJMkPpuyjt5/q9IBu1PEcvNE+phvf/IiucJQkuzGYlQ4g13C6KmWfA8lvrdK2; 3:b0DEq9BbFQZumXWCrgki6gDDhUv5a7z4xZ3BRHKRjLURNx9unACsQXy1kNn0Vqh3fwvgvdfIxDWGF3NqQdTgxrKVJCEsljPy1Mxj4jF9a8YGxfbyENAWJQpMIwR5WmRrIPfCCzcr0nxFwXwD0YcbUGMkkFXnw8hTCNDgpMZw2k0i2NUQhzIsg7/f+9wfA84TmG9L2XKhzT6y8nLYcaO6blBNiXjpsENqRfIY/kLHbkc=; 25:OlvCt9Y6BpevsWkgUjnlIzMoqMVYJH+qhXC85/HF02o2dg2/QsU6QJ82yt0WZjDtAgK42NXqO0F0bf8up+tyyKXhsZexibRO0uxL8OJWKbLr8+8rD7GyKwcmCiP0FmncY81aOeJx2hLRiUZ6MqP/p2RmZJqgWqCEVLpvammal4DZXcomWZMwqY6UkbsqvHOxErzcjtAjjk0RE0oxPrDPfp+bSw0VHzzM70h05iyeb2K6CM+hBVIowQAwFyIjafW58mxfY82AZYP5iJ60v4HBceg9hmge0WiDrs7JkPaReMapmDev2/S92n9mFlSmWPVky9+7+WlQEkSaTQEtGWID1XxU7Ur3JrEEEFiJURD9HuqjQh5v565Dr11vCseLOqcSPL966MDRUmRMPAltZfg2hBHZj8eyDBYOxA2H5VsbpKg= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2449; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 20:Y1oXR7pOBw3wZzlRqeAaRZAXpZVXc2eeP4yENzI3YmjCR8K2ZkfhXJ/O2cO19HDkcoA9/xseSNA2qnQS/92qgyVw7PAjuI1XKhZ2KcF14Uxhig5bpIR0o9Q2hOoca9oxjmZIiU/kqcRgVDgAQn1ngp+NrQCxiE6xLBivIQXPMEVbmsISdGh1xA+73xQ9b3PvgQ+pjCwCZeWNMJsR4nmdhDYB6ACoYSe1qhIHtd1ZWIsdOG2s60SlHx1Z6i1XD5k+aq7uKDoCj43w7nPN/yzubcpZr4Ysyxpn74a6CaK25kl0vUiDZ7qV6+t//ZXL3uSdPdZcDuth2b7v8QNa+W0rC2u9mfdVRveG7YqaB9a86c5Vvt/5X4bX6vplvc/Yfbly8JaGMjig6XGEH/dDgvlWhfN/3V9T8imMWkkZxgDAsgXv+q3+fO+BoHpVuWEBXfEuVCxItjfsTgaM0LbZyGp/Iuy931WkcUE7OKeHzhtfwZMEhBFusOg0E0zKk1/GKxU7 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13015025)(5005006)(13018025)(13024025)(13017025)(13023025)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2449; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2449; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 4:dZ+2fHsllUsydJAwFWcgJDXkhNHU7vbtPOQdoeArUMtVDT5X8dMeAs2QO1NN/Y3iBadwssFBfWu2LFXDBG8bGfWHwvqq8DzfICIToVZPgxGq8LcoEaBCHz7+sDfsGEYLP4j0Xc3bcI9EaNzZ91BRtbnPURWFnWgawQ3OqHGcNAWRQC/qTInRhseGw9CORcfK3NdvCHiPFyWfADoNV9LAkLQprWVrh6FGB0vYKRNrti7vszeVJELZXLwpxiUb8J6U//SiiR9+YUstF3ZfIgkDigUXYhcuUhSBkvUOSL80GZPRBaee3ebziWei6KwXiRI9oKX1HyIso/IJVsFF1WoM2zZuwHFpoJ5wvXgYvAoAwVTlURKnXuXRL3W9e4KsqfKNDMwaRUrSHXt33grL5cVTxS0XdjNye0Pl44BGNUffAVjm8Hvm2fYorjaV4samWcFodKJ98NWUgZKIw4jHABAjBrxiOMdUPfZQlNbQQB+MYMk= X-Forefront-PRVS: 0957AD37A0 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2449; 23:IgQAlB7UjS2ll5oj8JhIxccI8Dfgi/STG0pwG8HAh?= =?us-ascii?Q?/2b3KBnZIyBXDsqfJp9EfIjBojdpuVWbnMO/+LQ08/0lGzLMnnuNPJiuv6o1?= =?us-ascii?Q?hdm556V8T5KIplYE8ZSvgwvbQhWUS7tkha7UbJcl5nQ1wTMl6fVHNCnDb3kV?= =?us-ascii?Q?+pSlHNqC9r/1nM6B+BMuz5H1oDz36ihkwDtth0puMvVy6jixztlD+8y467oI?= =?us-ascii?Q?6UjvYLo2LDxk/lFnx6J5I/bLwjm9OLYgQuqsOE70gQlD+LqNon7sXn8tuPDw?= =?us-ascii?Q?oMMksO83ElvIu2pvPhw3tpOsZaW8dd21CILk414CRgD7607Ava+UN94dQiJQ?= =?us-ascii?Q?RUPH7oGkdtpb20UWSbyhau4XpyDTALIYJHqfrPhKqidIpnZWs/F88h4JZkyG?= =?us-ascii?Q?ejo/R0E3TqQjWEeatAsL6v3qul6irqYHw7tLnX4VjkVN8UHkbQ4Xsm7AZHdV?= =?us-ascii?Q?EAgsE6N67VeAZLwNu2qYZITrO2rc8Xnt4TcGkbfLyGMtV0sQdqeTnrGICwaP?= =?us-ascii?Q?wgHzS/1NHssoytc7CmnOdirYVDmJq2gBXxAOtlicRVNRB9Y3ncaChdfHzydl?= =?us-ascii?Q?szcrCn+S8Bgo3oLceKM7avEJSyqo09Ku+aolKuRfOzM8VSYAoZPyVyN4zLYm?= =?us-ascii?Q?YbWss+NQCCJuBNMxlbM+zxK5gw9XuetTSIbEvMOIAEvFphoWHCxInknjgDzW?= =?us-ascii?Q?Ef24u6gB3ml4SPGoYwQJ+8F6fN10iny3nW5Y387iTHxPjb/3vv4zvg53t/ec?= =?us-ascii?Q?ilOdV4AVYfPsJL6+qEFcIqiyt0THVdIdegyk51jkppbc6JmIkWTDi77xF8t6?= =?us-ascii?Q?C/KEVFQYntqVnK2sPYELbBGsyfq5QLQ/tUHwZMWdrMvyvLJiinb8Lb2Weu0t?= =?us-ascii?Q?xFpR15uGWs1yxGIdxqd5aed7rYIfR+OU4hPnqo4pgFdwRQFNgMLKwmRKd3nt?= =?us-ascii?Q?MRPcLe+mJQZGA0DUd5wXBhYSb/nQw7/UNFU6wM8eXwfxP3weR2DSyRgZfr6o?= =?us-ascii?Q?XG//IjcsafRoqVbJIfzLbEYiLdPlBbHh2f+eXC4daQFAVP3qt0pb7QEy7cgG?= =?us-ascii?Q?7kne4HQdZ+48MK4UYWG7fPY+Y1ej7ipWB7tEkRasjwb2hdJXIs6VUvePcjRe?= =?us-ascii?Q?Y+qXyBGinY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 5:TsRmnhzV3XNEZpPBD3ZAXKZ3G3UoGQVbW8IoSnvxHhQGEYCL0HFOYz/Ks3wmqAO/PW2AyTvvC7EY6M//Y6BcOtyEzOivB6fCdxzl3uvK5sYVc5zVPEJU470I+4uudzUbC2Th0MHQXTOmRHgG7BWndg==; 24:NCaeBxlAIE9oetejWeL66pz/EcD1KGR7yQWCJNn3YvgN+oufaJSzMBpG/iQog/d9Qj8MwCIWzjRqCOrgKUvrWiVcvjq6CbjW1CpCmbPnoGs=; 7:0NYxRNZgjmMfKiBcqhktoOxi/dnxYgsuHXAGy+iGhqoqKLBYICM9GwLr0oAT0h3EWs9cGiVbHRUVjLvFUDGwX+Q8mQZFY33i+CodN1ikOw9FTK9k1sxGrN8rQexbxoJo7m9LDooE5SSp06xK3+RjzpwPMWki3vUm7cO8hy15unAvfMeCGJYtz6Q+O2U5pKTA SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2016 17:26:45.6119 (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.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2449 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 17:26:55 -0000 Warner Losh wrote: > > The feature is named 'WITH_AUTO_OBJ'. Enabling this by default means > > that the only way to disable it is to add WITHOUT_AUTO_OBJ=yes to > > environment, make argument or /etc/src-env.conf. > > I tend to think this is a good idea. However, more and more is moving > into sys.mk, and it's been collecting lots of odd pebbles... The issue in this case, is that presence/absence of objdir affects .PATH, so if auto objdir is to be done, it greatly simplifies life to do it as early as possible ie, during sys.mk From owner-freebsd-arch@freebsd.org Fri Jun 3 04:16:48 2016 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 A8884B6874B for ; Fri, 3 Jun 2016 04:16:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 82BB21291 for ; Fri, 3 Jun 2016 04:16:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x236.google.com with SMTP id w184so109471755oiw.2 for ; Thu, 02 Jun 2016 21:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:date:message-id:subject:from:to; bh=UuUa4dXL1nc6kcqGLYHhwZ8+IbnuB6uwDNezDYUB6qM=; b=PALyFcIuB5PPzuTvm9CxO1PXGTYU+vNmxXwUppovywJPTdjlZMmzmM/yhVyi3+TRQE hGdhzBU7O45vpIBMun7yM6/TfPlBItIXD8p+qscURFANU5wRAcESAkeagjNumkcpH7nG TRG4kK9hsz5qiv5jEs3C39v7O4/hp9KRry9gajx6fuu9fjY1ql3dBEuPcuQ4vPV2t/V1 z7t+vYZeeyAAOHbHVMYa70zy3UKWdoWzsmlqs75a8zhIvBvh8RXGj4QX8XGD/FvGS6zb pCEOGzbxiLFw1F/UDUjqgfqrP9fBO09XGFIKYPqqhVPpubYoEkLp28nefXrCCtEXiTWi gmmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=UuUa4dXL1nc6kcqGLYHhwZ8+IbnuB6uwDNezDYUB6qM=; b=Zu7O5K1AwIKpzqip2b63TJfD5kfpR3KO1/qBKhAA2/jgV1E1fnFnJPABEXab1vNpFA 0j/Xr1cb8T3GWJ9LLGe+Q5o4BSf9WODW1o6mVvhCXf474O/kWcNBnbUASZTe7cl9rmf2 R2pA5dEwEfTQBpsCXcN5FLXFn3sdvWo5bfkxEGYuGKnqOGNN0pOeJeqzQ2rpeFgYVU09 pUvwqhBgKAXpCu+mjQI6h0cfEFSXxU3XvWN4kMnKhugrG3mZ8kYudUifJSiRVrjbs9cl KRmK7rBnAIcyQ+1gglNIOpbzg6Jo4GR7ExkP3igOteNp3h6EmsJc76F0Kmiy452hmobK uCuA== X-Gm-Message-State: ALyK8tIgzu3C0UT/MBhcyADik5hkPjHgwjw2CEcFo1b/QaHM+ToP9CQIpFEWjC8xN2G+Me0tz9vUGBjUv0uREFWk MIME-Version: 1.0 X-Received: by 10.202.241.67 with SMTP id p64mr652858oih.197.1464927407613; Thu, 02 Jun 2016 21:16:47 -0700 (PDT) Sender: sobomax@sippysoft.com Received: by 10.157.56.70 with HTTP; Thu, 2 Jun 2016 21:16:47 -0700 (PDT) Date: Thu, 2 Jun 2016 21:16:47 -0700 X-Google-Sender-Auth: _pVd8Ya48XkdEhMcg4Hhyl0Z93I Message-ID: Subject: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads From: Maxim Sobolev To: FreeBSD Current , freebsd-threads@freebsd.org, freebsd-questions@freebsd.org, freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 04:16:48 -0000 Hi there, we have an application here which is trying to measure UDP command/response round-trip-time. It runs two posix threads (more actually, but that's probably irrelevant), one (let's call it A) that does high-level logic and the second one (B) that does network packet I/O. The sending side is done by first thread A forming the request, then calling the function clock_gettime(CLOCK_MONOTONIC) and passing the packet into the thread B. Obtained timestamp is stored with some logical transaction ID allowing us to pull that stored value later on when response arrives. Then we have a separate process that receives those requests, processing them and sending back some form of response. Upon receiving a response from the network, the network I/O thread (B) timestamps it by running clock_gettime(CLOCK_MONOTONIC) and passes the packet data along with that value via queue to the thread A for processing. So if we put things into timeline, what our app does would probably look something like the following: 1. Thread A generates request. 2. A calls clock_gettime(CLOCK_MONOTONIC), storing value as t1 internally 3. A passes packet to thread B 4. B sends out packet via sendto() to server process running on the same box (fully separate, not a thread) [some microseconds later] 5. B receives response from server with recvfrom() 6. B instantly calls clock_gettime(CLOCK_MONOTONIC), assigns returned value to t2 7. B passes packet data along with t2 to the A via queue 8. A picks up packet, parses it and retrieves corresponding t1 stored at step 2. 9. A calculates RTT by doing t2 - t1 assuming it's going to be positive... As you might have guessed if you are still reading, from time to time t2 - t1 comes out slightly negative! Provided it's not some obscure bug in our app, there is no way this could happen if clock_gettime(CLOCK_MONOTONIC) would work as advertised. Event (2) could not possibly happen earlier than (6), which is guaranteed by the fact that the request needs to be processed by the external entity first in order for the response to be seen by our app at all. I've added some logs and it seems to be confirming that the server only sees a single request, there is no chance for the client to receive some other packet and confuse it. I've also confirmed with tcpdump, which shows reasonable time delay between request and reply of few hundreds microseconds. I've checked all logic and I could not find any mistakes on my end here, so I added some logging for such events. The distribution appears to be centered around 0.00006s, but there are some events that go as far up as 0.012s. I've also tried using CLOCK_UPTIME_PRECISE instead, but it makes no difference whatsoever. My questions therefore are: 1. Is it intended/expected behavior of the said API? 2. Has anyone else bumped into this? 3. I know we are doing some clever optimizations using TSC to speed those APIs up, could be it related to that? 4. If the answer for (3) is yes, then what is the method to disable using TSC and use slower but possibly more reliable method? 5. Is there any way/plan to fix this long-term? 6. If the behavior is intended/expected, what is the maximum discrepancy we can expect from this effect? In general some time ago we've spend quite lot of time switching our app from using REALTIME into MONOTIME in the hope to eliminate any wizardry needed to deal with realtime possibly jumping back and forth due to NTP, leap seconds etc, it's shame that this is not working either. Apart from measuring command processing delay, that app does lot of high-volume voip call billing, so even such small discrepancy can easily build up into a bigger problem, not to mention the fact that every time we deal with duration we now need to have some check in place to make sure we don't have some negative values popping our of nowhere. Any hints, suggestions, pointers are appreciated. I can also give more debug information as needed. Thanks! -Max From owner-freebsd-arch@freebsd.org Fri Jun 3 05:05:29 2016 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 991DBB68FDA; Fri, 3 Jun 2016 05:05:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 653831B40; Fri, 3 Jun 2016 05:05:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x231.google.com with SMTP id o189so54931278ioe.2; Thu, 02 Jun 2016 22:05:29 -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; bh=HB2MCHDu3HgA9EshZyPtgWRG8azVzZUZFLIwjsNXc4A=; b=qvqAYuCxTCebd03wL9RXt5fe999NOWxcnFvdYKRzRmVqkS4CGskzREs/3cfjwk6ru0 ZDSEzO40J5bEzWG8vkvqT1t1XOIDvXOzvvouRCAPbBWPjLB0mCXsAIPFaZM2ZYMZU8ko 5qUTI40ph0s31Zh6pnVH3pROoVuXinWjckIXazrKqdClFvvVZhehbCbkfDVKsJOyeEOq Puislektl9aLQ1Awp4PmRRCu1CGd7tY0n6iuuFnKEA84L2ArB6LDJYSzMHl0Q8fDBlLE 9KqHo0H6YAiQ5nAOGE0/x+WCRWVyjpNfwpUPDdBWO4/8SzVxi+gxOsG/yGYugO+DPNdc 0IMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HB2MCHDu3HgA9EshZyPtgWRG8azVzZUZFLIwjsNXc4A=; b=ltZi74TQWgTRBiw61zM5zUv4seayn9QIZH14veKSADSde8YGAJ05bifctH9i+xqf7M boQenHfwgAsQbrjcJh8TCMzHFlg/8pKXo6Pop1wg52KA/4WzsumKD9UX/z5lGAl1at8N fZSjr1urTbolfCgcRKbvKHogssam5CAO+oDpproJS6WI3SQVW5spRCP1ePUuooGDrqXN BKuqL3exOkwpCiMXvvi+n1PiFAq501/SW9bM+5Oe9hhkBjzR/1jJNeqsqVG8JPEu99HY CTOhlw0zfbuS1jZcOFJaYBg0pTG+vQoNHyWjht+bVCpqZV3FiuqHN7kT8n8t+LB/PYXb 6cuQ== X-Gm-Message-State: ALyK8tJV1p1JlAgAB38AkJzzF/PJxW8l+N7LhPSFP7HqE63f453TW51fEaNYZbBRKHYHb0SoocH5h92hPtlQuw== MIME-Version: 1.0 X-Received: by 10.107.48.203 with SMTP id w194mr2390958iow.123.1464930328822; Thu, 02 Jun 2016 22:05:28 -0700 (PDT) Received: by 10.36.113.3 with HTTP; Thu, 2 Jun 2016 22:05:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Jun 2016 22:05:28 -0700 Message-ID: Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads From: Adrian Chadd To: Maxim Sobolev Cc: FreeBSD Current , freebsd-threads@freebsd.org, FreeBSD Questions , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 05:05:29 -0000 [snip] a) is it on one core, or multiple cores? b) CLOCK_MONOTONIC_FAST? c) is it on a system that /has/ invariant-TSC ? d) is this a multi-socket system? -adrian From owner-freebsd-arch@freebsd.org Fri Jun 3 10:09:48 2016 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 5D01FB66AC4; Fri, 3 Jun 2016 10:09:48 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from degoeje.nl (degoeje.nl [81.169.238.128]) by mx1.freebsd.org (Postfix) with ESMTP id 245B41878; Fri, 3 Jun 2016 10:09:47 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from [192.168.1.250] (unknown [188.203.228.182]) by degoeje.nl (Postfix) with ESMTPSA id 1BD4115C0025; Fri, 3 Jun 2016 12:09:39 +0200 (CEST) Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads To: Maxim Sobolev , FreeBSD Current , freebsd-threads@freebsd.org, freebsd-questions@freebsd.org, freebsd-arch@freebsd.org References: From: Pieter de Goeje Message-ID: Date: Fri, 3 Jun 2016 12:09:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=3.5 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on degoeje.nl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 10:09:48 -0000 Op 2016-06-03 om 06:16 schreef Maxim Sobolev: > 4. If the answer for (3) is yes, then what is the method to disable using > TSC and use slower but possibly more reliable method? sysctl kern.timecounter.choice lists the available timers. sysctl kern.timecounter.hardware selects the timer. Changes take effect immediately. - Pieter From owner-freebsd-arch@freebsd.org Fri Jun 3 14:28:33 2016 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 502F7B6856E for ; Fri, 3 Jun 2016 14:28:33 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 146731AB0 for ; Fri, 3 Jun 2016 14:28:33 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x22f.google.com with SMTP id j1so128993982oih.3 for ; Fri, 03 Jun 2016 07:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/R1r4y9qtKUG1dHzy0HWyVDbah0Oa/cO79CxNqLFass=; b=x279AAiC/I/Tnt/vlSykudYqoId3KDJnLN5N64dcBjybxaYicygHPAUQKlfU+XhtSp aYhkB/ZbVO8Ipc+u4kIANOl1fMs3QZH0MrGYpVzL5runJ5AF/uC7UD98TDg8+L95CwAA YlF+4Lru9l1OSOEmCXYgdE/MwWK3O5IQJ3weBYI3dKpwEiz1Kfvf+guniqyEAnBsrgs5 x+unrPYfDeNk4BQ+RQf+yYb9y1fB2PaAkRxmjgZjHxvDXZBn3qi0oVH+uhXbeYoWhjaz BgNiW/60SjOysNd8EljJEqG6myMfTxgiFcxYz2nkLXEQlwYmfVySzUspF9B+m/zc625O ga2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/R1r4y9qtKUG1dHzy0HWyVDbah0Oa/cO79CxNqLFass=; b=V+IXA+wR5UysSgXv73En/9eYtKaAZZJIyWrqc8DIQx4mgfft9iPd9Pn/AB5tm+cugT sIptAl+JjLh793g1KN3Yi6080yms66vVf6tfl2ObZy8Zzbsgr+fcHkuQdxN7NhJi7a4m YyqkqHzoBeMAP16pe0gdNqqDFPJeMF9oad2mq4Ft5WtOib58jyrN7xzBK+1QMW0GE90b 0cZ9RgpB13+KMJCQnJgwybl5gtSm88pbSqyyBj5haBImiBGVf1k62EOyMCuS9uuJ9J+X 25+lam/1DBJDZvd5263Nr1EA68gMqGTlI/046Qg0Xerh16OxoUU6FTqO6B8BxCLbs8Mq o6DQ== X-Gm-Message-State: ALyK8tLshLF6Ov0WJA1QmgJ2wswOhQ4zFokG69dZbzmmPfQqtg3l1rd4B1aMW+s2ff8QDCbxKrRMkss19cCsg/j9 X-Received: by 10.157.31.78 with SMTP id x14mr2143800otx.15.1464964112288; Fri, 03 Jun 2016 07:28:32 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.157.56.70 with HTTP; Fri, 3 Jun 2016 07:28:31 -0700 (PDT) In-Reply-To: References: From: Maxim Sobolev Date: Fri, 3 Jun 2016 07:28:31 -0700 X-Google-Sender-Auth: _Ht2eSLKxKB2HEHmY-rA1U04kUI Message-ID: Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads To: Adrian Chadd Cc: FreeBSD Current , freebsd-threads@freebsd.org, FreeBSD Questions , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:28:33 -0000 a. multiple cores. b. makes no difference c. yes, I believe so kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 machdep.tsc_freq: 2658118740 machdep.disable_tsc_calibration: 0 machdep.disable_tsc: 0 d. no, single socket Intel Q6700. I've also seen this problem on core i7-4770 running virtualbox 5.x. I have a hints that this also happens on our bigger production boxes, but I have no specifics yet. On Thu, Jun 2, 2016 at 10:05 PM, Adrian Chadd wrote: > [snip] > > a) is it on one core, or multiple cores? > b) CLOCK_MONOTONIC_FAST? > c) is it on a system that /has/ invariant-TSC ? > d) is this a multi-socket system? > > > > -adrian > > From owner-freebsd-arch@freebsd.org Fri Jun 3 17:14:49 2016 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 403DFB6989C for ; Fri, 3 Jun 2016 17:14:49 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 BDA98109B; Fri, 3 Jun 2016 17:14:48 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id w16so8518317lfd.0; Fri, 03 Jun 2016 10:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=F2ZXt6fYLMVoH6IlHeFgQlbefyCTNa76+oRmDbUVMj8=; b=JMGcRGXHC5YSpE3d8wuIww7WxFAOIwCG2JyL/s/sTz7DA5kYU7zJ1JABETHBwcQtPc AMd9S38hGfQR+R3XWYLn/HcgyJ0WJECHuBAiGudbGa7sN2YZdclQ7NqIjBMv/YsHnqJY 0i+iMZfHPsi8e60nAKP2KkYbDPT+vSLIMpTAapNMpHBDOQ2de9Q81AcnqtETuybBOZGx PkaNInZ37K2m1PY56qN25VPueWAMmlOcpIAqaf4RMydj1oBlGbUDEuCPUtKoeM14SINw SWuZrqsJIxlSvJSR8EXUgKY0EYPsVI6xGRAes18FQmC2rEqm6xRnvd/qRD6FY+by4hx6 0i0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=F2ZXt6fYLMVoH6IlHeFgQlbefyCTNa76+oRmDbUVMj8=; b=m7urhtUTd/lBwvgVCLSuX9BS5Ut4jIPIbWz3FwSa7EOHm/n77CLSnVY47LEaD6mfpL G9+14ysesMZwRNPDQ3Wi0ZDOnGBi7xRpwfbWsyXov6qe9eYWvtzwaAJrSeCksl8uE6fR TdezxdbYgK3xQJTUpHTqMhHG4zU+Fikhu0iRaylJEWiUr/LPvprN4SbE5nsvKqsKQSM0 oCWugv9dIDn3J9jCYOHFpJf4DglN1PbCFmNpU80w6x4115OJ+feRviOrSzc+N588lBrl z5rRaTi9k6B2IQeF99+p7EJgOP3rxaiYRqouq3S3t4TQ/UsjtgS0H+fsRuDO3mKts+iq 3B1g== X-Gm-Message-State: ALyK8tJlug9G9ph4JLXZIBfm/GKz4map6182+4DH73nl08AmnFbyi0lxVGDdmKz7qKCyuauveK7/Fe6e5GfXdQ== X-Received: by 10.46.32.85 with SMTP id g82mr1312901ljg.51.1464974086230; Fri, 03 Jun 2016 10:14:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.16.195 with HTTP; Fri, 3 Jun 2016 10:14:45 -0700 (PDT) From: KILOREUX Emperex Date: Fri, 3 Jun 2016 18:14:45 +0100 Message-ID: Subject: API to link sysctl nodes to devices To: freebsd-arch@freebsd.org Cc: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , Koop Mast , eadler@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:14:49 -0000 Hey, As part of my participation GSOC, I have been working on an API spec to link sysctl nodes to devices. And I cam up with few ideas that I need some feedback on before proceeding to the implementation on the kernel. - We need devices to have their propoer sysctl trees, and thus every device linked will have its own id as the head of its syctl tree. For example a device with id 0x94, would have it's sysctl root look like dev.fs.0x94 where the below parameters can be accessed after that. - We want to give device drivers the ability to create and delete sysctl nodes as they want, thus proposing a proper interface for it. So I have been thinking so far to enable the creation of the root for those sysctl nodes on the system initialization, to allow existing device drivers to link their device on the tree. Also we want to propose a new function similar to make_dev, supposed we name it make_dev_sys, that gets the device id and links it on the tree of existing sysctl nodes, and for the purpose of keeping track of the available sysctl nodes for each device, I thought of proposing a change to the device switching table "cdevsw" to keep systcl context tracked for the device. Would any modification to cdevsw break backward compatibility ? Please provide us with any feedback you have on this proposition and any defects you seeing in the logic. Your help is much appreciated. From owner-freebsd-arch@freebsd.org Fri Jun 3 20:20:42 2016 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 03B6CB6800E for ; Fri, 3 Jun 2016 20:20:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C02B01B8D; Fri, 3 Jun 2016 20:20:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 14BBA1FE024; Fri, 3 Jun 2016 22:20:37 +0200 (CEST) Subject: Re: API to link sysctl nodes to devices To: KILOREUX Emperex , freebsd-arch@freebsd.org References: Cc: Koop Mast , eadler@freebsd.org, =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= From: Hans Petter Selasky Message-ID: <6b21329d-33ea-e628-b06c-27a744c9ec09@selasky.org> Date: Fri, 3 Jun 2016 22:24:00 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 20:20:42 -0000 Hi, On 06/03/16 19:14, KILOREUX Emperex wrote: > Hey, > > As part of my participation GSOC, I have been working on an API spec to > link sysctl nodes to devices. > Can you clarify a bit what you mean by "device". The term "device" was a bit too generic for me :-) I suppose you mean a "character device", right? Can you give some examples of properties for a character device, which can be exposed trough these sysctls you propose ? > And I cam up with few ideas that I need some feedback on before proceeding > to the implementation on the kernel. > > - We need devices to have their propoer sysctl trees, and thus every device > linked will have its own id as the head of its syctl tree. > > For example a device with id 0x94, would have it's sysctl root look like > dev.fs.0x94 where the below parameters can be accessed after that. Would it be better to have a direct mapping between character device name, including directories and dev.fs.xxx , like /dev/cuaU0 maps to dev.fs.cuaU0.xxx ? > > - We want to give device drivers the ability to create and delete sysctl > nodes as they want, thus proposing a proper interface for it. > > > So I have been thinking so far to enable the creation of the root for those > sysctl nodes on the system initialization, to allow existing device drivers > to link their device on the tree. > > Also we want to propose a new function similar to make_dev, supposed we > name it make_dev_sys, that gets the device id and links it on the tree of > existing sysctl nodes, and for the purpose of keeping track of the > available sysctl nodes for each device, I thought of proposing a change to > the device switching table "cdevsw" to keep systcl context tracked for the > device. > > Would any modification to cdevsw break backward compatibility ? > Please provide us with any feedback you have on this proposition and any > defects you seeing in the logic. > > Your help is much appreciated. --HPS From owner-freebsd-arch@freebsd.org Sat Jun 4 08:52:58 2016 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 58C53B689C8 for ; Sat, 4 Jun 2016 08:52:58 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 250E7197F; Sat, 4 Jun 2016 08:52:57 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4F1294F57A; Sat, 4 Jun 2016 08:52:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u548qncE013622; Sat, 4 Jun 2016 08:52:49 GMT (envelope-from phk@phk.freebsd.dk) To: KILOREUX Emperex cc: freebsd-arch@freebsd.org, Koop Mast , eadler@freebsd.org, =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Subject: Re: API to link sysctl nodes to devices In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13620.1465030369.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 04 Jun 2016 08:52:49 +0000 Message-ID: <13621.1465030369@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 08:52:58 -0000 -------- In message , KILOREUX Emperex writes: >As part of my participation GSOC, I have been working on an API spec to >link sysctl nodes to devices. It's not really the sysctl nodes as such you should focus on, but rather on the gap between (the increasingly inaccurately named) newbus and devfs. The poster-boy example is how you get from USB bus coordinates to /dev/da* or /dev/{tty|cua}U* devices. devd(8) seems to know the linkage and usually I resort to /etc/devd entries like this to make it liveable: attach 1000 { match "device-name" "uftdi[0-9]*"; match "vendor" "0x0403"; match "product" "0x6001"; match "sernum" "FTHAV9UU"; action "ln -s /dev/cua$ttyname /dev/bbb1"; }; notify 1000 { match "system" "USB"; match "subsystem" "DEVICE"; match "type" "DETACH"; match "vendor" "0x0403"; match "product" "0x6001"; match "sernum" "FTHAV9UU"; action "rm -f /dev/bbb1"; }; -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Sat Jun 4 11:09:58 2016 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 A5B0AB69F68; Sat, 4 Jun 2016 11:09:58 +0000 (UTC) (envelope-from seotownsend@icloud.com) Received: from st11p01im-asmtp001.me.com (st11p01im-asmtp001.me.com [17.172.204.151]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78EFD1E55; Sat, 4 Jun 2016 11:09:58 +0000 (UTC) (envelope-from seotownsend@icloud.com) Received: from process-dkim-sign-daemon.st11p01im-asmtp001.me.com by st11p01im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) id <0O8801E00S7A6Q00@st11p01im-asmtp001.me.com>; Sat, 04 Jun 2016 10:09:48 +0000 (GMT) Received: from [10.30.1.6] (unknown [104.156.228.75]) by st11p01im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O8800DJDS891630@st11p01im-asmtp001.me.com>; Sat, 04 Jun 2016 10:09:47 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-04_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1606040116 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads From: Seo Townsend In-reply-to: Date: Sat, 04 Jun 2016 03:09:44 -0700 Cc: Adrian Chadd , "freebsd-arch@freebsd.org" , FreeBSD Current , FreeBSD Questions , freebsd-threads@freebsd.org Message-id: References: To: Maxim Sobolev X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1465034988; bh=kLj1bwabNtxVLQmtlFkraJhlhovJ1iVjbxBt0eUnpiU=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=BvOWAs70DrcIGAR4HE1Bck50E5kbedqOPuAkoGMsSOrWiHcaQKTIuLR9wcXRimCwt S0W2cr+PfTJKropgJhMLiW54rEB5DC/34vreIJWraRyTOlP3BLkrwmlp0lssNw7RNy Qm7W9uWtklW+TXvZgCVeO0gmxxx5GA+27DkjjAzBHzE+z1SlVymS1CpelpUi7bIFFb qfrhmZXyOjvJMmcV9tBOjDZ3jy7i/4k2kv4sJmVgkYlHw3BWdEREuPgyN3xBvBpl3d RB6TdubyzFECYKgLzo8I1P9XSO93midPOnlntnlRoL972ivqvhuJL9RucHWITf+I03 0djXGb0vSDquQ== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 11:09:58 -0000 Heyy, Sure your machine isn=E2=80=99t sitting next to a block hole? :P Many of the names (CLOCK_XXXXXX) seem to be just aliased. https://github.com/freebsd/freebsd/blob/master/sys/kern/kern_time.c#L343 = = I didn=E2=80=99t thoroughly look at this, but it seems like there=E2=80=99= s a margin of noise introduced by drift corrections that might (half ass-edly) explain the = sub millisecond errors you were receiving? https://github.com/freebsd/freebsd/blob/master/sys/kern/kern_tc.c#L1374 = For the larger >1ms errors, ...that=E2=80=99s probably not good? lol. = Might be worth it to try the timersub library function: = (http://www.unix.com/man-page/freebsd/3/timercmp/) to calculate the delta. > On Jun 3, 2016, at 7:28 AM, Maxim Sobolev wrote: >=20 > a. multiple cores. > b. makes no difference > c. yes, I believe so >=20 > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > machdep.tsc_freq: 2658118740 > machdep.disable_tsc_calibration: 0 > machdep.disable_tsc: 0 >=20 > d. no, single socket Intel Q6700. I've also seen this problem on core > i7-4770 running virtualbox 5.x. I have a hints that this also happens = on > our bigger production boxes, but I have no specifics yet. >=20 > On Thu, Jun 2, 2016 at 10:05 PM, Adrian Chadd > wrote: >=20 >> [snip] >>=20 >> a) is it on one core, or multiple cores? >> b) CLOCK_MONOTONIC_FAST? >> c) is it on a system that /has/ invariant-TSC ? >> d) is this a multi-socket system? >>=20 >>=20 >>=20 >> -adrian >>=20 >>=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"