From owner-freebsd-hackers@freebsd.org Sun Feb 16 21:56:07 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E5F432441A6 for ; Sun, 16 Feb 2020 21:56:07 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48LLXk2G5Nz4nTb for ; Sun, 16 Feb 2020 21:56:05 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 9A8BDB1358 for ; Sun, 16 Feb 2020 13:55:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 16 Feb 2020 13:55:56 -0800 From: Neel Chauhan To: freebsd-hackers@freebsd.org Subject: Committing three Phabricator patches (Netgraph/IPFW) User-Agent: Roundcube Webmail/1.4.1 Message-ID: <06564da64541b9dfe19c4a9bb4937263@neelc.org> X-Sender: neel@neelc.org X-Rspamd-Queue-Id: 48LLXk2G5Nz4nTb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 2001:19f0:8001:fed:5400:2ff:fe73:c622 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-3.08 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.38)[asn: 20473(-1.83), country: US(-0.05)]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 21:56:08 -0000 Hi freebsd-hackers@ mailing list, I have three patches on Phabricator in an "accepted" state, and would like to get them committed. The first two are on Netgraph, and the third is on IPFW. If someone can do this, could you please do the needful? The three patches are as follows: * https://reviews.freebsd.org/D23477 (netgraph: If queue is full, don't enqueue in ng_source_rcvdata()) * https://reviews.freebsd.org/D23461 (netgraph: Add RFC 6598/Carrier Grade NAT support to ng_nat) * https://reviews.freebsd.org/D21812 (ipfw(8): When checking for IPv4 in add_src() and add_dat(), don't assume !IPv6 is IPv4) -Neel === https://www.neelc.org/ From owner-freebsd-hackers@freebsd.org Sun Feb 16 22:05:33 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 43EC92445F3 for ; Sun, 16 Feb 2020 22:05:33 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from hermes.heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2560 bits) client-digest SHA256) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48LLlZ2w4Dz4tP4 for ; Sun, 16 Feb 2020 22:05:29 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from [10.0.5.3] (noddy.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.15.2/8.15.2) with ESMTPSA id 01GM4idl028539 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Mon, 17 Feb 2020 09:04:45 +1100 (AEDT) (envelope-from dewayne.geraghty@heuristicsystems.com.au) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=heuristicsystems.com.au; s=hsa; t=1581890685; x=1582495486; bh=5A6pUSEhdjkq1c0Ri1scIacTa1Xb9+pH/9qHK+7JaKo=; h=Subject:To:From:Message-ID:Date; b=SmEoGWoeS7WOZ3mfa/3UGDiG0XijvKAbu3lJDvY6MuhBllokWhfjuWq8k95oaki9L RpF+wqNenRf5SOFrBJsxDk0pCpv1qbaYIjKm1OWY4kqkeM5Q+zmeG7M3EsSw03EiRH 7G68nnlcJ9MsYOyJbC7KR+Gf7pLe5hqlMNGYPlSwu/amuTDFJ65gF X-Authentication-Warning: b3.hs: Host noddy.hs [10.0.5.3] claimed to be [10.0.5.3] Subject: Re: Why is not llvm-config executable included? To: freebsd-hackers@freebsd.org References: <20200215185821.GV4808@kib.kiev.ua> From: Dewayne Geraghty Autocrypt: addr=dewayne.geraghty@heuristicsystems.com.au; prefer-encrypt=mutual; keydata= mQFNBFbOsVMBCgDfvi2PspSwoMEtFhF+aFLQKtzSA9f0dhDqthKHESdfbqxvKzhkBjvTJ5Na EgjKoKfoQTh5xuIv3HLhtDo5PeasPgQl9cPJeriqmqlS+UhY5BGYcMc1AO/TX0fsDaQz96ko at3RUW7sff/qPgVzSurk+DV5h866gPdn5Jdjohyl2F1rzRl6dnaAIyg49zlwZOnPHJGKye+B meqUCnPRglhkpNqXR3v1ulbWpfwhdNDvWT82qTG/qsFy/agjJvxwLuEBeoGc1dPWasO8Nztt 0dqf1Lpeg6SX2yJd76WVS4znt88OEbx/QL2PTJ/YtSepS68WaeKuARKPukkU+QXDep0gaLPl /TvU5xAZndNB3rYnpmoLb32pDHlrJbZUVyTMqc3J2EYM6aaizCpg4VEvVpVSqUT4D9MuREhu PeZ3SvEazQARAQABiQF3BB8BCAAhBQJWzrFTFwyAAWHe5yZt8RJL0vaU1MfDto5dBmeFAgcA AAoJEJVk7a1LmFrdy2QJ/AysDdFIMCRiaqEellprZQyEz5I/qZJEi6yRfXH813hhISFz6moh urZYLQ9SRdyMntT8W3Oc4pJc9fF9RSnY0SSQY/arZbrvsv6hKb1KtIK7P5mLS914J9buxEcJ SWeVuOuMA9aCNqg5uMu19pH5pXayORfbv+K7vFPiyllZ64ShUWZJL69vAc/TsbvMrGtG1M4P qyWCOKEiUT93zhVGQoA0aUYjMAZoyvozZCuieo4O8hkPgMz9lka+3bqQBSOB+qO4Iz+CZs0k Lw7Soga6bRqLK86DH99WjTA6Oj1r8Won+j4V9fnTDCVJoSyqdVHLySDv/lHaNu4Ia4AO4i2d shmLw03gOUvoWLJx5X01A5Zio4FvecnpZqQ0Wz5Ph9MiK3lwarfjonTOLeNGd5BpdnHu5VRC fJml7uAYeyKsD8C4tDtEZXdheW5lIEdlcmFnaHR5IDxkZXdheW5lLmdlcmFnaHR5QGhldXJp c3RpY3N5c3RlbXMuY29tLmF1PokBgAQTAQgAKgUCVs6xUwIbIQsLCg0JCAwHCwMCBAgVCgkI CwMCAQUWAwIBAAIeAQIXgAAKCRCVZO2tS5ha3aBzCgCB6n7hpYUJQ1jT6VxXDpo2OB+Vo7/U ajxY3uVd9NibvCQwRirweCFcR8nCMH5AaXxcrR2znKQ2P9xCTwoFF5sureYhsESiE3vbh0Nt 6DCJVLi2hZM0LdPdwaFSCyCewZq7SZh5XonvJr9BC0p90+gR+pqn8DO/4Tv5zgS69KhCa5uz EfJ/RBkHULCthQihh8/Fnkd1gxetB3K8jGMAbg1gWZcSRY/ti+ibWNJd6bBhtKc6b0r/Aq3Q 1Xls39o6MADu9P2zVP5E5Q33+2pVy8D1Z/Yfro7i84NlJPyIuAnt4GYQzBW4e2+aaQeJCcUh Sddio+GY7KOuwHcAEkvojH1tooxbMT+J36end8y7BrXMR+QRFVtlJmAIPrEcdf7bC06MzL8e SW5FjUavan7zIl2Zk6c/M7OfCBLioUfVhha4SA== Message-ID: <0f258cc4-7aae-b757-add0-e44c329c8255@heuristicsystems.com.au> Date: Mon, 17 Feb 2020 09:03:49 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200215185821.GV4808@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48LLlZ2w4Dz4tP4 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=heuristicsystems.com.au header.s=hsa header.b=SmEoGWoe; dmarc=none; spf=pass (mx1.freebsd.org: domain of dewayne.geraghty@heuristicsystems.com.au designates 203.41.22.115 as permitted sender) smtp.mailfrom=dewayne.geraghty@heuristicsystems.com.au X-Spamd-Result: default: False [-7.45 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_XAW(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; TO_DN_NONE(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[115.22.41.203.list.dnswl.org : 127.0.4.2]; DKIM_TRACE(0.00)[heuristicsystems.com.au:+]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-3.25)[ip: (-9.71), ipnet: 203.40.0.0/13(-4.18), asn: 1221(-2.37), country: AU(0.01)]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:1221, ipnet:203.40.0.0/13, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[heuristicsystems.com.au:s=hsa]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[heuristicsystems.com.au.dwl.dnswl.org : 127.0.4.2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[heuristicsystems.com.au]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 22:05:33 -0000 On 16/02/2020 9:27 am, Konstantin Belousov wrote: > One of the reason why llvm in base should not be used as llvm infrastructure > is because llvm API and ABI is not stable across llvm releases, and exposing > that would make compiler updates in stable impossible due to the stable > branches guarantee of ABI stability. I think you're saying - don't build ports in a base (without the llvm port), rather use a separate build jail with llvm port. We used to build all ports in base and ship them to clients. Around FreeBSD6 we started to build within a jailed environment, as we supported i386 & amd64; something we still do. Though I'm concerned that perhaps we should migrate (our jails) back to using gcc where-ever possible, in the hope of avoiding future ABI incompatibility? In my experience replacing a base 'something' with the port of 'something' must be done carefully. (our experience with binutils and libressl, ultimately required removing all base "stuff" and using workarounds like softlinks - a bit messy, but scriptable) Would using gcc, in the build jail, provide better insurance against ABI breakage? From owner-freebsd-hackers@freebsd.org Mon Feb 17 11:14:38 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8FAEF2554C0 for ; Mon, 17 Feb 2020 11:14:38 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98]) (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 48LhG52d4Vz4JRV for ; Mon, 17 Feb 2020 11:14:37 +0000 (UTC) (envelope-from ap00@mail.ru) Received: by smtp38.i.mail.ru with esmtpa (envelope-from ) id 1j3eME-0007KH-FQ for freebsd-hackers@freebsd.org; Mon, 17 Feb 2020 14:14:34 +0300 Date: Mon, 17 Feb 2020 14:14:32 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <661730512.20200217141432@mail.ru> To: FreeBSD Hackers Subject: is there a future for user accounting (getpw* replacement) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-7564579A: 78E4E2B564C1792B X-77F55803: 0A44E481635329DB0E1AA8A03B392317F65658A2B47C080330131054616CB0F120ADF35AEC30349DF688BCB05C26794D575C405348F4CF73B076D253F05E11AABEB38AD8896B7530D79DA5B6B6F53AEF X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7CA8E915ACC910FBDEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063781769915DC205ABEEA1F7E6F0F101C674E70A05D1297E1BBC6CDE5D1141D2B1C0DC91DF045D0351914F1DBF78F1D1392000BB2602D4A83109FA2833FD35BB23D9E625A9149C048EE26EBC606A559BFCFE5D25F19253116ADD2E47CDBA5A96583BD4B6F7A4D31EC0BB23A54CFFDBC96A8389733CBF5DBD5E9D5E8D9A59859A8B62A2FE3BEE621D36CA471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C22491BDC5325088848EC76E601842F6C81A12EF20D2F80756B5F012D6517FE479FCD76E601842F6C81A127C277FBC8AE2E8B0704B65276AE8F4C3AA81AA40904B5D99449624AB7ADAF3726B9191E2D567F0E725E5C173C3A84C309A7649CC036878F35872C767BF85DA2F004C906525384306FED454B719173D6462275124DF8B9C9DE2850DD75B2526BE5BFE6E7EFDEDCD789D4C264860C145E X-D57D3AED: Y8kq8+OzVoxvgW9Op3aR8Fxwo7H2ZNxGP5qz8aO2mjTJzjHGC4ogvVuzB3zfVUBtENeZ6b5av1fnCBE34JUDkaJinJwwHx5ysVv9/YfT9ueKN0Nh/ly1Ag== X-Mailru-Sender: D8D48EF70163D79D00784CDFC8FD31073B60C61F5AE661AD1750D297725C05F1707A50CDA4C0E07250D5CF8590B94F4EC77752E0C033A69E81198BD1A48777B793AC9912533B2342AE208404248635DF X-Mras: Ok X-Rspamd-Queue-Id: 48LhG52d4Vz4JRV X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.100.176.0/20]; FREEMAIL_FROM(0.00)[mail.ru]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ipnet: 94.100.176.0/20(0.06), asn: 47764(0.25), country: RU(0.01)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[mail.ru:+]; DMARC_POLICY_ALLOW(-0.50)[mail.ru,reject]; HAS_X_PRIO_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; RCVD_IN_DNSWL_LOW(-0.10)[98.177.100.94.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[mail.ru]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[mail.ru.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 11:14:38 -0000 Greetings, I'm wondering has anybody any thoughts about user accounting provided at the system level? It seems that getpw* doesn't suit the needs of application services. All applications has some external/internal mechanism for storing and retrieving user properties (settings, roles etc). Furthermore they implement own security policy based on this mechanism. Mostly it is done via LDAP connection or internal store (as for database). It seems that all application developers will be more happy if OS will have a few functions to do the things such as: - list users of some type; - get user properties specific to application; - get user roles specific to application -? Does anybody has thoughts about what OS must provide to keep applications consistency and make developers happier? -- Best regard, Anthony Pankov mailto:ap00@mail.ru From owner-freebsd-hackers@freebsd.org Mon Feb 17 12:01:53 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B170E257175 for ; Mon, 17 Feb 2020 12:01:53 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48LjJc4Y80z451L for ; Mon, 17 Feb 2020 12:01:52 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-oi1-f181.google.com with SMTP id d62so16387907oia.11 for ; Mon, 17 Feb 2020 04:01:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k8T1ojxvDIZ6HrWvyPQJlH+XuTSotw1i4tiIdrFLFuI=; b=sBIbRx3fvGL7RtUcNdGs6e5gfEX81NGyUJ00NvXMzQZORnGICkxYITffjNuBWSikd0 odoSVur/NhFJtSx63Xs6LLgLDCvgus3dzzACgVpOHNwIw+DKGqonB/jlhCXNilP8hbrv m5mn79h5OE6iLMIqr3iY4PqVapxU8S28JyYnnWgpeOq7t2uSkThYlujXEwIt2fBJrZUH AI7apu04BCcUbvvA/YIW6XtSDkSfexRYBwlOqc4z7Z850PNm7mghrsOvEM/rYPD3h6br 2NdxSKOJJM3l3GDrrgZh6oC+5aDf3/Yasg+a1Skvpkd1n+l4cyIsYm6Y+7s990aRZIdZ zjIQ== X-Gm-Message-State: APjAAAXBLi2xh6Qoz6fQ4Uk9C5V7fXvxVZ3m0D9r88ZCtgUc/jqU1IGm ms5z/jOga177G+HEHQqf12GuUZNDJrwgoc4hTOc= X-Google-Smtp-Source: APXvYqwEwEX64shSoeTyFyZzfdCaaIVi64wGYY9r3b9XPtH6sENIxkxx1AP6o6kKjJ9n1xe+HOat8Gx8c5YZewKQstU= X-Received: by 2002:aca:48cd:: with SMTP id v196mr10045560oia.102.1581940910993; Mon, 17 Feb 2020 04:01:50 -0800 (PST) MIME-Version: 1.0 References: <661730512.20200217141432@mail.ru> In-Reply-To: <661730512.20200217141432@mail.ru> From: Igor Mozolevsky Date: Mon, 17 Feb 2020 12:01:14 +0000 Message-ID: Subject: Re: is there a future for user accounting (getpw* replacement) To: Anthony Pankov Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48LjJc4Y80z451L X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mozolevsky@gmail.com designates 209.85.167.181 as permitted sender) smtp.mailfrom=mozolevsky@gmail.com X-Spamd-Result: default: False [-3.05 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hybrid-lab.co.uk]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[181.167.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.05)[ip: (-0.54), ipnet: 209.85.128.0/17(-3.00), asn: 15169(-1.68), country: US(-0.05)]; FORGED_SENDER(0.30)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; FREEMAIL_TO(0.00)[mail.ru]; RWL_MAILSPIKE_POSSIBLE(0.00)[181.167.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 12:01:53 -0000 On Mon, 17 Feb 2020 at 11:15, Anthony Pankov via freebsd-hackers wrote: > > Greetings, > > I'm wondering has anybody any thoughts about user accounting > provided at the system level? > > It seems that getpw* doesn't suit the needs of application services. > All applications has some external/internal mechanism for storing and > retrieving user properties (settings, roles etc). Furthermore they > implement own security policy based on this mechanism. > > Mostly it is done via LDAP connection or internal store (as for database). > > It seems that all application developers will be more happy if OS will > have a few functions to do the things such as: > - list users of some type; > - get user properties specific to application; > - get user roles specific to application > -? > > Does anybody has thoughts about what OS must provide to keep > applications consistency and make developers happier? I think it's dangerous to conflate *application* users with *system* users, why would you want to do that in the first place? -- Igor M. From owner-freebsd-hackers@freebsd.org Mon Feb 17 12:12:48 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 235F9257774 for ; Mon, 17 Feb 2020 12:12:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48LjYC1RpSz4DDl for ; Mon, 17 Feb 2020 12:12:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 01HCCWNO031501 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 17 Feb 2020 14:12:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 01HCCWNO031501 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 01HCCVhC031499; Mon, 17 Feb 2020 14:12:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 17 Feb 2020 14:12:31 +0200 From: Konstantin Belousov To: Dewayne Geraghty Cc: freebsd-hackers@freebsd.org Subject: Re: Why is not llvm-config executable included? Message-ID: <20200217121231.GB29554@kib.kiev.ua> References: <20200215185821.GV4808@kib.kiev.ua> <0f258cc4-7aae-b757-add0-e44c329c8255@heuristicsystems.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0f258cc4-7aae-b757-add0-e44c329c8255@heuristicsystems.com.au> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 48LjYC1RpSz4DDl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; IP_SCORE(0.00)[ip: (-3.14), ipnet: 2001:470::/32(-4.65), asn: 6939(-3.58), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 12:12:48 -0000 On Mon, Feb 17, 2020 at 09:03:49AM +1100, Dewayne Geraghty wrote: > On 16/02/2020 9:27 am, Konstantin Belousov wrote: > > One of the reason why llvm in base should not be used as llvm infrastructure > > is because llvm API and ABI is not stable across llvm releases, and exposing > > that would make compiler updates in stable impossible due to the stable > > branches guarantee of ABI stability. > > I think you're saying - don't build ports in a base (without the llvm > port), rather use a separate build jail with llvm port. I am not saying anything even close to that. I am claiming that libraries built as part of the /usr/bin/cc build in base should not be used for any other purposes. It is not trivial to use them, because they are not installed. Which is good for the reasons I explained in my first response. It might be that installing these libs in private manner would be useful because tom% ls -li /usr/bin/{cc,ld.lld,lldb} ~ 241736 -r-xr-xr-x 6 root wheel 66188728 28 янв. 13:21 /usr/bin/cc 241866 -r-xr-xr-x 1 root wheel 39837056 28 янв. 13:21 /usr/bin/ld.lld 241987 -r-xr-xr-x 1 root wheel 64386992 28 янв. 13:21 /usr/bin/lldb i.e. we might save around 100MB from the base install. But even if this is done, the libs are still strictly for base /usr/bin/cc. > > We used to build all ports in base and ship them to clients. Around > FreeBSD6 we started to build within a jailed environment, as we > supported i386 & amd64; something we still do. Though I'm concerned > that perhaps we should migrate (our jails) back to using gcc where-ever > possible, in the hope of avoiding future ABI incompatibility? > > In my experience replacing a base 'something' with the port of > 'something' must be done carefully. (our experience with > binutils and libressl, ultimately required removing all base "stuff" and > using workarounds like softlinks - a bit messy, but scriptable) > > Would using gcc, in the build jail, provide better insurance against ABI > breakage? I do not see how using gcc instead of clang would change anything regarding ABI. Also what ABI breakage are you talking about there ? From owner-freebsd-hackers@freebsd.org Mon Feb 17 12:56:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0CAC723869B for ; Mon, 17 Feb 2020 12:56:57 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from smtp36.i.mail.ru (smtp36.i.mail.ru [94.100.177.96]) (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 48LkX74G5lz40q5 for ; Mon, 17 Feb 2020 12:56:55 +0000 (UTC) (envelope-from ap00@mail.ru) Received: by smtp36.i.mail.ru with esmtpa (envelope-from ) id 1j3fxE-0004Vh-Nv; Mon, 17 Feb 2020 15:56:53 +0300 Date: Mon, 17 Feb 2020 15:56:51 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <419974027.20200217155651@mail.ru> To: Igor Mozolevsky CC: FreeBSD Hackers Subject: Re: is there a future for user accounting (getpw* replacement) In-Reply-To: References: <661730512.20200217141432@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-7564579A: B8F34718100C35BD X-77F55803: 0A44E481635329DB0E1AA8A03B392317D32E5E4886521736F9FEA8B0F5145E37D2CC67C7B686A935F688BCB05C26794DCC8ABFDCEB430A40407978A7B2C0D00300829216C2FC1324AF560845B571D7DB X-7FA49CB5: 0D63561A33F958A5DAEE30CEA4DE243F7956BB04AB2375D38B9919F3CEDB30618941B15DA834481FA18204E546F3947C17119E5299B287EEF6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8B974A882099E279BDA471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C2249505D71D783575ABE3AA81AA40904B5D9CF19DD082D7633A0BE77C518755DECA13AA81AA40904B5D98AA50765F790063734F2AC531863AAEDEC76A7562686271E8729DE7A884B61D135872C767BF85DA227C277FBC8AE2E8BDAE3FA6833AEA0C275ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85D9B7C4F32B44FF57285124B2A10EEC6C00306258E7E6ABB4E4A6367B16DE6309 X-D57D3AED: Y8kq8+OzVoxvgW9Op3aR8Fxwo7H2ZNxGP5qz8aO2mjTJzjHGC4ogvVuzB3zfVUBtENeZ6b5av1fnCBE34JUDkaJinJwwHx5ysVv9/YfT9udwNEOvzTh/sA== X-Mailru-Sender: D8D48EF70163D79D00784CDFC8FD310736D973F3AB9FBED9F7A467B04588471F8D85D87526EB286750D5CF8590B94F4EC77752E0C033A69E81198BD1A48777B793AC9912533B2342AE208404248635DF X-Mras: Ok X-Rspamd-Queue-Id: 48LkX74G5lz40q5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.100.176.0/20]; FREEMAIL_FROM(0.00)[mail.ru]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ipnet: 94.100.176.0/20(0.06), asn: 47764(0.25), country: RU(0.01)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[mail.ru:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[96.177.100.94.list.dnswl.org : 127.0.5.0]; HAS_X_PRIO_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[mail.ru,reject]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[mail.ru]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[mail.ru.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 12:56:57 -0000 =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Igor. =C2=FB =EF=E8=F1=E0=EB=E8 17 =F4=E5=E2=F0=E0=EB=FF 2020 =E3., 15:01:14: > On Mon, 17 Feb 2020 at 11:15, Anthony Pankov via freebsd-hackers > wrote: >> >> Greetings, >> >> I'm wondering has anybody any thoughts about user accounting >> provided at the system level? >> >> It seems that getpw* doesn't suit the needs of application services. >> All applications has some external/internal mechanism for storing and >> retrieving user properties (settings, roles etc). Furthermore they >> implement own security policy based on this mechanism. >> >> Mostly it is done via LDAP connection or internal store (as for database= ). >> >> It seems that all application developers will be more happy if OS will >> have a few functions to do the things such as: >> - list users of some type; >> - get user properties specific to application; >> - get user roles specific to application >> -? >> >> Does anybody has thoughts about what OS must provide to keep >> applications consistency and make developers happier? > I think it's dangerous to conflate *application* users with *system* > users, why would you want to do that in the first place? That is the question! First of all, I think there was no technical opportunity to conflate applications and system users at least because uid_t is 65535 max and lack of custom user properties. I can note some Cons for splitting *application* and *system* users: - users of one application is not a users of another application by design. Applications is hard to integrate (yes, there is ldap but...); - each application has own accounting implementation which enlarge attack surface. Furthermore, application developers do not really want to implement any user accounting parts because it is far away from application functioning. As a result it usually implemented "somehow". - applications users are out of system control. There is a system users, application users, and daemons. It seems there is no chance to do the thing really right in mean of access control of entire system (OS +applications). - etc. --=20 =D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC, Anthony mailto:ap00@mail.ru From owner-freebsd-hackers@freebsd.org Mon Feb 17 13:22:01 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5EFA52391B3 for ; Mon, 17 Feb 2020 13:22:01 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Ll542Kchz4NJj for ; Mon, 17 Feb 2020 13:22:00 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-oi1-f182.google.com with SMTP id z2so16632945oih.6 for ; Mon, 17 Feb 2020 05:22:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YGURFx+FaHy96YBR6IQog13jtAG5Nt0BBfRak+hOs1g=; b=g8+I2hY0W8lYLePA/xtJxr+X5CDjHNR+RGr5AUC+O9CdcsWZrkd5FZ9XG95SleGLQ5 2aG4Xg/KgyMrbosrtWo3JY0Mv3QSe2ovY16QLOkNEyWrJ3dy2R/NbJytU/bMOaiJx/j+ BSnlrpAulEDJSckMx7FtA3NO8KNfWEHL/65Zz5poX6FOQIwLowFN53ns+Xz9jY5BEYCm Ix74MV5dOYs+qLjSl2A0w0z8jryftqr1QDRzE67fcDK1yNz2v9cUXNyW9R6jT0Xxw3eP kzZupAYfQbMecAQYAaBkKLeMCVkE5VuAQ1xHBUdkKHDeG0G66Blz0NfMlmQ5BQCkEGD7 cwvA== X-Gm-Message-State: APjAAAVI0IeezlghkMOuMpRStfmOjOZMBOCdYPqvEKGhBbVNqearmRq/ rAV5sPMVaqk82nFV46UCPbEzn+FYLzl5nWP0vrg= X-Google-Smtp-Source: APXvYqwNIrNi9BB6HXvaA6t2DufJmtHnwr6VdXOayMp2Ce8QvSzPDbquk/bwv6vzr8EIwYHyQMDJIavmgpK6ihHlAtI= X-Received: by 2002:a54:4010:: with SMTP id x16mr10331707oie.174.1581945718792; Mon, 17 Feb 2020 05:21:58 -0800 (PST) MIME-Version: 1.0 References: <661730512.20200217141432@mail.ru> <419974027.20200217155651@mail.ru> In-Reply-To: <419974027.20200217155651@mail.ru> From: Igor Mozolevsky Date: Mon, 17 Feb 2020 13:21:22 +0000 Message-ID: Subject: Re: is there a future for user accounting (getpw* replacement) To: Anthony Pankov Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48Ll542Kchz4NJj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mozolevsky@gmail.com designates 209.85.167.182 as permitted sender) smtp.mailfrom=mozolevsky@gmail.com X-Spamd-Result: default: False [-3.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hybrid-lab.co.uk]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[182.167.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.01)[ip: (-0.31), ipnet: 209.85.128.0/17(-3.00), asn: 15169(-1.68), country: US(-0.05)]; FORGED_SENDER(0.30)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; FREEMAIL_TO(0.00)[mail.ru]; RWL_MAILSPIKE_POSSIBLE(0.00)[182.167.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 13:22:01 -0000 On Mon, 17 Feb 2020 at 12:56, Anthony Pankov wrote: > > I think it's dangerous to conflate *application* users with *system* > > users, why would you want to do that in the first place? > > That is the question! > > First of all, I think there was no technical opportunity to conflate > applications and system users at least because uid_t is 65535 max and > lack of custom user properties. > > I can note some Cons for splitting *application* and *system* users: > > - users of one application is not a users of another application by > design. Applications is hard to integrate (yes, there is ldap but...); ... and SASL, and PAM (if you really have to)... and Federation (if you really-really have to)... Why should the OS be "Application Aware"? > - each application has own accounting implementation which enlarge > attack surface. Furthermore, application developers do not really want > to implement any user accounting parts because it is far away from > application functioning. As a result it usually implemented > "somehow". You speak of enlarging the attack surface, but that attack surface is limited to the single application (or a badly designed collaboration of several)! You do realise that if one were to have a universal "user" awareness, then one compromised account exposes the whole system?! The problem you describe seems to be the "lazy app developers" who can't be bothered to do things properly and want to palm off what is essentially the application logic down to the layer below. > - applications users are out of system control. There is a system > users, application users, and daemons. It seems there is no > chance to do the thing really right in mean of access control > of entire system (OS +applications). If the application users are out the system control, then application users cannot interfere with the system, and that sounds like a very sound design! ;-) Best, -- Igor M. From owner-freebsd-hackers@freebsd.org Tue Feb 18 19:15:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E68D243576 for ; Tue, 18 Feb 2020 19:15:57 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48MVv02G4pz42Ws for ; Tue, 18 Feb 2020 19:15:56 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 4B683243574; Tue, 18 Feb 2020 19:15:56 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 49F94243573 for ; Tue, 18 Feb 2020 19:15:56 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48MVty6zqdz42Tt for ; Tue, 18 Feb 2020 19:15:54 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: by mail-pg1-x534.google.com with SMTP id d6so11407468pgn.5 for ; Tue, 18 Feb 2020 11:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :to; bh=r/xkrcpSq9z5GKMYJFQgAAm7Qrqlajy0ndrBhgiWYs8=; b=rR1hREbjxlzAOPwNwzc2VWQ6BepOllDToD3JszfyiNHmuw/EYOKvAMk4EFGGJs6Imm /sRBmghrYXutAbRjYydFp0Zipv7dJnV24SnsEArgHvb6TPCRtYeMEP8ujQ2B+K2nWbdr r+eJP7IyzeNXm4HTx4BdO4Lk1A1BDRnOidO6v3BcRzS/WzR7510ACDchmz3ybSNuOGpB K02/FXVjyt1uwJtj76Pxbluzur/fck3qGcCdThgSZ1zMzO6DK0UQb9+gVYyzEnzp0ZWH pPgvtmOcOxS0m4C+ru8FAS44j/3efmJhefucULBtITVoSAb+ee4DaNvFVsRdLSlt0aK4 ZBQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:to; bh=r/xkrcpSq9z5GKMYJFQgAAm7Qrqlajy0ndrBhgiWYs8=; b=Hhpbq9Y5e9dkg/CrwJ1FmC0iL8mzJZq5DnOPIs8u1fx3ovSfahrKs8eI78GV8r3jLo 5eERiT1w4ElZRYj046uYOgfRQVvBYY2yf9BZ/Mb1AjAI35yZZ8gSeJBCSfLEbko7Zu7L x39DZL0HtmDn6VMX8PE9U5deGNxc4T9ugzeXqzrY62Jkp+menP/LuObdy3DDf4dEU3QK ME4Z6Lqr3mCseFd401+uCdDwZihvAYmrc6xc5uwW9+UEOg7h1T9YwudyJsHcR3+EatMs 7H4wi9j18ZqRs4DfJRfs6cZMGbNdICTn0YZuKtXxYl5RviGzBRjZxuPLOjI1oGbsQ98l vpBQ== X-Gm-Message-State: APjAAAUkDE7ESwod14KBG7XGi3GmJc9ofJa1dyphvzKSzIHNONoLmjr6 txoabTRSk4HzwzZqOtHzDFpo8ZU= X-Google-Smtp-Source: APXvYqz3FhNi8J/VhiPqP+jiV0ggu03CSEypZmPwLykKg7EJxtSacaI7EwFfzomD8LQmztcbKAYM2w== X-Received: by 2002:a62:78c1:: with SMTP id t184mr22210473pfc.222.1582053352893; Tue, 18 Feb 2020 11:15:52 -0800 (PST) Received: from [192.168.0.103] ([203.90.98.200]) by smtp.gmail.com with ESMTPSA id e6sm5251091pfh.32.2020.02.18.11.15.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Feb 2020 11:15:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: rahul deshmukh Mime-Version: 1.0 (1.0) Date: Wed, 19 Feb 2020 00:45:49 +0530 Subject: Rsync copy tuneable Message-Id: <96840ED1-2F2C-4EF6-8BD5-6B7DEF1CB9B6@gmail.com> To: hackers@freebsd.org X-Mailer: iPad Mail (17C54) X-Rspamd-Queue-Id: 48MVty6zqdz42Tt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=rR1hREbj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rahuldshmkh1@gmail.com designates 2607:f8b0:4864:20::534 as permitted sender) smtp.mailfrom=rahuldshmkh1@gmail.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[200.98.90.203.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-8.94), ipnet: 2607:f8b0::/32(-1.89), asn: 15169(-1.68), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[4.3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 19:15:57 -0000 Hello hackers, I have one question, I am planning to copy date from onprem to AWS S3 using R= sync do I need tune any kernel parameters to optimise copy process in FreeBS= D or defaults are suffice? Any other suggestions will be helpful. Regards, Rdx Sent from my iPad= From owner-freebsd-hackers@freebsd.org Tue Feb 18 19:34:50 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 062EA24407B for ; Tue, 18 Feb 2020 19:34:50 +0000 (UTC) (envelope-from darkfiberiru@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48MWJn5Stvz4TBt for ; Tue, 18 Feb 2020 19:34:49 +0000 (UTC) (envelope-from darkfiberiru@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id B8956244079; Tue, 18 Feb 2020 19:34:49 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B84A5244078 for ; Tue, 18 Feb 2020 19:34:49 +0000 (UTC) (envelope-from darkfiberiru@gmail.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48MWJm3Ltvz4T9n for ; Tue, 18 Feb 2020 19:34:47 +0000 (UTC) (envelope-from darkfiberiru@gmail.com) Received: by mail-lj1-x22e.google.com with SMTP id x7so24351023ljc.1 for ; Tue, 18 Feb 2020 11:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KA1ch5vf4Z/zfpZ7TzyCBB1SxMwgTsn+NF13ef0lcLk=; b=mzNaV8Mdqv50Xd8YEqGZSlq+kyU+ifvT5Z287fWNqy9Gb8XNnVMT3/H3UmKq5NYhWO W8hvjU/OQurdgkvtc5AJdeBIcGhgClsUNT3AWTBgmjOtIOIeKmLfg1wHzfbiTbGhFtSy /eCV5F5U/9iMtuJaH/Rpoy9bGY0Et1DLduM0UgvJZyr6bN220zaYi9c+UdfZWyKSLnqx ceHvpxFMFQyb4QunCEnmWSKD0v0uW3sr8VAC+S20pTalVVy7sz7mI0TgdSRiMOIzoY4c EYlBvf0jvQDlsjUtmeM/kuysPE+4rQQKHGACKvSfb+e8aCq6ewEKdIhjTP5o2nofT0r9 4+BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KA1ch5vf4Z/zfpZ7TzyCBB1SxMwgTsn+NF13ef0lcLk=; b=LtyfIeyFyrGZvOgfFrFZUX+ydL31VrloF64HDoeolrT607fKEaSIOq0lcOWtKnsIRF JnbdApxv0OvoMoxKic7Ey80Hxans6Vrx0Zh8JwJ796yKgf1fiDOWQncalms/DfKK2x+E 5eMWraa4i2SbdvL5Bkc9GhgbdyixPFxly3JjXHBjtdrCjjrdUkogjNHquUGk1RxHQXjY Z4yyk5eXffmQRgMMC/T5tkK/lhNG4vIg/tTLyXW2lYtbfy6sBUC2bsgOKqfN7i81RmkV z6y+WVGePD8HlpaxTns+nTWDci6e2ACUdqRB+frDxUPPgCyqSofKRT5QrBECrykZF3oK 6UMg== X-Gm-Message-State: APjAAAXjvA5/nMX9AoWoXJl7P4e/dnXTAO2UKuovaHAQb/iAx8HIiThn vIbTZ6SpRIMok3+YWI94j/vCaG4Ic32OGwLVcK8= X-Google-Smtp-Source: APXvYqwd8R4c6f1v5Z0PEmlHGLavHd/L1hlYOCyaLNp/+gRK2B9EYPumar3tjgVtw/QliS8stTk9VLCiL/oWy1/nqJM= X-Received: by 2002:a05:651c:321:: with SMTP id b1mr13793236ljp.62.1582054485644; Tue, 18 Feb 2020 11:34:45 -0800 (PST) MIME-Version: 1.0 References: <96840ED1-2F2C-4EF6-8BD5-6B7DEF1CB9B6@gmail.com> In-Reply-To: <96840ED1-2F2C-4EF6-8BD5-6B7DEF1CB9B6@gmail.com> From: Nick Wolff Date: Tue, 18 Feb 2020 14:34:33 -0500 Message-ID: Subject: Re: Rsync copy tuneable To: rahul deshmukh Cc: hackers@freebsd.org X-Rspamd-Queue-Id: 48MWJm3Ltvz4T9n X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=mzNaV8Md; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of darkfiberiru@gmail.com designates 2a00:1450:4864:20::22e as permitted sender) smtp.mailfrom=darkfiberiru@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.27), ipnet: 2a00:1450::/32(-2.42), asn: 15169(-1.68), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[e.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 19:34:50 -0000 You probably want to look at rclone to copy the data to use a properly object aware method that is parallel. How were you planning on using rsync to do the migration? Thanks, Nick Wolff On Tue, Feb 18, 2020 at 2:16 PM rahul deshmukh wrote: > Hello hackers, > I have one question, I am planning to copy date from onprem to AWS S3 > using Rsync do I need tune any kernel parameters to optimise copy process > in FreeBSD or defaults are suffice? Any other suggestions will be helpful. > > Regards, > Rdx > > Sent from my iPad > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Tue Feb 18 19:40:06 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B4EFC244327 for ; Tue, 18 Feb 2020 19:40:06 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48MWQt1SXxz4XV8 for ; Tue, 18 Feb 2020 19:40:06 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 307E8244325; Tue, 18 Feb 2020 19:40:06 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F937244324 for ; Tue, 18 Feb 2020 19:40:06 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48MWQs285sz4XSx for ; Tue, 18 Feb 2020 19:40:05 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: by mail-il1-x12d.google.com with SMTP id l4so18396605ilj.1 for ; Tue, 18 Feb 2020 11:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9G0iB696HmPDGsLabqI5sjKORn8tv2AmBL0hOxGCWNA=; b=qL3fig2n6c5Nvl793P/dlMus4gdZ8mV9yn+Q2ojS5XrxOd1+Hbzu3EmNP4HXTQTy2w R89egy+NMHHzV8RI0OYohd+n7fWQpU9d8WAY/k8AehIDwHYIt2dnTRnCh3wTUHXIgQDa qKk+zEfJNp2Wz33W9SfpcgL18vCBz574dKKH/hQ4hEQUkAM3LuQ/9aomZm336jJoWXit 0Y4RwByMNfQhQDvQGbwaEYlIXeTl91nMB+pujBXn6h/yf7PUl3s0P8HNccBw5LWOgbgX 7WIVzOjT0yOaRitBDtxG8VFynkt3l7WlDo8j7qp4MO6Mf7S7149Ty4uTSZwu4DPb2PK3 A5XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9G0iB696HmPDGsLabqI5sjKORn8tv2AmBL0hOxGCWNA=; b=rXCw4dIOJXkkV/Rp5eSChEZ7SCVUK+i+0zIkgj3+woJT9kZDFBomwJJAbk4k4PFHbO 0DwVGMSb0rWL/1jZ7N0vSjpzgsgSPMdcgFTSTP70vzYUO3ZKY2OTjs6gffN1thySEP2G 3aJaCGjbKdqft69W0Ykm2cjO+Q/DKUF2Y6hiVHY96AccH6q452W6vszJubMUTaLqUc1n g36RajV0VoOBPHN/xWxb9M+SEtBtY1eZsQmOye4lEStXgK0JS3RO7if91+VDuSP44RfX Unmy2IhdiNPHH3LvtkLpT6w3pIVNViQ7pxUuHZXnafxlsjbFdb18+LgH9VpZekGMEhFp Fbsg== X-Gm-Message-State: APjAAAVQkxpqaF/yR78VyKuo/2VedJwlXmIbIonY0//FLYfCNNeh0Va6 6u1xvkrhom2tPSh9CGxfJf1SmSpWXbFXjExX6Q== X-Google-Smtp-Source: APXvYqzOyoS36KS08IoW/ozJHJoQ9USbBjFLMIKLBD0W8KoUh4Kj+zmse2/a1j+ATFfXPZ0kiVeC17jrz8+cG0kjA9k= X-Received: by 2002:a92:d3c6:: with SMTP id c6mr21621591ilh.228.1582054803996; Tue, 18 Feb 2020 11:40:03 -0800 (PST) MIME-Version: 1.0 References: <96840ED1-2F2C-4EF6-8BD5-6B7DEF1CB9B6@gmail.com> In-Reply-To: From: rahul deshmukh Date: Wed, 19 Feb 2020 01:09:51 +0530 Message-ID: Subject: Re: Rsync copy tuneable To: Nick Wolff Cc: hackers@freebsd.org X-Rspamd-Queue-Id: 48MWQs285sz4XSx X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=qL3fig2n; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rahuldshmkh1@gmail.com designates 2607:f8b0:4864:20::12d as permitted sender) smtp.mailfrom=rahuldshmkh1@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-8.61), ipnet: 2607:f8b0::/32(-1.89), asn: 15169(-1.68), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 19:40:07 -0000 Hi Nick, I would be using aws storage gateway as nfs mount point on my host to perform the rsync. I will certainly look into it rclone. Thank you. Regards, Rdx On Wed, Feb 19, 2020, 1:04 AM Nick Wolff wrote: > You probably want to look at rclone to copy the data to use a properly > object aware method that is parallel. > > How were you planning on using rsync to do the migration? > > Thanks, > > Nick Wolff > > On Tue, Feb 18, 2020 at 2:16 PM rahul deshmukh > wrote: > >> Hello hackers, >> I have one question, I am planning to copy date from onprem to AWS S3 >> using Rsync do I need tune any kernel parameters to optimise copy process >> in FreeBSD or defaults are suffice? Any other suggestions will be helpful. >> >> Regards, >> Rdx >> >> Sent from my iPad >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> > From owner-freebsd-hackers@freebsd.org Tue Feb 18 19:51:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 792212448CA for ; Tue, 18 Feb 2020 19:51:47 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48MWhM12HYz3DWw for ; Tue, 18 Feb 2020 19:51:47 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 20BBD2448C9; Tue, 18 Feb 2020 19:51:47 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1BA8E2448C8 for ; Tue, 18 Feb 2020 19:51:47 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48MWhJ0CpSz3DTw for ; Tue, 18 Feb 2020 19:51:43 +0000 (UTC) (envelope-from rahul.dshmkh1@gmail.com) Received: by mail-il1-x12d.google.com with SMTP id f5so18445584ilq.5 for ; Tue, 18 Feb 2020 11:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Qwk3Hm+RD3HYkQDtkz6undaTVEfbbwo6iVSWC/BciM=; b=h+3TbM/sxIwUs+ytOlwh/56TXKGVOpq0kIS9b5OEH3f1ObQQMMfVB2wBG/cv0qeu0I syYQh5fYK/BC9WzK75QX599GHwLV12oXdGcXGKQ/rtaOCeUV4WIf5T1n/M8opwuSDn1H pN9LuUPyer0UW7eBG6Zwe+AIxXxIwe7NSJfAFj7o+tYEqgWVk4CZb8AkpMDc0/76fKGz 2PiMonbhnLdHCUtJmRqdC8YkxzAth21QqToWXZdXqBrP3EPsQRO/6Zgf94qZ9uGYDtUq zjh4zXA78EVm/r+UWcNPq87KSGPJKiWYGUDGzYeQwb9/I3r/WK1hmiXMxx0u+wKernMi K/Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Qwk3Hm+RD3HYkQDtkz6undaTVEfbbwo6iVSWC/BciM=; b=nv5p0lnybcKhjyk84JJWUFRS2fg19jBnQ2FSOIOG0whLUsEeT9HqyqMmnAO3EFjkFZ fmC9tAPW9JVF/72FRg7/jQz8kNNc64F4kPGiMz1eXcJ0/Cq6yDODj4H31UDL0rw0jsyd kjVegwVv27GVFgoiQnbab7U2osWDS4y2j9D599i/wB/glJlByIQ9NlltgG6NN3hR7BGx xh4EhalRcQ1icmk7Tld0O60VTjyOmzUe2yVd9bGYTSlWHVFFuRhklF8So2KlNLJukKBR ZVj1SbuhhNRwnGk2MPNzpbrjk7U5oCY5yJM2zKEq00DjcoW8bzI996ZAE/uDHrvtLNYv 2ilg== X-Gm-Message-State: APjAAAVnnIbNeQDgrTOpd5xDvY0Wh5UBYCA1GZ65vW/cywuYxDjoY6y0 M+oY8d61PsJopXRnT8HzhY3HTjjIwCE1Hu9oBw== X-Google-Smtp-Source: APXvYqyloZlzLT63L+WE/P7JS6dm55YmF/2BwFpz9EZ3seMkK3RLg96qaNOiSRVFGf4qiB9dFvQXxQcKGoaLBXUNa/A= X-Received: by 2002:a05:6e02:5cb:: with SMTP id l11mr19978773ils.307.1582055503206; Tue, 18 Feb 2020 11:51:43 -0800 (PST) MIME-Version: 1.0 References: <96840ED1-2F2C-4EF6-8BD5-6B7DEF1CB9B6@gmail.com> In-Reply-To: From: rahul deshmukh Date: Wed, 19 Feb 2020 01:21:30 +0530 Message-ID: Subject: Re: Rsync copy tuneable To: Nick Wolff Cc: hackers@freebsd.org X-Rspamd-Queue-Id: 48MWhJ0CpSz3DTw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=h+3TbM/s; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rahuldshmkh1@gmail.com designates 2607:f8b0:4864:20::12d as permitted sender) smtp.mailfrom=rahuldshmkh1@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-8.58), ipnet: 2607:f8b0::/32(-1.89), asn: 15169(-1.68), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 19:51:47 -0000 I can bypass storage gateway using rclone i believe based as per initial reading, is it better than aws s3 cli? Will give it a try tomorrow. -Rdx On Wed, Feb 19, 2020, 1:09 AM rahul deshmukh wrote: > Hi Nick, > > I would be using aws storage gateway as nfs mount point on my host to > perform the rsync. > > I will certainly look into it rclone. Thank you. > > Regards, > Rdx > > On Wed, Feb 19, 2020, 1:04 AM Nick Wolff wrote: > >> You probably want to look at rclone to copy the data to use a properly >> object aware method that is parallel. >> >> How were you planning on using rsync to do the migration? >> >> Thanks, >> >> Nick Wolff >> >> On Tue, Feb 18, 2020 at 2:16 PM rahul deshmukh >> wrote: >> >>> Hello hackers, >>> I have one question, I am planning to copy date from onprem to AWS S3 >>> using Rsync do I need tune any kernel parameters to optimise copy process >>> in FreeBSD or defaults are suffice? Any other suggestions will be helpful. >>> >>> Regards, >>> Rdx >>> >>> Sent from my iPad >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to " >>> freebsd-hackers-unsubscribe@freebsd.org" >>> >> From owner-freebsd-hackers@freebsd.org Wed Feb 19 07:58:23 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 99043252088 for ; Wed, 19 Feb 2020 07:58:23 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from smtp15.mail.ru (smtp15.mail.ru [94.100.176.133]) (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 48Mqpk1gKkz3LRc for ; Wed, 19 Feb 2020 07:58:21 +0000 (UTC) (envelope-from ap00@mail.ru) Received: by smtp15.mail.ru with esmtpa (envelope-from ) id 1j4KFO-0007nB-TK; Wed, 19 Feb 2020 10:58:19 +0300 Date: Wed, 19 Feb 2020 10:58:17 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <77695285.20200219105817@mail.ru> To: Igor Mozolevsky CC: FreeBSD Hackers Subject: Re: is there a future for user accounting (getpw* replacement) In-Reply-To: References: <661730512.20200217141432@mail.ru> <419974027.20200217155651@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-7564579A: B8F34718100C35BD X-77F55803: 0A44E481635329DB0E1AA8A03B392317D32E5E4886521736714D0EA31FF8009265C502D28932F754F688BCB05C26794D11FC32B0A011826D92A1D1BB6FE7615A399CEB365C9B77261D2CD58DDFFB006F X-7FA49CB5: 0D63561A33F958A57B8CAA71B4E1D4822CA3BC1D2873107FB285788E247AC4CE8941B15DA834481FA18204E546F3947CCE135D2742255B35F6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8BF80095D1E17F4578A471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C2249505D71D783575ABE3AA81AA40904B5D9CF19DD082D7633A0BE77C518755DECA13AA81AA40904B5D98AA50765F790063734F2AC531863AAEDEC76A7562686271E8729DE7A884B61D135872C767BF85DA227C277FBC8AE2E8BDAE3FA6833AEA0C275ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85D9B7C4F32B44FF57285124B2A10EEC6C00306258E7E6ABB4E4A6367B16DE6309 X-D57D3AED: Y8kq8+OzVoxvgW9Op3aR8Fxwo7H2ZNxGP5qz8aO2mjTJzjHGC4ogvVuzB3zfVUBtENeZ6b5av1fnCBE34JUDkaJinJwwHx5ysVv9/YfT9uel7S36v6jwZg== X-Mailru-Sender: D8D48EF70163D79D00784CDFC8FD3107C54BE1062458E974C31F381AFF9C8BE9DD40DC63F2C6AA4550D5CF8590B94F4EC77752E0C033A69E81198BD1A48777B793AC9912533B2342AE208404248635DF X-Mras: Ok X-Rspamd-Queue-Id: 48Mqpk1gKkz3LRc X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail2]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[133.176.100.94.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:94.100.176.0/20]; FREEMAIL_FROM(0.00)[mail.ru]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[mail.ru:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[mail.ru,reject]; IP_SCORE(0.00)[ipnet: 94.100.176.0/20(0.06), asn: 47764(0.25), country: RU(0.01)]; RCVD_COUNT_ZERO(0.00)[0]; RCVD_IN_DNSWL_LOW(-0.10)[133.176.100.94.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[mail.ru]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[mail.ru.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 07:58:23 -0000 > On Mon, 17 Feb 2020 at 12:56, Anthony Pankov wrote: > >> > I think it's dangerous to conflate *application* users with *system* >> > users, why would you want to do that in the first place? >> >> That is the question! >> >> First of all, I think there was no technical opportunity to conflate >> applications and system users at least because uid_t is 65535 max and >> lack of custom user properties. >> >> I can note some Cons for splitting *application* and *system* users: >> >> - users of one application is not a users of another application by >> design. Applications is hard to integrate (yes, there is ldap but...); > ... and SASL, and PAM (if you really have to)... and Federation (if > you really-really have to)... Why should the OS be "Application > Aware"? >> - each application has own accounting implementation which enlarge >> attack surface. Furthermore, application developers do not really want >> to implement any user accounting parts because it is far away from >> application functioning. As a result it usually implemented >> "somehow". > You speak of enlarging the attack surface, but that attack surface is > limited to the single application (or a badly designed collaboration > of several)! You do realise that if one were to have a universal > "user" awareness, then one compromised account exposes the whole > system?! The problem you describe seems to be the "lazy app > developers" who can't be bothered to do things properly and want to > palm off what is essentially the application logic down to the layer > below. >> - applications users are out of system control. There is a system >> users, application users, and daemons. It seems there is no >> chance to do the thing really right in mean of access control >> of entire system (OS +applications). > If the application users are out the system control, then application > users cannot interfere with the system, and that sounds like a very > sound design! ;-) I think it is greatly depends of system appliance. If we speak about *system* as of part of IT infrastructure that provides some technical service then I fully agree. Excess users is disadvantage and OS survival is equal to *system* survival. But if our deployment include applications human interact with then *system* concept goes wider. In this case OS survival is not equal to *system* survival. When users/orgs lost their data or facing *system* malfunction they don't care that underlining OS did survive and not compromised. I think that in wider *system* concept idea to bring to OS fine tuned users accounting that will be shared between applications have to be considered. -- Best regards, Anthony mailto:ap00@mail.ru From owner-freebsd-hackers@freebsd.org Wed Feb 19 08:22:32 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 52D2A252C41; Wed, 19 Feb 2020 08:22:32 +0000 (UTC) (envelope-from babupalit@gmail.com) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48MrLZ5qXYz4RNw; Wed, 19 Feb 2020 08:22:30 +0000 (UTC) (envelope-from babupalit@gmail.com) Received: by mail-oi1-x229.google.com with SMTP id q84so23017402oic.4; Wed, 19 Feb 2020 00:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4J3GeLY3nbFQj1QR48LzVMbrsfkFteeIrBeO23XvwXg=; b=LXlc6E32KIvten3dGRz5a+ohXHhrCj6/JEQSr6Jcr96WAnPVehMBKiJ3P4DERVzKIG QZ8fkJuIo87mS3FAcunux+uscC5W2cejp2zGUzrk2CrkJ1H0a6nV9LTL2R17M7v1Hl6y 4DGfJdaZFxFEn/19rCdgC4HGMrOl+X5iA2XejMI7rqvte6Mh9R4Evb32+81Cks1uDDhN 1HgsWNdXIIhVTToXyyF2N4R9J8q4QKIHOMBCgSZOC5NyAFqhelkno+H1Xs+j5/eXxwiV eKrqenu9mE4zr/Km5jzCD68E/hCjAchCImcdIjtAdENW93m+ouNsJftVHEWt/qLebbMv Rm1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4J3GeLY3nbFQj1QR48LzVMbrsfkFteeIrBeO23XvwXg=; b=n6tILMGoKCXIgfl1lMt13dn5qh2mDegD3ovhWY0x9Uu+Pl2eJ/iIY8zExIIeyBb2VL 3TsxqZrw2/csA85BR0huJmnpeSqV/My7kNbuJ0XLemKgirZiZNjdG/84I4GU0clmkynC GW5dEGoV3+HWjBn98wzaaaskgXVLK1lAzyLfCsYnuir7rxVNGl2vOm2MoG1mr7/dkc3r QMpm6HQ/GGTh/ptvzPNtb8MvLDBjalXRZ9B9Sbo/Pm9yHylnWT+UnR5xA1JqWMd1Q9WA I9UKgh5+u19G+PM0Vn5IfpD2jCIdgtiLF5urvY33XAHpklUtnDWsfeMduXZkDNSI9RP7 RmCw== X-Gm-Message-State: APjAAAXJdMZyM+oa1pqKjc7I8gmDHD0sCVwoXLGBi/1os4kqfOqqw4R8 XIaYe3GjdxMI2P7ekTfhc+o8UwcORXQ8mdt7Ud4ia+P5 X-Google-Smtp-Source: APXvYqxGRHkcA9SiXICrDljeNu3V26U3cqJvbxymXIK7jFYa9IJUjjRO2QimUUc7e/YOvc//zu0X1B1GGZX4IX74kxY= X-Received: by 2002:aca:814:: with SMTP id 20mr3942792oii.159.1582100549397; Wed, 19 Feb 2020 00:22:29 -0800 (PST) MIME-Version: 1.0 From: Arpan Palit Date: Wed, 19 Feb 2020 13:52:18 +0530 Message-ID: Subject: msleep_spin is failed to waken up even after wakeup routine is invoked for the same. To: freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org X-Rspamd-Queue-Id: 48MrLZ5qXYz4RNw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=LXlc6E32; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of babupalit@gmail.com designates 2607:f8b0:4864:20::229 as permitted sender) smtp.mailfrom=babupalit@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.00)[ip: (-8.50), ipnet: 2607:f8b0::/32(-1.89), asn: 15169(-1.68), country: US(-0.05)]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[9.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 08:22:32 -0000 Hi, I am facing one issue where wakeup rountine call is unable to waken up a msleep_spin routine call with a timeout value of 10 Seconds. The real scenario is as follows: post a hardware command and sleep using msleep_spin routine till interrupt comes, After getting the interrupt waken up the sleeping process using wakeup_one/wakeup routine call. As there are more than 2048 command and 16 parallel threads are running, observed randomly *one or two of the posted command* is *timing out* for which the *interrupt has came and also wakeup routine is invoked *after getting the interrupt for the same command. Note: *The issue is not seen when number of commands are less than 2048 with timeout of 10 seconds. *The issue can be seen with less number of commands also when timeout value 1 second. Can anyone please provide me an optimized way to schedule the process or a better way to do the scheduling. Thanks, Arpan Palit From owner-freebsd-hackers@freebsd.org Wed Feb 19 08:44:03 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DA44D25333E; Wed, 19 Feb 2020 08:44:03 +0000 (UTC) (envelope-from babupalit@gmail.com) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48MrqP5NsQz44Ff; Wed, 19 Feb 2020 08:44:01 +0000 (UTC) (envelope-from babupalit@gmail.com) Received: by mail-ot1-x32f.google.com with SMTP id 59so22374795otp.12; Wed, 19 Feb 2020 00:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dAD/IkF8ebZ665SDZJVBjGrvclsHc0hA8qyeedckxmI=; b=Ts4WnTO/uLgrZSc+g6SBsVmqtYppMUCtlPGEhaY9PK3NRk/Mh0EGUuYrloZI0/3DJ/ eJ+NHlmA1353snO+6g2ezKOuVhU8YWssmrOl8y7ADcAK+AcD0G276+lukVklNkRASGge Xzj/F9X8l5tCgEeH16Zw93qSJCWGat0HUe4+lbL/dV6cEDmr1sA6LeHFJHD7ivJaDC+y NH6SEp866kxDXVvhQi3+Ewd357gexT43ADe+4wa+e+tAvecenm1NbASnWMgO6x8WxjWN M0pfD+iPl+gux2HEyvVq39+HF4ZBcJo7nSmNx90k5ovWHMijv94H2+VemtWe+t3u5E89 yTGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dAD/IkF8ebZ665SDZJVBjGrvclsHc0hA8qyeedckxmI=; b=SJ49Z3/b2wWVDKzQPdc7ZsIB37jT2/lf2LhBUv2/9m8cYohlZrxg6tBJw8LUtnfVB7 XOVni4HOYWrKS1pxDU0vb7Lg2UxzbrcpVunl/3DFSE+MmwD2/kSSTG8xjQ88NKVOU17V /ULuxa/xWXFCvxFp7ZCzFwdcZqo1MUahQhWPQs5qfEsCJKAGDP9CG8yvNzGadoJMzyjE CtM2GttkOvxgaaU2HzImdq2RUC5sTPxRv7qRqnBrrCS73idPKSzIvzYinzoa6VMfhkML Oatmog/FEuUXZnrIf7ZUZlNW0zaN9u3frc0bpYhlVV44r2kUlZouRKhWI+pQBH7uF1// yY4A== X-Gm-Message-State: APjAAAUHunk3U0YVBOfurzqzflEd9Ea4DGVrfE5LjAG3pzJ9H6pCKM1J /s7yqcQdvrN62nZG+1EksL6m0cevGL9cvwV+FOqbgZYP X-Google-Smtp-Source: APXvYqzGQczGEAQqIWJvqfw7Jap9mmygdGCgPKR5XN3xLEoFQYTWT13dQilWFfYiQ38f9dgcnG5JahYJuxDvd8cEO38= X-Received: by 2002:a05:6830:139a:: with SMTP id d26mr19542074otq.75.1582101839884; Wed, 19 Feb 2020 00:43:59 -0800 (PST) MIME-Version: 1.0 From: Arpan Palit Date: Wed, 19 Feb 2020 14:13:48 +0530 Message-ID: Subject: msleep_spin is failed to waken up even after wakeup routine is invoked for the same. To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org X-Rspamd-Queue-Id: 48MrqP5NsQz44Ff X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Ts4WnTO/; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of babupalit@gmail.com designates 2607:f8b0:4864:20::32f as permitted sender) smtp.mailfrom=babupalit@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.00)[ip: (-7.81), ipnet: 2607:f8b0::/32(-1.89), asn: 15169(-1.68), country: US(-0.05)]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[f.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 08:44:03 -0000 Hi, I am facing one issue where wakeup rountine call is unable to waken up a msleep_spin routine call with a timeout value of 10 Seconds. The real scenario is as follows: post a hardware command and sleep using msleep_spin routine till interrupt comes, After getting the interrupt waken up the sleeping process using wakeup_one/wakeup routine call. As there are more than 2048 command and 16 parallel threads are running, observed randomly *one or two of the posted command* is *timing out* for which the *interrupt has came and also wakeup routine is invoked *after getting the interrupt for the same command. Note: *The issue is not seen when number of commands are less than 2048 with timeout of 10 seconds. *The issue can be seen with less number of commands also when timeout value 1 second. Can anyone please provide me an optimized way to schedule the process or a better way to do the scheduling. Thanks, Arpan Palit From owner-freebsd-hackers@freebsd.org Wed Feb 19 12:39:36 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 22B20238E8C for ; Wed, 19 Feb 2020 12:39:36 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48My3B42Zcz4Yk0 for ; Wed, 19 Feb 2020 12:39:34 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-oi1-f174.google.com with SMTP id p125so23612923oif.10 for ; Wed, 19 Feb 2020 04:39:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TM2ujgRky5+ul2qLbB8pkFWc/PhTka/XQISgGJuKtZE=; b=CCCUgbndtx7oUOuyz9Kmbgv2QKZ8tXxFcfDgXMCaYpdw2y/szWhZheoeGivDNu0ICG +oYWgjLRjYl1kHAMHocloFby8QjpggHoL/ST6yC7yHl9lRmHSlkzc/od3TSQg84vCc8G A5Dp/hADFVEvmeDf/4Cz88c4fObm7wE46cZlWNFL3rAwq3CmeGONqBHYmO9KBBOJBeyX AMQNFzPBEGLLOF3V40pphRtVC+JKr/LqrYnfgxq0aFlSFj9zLPjdDwO/DtmJyXZn8Kp4 VudtRVEpa/+X3Dr9AojPgz+TBIx7+uMwBwUye/c0mxColszQQ7qFiQaZpyE6o0Xepyw3 UsVg== X-Gm-Message-State: APjAAAXe6bs2LFEoBhpLyZhIlaEpJJwb6JWynr4DFy4lmWgNiGuQnNTb G3khJdx+xMPP4Qy83WFO8CAEVTeRxsVjOB9Uz5H/lg== X-Google-Smtp-Source: APXvYqyN0VMSTe1SOx0024FeuqTDYxwtBtXQP8/pL9vAt08JtmMGhWhBvIVyPRyTj/NrqAbbRuen6JtzQKTdOBuPca8= X-Received: by 2002:aca:d5d3:: with SMTP id m202mr4257327oig.161.1582115973194; Wed, 19 Feb 2020 04:39:33 -0800 (PST) MIME-Version: 1.0 References: <661730512.20200217141432@mail.ru> <419974027.20200217155651@mail.ru> <77695285.20200219105817@mail.ru> In-Reply-To: <77695285.20200219105817@mail.ru> From: Igor Mozolevsky Date: Wed, 19 Feb 2020 12:38:57 +0000 Message-ID: Subject: Re: is there a future for user accounting (getpw* replacement) To: Anthony Pankov Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48My3B42Zcz4Yk0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mozolevsky@gmail.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=mozolevsky@gmail.com X-Spamd-Result: default: False [-3.05 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hybrid-lab.co.uk]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[174.167.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.05)[ip: (-0.55), ipnet: 209.85.128.0/17(-3.00), asn: 15169(-1.68), country: US(-0.05)]; FORGED_SENDER(0.30)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; FREEMAIL_TO(0.00)[mail.ru]; RWL_MAILSPIKE_POSSIBLE(0.00)[174.167.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[igor@hybrid-lab.co.uk,mozolevsky@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 12:39:36 -0000 On Wed, 19 Feb 2020 at 07:58, Anthony Pankov wrote: > I think it is greatly depends of system appliance. If we speak > about *system* as of part of IT infrastructure that provides some > technical service then I fully agree. Excess users is disadvantage > and OS survival is equal to *system* survival. > > But if our deployment include applications human interact with > then *system* concept goes wider. In this case OS survival is not > equal to *system* survival. When users/orgs lost their data or facing > *system* malfunction they don't care that underlining OS did > survive and not compromised. I think that in wider *system* concept > idea to bring to OS fine tuned users accounting that will be shared between > applications have to be considered. Well, a user might care if another user steals the former's data in a misconfigured system by bypassing application admission control and going straight to the OS! Like I said before, by the sound of it, what you want is either RFC4422 (aka SASL), or PAM, if you really have to! Best, -- Igor M. From owner-freebsd-hackers@freebsd.org Wed Feb 19 14:42:48 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 94C3D23C719 for ; Wed, 19 Feb 2020 14:42:48 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48N0nN0YH9z4WK6 for ; Wed, 19 Feb 2020 14:42:47 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1582123366; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=DFaz1DccmdgBSyHZ1GpufBnWGUxfjcFrbcMEPbFTJhutwvbLA0Xaltn0VgU2pAHXlUarNaTZoCBx3 nx+VlkBH00kDxGwObGK0yg/YVbEkfu9RY4GNPvnzhIKhRBlCQcVSqJfcTlhDZtrcHUrzQRcXkwgnuS ExfDPT+EXzdGMKt/OeWv50yYNGo9V6hYpIGA2aifMvY8GSbOq0UCh5YijQp1GebNGlCN+lU6uFmTpW k/5jjf5MsHLtvvtjwDCvitEht+7j35W8lT27zzZ4HWbshMNq8I/Oh3LOJToz4FoWoYig9vLicbNLWX GuEHG3Z5eGS+GdigbcY2O65pObvXbQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=qap6KxL2+l0uV+1spGLtWGwepqTlKT5dVD4gNJT6rd8=; b=UhSeS3zCv+3mNc5yBCFgvu+PC6y6p8+ad08VZT+ZwL209Q3bZNQjrjDwBVdfbBItxj7fUtdNvWnCv 1jKWprJZJABCkuZSxEhgI+kPg1U71mxN4XZr5m2efiac6/ttHDlsNs1t7LtZBNxA7sN2qfca4KRwOH 6KwIo5nGpS9/lp8K2BfmjtV2kbXm4LoypQn4I3frFpoYyvbCM+xDdnlp/cxLH95P1H+pLVPSp/CzYP G5MDeH7P0QRgptjFC+NY7ZRJuES1/6tl0he0kW33SSSwSl/ikuH9ABEizZEtaW1lXGsnNreKs6wxgn o9csMV01vDcSnWFOV1b5RT2zvIczupQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=qap6KxL2+l0uV+1spGLtWGwepqTlKT5dVD4gNJT6rd8=; b=M4ta7y8TK4jRrnKqL9oT78ecGO4XeYZPwErXNv34oUNVCzi0JQKqNVRbGoh22qMYBlECEQf1C3WWk xex9pZ9q3K3YyoFUeKfBsgQpqF3LwkHoImlMFg+2gIXVuihQu8US7LVBp3WEg7vt0jWV33tehC+9rq zGUri5LJcJglq+oxAYmSfMx8k4sdAsyrbnsDn0Kg7UgdFc0iXVkS41J6YsLLOsb4R4qUfVrrl7E+ZO pil5TgyGPwYhv5aU12QIcAm71mE3/DN0L/pt8WWz3b/JRjTF0b6JtMhQQGxqPbbQ8ZZNcawO+y1c9G RkLYCW72mKeKJtHFCCmM3uzEVYAGc2Q== X-MHO-RoutePath: aGlwcGll X-MHO-User: 16fe6f1f-5326-11ea-b80d-052b4a66b6b2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 16fe6f1f-5326-11ea-b80d-052b4a66b6b2; Wed, 19 Feb 2020 14:42:45 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 01JEgi3o002972; Wed, 19 Feb 2020 07:42:44 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <890a299c074fc83a02911583531d686257924be8.camel@freebsd.org> Subject: Re: msleep_spin is failed to waken up even after wakeup routine is invoked for the same. From: Ian Lepore To: Arpan Palit , freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Date: Wed, 19 Feb 2020 07:42:44 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48N0nN0YH9z4WK6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.97)[-0.968,0]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 14:42:48 -0000 On Wed, 2020-02-19 at 14:13 +0530, Arpan Palit wrote: > Hi, > > I am facing one issue where wakeup rountine call is unable to waken up a > msleep_spin routine call with a timeout value of 10 Seconds. > > The real scenario is as follows: post a hardware command and sleep using > msleep_spin routine till interrupt comes, After getting the interrupt waken > up the sleeping process using wakeup_one/wakeup routine call. As there are > more than 2048 command and 16 parallel threads are running, > observed randomly *one or two of the posted command* is *timing out* for > which the *interrupt has came and also wakeup routine is invoked *after > getting the interrupt for the same command. > > Note: > *The issue is not seen when number of commands are less than 2048 with > timeout of 10 seconds. > *The issue can be seen with less number of commands also when timeout value > 1 second. > > Can anyone please provide me an optimized way to schedule the process or a > better way to do the scheduling. > > Thanks, > Arpan Palit > Is there any chance this is the classic "missed wakeup" scenario, where the wakeup happens before the thread enters msleep_spin()? That can happen with code structured like enqueue_request(req); err = msleep_spin(req, etc); /* Handle done req or timeout */ and a fix is to structure the code using the same idiom required for pthread_cond_wait() in userland, something like: req->doneflag = false; enqueue_request(req); while (!req->doneflag && err == 0) err = msleep_spin(req, etc); /* Handle done req or timeout */ and of course on the interrupt handler side you need something like /* lock mutex, do hardware stuff */ req->doneflag = true; wakeup(req); /* unlock mutex */ -- Ian From owner-freebsd-hackers@freebsd.org Thu Feb 20 04:28:13 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8DAF1252A0E for ; Thu, 20 Feb 2020 04:28:13 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48NM5m0l3wz4Bl2 for ; Thu, 20 Feb 2020 04:28:11 +0000 (UTC) (envelope-from lichray@gmail.com) Received: by mail-io1-xd31.google.com with SMTP id z16so3148967iod.11 for ; Wed, 19 Feb 2020 20:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=v9l+yaF07+xrhvIb4HVGbD7I6KEmQ9Rg1YkRUgXMdSg=; b=olplb6/F62DgQiHp5Oi3c2R+Hcg9v5PjYX2k9OxQelrem61l3jzyfm0iwi3qaur6aP vVM9rEci5+T4bNK+u08CgqaRJPOn1YBhYuwApviXi5j/F9MRwX52Ish56YDtnzgiEiHN dpx+mjq1B4imZR8h0A6RkVoag3JgHG/+E5Hr7VVPSyDo9vkQJgENTbMoBw1nyYUUIywZ c/wnNpLNMDR5SBlbH0MdHN0A04+v1FjR+sJe6seSDn45ZiYMkTskhYiCgESt9tAVB2Fr 6H0kO36m3kTKvrE33Zp9MV5R02+0CYAkkCx6JauWw6QLgX9ieKsGJZGPGId3EJCvyl28 M03g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v9l+yaF07+xrhvIb4HVGbD7I6KEmQ9Rg1YkRUgXMdSg=; b=kbqKeiaI7C6SdaVUcpKOxlM/+T90FZTW89ESnqIjMGA35Wj5hHkQe9kFXPzEp5UK5v 1tzQBOXKGY8fdXbuXbJ1vSTVzknWWBjvHGq7BWp58j2NIP4Y9NJmvMngGOZ4ccKTAsvn rZiVlJyWKwlFseyNVyw6cQsEAF5GMgN/KFzUFKJoJD6ERWOLnCGgAJoM582ilUfuIOmU AbbxqqIPNCeStZL8bBlNi36Sa/hGze9AMq9iSyNVSrL8A7xgMkbkrYohaixFxsqqiZPL wkVsr2engCuE81q3hro8aEjFxLX6D60i9f+pDJ15lHt7Hi1O8yeu2ogRbeBrqYF3VLnw qHTQ== X-Gm-Message-State: APjAAAW5oF0GqQrh7NF1c5DjJxldYae/ES/8B7pv7uESJiNTBLwsKwAr ZOFt9NuQ9qOrFsKBQqjJBXIxj++ytf7o9kPrvNMnOQ/FSFI= X-Google-Smtp-Source: APXvYqx7o9t5WNP/bTtyospiqj3cVGzUZArq2uvIe/JXl3qV8DssqbOkYVvfr4xywOwNIVYul49ExeJCk2rGpIEVzME= X-Received: by 2002:a5d:8892:: with SMTP id d18mr21053289ioo.59.1582172888360; Wed, 19 Feb 2020 20:28:08 -0800 (PST) MIME-Version: 1.0 From: Zhihao Yuan Date: Wed, 19 Feb 2020 22:27:57 -0600 Message-ID: Subject: How much libc++ ABI changes FreeBSD can consume? To: FreeBSD Hackers X-Rspamd-Queue-Id: 48NM5m0l3wz4Bl2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=olplb6/F; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of lichray@gmail.com designates 2607:f8b0:4864:20::d31 as permitted sender) smtp.mailfrom=lichray@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.3.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.00)[ip: (-6.55), ipnet: 2607:f8b0::/32(-1.89), asn: 15169(-1.67), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 04:28:13 -0000 Hi, I'm sending this email because a. FreeBSD has been stuck on libc++ V1 ABI long enough. I would like to learn some details. b. There is an ongoing discussion in the C++ standards committee talking about whether the standard library should break ABI on a regular basis. Here are my questions: 1. Is FreeBSD waiting for libc++ V2 ABI to freeze? If so, will FreeBSD switch to V2 ABI afterwards? 2. The pkgs are tagged with __FreeBSD_version, is that enough to allow libc++ ABI to change at every FreeBSD (major) release? 3. Is MFC required for libc++ updates? If so, how does that affect ABI changes? 4. Is there any desire to make C++ ABI breakage smoother by ultilzing mechanisms such as Symbol.map? Thanks, -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________ From owner-freebsd-hackers@freebsd.org Thu Feb 20 14:17:12 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1C53B23A2BD for ; Thu, 20 Feb 2020 14:17:12 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48Nc9L6NCNz4VlL; Thu, 20 Feb 2020 14:17:10 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 01KEGtS9096648 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 20 Feb 2020 16:16:58 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 01KEGtS9096648 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 01KEGtFB096647; Thu, 20 Feb 2020 16:16:55 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Thu, 20 Feb 2020 16:16:55 +0200 From: Konstantin Belousov To: Zhihao Yuan Cc: FreeBSD Hackers , dim@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200220141655.GP29554@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 48Nc9L6NCNz4VlL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.74 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.74)[-0.741,0]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; NEURAL_HAM_LONG(-0.99)[-0.994,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 14:17:12 -0000 On Wed, Feb 19, 2020 at 10:27:57PM -0600, Zhihao Yuan wrote: > Hi, > > I'm sending this email because > > a. FreeBSD has been stuck on libc++ V1 ABI > long enough. I would like to learn some details. > b. There is an ongoing discussion in the C++ > standards committee talking about whether > the standard library should break ABI on a > regular basis. > This is only part of the answers to your questions, Dmitry (Cc:ed) would provide more info later. > Here are my questions: > > 1. Is FreeBSD waiting for libc++ V2 ABI to freeze? > If so, will FreeBSD switch to V2 ABI afterwards? See later responses. > 2. The pkgs are tagged with __FreeBSD_version, > is that enough to allow libc++ ABI to change > at every FreeBSD (major) release? No. This mechanism has nothing to do with userspace ABI. > 3. Is MFC required for libc++ updates? If so, how > does that affect ABI changes? It is highly desirable to get libc++ synced between head and all actively supported stable versions. > 4. Is there any desire to make C++ ABI breakage > smoother by ultilzing mechanisms such as > Symbol.map? Yes. More expanded answer below. Right now any libc++ ABI breakage requires dso version bump. We try hard to avoid that because it trivially leads to a situation when multiple libc++'s are loaded into same process, unless everything is recompiled against same lib. In other words, bumping version for such fundamental library is too troublesome. Symver provides a solution for gradual ABI changes, but by policy we never provide symbol versioning for third-party libraries unless upstream maintains the versioning. The reason is that we cannot enforce upstream ABI policy, which would make versioning broken by updates and then pointless. So for instance libstdc++.so from gcc is versioned, while ncurses are not. If applying the symver policy to the library, we expect that it would prevent any dso version bumps in the future. Normally we bump dso version for introducing the symver, which is technically not strictly necessary but appeared to solve some corner cases. From owner-freebsd-hackers@freebsd.org Fri Feb 21 09:10:03 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E6DE25771D for ; Fri, 21 Feb 2020 09:10:03 +0000 (UTC) (envelope-from yuripv@yuripv.me) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (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 48P5JT0Tcpz4S02 for ; Fri, 21 Feb 2020 09:10:00 +0000 (UTC) (envelope-from yuripv@yuripv.me) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 546986A26 for ; Fri, 21 Feb 2020 04:10:00 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 21 Feb 2020 04:10:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.me; h= from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=fm1; bh=KW5i93eEbW7q6ZidPA+LD883S+aQl0O65 RJGCPKeKDo=; b=hlFIbWOCvDKr7Ub+x+9cC9RhQYyxYDRKg1Cc6AJM9qNczISVx TUrYQZI7xVZ9xTyG/07Ls/JfvUcvfEqlC8+7NpJjm3FB1rn52652A6JzXAzOMAte LCFESFUlYRP67wMjdDr1hmj0Wx2ydb0W+8vuHwAHwYvrlEDeMB/UJGEKqwEjQ2C6 i1tPr8yISVSLPwN1K20Rkg9gHlc+OIWY19J3OZfCvvrOaPGjn7NXkEIh45EcQPCz qASMB2vXx1tYct7w2NlUmAs7VRnl9tp0EqeqL0J250XvP/S8necIOVw5mN+nwQvJ l/QL7kB1nxsPLVWoB7VMNHf3k/0Az/fTsxEHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KW5i93 eEbW7q6ZidPA+LD883S+aQl0O65RJGCPKeKDo=; b=D2jOW/AaXRyIL8bQOdJTMY N2sCMbbMyxHPjrgBiIVmsN9xpwSmxtJzLBt6jyRF51dd/jrnA16w7CZg59CbCNLp ilvpiGfo9WbzeKv8RpF5U6ZG+o0AZA6T3Vmjr15uCvFm5XEHK7pUTbjOTjzJin85 xgzapeI0bi85T1luu1RT2qnhRQdhyf5FMF9eMVDa3+U4SOzf0FCpeU/7pW94dGIW 0+oijzPIyW02OEEd9KBrL9POjhxeGuyLy8DNsXURLsmqAr9Of+4YKD9eaatmcOoC We3bdMNC4N1/Pu4bn3dg+NA8DN4JtJQY7FtJ/QrtAJJWBIjjN6PefqWaTu6+b49w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeefgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd hhtddvnecuhfhrohhmpegjuhhrihcurfgrnhhkohhvuceohihurhhiphhvseihuhhrihhp vhdrmhgvqeenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucfkphepudejkedrud ehhedrgedrieeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhephihurhhiphhvseihuhhrihhpvhdrmhgv X-ME-Proxy: Received: from earth.yuripv.me (unknown [178.155.4.68]) by mail.messagingengine.com (Postfix) with ESMTPA id AD3913060BE4 for ; Fri, 21 Feb 2020 04:09:59 -0500 (EST) From: Yuri Pankov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: D23724: provide correct lid state after boot and resume Message-Id: Date: Fri, 21 Feb 2020 12:09:57 +0300 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48P5JT0Tcpz4S02 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.me header.s=fm1 header.b=hlFIbWOC; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=D2jOW/Aa; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.me designates 66.111.4.221 as permitted sender) smtp.mailfrom=yuripv@yuripv.me X-Spamd-Result: default: False [2.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[221.4.111.66.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(0.00)[+ip4:66.111.4.221]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[yuripv.me:+,messagingengine.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-3.48)[ip: (-9.78), ipnet: 66.111.4.0/24(-4.89), asn: 11403(-2.68), country: US(-0.05)]; RCVD_IN_DNSWL_LOW(-0.10)[221.4.111.66.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[68.4.155.178.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[68.4.155.178.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; R_DKIM_ALLOW(0.00)[yuripv.me:s=fm1,messagingengine.com:s=fm2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[yuripv.me]; NEURAL_SPAM_MEDIUM(0.04)[0.041,0]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_LONG(0.33)[0.335,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 09:10:03 -0000 A simple change providing correct dev.acpi_lid.0.state value on boot and = after resume: https://reviews.freebsd.org/D23724 If anyone has spare cycles, please review.= From owner-freebsd-hackers@freebsd.org Fri Feb 21 09:24:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CFF5B2580D8 for ; Fri, 21 Feb 2020 09:24:47 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48P5dW4r0Wz3KXr; Fri, 21 Feb 2020 09:24:47 +0000 (UTC) (envelope-from lichray@gmail.com) Received: by mail-il1-x12e.google.com with SMTP id i7so1099905ilr.7; Fri, 21 Feb 2020 01:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0mIJ9DsDVviulxpUkrgpsl1YqI8aRqwUH0sBn/6+nwk=; b=j5btm4B8Upm8j9ZJ5CgM1oLPFkUb2YQO9wFB77oJVm75Mgp3YSTJnKtKVfd2Do4AGp baYd8Gk0OiUSK++DEZY/68HKFK6C5DBL4ioPaiSmdJDMLM6rmaF7K8kqGJoq7UWzD41j kI+beUk6FoAHrKj4B2mYSegOWHmNYoyedHXoUg/rjaQexbx4d9hfutSsbyd4ZHkyuaXT EeNiLJqtAFMDJyZTowa3UP8XvGLBVz3FAXeki4EEdKmGM+urudP88sBJm4EeyA5B5lCu 12x3EAbBMDGVAAQKwh2RcJbCE7TYvK5ujeQt+OR7S66V6pdCQOaLUP8pSB5tI8pW61W7 tZLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0mIJ9DsDVviulxpUkrgpsl1YqI8aRqwUH0sBn/6+nwk=; b=l/9hZj7C10NO9YN0ujmd68VN07v75B1QQzTbK9eFpRO2o7l7TFCI5vJpU5r19WabQ+ VrC4Z6iQfsj7w7VRQpLFOS+HiNAsESzEJuKgMvSCky8uTWbdWdjr1Xbu9db3lgbbRJ86 em2xzzSa5nysYpztJsuRxIRlpEb1GIjNXoZp0UFSnC1LfkNi2QfvX0qR9GM3qDmt2Idm 1dIdAr7I47uV/8by75ngRet6uuySKlO8GvEzagm1O9iM9kP+ZizaEZsyUP8ePZCQ6mFe whtQkmTrw90YER8/wiXmt1oyq6XN0f2wltlV+/FYzHPsCvCFt7/om7CpT7wg9vXz+L81 0org== X-Gm-Message-State: APjAAAVPrDQSPkblh+Nps4ysRB1IZZHO1ngYH4onDhUZnurVYV6f4woj mBIoEmbmX4VkC8gnuRwwUJtUdTG2ic3EsnjlE/DYAhrw X-Google-Smtp-Source: APXvYqwuyrU0+1lOBXaUB/ys2/t35MF0WOz875R3opDaIomiJtIQoQWeFJsoBCtF7DDbjYmdYWgkZgb627E72TcSwxo= X-Received: by 2002:a92:9f1a:: with SMTP id u26mr35418343ili.72.1582277085137; Fri, 21 Feb 2020 01:24:45 -0800 (PST) MIME-Version: 1.0 References: <20200220141655.GP29554@kib.kiev.ua> In-Reply-To: <20200220141655.GP29554@kib.kiev.ua> From: Zhihao Yuan Date: Fri, 21 Feb 2020 03:24:32 -0600 Message-ID: Subject: Re: How much libc++ ABI changes FreeBSD can consume? To: Konstantin Belousov Cc: FreeBSD Hackers , Dimitry Andric X-Rspamd-Queue-Id: 48P5dW4r0Wz3KXr X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 09:24:47 -0000 On Thu, Feb 20, 2020 at 8:17 AM Konstantin Belousov wrote: > > 3. Is MFC required for libc++ updates? If so, how > > does that affect ABI changes? > It is highly desirable to get libc++ synced between head and all actively > supported stable versions. > > > 4. Is there any desire to make C++ ABI breakage > > smoother by ultilzing mechanisms such as > > Symbol.map? > Yes. More expanded answer below. > > Right now any libc++ ABI breakage requires dso version bump. We try hard > to avoid that because it trivially leads to a situation when multiple > libc++'s are loaded into same process, unless everything is recompiled > against same lib. In other words, bumping version for such fundamental > library is too troublesome. > > Symver provides a solution for gradual ABI changes, but by policy > we never provide symbol versioning for third-party libraries unless > upstream maintains the versioning. The reason is that we cannot enforce > upstream ABI policy, which would make versioning broken by updates and > then pointless. > > So for instance libstdc++.so from gcc is versioned, while ncurses are not. > To summarize what I heard, even if libc++ stabilizes V2 ABI, we do not want to do an "ABI break since release 1X" thing. If we really upgrade, we break all stable versions. And we hope/encourage libc++ to version symbols like what libstdc++ does, correct? -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________ From owner-freebsd-hackers@freebsd.org Fri Feb 21 09:53:21 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A4B30258C9E for ; Fri, 21 Feb 2020 09:53:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48P6GS726Cz3JCR for ; Fri, 21 Feb 2020 09:53:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E15B1260060; Fri, 21 Feb 2020 10:53:17 +0100 (CET) Subject: Re: D23724: provide correct lid state after boot and resume To: Yuri Pankov , freebsd-hackers@freebsd.org References: From: Hans Petter Selasky Message-ID: <61f3742c-52e7-bd02-06fc-0cb63544c3e9@selasky.org> Date: Fri, 21 Feb 2020 10:52:55 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48P6GS726Cz3JCR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.96 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-2.66)[ip: (-9.21), ipnet: 2a01:4f8::/29(-2.54), asn: 24940(-1.55), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 09:53:21 -0000 On 2020-02-21 10:09, Yuri Pankov wrote: > A simple change providing correct dev.acpi_lid.0.state value on boot and after resume: > > https://reviews.freebsd.org/D23724 > > If anyone has spare cycles, please review. Fixed. --HPS From owner-freebsd-hackers@freebsd.org Fri Feb 21 12:03:30 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6195025BB91 for ; Fri, 21 Feb 2020 12:03:30 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (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 48P98d3tKFz45jn for ; Fri, 21 Feb 2020 12:03:29 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 93.205.161.59 Received: from bec.de (p5DCDA13B.dip0.t-ipconnect.de [93.205.161.59]) (Authenticated sender: joerg@bec.de) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 9BC611BF209 for ; Fri, 21 Feb 2020 12:03:27 +0000 (UTC) Date: Fri, 21 Feb 2020 13:03:25 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221120325.GA86511@bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20200220141655.GP29554@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Rspamd-Queue-Id: 48P98d3tKFz45jn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.183.201) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-1.33 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-1.26)[ip: (-3.45), ipnet: 217.70.176.0/20(-1.57), asn: 29169(-1.27), country: FR(0.00)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RECEIVED_SPAMHAUS_PBL(0.00)[59.161.205.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_MEDIUM(-0.87)[-0.865,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[201.183.70.217.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 12:03:30 -0000 On Fri, Feb 21, 2020 at 03:24:32AM -0600, Zhihao Yuan wrote: > On Thu, Feb 20, 2020 at 8:17 AM Konstantin Belousov wrote: > > > > 3. Is MFC required for libc++ updates? If so, how > > > does that affect ABI changes? > > It is highly desirable to get libc++ synced between head and all actively > > supported stable versions. > > > > > 4. Is there any desire to make C++ ABI breakage > > > smoother by ultilzing mechanisms such as > > > Symbol.map? > > Yes. More expanded answer below. > > > > Right now any libc++ ABI breakage requires dso version bump. We try hard > > to avoid that because it trivially leads to a situation when multiple > > libc++'s are loaded into same process, unless everything is recompiled > > against same lib. In other words, bumping version for such fundamental > > library is too troublesome. > > > > Symver provides a solution for gradual ABI changes, but by policy > > we never provide symbol versioning for third-party libraries unless > > upstream maintains the versioning. The reason is that we cannot enforce > > upstream ABI policy, which would make versioning broken by updates and > > then pointless. > > > > So for instance libstdc++.so from gcc is versioned, while ncurses are not. > > > > To summarize what I heard, even if libc++ > stabilizes V2 ABI, we do not want to do an > "ABI break since release 1X" thing. If we > really upgrade, we break all stable versions. > And we hope/encourage libc++ to > version symbols like what libstdc++ does, > correct? Symbol versioning helps really little for this kind of ABI breaks. It still ends up effectively being a flag day as libraries build before and after don't interact that well with each other. Joerg From owner-freebsd-hackers@freebsd.org Fri Feb 21 12:35:54 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A294C25C88F for ; Fri, 21 Feb 2020 12:35:54 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48P9t14ZDzz3Mfd; Fri, 21 Feb 2020 12:35:53 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 01LCZjbD010708 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 21 Feb 2020 14:35:48 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 01LCZjbD010708 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 01LCZjp0010707; Fri, 21 Feb 2020 14:35:45 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Fri, 21 Feb 2020 14:35:45 +0200 From: Konstantin Belousov To: Zhihao Yuan Cc: FreeBSD Hackers , Dimitry Andric Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221123545.GS29554@kib.kiev.ua> References: <20200220141655.GP29554@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 48P9t14ZDzz3Mfd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.74 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.74)[-0.741,0]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; NEURAL_HAM_LONG(-0.99)[-0.994,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 12:35:54 -0000 On Fri, Feb 21, 2020 at 03:24:32AM -0600, Zhihao Yuan wrote: > On Thu, Feb 20, 2020 at 8:17 AM Konstantin Belousov wrote: > > > > 3. Is MFC required for libc++ updates? If so, how > > > does that affect ABI changes? > > It is highly desirable to get libc++ synced between head and all actively > > supported stable versions. > > > > > 4. Is there any desire to make C++ ABI breakage > > > smoother by ultilzing mechanisms such as > > > Symbol.map? > > Yes. More expanded answer below. > > > > Right now any libc++ ABI breakage requires dso version bump. We try hard > > to avoid that because it trivially leads to a situation when multiple > > libc++'s are loaded into same process, unless everything is recompiled > > against same lib. In other words, bumping version for such fundamental > > library is too troublesome. > > > > Symver provides a solution for gradual ABI changes, but by policy > > we never provide symbol versioning for third-party libraries unless > > upstream maintains the versioning. The reason is that we cannot enforce > > upstream ABI policy, which would make versioning broken by updates and > > then pointless. > > > > So for instance libstdc++.so from gcc is versioned, while ncurses are not. > > > > To summarize what I heard, even if libc++ > stabilizes V2 ABI, we do not want to do an > "ABI break since release 1X" thing. If we > really upgrade, we break all stable versions. We do not deny the possibility of upgrade outright, but decision to do so cannot be taken lightly. Upgrade should provide a large benefit to upgrade (or very large penalty to not upgrade). If it combines with additional measures that ensure more stable ABI in future, like applying symbol versioning, this alone might be considered a large enough benefit. > And we hope/encourage libc++ to > version symbols like what libstdc++ does, > correct? Yes, but we expect the upstream to care about ABI even more then. From owner-freebsd-hackers@freebsd.org Fri Feb 21 12:36:46 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0F24D25C9B1 for ; Fri, 21 Feb 2020 12:36:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48P9v12Tsyz3NPr for ; Fri, 21 Feb 2020 12:36:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 01LCacDc010731 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 21 Feb 2020 14:36:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 01LCacDc010731 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 01LCacwt010730 for freebsd-hackers@freebsd.org; Fri, 21 Feb 2020 14:36:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Feb 2020 14:36:37 +0200 From: Konstantin Belousov To: freebsd-hackers@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221123637.GT29554@kib.kiev.ua> References: <20200220141655.GP29554@kib.kiev.ua> <20200221120325.GA86511@bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200221120325.GA86511@bec.de> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 48P9v12Tsyz3NPr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; HAS_XAW(0.00)[]; IP_SCORE(0.00)[ip: (-3.18), ipnet: 2001:470::/32(-4.65), asn: 6939(-3.58), country: US(-0.05)]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 12:36:46 -0000 On Fri, Feb 21, 2020 at 01:03:25PM +0100, Joerg Sonnenberger wrote: > On Fri, Feb 21, 2020 at 03:24:32AM -0600, Zhihao Yuan wrote: > > On Thu, Feb 20, 2020 at 8:17 AM Konstantin Belousov wrote: > > > > > > 3. Is MFC required for libc++ updates? If so, how > > > > does that affect ABI changes? > > > It is highly desirable to get libc++ synced between head and all actively > > > supported stable versions. > > > > > > > 4. Is there any desire to make C++ ABI breakage > > > > smoother by ultilzing mechanisms such as > > > > Symbol.map? > > > Yes. More expanded answer below. > > > > > > Right now any libc++ ABI breakage requires dso version bump. We try hard > > > to avoid that because it trivially leads to a situation when multiple > > > libc++'s are loaded into same process, unless everything is recompiled > > > against same lib. In other words, bumping version for such fundamental > > > library is too troublesome. > > > > > > Symver provides a solution for gradual ABI changes, but by policy > > > we never provide symbol versioning for third-party libraries unless > > > upstream maintains the versioning. The reason is that we cannot enforce > > > upstream ABI policy, which would make versioning broken by updates and > > > then pointless. > > > > > > So for instance libstdc++.so from gcc is versioned, while ncurses are not. > > > > > > > To summarize what I heard, even if libc++ > > stabilizes V2 ABI, we do not want to do an > > "ABI break since release 1X" thing. If we > > really upgrade, we break all stable versions. > > And we hope/encourage libc++ to > > version symbols like what libstdc++ does, > > correct? > > Symbol versioning helps really little for this kind of ABI breaks. It > still ends up effectively being a flag day as libraries build before and > after don't interact that well with each other. It helps some, and from my undertanding, symver + properly used inline namespaces cover much, if not everything. From owner-freebsd-hackers@freebsd.org Fri Feb 21 12:58:52 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 83CEE25D131 for ; Fri, 21 Feb 2020 12:58:52 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (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 48PBNW1Rfrz4Q9y for ; Fri, 21 Feb 2020 12:58:50 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 93.205.161.59 Received: from bec.de (p5DCDA13B.dip0.t-ipconnect.de [93.205.161.59]) (Authenticated sender: joerg@bec.de) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 94DECC0011 for ; Fri, 21 Feb 2020 12:58:48 +0000 (UTC) Date: Fri, 21 Feb 2020 13:58:46 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221125846.GA88921@bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20200220141655.GP29554@kib.kiev.ua> <20200221120325.GA86511@bec.de> <20200221123637.GT29554@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200221123637.GT29554@kib.kiev.ua> User-Agent: Mutt/1.11.3 (2019-02-01) X-Rspamd-Queue-Id: 48PBNW1Rfrz4Q9y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.183.198) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-1.32 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-1.26)[ip: (-3.44), ipnet: 217.70.176.0/20(-1.57), asn: 29169(-1.27), country: FR(0.00)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RECEIVED_SPAMHAUS_PBL(0.00)[59.161.205.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_MEDIUM(-0.87)[-0.866,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.183.70.217.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 12:58:52 -0000 On Fri, Feb 21, 2020 at 02:36:37PM +0200, Konstantin Belousov wrote: > On Fri, Feb 21, 2020 at 01:03:25PM +0100, Joerg Sonnenberger wrote: > > On Fri, Feb 21, 2020 at 03:24:32AM -0600, Zhihao Yuan wrote: > > > On Thu, Feb 20, 2020 at 8:17 AM Konstantin Belousov wrote: > > > > > > > > 3. Is MFC required for libc++ updates? If so, how > > > > > does that affect ABI changes? > > > > It is highly desirable to get libc++ synced between head and all actively > > > > supported stable versions. > > > > > > > > > 4. Is there any desire to make C++ ABI breakage > > > > > smoother by ultilzing mechanisms such as > > > > > Symbol.map? > > > > Yes. More expanded answer below. > > > > > > > > Right now any libc++ ABI breakage requires dso version bump. We try hard > > > > to avoid that because it trivially leads to a situation when multiple > > > > libc++'s are loaded into same process, unless everything is recompiled > > > > against same lib. In other words, bumping version for such fundamental > > > > library is too troublesome. > > > > > > > > Symver provides a solution for gradual ABI changes, but by policy > > > > we never provide symbol versioning for third-party libraries unless > > > > upstream maintains the versioning. The reason is that we cannot enforce > > > > upstream ABI policy, which would make versioning broken by updates and > > > > then pointless. > > > > > > > > So for instance libstdc++.so from gcc is versioned, while ncurses are not. > > > > > > > > > > To summarize what I heard, even if libc++ > > > stabilizes V2 ABI, we do not want to do an > > > "ABI break since release 1X" thing. If we > > > really upgrade, we break all stable versions. > > > And we hope/encourage libc++ to > > > version symbols like what libstdc++ does, > > > correct? > > > > Symbol versioning helps really little for this kind of ABI breaks. It > > still ends up effectively being a flag day as libraries build before and > > after don't interact that well with each other. > It helps some, and from my undertanding, symver + properly used inline > namespaces cover much, if not everything. Take a look at all the pain libstdc++ had with its new string implementation. Symbol versioning is fine as long as the ABI doesn't extend beyond the boundaries of the depending DSOs. But if you want to change e.g. std::string, all libraries to be mixed need to version any interface containing it and that is effectively as much trouble as just doing the DSO bump. Joerg From owner-freebsd-hackers@freebsd.org Fri Feb 21 13:19:48 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 25CED25D6DF for ; Fri, 21 Feb 2020 13:19:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48PBrg3hLbz3yl8 for ; Fri, 21 Feb 2020 13:19:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 01LDJdNY020093 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 21 Feb 2020 15:19:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 01LDJdNY020093 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 01LDJd7V020091 for freebsd-hackers@freebsd.org; Fri, 21 Feb 2020 15:19:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Feb 2020 15:19:39 +0200 From: Konstantin Belousov To: freebsd-hackers@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221131939.GV29554@kib.kiev.ua> References: <20200220141655.GP29554@kib.kiev.ua> <20200221120325.GA86511@bec.de> <20200221123637.GT29554@kib.kiev.ua> <20200221125846.GA88921@bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200221125846.GA88921@bec.de> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 48PBrg3hLbz3yl8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; HAS_XAW(0.00)[]; IP_SCORE(0.00)[ip: (-3.17), ipnet: 2001:470::/32(-4.65), asn: 6939(-3.58), country: US(-0.05)]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 13:19:48 -0000 On Fri, Feb 21, 2020 at 01:58:46PM +0100, Joerg Sonnenberger wrote: > On Fri, Feb 21, 2020 at 02:36:37PM +0200, Konstantin Belousov wrote: > > On Fri, Feb 21, 2020 at 01:03:25PM +0100, Joerg Sonnenberger wrote: > > > On Fri, Feb 21, 2020 at 03:24:32AM -0600, Zhihao Yuan wrote: > > > > On Thu, Feb 20, 2020 at 8:17 AM Konstantin Belousov wrote: > > > > > > > > > > 3. Is MFC required for libc++ updates? If so, how > > > > > > does that affect ABI changes? > > > > > It is highly desirable to get libc++ synced between head and all actively > > > > > supported stable versions. > > > > > > > > > > > 4. Is there any desire to make C++ ABI breakage > > > > > > smoother by ultilzing mechanisms such as > > > > > > Symbol.map? > > > > > Yes. More expanded answer below. > > > > > > > > > > Right now any libc++ ABI breakage requires dso version bump. We try hard > > > > > to avoid that because it trivially leads to a situation when multiple > > > > > libc++'s are loaded into same process, unless everything is recompiled > > > > > against same lib. In other words, bumping version for such fundamental > > > > > library is too troublesome. > > > > > > > > > > Symver provides a solution for gradual ABI changes, but by policy > > > > > we never provide symbol versioning for third-party libraries unless > > > > > upstream maintains the versioning. The reason is that we cannot enforce > > > > > upstream ABI policy, which would make versioning broken by updates and > > > > > then pointless. > > > > > > > > > > So for instance libstdc++.so from gcc is versioned, while ncurses are not. > > > > > > > > > > > > > To summarize what I heard, even if libc++ > > > > stabilizes V2 ABI, we do not want to do an > > > > "ABI break since release 1X" thing. If we > > > > really upgrade, we break all stable versions. > > > > And we hope/encourage libc++ to > > > > version symbols like what libstdc++ does, > > > > correct? > > > > > > Symbol versioning helps really little for this kind of ABI breaks. It > > > still ends up effectively being a flag day as libraries build before and > > > after don't interact that well with each other. > > It helps some, and from my undertanding, symver + properly used inline > > namespaces cover much, if not everything. > > Take a look at all the pain libstdc++ had with its new string > implementation. Symbol versioning is fine as long as the ABI doesn't > extend beyond the boundaries of the depending DSOs. But if you want to > change e.g. std::string, all libraries to be mixed need to version any > interface containing it and that is effectively as much trouble as just > doing the DSO bump. Right, as I understand, inline namespaces were the reaction to this and similar issues. With new namespace, std::string methods would get different mangled name. I am not claiming that either approach (or its combination) cover everything, but the situation should be not that dim. E.g., after ino64 changes, I am aware of only one serious breakage when running binaries built for older struct stat, on newer system, and this comes from Firefox doing dlsym("stat"). From owner-freebsd-hackers@freebsd.org Fri Feb 21 14:30:04 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C34AC25F405 for ; Fri, 21 Feb 2020 14:30:04 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (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 48PDPl3BQjz451G for ; Fri, 21 Feb 2020 14:30:03 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 93.205.161.59 Received: from bec.de (p5DCDA13B.dip0.t-ipconnect.de [93.205.161.59]) (Authenticated sender: joerg@bec.de) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 9F5F92000D for ; Fri, 21 Feb 2020 14:30:00 +0000 (UTC) Date: Fri, 21 Feb 2020 15:29:58 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221142958.GA69281@bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20200220141655.GP29554@kib.kiev.ua> <20200221120325.GA86511@bec.de> <20200221123637.GT29554@kib.kiev.ua> <20200221125846.GA88921@bec.de> <20200221131939.GV29554@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200221131939.GV29554@kib.kiev.ua> User-Agent: Mutt/1.11.3 (2019-02-01) X-Rspamd-Queue-Id: 48PDPl3BQjz451G X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.183.200) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-1.03 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-1.03)[ip: (-2.32), ipnet: 217.70.176.0/20(-1.57), asn: 29169(-1.27), country: FR(0.00)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RECEIVED_SPAMHAUS_PBL(0.00)[59.161.205.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_MEDIUM(-0.80)[-0.799,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[200.183.70.217.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:30:04 -0000 On Fri, Feb 21, 2020 at 03:19:39PM +0200, Konstantin Belousov wrote: > On Fri, Feb 21, 2020 at 01:58:46PM +0100, Joerg Sonnenberger wrote: > > Take a look at all the pain libstdc++ had with its new string > > implementation. Symbol versioning is fine as long as the ABI doesn't > > extend beyond the boundaries of the depending DSOs. But if you want to > > change e.g. std::string, all libraries to be mixed need to version any > > interface containing it and that is effectively as much trouble as just > > doing the DSO bump. > > Right, as I understand, inline namespaces were the reaction to this and > similar issues. With new namespace, std::string methods would get different > mangled name. > > I am not claiming that either approach (or its combination) cover > everything, but the situation should be not that dim. E.g., after ino64 > changes, I am aware of only one serious breakage when running binaries > built for older struct stat, on newer system, and this comes from > Firefox doing dlsym("stat"). The difference is that ino_t and transitively stat are passed around rarely between libraries. This is completely different from std::string, which is passed around a lot between C++ libraries. As such, any such interface needs to be versioned. This gets worse if it is a member of a public class, because then every use of that class has to be versioned as well. Joerg From owner-freebsd-hackers@freebsd.org Sat Feb 22 17:13:07 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 672742455B1 for ; Sat, 22 Feb 2020 17:13:07 +0000 (UTC) (envelope-from takumijohn0806@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48PvzQ42Xlz43Pq for ; Sat, 22 Feb 2020 17:13:06 +0000 (UTC) (envelope-from takumijohn0806@gmail.com) Received: by mail-wm1-x331.google.com with SMTP id a5so4938921wmb.0 for ; Sat, 22 Feb 2020 09:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DJ4ROUh8qfSTFtcIUq9NCDasSnQDDNhWdHO1ZC8Fspk=; b=PkKLZWpj+1HP1fwImhiEPC5GXHzxFKe/J2tNhflG9j70rOYIDR3ZCcqAazND6A5XSR x6PfNRuaAwa+tUBl0ubqtElhLDEVNNkDcUj4N/NxQtsT+FIRED5XCiWlr1dY+1zYGgIg Hkjs6CmleZJHbS3EbWPlGb1ILpC1iMKw/IWs3yUXWe5Zczdqe8PP3Jt3kPsLfjBYFzRI BK7Jb9NV+jQIxdm/RNI5qzgLuZlD7HzVdoyTKv3WARVoV7iCwc31ynPe98c+hwjZhMmu l4F9HJqO+71bjlR6wC3XlLWRshz3X1Um3+yqh4oN8QRqdnZqWSTC2ruYovlt/xAV4FxV plxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DJ4ROUh8qfSTFtcIUq9NCDasSnQDDNhWdHO1ZC8Fspk=; b=UPhzNyYSrZ4xBcZlo0bLrmyp/FpXvDYzRyXlpISPrLYbaQbRdKxgubEav7Wlxt5PBH HnnVO2++CLmiIJwhZw9aRetS37IAuBJDOXECMilqjFq3GTzhDxKf7IkiIGNtufLYR77o EbIN/SWt441XGU5N1wV4x1Ga8jLui3LS51io7Akw4Nwl+CKqWkJZF/Yfsnjs53WqUhkr 168D8dpGs+W6a8NQrH/a9p8KSojVf61gaGY0vbAywzRgAxqU8K2Y19p3IjtpscYT6UWO L7QKg7krMwiuPaGqcVo7NGN+Asqu//LDWpAdrSiMzcRx1lbEktQyTU4cuZEYw/rp6cKu fFjQ== X-Gm-Message-State: APjAAAVVoPlW08wkg5RFqtVmXcMAfpiiLYifBmrLmGDg/acdnqdmORT6 zC59zbHGoN+n4UGhuE6cZkafYslupfbd75ghw2k1yxUtwXk= X-Google-Smtp-Source: APXvYqx88pd55PwyQOn3uR8BDY6yYHHNYskQw2v7jiCXWdlx7pP5t2K8Q+MS84fI8HuMYAiU+dfX7plCyt1SqApDXgc= X-Received: by 2002:a7b:c450:: with SMTP id l16mr11469654wmi.31.1582391584463; Sat, 22 Feb 2020 09:13:04 -0800 (PST) MIME-Version: 1.0 From: Takumi Kataoka Date: Sun, 23 Feb 2020 02:12:53 +0900 Message-ID: Subject: Question about Google Summer 2020 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48PvzQ42Xlz43Pq X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PkKLZWpj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of takumijohn0806@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) smtp.mailfrom=takumijohn0806@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; IP_SCORE(0.00)[ip: (-8.72), ipnet: 2a00:1450::/32(-2.42), asn: 15169(-1.67), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; INTRODUCTION(2.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 17:13:07 -0000 Hi , My name is Takumi and senior college student in Japan. I'm thinking to participate Google Summer of Code 2020. And I'd like to work on FreeBSD. I found "Dual-stack traceroute(1) command" in GSoC ideas list , it's sound interesting for me. Could you tell me more details about it? Sincerely, Takumi Kataoka From owner-freebsd-hackers@freebsd.org Sat Feb 22 18:27:43 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 31BBC248914 for ; Sat, 22 Feb 2020 18:27:43 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48PxdV1Hnmz4HjV for ; Sat, 22 Feb 2020 18:27:42 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from ice.alameda.xse.com (unknown [IPv6:2600:1700:a570:11f0:f2ad:4eff:fe0b:a065]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id C46E068AC for ; Sat, 22 Feb 2020 18:27:41 +0000 (UTC) (envelope-from leres@freebsd.org) To: FreeBSD Hackers From: Craig Leres Subject: Slow performance with one of two power supplies powered Message-ID: <8813b1e2-74af-5a13-adb9-36c4ed07cfcd@freebsd.org> Date: Sat, 22 Feb 2020 10:27:39 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 18:27:43 -0000 I have two Supermicro X9SRi-F systems that are nearly identical. Both have dual power supplies fed from building and generator power. One is acting normally but the other does not have building power due to electrical work this weekend and has really poor performance. For example running wc on a 2.5M line file takes 2 seconds on the good system and 40 on the bad. Last time I ran into this I found the system was underclocking and "sysctl dev.cpu.0.freq" would report a lower than expected value. I solved this by running powerd with this config: powerd_enable="YES" powerd_flags="-a max -b max -n max" In this case dev.cpu.0.freq is reported as 2201 for both systems which seems correct for the 2.20GHz Intel E5-2660 processors in use. Running powerd does not change the reported frequency nor does it improve performance. I have another pair of X9SRi-F systems with the same power situation. They have 3.00GHz E5-2637 and the one running on one of two power supplies was reporting dev.cpu.0.freq as 1200 before running powerd and 3001 after. The single powered system also has lower performance, the wc test takes 14 seconds, the fully powered system takes < 0.5. How do I solve this? dmidecode reports the power supplies as PWS-406P-1R which is rated for 400W so I think they are beefy enough to run a single E5-2660, memory, and a couple of SSDs. Craig From owner-freebsd-hackers@freebsd.org Sat Feb 22 19:45:04 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C98524A9E9 for ; Sat, 22 Feb 2020 19:45:04 +0000 (UTC) (envelope-from beckman@angryox.com) Received: from nog2.angryox.com (nog2.angryox.com [70.164.19.85]) (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 48PzLk623dz3KWD for ; Sat, 22 Feb 2020 19:45:02 +0000 (UTC) (envelope-from beckman@angryox.com) Received: by nog2.angryox.com (Postfix, from userid 1001) id 76C6917448D7; Sat, 22 Feb 2020 19:44:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=angryox.com; s=powerfulgood; t=1582400696; bh=GhKNG+djGt1K71BmnBNUcZRH0eGM7o5B/qSyI6Tl7P8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=vskY2RbZ03YvWtnZnRJR1Qv/d4rob1+22MVURRrA2ZbzmHE476lfprM5AnUGBCCOm bH0yU23fI6gfifANs+KSP/nWgYGa1bNLTqVwBYGInz8cLP0kOLIrefkIgHlSLBtbLD f1y7JtY/PxgYeq9JiXnhVVHdCo5o5donyrz8gmBM= Received: from localhost (localhost [127.0.0.1]) by nog2.angryox.com (Postfix) with ESMTP id 71CFA17448D2; Sat, 22 Feb 2020 14:44:56 -0500 (EST) Date: Sat, 22 Feb 2020 14:44:56 -0500 From: Peter Beckman To: Takumi Kataoka cc: freebsd-hackers@freebsd.org Subject: Re: Question about Google Summer 2020 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 48PzLk623dz3KWD X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=angryox.com header.s=powerfulgood header.b=vskY2RbZ; dmarc=none; spf=pass (mx1.freebsd.org: domain of beckman@angryox.com designates 70.164.19.85 as permitted sender) smtp.mailfrom=beckman@angryox.com X-Spamd-Result: default: False [2.98 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[angryox.com:s=powerfulgood]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:nog2.angryox.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[angryox.com]; NEURAL_SPAM_MEDIUM(0.43)[0.430,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[angryox.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.81)[0.814,0]; IP_SCORE(0.24)[asn: 22773(1.25), country: US(-0.05)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; INTRODUCTION(2.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:22773, ipnet:70.164.18.0/23, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 19:45:04 -0000 The description: "Currently there are two traceroute tools: traceroute (for IPv4 networks), and traceroute6 (for IPv6 networks). Between the two commands there's a lot of duplicate functionality, but there's also a lot of necessary divergence. Unifying these commands (and allowing user selection for IPv4 or IPv6 functionality) would mean only requiring one utility." My read from this is: 1. Create a new "traceroute" tool 2. based on the existing traceroute/traceroute6 code 2. in C 3. Accepts either an IPv4 _OR_ and IPv6 address 4. Works correctly for whatever the valid input is 5. unifies the two separate commands currently 6. Intelligently re-use shared code Unit test cases: traceroute 8.8.8.8 traceroute 2607:f8b0:4004:815::200e Beckman On Sun, 23 Feb 2020, Takumi Kataoka wrote: > Hi , > My name is Takumi and senior college student in Japan. > I'm thinking to participate Google Summer of Code 2020. > And I'd like to work on FreeBSD. > > I found "Dual-stack traceroute(1) command" in GSoC ideas list , it's > sound interesting for me. > Could you tell me more details about it? > > Sincerely, > Takumi Kataoka > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------