From nobody Mon Jan 29 12:48:21 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TNp5971jGz58fg1 for ; Mon, 29 Jan 2024 12:48:45 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNp586BXHz49Nx for ; Mon, 29 Jan 2024 12:48:44 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=rZWiXu3q; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="XvHtLK/0"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.19 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id D1B673200319 for ; Mon, 29 Jan 2024 07:48:42 -0500 (EST) Received: from imap46 ([10.202.2.96]) by compute6.internal (MEProxy); Mon, 29 Jan 2024 07:48:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1706532522; x=1706618922; bh=srm+qEucbeeqvW8a2q1W8tHV4iSpyQDU jbYgDGcurYw=; b=rZWiXu3qLrFoRko2T6Jg85LdeKvKBkHXJUbr/issGbLRSYY/ R/Qt5Z8e8R6vDZY/9Mw2b+FXKceh6w9fpF21lARIFoFN++aD2b9pkTz2WDiWEMfc kOrvJfeGN6hpOawU2gVKWaJA4yT3+diVNt7MQzRlwsTeaxwaImCDJb2u7hZE/+YZ k1XENc7pZ51T/slkhT2IShkSSQKrcexPraGnGJyep+RE5/UacxGdwPaT8TsHWxV9 yHdMopLvC5uDv+u3+feWlsHj+/IAiiA1x1jderCsbO+IFBlD1mP0PSc+OJDj44/7 9TjXT5Gbj88yAk80g9/JKywogj36Vf9iEVXWIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1706532522; x=1706618922; bh=srm+qEucbeeqvW8a2q1W8tHV4iSpyQDUjbY gDGcurYw=; b=XvHtLK/0voYBRKKNeENCSzQJ8FZW3ds4WF5pxZr07Qgr/NzqE7E IvjZ1wk04DohRDJrx/cMQehmafpkwXXAO5bk3OibcoHU0Ak4zEUG7Vte1kzssigL 6m7xCDce4FAV3nE+sVaS0XldTMADo6zVEr8igEBwJmultZkLrdRTmNE9ZvhaPzKj fEEda7imKNhghmL76uGnml0brZ2NcgqrU1m5+bfig8OfDA7KFWthHfVrBu0TT0Q7 NCuLD0rvdOTqcMImk0YjOJxpblwiU89n68BVBSbop08s51+T7ciB5h7adRuBS0mU twmJw4tAR88ySmpriU0b8rXzg8ExVwpv8ZA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedtgedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeeftdfhhefgjeeiteevfeeghedvkeefgeetudffffehfffgjeehtedukefhje dtveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv ohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2190E2A2008B; Mon, 29 Jan 2024 07:48:42 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-Id: Date: Mon, 29 Jan 2024 12:48:21 +0000 From: void To: freebsd-hackers@freebsd.org Subject: arm64 swap-related question Content-Type: text/plain X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.39 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.896]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.19:from]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4TNp586BXHz49Nx Hello, What's the default granularity with swapping on recent -current on arm64? ie. whats the smallest size of data that is swapped out. 1k? 4k? Where can I find this info? Can it be set/tuned? How to see what it currently is? I'd like to set it to 32k if possible. Read performance on this disk for swap tops out at 60MB/s with a 32k block size. For bs=512 it's 1349 kB/s For bs=4k it's 11MB/s context: the thing I'm trying to work around is poor swap performance on this arch/hardware. -- From nobody Mon Jan 29 13:12:34 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TNpcq5Q4mz58gyp for ; Mon, 29 Jan 2024 13:12:43 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNpcq0yMwz4Gjn for ; Mon, 29 Jan 2024 13:12:42 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 40TDCZk0043077; Mon, 29 Jan 2024 22:12:35 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 29 Jan 2024 22:12:34 +0900 From: Tomoaki AOKI To: void Cc: freebsd-hackers@freebsd.org Subject: Re: arm64 swap-related question Message-Id: <20240129221234.657f47be4718f7c894801cac@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4TNpcq0yMwz4Gjn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] On Mon, 29 Jan 2024 12:48:21 +0000 void wrote: > Hello, > > What's the default granularity with swapping on recent -current > on arm64? > > ie. whats the smallest size of data that is swapped out. 1k? 4k? Where > can I find this info? Can it be set/tuned? How to see what it currently is? > I'd like to set it to 32k if possible. Read performance on this disk > for swap tops out at 60MB/s with a 32k block size. > > For bs=512 it's 1349 kB/s > For bs=4k it's 11MB/s > > context: the thing I'm trying to work around is poor swap performance > on this arch/hardware. > -- You should read /usr/src/sys/vm/swap_pager.c. Keyword would PAGE_SIZE. Then, look for its definition for arm64. IIUC, swap is based on "paging" and once severe memory shortage happens, swap out whole idle but not pinned processes with per-process basis, and when it's not sufficient to keep OS running, OOM killer whould look for which process to kill. So PAGE_SIZE shold be the keyword for it. HTH. -- Tomoaki AOKI From nobody Wed Jan 31 10:09:59 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TPyTJ5f56z57RsY for ; Wed, 31 Jan 2024 10:10:12 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4TPyTH20Jcz4FKp; Wed, 31 Jan 2024 10:10:11 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=SLi3mj4a; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.17.1) with ESMTPS id 40VAA1Pb098663 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Jan 2024 11:10:02 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1706695802; bh=EH/ffAXo4mBJB0qQW8Bm5SnCBJbGi8PchHYf9xQR8+A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SLi3mj4aPPAd1yEMfsnO1ZpfekbHdJRLwlgf/mMde+5XPSMEOwAwZpcU48I/cTvC+ PC83Xo9MZ/AhA9PBR44ExISDpuY+8tJ+YDNcAuJHRowEWHgU5+RFYudYZW3m5q0fpz gAi8kwYy5Oei6XVoOBBx5AqrP8StPMm6192CS9kw= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.17.1/8.16.1) with ESMTP id 40VAA1qH027972; Wed, 31 Jan 2024 11:10:01 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.17.1/8.16.1/Submit) with ESMTP id 40VAA0Qi027965; Wed, 31 Jan 2024 11:10:00 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 31 Jan 2024 11:09:59 +0100 (CET) From: Wojciech Puchar To: Alan Somers cc: FreeBSD Hackers , Warner Losh , Scott Long , meka@tilda.center Subject: Re: The Case for Rust (in the base system) In-Reply-To: Message-ID: <515f384-6334-3e5c-f9e-40f469ca5e@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[puchar.net:+] X-Rspamd-Queue-Id: 4TPyTH20Jcz4FKp is FreeBSD unix system or religion? if it have to evolve to religion PLEASE provide usable unix system, maybe under other project. I do need normal unix system. FreeBSD is the only remaining useful. From nobody Wed Jan 31 10:15:56 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TPyc50Rckz57SMh for ; Wed, 31 Jan 2024 10:16:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4TPyc40d1Hz4GYl; Wed, 31 Jan 2024 10:16:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=JPRakLA2; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.17.1) with ESMTPS id 40VAFvNn003184 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Jan 2024 11:15:58 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1706696158; bh=Y26BCcFFxntiupSRZlBwnvHY4n+QUtdcv0wBUQvPmhU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JPRakLA21Mm/lsEzE7WzkP4JdqBI6ziGjPMgRpFS+lB9YQPXZ/BR8dU+SgMwYXdLf HUukis1tdjIdtAv3UGLejBT3FylK4phLjQgDQypO0wK1WiKzysjMm1OtX2nH7OHuMt UvKqNVxMVcBcXKCiK04q4M66eM25hlpTHnSGSQ4g= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.17.1/8.16.1) with ESMTP id 40VAFvs2028000; Wed, 31 Jan 2024 11:15:57 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.17.1/8.16.1/Submit) with ESMTP id 40VAFuSn027997; Wed, 31 Jan 2024 11:15:57 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 31 Jan 2024 11:15:56 +0100 (CET) From: Wojciech Puchar To: Antranig Vartanian cc: Alan Somers , FreeBSD Hackers , Warner Losh , Scott Long , =?ISO-8859-2?Q?Goran_Meki=E6?= Subject: Re: The Case for Rust (in the base system) In-Reply-To: Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3974694515-796881025-1706696157=:27992" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_XAW(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; DMARC_NA(0.00)[puchar.net]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+] X-Rspamd-Queue-Id: 4TPyc40d1Hz4GYl This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3974694515-796881025-1706696157=:27992 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT > I don’t want to do a what-aboutism, but if all we’re looking for is a good and > secure system programming language, the alternatives are nicer. The is no such thing as secure system programming language. Security come only from proper programming practices. --3974694515-796881025-1706696157=:27992-- From nobody Wed Jan 31 10:17:14 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TPydV3Vmmz57SYD for ; Wed, 31 Jan 2024 10:17:18 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4TPydT55Tsz4HpL; Wed, 31 Jan 2024 10:17:17 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=HXdHxpbF; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.17.1) with ESMTPS id 40VAHEIf004303 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Jan 2024 11:17:15 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1706696235; bh=NsIKYYudIMulRiXBaVbQ9tqtqZfnI87FnUooroOtp+U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HXdHxpbFPRJVoBNO0HDMZOzgt4dq8VZxJiCKHGYktDnAqqEYzH+lUmxlsEXVCCbDM nuuFFE/kcgARj9KcdE/eXd7eeDMRX3nBRcq6IoR2eWAtpYBGHMJcQSEjpiQaIHIlAX uTCbQhcfjsvvt4Ce7A0ZCBcMUODVhQZxjKw447cs= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.17.1/8.16.1) with ESMTP id 40VAHExl028013; Wed, 31 Jan 2024 11:17:14 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.17.1/8.16.1/Submit) with ESMTP id 40VAHE2O028010; Wed, 31 Jan 2024 11:17:14 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 31 Jan 2024 11:17:14 +0100 (CET) From: Wojciech Puchar To: Warner Losh cc: Alan Somers , FreeBSD Hackers , Goran Meki?? Subject: Re: The Case for Rust (in the base system) In-Reply-To: Message-ID: <567c6bf7-1ccf-dde6-3792-ed4419fce3c8@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[puchar.net]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4TPydT55Tsz4HpL > materially improves things. The why of Rust is currently somewhere between hype and reality. Those that love it, love it Those that It's just another hype trying to solve problem of bad programmers. Proper programmer with proper use of brain cannot be replaced by machine. From nobody Wed Jan 31 10:29:36 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TPyvm6gZqz57TPF; Wed, 31 Jan 2024 10:29:40 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4TPyvm18Q1z4K8X; Wed, 31 Jan 2024 10:29:40 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=F0aryCdd; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.17.1) with ESMTPS id 40VATa4o013170 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Jan 2024 11:29:37 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1706696977; bh=BIzd/tTg4DpOXkfzqj+JvNoWdAsFWh6xm/gy7Au7fPA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=F0aryCdd+V2OmW8GE+F7caOs8s2Y3YbJCNM5v7bHozZqAbKnOzpHeOIVmREXpRuBd odFF/Lq3AiIRTNvHu4bEfM1Cc097+ZvB5uy/cdmzvDaEWyd4Mxy5RFMZ1IQiTHxTIJ b4GHE7D5L+Eu+2az3nbt0Ha08A1i1w7v+27qp8Ww= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.17.1/8.16.1) with ESMTP id 40VATaXv028052; Wed, 31 Jan 2024 11:29:36 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.17.1/8.16.1/Submit) with ESMTP id 40VATaEx028049; Wed, 31 Jan 2024 11:29:36 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 31 Jan 2024 11:29:36 +0100 (CET) From: Wojciech Puchar To: Mario Marietto cc: FreeBSD Mailing List , freebsd-hackers Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. In-Reply-To: Message-ID: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+] X-Rspamd-Queue-Id: 4TPyvm18Q1z4K8X quick dirty fix is to install bash and link /bin/sh to /usr/local/bin/bash (it may break something) other - manually compile later /bin/sh and replace. the problem is that newer ports needs newer /bin/sh From nobody Wed Jan 31 10:44:04 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TPzDq0ZHlz57W4V for ; Wed, 31 Jan 2024 10:44:27 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPzDp5PS6z4Lkg; Wed, 31 Jan 2024 10:44:26 +0000 (UTC) (envelope-from borjam@sarenet.es) Authentication-Results: mx1.freebsd.org; none Received: from localhost (unknown [194.30.0.88]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTP id D52E160C354; Wed, 31 Jan 2024 11:44:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sarenet.es; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received:received:received; s=saremail; t=1706697857; bh=3dKt0hzFLGoNfT3WjgD8YyltkBooFz6nK2 fuenzwRDo=; b=wdqrWGIwL37LdRhr/uTpRQoC6MmbCwcWW1qBUaifeu1oKSiiMS 5nx/sNeLfD8h2LcgSoHtGwjRxjCCYuneRyKhPIvnPNj9rx7+cTAvMKkkPfPN1F+x KFzIbyY424WersYX5UdCrOwONdbWQArUzsQa5AKed3FTisD8GeCpEWvRPs0FTYoB jPU/sSLJTL0Hs4AZo3X9wodgDUAgX1tyZae4N8+6pdhs1VCT6ip0fGJ/r5Tw0xJv h7qWUxMi8lsck7U6EQ5ifXcgXHukBW+cA+tYfZYMJc/hrJICVOxDQh9okwwRZ7gP YSntY8bF0JXt0l0vzdgqYJYrQIDc5DpsOymw== X-Amavis-Modified: Mail body modified (using disclaimer) - dkim-disclaimer03.saremail.com Received: from sieve-smtp-backend02.sarenet.es ([194.30.0.95]) by localhost (dkim-disclaimer03.saremail.com [194.30.0.88]) (amavisd-new, port 10024) with ESMTP id jNPQ8EAfqUQT; Wed, 31 Jan 2024 11:44:17 +0100 (CET) Received: from localhost (unknown [194.30.0.88]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTP id BDEA560C317; Wed, 31 Jan 2024 11:44:17 +0100 (CET) X-Amavis-Modified: Mail body modified (using disclaimer) - dkim-disclaimer03.saremail.com Received: from sieve-smtp-backend02.sarenet.es ([194.30.0.95]) by localhost (dkim-disclaimer03.saremail.com [194.30.0.88]) (amavisd-new, port 10023) with ESMTP id NNOXHOxfQ0hT; Wed, 31 Jan 2024 11:44:17 +0100 (CET) Received: from smtpclient.apple (unknown [192.148.167.11]) AUTENTIFICADOSAREMAIL by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 4AB9D60C332; Wed, 31 Jan 2024 11:44:15 +0100 (CET) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: The Case for Rust (in the base system) From: Borja Marcos In-Reply-To: Date: Wed, 31 Jan 2024 11:44:04 +0100 Cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers , Warner Losh , Scott Long , =?utf-8?Q?Goran_Meki=C4=87?= Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Puchar X-Mailer: Apple Mail (2.3774.400.31) X-dominio-dkim: sarenet.es X-rutado-saremail: smtp1176 X-Rspamd-Queue-Id: 4TPzDp5PS6z4Lkg X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES] > On 31 Jan 2024, at 11:15, Wojciech Puchar wrote: >=20 >> I don=E2=80=99t want to do a what-aboutism, but if all we=E2=80=99re = looking for is a good and >> secure system programming language, the alternatives are nicer. > The is no such thing as secure system programming language. > Security come only from proper programming practices. While I think I agree with the arguments against including Rust, there = are programming languages that make it really hard to manage the possible interactions between components and = hence expose you to security issues.=20 C is the =E2=80=9Crust golden=E2=80=9D example. Complexity can become = unbearable and it can be compared to programming in assembler. ;) Borja. From nobody Wed Jan 31 11:14:55 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TPzwF14K4z57YFm for ; Wed, 31 Jan 2024 11:15:09 +0000 (UTC) (envelope-from theraven@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPzwF0b4Fz4PKt; Wed, 31 Jan 2024 11:15:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706699709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L/HmiDCWCLVCiSZ5qVHOgRzt9CHci3WqDSs/9UHJPx8=; b=Y7BdZYwsBt+meTHuZrUYC1Pcx3ndZ8RHwFeJSVdZqTpEql1KJ8fRkGX9fVKSRBaYuuh3/4 VZzHDgrm8g3XCYyqv6uOyUXdFCL6h9murfN/yzzq9nz4a4IOrWFfzkwuPvHCahnIZiap5j fn8YIqWdhnM/4kirFiBIKYfZnKq8OjXwhArpscFtsExE+67voleVXXnny5Y56ay+KjOcWI HIYHqpa1FhefQgPk9d/yDSIrhwTDnA2CN05E4RxIusNCHS2iJa3sxupUSzbtF7VljYLiQf jHXCfPAmpGu0r4eGNdM2Myd/HNQh5ce73uW7fQwGbl02HMHwKgrbbJXAW+pieQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706699709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L/HmiDCWCLVCiSZ5qVHOgRzt9CHci3WqDSs/9UHJPx8=; b=pRuakbBV0h0pS/ckwjP3nkEWq4Fctj3chbkKAt597Xxv2pEL9gzs2iWv2uDyPBM8ymObUO SswXfSCKcmGxPlpShpbHi3mk5uYXkvPNuOyMl4EQsYe/U1KN7dYwSw45UHjyd+7rsRyEj+ qMCkwRS6SSH2Pbbhrvaz1Ss6agxG1kcxT3uqqWj/xqihxRSTiykxY6AIwQiqP+32eCtIZ6 oNjLuAH92BhZIinpiiwmdYk2rZurLpPJ3lcfrGx/G7W5V+gK8QBfVeiqcgAvSEGrb2B85m oWdcw0+QfwzQnO+R/OoBDIW2I9LIHVlo8N9cif/xZ3l3zSwf8Aiukfzmi4sY4g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706699709; a=rsa-sha256; cv=none; b=nwP3vctXGdregCq2f5Qzfsn3w9tUQGHChqdBu0xGx5wyfQUkQW3BIxMbECVmySq3UVV5fn ooMSypXB6nevDGX2Omg6KHbzeo9ySM3BCB36eQG9Fqgag3V9Fdd0/2v4d9S5Ij3r64MaiB 4F8RNCn/grFJTQT3/zp2tvMRrj4q8vj/XnsXBUUtmbYxyMiqEnz0FcRoxbG3WzpfNt36Kl hTeiUexkzp6pYsgEaGN+DUy33nWmL7v4ar6tCT8ELoRUfJd/6bbClzC4H/KtZdMXekHjYb j0TnCd7fUbLHFhTsU8ananimnFkWDbrRcysozW3pDTC4r7lnfh6T/kO8pnevMA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TPzwD6bzyzbqY; Wed, 31 Jan 2024 11:15:08 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-153-95-118.range109-153.btcentralplus.com [109.153.95.118]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 26E74C0A7; Wed, 31 Jan 2024 11:15:07 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: The Case for Rust (in the base system) From: David Chisnall In-Reply-To: Date: Wed, 31 Jan 2024 11:14:55 +0000 Cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers , Warner Losh , Scott Long , =?utf-8?Q?Goran_Meki=C4=87?= Content-Transfer-Encoding: quoted-printable Message-Id: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> References: To: Wojciech Puchar X-Mailer: Apple Mail (2.3774.200.91.1.1) On 31 Jan 2024, at 10:15, Wojciech Puchar wrote: >=20 > The is no such thing as secure system programming language. While true in the absolute, that=E2=80=99s an unhelpful framing. = Different languages can eliminate different bug classes by construction. = The same is true of different APIs. For example, SQL injection attacks = are completely eliminated by APIs that present format strings, whereas = they are easy to introduce in ones that require you to construct an SQL = expression by string concatenation. For the languages under discussion, the key properties are memory = safety. Rust and modern C++ prevent a lot of bounds errors by carrying = bounds either in the type or as properties of a value and performing = explicit checks. More importantly, they provide abstractions such as = iterators, ranges, and views, which make bounds errors impossible by = construction because they use subset-like operators on valid ranges = derived from a collection and so ensure that every range that you = iterate over *must* be a valid subrange of the underlying collection. = They provide ownership semantics for pointers (in the language for Rust, = in the library via RIAA and smart pointers) than ensure that owning a = pointer prolongs its lifetime and so avoid temporal safety errors. Can a programmer get these things right without language support? = Absolutely, but each programmer has a finite budget for cognitive load. = In addition to thinking about memory management, they need to think = about good data structure design, efficient algorithms, and higher-level = security properties. The more attention that they have for these = things, the better their code is. We=E2=80=99ve seen this in some of = the Apple Silicon drivers for Linux, where writing them in Rust with = strong ownership types made it easy to implement some concurrent = algorithms that would be hard to get right in C and led to fast and = correct code. In terms of safe *systems* programming, I would regard the definition of = *systems* programming as programming that needs to step outside of a = language=E2=80=99s abstract machine. Memory allocators and schedulers, = for example, are in this category. These still benefit from richer type = systems (in snmalloc, as I mentioned previously in the thread, we model = the allocation state machine in C++ templates to ensure that memory = state transitions are all valid as memory moves between allocated and = the various states of deallocation), but the language cannot enforce = strong properties, it can at best provide the programmer with tools to = ensure that certain properties are always true in code that compiles. It=E2=80=99s up to you where you want to invest your cognitive budget, = but for code that runs in the TCB I=E2=80=99d rather we have as many = properties correct by construction as possible. David= From nobody Wed Jan 31 11:35:02 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQ0Mx2YRnz58Kwj; Wed, 31 Jan 2024 11:35:41 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ0Mx24pJz4RCG; Wed, 31 Jan 2024 11:35:41 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a35e65df2d8so376076266b.0; Wed, 31 Jan 2024 03:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706700940; x=1707305740; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IErXxhnr7Sr3iuRkIP+bNCT9P+lyiJi7K5wIctH9pCQ=; b=LpfarKJwa0DzMHG7DEGDrSXAQm+ltSyG26jVHXwcwhSyhjKCTGDQP116f4ceJTiuaA vwoo1frgmRVcwSRBMpa2zc/vaeobSkSOB4dkhK3ahLDI/agU4il3aT4wBi4KdNGQ/aQu k54/yNEpvp6gqQvzZ9KHK28jCp8Y0lfE7IxhDwojeLLBr9GwKY5p2ufkM9EJMep6n/eC OUgshVMgUSuYIycopBGmJRnVLHsxgSXgPSzFDtRY7Didvn+Ccb/+GV3VDz9R0QVl50t9 emsbAbONYEJI8wojv6qo8iwfFeJCEHdQdiq2EvN/syOqNjbOVVQ3xwdkNdAmy9HsVcJ8 1siQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706700940; x=1707305740; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IErXxhnr7Sr3iuRkIP+bNCT9P+lyiJi7K5wIctH9pCQ=; b=gFkfP57gnjFUiX2nOFUzLjQ+mI3MziVbAoXVArscaszL6TeibaRGH8DMpCXUhdPQea jt+J6/QXnYZQsCOjir4uuw75BoRnpQHm+Fq+BxWYBceje9ljAl373VhpylsS2S3ySgTn 8JuiYdWLEVJdhZCARHr+lAzy7HNPhObPvwVQVOvI1wkJ8xPiY41mYxRjbG9RXpPsRy8k gC2ECCHuTLY/a5bCyWVELPvTrNk6O9TXIITtoy9GhG0r+VSLuwqtusd2X+9LX8TklEwh D8da/zUzi7WF4l2U9O0BKm2l6twu+5BTSyJQHlhVivYMmz7wP7htqbZT1NAAdGIIXa6O Xtcw== X-Gm-Message-State: AOJu0YyOSNE1vyU8CEmHAtxNm90d6Ws7yCC8a2YMMtbSfoRs+Ycjlv44 mc+aZLrodoylokjvBnSNzAY+IY/ej1GcH9+x+yeIt30ataojXMC9suew3TxRm+aNKhsGguDcoyc e0NqjfbEJEXb59ufXOtddqWGiFIo= X-Google-Smtp-Source: AGHT+IGFM8zgkJSyB2q1hiXS4r8mphdY7yGpchl9Fr50578iFlW5B4itXMaw3v6bC3eTBG6zP0UPMHuE4h3m+O9u6uw= X-Received: by 2002:a17:907:171b:b0:a31:1907:2fe8 with SMTP id le27-20020a170907171b00b00a3119072fe8mr957060ejc.48.1706700939343; Wed, 31 Jan 2024 03:35:39 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> In-Reply-To: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> From: Mario Marietto Date: Wed, 31 Jan 2024 12:35:02 +0100 Message-ID: Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. To: Wojciech Puchar Cc: FreeBSD Mailing List , freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000003a3be306103c4790" X-Rspamd-Queue-Id: 4TQ0Mx24pJz4RCG X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --0000000000003a3be306103c4790 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What I haven't understood is why you are talking about newer ports when the only thing I do is to update ports using the same FreeBSD version,in this case 10.4. I mean,upgrading ports without upgrading the version of FreeBSD,can't mean to use newer ports,since I don't use a newer version of the OS. On Wed, Jan 31, 2024 at 11:29=E2=80=AFAM Wojciech Puchar wrote: > quick dirty fix is to install bash and link /bin/sh to /usr/local/bin/bas= h > (it may break something) > other - manually compile later /bin/sh and replace. > > the problem is that newer ports needs newer /bin/sh > --=20 Mario. --0000000000003a3be306103c4790 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What I haven't understood is why you are talking about= newer ports when the only thing I do is to update ports using the same Fre= eBSD version,in this case 10.4. I mean,upgrading ports without upgrading th= e version of FreeBSD,can't mean to use newer ports,since I don't us= e a newer version of the OS.

On Wed, Jan 31, 2024 at 11:29=E2=80=AFAM Wo= jciech Puchar <wojtek@puchar.net> wrote:
qui= ck dirty fix is to install bash and link /bin/sh to /usr/local/bin/bash (it may break something)
other - manually compile later /bin/sh and replace.

the problem is that newer ports needs newer /bin/sh


--
Mario.
--0000000000003a3be306103c4790-- From nobody Wed Jan 31 12:16:35 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQ1HB1CMBz58Py4; Wed, 31 Jan 2024 12:16:38 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4TQ1H950t4z4WgP; Wed, 31 Jan 2024 12:16:37 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-hackers@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 40VCGZuT001052; Wed, 31 Jan 2024 12:16:35 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 40VCGZSo001051; Wed, 31 Jan 2024 12:16:35 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202401311216.40VCGZSo001051@donotpassgo.dyslexicfish.net> Date: Wed, 31 Jan 2024 12:16:35 +0000 Organization: Dyslexic Fish To: wojtek@puchar.net, marietto2008@gmail.com Cc: freebsd-questions@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. References: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Wed, 31 Jan 2024 12:16:35 +0000 (GMT) X-Rspamd-Queue-Id: 4TQ1H950t4z4WgP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US] Mario Marietto wrote: > What I haven't understood is why you are talking about newer ports when the > only thing I do is to update ports using the same FreeBSD version,in this > case 10.4. I mean,upgrading ports without upgrading the version of > FreeBSD,can't mean to use newer ports,since I don't use a newer version of > the OS. The ports infrastucture (under /usr/ports/Mk) now contains scripts that set the "pipefail" option - these scripts are updated when you update the ports tree. I had an old out-of-date box for a while, and used this quick hack to get it to work. You need to run this after you update the ports tree: sed -i.bak '/^[[:space:]]*set [+-]o pipefail/d' /usr/ports/Mk/Scripts/* It removes the references to pipefail. This can mean that some build errors are potentially not trapped, but if that's the case you're likely to notice the failure anyway. Still best to update your system or your /bin/sh though! Cheers, Jamie From nobody Wed Jan 31 14:31:11 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQ4HC6n2xz58dQJ; Wed, 31 Jan 2024 14:31:51 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ4HB5x6wz4t5j; Wed, 31 Jan 2024 14:31:50 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-55efbaca48bso5030626a12.2; Wed, 31 Jan 2024 06:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706711509; x=1707316309; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eoJG7eRx8UCNhJks2Uuc52pkrPBfBeUlZnKeYHOjVcA=; b=cZnFfuMLnB5BCxOjCXhOiMhFSqy0RC+rRHOU8Xvi4az+yl1vnRus9k4UP+AGXTUcHi QrjK0DU8nCTEL2gaeUEDG34AVRgJuVOGirHCKtfQQ9j6XT/hwHi4cOcSyUdhN5T5rFY5 bg2J/GhHA1Mdy/zmc2TOZGvtQe9N06T5w/NMmnHDrDJmqXBEe9c+8OITjtVA67RanLfK qO+8asOaxTVQ74CYhUvGu3FdPZE5mzhMatPFHmu9W5fiIdzU7MQpbZskf/mFa8xvqeid q5XFV9LeZ+iNbsOYByDcySPn8Q4xMvIOJ7K7XHkghlvHaTxKZXixk90mlE83Mx1akk8X bUow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706711509; x=1707316309; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eoJG7eRx8UCNhJks2Uuc52pkrPBfBeUlZnKeYHOjVcA=; b=SnR8XyU+DPVQi2HAMlqUyFSixxiuzzQpgZFc9iDnPY+hE27smtbrCKtZn9nr99JiWg soO/mTTwr+A+j8KKjee2/5Sw3lymOM1W1kLAqiqJIqGXOJ5YHnE7DMUqyuq3/3bEHLtA bGZI6m6ZZ6l93SuKJCO5Owaojkpdgf8+LIdxh2O0curU6XHf03+SRd2WQE7dwhppu7nz Exeva9b9H7/N7NTCsxTMzI58WtOvSI6I/eniZ5/nxcRTzFMXM22JFW1L5pVE4/6D/PGx kMPVYNsPZoOl6CvgJ82plyR17D6zZ4u2OpnWuYi1oIfCL0h3z5iS76dZ2KHixANBPzAp tnKQ== X-Gm-Message-State: AOJu0Yyqk3ADgkqle88Wcs/gTHijzR6Pk7RAQu4dLl9cqKeHKLUOSasi uPpX4aWB4U8kSCH9LnXpQHIB3QtAbgUuh5Y8lz0foEkQ41KVy6gn1sxze4UOD0Y9P39s4txmYEi qhrIpoC/22FU0o8c/gwrQk9HcOAbbw6lk X-Google-Smtp-Source: AGHT+IG+ZRGnnZEtWCecd9klWcDLaN6sJw1IxQBzOogur4r/WvRDoR+jOQ47j/a8QS7IkfWGXlgXkJDXC9sVB5DDcqA= X-Received: by 2002:a17:906:3b19:b0:a35:7192:1f with SMTP id g25-20020a1709063b1900b00a357192001fmr1352702ejf.49.1706711509146; Wed, 31 Jan 2024 06:31:49 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> <202401311216.40VCGZSo001051@donotpassgo.dyslexicfish.net> In-Reply-To: <202401311216.40VCGZSo001051@donotpassgo.dyslexicfish.net> From: Mario Marietto Date: Wed, 31 Jan 2024 15:31:11 +0100 Message-ID: Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. To: Jamie Landeg-Jones Cc: wojtek@puchar.net, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003ca13206103ebd00" X-Rspamd-Queue-Id: 4TQ4HB5x6wz4t5j X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --0000000000003ca13206103ebd00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jamie, I ran your script and it gave no error message,BUT I still got the error : root@marietto:/usr/ports/ports-mgmt/pkg # make set: illegal option -o pipefail.... ? On Wed, Jan 31, 2024 at 1:16=E2=80=AFPM Jamie Landeg-Jones wrote: > Mario Marietto wrote: > > > What I haven't understood is why you are talking about newer ports when > the > > only thing I do is to update ports using the same FreeBSD version,in th= is > > case 10.4. I mean,upgrading ports without upgrading the version of > > FreeBSD,can't mean to use newer ports,since I don't use a newer version > of > > the OS. > > The ports infrastucture (under /usr/ports/Mk) now contains scripts that s= et > the "pipefail" option - these scripts are updated when you update the por= ts > tree. > > I had an old out-of-date box for a while, and used this quick hack to get > it to work. > > You need to run this after you update the ports tree: > > sed -i.bak '/^[[:space:]]*set [+-]o pipefail/d' /usr/ports/Mk/Scripts/* > > It removes the references to pipefail. This can mean that some build erro= rs > are potentially not trapped, but if that's the case you're likely to noti= ce > the failure anyway. > > Still best to update your system or your /bin/sh though! > > Cheers, Jamie > --=20 Mario. --0000000000003ca13206103ebd00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jamie,

I ran your script and= it gave no error message,BUT I still got the error :=C2=A0

<= /div>
root@marietto:/usr/ports/ports-mgmt/pkg # make
set:= illegal option -o pipefail....

?
<= br>
On Wed,= Jan 31, 2024 at 1:16=E2=80=AFPM Jamie Landeg-Jones <jamie@catflap.org> wrote:
Mario Marietto <marietto2008@gmail.com> wrote= :

> What I haven't understood is why you are talking about newer ports= when the
> only thing I do is to update ports using the same FreeBSD version,in t= his
> case 10.4. I mean,upgrading ports without upgrading the version of
> FreeBSD,can't mean to use newer ports,since I don't use a newe= r version of
> the OS.

The ports infrastucture (under /usr/ports/Mk) now contains scripts that set=
the "pipefail" option - these scripts are updated when you update= the ports
tree.

I had an old out-of-date box for a while, and used this quick hack to get it to work.

You need to run this after you update the ports tree:

sed -i.bak '/^[[:space:]]*set [+-]o pipefail/d' /usr/ports/Mk/Scrip= ts/*

It removes the references to pipefail. This can mean that some build errors=
are potentially not trapped, but if that's the case you're likely t= o notice
the failure anyway.

Still best to update your system or your /bin/sh though!

Cheers, Jamie


--
Mario.
--0000000000003ca13206103ebd00-- From nobody Wed Jan 31 14:45:29 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQ4bj0Zltz58fw0; Wed, 31 Jan 2024 14:46:09 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ4bg6pjRz3x4y; Wed, 31 Jan 2024 14:46:07 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="Msb/dDNC"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=marietto2008@gmail.com Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-55f19a3ca7aso1850199a12.1; Wed, 31 Jan 2024 06:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706712366; x=1707317166; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=a2HbxWPGtCb3J4yT1cBIValySXAmSIL7eDlOsAGreRM=; b=Msb/dDNCtls/v/wAp4AY4OjJKGU5W+79Zw0cKZ4/sRtIRxXXeIeyruunYYrkpG2ra4 6wdT9AROU8Qr2lp9IxEqKdVFnKkN2L/fHcqyX0xKIyJhW9z1EIOr3h6HEA+u/DRHjN50 Gr4oTFPk+f92wEClgXSEjwV2Dqp7p9jw3NNsA1rN2kGzPffJPrOIUnKJ/TY0dUMAFbw5 ZCN27TmILEAMLVeZGy2Dy3f+xIdK8Qf801yJzHLG7832MLeGu6Ic/MRfAHbjoMWaJ2qG 3zpSeGBoSWk3etK+m/yjZX236Ql/DvOReydBQfeksQtZLJrxavsfo6yG9REo+FWrrVFM DWKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706712366; x=1707317166; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=a2HbxWPGtCb3J4yT1cBIValySXAmSIL7eDlOsAGreRM=; b=cm/lR1Z/0XeLhQJcxkTSHdDoyENIGP3Y9iA9H2vHgQQfekxBmb21FjLyeXq94ZIAjV SBKbAOKXj1+V85Azs8yH2ehX/3NoqWVXZ3jUVav+YD69/KKq8vQ8XyJ7ZSsAAo6t5CoH hkYXE+CJ2GrUdWoX1Bz09y8OC62VSJYB5D4vHSCVql0AUYQCJdcnBRgqlN0khK75lw3r +GvwCmRkOQ5r6sp0bWQpBsg3d7GMv6o8nSPSmRxGLjrDVqJSjjaDalPchF2K/wv/Olj3 zRjKa0nwHYQWmBIBxTlY1IlP6TexSjAGX8esQYF0zgH8bKNmRXo0Pwbj/aQNIUIXzVIy e5fw== X-Gm-Message-State: AOJu0Yw7KrIj2zZqXDFZdIV7cfzBpvGGWNOHZwd443lLRu6v0d1niAxo 8DmCzc6pfrCqawaCrQ2Ac6i3aFC+pADDzanEcV4yVCJ/m9daVdDJqG5HcN2Kt8gdEe2DRsmq3Er nExcf78AGMMpcvpMmoqCQAjW3T84= X-Google-Smtp-Source: AGHT+IE5gPZ1u2GN3oEnRTl2IzFn8pMeu4vgb5IPz/aTghalsg1Ugj/levpJ2LpKfTC2MGdCuE9FCnUuhQA6Yk6g+mE= X-Received: by 2002:a17:906:254a:b0:a23:5939:759e with SMTP id j10-20020a170906254a00b00a235939759emr1646604ejb.26.1706712366202; Wed, 31 Jan 2024 06:46:06 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> <202401311216.40VCGZSo001051@donotpassgo.dyslexicfish.net> In-Reply-To: From: Mario Marietto Date: Wed, 31 Jan 2024 15:45:29 +0100 Message-ID: Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. To: Jamie Landeg-Jones Cc: wojtek@puchar.net, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000052417506103ef0f6" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.77 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.77)[-0.772]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org,freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4TQ4bg6pjRz3x4y --00000000000052417506103ef0f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can you tell me where should be stored the references to pipefail ? Maybe I will try to remove them manually. Maybe your command does not work out of the box. On Wed, Jan 31, 2024 at 3:31=E2=80=AFPM Mario Marietto wrote: > Jamie, > > I ran your script and it gave no error message,BUT I still got the error = : > > root@marietto:/usr/ports/ports-mgmt/pkg # make > set: illegal option -o pipefail.... > > ? > > On Wed, Jan 31, 2024 at 1:16=E2=80=AFPM Jamie Landeg-Jones > wrote: > >> Mario Marietto wrote: >> >> > What I haven't understood is why you are talking about newer ports whe= n >> the >> > only thing I do is to update ports using the same FreeBSD version,in >> this >> > case 10.4. I mean,upgrading ports without upgrading the version of >> > FreeBSD,can't mean to use newer ports,since I don't use a newer versio= n >> of >> > the OS. >> >> The ports infrastucture (under /usr/ports/Mk) now contains scripts that >> set >> the "pipefail" option - these scripts are updated when you update the >> ports >> tree. >> >> I had an old out-of-date box for a while, and used this quick hack to ge= t >> it to work. >> >> You need to run this after you update the ports tree: >> >> sed -i.bak '/^[[:space:]]*set [+-]o pipefail/d' /usr/ports/Mk/Scripts/* >> >> It removes the references to pipefail. This can mean that some build >> errors >> are potentially not trapped, but if that's the case you're likely to >> notice >> the failure anyway. >> >> Still best to update your system or your /bin/sh though! >> >> Cheers, Jamie >> > > > -- > Mario. > --=20 Mario. --00000000000052417506103ef0f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you tell me where should be stored the references to p= ipefail ? Maybe I will try to remove them manually. Maybe your command does= not work out of the box.

On Wed, Jan 31, 2024 at 3:31=E2=80=AFPM Mario= Marietto <marietto2008@gmail.= com> wrote:
Jamie,

I ran your script = and it gave no error message,BUT I still got the error :=C2=A0
root@marietto:/usr/ports/ports-mgmt/pkg # make
s= et: illegal option -o pipefail....

?

On W= ed, Jan 31, 2024 at 1:16=E2=80=AFPM Jamie Landeg-Jones <jamie@catflap.org> wrote:
=
Mario Marietto <= marietto2008@gm= ail.com> wrote:

> What I haven't understood is why you are talking about newer ports= when the
> only thing I do is to update ports using the same FreeBSD version,in t= his
> case 10.4. I mean,upgrading ports without upgrading the version of
> FreeBSD,can't mean to use newer ports,since I don't use a newe= r version of
> the OS.

The ports infrastucture (under /usr/ports/Mk) now contains scripts that set=
the "pipefail" option - these scripts are updated when you update= the ports
tree.

I had an old out-of-date box for a while, and used this quick hack to get it to work.

You need to run this after you update the ports tree:

sed -i.bak '/^[[:space:]]*set [+-]o pipefail/d' /usr/ports/Mk/Scrip= ts/*

It removes the references to pipefail. This can mean that some build errors=
are potentially not trapped, but if that's the case you're likely t= o notice
the failure anyway.

Still best to update your system or your /bin/sh though!

Cheers, Jamie


--
Mario.


--
Mario.
--00000000000052417506103ef0f6-- From nobody Wed Jan 31 15:07:34 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQ54z6c4Qz58j4l for ; Wed, 31 Jan 2024 15:08:03 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ54z1pF8z431H; Wed, 31 Jan 2024 15:08:03 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 40VF7YIR053509; Thu, 1 Feb 2024 00:07:35 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 1 Feb 2024 00:07:34 +0900 From: Tomoaki AOKI To: David Chisnall Cc: Wojciech Puchar , Antranig Vartanian , Alan Somers , FreeBSD Hackers , Warner Losh , Scott Long , Goran =?UTF-8?B?TWVracSH?= Subject: Re: The Case for Rust (in the base system) Message-Id: <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp> In-Reply-To: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> References: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4TQ54z1pF8z431H X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] On Wed, 31 Jan 2024 11:14:55 +0000 David Chisnall wrote: > On 31 Jan 2024, at 10:15, Wojciech Puchar wrote: > > > > The is no such thing as secure system programming language. > > While true in the absolute, that’s an unhelpful framing. Different languages can eliminate different bug classes by construction. The same is true of different APIs. For example, SQL injection attacks are completely eliminated by APIs that present format strings, whereas they are easy to introduce in ones that require you to construct an SQL expression by string concatenation. > > For the languages under discussion, the key properties are memory safety. Rust and modern C++ prevent a lot of bounds errors by carrying bounds either in the type or as properties of a value and performing explicit checks. More importantly, they provide abstractions such as iterators, ranges, and views, which make bounds errors impossible by construction because they use subset-like operators on valid ranges derived from a collection and so ensure that every range that you iterate over *must* be a valid subrange of the underlying collection. They provide ownership semantics for pointers (in the language for Rust, in the library via RIAA and smart pointers) than ensure that owning a pointer prolongs its lifetime and so avoid temporal safety errors. > > Can a programmer get these things right without language support? Absolutely, but each programmer has a finite budget for cognitive load. In addition to thinking about memory management, they need to think about good data structure design, efficient algorithms, and higher-level security properties. The more attention that they have for these things, the better their code is. We’ve seen this in some of the Apple Silicon drivers for Linux, where writing them in Rust with strong ownership types made it easy to implement some concurrent algorithms that would be hard to get right in C and led to fast and correct code. > > In terms of safe *systems* programming, I would regard the definition of *systems* programming as programming that needs to step outside of a language’s abstract machine. Memory allocators and schedulers, for example, are in this category. These still benefit from richer type systems (in snmalloc, as I mentioned previously in the thread, we model the allocation state machine in C++ templates to ensure that memory state transitions are all valid as memory moves between allocated and the various states of deallocation), but the language cannot enforce strong properties, it can at best provide the programmer with tools to ensure that certain properties are always true in code that compiles. > > It’s up to you where you want to invest your cognitive budget, but for code that runs in the TCB I’d rather we have as many properties correct by construction as possible. > > David First of all, NO MEMORY-SAFE language can write codes using volatile memory objects, most notably, memory-mapped I/O and/or DMA driver. I formerly thought "Rust should NOT be able to write one by itself only, as Rust guys states it's memory-safe". But I huppened to know "unsafe" keyword to allowing such a thing. So I come to consider Rust as non-memory-safe. Evil programmer CAN ABUSE THE MECHANISM. Recall what happened to Linux kernel by UMN. [1] [2] Even using Rust, memory safety is ON HUMAN. Rust should have NOT introducing such a functionality and let them be kept on C and/or assembler codes to be called. This way, C/assembler could have been focused upon left C/assembler codes only about memory-safety. Yes, there can be memory-mapped I/O devices which completely divide addresses it uses for input and output. In such devices, "unsafe" keyword should be needed at all IN THEORY, but hardware/firmware bugs and intentional backdoors could overrun the buffer on write. Keeping these in mind, Rust would be EASIER to write memory-safe codes than C/assembler. What are problems of Rust-in-Base, I think, are that *Differences of philosophy. Unix and its delivetives, of course including FreeBSD base, is based on simplicity and memory/disk efficiency, notably uses of shared objects (*.so). Reuse / share everything immutable anywhere. In contrast with it, Rust persons prefer "sharing source codes as crates but do NOT share compiled objects". IIUC, if crate A is used on crate B and C, and crate B is used by crate D, usually crate D is built with crate A and B included. Then, if crate C and D is required by crate E as dinamically loadable module (the API/ABI changes when Rust itseld is updated, thus basically required full rebuild to link as native Rust objects), crate A and B are duplicated when object created from crate E are loaded. In these cases, all of crate A, B, C, D and E should be build as dynamically linked object and avoid duplicates. *API/ABI instability within Rust versions. But IIUC, this would be avoided if built with --crate-type=cdylib. We should force this unless the whole codes of FreeBSD are rewritten with Rust only. No moving goal is wanted for not-enough-large projects. *crates. All crates needed for FreeBSD base SHALL be BSD-compatiblly licensed and allowed to fork to commit to FreeBSD src tree. Every other crates need to be REIMPLEMENTED BY OURSELVES WITH CLEAN ROOM DEVELOPEMENT. *CPU consumption of rustc. For anyone not having dedicated build computer like me, if any of poudriere jail stard building Rust codes, the computer on hand becomes unresponsive/unusable, as ALL EXISTING CORES ARE EATEN UP. This would possibly fixed/relaxed once sched_ule is overhauled or new scheduler which can avoid this is implemented. At least for now, 6C12T core processor is not at all enough for Rust. [1] https://www.bleepingcomputer.com/news/security/linux-bans-university-of-minnesota-for-committing-malicious-code/ [2] https://www.reddit.com/r/HobbyDrama/comments/nku6bt/kernel_development_that_time_linux_banned_the/ -- Tomoaki AOKI From nobody Wed Jan 31 15:50:40 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQ62P3YXcz58mCP for ; Wed, 31 Jan 2024 15:50:53 +0000 (UTC) (envelope-from theraven@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ62P30gdz46f4; Wed, 31 Jan 2024 15:50:53 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706716253; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sUGySNXfZnNW1l5Kx6eobtIsVsv2oYLSWyXOHPVf1tA=; b=S1j0p1PcKG90ck4mG5jRMXqOyrsV8F8bbB9CSQ1ypwa2Ad+rIa0DlzDehJhNq2z1CMQOjg Vqo6JIiEXSNG8uU3SuR74OlOzZR05CaKiFjrHXXvuaaPM3n56xgoFK25AQjcCg1h0wWq3V qfPl334XtlGblBQQ/Ah7z5sJA5SRdj0VBBSXzg7zIm2VRj8unhJaZ8vhBpFkUvic2F+IGN R6/pCKw8DlwRnRshp9C62L9+erXv64XyrCWti8Pk1qC71U9VjEn7U+ctPugHGuvOusK+yB 6g9KL8UpRr3AGY8izoXpCM4FapLKB6m/5dLgghOGV2cnIfZdtUlKWK+xfOr+2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706716253; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sUGySNXfZnNW1l5Kx6eobtIsVsv2oYLSWyXOHPVf1tA=; b=WjSbSnZjz5kQ3olrhcvYnH/uZgcJTt+veSjzQHQqvp+uJYbCe18Ehr0M7wKTEDSa5ShKcL xBRXuhIao6Sc35zCwYylH/ih8vJj9nrnPf0cZdJ9c2Da5KLc879rJSqDlO0caktvrS7UBy /lxtNUkQsPbOfBoJwN8glMt4h0hbIeiQR0wkfxwTWsn5sn6BF/KBxjM2sC6QuFDEouVs+E NylglydX4X15h00gGxSiQeazLK81vgp2v59m2I/GHXx4FSNHPGOI60Y7+8E9gwTw+22eD1 x0nDA4fItEkAaXJjKgwwAmkuxp6eJ47HhXc0KLVLO5K76+l6715gnTQDvCgAzA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706716253; a=rsa-sha256; cv=none; b=D4tRD+Mu6YRNJjitCdfjdlHR7RDXH1cm9QH2VdVIgMCbE+p9FSVfPmuedp0rqOqBFQaXd4 JNd3rsFVqvYNuXpWU3M9oQIGFliQr5+dwMQ02tqWgAV5C5mv6zH+ReeaCL+QrNaewUvIpc PzJ06Na52ToSQVf3MRBmw94jalc0Gutn9G2Opogp9NDdD+pwLIWN6Wd6O8TFAXkprDUr2U wEOGAHTdFx/SHin537U7DU1976C4hitr0TRGyF4boUIgVgZ9e77/Q62GhMvM1FV2CWPwrd 7V1X6M4dPOUrsIN6iEtD9s2fAxH/qRG0WuuWJ7zrCwszQuSa03H0GeWHlzoTiQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TQ62P20hXzhQD; Wed, 31 Jan 2024 15:50:53 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-153-95-118.range109-153.btcentralplus.com [109.153.95.118]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 06C6CC0AE; Wed, 31 Jan 2024 15:50:51 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: The Case for Rust (in the base system) From: David Chisnall In-Reply-To: <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp> Date: Wed, 31 Jan 2024 15:50:40 +0000 Cc: Wojciech Puchar , Antranig Vartanian , Alan Somers , FreeBSD Hackers , Warner Losh , Scott Long , =?utf-8?Q?Goran_Meki=C4=87?= Content-Transfer-Encoding: quoted-printable Message-Id: <782FA00C-3B90-49C8-85F7-AF784F42A3CC@FreeBSD.org> References: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp> To: Tomoaki AOKI X-Mailer: Apple Mail (2.3774.200.91.1.1) On 31 Jan 2024, at 15:07, Tomoaki AOKI = wrote: >=20 > First of all, NO MEMORY-SAFE language can write codes using volatile > memory objects, most notably, memory-mapped I/O and/or DMA driver. The first half of that is obvious nonsense. Memory-mapped I/O is not = intrinsically unsafe, from a memory-safety perspective. Even Java has = volatile objects and Sun Labs used Java for device drivers twenty years = ago. Having a memory-safe interface for MMIO is helpful. With another hat, I am the maintainer of CHERIoT RTOS, which uses = hardware-enforced memory safety for all code, including RTOS code. All = of our drivers do direct MMIO and are memory safe. DMA is in the category of things that I class as real systems = programming because it sits below the level of the language abstract = machine and so *is* able to violate the guarantees. Even in C; however, = the busdma framework tries to make this safe: you are not *supposed to* = DMA to and from arbitrary memory. A strong type system can enforce = this. > I formerly thought "Rust should NOT be able to write one by itself > only, as Rust guys states it's memory-safe". But I huppened to know > "unsafe" keyword to allowing such a thing. Correct, for things that are real systems programming tasks, you need to = poke holes in Rust=E2=80=99s abstract machine via the unsafe keyword. = These come with an implicit contract that *you* are now responsible for = enforcing those rules at the boundary. For a DMA interface, for = example, a Rust equivalent of the busdma framework would provide objects = that encapsulate valid DMA mappings whose lifetime manages IOMMU = entries. These would be passed into unsafe blocks for DMA operations. = Within those blocks, you could still violate memory safety, but the code = review required to ensure that you don=E2=80=99t is entirely local = reasoning. > So I come to consider Rust as non-memory-safe. Evil programmer CAN > ABUSE THE MECHANISM. Recall what happened to Linux kernel by UMN. [1] > [2] A malicious programmer, whose code is not reviewed properly or who = manages to sneak in bad code, can break out of the type system for Rust. = In contrast, a C programmer whose attention drifts for a few seconds = while typing can do the same thing. > Even using Rust, memory safety is ON HUMAN. Rust should have NOT > introducing such a functionality and let them be kept on C and/or > assembler codes to be called. This way, C/assembler could have been > focused upon left C/assembler codes only about memory-safety. I don=E2=80=99t understand the rationale here. FFI in Rust, due to the = tight coupling, needs to be unsafe. Whether your unsafe language is a = subset of Rust or is purely FFI code, it still exists. If it=E2=80=99s = a subset of Rust, then it=E2=80=99s easier to review because it=E2=80=99s = in context and can operate over Rust types. > Yes, there can be memory-mapped I/O devices which completely divide > addresses it uses for input and output. In such devices, "unsafe" > keyword should be needed at all IN THEORY, but hardware/firmware bugs > and intentional backdoors could overrun the buffer on write. This is specific to MMIO devices *that initiate DMAs* > Keeping these in mind, Rust would be EASIER to write memory-safe codes > than C/assembler. Correct. David From nobody Wed Jan 31 18:52:38 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQB4t0gMBz584TY; Wed, 31 Jan 2024 18:53:18 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQB4s2bfNz4SvZ; Wed, 31 Jan 2024 18:53:17 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Eg9MN5iR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=marietto2008@gmail.com Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a36597a3104so5460866b.2; Wed, 31 Jan 2024 10:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706727195; x=1707331995; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s5hM4rhwevdxS0Ck8quXu0LRO2DJlbt4/acZMtTbmYk=; b=Eg9MN5iRaH8z2DINngDddaN0wbakW5FfiaZ0rb6O7WrChUnCA9OxRf8b1QGtf2Sxlt udi/VRgelBo0DtgVdGe+DSI72hW59Vl5d1quGL0PbAyf77UuV1wj4Vfk0GmP/WLpHidd 6HP8pO4FK1I/c2Asm3fBhVPQP33di2ItI5CrVdNhx/ogqc6qXw2mFBRuc+CEPqWt9bDy wPZGIE1NLRpybdxQFCFC8zEyQ7IDBYr2zaBEmbgZ6+CpoLX4HIKQe8YqA5ij9su0xTyT tGs5U/BuqaIQOD5i8nHziZhfGSj242H0eebiYNWBHAigIJELc8AdL7Zk2Ekek7Qi88mp 416A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706727195; x=1707331995; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s5hM4rhwevdxS0Ck8quXu0LRO2DJlbt4/acZMtTbmYk=; b=f461Vp99KVlSqe+3J7PDbhAD0150b1+ka36KSD9qsv2DSopHt/iVdKQ8PnYwzivhE/ EuEm9bwfofF0BrMR8BrQ+otVCD5SI+xddl6zAyodP29x2G+xQCRMdsBnzhOkeh/fne1t npfRi2+P7nEudvxuC8QoLaL/540brfWxFrZVBGZwk3vl+X7DOZzgMbLGp4Ghh32bykpL deheiwTtli4JNzRsQshS+efGiI1KACe3UhPs61EKU90UpgOrpgqygOQSZlxFTeU1DTCj UJYgT7obsmUQTzUz6UAnoIUrERAQC6M/enBnWZpGv0AFeQlp4N6U7nd27vHrgxEgrCzr Ymvw== X-Gm-Message-State: AOJu0YzbsR/qxtU+kOf3o3O4kgSxpJ4FbLJhjmCjsizJ0TT4zlDE+axF 0VWhSGCZM9UtZ0MD/p2B3DiumeD3XKzcpkGQOn3DFs2T3acmCxYXP50li7XZlNiGBt//4vEmI3z EYUkE3rywQlh5kJVdfipWr9HZ9Rk= X-Google-Smtp-Source: AGHT+IHZZn5zkOmanmtabVZq2VzNjToI+FzLT+Qxm5QMSugVMRCEGTlxhKbpx0o60rJPADdsDt7p3HjBJu/XBvgVerA= X-Received: by 2002:a17:906:4154:b0:a36:70ce:31ba with SMTP id l20-20020a170906415400b00a3670ce31bamr1605444ejk.5.1706727195267; Wed, 31 Jan 2024 10:53:15 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> <202401311216.40VCGZSo001051@donotpassgo.dyslexicfish.net> In-Reply-To: From: Mario Marietto Date: Wed, 31 Jan 2024 19:52:38 +0100 Message-ID: Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. To: Jamie Landeg-Jones Cc: wojtek@puchar.net, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000033d78606104264fd" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.22 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.22)[-0.222]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org,freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4TQB4s2bfNz4SvZ --00000000000033d78606104264fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jamie. Your script didn't work,but I get your idea and I've backed up the directory /mnt/da0p2/usr/ports/Mk/Scripts to /mnt/da0p2/usr/ports/Mk/Scripts-old ; then I have upgraded the ports tree with the commands : # portsnap fetch extract # portsnap fetch update At this point I have renamed the directory Scripts-old to Scripts and I tried to compile a port. This is what happened : Invoked as: ./configure --prefix=3D/usr/local Tclsh: /usr/ports/ports-mgmt/pkg/work/pkg-1.20.9/jimsh0 Failed: cc -O2 -pipe -Wno-error -fstack-protector-strong -fno-strict-aliasing -c conftest__.c -o conftest__.o cc: error: unknown argument: '-fstack-protector-strong' =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The failed code was: #include int main(void) { return 0; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Wed, Jan 31, 2024 at 3:45=E2=80=AFPM Mario Marietto wrote: > Can you tell me where should be stored the references to pipefail ? Maybe > I will try to remove them manually. Maybe your command does not work out = of > the box. > > On Wed, Jan 31, 2024 at 3:31=E2=80=AFPM Mario Marietto > wrote: > >> Jamie, >> >> I ran your script and it gave no error message,BUT I still got the error >> : >> >> root@marietto:/usr/ports/ports-mgmt/pkg # make >> set: illegal option -o pipefail.... >> >> ? >> >> On Wed, Jan 31, 2024 at 1:16=E2=80=AFPM Jamie Landeg-Jones >> wrote: >> >>> Mario Marietto wrote: >>> >>> > What I haven't understood is why you are talking about newer ports >>> when the >>> > only thing I do is to update ports using the same FreeBSD version,in >>> this >>> > case 10.4. I mean,upgrading ports without upgrading the version of >>> > FreeBSD,can't mean to use newer ports,since I don't use a newer >>> version of >>> > the OS. >>> >>> The ports infrastucture (under /usr/ports/Mk) now contains scripts that >>> set >>> the "pipefail" option - these scripts are updated when you update the >>> ports >>> tree. >>> >>> I had an old out-of-date box for a while, and used this quick hack to g= et >>> it to work. >>> >>> You need to run this after you update the ports tree: >>> >>> sed -i.bak '/^[[:space:]]*set [+-]o pipefail/d' /usr/ports/Mk/Scripts/* >>> >>> It removes the references to pipefail. This can mean that some build >>> errors >>> are potentially not trapped, but if that's the case you're likely to >>> notice >>> the failure anyway. >>> >>> Still best to update your system or your /bin/sh though! >>> >>> Cheers, Jamie >>> >> >> >> -- >> Mario. >> > > > -- > Mario. > --=20 Mario. --00000000000033d78606104264fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jamie. Your script didn't work,but I get your ide= a and I've backed up the directory /mnt/da0p2/usr/ports/Mk/Scripts to /= mnt/da0p2/usr/ports/Mk/Scripts-old ; then I have upgraded the ports tree wi= th the commands :

# = portsnap fetch extract
# portsnap fetch update
=

At this point = I have renamed the directory Scripts-old to Scripts and I tried to compile = a port. This is what happened :

Invoked as: ./conf= igure --prefix=3D/usr/local
Tclsh: /usr/ports/ports-mgmt/pkg/work/pkg-1.= 20.9/jimsh0
Failed: cc -O2 -pipe -Wno-error -fstack-protector-strong -fn= o-strict-aliasing -c conftest__.c -o conftest__.o
cc: error: unknown arg= ument: '-fstack-protector-strong'
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
The failed code was:
#include <stdlib.h>
int main(voi= d) {

return 0;
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Jan 31, 2024 at 3:45=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
=
Can you = tell me where should be stored the references to pipefail ? Maybe I will tr= y to remove them manually. Maybe your command does not work out of the box.=

On Wed, Jan 31, 2024 at 3:31=E2=80=AFPM Mario Marietto <marietto2008@gmail.com= > wrote:
Jamie,

I ran your script and it = gave no error message,BUT I still got the error :=C2=A0

root@marietto:/usr/ports/ports-mgmt/pkg # make
set: ill= egal option -o pipefail....

?

<= div class=3D"gmail_quote">
On Wed, Jan= 31, 2024 at 1:16=E2=80=AFPM Jamie Landeg-Jones <jamie@catflap.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Mario Marietto <marietto2008@gmail.com= > wrote:

> What I haven't understood is why you are talking about newer ports= when the
> only thing I do is to update ports using the same FreeBSD version,in t= his
> case 10.4. I mean,upgrading ports without upgrading the version of
> FreeBSD,can't mean to use newer ports,since I don't use a newe= r version of
> the OS.

The ports infrastucture (under /usr/ports/Mk) now contains scripts that set=
the "pipefail" option - these scripts are updated when you update= the ports
tree.

I had an old out-of-date box for a while, and used this quick hack to get it to work.

You need to run this after you update the ports tree:

sed -i.bak '/^[[:space:]]*set [+-]o pipefail/d' /usr/ports/Mk/Scrip= ts/*

It removes the references to pipefail. This can mean that some build errors=
are potentially not trapped, but if that's the case you're likely t= o notice
the failure anyway.

Still best to update your system or your /bin/sh though!

Cheers, Jamie


--
Mario.


--
Mario.


--
Mario.
--00000000000033d78606104264fd-- From nobody Wed Jan 31 21:23:45 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQFQg0rwDz58KBn for ; Wed, 31 Jan 2024 21:23:55 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4TQFQf5v7Sz4r7Q for ; Wed, 31 Jan 2024 21:23:54 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; none Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.17.1) with ESMTPS id 40VLNkaj081903 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Jan 2024 22:23:47 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1706736228; bh=uHQ9gESUNTGzHCRxzahs8nQOH8UwG8kX4zqWCdiqiWI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=M3ZO3k+vQ3LYlDU57svEH0YDb+z22GWt5cXFDvVA90o7gjSO7oSIG08zaf8D57NC0 rWf6oJhNcBZyOo4fAHoziL4XsZv/V8043nys6ryw2guRrVcUVrMvfvSjL+Y2B2o0Ez tXsH9cj9sVADpuzFlgtViwV07Nlyp+a+0zIs4sLg= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.17.1/8.16.1) with ESMTP id 40VLNku5030066; Wed, 31 Jan 2024 22:23:46 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.17.1/8.16.1/Submit) with ESMTP id 40VLNjwX030063; Wed, 31 Jan 2024 22:23:45 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 31 Jan 2024 22:23:45 +0100 (CET) From: Wojciech Puchar To: Borja Marcos cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers , Warner Losh , Scott Long , =?ISO-8859-2?Q?Goran_Meki=E6?= Subject: Re: The Case for Rust (in the base system) In-Reply-To: Message-ID: <3faef650-8cf9-13cd-f731-e84c6eff86ee@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3974694515-1020621650-1706736226=:30050" X-Rspamd-Queue-Id: 4TQFQf5v7Sz4r7Q X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL] This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3974694515-1020621650-1706736226=:30050 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT > While I think I agree with the arguments against including Rust, there are programming languages that make it > really hard to manage the possible interactions between components and hence expose you to security issues. > > C is the “rust golden” example. Complexity can become unbearable and it can be compared to programming in assembler. ;) > Common argument from people that cannot program. How nice i don't have to interact with such, as i switched completely to embedded programming (real embedded, not pseudoembedded like raspberry pi). But still - i will need for many years UNIX that make sense. As well as for providing services to support my and other works, communicate etc. --3974694515-1020621650-1706736226=:30050-- From nobody Wed Jan 31 21:31:46 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQFc35YfRz58Klm for ; Wed, 31 Jan 2024 21:32:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4TQFc33S1fz4sJn; Wed, 31 Jan 2024 21:32:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; none Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.17.1) with ESMTPS id 40VLVmd2083503 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Jan 2024 22:31:49 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1706736709; bh=CYYkVlSJKctI07liHTGBzGjD8tVi/DK0Byi3SIJJiP0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iwbdGblPEDOqomHXrnAS51pwee1MU60JaQVUT9aGdgakpfH0RyiTu5RpHio9IlpyG kMSvkpoCPkpPXmGdMLLKsxrq9vrTlEA0ocmmf7p7uEHwfiBCfiVrgi4sksDRcj/30e +xhffNayYg03TqhaDxzMPYgu06c8CHa80uuvLp6o= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.17.1/8.16.1) with ESMTP id 40VLVmtL030095; Wed, 31 Jan 2024 22:31:48 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.17.1/8.16.1/Submit) with ESMTP id 40VLVkcr030092; Wed, 31 Jan 2024 22:31:46 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 31 Jan 2024 22:31:46 +0100 (CET) From: Wojciech Puchar To: David Chisnall cc: Tomoaki AOKI , Antranig Vartanian , Alan Somers , FreeBSD Hackers , Warner Losh , Scott Long , =?ISO-8859-2?Q?Goran_Meki=E6?= Subject: Re: The Case for Rust (in the base system) In-Reply-To: <782FA00C-3B90-49C8-85F7-AF784F42A3CC@FreeBSD.org> Message-ID: <6af9739e-2be3-d0a8-bcb0-fd63196246e5@puchar.net> References: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp> <782FA00C-3B90-49C8-85F7-AF784F42A3CC@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4TQFc33S1fz4sJn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL] On Wed, 31 Jan 2024, David Chisnall wrote: > On 31 Jan 2024, at 15:07, Tomoaki AOKI wrote: >> >> First of all, NO MEMORY-SAFE language can write codes using volatile >> memory objects, most notably, memory-mapped I/O and/or DMA driver. > > The first half of that is obvious nonsense. Memory-mapped I/O is not intrinsically unsafe, from a memory-safety perspective. Even Java has volatile objects and Sun Labs used Java for device drivers twenty years ago. Having a memory-safe interface for MMIO is helpful. This line above is complete nonsense. as most of that discussion. Two things are certain: - democracy is last phase of civilisation fall. Happening today. Democracy, in case of FreeBSD will do the same for FreeBSD. Already happened year ago for linux and others. As there are more stupid people than clever. If it wins - Rust and other nonsenses will become quickly standard. What is certain - that there will be exactly opposite about security holes that their claims. There will be far more that it is today. - clever people don't need latest computers, so current FreeBSD can still be used. With possibly some development to meet current needs. So not really a problem. Mark Twain once said "no amount of arguments are sufficient for idiot". So this is my last post. Keep fighting. From nobody Wed Jan 31 22:44:49 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQHD94LCqz58SZ4 for ; Wed, 31 Jan 2024 22:44:57 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQHD86PKFz436Z for ; Wed, 31 Jan 2024 22:44:56 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (096-033-195-197.res.spectrum.com [96.33.195.197]) by colo1.denninger.net (Postfix) with ESMTP id CE55E2110B2 for ; Wed, 31 Jan 2024 17:45:16 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id B982737C2F6 for ; Wed, 31 Jan 2024 17:44:49 -0500 (EST) Message-ID: Date: Wed, 31 Jan 2024 17:44:49 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in the base system) Content-Language: en-US To: freebsd-hackers@freebsd.org References: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp> <782FA00C-3B90-49C8-85F7-AF784F42A3CC@FreeBSD.org> <6af9739e-2be3-d0a8-bcb0-fd63196246e5@puchar.net> From: Karl Denninger In-Reply-To: <6af9739e-2be3-d0a8-bcb0-fd63196246e5@puchar.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000907060606090808030305" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.67 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; NEURAL_SPAM_MEDIUM(0.20)[0.204]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FREEFALL_USER(0.00)[karl]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4TQHD86PKFz436Z This is a cryptographically signed message in MIME format. --------------ms000907060606090808030305 Content-Type: multipart/alternative; boundary="------------G78ozs15shRv04Umr5KvQjYb" --------------G78ozs15shRv04Umr5KvQjYb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/31/2024 16:31, Wojciech Puchar wrote: > > On Wed, 31 Jan 2024, David Chisnall wrote: > >> On 31 Jan 2024, at 15:07, Tomoaki AOKI >> wrote: >>> >>> First of all, NO MEMORY-SAFE language can write codes using volatile >>> memory objects, most notably, memory-mapped I/O and/or DMA driver. >> >> The first half of that is obvious nonsense.  Memory-mapped I/O is not >> intrinsically unsafe, from a memory-safety perspective. Even Java has >> volatile objects and Sun Labs used Java for device drivers twenty >> years ago.  Having a memory-safe interface for MMIO is helpful. > This line above is complete nonsense. as most of that discussion. > > ...... > I've read most of this thread thus far and have a few observations.  Mind you this is coming from a 60 year old who was programming in assembler before I had a driver's license and has run FreeBSD both personally and professionally all the way back to the mid 1990s when MCSNet ran on it both on our back end and in customer-facing use.  I'll try to keep this somewhat-brief as I'm not really interested in a catfight. Languages come and go in popularity.  Some concepts endure, but implementations often not-so-much.  Sometimes decisions made a long time ago wind up locking you up "almost forever"; witness Android as an example.  Sometimes much less-consequential decisions (e.g. to use something from packages) bites you; Digital Ocean, for example, no longer "supports" FreeBSD at all. They used to up to FreeBSD 11. Why no longer? Maybe (can't be proved) because they used "jq" to parse the cloud config files, that's a package, their cloud init script /forgot /to put the "REQUIRE" for "ldconfig" in there to make sure adding local libraries was run first /and thus on an upgrade to a newer version if rcorder spat things out differently it could try to run the cloud init before the linker knew where the shared libraries were and thus break all networking, appearing to be entirely dead. /It took me 30 seconds to find this and eight bytes of inserted text to fix it, I reported it back to DO but.... they haven't changed their mind on forward support.  Sad too because their infrastructure works really well with FreeBSD (in fact my blog has been on it for several years now and still is on 13.2p8) The idea of having a language at compile time cover for foolish mistakes or lack of attention sounds good but as we have all seen with various data breaches whenever you think you've made something idiot-proof Murphy comes up with a better idiot.  I'm not much of a fan of the premise that with more-rapid development of working code one also gets both correct and more-efficient code, and again I post up Android (which I do write app code for) as a counter-example. Bringing a language into base IMHO ought to be very carefully considered /as removing it might be impossible down the road and ultimately FreeBSD could pay horribly for that. /This is especially true when the language itself isn't simply a language; it also means that in practical use it has a huge number of other outside resources (e.g. containers or whatever) particularly when they're not static and might have compilation issues down the road.  I personally hate coding for Android (although I do it) because its essentially required to use their IDE to be productive at all and it changes out from under you whenever Google decides to deprecate or change something; do we really want to bring that sort of situation into FreeBSD?  In addition I've been bit several times by the "floating dependency" thing with with php over the years -- php itself is of course a package but there are /other /packages that use it as a language and a huge number of modules that are brought in to handle various things from xml parsing to database connectivity. Several times over the years I've upgraded php using "pkg upgrade" and immediately had one or more packages that allegedly should be forward-compatible break with missing dependencies that weren't originally there and thus "pkg" had no knowledge of them.  These are the risks you accept when using a "language + other things" model in all respects; it can happen with code linked against openssl, for example (e.g. Postgres was a recent one built from source that required a bit of effort to resolve as I build that in a production environment I'm responsible for from source.) I would argue that this risk in a core component should not be accepted without a showing of extraordinary benefit in the context of improvement of some element that the core system includes now, and even then only if the container problem can be resolved in a way that will not wind up screwing the ability to build -- including a retrospective release -- on an indefinite basis down the road.  That is, if you can't (for example) check out 14.x five years from now /and build it from source /then its not acceptable, which implies that whatever containerized assets are required they must also be in said tree and versioned in same without having to be pulled from an external source (which may have changed such that backward compatibility to build has been lost.)  This could get into more than just a technical question if there are potential licensing issues with those "must have to build" assets as well. My 2 bits of contribution; carry on. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------G78ozs15shRv04Umr5KvQjYb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/31/2024 16:31, Wojciech Puchar wrote:

On Wed, 31 Jan 2024, David Chisnall wrote:

On 31 Jan 2024, at 15:07, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

First of all, NO MEMORY-SAFE language can write codes using volatile
memory objects, most notably, memory-mapped I/O and/or DMA driver.

The first half of that is obvious nonsense.  Memory-mapped I/O is not intrinsically unsafe, from a memory-safety perspective.  Even Java has volatile objects and Sun Labs used Java for device drivers twenty years ago.  Having a memory-safe interface for MMIO is helpful.
This line above is complete nonsense. as most of that discussion.

......

I've read most of this thread thus far and have a few observations.  Mind you this is coming from a 60 year old who was programming in assembler before I had a driver's license and has run FreeBSD both personally and professionally all the way back to the mid 1990s when MCSNet ran on it both on our back end and in customer-facing use.  I'll try to keep this somewhat-brief as I'm not really interested in a catfight.

Languages come and go in popularity.  Some concepts endure, but implementations often not-so-much.  Sometimes decisions made a long time ago wind up locking you up "almost forever"; witness Android as an example.  Sometimes much less-consequential decisions (e.g. to use something from packages) bites you; Digital Ocean, for example, no longer "supports" FreeBSD at all. They used to up to FreeBSD 11. Why no longer? Maybe (can't be proved) because they used "jq" to parse the cloud config files, that's a package, their cloud init script forgot to put the "REQUIRE" for "ldconfig" in there to make sure adding local libraries was run first and thus on an upgrade to a newer version if rcorder spat things out differently it could try to run the cloud init before the linker knew where the shared libraries were and thus break all networking, appearing to be entirely dead.  It took me 30 seconds to find this and eight bytes of inserted text to fix it, I reported it back to DO but.... they haven't changed their mind on forward support.  Sad too because their infrastructure works really well with FreeBSD (in fact my blog has been on it for several years now and still is on 13.2p8)

The idea of having a language at compile time cover for foolish mistakes or lack of attention sounds good but as we have all seen with various data breaches whenever you think you've made something idiot-proof Murphy comes up with a better idiot.  I'm not much of a fan of the premise that with more-rapid development of working code one also gets both correct and more-efficient code, and again I post up Android (which I do write app code for) as a counter-example.

Bringing a language into base IMHO ought to be very carefully considered as removing it might be impossible down the road and ultimately FreeBSD could pay horribly for that.  This is especially true when the language itself isn't simply a language; it also means that in practical use it has a huge number of other outside resources (e.g. containers or whatever) particularly when they're not static and might have compilation issues down the road.  I personally hate coding for Android (although I do it) because its essentially required to use their IDE to be productive at all and it changes out from under you whenever Google decides to deprecate or change something; do we really want to bring that sort of situation into FreeBSD?  In addition I've been bit several times by the "floating dependency" thing with with php over the years -- php itself is of course a package but there are other packages that use it as a language and a huge number of modules that are brought in to handle various things from xml parsing to database connectivity.  Several times over the years I've upgraded php using "pkg upgrade" and immediately had one or more packages that allegedly should be forward-compatible break with missing dependencies that weren't originally there and thus "pkg" had no knowledge of them.  These are the risks you accept when using a "language + other things" model in all respects; it can happen with code linked against openssl, for example (e.g. Postgres was a recent one built from source that required a bit of effort to resolve as I build that in a production environment I'm responsible for from source.)

I would argue that this risk in a core component should not be accepted without a showing of extraordinary benefit in the context of improvement of some element that the core system includes now, and even then only if the container problem can be resolved in a way that will not wind up screwing the ability to build -- including a retrospective release -- on an indefinite basis down the road.  That is, if you can't (for example) check out 14.x five years from now and build it from source then its not acceptable, which implies that whatever containerized assets are required they must also be in said tree and versioned in same without having to be pulled from an external source (which may have changed such that backward compatibility to build has been lost.)  This could get into more than just a technical question if there are potential licensing issues with those "must have to build" assets as well.

My 2 bits of contribution; carry on.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------G78ozs15shRv04Umr5KvQjYb-- --------------ms000907060606090808030305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yNDAxMzEyMjQ0NDlaME8GCSqGSIb3DQEJBDFCBEBZ/ZFFFG+FCGL/nM9w XxJCg2fsoRK6bDUpF3tQG9qqM+q1AWjAXWw7HvO9WzebRdExzdtWAns+qWQwgFO2YqjNMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgBAdapxvD2fZ2BhDw1EakjUWY0k/nVRmw0lp5cb ouRW41EgFnQVvL0ihXGlnYQG5mEamh6KvqbbZ3HiIp/xoWIemRtAufNDN9lseaqbJwBZtbXM lKGvnfG5Zi/gvzFkVnCQaM6cifZceugczcdCZGlvfJW1/af+uqSTeitlATUTh7wztN2SHFFT 5u50Xhaj6RV6dha6a/kfulfkUl5T1K4h8Jq4r21t7eIcX+BeJneH7wFCIyAsvse+6z3WnnRe JB9+foNdTBPpt2CuM4ffzq22EyJBWf1hoyVO+1MuAh0AyKnPW7Rhn6jcxeWfqEAItjmtQsr5 23KjvEUKiV/zQt7lLNY1lqravSikfgQxptTqEbvAo9wQ5QCs2SHBqFxXIEMGwHRB/IueofiT TlVWlrCV9fhxcknH5M8ax9SZEKtGKYQ5yIw35pY8PTxapiiydom+4jcmDMo85X7Y7SBKhDFy UqDtWr2YUfx2k5rvu250U4o1XBhk+GHW4K0ASACfsqurwF4ZNnamKuap7+On3EimVu7Tupli u9vmAKQwZXts4FDer7hoCpylp/xWWivYmXJ5BpZlMEygvG3PF8YEWpBLxOSkSaWiAp3sV/wX gM84cB77acHvB6uzjze3bMdveuQWCpIJqxt59hfQQ8UtmhoiHCN6j6qPjRvgMGC+icvzpgAA AAAAAA== --------------ms000907060606090808030305-- From nobody Thu Feb 1 04:12:39 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQQWl5w4hz58yXR for ; Thu, 1 Feb 2024 04:13:55 +0000 (UTC) (envelope-from lain@fair.moe) Received: from mail.076.ne.jp (mail.076.ne.jp [45.76.218.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQQWj4B1Kz4kGk for ; Thu, 1 Feb 2024 04:13:52 +0000 (UTC) (envelope-from lain@fair.moe) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=076.ne.jp header.s=dkim header.b=T+CcCCJx; dmarc=none; spf=none (mx1.freebsd.org: domain of lain@fair.moe has no SPF policy when checking 45.76.218.69) smtp.mailfrom=lain@fair.moe Received: from mail.076.ne.jp (localhost [127.0.0.1]) by mail.076.ne.jp (Postfix) with ESMTP id 4TQQWX6FBkzW3TD for ; Thu, 1 Feb 2024 13:13:44 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=076.ne.jp; h= user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:to:from:date; s= dkim; t=1706760823; x=1709352824; bh=cQNgVpU9fLdtuZ/uIeCzQn3bm+t 5/n1Ht9CdVEkl1UM=; b=T+CcCCJxpaB7E0hLKjdPQl0KEJ9A/Y/rKSqLLVFyQEx tZfGBzNUY4X5WUAxUUv58CP0+KWPaLrNqVzx5Sto3dKEPIdcyoPxVzEXe1gkM+5R OQRFT8uxLxRcGAfOoVQveNqmvBsXetXH1QaOQns35O9Ck7MZ3aJjKI3aYXIuOY9i 8AI6RTs1TNAEgkLCe9iupepQC5ubQhLW1CXTDci6bTuAIIalcHAwIbUt14M+3uzF gdpksVpZIFf5Jt1Lun83PdLs0J6RxCFMjKN3oNm/2d8mKQ/CE2GZ6/ji5JPZ/lux gD+iLd9Ms6zqZWquBHojS4xLzXoF55nu4TZBaQb3VLA== X-Virus-Scanned: Debian amavisd-new at guest.guest Received: from mail.076.ne.jp ([127.0.0.1]) by mail.076.ne.jp (mail.076.ne.jp [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6fItamFz6oDl for ; Thu, 1 Feb 2024 13:13:43 +0900 (JST) Received: from mail.fair.moe (ip1.193.076.moe [219.117.254.193]) by mail.076.ne.jp (Postfix) with ESMTPSA id 4TQQWW3lSgzW0qn for ; Thu, 1 Feb 2024 13:13:43 +0900 (JST) Date: Thu, 1 Feb 2024 13:12:39 +0900 From: "lain." To: freebsd-hackers@freebsd.org Subject: Re: Re: The Case for Rust (in the base system) Message-ID: X-Location: =?utf-8?B?IkVhcnRoL+WcsOeQgyI=?= X-Operating-System: "GNU/Linux" References: <567c6bf7-1ccf-dde6-3792-ed4419fce3c8@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vjx4matrqenxz4bv" Content-Disposition: inline In-Reply-To: <567c6bf7-1ccf-dde6-3792-ed4419fce3c8@puchar.net> User-Agent: NeoMutt/20231221 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[076.ne.jp:s=dkim]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[fair.moe]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:20473, ipnet:45.76.192.0/19, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[076.ne.jp:+] X-Rspamd-Queue-Id: 4TQQWj4B1Kz4kGk --vjx4matrqenxz4bv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024=E5=B9=B401=E6=9C=8831=E6=97=A5 11:17, the silly Wojciech Puchar cla= imed to have said: > It's just another hype trying to solve problem of bad programmers. Proper > programmer with proper use of brain cannot be replaced by machine. And the irony is, it "solves" problems of bad programmers by enforcing bad programmer behavior, while only preventing mistakes in areas they previously didn't care about. It's clear to me that most of the Rust developers at one point were Javascript developers, because while they went from extremely high end with no mercy to somebody else's hardware at all to near low end where the compiler forces them to treat hardware with at least some respect, they still tend to pull 3rd party packages for every little thing they want to implement, making Cargo no different from NPM. One would argue that "you can't accomplish everything with the standard libraries alone", yet Go doesn't have this problem, and all it did was provide a complete standard library. On the other hand, PHP's standard library (if you can call it like that) is even more complete, but most people there import Composer packages for almost everything as well. So I don't think that putting the blame on standard libraries is really valid, but rather on both skill issues and lack of productivity. Like Jonathan Blow said, "it's not like why not caring about performance, they've become more productive in other dimensions, no, they just have bad performance, and they still can't get anything done". --=20 lain. Did you know that? 90% of all emails sent on a daily basis are being sent in plain text, and i= t's super easy to intercept emails as they flow over the internet? Never send passwords, tokens, personal information, or other volunerable in= formation without proper PGP encryption! If you're writing your emails unencrypted, please consider sending PGP encr= ypted emails for security reasons. You can find my PGP public key at: https://fair.moe/lain.asc Every good email client is able to send encrypted emails. If yours can't, then you should consider switching to a secure email client= , because yours just sucks. My recommendations are Claws Mail or NeoMutt. For instructions on how to encrypt your emails: https://unixsheikh.com/tutorials/gnupg-tutorial.html --vjx4matrqenxz4bv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEozVhUpXECiNYIKIXtWNzC1Y29b0FAmW7GjEACgkQtWNzC1Y2 9b1KjQv8CCTt0482LqVGqFQ4dlUyl6DDh+w2Rhn26/n2/V9+EAOaMO8IwRfRBdU5 fHpgQypAb99Mwgap/ME17/Q1F8T+9nHThs62Fay65Ob9S7HoMgRs0cEPDtfOEnX6 s8Z3O5Zm+IOIGHk4ElorsEWRb7lAPIAUEIhV53CP2v/nfEiXgGZtrkXLpjNGIQUk 8bIravlO5u6C33Bj/LMcn6Gs4SZ+IOzzVtpikXTAGmTQ5QRW4PdKckwWBjIQM6PT KfqaJyZssGGwrwFlizhZaDeI3uszqGskHsT7IjSHB3Iu5s5+2pBmtzpEK83RgrQW he/8zL2Fcbo7bzwEFaU4iVviFdSuWM61HfZ2D9IM3luCPRvyZnuyw2hPxehdvsf7 quLi7OvXDpvCM8LRrlaybmMmpQ8LvkgKeRTWxKCNoJSmtNOX6ZWCQNTP10h9r+ai 429lz61ZGetNORnEKNhowkMWS2G7AwoHqmI76ajJPll66tZUFkS3iAqq6bE4LQKR RRBeLfyP =gb35 -----END PGP SIGNATURE----- --vjx4matrqenxz4bv-- From nobody Thu Feb 1 04:14:48 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQQZ36m2vz58yyp for ; Thu, 1 Feb 2024 04:15:55 +0000 (UTC) (envelope-from lain@fair.moe) Received: from mail.076.ne.jp (mail.076.ne.jp [45.76.218.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQQZ30tR8z4lsL for ; Thu, 1 Feb 2024 04:15:55 +0000 (UTC) (envelope-from lain@fair.moe) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=076.ne.jp header.s=dkim header.b=G3+DUaUh; dmarc=none; spf=none (mx1.freebsd.org: domain of lain@fair.moe has no SPF policy when checking 45.76.218.69) smtp.mailfrom=lain@fair.moe Received: from mail.076.ne.jp (localhost [127.0.0.1]) by mail.076.ne.jp (Postfix) with ESMTP id 4TQQZ11mjzzW3TD for ; Thu, 1 Feb 2024 13:15:53 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=076.ne.jp; h= user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:to:from:date; s= dkim; t=1706760952; x=1709352953; bh=LeKQ0/mYBpp5sSqK5R52ieKbd4M KD3f1cteiDM2k6LQ=; b=G3+DUaUhRqg+vzTxTswzx13rS/Ai9oJF45oVOcm9LwZ ya94l4YlziMmLTEp+SKE2sXLfiZ8RbBgs7Xzkr+YmN+RJ8pW7XJmTnrVY+26IuR0 /ufv15y+HGTIJG15wUSwNgyoFMcSmoUC/HU4TEeOUG9an2oXySY+7mwhPBGJHRZE 61/Vzy8IckBKyBM1QbRJ+LDXEbHhTBRlKpRn9i6HMH7FxBpIGd6U/3aszDqwX6tQ 6I/qDl0Pz3TbQb0F49wa3C80LZ5JWXX4aGBK7suapN8V43H3GYz/X45F5qx5bD+n b1vEvOO1wBX0OH2L7QvUcED825vgGIpTeOn55QQXzXg== X-Virus-Scanned: Debian amavisd-new at guest.guest Received: from mail.076.ne.jp ([127.0.0.1]) by mail.076.ne.jp (mail.076.ne.jp [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NcbWnfV2YQ1L for ; Thu, 1 Feb 2024 13:15:52 +0900 (JST) Received: from mail.fair.moe (ip1.193.076.moe [219.117.254.193]) by mail.076.ne.jp (Postfix) with ESMTPSA id 4TQQZ04h17zW0qn for ; Thu, 1 Feb 2024 13:15:52 +0900 (JST) Date: Thu, 1 Feb 2024 13:14:48 +0900 From: "lain." To: freebsd-hackers@freebsd.org Subject: Re: Re: The Case for Rust (in the base system) Message-ID: X-Location: =?utf-8?B?IkVhcnRoL+WcsOeQgyI=?= X-Operating-System: "GNU/Linux" References: <515f384-6334-3e5c-f9e-40f469ca5e@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4agtlfdruu7kmkon" Content-Disposition: inline In-Reply-To: <515f384-6334-3e5c-f9e-40f469ca5e@puchar.net> User-Agent: NeoMutt/20231221 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[076.ne.jp:s=dkim]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:20473, ipnet:45.76.192.0/19, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[fair.moe]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[076.ne.jp:+] X-Rspamd-Queue-Id: 4TQQZ30tR8z4lsL --4agtlfdruu7kmkon Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024=E5=B9=B401=E6=9C=8831=E6=97=A5 11:09, the silly Wojciech Puchar cla= imed to have said: > is FreeBSD unix system or religion? > if it have to evolve to religion PLEASE provide usable unix system, maybe > under other project. > I do need normal unix system. FreeBSD is the only remaining useful. Did you just say OpenBSD? --=20 lain. Did you know that? 90% of all emails sent on a daily basis are being sent in plain text, and i= t's super easy to intercept emails as they flow over the internet? Never send passwords, tokens, personal information, or other volunerable in= formation without proper PGP encryption! If you're writing your emails unencrypted, please consider sending PGP encr= ypted emails for security reasons. You can find my PGP public key at: https://fair.moe/lain.asc Every good email client is able to send encrypted emails. If yours can't, then you should consider switching to a secure email client= , because yours just sucks. My recommendations are Claws Mail or NeoMutt. For instructions on how to encrypt your emails: https://unixsheikh.com/tutorials/gnupg-tutorial.html --4agtlfdruu7kmkon Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEozVhUpXECiNYIKIXtWNzC1Y29b0FAmW7GrcACgkQtWNzC1Y2 9b1Y1wv/f6TAGUiZuhT4N1q/CiRzjtsQCAuz136LKN6D9Vvutt2k6wTxotjOAqtF 7FK1b+14r94GhqITDbLstRNh6dfJWrhvGYNlJcuAzPGJiURzB9gihYQMpJVn3iwV Qc3tE5bkzbQ5fQRg5EGx09Sc/sUpTQGcvFv360oJ8hvojq5KKmQd1VUfouNkdMvw AmOaV/S0UkSlZNhEStuqgMUydwQ6ll29pVSbh4opnWOQwd9mlq+pe3qt1dxsEG0e 8+T9zRCp/gWQW/EG2NmJ8ni5N/oiIG68OjmBNTbCl+LUFhMWVj/DFhxazRkjeGQF g/HvMbxzdMhJlWE0jG90Pd30G9mChbXZJGqq5tNzQOKmaxIskQD5Af25r/AvC2q3 0AWkYMes1GCBOv06MmBWRQ6Bm6gI0TzLC+ez6n2zLGptLblAQYFePP+yYVkbzcEY 1ucQtiCqnx7y0DyY6mlmlZbmEOi6fGNW0hbUx1W6xJVrhgT04PqbNuX7i5DuhLw5 htrCmU4M =cixh -----END PGP SIGNATURE----- --4agtlfdruu7kmkon-- From nobody Thu Feb 1 11:41:52 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQcSl38qcz58T0c; Thu, 1 Feb 2024 11:41:59 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4TQcSl0ZXCz4Fcl; Thu, 1 Feb 2024 11:41:58 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 411Bfqar057811; Thu, 1 Feb 2024 11:41:52 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 411Bfq9W057810; Thu, 1 Feb 2024 11:41:52 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202402011141.411Bfq9W057810@donotpassgo.dyslexicfish.net> Date: Thu, 01 Feb 2024 11:41:52 +0000 Organization: Dyslexic Fish To: marietto2008@gmail.com, jamie@catflap.org Cc: wojtek@puchar.net, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. References: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> <202401311216.40VCGZSo001051@donotpassgo.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Thu, 01 Feb 2024 11:41:52 +0000 (GMT) X-Rspamd-Queue-Id: 4TQcSl0ZXCz4Fcl X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US] Mario Marietto wrote: > Can you tell me where should be stored the references to pipefail ? Maybe I > will try to remove them manually. Maybe your command does not work out of > the box. I juat tested it on an old 11.1 box and it worked. The various files are the ones listed in the command, under /usr/ports/Mk/Scripts - there are about 22 that contain mentions of pipefail, though not all will be relevent to your particilar cases. Yes, you can manually just delete the "set +o pipefail" and "set -o pipefail" commands as you find them, not forgetting the caveat mentioned in the previous mail that you may miss some errors that may occur during building. From nobody Thu Feb 1 12:07:49 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQd3K1pNZz58W9b; Thu, 1 Feb 2024 12:08:29 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQd3J74Qrz4KdV; Thu, 1 Feb 2024 12:08:28 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a29c4bbb2f4so93984666b.1; Thu, 01 Feb 2024 04:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706789307; x=1707394107; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QCeb6GvWnqzD7N77n8QHgYwhIoz8TiUmAwTeizfWkmA=; b=OEnamUYPpfMnP4viwgvgN6T3l3/ArGccWo3hEOLU/gi/8ufeT7UMznM9DQjCIllV+A fTsmgfMKOk2SIIWhmttyQiAhPgk0V89UykCntOpqKP7+pi2FRYgV66Y08fwWkxWuIAdZ ykIbfgxix5VK/uwYBx0+4msMFMGzJGZ685euL0Kh6uUOEEqDgDh85f2Rkedmh12kIO+R m3DChwmTWWzLJbhtj9Xn6+hgigwAeRuo2hKPDhloC1a5E21jpxRlv2vXxQxBrWGYmjsC yt01U+zdbZJ5hUm99++PKqr1oZwlp+eLOJVSlO3uKKs5drnKClu+UYyTyP29Oc6mDfYI ufpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706789307; x=1707394107; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QCeb6GvWnqzD7N77n8QHgYwhIoz8TiUmAwTeizfWkmA=; b=tSAf1uKek+x4+cP+A+7YzquVc0f22vzGZeKLFzzGqtfzH3nFiMdf4ZDZ7hxbWhzmVP uXw0k4IxbdQYV8zpBxAOJXe/oJwpfIaaT1hrjFY4k7Cqq7cYfP90xwNU0pHWN4ggcmfT n+YfIa/d9C9bu0lPmxCGuZA6cZVmU3FHVvJBGmM4FJmjXLTnQ2UNlOiq1KclP+Cs8b/r SewvLDQdVIy4MWsArY6wtrxNhK6sk8Kukx4lpeNMjjQkGAiYRfQZN1LucF9rzu5FnlMu D1sLyMIi+rGRVmcYpKNCjsrIrK4oua2tix2ezOdEaRoXjMCU6dm0RQ6FUFVa3vkQzPQD VnHg== X-Gm-Message-State: AOJu0YwK5R/iFNV+qK3UXEJVdM8PjxStj5c0MUyYAOIutPJkqe/sXVtu 8N+IBE3sKydZVyLjCdGbfno6pIMoZYEdqBwCPkyMdoPXWJyq1pAlQarTdJyaQczC/WX00cMkeKJ PX8cEjAD/srWuu38R1VdmN4jqEXueVGHY X-Google-Smtp-Source: AGHT+IGMetaR9cu9qWIZj5VPBHupg5T7VFeLpwzCBZjnUZaGBVkcyhhjSnzCZFTV7BaHp1V9CjhTfYCQlFDqorvNCew= X-Received: by 2002:a17:906:c457:b0:a36:71c1:468c with SMTP id ck23-20020a170906c45700b00a3671c1468cmr3192547ejb.62.1706789306523; Thu, 01 Feb 2024 04:08:26 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> <202401311216.40VCGZSo001051@donotpassgo.dyslexicfish.net> <202402011141.411Bfq9W057810@donotpassgo.dyslexicfish.net> In-Reply-To: <202402011141.411Bfq9W057810@donotpassgo.dyslexicfish.net> From: Mario Marietto Date: Thu, 1 Feb 2024 13:07:49 +0100 Message-ID: Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. To: Jamie Landeg-Jones Cc: wojtek@puchar.net, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000526765061050daf8" X-Rspamd-Queue-Id: 4TQd3J74Qrz4KdV X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000526765061050daf8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jamie, thanks. I don't know if you read my last email,but I have cut the problem at the root,by using the old version of the Mk Scripts,to be sure that it didn't have the pipefail parameter. I did like this because your script probably didn't remove some of those references and I got the same error. Unfortunately,when I tried to upgrade the port "pkg" to 1.20.9 I got a compilation error. I'm not able to upgrade the whole system until I'm not able to upgrade it. The error that I need to fix is : Invoked as: ./configure --prefix=3D/usr/local Tclsh: /usr/ports/ports-mgmt/pkg/work/pkg-1.20.9/jimsh0 Failed: cc -O2 -pipe -Wno-error -fstack-protector-strong -fno-strict-aliasing -c conftest__.c -o conftest__.o cc: error: unknown argument: '-fstack-protector-strong' =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The failed code was: #include int main(void) { return 0; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Feb 1, 2024 at 12:42=E2=80=AFPM Jamie Landeg-Jones wrote: > Mario Marietto wrote: > > > Can you tell me where should be stored the references to pipefail ? > Maybe I > > will try to remove them manually. Maybe your command does not work out = of > > the box. > > I juat tested it on an old 11.1 box and it worked. The various files are > the > ones listed in the command, under /usr/ports/Mk/Scripts - there are about > 22 > that contain mentions of pipefail, though not all will be relevent to you= r > particilar cases. > > Yes, you can manually just delete the "set +o pipefail" and "set -o > pipefail" > commands as you find them, not forgetting the caveat mentioned in the > previous mail that you may miss some errors that may occur during buildin= g. > --=20 Mario. --000000000000526765061050daf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello=C2=A0Jamie,

thanks. I = don't know if you read my last email,but I have cut the problem at the = root,by using the old version of the Mk Scripts,to be sure that it didn'= ;t have the pipefail parameter. I did like this because your script probabl= y didn't remove some of those references and I got the same error. Unfo= rtunately,when I tried to upgrade the port "pkg" to 1.20.9 I got = a compilation error. I'm not able to upgrade the whole system until I&#= 39;m not able to upgrade it. The error that I need to fix is :
Invoked as: ./configure --prefix=3D/usr/local
Tclsh: /usr/p= orts/ports-mgmt/pkg/work/pkg-1.20.9/jimsh0
Failed: cc -O2 -pipe -Wno-err= or -fstack-protector-strong -fno-strict-aliasing -c conftest__.c -o conftes= t__.o
cc: error: unknown argument: '-fstack-protector-strong'=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The failed code was:
#include &= lt;stdlib.h>
int main(void) {

return 0;
}
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Feb 1, 2024 at 12:42=E2=80=AFPM Jamie= Landeg-Jones <ja= mie@catflap.org> wrote:
Mario Marietto <marietto2008@gmail.com> wrote:

> Can you tell me where should be stored the references to pipefail ? Ma= ybe I
> will try to remove them manually. Maybe your command does not work out= of
> the box.

I juat tested it on an old 11.1 box and it worked. The various files are th= e
ones listed in the command, under /usr/ports/Mk/Scripts - there are about 2= 2
that contain mentions of pipefail, though not all will be relevent to your<= br> particilar cases.

Yes, you can manually just delete the "set +o pipefail" and "= ;set -o pipefail"
commands as you find them, not forgetting the caveat mentioned in the
previous mail that you may miss some errors that may occur during building.=


--
Mario.
--000000000000526765061050daf8-- From nobody Thu Feb 1 12:13:58 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQd9g41byz58WjS; Thu, 1 Feb 2024 12:13:59 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4TQd9g2c9bz4N8T; Thu, 1 Feb 2024 12:13:59 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 411CDwIq064567; Thu, 1 Feb 2024 12:13:58 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 411CDwKw064566; Thu, 1 Feb 2024 12:13:58 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202402011213.411CDwKw064566@donotpassgo.dyslexicfish.net> Date: Thu, 01 Feb 2024 12:13:58 +0000 Organization: Dyslexic Fish To: marietto2008@gmail.com, jamie@catflap.org Cc: wojtek@puchar.net, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: set : illegal option -o pipefail error while trying to upgrade pkg. References: <80d527f-df83-5657-6a2a-262156e08440@puchar.net> <202401311216.40VCGZSo001051@donotpassgo.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Thu, 01 Feb 2024 12:13:59 +0000 (GMT) X-Rspamd-Queue-Id: 4TQd9g2c9bz4N8T X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US] Mario Marietto wrote: > Jamie. Your script didn't work,but I get your idea and I've backed up the > directory /mnt/da0p2/usr/ports/Mk/Scripts to > /mnt/da0p2/usr/ports/Mk/Scripts-old ; then I have upgraded the ports tree > with the commands : > > # portsnap fetch extract > # portsnap fetch update > > At this point I have renamed the directory Scripts-old to Scripts and I > tried to compile a port. This is what happened : > > Invoked as: ./configure --prefix=/usr/local > Tclsh: /usr/ports/ports-mgmt/pkg/work/pkg-1.20.9/jimsh0 > Failed: cc -O2 -pipe -Wno-error -fstack-protector-strong > -fno-strict-aliasing -c conftest__.c -o conftest__.o > cc: error: unknown argument: '-fstack-protector-strong' > ============ > The failed code was: > #include > int main(void) { > > return 0; > } > ============ Ah ok, so you've got around the pipefail issue. This is a different issue. stack-protection got added to the clang compiler long after the freebsd version you are using. I think you can disable this by adding SSP_CFLAGS="" to your make command line, e.g. make SSP_CFLAGS="" But then, you're likely to get build errors due to the old version of "make" on that system, so unless you know how to remove the problem in the makefile, you'll need a more recent version of "make" too... From nobody Thu Feb 1 13:04:34 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQfJK4jXwz58cDj for ; Thu, 1 Feb 2024 13:04:49 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4TQfJK1VPkz4TLn for ; Thu, 1 Feb 2024 13:04:48 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; none Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.17.1) with ESMTPS id 411D4Yjg007457 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Feb 2024 14:04:35 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1706792675; bh=qEpZigX3YthElLfV5AU5WapijE8qHVcIeO4kURqBMqU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=vGLVHoTRi8i2xw3E3XtxbsaHqdZZhscQjFPpl2pQv6RcV/UVO8E5TH692h0XaCoPP VGc0bNAVk0DH0s2CD+LxcPdWSNHn6it0meVbJNriEdJmkNVEfdNgNVaiBEKWGHPf+Q ozIVuWb61DRtmUpT0FxYEctcg/8R6UTYYLcjeEq8= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.17.1/8.16.1) with ESMTP id 411D4YpI034241; Thu, 1 Feb 2024 14:04:34 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.17.1/8.16.1/Submit) with ESMTP id 411D4Y0M034238; Thu, 1 Feb 2024 14:04:34 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Thu, 1 Feb 2024 14:04:34 +0100 (CET) From: Wojciech Puchar To: "lain." cc: freebsd-hackers@freebsd.org Subject: Re: Re: The Case for Rust (in the base system) In-Reply-To: Message-ID: <67aa7fc0-914a-3e9e-8e7d-89e3b16ab713@puchar.net> References: <567c6bf7-1ccf-dde6-3792-ed4419fce3c8@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4TQfJK1VPkz4TLn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL] your talking, as well as my talking is useless. It doesn't help because large corporations have big resources to make anything useful a trash, so everything be the same nonsense like their products. And people are every year more and more retarded. So they succeed. Microsoft is FreeBSD sponsor. It tells all. If FreeBSD will have to be more secure, or improved in real way the discussion would turn to "How to simplify that software". That's all From nobody Thu Feb 1 13:15:41 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQfY6535Pz58d8t for ; Thu, 1 Feb 2024 13:15:54 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQfY64XnSz4Xnm; Thu, 1 Feb 2024 13:15:54 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706793354; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=euKF0uWT2D7N7ARxWpW6C5foMytt+cfkDSL22VCrJww=; b=FEWrw+MR4QX82+X5Ku29h1YQGAQSaPYbUJe4l+eQ6cM5BrYiCvKwDv50PUb+sh15qdl7vI IrJNO/kI0ZLFw9HKl/lwJUjfZu8EYNFiczZtzTmWFVHLlnDezoWhK0K7UsPUPPYsLBGwcv tKU4x2UNlA3r/QdTUDHzV9cRr7g2a5DyThDxeuERmvYD2WqkItFscI+KjDQdFTM/OSVT0E end2rxy2Fxrs1v4FnXsOejBMQ4/8yIVko7nmTdCjOEdBy2sXHnW70bzq1RmGFcK6J7FM8u JLSgJcTgDdWYyM8U6pv5txwcG0CMmmOq4SpJoYPfbTjs/YgjUXd/FRxxEb0xSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706793354; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=euKF0uWT2D7N7ARxWpW6C5foMytt+cfkDSL22VCrJww=; b=LX0y8w8zAqdSGsR2WPTTp9dZ2TKl9YiP9AHiiN0HQrbK+CBftZfQhGAgteIbfV3wjwH8j/ mx+W+FQYv6SBW1GfWEXaxp0kjnUrb7zLpNbSx8FdQQN0N80iodahzx7RwPU2x0/6+HTHcg P5LEnOQEpoB2Pff0MJo3Na2a+20y9lsPQRYL9QBDS204VntX2H4VYGdpfDG4q/AdCKtW7G OFQsblA5O/LpCR79MHP7VTrYW3uG4F5a1QQcLVYt4GUScZm/30jM0bRq5+0eRNEpV/qkx6 g9pDVUkTbfFF42RE165+NGmJL086EFMUt+YV0AZB2QT1gW+4N2Deh8rfVEEumw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706793354; a=rsa-sha256; cv=none; b=Leq+r6z+al6pbW/Xp5GOHyyA0qdNenlk79wJyOsOfkBy8pU/Yum0O7Yqhegw/yXoZfEqK/ cYuKwcoO7SkF2yEyUNVLgZodJClyR8gQN5HvjIbqh/YJkGmf3gYTsLtDnbEFEa2Php7QKY ynKMelkOj001mhZ0+p9sT4Uaqa1sf4AxGGAKO2OguUGDNBpX30+gF1XMIYfHwSm5fqdaFh /f/bxCM8HGS2q9AAzeoKHbcNwKfek56zTbcjWWAb3DRwVhc/6judBum4dUJeCbbP45x+U/ 52DYRBwoc7A/L9q5s81l45YKYpz7GmXNm9/lco3QdrEWmJiw5oCwcb5CkoEPQw== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TQfY63RJ8z1Lfd; Thu, 1 Feb 2024 13:15:54 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-153-95-118.range109-153.btcentralplus.com [109.153.95.118]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 32B11101E9; Thu, 1 Feb 2024 13:15:53 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: The Case for Rust (in the base system) From: David Chisnall In-Reply-To: <67aa7fc0-914a-3e9e-8e7d-89e3b16ab713@puchar.net> Date: Thu, 1 Feb 2024 13:15:41 +0000 Cc: "lain." , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6EF19C86-6FEF-4BC5-93A2-1A6584408C64@FreeBSD.org> References: <567c6bf7-1ccf-dde6-3792-ed4419fce3c8@puchar.net> <67aa7fc0-914a-3e9e-8e7d-89e3b16ab713@puchar.net> To: Wojciech Puchar X-Mailer: Apple Mail (2.3774.200.91.1.1) On 1 Feb 2024, at 13:04, Wojciech Puchar wrote: >=20 > my talking is useless I completely agree. When your talking is entirely personal attacks and = vague claims with no evidence or data to support them, it is entirely = useless. If you wish to engage with the topic politely, on the basis of the = technical merits of the topics under discussion, then your contributions = could be valuable. If you=E2=80=99re just going to complain that any = use of post-1980 tooling is a plot by corporations to enable incompetent = programmers to contribute to FreeBSD then you would help everyone by = just reading the thread and not posting. I=E2=80=99ve not quoted the rest of your post because that kind of = message has absolutely no place in this project. David From nobody Thu Feb 1 14:47:44 2024 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQhbc3zlPz58mwv for ; Thu, 1 Feb 2024 14:48:12 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQhbb4dHDz4kJp for ; Thu, 1 Feb 2024 14:48:11 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tdx.co.uk header.s=krpdkim header.b=MZqIlx8a; dmarc=pass (policy=none) header.from=tdx.co.uk; spf=pass (mx1.freebsd.org: domain of kpielorz_lst@tdx.co.uk designates 62.13.128.145 as permitted sender) smtp.mailfrom=kpielorz_lst@tdx.co.uk Received: from [10.12.30.106] by smtp.krpservers.com (8.16.1/8.15.2) with ESMTPSA id 411EliZR056041 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Feb 2024 14:47:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tdx.co.uk; s=krpdkim; t=1706798866; bh=hVlfIwIQGdD7sGAgXHJW/faMtcJ6Ou218gA3S7+6tRE=; h=Date:From:To:Subject; b=MZqIlx8awDqY3BPZ57QRvSub7eC4fMynGjOX1BqBMR3RJltxl0S1mSskumyYUfa7g 5ELn7Iw/vJYyb5P0kGJU65Q9SPdfZ0Iq3JKGK9aAZqyoTHsMtDBImAUk/uUrGyKedh Khjgyp2BoXtbMBuIWZCJm2cbD2MZsEzoL4OdQssci73I8XN4b7tIveY6M5K//PSnDN eiNDpC6ljncRX1anKGhLU7CWCsVyFOl/x6DudwWTLJYguSQoiMyhmh+FeRnJ8L1VNZ cN0VEKoF7GHGNADaFNVxd4eeH1NL08uYWpeFP7GyalqAU2ZyuTVQTKUuHzDYsE84lQ uh3EyMj5/bMkw== Date: Thu, 01 Feb 2024 14:47:44 +0000 From: Karl Pielorz To: Daniel Braniss , freebsd-hackers Subject: Re: ... was killed: a thread waited too long to allocate a page Message-ID: <29D13BFFCFA5255C07379043@[10.12.30.106]> In-Reply-To: <0C31C8D8-2335-43ED-96B3-21AC46F30C1D@cs.huji.ac.il> References: <0C31C8D8-2335-43ED-96B3-21AC46F30C1D@cs.huji.ac.il> X-Mailer: Mulberry/4.0.8 (Win32) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[tdx.co.uk,none]; MID_RHS_IP_LITERAL(0.50)[]; R_DKIM_ALLOW(-0.20)[tdx.co.uk:s=krpdkim]; R_SPF_ALLOW(-0.20)[+a:smtp.krpservers.com]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:60969, ipnet:62.13.128.0/22, country:GB]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tdx.co.uk:+] X-Rspamd-Queue-Id: 4TQhbb4dHDz4kJp --On 28 December 2023 11:38 +0200 Daniel Braniss wrote: > hi, > I'm running 13.2 Stable on this particular host, which has about 200TB of > zfs storage the host also has some 132Gb of memory, > lately, mountd is getting killed: > kernel: pid 3212 (mountd), jid 0, uid 0, was killed: a thread waited > too long to allocate a page > > rpcinfo shows it's still there, but > service mountd restart > fails. > > only solution is to reboot. > BTW, the only 'heavy' stuff that I can see are several rsync > processes. Hi, I seem to have run into something similar. I recently upgraded a 12.4 box to 13.2p9. The box has 32G of RAM, and runs ZFS. We do a lot of rsync work to it monthly - the first month we've done this with 13.2p9 we get a lot of processes killed, all with a similar (but not identical) message, e.g. pid 11103 (ssh), jid 0, uid 0, was killed: failed to reclaim memory pid 10972 (local-unbound), jid 0, uid 59, was killed: failed to reclaim memory pid 3223 (snmpd), jid 0, uid 0, was killed: failed to reclaim memory pid 3243 (mountd), jid 0, uid 0, was killed: failed to reclaim memory pid 3251 (nfsd), jid 0, uid 0, was killed: failed to reclaim memory pid 10996 (sshd), jid 0, uid 0, was killed: failed to reclaim memory pid 3257 (sendmail), jid 0, uid 0, was killed: failed to reclaim memory pid 8562 (csh), jid 0, uid 0, was killed: failed to reclaim memory pid 3363 (smartd), jid 0, uid 0, was killed: failed to reclaim memory pid 8558 (csh), jid 0, uid 0, was killed: failed to reclaim memory pid 3179 (ntpd), jid 0, uid 0, was killed: failed to reclaim memory pid 8555 (tcsh), jid 0, uid 1001, was killed: failed to reclaim memory pid 3260 (sendmail), jid 0, uid 25, was killed: failed to reclaim memory pid 2806 (devd), jid 0, uid 0, was killed: failed to reclaim memory pid 3156 (rpcbind), jid 0, uid 0, was killed: failed to reclaim memory pid 3252 (nfsd), jid 0, uid 0, was killed: failed to reclaim memory pid 3377 (getty), jid 0, uid 0, was killed: failed to reclaim memory This 'looks' like 'out of RAM' type situation - but at the time, top showed: last pid: 12622; load averages: 0.10, 0.24, 0.13 7 processes: 1 running, 6 sleeping CPU: 0.1% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.7% idle Mem: 4324K Active, 8856K Inact, 244K Laundry, 24G Wired, 648M Buf, 7430M Free ARC: 20G Total, 8771M MFU, 10G MRU, 2432K Anon, 161M Header, 920M Other 15G Compressed, 23G Uncompressed, 1.59:1 Ratio Swap: 8192M Total, 5296K Used, 8187M Free Rebooting it recovers it, and it completed the rsync after the reboot - which left us with: last pid: 12570; load averages: 0.07, 0.14, 0.17 up 0+00:15:06 14:43:56 26 processes: 1 running, 25 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 39M Active, 5640K Inact, 17G Wired, 42M Buf, 14G Free ARC: 15G Total, 33M MFU, 15G MRU, 130K Anon, 32M Header, 138M Other 14G Compressed, 15G Uncompressed, 1.03:1 Ratio Swap: 8192M Total, 8192M Free I've not seen any bug reports along this line, in fact very little coverage at all of the specific error. My only thought is to set a sysctl to limit ZFS ARC usage, i.e. to leave more free RAM floating around the system. During the rsync it was 'swapping' occasionally (few K in, few K out) - but it never ran out of swap that I saw - and it certainly didn't look like an complete out of memory scenario/box (which is what it felt like with everything getting killed). -Karl From nobody Thu Feb 1 16:30:19 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQksp2rcBz58x7X for ; Thu, 1 Feb 2024 16:30:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQksn1pHxz3xhs for ; Thu, 1 Feb 2024 16:30:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qFxvRv1r; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706805033; bh=BGeScltvFUSPzoh4m9rbePkx5k3tl5P1fyYXVn5EsNA=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=qFxvRv1rcUjFMCMzpBw5v4j087qMvb/+ZpedMR14vaui7rv3HQhXj4kRwR5ogYZdL7okvKctdS/G9IDrlZdRGrFn5rMnwLvh2ux3QX/5rg+SH66wupAmIgis+0fXEMt0eN9zpvbKj6FzEhIl57gC14yoJl/yph1Zvi/hEbHnZjQrB48MiU6Gsz2/T0ifzG/1N5YTMI+YsUi0W7FffxfGDW3QyS6U2k+nSRYIVNErwLQbVBJ58CcGyEQPzuf8tIjhtob1bTpXy19zdrV5XmSyTpp7rhCVV2vuWIW8y0NLjPnR8xmDG0xsLSIsE1Q4Vh9scp5z58YRtuarhrjPav651w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706805033; bh=N+KZduP6I8+9SP3DZ7p4mcJRIR6ojLDE9gHtViuluai=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=aaPodpKMVJL86wSMzsFZMSVP+6hLTDsIrDH3jMXdR1oOygsSVd2y2nmoB6rvypczgjqyE9C0efH84tmX5Dt/Hs6TV07f/P0SqdPa/LDkJzZiSc/1xPo14jJ639Gqq60pVLHJLsHkpPJhZw37MdkeH97G+3xmvLC1epXW/2GTmF61rXkEtrRaJ6fumnj68g8Gm4ai0HLksoEL3NCpPT6JJfggMjA32fAm9Pc5IZGmq8sOV5yqjiS9Cwh/xrZTtl5qn7Vhrl6thIC3/+gtwjKblx/sROCXAUtkuBEGt/gL2LwmR6b4DbO2CMwcdBZ9x7kELg2UN2twQNRtWPFRcKtANg== X-YMail-OSG: Uh4u27UVM1l03qlFTRjFI6hQ6IkuXnaZsD2l_JyjmPrnf4HzdsQSRy4clD09S_F Uis79ZvpCdPS5FSlXM.z323wc94kOhkVOdgV.pQrDxjA1fUWKS_5PwkpYu2KLFWwBwbl9d3SstUa u_o8Pv5.p.lyN.wH54JAdx3_6Cm1oNBNzzGJZ.q4yRztUEgOxyqjfpJzRNSvZ_4r6SHUWGpOSDxO SpoekYqQQ.SOTMokq7CP4VoAnTGVeBgdLFV07FQcORum.zX1kZS.0ZkmVThnRhwMOv6JAPas8MVR EjMZ3C_cAKITMcTSDXfNLJJGIewYGQiZoGvShOdpNyfk.z.sK0HA13yMvnW9F2hEZw0k8iNibJ9F iyzTjdIEjsUaqw5mEYDrSLHWRtcH0HeFzVgtGBhzqwgqWlBhtmXkYngQeDT98MCF0a3LD91Mtc8X 9N355VJ4P55M7G8n2WsJy1dywM56feHIAS4Wh26AOQzbkEUAR4Nm867ioUpMv7FYYC6NLpcYml6o XQmEi.FN3Jf44V1dbLTc3CiKt4TzEUOclkeUeqOzfxZdmec6VuQAIq9cUIm_6jwGDI_xo.Hqndhc MhpbcKkLIwekEje1UBwH91RC7Gp3FK5ispbz3YLRIY1mlE.iwJQZJM6cX2O8NmFBJ1oRBbBa_bCY wvJnXX29CR4FyH9kB0nGT3SP.AoTPpmFxSDwUZXXTr317C8MtnosXsFvAi0uYAydddauGyNnaO0x 9Cbw.vfn1u9R1sVd_RbITqjLTzvGiHk5ry.wA34rOOh9g1LRALbm0alWVPgJ.VCHW1r0x9eocP28 LXyq_Kfk6tQvq4cqvzjb.liAky8EtWtQ6jWWjoOaLjn30Oopx8_DqD2pe87rNHewetSV_bztPRij cKBCj9I8WWreeBCCagzTLyOtfnoSzfws8uPnKc6VS7V3THjiF7nRm5H93vKiFuv_XIpafOvRy_s6 LVgxpA6nEKIJ8MbwdFA2nxAcF2693E1TogV3yfzoAZvWNWxF.1gjauHZU6B2te15mtXubLhA2sDs IpB_R1Dfy9kVdj8Nr4AR2wxT8QPIGjokwujZbQAt8qGZ9mp0NnM4ayhELKLjQnT2ZlGQE.deD9So bIcmi0SCabxZxFBP4lx.VMqyiQ1MDS9QJ52267YzcAocpv7OywKvRcdazTJOzlwWGZlaiFJjQUtB fpGT58x3XLUkBF5UDoPCCo6BB0OJed_KDxNXySSlr_SM527nxRkDwgVDeOiRnLxqBfgrbZBTxkFS loHudmD977Z_ZkXqXhKr0J1fPUKwPi.7ctDktRvz9QyqeUUvPfN6g3YBTFwkaYP6AwLFtzdUsjAb NQ2o9UAH8A6facgw4Fz8DEmyqJ5GSFnKRklFpbrqh5wEZa0FPox_gsFFurxHsZ41kbobAakTdPMH XYOolslQ7t.QM8Owk8ndgJFeHVvBRfklQKOJzv58DNPXs8PJffIrq1g_3uMCMoh9ppyeH_ltOm9X JZljsQO4zU9K8cuAysBA9e5N_BjXzvKm61po36snWd_KY0K6911SOF2WgxTXFlFCH_CBkAWaoQ9o WMak_k8dt11FOrds2BhmXcNX8c6zsDM39ssxtVL0wTbLP2IuTjeSMsyJ5MbGk_xxT5pIdAUAsvrw .VTBsf6ioWNfTsNqZtm1IwRKuoy5jpTbQTgloBIvUfpzwsZxZ066B5usdo.BCLIVStf26eVicGOp ePU3pL1Qn1Ult4RZyZyL2n1vZVt_e2gWE__YXIzO8Ood6Yoolu2sMgyTtmsby9GUHB4_Q8IIP8bq QUE6QGm_QdXWlyLFlie_8o429TK4tMAO4TVJzKmnBX8BP9We1IKJ8BImyGQ1Gmf6p.frcWkFoaRS 0LZnGE2KuJ7s9H8CHF_S0w5x.JbzAvvgCdhZ08jN7qAgaYze3yXZbSHdyCJBrcU9J0nioFkbG96W uk2az7J9kuUPxb3ncMi07yoPt4G6RtVscPPS4JcDeqjA8W3H3FVdWQjNwNzRe8LaZSJPtx7f34PY pXujOaXTiPVm5SlxHRQ9LcJB.vinyBe_BXOA2TsAvZ63t48mbfXrnuRpYrOiWkku9_EjZiQdLXGa 2E4wMQhsdwWjl9waHl7sGOmpkbP557aMZpB73Wc2YV0_yFirdigD7qhWW8EIdt9ch1kdrwWrTGKu 2PH7UmZDRIjX07aIO9JHUUqYDbQXhqpXPymgtGIb6YFiRdzvXVjRyhYdm2uDJmF_UGu52hOzGyLe c4UlexyAuxaZ3kl0HNXZcJlZ864a47pmXqpJAK3ue6m1PYvm1iW99ccEk9_yhgdC4VrjrEB_.Jno - X-Sonic-MF: X-Sonic-ID: 750def05-8f6f-4d9d-84a7-1a5badb93094 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 1 Feb 2024 16:30:33 +0000 Received: by hermes--production-gq1-5c57879fdf-wt62k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4dcdb5fbc5a3d36791259574ed92ab9f; Thu, 01 Feb 2024 16:30:30 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: ... was killed: a thread waited too long to allocate a page [actually: was killed: failed to reclaim memory problem] Message-Id: Date: Thu, 1 Feb 2024 08:30:19 -0800 To: kpielorz_lst@tdx.co.uk, FreeBSD Hackers X-Mailer: Apple Mail (2.3774.300.61.1.2) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.79)[-0.791]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.205:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.205:from] X-Rspamd-Queue-Id: 4TQksn1pHxz3xhs Karl Pielorz wrote on Date: Thu, 01 Feb 2024 14:47:44 UTC : > --On 28 December 2023 11:38 +0200 Daniel Braniss =20= > wrote: >=20 > > hi, > > I'm running 13.2 Stable on this particular host, which has about = 200TB of > > zfs storage the host also has some 132Gb of memory, > > lately, mountd is getting killed: > > kernel: pid 3212 (mountd), jid 0, uid 0, was killed: a thread waited > > too long to allocate a page > > > > rpcinfo shows it's still there, but > > service mountd restart > > fails. > > > > only solution is to reboot. > > BTW, the only 'heavy' stuff that I can see are several rsync > > processes. >=20 > Hi, >=20 > I seem to have run into something similar. I recently upgraded a 12.4 = box=20 > to 13.2p9. The box has 32G of RAM, and runs ZFS. We do a lot of rsync = work=20 > to it monthly - the first month we've done this with 13.2p9 we get a = lot of=20 > processes killed, all with a similar (but not identical) message, e.g. >=20 > pid 11103 (ssh), jid 0, uid 0, was killed: failed to reclaim memory > pid 10972 (local-unbound), jid 0, uid 59, was killed: failed to = reclaim=20 > memory > pid 3223 (snmpd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3243 (mountd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3251 (nfsd), jid 0, uid 0, was killed: failed to reclaim memory > pid 10996 (sshd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3257 (sendmail), jid 0, uid 0, was killed: failed to reclaim = memory > pid 8562 (csh), jid 0, uid 0, was killed: failed to reclaim memory > pid 3363 (smartd), jid 0, uid 0, was killed: failed to reclaim memory > pid 8558 (csh), jid 0, uid 0, was killed: failed to reclaim memory > pid 3179 (ntpd), jid 0, uid 0, was killed: failed to reclaim memory > pid 8555 (tcsh), jid 0, uid 1001, was killed: failed to reclaim memory > pid 3260 (sendmail), jid 0, uid 25, was killed: failed to reclaim = memory > pid 2806 (devd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3156 (rpcbind), jid 0, uid 0, was killed: failed to reclaim memory > pid 3252 (nfsd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3377 (getty), jid 0, uid 0, was killed: failed to reclaim memory >=20 > This 'looks' like 'out of RAM' type situation - but at the time, top = showed: >=20 > last pid: 12622; load averages: 0.10, 0.24, 0.13=20 >=20 > 7 processes: 1 running, 6 sleeping > CPU: 0.1% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.7% idle > Mem: 4324K Active, 8856K Inact, 244K Laundry, 24G Wired, 648M Buf, = 7430M=20 > Free > ARC: 20G Total, 8771M MFU, 10G MRU, 2432K Anon, 161M Header, 920M = Other > 15G Compressed, 23G Uncompressed, 1.59:1 Ratio > Swap: 8192M Total, 5296K Used, 8187M Free >=20 > Rebooting it recovers it, and it completed the rsync after the reboot = -=20 > which left us with: >=20 > last pid: 12570; load averages: 0.07, 0.14, 0.17=20 > up 0+00:15:06 14:43:56 > 26 processes: 1 running, 25 sleeping > CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > Mem: 39M Active, 5640K Inact, 17G Wired, 42M Buf, 14G Free > ARC: 15G Total, 33M MFU, 15G MRU, 130K Anon, 32M Header, 138M Other > 14G Compressed, 15G Uncompressed, 1.03:1 Ratio > Swap: 8192M Total, 8192M Free >=20 >=20 > I've not seen any bug reports along this line, in fact very little = coverage=20 > at all of the specific error. >=20 > My only thought is to set a sysctl to limit ZFS ARC usage, i.e. to = leave=20 > more free RAM floating around the system. During the rsync it was=20 > 'swapping' occasionally (few K in, few K out) - but it never ran out = of=20 > swap that I saw - and it certainly didn't look like an complete out of=20= > memory scenario/box (which is what it felt like with everything = getting=20 > killed). One direction of control is . . . What do you have for ( copied from my /boot/loader.conf ): # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 The default is 12 (last I knew, anyway). The 120 figure has allowed me and others to do buildworld, buildkernel, and poudriere bulk runs on small arm boards using all cores that otherwise got "failed to reclaim memory" (to use the modern, improved [not misleading] message text). Similarly for others that had other kinds of contexts that got the message. (The units for the 120 are not time units: more like a number of (re)tries to gain at least a target amount of Free RAM before failure handling starts. The comment wording is based on a consequence of the assignment.) The 120 is not a maximum, just a figure that has proved useful in various contexts. But see the notes below based as well. Notes: "failed to reclaim memory" can happen even with swap space enabled but no swap in use: sufficiently active pages are just not paged out to swap space so if most non-wired pages are classified as active, the kills can start. (There are some other parameters of possible use for some other modern "was killed" reason texts.) Wired pages are pages that can not be swapped out, even if classified as inactive. Your report indicates: 24G Wired with 20G of that being from ARC use. This likely was after some processes had already been killed. So likely more was wired and less was free at the start of the kills. That 24G+ of wired meant that only 8GiBytes- were available everything else. Avoiding that by limiting the ARC (tuning ZFS) or adjusting how the work load is spread over time or some combination also looks appropriate. I've no clue why ARC use would be signifcantly different for 12.4 vs. 13.2p9 . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 1 16:32:00 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQkvb0cgyz58x4d for ; Thu, 1 Feb 2024 16:32:11 +0000 (UTC) (envelope-from SRS0=8X+v=JK=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4TQkvY715Bz40lL for ; Thu, 1 Feb 2024 16:32:09 +0000 (UTC) (envelope-from SRS0=8X+v=JK=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quip.cz header.s=private header.b=5sm3Szir; dkim=pass header.d=quip.cz header.s=private header.b=ycTpJAyb; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=8X+v=JK=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=8X+v=JK=quip.cz=000.fbsd@elsa.codelab.cz" Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 8F89ED788B for ; Thu, 1 Feb 2024 17:32:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1706805121; bh=LABKQZXNSGLhQjMXua9rYoWTzhsK3i5eM/DFSgRDBCE=; h=Date:Subject:To:References:From:In-Reply-To; b=5sm3SzirtD8mSvl1DnSB1ghIXEriuivr+qEQ5UpS+pmpIzfOAHLj4Eg1UQdR5RSaD zI1ubRehVo2hfDErOs5jxfEElDpplfs5GyAYGsxSPLcSE4OD12FXSM6Y+ctdFwXIjN /ubwMcG3qPNsT5JZnfxcTBGlVGi/K4fJGjfV3l5g= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9B749D7884 for ; Thu, 1 Feb 2024 17:32:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1706805120; bh=LABKQZXNSGLhQjMXua9rYoWTzhsK3i5eM/DFSgRDBCE=; h=Date:Subject:To:References:From:In-Reply-To; b=ycTpJAybavhcAaDU3XarYuOzGYj/FfcZALT7ZBNPVp7awlecuTqs8Q4QXbr0osKKo G64pkk4gd+o6gEEHP1PvB8FvJ+RolUJ09vrD3rVDXYDwXrGHoekPbLkHJETdNPdEEx IPFEkgw9JMD4mblq/IZW/2p1Y++nVFFc33e9I0zw= Message-ID: <2d2f309b-d27d-46f1-9a04-5d08252c0c0f@quip.cz> Date: Thu, 1 Feb 2024 17:32:00 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ... was killed: a thread waited too long to allocate a page Content-Language: en-US To: freebsd-hackers@freebsd.org References: <0C31C8D8-2335-43ED-96B3-21AC46F30C1D@cs.huji.ac.il> <29D13BFFCFA5255C07379043@[10.12.30.106]> From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <29D13BFFCFA5255C07379043@[10.12.30.106]> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.975]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=8X@elsa.codelab.cz]; R_DKIM_ALLOW(-0.20)[quip.cz:s=private]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[quip.cz]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=8X@elsa.codelab.cz]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TAGGED_FROM(0.00)[v=JK=quip.cz=000.fbsd]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[quip.cz:+] X-Rspamd-Queue-Id: 4TQkvY715Bz40lL On 01/02/2024 15:47, Karl Pielorz wrote: [..] > I seem to have run into something similar. I recently upgraded a 12.4 > box to 13.2p9. The box has 32G of RAM, and runs ZFS. We do a lot of > rsync work to it monthly - the first month we've done this with 13.2p9 > we get a lot of processes killed, all with a similar (but not identical) > message, e.g. > > pid 11103 (ssh), jid 0, uid 0, was killed: failed to reclaim memory > pid 10972 (local-unbound), jid 0, uid 59, was killed: failed to reclaim > memory > pid 3223 (snmpd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3243 (mountd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3251 (nfsd), jid 0, uid 0, was killed: failed to reclaim memory > pid 10996 (sshd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3257 (sendmail), jid 0, uid 0, was killed: failed to reclaim memory > pid 8562 (csh), jid 0, uid 0, was killed: failed to reclaim memory > pid 3363 (smartd), jid 0, uid 0, was killed: failed to reclaim memory > pid 8558 (csh), jid 0, uid 0, was killed: failed to reclaim memory > pid 3179 (ntpd), jid 0, uid 0, was killed: failed to reclaim memory > pid 8555 (tcsh), jid 0, uid 1001, was killed: failed to reclaim memory > pid 3260 (sendmail), jid 0, uid 25, was killed: failed to reclaim memory > pid 2806 (devd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3156 (rpcbind), jid 0, uid 0, was killed: failed to reclaim memory > pid 3252 (nfsd), jid 0, uid 0, was killed: failed to reclaim memory > pid 3377 (getty), jid 0, uid 0, was killed: failed to reclaim memory > > This 'looks' like 'out of RAM' type situation - but at the time, top > showed: I remember something similar on our machines after upgrade to 13.x about a year ago. But don't remember what steps we take to walk around this issue (if any). I also see this on my FreeBSD based desktop from time to time... "ad more memory" and limit the ARC in loader.conf is my way. [..] > I've not seen any bug reports along this line, in fact very little > coverage at all of the specific error. > > My only thought is to set a sysctl to limit ZFS ARC usage, i.e. to leave > more free RAM floating around the system. During the rsync it was > 'swapping' occasionally (few K in, few K out) - but it never ran out of > swap that I saw - and it certainly didn't look like an complete out of > memory scenario/box (which is what it felt like with everything getting > killed). From nobody Thu Feb 1 18:26:48 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQnS71PVGz58NqQ for ; Thu, 1 Feb 2024 18:27:03 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQnS63MPCz4CvN for ; Thu, 1 Feb 2024 18:27:01 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 411IQnk5029266; Fri, 2 Feb 2024 03:26:49 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 2 Feb 2024 03:26:48 +0900 From: Tomoaki AOKI To: Mark Millard Cc: kpielorz_lst@tdx.co.uk, FreeBSD Hackers Subject: Re: ... was killed: a thread waited too long to allocate a page [actually: was killed: failed to reclaim memory problem] Message-Id: <20240202032648.917edb3172db93881b3dd67f@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4TQnS63MPCz4CvN X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] On Thu, 1 Feb 2024 08:30:19 -0800 Mark Millard wrote: > Karl Pielorz wrote on > Date: Thu, 01 Feb 2024 14:47:44 UTC : > > > --On 28 December 2023 11:38 +0200 Daniel Braniss > > wrote: > > > > > hi, > > > I'm running 13.2 Stable on this particular host, which has about 200TB of > > > zfs storage the host also has some 132Gb of memory, > > > lately, mountd is getting killed: > > > kernel: pid 3212 (mountd), jid 0, uid 0, was killed: a thread waited > > > too long to allocate a page > > > > > > rpcinfo shows it's still there, but > > > service mountd restart > > > fails. > > > > > > only solution is to reboot. > > > BTW, the only 'heavy' stuff that I can see are several rsync > > > processes. > > > > Hi, > > > > I seem to have run into something similar. I recently upgraded a 12.4 box > > to 13.2p9. The box has 32G of RAM, and runs ZFS. We do a lot of rsync work > > to it monthly - the first month we've done this with 13.2p9 we get a lot of > > processes killed, all with a similar (but not identical) message, e.g. > > > > pid 11103 (ssh), jid 0, uid 0, was killed: failed to reclaim memory > > pid 10972 (local-unbound), jid 0, uid 59, was killed: failed to reclaim > > memory > > pid 3223 (snmpd), jid 0, uid 0, was killed: failed to reclaim memory > > pid 3243 (mountd), jid 0, uid 0, was killed: failed to reclaim memory > > pid 3251 (nfsd), jid 0, uid 0, was killed: failed to reclaim memory > > pid 10996 (sshd), jid 0, uid 0, was killed: failed to reclaim memory > > pid 3257 (sendmail), jid 0, uid 0, was killed: failed to reclaim memory > > pid 8562 (csh), jid 0, uid 0, was killed: failed to reclaim memory > > pid 3363 (smartd), jid 0, uid 0, was killed: failed to reclaim memory > > pid 8558 (csh), jid 0, uid 0, was killed: failed to reclaim memory > > pid 3179 (ntpd), jid 0, uid 0, was killed: failed to reclaim memory > > pid 8555 (tcsh), jid 0, uid 1001, was killed: failed to reclaim memory > > pid 3260 (sendmail), jid 0, uid 25, was killed: failed to reclaim memory > > pid 2806 (devd), jid 0, uid 0, was killed: failed to reclaim memory > > pid 3156 (rpcbind), jid 0, uid 0, was killed: failed to reclaim memory > > pid 3252 (nfsd), jid 0, uid 0, was killed: failed to reclaim memory > > pid 3377 (getty), jid 0, uid 0, was killed: failed to reclaim memory > > > > This 'looks' like 'out of RAM' type situation - but at the time, top showed: > > > > last pid: 12622; load averages: 0.10, 0.24, 0.13 > > > > 7 processes: 1 running, 6 sleeping > > CPU: 0.1% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.7% idle > > Mem: 4324K Active, 8856K Inact, 244K Laundry, 24G Wired, 648M Buf, 7430M > > Free > > ARC: 20G Total, 8771M MFU, 10G MRU, 2432K Anon, 161M Header, 920M Other > > 15G Compressed, 23G Uncompressed, 1.59:1 Ratio > > Swap: 8192M Total, 5296K Used, 8187M Free > > > > Rebooting it recovers it, and it completed the rsync after the reboot - > > which left us with: > > > > last pid: 12570; load averages: 0.07, 0.14, 0.17 > > up 0+00:15:06 14:43:56 > > 26 processes: 1 running, 25 sleeping > > CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > > Mem: 39M Active, 5640K Inact, 17G Wired, 42M Buf, 14G Free > > ARC: 15G Total, 33M MFU, 15G MRU, 130K Anon, 32M Header, 138M Other > > 14G Compressed, 15G Uncompressed, 1.03:1 Ratio > > Swap: 8192M Total, 8192M Free > > > > > > I've not seen any bug reports along this line, in fact very little coverage > > at all of the specific error. > > > > My only thought is to set a sysctl to limit ZFS ARC usage, i.e. to leave > > more free RAM floating around the system. During the rsync it was > > 'swapping' occasionally (few K in, few K out) - but it never ran out of > > swap that I saw - and it certainly didn't look like an complete out of > > memory scenario/box (which is what it felt like with everything getting > > killed). > > > One direction of control is . . . > > What do you have for ( copied from my /boot/loader.conf ): > > # > # Delay when persistent low free RAM leads to > # Out Of Memory killing of processes: > vm.pageout_oom_seq=120 > > The default is 12 (last I knew, anyway). > > The 120 figure has allowed me and others to do buildworld, > buildkernel, and poudriere bulk runs on small arm boards > using all cores that otherwise got "failed to reclaim > memory" (to use the modern, improved [not misleading] > message text). Similarly for others that had other kinds > of contexts that got the message. > > (The units for the 120 are not time units: more like a > number of (re)tries to gain at least a target amount of > Free RAM before failure handling starts. The comment > wording is based on a consequence of the assignment.) > > The 120 is not a maximum, just a figure that has proved > useful in various contexts. > > But see the notes below based as well. > > Notes: > > "failed to reclaim memory" can happen even with swap > space enabled but no swap in use: sufficiently active > pages are just not paged out to swap space so if most > non-wired pages are classified as active, the kills > can start. > > (There are some other parameters of possible use for some > other modern "was killed" reason texts.) > > Wired pages are pages that can not be swapped out, even > if classified as inactive. > > Your report indicates: 24G Wired with 20G of that being > from ARC use. This likely was after some processes had > already been killed. So likely more was wired and less > was free at the start of the kills. > > That 24G+ of wired meant that only 8GiBytes- were > available everything else. Avoiding that by limiting > the ARC (tuning ZFS) or adjusting how the work load > is spread over time or some combination also looks > appropriate. > > I've no clue why ARC use would be signifcantly > different for 12.4 vs. 13.2p9 . > > === > Mark Millard > marklmi at yahoo.com Possibly not related, but codebase of ZFS on FreeBSD is switched from legacy one (aka ZoF) to OpenZFS on 13.0. -- Tomoaki AOKI From nobody Thu Feb 1 18:31:22 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQnYB0jhgz58P84 for ; Thu, 1 Feb 2024 18:31:26 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQnY95Jmsz4Dqk for ; Thu, 1 Feb 2024 18:31:25 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from [10.12.30.106] by smtp.krpservers.com (8.16.1/8.15.2) with ESMTPSA id 411IVMQ7009949 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Feb 2024 18:31:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tdx.co.uk; s=krpdkim; t=1706812283; bh=fupx3TGPTBNVUKxCSjg5yIu3v0+pny02zxS7dtSPXL4=; h=Date:From:To:Subject; b=S6dC8SgKKVP0DFDCcs275+KEVs3taOroyNGizjQhoThIsnOxfO9SLXQ5TB3ZJNw7a qMuf5uCgQyu8wJhRPNch1I+ErRLb02HOeMmboo6uPDHnPyNt9JjUqYwHaWtbE+NvDD VcCyphcS9m6L5HPY+5S+fr0BOIiJOw/4A25MZbIaro5kQ5yLozCysphesfc3yN/gb7 6QOTetiUFKpBqk629GVB8PrxPXwUQpwS2vUBIM7AKqX4kn/5mm7iJhp2rEJ6YRRBIO a/Gt2bYVeqI7RdjXcBSLEY0YAlnb56Kvi7u3HNLFuDv1HmmvXznpTVuoVLqRywyze8 NJbcu1EjOU6UQ== Date: Thu, 01 Feb 2024 18:31:22 +0000 From: Karl Pielorz To: Mark Millard , FreeBSD Hackers Subject: Re: ... was killed: a thread waited too long to allocate a page [actually: was killed: failed to reclaim memory problem] Message-ID: <25AE8AA9598F0FDEB97B2C47@[10.12.30.106]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Rspamd-Queue-Id: 4TQnY95Jmsz4Dqk X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:60969, ipnet:62.13.128.0/22, country:GB] --On 01 February 2024 08:30 -0800 Mark Millard wrote: > [snip] > > One direction of control is . . . > > What do you have for ( copied from my /boot/loader.conf ): > ># ># Delay when persistent low free RAM leads to ># Out Of Memory killing of processes: > vm.pageout_oom_seq=120 loader.conf is empty - it's a pretty stock / out the box install. > The default is 12 (last I knew, anyway). Yes, default is 12 here. > The 120 figure has allowed me and others to do buildworld, > buildkernel, and poudriere bulk runs on small arm boards > using all cores that otherwise got "failed to reclaim > memory" (to use the modern, improved [not misleading] > message text). Similarly for others that had other kinds > of contexts that got the message. > > (The units for the 120 are not time units: more like a > number of (re)tries to gain at least a target amount of > Free RAM before failure handling starts. The comment > wording is based on a consequence of the assignment.) > > The 120 is not a maximum, just a figure that has proved > useful in various contexts. > > But see the notes below based as well. Thanks for the notes. I think I can reproduce this (but it's painful to do - as is pretty much any production server killing all it's procs) so I'll wait until next run. I've set the vm.pageout_oom_seq=120 if only because it's a runtime option (no reboot). It's been many, many years since I had to do anything with default arc sizing on FreeBSD (thankfully) - something I wouldn't want to really do again for such a 'simple' machine. I've noted the change here - and we'll see how it goes. > That 24G+ of wired meant that only 8GiBytes- were > available everything else. Avoiding that by limiting > the ARC (tuning ZFS) or adjusting how the work load > is spread over time or some combination also looks > appropriate. tbh - 8GiB is probably more than enough for what's running on that machine (very little) - but I take your point. Cheers, -Karl From nobody Thu Feb 1 19:17:34 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQpZl61Dfz58T8q for ; Thu, 1 Feb 2024 19:17:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQpZl2Rddz4JLm for ; Thu, 1 Feb 2024 19:17:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706815068; bh=dg5POWZ53SCIEBGXsi+vXlF2sTeAcbUDNL0IsZNi0wo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=m53zuOJH/p3zSDBORyP66makMZ06XzgEKqB+DpkMA9EmerN9r/TBIIFsb6y686Hlueh2SuINkv/biV+OkSak7ZXoLWcO5RpJr420e3EJSgIgj/64yO/5Vh9RT971IajgJoYQ+e/lX5gefiW/ufXF0+LsTZ08A6iW1KSC+GWJ1WYDWbjSN5z/HFn9RnSSIXPoEaNhMbO/bSBedS+K9k9J6VTt3G2d6y0XnUW4zs8l6qkwiXVJL+0EjWwIZlrd14rb45HWaHbvZoSj+YUELUicbodlngY6azv0pdPcRWomeDwnqYyVaYdiKbIj6bkyTwbd+E5vaCGrLsdmLMWFR4FnYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706815068; bh=VYiWzPst+8tXvPt8fbwFRdOJ7IPgdLcWUaSUaBrZNLB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IMueXsd7eIVODCRFJ+vGS0EnLtHiMh4rysElhAod64+Wo4+c5jgpLX3lFHwC1E3GCxf85M8cS+6kil7E2nnw1SXedqO4uab1J8cfI86wUjP//K3ONsjLpssURpHFc4QybCloTGey6fdF52q2Qv/O3XdkF2C43TGvyYq69pbVt5PYXSpSLi3K817ljK4D4k3TYwbY8NJfLyH13Im1JUSzVY6eDbwuceOD5HCxD0xIEEllh0bd0qsNk3bjs9CHJIzeGZ6I0SMi2AzpgiB5xDCIBmZ8/YEdMbc6HZ09297QJ2PAEEWru0bKW/PteTbbjJoTlQB9KSOjZMU4yZiGk+mw+w== X-YMail-OSG: ZG8_1YMVM1njHtkcilU8xzaOPpJNfuaPYzGbBIe4flfBq17qFMmVYQIB4..0oHg 3.RsuIcoYBJdM3wftUnl34cP5WSFMRHQDOBrlFMDVjEV1XI_G.QKP.Hzns7OpF2jB18FoLVu9VOB jhVX00Fbx1JMENUahnSUnq0YbEI69mt0V9lLXH8.Xv8DkxGoIyfBXTVBcU89rPSct28P7caUqQlF 1witGPcZTwF1IXKm3n6vsd08s9Sl.pEMln8QWNejktrv04Yj8RQrerbJI5z4rnDP.el4x7FfYNHt s4FUgy1F7DoK9SyBpYpo1WIi4qqDkSichbrRakfeDY4j_gEJFranJxUxVb_tu.jvV6LTt6yQkF1k SXb1.eaFbVCeejHnVAyN8b28ySchS6ZZ5hJq6cnkF3vi_s5MAN8.fUXpnAfS6IdLjl59z0pmgEnS 0102Lb4Z5bY9aed3Zo0IWJNmwZzyWx97PjO7mJ5sk_tO.rBMsC3NvUm4bSgxK_1kZML0UPRMuvhI ahHywS8ur9HFzc2sXJ0833tgEJwQALFrBzMHFLtr95LTvfC60oewTF3N_p72e5914nCzJammTrC4 sxUAY8NSU7OAmAdH40sr.wLjzv9_j6wB8rRkL5Rqi0LQz9oeSz1nIjRR81WXbl9Az02C65E.xVPq iJ0So6xpst3PGpAFcnuVYSBSHtCEKkMnutk.OH35QqYDyyrMfpdGnKYY.8VH5Z9VzBLQ63Wf9lUA 72wvGYfqoBUD62E.ZQQp.jRpgwu5gIVx8rJs_TzR.Vz2hi6D0GImMQMxq945lxGKfdJVV76C7Vxc G8lcYq77G._neoOhpNMjVQyU0Kqvz3ztTfeEM0PuENigROTeWxKmctIgmDW68I3gDqNduyOVJj96 bt0eMdqWT8JTUBw8NskWJiCsgVa5ogwi6NeOrDCtr07DeFzV4tvSSMV3WVrL7SDSDLunBDh9_uyx j5gdQ9scNGWeBl9UXOPgasIUCtF9vzxpMt8_mo9vAvHwdbNbg3zF.t308x026b9GkSlzYFua7Shs oAe0zcyepMoHLLKj1eNfVfM6CMgk2S8U6ZcfPU3jQrWPRCYL6X90Z81Za4iHY1fsT5ELK9m2RmKF j9AVxIo.0J0Mm1Q0wRnWc6YMyKsxLIvDB5WZATnhl8jXcMM3xm3YOVbG4zeOaRu2PBdQtrOKBElz z84f7N_Db1BZJe4W15k6ETu3_4BMOysbz5UEoKCSXHvmF5XWVnPiR4IpREPwoehFt8mquFoID2DF 9iFfrZTsKfvzF86DYvU.DlpJSG3V2Bx1c7hMxYReq4CpO433IcP7saZg.UD7QKKCdv19Y0GOffP_ zngcVcQiDlLDFmu1x3qiWOSs9blyZCtzeWhhuPxBawaLDRVZ6_hyh6WMUH7i6fMMXlUSWyps1KqW KvZvVVmvRwfmd5y0PNs31Lxm8nft_gSuxSA1Ha.CN5LBoaWJUkA.rlYmc66x5JRb4MnaJLrZXPU. H2LC7YGNuwLhD8Ww27bWgWcGp5pgq8W2Eqx2r235WLH_fP4AomP8I5nv5l541CmxDNqf7ujgtS.R Y7FAIfsG9hK7CNrF8pbXxiQP61X3rho510.7n5C_KRi2QoR.mX5ttMc3zX3uuSHM643jaxp4QVzy Ve4SGbBHhXCi9kBPi31VW04AUHh_DH82AcKMDiClJjQNRhCzsgnAdzOt66IZcDZXUYDdt5p48PR_ Ztmsqz344QSwMxJLYsoVmdhVgIuOxpfSsV0OVhtFlN4sLulmLRLEezl7e1vJ1YLgIORGIIsBlSpx ULJmVG4naKOizKNE.T5xFrMP.v.FvgLnO9mzuXRom1pzBNyRrRxkTglZ4P5ca.YFwFZ7c3ZTuj_C AmeUpjdjaZiWb7xeLEbsP6oM7KnlVUaaa71WUpN7WwHXoihuwAj7Yzbj6SfFKbRTLiRbGTjGCPdm UMBLe8ZXTBtqdcpamwDRe.xr_fQW8vJvQX8lXf4vWJn9DkioQ6GegCPuaxXjfR.2NeKE6Q2go7Rr mJC5FZdQQsaHZAjXJo7rk3SXzFxzRBxKZkSHlkp3fHmJ4lGK8Pv05IBaiASmpB7SRMUZerEEsTYg QtUywiAdCBL7tPkXO5hwSD3.golvUJe9fZsd2.pCl6nIsn_e6_YXqAdtiUASNhIux5n6wBWMM_bI boqHi4dPM8lN_Y7B7zlPXmYF7VaALqO8Agz7XG2DeiKyJ3lqR1bbQWOPoOoTJstD6D_TyZRoCMb1 5ixzlJ_oHteT3XL6YFvh_TgwxoRoMexY_4lm.svWbVi4hSlJtFUaDfbT1zwENjQ88JdQYBBJ9ZAT e X-Sonic-MF: X-Sonic-ID: 220bfba2-95ec-48fa-ad5d-bb9b3334e200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 1 Feb 2024 19:17:48 +0000 Received: by hermes--production-gq1-5c57879fdf-wt62k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9807c63dc8df3b50ae3dfda4078bd900; Thu, 01 Feb 2024 19:17:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: ... was killed: a thread waited too long to allocate a page [actually: was killed: failed to reclaim memory problem] From: Mark Millard In-Reply-To: <25AE8AA9598F0FDEB97B2C47@[10.12.30.106]> Date: Thu, 1 Feb 2024 11:17:34 -0800 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <25AE8AA9598F0FDEB97B2C47@[10.12.30.106]> To: Karl Pielorz X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TQpZl2Rddz4JLm X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Feb 1, 2024, at 10:31, Karl Pielorz wrote: > --On 01 February 2024 08:30 -0800 Mark Millard = wrote: >> [snip] >>=20 >> One direction of control is . . . >>=20 >> What do you have for ( copied from my /boot/loader.conf ): >>=20 >> # >> # Delay when persistent low free RAM leads to >> # Out Of Memory killing of processes: >> vm.pageout_oom_seq=3D120 >=20 > loader.conf is empty - it's a pretty stock / out the box install. >=20 >> The default is 12 (last I knew, anyway). >=20 > Yes, default is 12 here. >=20 >> The 120 figure has allowed me and others to do buildworld, >> buildkernel, and poudriere bulk runs on small arm boards >> using all cores that otherwise got "failed to reclaim >> memory" (to use the modern, improved [not misleading] >> message text). Similarly for others that had other kinds >> of contexts that got the message. >>=20 >> (The units for the 120 are not time units: more like a >> number of (re)tries to gain at least a target amount of >> Free RAM before failure handling starts. The comment >> wording is based on a consequence of the assignment.) >>=20 >> The 120 is not a maximum, just a figure that has proved >> useful in various contexts. >>=20 >> But see the notes below based as well. >=20 > Thanks for the notes. I think I can reproduce this (but it's painful = to do - as is pretty much any production server killing all it's procs) = so I'll wait until next run. I've set the vm.pageout_oom_seq=3D120 if = only because it's a runtime option (no reboot). Yep: sysctl -T vm.pageout_oom_seq shows it (so: a tunable) and sysctl -W vm.pageout_oom_seq shows it (so: a writable). > It's been many, many years since I had to do anything with default arc = sizing on FreeBSD (thankfully) - something I wouldn't want to really do = again for such a 'simple' machine. I've noted the change here - and = we'll see how it goes. >=20 >> That 24G+ of wired meant that only 8GiBytes- were >> available everything else. Avoiding that by limiting >> the ARC (tuning ZFS) or adjusting how the work load >> is spread over time or some combination also looks >> appropriate. >=20 > tbh - 8GiB is probably more than enough for what's running on that = machine (very little) - but I take your point. >=20 That you got the kill's indicates otherwise for the before-kills context: the free RAM had to be much smaller than that to get the kills (see notes below). Getting information from the time just before the kills start, such as top output, could be very interesting. Unfortunately, getting such tends to be messy. But the likes of vm.pageout_oom_seq=3D120 helps with the issue of observerving the bad conditions because they last longer. Even if vm.pageout_oom_seq=3D120 prevents the kills, you should be able to observe how bad things get during the bad time. (Presuming you can be there to observe in the proper time frame.) Of interest would also be the likes of: # sysctl -d vm.stats.vm | grep v_free vm.stats.vm.v_free_severe: Severe page depletion point vm.stats.vm.v_free_count: Free pages vm.stats.vm.v_free_min: Minimum low-free-pages threshold vm.stats.vm.v_free_target: Pages desired free vm.stats.vm.v_free_reserved: Pages reserved for deadlock So (not from your bad context): # sysctl vm.stats.vm | grep v_free vm.stats.vm.v_free_severe: 30540 vm.stats.vm.v_free_count: 6072295 vm.stats.vm.v_free_min: 50578 vm.stats.vm.v_free_target: 170806 vm.stats.vm.v_free_reserved: 10502 This was from an aarch64 context with: real memory =3D 33698009088 (32136 MB) avail memory =3D 32827478016 (31306 MB) In decreasing order (ignoring the live count): vm.stats.vm.v_free_target: 170806 vm.stats.vm.v_free_min: 50578 vm.stats.vm.v_free_severe: 30540 vm.stats.vm.v_free_reserved: 10502 You may want to look those up on your system. FYI: 170806 * 4096 Bytes/page is somewhat over 667 MiBytes. 50578 * 4096 Bytes/page is somewhat under 198 MiBytes. 30540 * 4096 Bytes/page is somewhat over 119 MiBytes. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 2 17:24:19 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRN1x1v5Kz597xq for ; Fri, 2 Feb 2024 17:24:53 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRN1v0gwfz4Z98 for ; Fri, 2 Feb 2024 17:24:51 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=UGiyD8tP; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=oESpXHUw; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.29 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 612465C00EA for ; Fri, 2 Feb 2024 12:24:50 -0500 (EST) Received: from imap46 ([10.202.2.96]) by compute6.internal (MEProxy); Fri, 02 Feb 2024 12:24:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1706894690; x=1706981090; bh=aJBWo+svz5oXC2IhYD7SDrX63963UyZM SbsYryZQqLU=; b=UGiyD8tP1TRiooyLcdt5BxM+X0iQOUgML9Aa/y9suH0BB9sv CkDJVWNYmm12QRxoRJFKxwSTAWCUrCioOL/9/GFRE3eoTSXBa4HwoiHlUj4+Ntv4 MovxmcKc55PVFLRDu1a+CaBmazRZVGZvFKsDbNL5rg/wx5yCfa8Bttk7Mq5gCRQW kMvdwI9DBUjVafmBjIF0YoMPeaFUtZAl/7yUt53zCd9NzE0IQRmWi93NEra5+IdF pxpwF5X77sUJQwRYNv0Fj+be4JC0cSKTlALHW30tfoLncv54X9P3lQ4BQqEk3l3G r25AkBCwltigdGdBnqXv9r+Hu3K5evEyAMX46g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1706894690; x=1706981090; bh=aJBWo+svz5oXC2IhYD7SDrX63963UyZMSbs YryZQqLU=; b=oESpXHUwSZFu/keUjZDTpfhoQ2f1mHf9JPH7zaid+g86RAFBjE4 WEECerMwYYAC9O7aZ/20xchJeQQNf70SJaK62w6KGM4oooVLIVOJYKjFuLEekaXw 9mgP8oysoQotsfnN2N+3cP+KVNRChOBUxLsD7VG/9ViUeb46CrJOosORWMMdNIFr nM36ZhuHixzXVwcxan08g0S7V9WmPtHtKM7TaMVDGA5fMs9ATMgt7b0z+eExijIO eiUCu99RfC21ZXJtjWEiDMEMhvWBNSx042P45zNO37yDqfMoGzlQrAQWD0c+ePEQ WROFdATb0pLbs4JeOl+no+gQoVcJD/bMA4w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedugedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeekieegvdekteefuedulefgheeutdfhtdevtdeuudehgfelveehffeliedufe fghfenucffohhmrghinhepuhhsvghrrdhfmhenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1F2332A2008B; Fri, 2 Feb 2024 12:24:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 x-forwarded-message-id: <0a901ea8-ac0d-47ec-8deb-8fae70ee583a@app.fastmail.com> Message-Id: <884072c0-48dd-4e4b-bc9a-012fda0aff6c@app.fastmail.com> Date: Fri, 02 Feb 2024 17:24:19 +0000 From: void To: freebsd-hackers@freebsd.org Subject: Fwd: onboard wireless on rpi4b Content-Type: text/plain X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.37 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; NEURAL_SPAM_SHORT(0.12)[0.121]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm] X-Rspamd-Queue-Id: 4TRN1v0gwfz4Z98 Hello, Re-mailing this to hackers@ in the hope of getting an answer yea or nay. Am no longer using the kernel mentioned below but am happy to recompile/test incorporating any work-in-progress, if there is any. On Mon, 22 Jan 2024, at 02:20, void wrote: > Hello wireless, > > I'm interested in trying to get the onboard wifi to run on a rpi4/8GB > board but the information I can get thus far on it appears to be > old/inconclusive. The MMCCAM kernel configs need to be used for this? > > dmesg of a few days ago, for GENERIC-MMCCAM: > http://void.f-m.fm.user.fm/2024.01.07.freebsd-current-main-n267425-generic-mmccam-dmesg.txt > > I'm right now using GENERIC-MMCCAM-NODEBUG > > What else do I need to do to test? > -- From nobody Sat Feb 3 00:16:26 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRY9G5VsMz58Zxy for ; Sat, 3 Feb 2024 00:16:50 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRY9F39sRz4GJt for ; Sat, 3 Feb 2024 00:16:49 +0000 (UTC) (envelope-from chuck@tuffli.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuffli.net header.s=fm2 header.b="ab0Bd/hE"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=OZNiobh8; dmarc=none; spf=pass (mx1.freebsd.org: domain of chuck@tuffli.net designates 64.147.123.20 as permitted sender) smtp.mailfrom=chuck@tuffli.net Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id 89DE63200A44 for ; Fri, 2 Feb 2024 19:16:47 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute7.internal (MEProxy); Fri, 02 Feb 2024 19:16:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuffli.net; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm2; t=1706919406; x=1707005806; bh=XjazfdgV4IoYfMH5YWvwvspEN2pzCZJP zE09FTXg4dg=; b=ab0Bd/hEWpWwKOWxsPo5C3HVKKbHThguz1p6e8sEoUnwqVvA UNQkxSVZdGSOu4ifph53RuMkj3dT0TGGlvkF8megJ4uRVsNhDN26rYGZzU5eKAcE KMADv4NnY8VuF2V+sWigqlhfrA43Vvqk1LBeb22E+XaOO8qiyTzZur2x5cLu742I shUUOmT9sXCqaUIApmASEpic4pJCWUrEM/16WTQ13pIENXBxWb+7AdUeQlxoh6Bb IuhALhbhKj4Qob/1eyeL+R4cVCms9lUilQCDjKZ15w2tmK/HqL1HCzeH30swPYGM 5waY+K/ioFWLrv/Gk4dzGQ3iGOvPnSv6vHWOpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1706919406; x=1707005806; bh=XjazfdgV4IoYfMH5YWvwvspEN2pzCZJPzE0 9FTXg4dg=; b=OZNiobh84WzRVIFGT0CDp+gS6tsU/zsNW05sX/eNdVkuMLR64Uw izVIn1IAeSPMLKpcB9RMTMgFmpgORmij67nNwKM4s1EMsdk/xgQF/gGqE8WzFtgq yWAEgx+lKxCTqFXjZXpn2x6rw0GtEMxHBmomaWzAmI53mYYNYI+cyQ5jkS4Dh2Y9 R6PMYooLaR0ING+0kSL16JtWRr5FprFSLGEJKq2LO0nITtU+JUPmfBg51uW7Ph5c MaHZUpizEww8UhxgNo6A8NQSPv2t9qqXRSEy02u/4szAqpPdY9YWnU7IDP3Apwdx 1gySkYk8zLQfgAmeKhUoSjhJ1lZR+/Op3rQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeduhedgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpedfvehhuhgtkhcuvfhufhhflhhifdcuoegthhhutghksehtuhhf fhhlihdrnhgvtheqnecuggftrfgrthhtvghrnhepieefleefleeiveekhfekvdeugffgvd eihedtueeujeeikeevhedvieduueffgfefnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheptghhuhgtkhesthhufhhflhhirdhnvght X-ME-Proxy: Feedback-ID: ib6f94606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5898CB6008D; Fri, 2 Feb 2024 19:16:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-Id: Date: Fri, 02 Feb 2024 16:16:26 -0800 From: "Chuck Tuffli" To: freebsd-hackers@freebsd.org Subject: Profiling applications Content-Type: multipart/alternative; boundary=433a32d60ab54ff8aee06081ae9ef40e X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_SHORT(-0.99)[-0.991]; SUBJECT_ENDS_SPACES(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.20:from]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; R_DKIM_ALLOW(-0.20)[tuffli.net:s=fm2,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; XM_UA_NO_VERSION(0.01)[]; DMARC_NA(0.00)[tuffli.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[tuffli.net:+,messagingengine.com:+]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[chuck]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~] X-Rspamd-Queue-Id: 4TRY9F39sRz4GJt --433a32d60ab54ff8aee06081ae9ef40e Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable What is the recommended way of profiling applications on FreeBSD these d= ays? I=E2=80=99m looking for information like =E2=80=9C28% of the execut= ion time is spent in function X=E2=80=9D. =E2=80=94chuck=20 --433a32d60ab54ff8aee06081ae9ef40e Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
What is the rec= ommended way of profiling applications on FreeBSD these days? I=E2=80=99= m looking for information like =E2=80=9C28% of the execution time is spe= nt in function X=E2=80=9D.

=E2=80=94chuck&n= bsp;
--433a32d60ab54ff8aee06081ae9ef40e-- From nobody Sat Feb 3 07:14:28 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRkRD4XpGz58XS6 for ; Sat, 3 Feb 2024 07:14:32 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRkRD2SRLz4DJF for ; Sat, 3 Feb 2024 07:14:32 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id VxLgr9flkGAIJWAERrMfUP; Sat, 03 Feb 2024 07:14:31 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id WAEPrRgcG9Cr4WAEQr87B5; Sat, 03 Feb 2024 07:14:31 +0000 X-Authority-Analysis: v=2.4 cv=etl8zZpX c=1 sm=1 tr=0 ts=65bde7d7 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=k7vzHIieQBIA:10 a=fV8ZZk05AAAA:8 a=TeXQEi0gAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=62Dx-lNWg2fSEhm-ccwA:9 a=QEXdDO2ut3YA:10 a=QFyySfyjxHkA:10 a=bW4SNCYk5CwG5Z2S0tlZ:22 a=bEhy0igz1TKSDeFmpLWy:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 42412400; Fri, 2 Feb 2024 23:14:29 -0800 (PST) Received: from slippy (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id 280ABDC; Fri, 2 Feb 2024 23:14:29 -0800 (PST) Date: Fri, 2 Feb 2024 23:14:28 -0800 From: Cy Schubert To: "Chuck Tuffli" Cc: freebsd-hackers@freebsd.org Subject: Re: Profiling applications Message-ID: <20240202231428.7c711308@slippy> In-Reply-To: References: Organization: KOMQUATS X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfLiWp6OT/4sozQqZxnfd2ojGNW4DNnY6PGr5Wih4sYL8uuVvjK6asNVrC87kGa35a71Co3jkSNbfWLFONMjxfUrZi2CjFGgGkBMVTxhAzj0FTShce9NN iiZ8Y0F0tbzvZmY0yZc3ClRjy2z6UCQm66+fITkDaqZbmHDjW+8DdNo4u+jGSk9Cvj1A4gTkzA9d6l12CEtokzpPcITXEn7IKIyux3R347Maps8QnpqKSY6z CjFJQpER44BmUestmxJjFQ== X-Rspamd-Queue-Id: 4TRkRD2SRLz4DJF X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] On Fri, 02 Feb 2024 16:16:26 -0800 "Chuck Tuffli" wrote: > What is the recommended way of profiling applications on FreeBSD these da= ys? I=E2=80=99m looking for information like =E2=80=9C28% of the execution = time is spent in function X=E2=80=9D. >=20 > =E2=80=94chuck=20 Try DTrace. The DTrace book (if you can get your hands on it) is a good source of information about profiling. Oracle (formerly Sun) has some good resources. https://ekamperi.github.io/Geant4/dtrace.html may provide some pointers. Brendan Gregg's (Brendan wrote DTrace) flame FlameGraph is another option, though it displays hot PIDs, probably not what you're looking for. The DTrace Tookit is in ports. There are some DTrace code samples there. Once you know where your app is spending its time you can add USDT probes to allow you to capture snapshots of data structures at points in time. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=3D0 From nobody Sat Feb 3 07:20:55 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRkZh29tzz58Xy1 for ; Sat, 3 Feb 2024 07:21:00 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRkZg2Ndgz4FNv for ; Sat, 3 Feb 2024 07:20:59 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=GAVPjU0g; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::332 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-40e800461baso24424735e9.3 for ; Fri, 02 Feb 2024 23:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706944856; x=1707549656; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=Tx4oM0H2YgZ6B3c221EzZGyfLa7G4nIL24kbM9B0Fho=; b=GAVPjU0gZ/D2HfK7G0JV1Q8YNt/PIEzJldLvHJvNYvyzcQpWVg5wHDkR8iyd/Zb51i jXNcCSatmisGTuNGVks5cmAxnNIxV5k4dHI0m16KoZXsBFS7MbINRibPHdF9UGmGdm47 W1nmHOM9CZ2DirKmWqUq+hlHWARdivIt5lhxQClBf3fbR1rFE3YJ0+lpY8YA+DJ/Vuu8 9wlbkS/LD/VhCI3MBVcZJdRJ09IS9LzxCjbjIkavo837lfYhW03NCwUMHcxSOvmNEhls xIzfOwEyVXtANu14Sw6223WT4nw2AQvwNd9B7PqdNQXrRmMDvdCPvAu5opc2W9mU7UfZ PCDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706944856; x=1707549656; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Tx4oM0H2YgZ6B3c221EzZGyfLa7G4nIL24kbM9B0Fho=; b=ZTW0hosla7UDLFJoCCG2Q+75AqIXJU2VP3RVTcYfn3FVoHg9DYiYkq8sOS8GtrWFlC +zcGJTXNcORXE3LH0QcHLem+g/aRdYvE8qPh2OHWhVDV+5ZTbCGPPHfOxUnOiNRA+QNj ggC1RwxxwXNAFnh+k9ti7iflqedAipiqvRMB4X+h9rIJAclxGxu4B3XBgvl0jX8UyymF knV6qglc+cMT/aSJeliRwTVVwaUzpjPMjlZt9KBTiOJePN6Y9BV3KAcUbyLmgBmahqZ0 Kl4WvTXQNrh7rddxkslVXEEp8IdynbhbWYtW8rxHl/X9NHmUDaoHpO2lvx1aZJWnyoet Ta7w== X-Gm-Message-State: AOJu0Yy/qwPzUk+TCkd8B0ifUpRnPfgnfEzDuuN8yQTKg+k2Ysn3zV2n gurwAGD52SUDjeuupq4dBoRI6vqhB7vwrP4P52LlT8TEYS7UePpg647Ew9nQ X-Google-Smtp-Source: AGHT+IHaEewdeZ7XbPeC2eIk2tKDSMRD8igKjBkvjxtIQVLyTO3/yFdan5ETP4+AutJfjxtMLe86Eg== X-Received: by 2002:a05:600c:3ca6:b0:40f:c234:1fd5 with SMTP id bg38-20020a05600c3ca600b0040fc2341fd5mr380225wmb.11.1706944856504; Fri, 02 Feb 2024 23:20:56 -0800 (PST) Received: from ?IPV6:2a01:cb15:8010:2f00:1aa9:5ff:fe16:2efb? ([2a01:cb15:8010:2f00:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id l20-20020a05600c4f1400b0040ef622799fsm1999147wmq.37.2024.02.02.23.20.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Feb 2024 23:20:56 -0800 (PST) Message-ID: <03729a10-8b55-416f-beb4-3a4275d880b7@gmail.com> Date: Sat, 3 Feb 2024 08:20:55 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Profiling applications To: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.79 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.80)[-0.796]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::332:from] X-Rspamd-Queue-Id: 4TRkZg2Ndgz4FNv On 03-02-24 01:16, Chuck Tuffli wrote: > What is the recommended way of profiling applications on FreeBSD these > days? I’m looking for information like “28% of the execution time is > spent in function X”. > > —chuck First off, you will get best results with DWARF debuginfo. If you can, build your test exe with "-g -O3" or similar. The first answer should be pmcstat. When I've used it, it didn't inspire a great amount of confidence. The wiki page https://wiki.freebsd.org/PmcTools hasn't been updated in 15 years, so I've no idea if it is still relevant. pmc and pmcstat are in base. No commits for the last 2 or 3 years, and low activity before that. Using a non-debug kernel I get lots of addr2line: dwarf_init: Debug info NULL [_dwarf_consumer_init(66)] pmcstat: WARNING: addr2line function name read error pmcstat: WARNING: addr2line pipe error messages. Still, I can get to see some measurements with it. To see sampling data 0. pkg install kcachegrind 1. kldload hwpmc 2. profile: pmcstat -P inst_retired.any_p -O /tmp/pmctest.bin -d [your command and arguments] 3. convert to callgrind format: pmcstat -R/tmp/pmctest.bin -F/tmp/pmctest.cg 4. view results: kcachegrind /tmp/pmctest.cg The next thing that I would suggest is Google perftools. You will need to install google-perftools. Roughly, you will need to link with their library (iirc LD_PRELOAD should also work), set some environment variables and then run your exe. You'll need to do some postprocessing similar to pmcstat. perftools are fairly well documented on the web. Lastly, you could try cachegrind and callgrind. They are slow, do not accurately model the cache or branch prediction and not at all speculative execution. What they measure is accurate and as close to deterministic as you can get. A+ Paul From nobody Sat Feb 3 07:27:50 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRkkd6KS1z58YHj for ; Sat, 3 Feb 2024 07:27:53 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRkkc5nlnz4GSS for ; Sat, 3 Feb 2024 07:27:52 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Tv9Ie9K9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-40fb63c40c0so24470045e9.2 for ; Fri, 02 Feb 2024 23:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706945271; x=1707550071; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=2Xru3vhgf/r2JDXRPYZWojt+NS/svzywhWZ+CjSemyg=; b=Tv9Ie9K98joThAAL+EQ8n1yd8tRQczGFmff7/eLpMBs/VaacQvsMvixgl5DgDiL/0K m/gRenTDSWgNr4qAwPDEdgxOD3Ljcn8mPNnYdH4jK+JQsqjBqZyywjK3TBnsdyIS0Eyy iQhfRvR2doQeSaw2Nu41miziKKFEDurGaEKcibMEqtqh2FwnH0/xcFbjbmhWeO73MgVx Y73tB+0zWhz7hJ0jPypvGfB+bw9xsUFWwXmSOI5hDLHIHHDSVDX1ozv+r5u/ufAoF7qw XmHBLjroIFaFGhOCUFqqE9Z140RcAc5m0sP4nhZSmLRUHSTUhWl/pb4xRhcPdCCH0OVx osag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706945271; x=1707550071; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2Xru3vhgf/r2JDXRPYZWojt+NS/svzywhWZ+CjSemyg=; b=L0qzotQDREs8vOpGdxbNK1KQ6NRJHm9bc7ecmArZc+UGfWWVANqWMhftUGTM8mWRU7 eeVmhk8R5elRBWJSmXfBPQ2JRP5hqw7nfRMoE6HYC2VQtEmZJvRrRCObamPUN3wgs8RH fq+pR3OLKQ1v9j1yeePR6CgyMjEftVjnQF9ZfyFX+phmwUlg58tRVltijaceC7QWPsHb B3Vmks+moN0UPCzk0zNlSduXia6IMRIyjdao8eR9fMmLT6jKFJiIfEluTOY1KrcADOsO ksWmVkUbecLclxFVD+Qr1/eGoqhPtwTXnG69GKrWBi4Ybm6zGcnmerwFYJ+WKtaxM36d r+AQ== X-Gm-Message-State: AOJu0Yxhd5j/ra+mh2/lUlUB/gopxEGJg7l6tDKo3QBIw4WlB3NaKGC3 OpG7Pd82iUwQat13emvZ0CLCydhih492eNuGh5zH34HB1W45D0xwnoo+QbJR X-Google-Smtp-Source: AGHT+IEQtwyWdZDQ9FfEwta4jdsZeBmhboWz237dJU5gSM9bqraQfC4UTRk+gRvkOsnAulKTIzJa8w== X-Received: by 2002:a05:600c:68c1:b0:40e:61d4:5d3b with SMTP id jd1-20020a05600c68c100b0040e61d45d3bmr458822wmb.20.1706945271256; Fri, 02 Feb 2024 23:27:51 -0800 (PST) Received: from ?IPV6:2a01:cb15:8010:2f00:1aa9:5ff:fe16:2efb? ([2a01:cb15:8010:2f00:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id p6-20020adff206000000b0033af5086c2dsm3466257wro.58.2024.02.02.23.27.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Feb 2024 23:27:50 -0800 (PST) Message-ID: Date: Sat, 3 Feb 2024 08:27:50 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Profiling applications Content-Language: en-US To: freebsd-hackers@freebsd.org References: <20240202231428.7c711308@slippy> From: Paul Floyd In-Reply-To: <20240202231428.7c711308@slippy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.81 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.82)[-0.816]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from] X-Rspamd-Queue-Id: 4TRkkc5nlnz4GSS On 03-02-24 08:14, Cy Schubert wrote: > Try DTrace. The DTrace book (if you can get your hands on it) is a good > source of information about profiling. Oracle (formerly Sun) has some > good resources. https://ekamperi.github.io/Geant4/dtrace.html may > provide some pointers. Brendan Gregg's (Brendan wrote DTrace) flame > FlameGraph is another option, though it displays hot PIDs, probably not > what you're looking for. > > The DTrace Tookit is in ports. There are some DTrace code samples there. > > Once you know where your app is spending its time you can add USDT > probes to allow you to capture snapshots of data structures at points > in time. DTrace is mostly a kernel profiling tool. Unless your code is already instrumented with USDTs it won't tell you much about your application, especially if it is CPU bound in userland. A+ Paul From nobody Sat Feb 3 07:48:32 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRlBf3LHXz58qnT for ; Sat, 3 Feb 2024 07:48:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRlBf0ZRPz4JKv for ; Sat, 3 Feb 2024 07:48:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 480FC89284; Sat, 3 Feb 2024 07:48:33 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.17.1/8.16.1) with ESMTPS id 4137mWB5030835 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 3 Feb 2024 07:48:33 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.17.1/8.16.1/Submit) id 4137mWtA030834; Sat, 3 Feb 2024 07:48:32 GMT (envelope-from phk) Message-Id: <202402030748.4137mWtA030834@critter.freebsd.dk> To: "Chuck Tuffli" cc: freebsd-hackers@freebsd.org Subject: Re: Profiling applications In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30832.1706946512.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 03 Feb 2024 07:48:32 +0000 X-Rspamd-Queue-Id: 4TRlBf0ZRPz4JKv X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] Chuck Tuffli writes: > What is the recommended way of profiling applications on FreeBSD these d= ays? > I'm looking for information like '28% of the execution time is spent in = function X'. I would start with basic-block profiling: gcov(1)/llvm-cov(1) It will not give you the /time/ spent in your functions, but it will tell you how many times each unbranched sequence of code was executed. I personally find that to be much more valuable information than time spent, because it also reveals a lot about the data being processed, average operations to find things in trees/lists etc. Here's an example of that: http://varnish-cache.org/gcov/bin/varnishd/cache/cache_esi_parse.c.html That is from the gcov which is part of Varnish Cache CI: http://varnish-cache.org/gcov/ (The python3 scripts to make HTML out of the gcov output are our own and know a lot about the Varnish source tree, but it can undoubtedly be adapted.) -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Sat Feb 3 16:19:06 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRyWw24VMz59fdC for ; Sat, 3 Feb 2024 16:19:24 +0000 (UTC) (envelope-from andrea@cocito.eu) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRyWv1rSBz4Sfw for ; Sat, 3 Feb 2024 16:19:23 +0000 (UTC) (envelope-from andrea@cocito.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cocito-eu.20230601.gappssmtp.com header.s=20230601 header.b=Ro6vzjWS; dmarc=none; spf=pass (mx1.freebsd.org: domain of andrea@cocito.eu designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=andrea@cocito.eu Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-40fd446d4cfso1793635e9.3 for ; Sat, 03 Feb 2024 08:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cocito-eu.20230601.gappssmtp.com; s=20230601; t=1706977157; x=1707581957; darn=freebsd.org; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:from:to:cc:subject:date:message-id:reply-to; bh=xV3Hn1n2FcJ15RyGtu2C0QN5ysPfSNz/L7cPthzXRGY=; b=Ro6vzjWSNcF6n+2whuHrRF/p4K4gVJW+B/mvdDVrJKerBCJzVqe7aG2ioe0S4xCPi0 S3xLmsPTaNmzVINUYm+cZIZD7oNPrXmxUrpu4mOwSRS9z3RhmrbsuvF8GM2Bl5OKt30T AaGNJF52CBaUh99o2OSVJyy4Z/+r3tGsZArs+HBOq9Ok62lHLg499tlNB4b7A4lwvi6g F+Ac5nfMlwWm/tWHp92F9vRr7qkUZZLwVlnVf89V0NDF0/SXucHQcictSgN5ldWzsynF QY3wMvK/ri7qoKXPcuOh26oNyPnQttjoDWGS4KuxW+pUogMcQc4IXzjCyUxXVXKEu1O3 eXFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706977157; x=1707581957; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xV3Hn1n2FcJ15RyGtu2C0QN5ysPfSNz/L7cPthzXRGY=; b=S7Ryp7lgvlZPtugraiB4hIq0Svv9ETfXoMYEn7xmECApN5Poo0dWONjdBaQyvQDTa4 UcqZ+2zf2Yt2CodlJOHQc5q5sjLBtgiAO8jmjSAc9Kc0APq1GtdL9WqJoxM6GQeuh+eN Ex/u1cNXAAFLoutqT/FllREifvWpT258AiRv9MjVO6TFCEYESwmUOfBeVMIseZdN8HPi 8sXnEm67DD46Bkn4oYpGsFPN4djLkBt4VNZMLnagku1mVJvcMHiJ/LabVq77e5F+Wh2c UGQJkjjorPeJ5ZTV2eOgLLGz4scVvqS3OTjaEOlvL7XUGNf6+2/i93RNuCdM1+zowAOo gc3w== X-Gm-Message-State: AOJu0YzIqhHh/jDQDkP6KWjPfiYRylFK1Jq2fokGAV12AXFRQJZ/PITc Z0lueYCtXXSnUg3dFAmUv2JbNM1D1RWNhfVVqE2lZl+7aQGlyPsuFZMgZBZlcI7W5GoamavtRWf q X-Google-Smtp-Source: AGHT+IFbIU2S+zpGPegvotnYN1Y5uHhaUw0JMQP5kwEvqTAA8E1NKx6NOR76nuZeaEdIbMCiggaNYw== X-Received: by 2002:a05:600c:198a:b0:40e:7232:bdf9 with SMTP id t10-20020a05600c198a00b0040e7232bdf9mr1232391wmq.16.1706977157386; Sat, 03 Feb 2024 08:19:17 -0800 (PST) Received: from smtpclient.apple ([185.8.198.100]) by smtp.gmail.com with ESMTPSA id l10-20020a5d410a000000b0033af5716a7fsm4308101wrp.61.2024.02.03.08.19.16 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Feb 2024 08:19:17 -0800 (PST) From: Andrea Cocito Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: TPM2 on AMD Rizen (fTPM) Message-Id: Date: Sat, 3 Feb 2024 17:19:06 +0100 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cocito-eu.20230601.gappssmtp.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[cocito.eu]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[cocito-eu.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4TRyWv1rSBz4Sfw Hi, I=E2=80=99m trying to enable TPM support on a box in order to experiment = a bit with it, but the driver does not seem to load and/or see the = device. In the firmware the =E2=80=9CfTPM=E2=80=9D option has been enabled, = tried both with SCM enabled and disabled, basically I tried all the = possible firmware options combinations with no success. I have tpm_load=3D=E2=80=9CYES=E2=80=9D in /boot/loader.conf and also = tried the hints suggested by the man page is /boot/device.hints No way to have the tpm? device(s) appear, the best I achieved so far on = dmesg in a verbose boot is: =E2=80=A6 Preloaded elf obj module "/boot/kernel.old/geom_mirror.ko" at = 0xffffffff8196d8c0. Preloaded elf obj module "/boot/kernel.old/tpm.ko" at = 0xffffffff8196dfb0. =E2=80=A6 tpm0 failed to probe at iomem 0xfffffffffed40000-0xfffffffffed44fff on = isa0 tpm1 failed to probe at iomem 0xfffffffffed40000-0xfffffffffed40fff on = isa0 =E2=80=A6 I am all but an expert about TPM architecture (this is why I am willing = to play with it), but as far as I understand AMD=E2=80=99s fTPM is a = TPM2 built into the CPU, I have no idea on which bus it should be seen = and how. So my questions are: - Is AMD=E2=80=99s fTPM supported at all by the driver? - Am I missing something very obvious? I have been digging around for information quite a bit, but there does = not seem to be much information around. Hope I am hitting the correct = list (accept my apologies if it is not). Thanks in advance for any advice.= From nobody Sun Feb 4 03:06:07 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TSDtR299nz592Bc for ; Sun, 4 Feb 2024 03:06:23 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSDtR1cVVz4lnc for ; Sun, 4 Feb 2024 03:06:23 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707015983; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ZvDY/MQQTbjqBNwfZrnxVw5jjm4prUw8fPgzhNvJ5VA=; b=QN160xegvPC+dKWk7y/evL/7a/gpltodlL3R1A1Cr1bSpZiMsFYEbel6V1tzJXlRVEbPK+ VUpaZN3cqeS9FeVQvjEDNxj/+bJWLNYfyv6ulUjz9T2xFTKq1+0H4J7RS+hRdFiJ2/Ksm4 kzMWS0gAY1nkUDpXx8o+kv9RGwza/0Id0tL2j8NVQId+JPWuSbsKkBocHS357+dO7fi3Qy GFxJR+OMGFosZPO/hdam7Tz3WrxUOhTnMThDMBkP6atWhHQSX3uQLXN2Yob5BmGAp7dS6M B3Y7+8c37xq+X26tHW02JRIkHb04d9/42UakaHFfHFWOIFHSCN+pLFTDkXPkVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707015983; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ZvDY/MQQTbjqBNwfZrnxVw5jjm4prUw8fPgzhNvJ5VA=; b=DmHHc6v7NK6om0nh5FqMEewI/HgM51QE6lAwZxwLpKJiIZOFrWwnXw1qgWDxK9s/S7i0TU amQuW+256Zgy+LymIbR1M+8anVbGOLHCN8dVSlFYDl+oBpKLbD1uubiQ5AtGvK0koyG5gy OUZX9QMePoncqIr322CIViQE986TNWfscm4ppsBp8Q6YMQPPdJQiYaoThGJXlxex8ZEx1v +K+McJBSDabnzZaNaxjtcgcdOZWyfhh1zu0gxu6dCaUD0XC9ieLhyW6aP1JxlUAXzS4KH7 PmmrMNk0OAR3jZHt0NHrZX6ELdZ2WR6jEAcYd3tGMHeh/drUhh9DeCG81kDYIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707015983; a=rsa-sha256; cv=none; b=NqkR73QwsuE2v6vAvuBlxcJs/tdajehC3p223vIsWTD4cps0m5dyggCW5vweb9MPvGdmPS 4UB0vJu8kiUPeQ9FzFhaAkkyq14I+iS/pjcF2h5toXJnv6xrcGd4POmZjMzI12fJdmAeq2 LwpVHULU5TNsPbF+dxaFIJ2q0QG3iiHi3n8kl7r4RzWYYh3WA9x9lODcbnItDCyP8wJwyb C62x7Opy0TmZ2NPhNU9Sz4MKK2GdPqgEsjjFzdjXXk0K/ct4kOioOC7oHzKn+f4/Dq46Uy BkHsJdw6yArsiKpf1uCTuhTHLaxz1tHBM41ubpGTKthswujzwDs9ZVEZ/EcMjw== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:ab1b:6800:2e0:edff:fece:8f27]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TSDtP42vLzK65 for ; Sun, 4 Feb 2024 03:06:21 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: <1f477b47-6a8e-4e32-889e-7f0788132953@freebsd.org> Date: Sat, 3 Feb 2024 19:06:07 -0800 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Craig Leres To: freebsd-hackers@freebsd.org Subject: portconfig vs xterm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I was trying to give 13.3-BETA1 a legit tryout and ended up spending hours fighting with portconfig. In my experience it does not play well with xterm. Function and arrow keys are no-ops and unlike dialog4ports it does not allow navigation with ^P/^N. Given that that my TERM is set to xterm when I login to the *console* of my newly installed 13.3 system (as when I ssh in from my FreeBSD desktop) how can my user experience be so terrible? I eventually figured out I could go back by adding: DIALOG=/usr/local/bin/dialog4ports to /etc/make.conf. Have a I managed to overlook a subtle clue somewhere? Similarity, I jave been hitting this on my 13.2 build server and today figured out the poudriere itself had a dependency on portconfig. Good luck using portconfig to change the option that controls this though. (In the end I used my windows laptop which identifies as a vt220 to ssh in -- so I didn't have to resort to editing the options file with vi...) Craig From nobody Sun Feb 4 13:43:03 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TSW1N08XBz59nhh for ; Sun, 4 Feb 2024 13:43:20 +0000 (UTC) (envelope-from andrea@cocito.eu) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSW1M18mwz4WYj for ; Sun, 4 Feb 2024 13:43:18 +0000 (UTC) (envelope-from andrea@cocito.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cocito-eu.20230601.gappssmtp.com header.s=20230601 header.b=kOtbCNPk; dmarc=none; spf=pass (mx1.freebsd.org: domain of andrea@cocito.eu designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=andrea@cocito.eu Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-40fd446d4ceso6694515e9.2 for ; Sun, 04 Feb 2024 05:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cocito-eu.20230601.gappssmtp.com; s=20230601; t=1707054195; x=1707658995; darn=freebsd.org; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=/me2u4EpBighIKaR0GIMISRg9CX6NvmWp/w2Jd2Vs88=; b=kOtbCNPkm86BBW3Jh9TCPs4aC44newFQyUV3xheW1gyw+u10dO0sRfwip5jsCc1LnA 0PcoX7m0eaZTOknnNClGagkUhPSF4nIAYUEC6x+K+EhP40BaYgC8x2Lcn7kdmuMJWxUy Upk+tXqpu32OCnvZKyPETHwBVuI5xpKZQBvlr8o/O5mosEK8MRfKAo7hWkqj23rSV3iN fHArtdOL6wMYmnGvR4dE8uJPL4BA0yjp9DMXxFF2OC/yKYA606Jk3Wsa/IV1Io6yvDMQ cQjqP03lLo5V+BOc2zZMN0rM6RbahqP2KGV3bLB1OSflMMoLdln/1A+6ysJSG99abWQp S7Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707054195; x=1707658995; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/me2u4EpBighIKaR0GIMISRg9CX6NvmWp/w2Jd2Vs88=; b=OjX5MsQr0MF/jn9ThjAED7QcKs0eImoASjZnkvlT8z6/TWaaP1UKG0NMQAY84zf9Az xPuuhe19c6843bktqKx9zcRy5d3HqC3bM3FAimZnpXtwXNYvBjh+bSKbtBBSPaWVJsGY KrXx23UkH4ZhOklS+a8o4rT51iJdMz+ob272DSbq+ulWhfaQOQsZ0I1aE2vDEx/oD+gX s4ieGp2dOHvq5pncUkpjjA+unnMfCcCeXSaJuChClzQslmd1dwQqNlMS3S2sEyCNtCM6 ZI2/4L05b1XbKxG6KzTmVOanap6K3Xfxcdzn2D+K4JpmqPGoWkOywKrAg+V+6ZVZtiaU Pu0g== X-Gm-Message-State: AOJu0YwlcoKWmJoJ403qzqZCnCbJB0IP5i3WBBsT7tkc4ix+5ZTEVQSD HVtBDqTxEPdDCYAB+YHCk6+ppxIasEUELLEVzixOlX89ElImajcJt1W/QiJCobIxs9WAxB2BEdI D X-Google-Smtp-Source: AGHT+IFfAJ3aG2rlW3ufvjgx8TH65axuXJnNnwTVgnLdteaVNj9JceSSye2hu1zUIAKQVMvmeJ1g8g== X-Received: by 2002:a05:600c:3d9b:b0:40e:f5d0:8517 with SMTP id bi27-20020a05600c3d9b00b0040ef5d08517mr2738387wmb.33.1707054194672; Sun, 04 Feb 2024 05:43:14 -0800 (PST) Received: from smtpclient.apple ([185.8.198.100]) by smtp.gmail.com with ESMTPSA id fs11-20020a05600c3f8b00b0040fb783ad93sm5735193wmb.48.2024.02.04.05.43.13 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2024 05:43:14 -0800 (PST) From: Andrea Cocito Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: TPM2 on AMD Rizen (fTPM) Date: Sun, 4 Feb 2024 14:43:03 +0100 References: <51A26E14-9374-4B1A-9DA1-A9E2A2B4E2EA@cocito.eu> To: freebsd-hackers@freebsd.org In-Reply-To: <51A26E14-9374-4B1A-9DA1-A9E2A2B4E2EA@cocito.eu> Message-Id: <71AF606D-1685-43E5-9455-E1882EAECE96@cocito.eu> X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cocito-eu.20230601.gappssmtp.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[cocito.eu]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[cocito-eu.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4TSW1M18mwz4WYj Hello again, First thing: apologies for my email client messing up with charset = encoding, hope is fixed now. Second, I add some detail/information. The machine is a bare metal on Hetzner, I do not have many details, = it=E2=80=99s an AMD Ryzen 9 3900 12-Core/24-Threads toy with some = motherboard using American Megatrends firmware; unfortunately I have = very limited access to the console (one hour upon request=E2=80=A6). As said the =E2=80=9CfTPM=E2=80=9D has been enabled in the firmare, and = I also tried all the possible combinations of the settings in the = firmware which could seem anyhow pertinent (SCM etc). The kernel is a custom-built one, simply stripped down to include = statically all used devices/modules and drop the rest, compiled with = -march=3Dnative as all the userland; no problem in rebooting with the = GENERIC kernel, but I cannot imagine how it could help. Should any additional information be useful to give me some advice just = ask, the machine is there to experiment. Thanks for any advice, A. > On 3 Feb 2024, at 18:21, Andrea Cocito wrote: >=20 > Hi, >=20 > I=E2=80=99m trying to enable TPM support on a box in order to = experiment a bit with it, but the driver does not seem to load and/or = see the device. >=20 > In the firmware the =E2=80=9CfTPM=E2=80=9D option has been enabled, = tried both with SCM enabled and disabled, basically I tried all the = possible firmware options combinations with no success. >=20 > I have tpm_load=3D=E2=80=9CYES=E2=80=9D in /boot/loader.conf and also = tried the hints suggested by the man page is /boot/device.hints >=20 > No way to have the tpm? device(s) appear, the best I achieved so far = on dmesg in a verbose boot is: > =E2=80=A6 > Preloaded elf obj module "/boot/kernel.old/geom_mirror.ko" at = 0xffffffff8196d8c0. > Preloaded elf obj module "/boot/kernel.old/tpm.ko" at = 0xffffffff8196dfb0. > =E2=80=A6 > tpm0 failed to probe at iomem 0xfffffffffed40000-0xfffffffffed44fff on = isa0 > tpm1 failed to probe at iomem 0xfffffffffed40000-0xfffffffffed40fff on = isa0 > =E2=80=A6 >=20 > I am all but an expert about TPM architecture (this is why I am = willing to play with it), but as far as I understand AMD=E2=80=99s fTPM = is a TPM2 built into the CPU, I have no idea on which bus it should be = seen and how. >=20 > So my questions are: > - Is AMD=E2=80=99s fTPM supported at all by the driver? > - Am I missing something very obvious? >=20 > I have been digging around for information quite a bit, but there does = not seem to be much information around. Hope I am hitting the correct = list (accept my apologies if it is not). >=20 > Thanks in advance for any advice. From nobody Sun Feb 4 15:13:33 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TSY1d076Nz59w74 for ; Sun, 4 Feb 2024 15:13:41 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from smtp-bc08.mail.infomaniak.ch (smtp-bc08.mail.infomaniak.ch [IPv6:2001:1600:4:17::bc08]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "relay.mail.infomaniak.ch", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSY1c4tGhz4f7N for ; Sun, 4 Feb 2024 15:13:40 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Authentication-Results: mx1.freebsd.org; none Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4TSY1V0t3SzMpvhZ; Sun, 4 Feb 2024 16:13:34 +0100 (CET) Received: from unknown by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4TSY1T52V2zMpnPg; Sun, 4 Feb 2024 16:13:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pyret.net; s=20231006; t=1707059614; bh=s3aN2c1LQIWRFmGYSVm1ZB8LhijFVK453obssNYA/e0=; h=Date:Subject:From:Reply-To:To:Cc:References:In-Reply-To:From; b=SJ0Uem2dncLVvxyxZCEXvukWfDeobV7Km49UQztuqqE94u22XAf88JlQUcIgIe/qT k4PzKoPQFgInDsQsKOuZ/z+9F8vRp7JxOGE3J43JGZeyyi2XxfqBn4AS1VLZ8DJONZ BHvWkf94Pd0QU0WqfY/Hy2p0VI9y7LZUVPfn+0oFngCZTblY6Mknd7zsWSXN37urSM QbvWITE7LgACJsJv/mAq/RrRtzG9tnR+loRW+VpS9h7PM8rGFwG7LGbEqjzjH00y0m 0XPwtC2D5+gISxKaU7QdqaXaN0Crngf7P1vi4bY3h7fUB9In93eN1+n4YsaRNz1SQC A90Vn7W8BqU7g== Message-ID: Date: Sun, 04 Feb 2024 16:13:33 +0100 Subject: Re: TPM2 on AMD Rizen (fTPM) From: Daniel Engberg Reply-To: Daniel Engberg To: Andrea Cocito Cc: freebsd-hackers@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_=_swift_1707059613_aa21c9bd060e13e37561d897574558a8_=_" X-WS-User-Origin: eyJpdiI6IjRzOXJybGxoOUJ1QjVGbDRYb0hQeFE9PSIsInZhbHVlIjoiV2x2dkJSb1JCdlR6WFZkc3A0Q1JiQT09IiwibWFjIjoiNjEwNDIwOTVkZmZlOTg1YjAwYzFmODAxYjJmZDMyNzZiMzhiZDA4YTMxMzA2MWQzYmRiYmIxN2IyOTFiZTk4NCIsInRhZyI6IiJ9 X-WS-User-Mbox: eyJpdiI6InpWQWxoSjV6U1hjWDhyUE9iK1VvcUE9PSIsInZhbHVlIjoiQVNrZlQ2OWhrcEpzdTZDOEdEUXM2dz09IiwibWFjIjoiMDQyMGYxODgyYmExNThlNTU0YTQ1NjJkYTJiYjc1MDAwZTYwYTc3ZGE1N2UzNTQ0MjY3NmFlOTBhZTYzYzJkMCIsInRhZyI6IiJ9 X-WS-Location: eJxzKUpMKykGAAfpAmU- X-Mailer: Infomaniak Workspace (1.3.633) References: <51A26E14-9374-4B1A-9DA1-A9E2A2B4E2EA@cocito.eu> <71AF606D-1685-43E5-9455-E1882EAECE96@cocito.eu> In-Reply-To: <71AF606D-1685-43E5-9455-E1882EAECE96@cocito.eu> X-Infomaniak-Routing: alpha X-Rspamd-Queue-Id: 4TSY1c4tGhz4f7N X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29222, ipnet:2001:1600::/32, country:CH] --_=_swift_1707059613_aa21c9bd060e13e37561d897574558a8_=_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Given the commit history I don't think it's supported yet. ht= tps://cgit.freebsd.org/src/log/sys/dev/tpm Best regards, Daniel= On 2024-02-04T14:43:03.000+01:00, Andrea Cocito = wrote: >=C2=A0Hello=C2=A0again, >=C2=A0 >=C2=A0First=C2=A0thing:= =C2=A0apologies=C2=A0for=C2=A0my=C2=A0email=C2=A0client=C2=A0messing=C2= =A0up=C2=A0with=C2=A0charset=C2=A0encoding,=C2=A0hope=C2=A0is=C2=A0fixed= =C2=A0now. >=C2=A0 >=C2=A0Second,=C2=A0I=C2=A0add=C2=A0some=C2=A0detail= /information. >=C2=A0 >=C2=A0The=C2=A0machine=C2=A0is=C2=A0a=C2=A0bare= =C2=A0metal=C2=A0on=C2=A0Hetzner,=C2=A0I=C2=A0do=C2=A0not=C2=A0have=C2= =A0many=C2=A0details,=C2=A0it=E2=80=99s=C2=A0an=C2=A0AMD=C2=A0Ryzen=C2= =A09=C2=A03900=C2=A012-Core/24-Threads=C2=A0toy=C2=A0with=C2=A0some=C2= =A0motherboard=C2=A0using=C2=A0American=C2=A0Megatrends=C2=A0firmware;= =C2=A0unfortunately=C2=A0I=C2=A0have=C2=A0very=C2=A0limited=C2=A0access= =C2=A0to=C2=A0the=C2=A0console=C2=A0(one=C2=A0hour=C2=A0upon=C2=A0request= =E2=80=A6). >=C2=A0 >=C2=A0As=C2=A0said=C2=A0the=C2=A0=E2=80=9CfTPM= =E2=80=9D=C2=A0has=C2=A0been=C2=A0enabled=C2=A0in=C2=A0the=C2=A0firmare,= =C2=A0and=C2=A0I=C2=A0also=C2=A0tried=C2=A0all=C2=A0the=C2=A0possible=C2= =A0combinations=C2=A0of=C2=A0the=C2=A0settings=C2=A0in=C2=A0the=C2=A0firmwa= re=C2=A0which=C2=A0could=C2=A0seem=C2=A0anyhow=C2=A0pertinent=C2=A0(SCM= =C2=A0etc). >=C2=A0 >=C2=A0The=C2=A0kernel=C2=A0is=C2=A0a=C2=A0custom-b= uilt=C2=A0one,=C2=A0simply=C2=A0stripped=C2=A0down=C2=A0to=C2=A0include= =C2=A0statically=C2=A0all=C2=A0used=C2=A0devices/modules=C2=A0and=C2=A0drop= =C2=A0the=C2=A0rest,=C2=A0compiled=C2=A0with=C2=A0-march=3Dnative=C2=A0as= =C2=A0all=C2=A0the=C2=A0userland;=C2=A0no=C2=A0problem=C2=A0in=C2=A0rebooti= ng=C2=A0with=C2=A0the=C2=A0GENERIC=C2=A0kernel,=C2=A0but=C2=A0I=C2=A0cannot= =C2=A0imagine=C2=A0how=C2=A0it=C2=A0could=C2=A0help. >=C2=A0 >=C2=A0Sho= uld=C2=A0any=C2=A0additional=C2=A0information=C2=A0be=C2=A0useful=C2=A0to= =C2=A0give=C2=A0me=C2=A0some=C2=A0advice=C2=A0just=C2=A0ask,=C2=A0the=C2= =A0machine=C2=A0is=C2=A0there=C2=A0to=C2=A0experiment. >=C2=A0 >=C2= =A0Thanks=C2=A0for=C2=A0any=C2=A0advice, >=C2=A0 >=C2=A0A. >=C2=A0 = >>=C2=A0=C2=A0On=C2=A03=C2=A0Feb=C2=A02024,=C2=A0at=C2=A018:21,=C2=A0Andrea= =C2=A0Cocito=C2=A0=C2=A0wrote: >>=C2=A0=C2=A0 >>= =C2=A0=C2=A0=C2=A0Hi, >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0I=E2=80=99m= =C2=A0trying=C2=A0to=C2=A0enable=C2=A0TPM=C2=A0support=C2=A0on=C2=A0a=C2= =A0box=C2=A0in=C2=A0order=C2=A0to >>=C2=A0=C2=A0experiment=C2=A0a=C2= =A0bit=C2=A0with=C2=A0it,=C2=A0but=C2=A0the=C2=A0driver=C2=A0does=C2=A0not= =C2=A0seem=C2=A0to=C2=A0load >>=C2=A0=C2=A0and/or=C2=A0see=C2=A0the=C2= =A0device. >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0In=C2=A0the=C2=A0firmware= =C2=A0the=C2=A0=E2=80=9CfTPM=E2=80=9D=C2=A0option=C2=A0has=C2=A0been=C2= =A0enabled,=C2=A0tried >>=C2=A0=C2=A0both=C2=A0with=C2=A0SCM=C2=A0enabled= =C2=A0and=C2=A0disabled,=C2=A0basically=C2=A0I=C2=A0tried=C2=A0all=C2=A0the= >>=C2=A0=C2=A0possible=C2=A0firmware=C2=A0options=C2=A0combinations= =C2=A0with=C2=A0no=C2=A0success. >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0I= =C2=A0have=C2=A0tpm_load=3D=E2=80=9CYES=E2=80=9D=C2=A0in=C2=A0/boot/loader.= conf=C2=A0and=C2=A0also=C2=A0tried=C2=A0the >>=C2=A0=C2=A0hints=C2=A0sugg= ested=C2=A0by=C2=A0the=C2=A0man=C2=A0page=C2=A0is=C2=A0/boot/device.hints= >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0No=C2=A0way=C2=A0to=C2=A0have=C2= =A0the=C2=A0tpm?=C2=A0device(s)=C2=A0appear,=C2=A0the=C2=A0best=C2=A0I= =C2=A0achieved=C2=A0so >>=C2=A0=C2=A0far=C2=A0on=C2=A0dmesg=C2=A0in=C2= =A0a=C2=A0verbose=C2=A0boot=C2=A0is: >>=C2=A0=C2=A0 >>=C2=A0=C2=A0= =C2=A0=E2=80=A6 >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0Preloaded=C2=A0elf= =C2=A0obj=C2=A0module=C2=A0"/boot/kernel.old/geom_mirror.ko"=C2=A0at >>= =C2=A0=C2=A00xffffffff8196d8c0. >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0Prel= oaded=C2=A0elf=C2=A0obj=C2=A0module=C2=A0"/boot/kernel.old/tpm.ko"=C2=A0at= >>=C2=A0=C2=A00xffffffff8196dfb0. >>=C2=A0=C2=A0 >>=C2=A0=C2=A0= =C2=A0=E2=80=A6 >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0tpm0=C2=A0failed= =C2=A0to=C2=A0probe=C2=A0at=C2=A0iomem >>=C2=A0=C2=A00xfffffffffed40000-0= xfffffffffed44fff=C2=A0on=C2=A0isa0 >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2= =A0tpm1=C2=A0failed=C2=A0to=C2=A0probe=C2=A0at=C2=A0iomem >>=C2=A0=C2= =A00xfffffffffed40000-0xfffffffffed40fff=C2=A0on=C2=A0isa0 >>=C2=A0=C2= =A0 >>=C2=A0=C2=A0=C2=A0=E2=80=A6 >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2= =A0I=C2=A0am=C2=A0all=C2=A0but=C2=A0an=C2=A0expert=C2=A0about=C2=A0TPM= =C2=A0architecture=C2=A0(this=C2=A0is=C2=A0why=C2=A0I=C2=A0am >>=C2=A0= =C2=A0willing=C2=A0to=C2=A0play=C2=A0with=C2=A0it),=C2=A0but=C2=A0as=C2= =A0far=C2=A0as=C2=A0I=C2=A0understand=C2=A0AMD=E2=80=99s=C2=A0fTPM >>= =C2=A0=C2=A0is=C2=A0a=C2=A0TPM2=C2=A0built=C2=A0into=C2=A0the=C2=A0CPU,= =C2=A0I=C2=A0have=C2=A0no=C2=A0idea=C2=A0on=C2=A0which=C2=A0bus=C2=A0it >= >=C2=A0=C2=A0should=C2=A0be=C2=A0seen=C2=A0and=C2=A0how. >>=C2=A0=C2= =A0 >>=C2=A0=C2=A0=C2=A0So=C2=A0my=C2=A0questions=C2=A0are: >>=C2=A0= =C2=A0 >>=C2=A0=C2=A0=C2=A0-=C2=A0Is=C2=A0AMD=E2=80=99s=C2=A0fTPM=C2= =A0supported=C2=A0at=C2=A0all=C2=A0by=C2=A0the=C2=A0driver? >>=C2=A0= =C2=A0 >>=C2=A0=C2=A0=C2=A0-=C2=A0Am=C2=A0I=C2=A0missing=C2=A0something= =C2=A0very=C2=A0obvious? >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0I=C2=A0have= =C2=A0been=C2=A0digging=C2=A0around=C2=A0for=C2=A0information=C2=A0quite= =C2=A0a=C2=A0bit,=C2=A0but=C2=A0there >>=C2=A0=C2=A0does=C2=A0not=C2= =A0seem=C2=A0to=C2=A0be=C2=A0much=C2=A0information=C2=A0around.=C2=A0Hope= =C2=A0I=C2=A0am=C2=A0hitting=C2=A0the >>=C2=A0=C2=A0correct=C2=A0list= =C2=A0(accept=C2=A0my=C2=A0apologies=C2=A0if=C2=A0it=C2=A0is=C2=A0not). >= >=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0Thanks=C2=A0in=C2=A0advance=C2=A0for= =C2=A0any=C2=A0advice. --_=_swift_1707059613_aa21c9bd060e13e37561d897574558a8_=_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

Given the commit history I don't thin= k it's supported yet.
<= br>
Best regards,
Daniel


=
On 2024-02-04T14:43:03.000+01:00, Andrea Cocito <andrea@cocito.eu&g= t; wrote:
Hello again,

First thing: a=
pologies for my email client messing up with charset encoding, hope is fixe=
d now.

Second, I add some detail/information.<=
br>

The machine is a bare metal on Hetzner, I do n=
ot have many details, it=E2=80=99s an AMD Ryzen 9 3900 12-Core/24-Threads t=
oy with some motherboard using American Megatrends firmware; unfortunately =
I have very limited access to the console (one hour upon request=E2=80=
=A6).

As said the =E2=80=9CfTPM=E2=80=9D has b=
een enabled in the firmare, and I also tried all the possible combinations =
of the settings in the firmware which could seem anyhow pertinent (SCM etc)=
.

The kernel is a custom-built one, simply str=
ipped down to include statically all used devices/modules and drop the rest=
, compiled with -march=3Dnative as all the userland; no problem in rebootin=
g with the GENERIC kernel, but I cannot imagine how it could help.

Should any additional information be useful to give me=
 some advice just ask, the machine is there to experiment.
Thanks for any advice,

A.


  On=
 3 Feb 2024, at 18:21, Andrea Cocito <andrea@cocito.eu> wrote:
=
 
 Hi,
 
 I=E2=80=99m trying to e=
nable TPM support on a box in order to experiment a bit with it, but the dr=
iver does not seem to load and/or see the device.
 
=

 In the firmware the =E2=80=9CfTPM=E2=80=9D option has been enabled, t=
ried both with SCM enabled and disabled, basically I tried all the possible=
 firmware options combinations with no success.
 
 I have tpm_load=3D=E2=80=9CYES=E2=80=9D in /boot/loader.conf and also t=
ried the hints suggested by the man page is /boot/device.hints
 
 No way to have the tpm? device(s) appear, the best I ach=
ieved so far on dmesg in a verbose boot is:
 =E2=80=A6
 Preloaded elf obj module "/boot/kernel.old/geom_mirror.ko" at 0xff=
ffffff8196d8c0.
 Preloaded elf obj module "/boot/kernel.old/t=
pm.ko" at 0xffffffff8196dfb0.
 =E2=80=A6
 tpm0 =
failed to probe at iomem 0xfffffffffed40000-0xfffffffffed44fff on isa0
<=
/div>
 tpm1 failed to probe at iomem 0xfffffffffed40000-0xfffffffffed40=
fff on isa0
 =E2=80=A6
 
 I am al=
l but an expert about TPM architecture (this is why I am willing to play wi=
th it), but as far as I understand AMD=E2=80=99s fTPM is a TPM2 built into =
the CPU, I have no idea on which bus it should be seen and how.
 
 So my questions are:
 - Is AMD=E2=80=
=99s fTPM supported at all by the driver?
 - Am I missing som=
ething very obvious?
 
 I have been digging aro=
und for information quite a bit, but there does not seem to be much informa=
tion around. Hope I am hitting the correct list (accept my apologies if it =
is not).
 
 Thanks in advance for any advice.

--_=_swift_1707059613_aa21c9bd060e13e37561d897574558a8_=_-- From nobody Sun Feb 4 19:02:38 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TSf5z0vybz58bJ5 for ; Sun, 4 Feb 2024 19:02:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSf5x6MnYz41yg for ; Sun, 4 Feb 2024 19:02:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=troutmask.apl.washington.edu header.s=troutmask header.b="EEZeAm/r"; dmarc=fail reason="No valid SPF" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 414J2cDO026353 for ; Sun, 4 Feb 2024 11:02:38 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 414J2cDO026353 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1707073358; bh=d33F0VyXMs40/3MF91tYDUjWIHF5nRsCdriU0Nf4Ft8=; h=Date:From:To:Subject:Reply-To:From; b=EEZeAm/r1vZzTjorlHDY1L5LIo7gf5ZhOJleOYIKgFEo2T0rVugN5EoPLwGgAfH7z KeCurRfZHDmASu17GlsofyPjOrYWraT+3/KN/DfJI696qJkeWldO3nHKFsgKLsxsJl lHdIpENHyIvNZlQ9SRMAPWZevIloPY+TGXEd3QQxGbSCpQGt3Uz4VbXHEp+DcpUKGP OoJEf7rV63Mfzx/Pg8ZQ5oSQEXyao26Lxr0vUpp4bAXGkqYRNAnPaOTOQAgIZkZUNZ 4DUPL+54pzyH5Csp+0UQxMBJ3KUJMRQzebl8A1/CpSdP4Lap1muVA3nUrZG1IzhR4K muUcTGgIaEdsg== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 414J2cIW026352 for freebsd-hackers@freebsd.org; Sun, 4 Feb 2024 11:02:38 -0800 (PST) (envelope-from sgk) Date: Sun, 4 Feb 2024 11:02:38 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: GPU programming? Message-ID: Reply-To: sgk@troutmask.apl.washington.edu List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Bar: / X-Spamd-Result: default: False [-0.52 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_SPAM_LONG(0.47)[0.474]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF,none]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; R_DKIM_PERMFAIL(0.00)[troutmask.apl.washington.edu:s=troutmask]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[troutmask.apl.washington.edu:~] X-Rspamd-Queue-Id: 4TSf5x6MnYz41yg Is anyone aware of work towards GPU programming on FreeBSD? Here, I am not interested in using a GPU while playing a video game or rendering graphics on a video monitor. I'm interested in offloading single and double precision floating-point computations to a GPU via OpenACC or OpenMP (ala HPC). Although using a high-end AMD Instinct MI300 would be great, I'm looking for something a bit more affordable such as an AMD RX 6700 XT. AFAICT, this may require either porting AMD ROCm software to FreeBSD or running it under the linuxlator. https://www.amd.com/en/products/software/rocm.html -- Steve From nobody Sun Feb 4 20:16:05 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TSglK5G1nz58jS3 for ; Sun, 4 Feb 2024 20:16:45 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSglK3Yf3z47y2 for ; Sun, 4 Feb 2024 20:16:45 +0000 (UTC) (envelope-from estrabd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-51117bfd452so6288977e87.3 for ; Sun, 04 Feb 2024 12:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707077803; x=1707682603; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AhN+8fjcTVoFiWLmgBmIHWCWdnbGcbSlKyYemWYa8sw=; b=myuTKe304s8TFfUUrHDt7H+Go7o77blDzPmLuLu2oI11XfupdlMjsnRVMDM19Ge2WM HPr0hddBkgYnR6PoUlxMGv0LVuYFqjQht2ZAYPX+iitmh+OyemD6jOLkAMveiM8LMDpf t+YSHPG4pgvYjVn20X9He2ca5p43w117n2gQhM+p+oXCOUbl73NAUtqvaiwSUtxp9szR lft9Fa2tNh1cmE3jPY/gOuwtDmSx2kflgaMBFJKqr7Pgf/KQkKvQsD8t44025L3VbuyY dL0/yhQl0xHZG3q72Lvq4bifpgkmqGstNtNvRkQrHVQ3+imCYFwjZPxG/6VK3d+nwiMc 2a2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707077803; x=1707682603; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AhN+8fjcTVoFiWLmgBmIHWCWdnbGcbSlKyYemWYa8sw=; b=uAbAvTmX5MnIGHYj8kovAu/pB/WAZsLpv7rXGdUh53E1hegRSi8t8vyKbDiSx0ioc/ Zxf5EgJsuazvE0ArqZ9j96eZ3ckj+jTmlLT+6nJouh6jMi2mPpAuHWuscWjwk5g+qSjt tEN765RnGSR1tnRAIYJ2kZvP3O93LM7mf292JISuiRMv0DF+K3j7srt4qaPGIysX1SVv Da+jqXccNpHFYfOFPXhAKEfUshhyZMu4SWi6OQ0lzMAV97XUINRbc2C53XEkRTHc71FU o/d9MxLtd5+U2Y1dBq+EqLDXeHPouqfsPnFPAavy7+DOLjD6Fb2Kgr9LfojOp89IF5TY 2sCw== X-Gm-Message-State: AOJu0Yxy/kGr2/kbEc8isUd81H2V20usMWJYraa/ESg0AlFKJsPHXX/g EEFOZZEKZmMSopka0xDGMkncz+9kfmpftN3F28EMtF0AcLMPd31LeQ2qZBmzaUz+RncYmlEeaLt 8h+J2yul3C7M39NGqTyfNXvIHWksySH89 X-Google-Smtp-Source: AGHT+IF3MhMEbePypqMjtaeb1i1s2gPVuBCjKSmvDRG/L0mXLcQd4/HEsa1Ff5a3TdVaqYrCocl62nv7dEhDnQ1J3JU= X-Received: by 2002:a05:6512:239a:b0:511:4752:fbb8 with SMTP id c26-20020a056512239a00b005114752fbb8mr3134581lfv.37.1707077802308; Sun, 04 Feb 2024 12:16:42 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: "B. E." Date: Sun, 4 Feb 2024 14:16:05 -0600 Message-ID: Subject: Re: GPU programming? To: sgk@troutmask.apl.washington.edu Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000002ba560610940672" X-Rspamd-Queue-Id: 4TSglK3Yf3z47y2 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000002ba560610940672 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable gcc (and gfortran) has supported OpenMP for a very long time via their GOMP (pthreads underneath), not sure about LLVM based support or offloading (via the latest supported OpenMP specification) to accelerators on FreeBSD per se. What are you looking for in terms of OS support? Cheers, Brett On Sun, Feb 4, 2024 at 1:02=E2=80=AFPM Steve Kargl wrote: > Is anyone aware of work towards GPU programming on FreeBSD? > > Here, I am not interested in using a GPU while playing a > video game or rendering graphics on a video monitor. I'm > interested in offloading single and double precision > floating-point computations to a GPU via OpenACC or OpenMP > (ala HPC). > > Although using a high-end AMD Instinct MI300 would be great, > I'm looking for something a bit more affordable such as an > AMD RX 6700 XT. AFAICT, this may require either porting > AMD ROCm software to FreeBSD or running it under the > linuxlator. > > https://www.amd.com/en/products/software/rocm.html > > -- > Steve > > --00000000000002ba560610940672 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
gcc (and gfortran) has supported OpenMP for a very long ti= me via their GOMP (pthreads underneath), not sure about LLVM based support = or offloading (via the latest supported OpenMP specification) to accelerato= rs on FreeBSD per se. What are you looking for in terms of OS support?
=
Cheers,
Brett

On Sun, Feb 4, 2024 at 1:02=E2= =80=AFPM Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
Is anyone aware of work= towards GPU programming on FreeBSD?

Here, I am not interested in using a GPU while playing a
video game or rendering graphics on a video monitor.=C2=A0 I'm
interested in offloading single and double precision
floating-point computations to a GPU via OpenACC or OpenMP
(ala HPC).

Although using a high-end AMD Instinct MI300 would be great,
I'm looking for something a bit more affordable such as an
AMD RX 6700 XT.=C2=A0 AFAICT, this may require either porting
AMD ROCm software to FreeBSD or running it under the
linuxlator.

https://www.amd.com/en/products/software/rocm.html=

--
Steve

--00000000000002ba560610940672-- From nobody Sun Feb 4 20:36:40 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TShC243NSz58lXh for ; Sun, 4 Feb 2024 20:37:18 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TShC14hBJz4Cs6 for ; Sun, 4 Feb 2024 20:37:17 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-42aa241b91aso33110441cf.1 for ; Sun, 04 Feb 2024 12:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707079037; x=1707683837; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vVQnAmP1nDVx7KxgJJvOljYSmyWgg1f2z+tWuSQeOhg=; b=RYvb7AbiSisUwoW2eWc61jnoZdd3H/hRL+BDDFePiAGqJIGfofWkxYnLBrJANUaHA/ YY4SFawIjYTC3rtajsvEXdewAbakz2fwVEgw60BUegAbxPMjs1VQHe9cxpPXfuF1ocXt Idsd6Orb9hMW68ExKCxJzvhpR0wcF4HDx85AyOera/+GRov4AW8I5mIPh5txhd0C8feO k0t7B09qYuqvTdqdd1jNf6xVsqnt4CalCZlFLJT8F0blMt/nVxq+Qs4aOo6lwyGbjXes als9I+8KTYCEoIEqtwlUsHjJtv9pClwqoMJkDn8gBRT6oo3tH1eGPu/K5/X4PAmkKshv J7Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707079037; x=1707683837; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vVQnAmP1nDVx7KxgJJvOljYSmyWgg1f2z+tWuSQeOhg=; b=dIEByFwdbisW0KweRSVZxXha8xqgt4N8y8u9rFZTVa0Vvy5MWCPt+B+0N4pqOE4tmt X1hG8gNQgy/B9fMFn/5YRo14aTS6ZjxJW9ulUnhAm5pKkkgcaLnZVANOWh3p2EVBTxN2 JGcbfyUa4Hq1/ixUH2YqfocWYpRjeXRNadLmSjzC/0+fqRFE/2brWN8rkOcI+KdOhIUe XP0jStTOWkBx7RUGxMNIO7abK3Jsx/icOz5pfWXxfULz6ylC2vCZaTziKDQ3MuVPf5qb +Omv5TC/n0QYUEcq4MtRy+qKAH2Y8abdgeoQr+ku0wp8wiQLKR8BaBLYh5Y81wg7Jxi0 uayQ== X-Gm-Message-State: AOJu0Ywa+pPIjfYCICwQTf76wMNIpXAVkR2CHPw2zQ5chytlybtAlLb4 NWjPMDOBsRz7ZFz0NFapCvn/GED8FZvoqxt+HT53QQ5NQq/RgLvF+YdrXSrfXeH5Ql0GTeWGoBp rT/Z6tO/NMuA1wU1Ud6+NxnGsPKstkDrRn3c= X-Google-Smtp-Source: AGHT+IH3YdH5vWZ5++J/mbiTJiBnBoho/9F4by5WaK0dYqrr3feEjbBXWas/bpxub/iwCImPuPc9GT5UzIU3Kn97ofA= X-Received: by 2002:ac8:7f47:0:b0:42c:d9d:c27f with SMTP id g7-20020ac87f47000000b0042c0d9dc27fmr6245511qtk.49.1707079036947; Sun, 04 Feb 2024 12:37:16 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Sun, 4 Feb 2024 23:36:40 +0300 Message-ID: Subject: Re: GPU programming? To: sgk@troutmask.apl.washington.edu Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000099cef60610944fd2" X-Rspamd-Queue-Id: 4TShC14hBJz4Cs6 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --00000000000099cef60610944fd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Feb 4, 2024 at 11:21=E2=80=AFPM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > Is anyone aware of work towards GPU programming on FreeBSD? > > Here, I am not interested in using a GPU while playing a > video game or rendering graphics on a video monitor. I'm > interested in offloading single and double precision > floating-point computations to a GPU via OpenACC or OpenMP > (ala HPC). > > Although using a high-end AMD Instinct MI300 would be great, > I'm looking for something a bit more affordable such as an > AMD RX 6700 XT. AFAICT, this may require either porting > AMD ROCm software to FreeBSD or running it under the > linuxlator. > > https://www.amd.com/en/products/software/rocm.html > > -- > Steve > > If you search GPU programming in all of Github , you may get 1.8k results . A Google search is also useful : https://www.google.com/search?q=3DGPU+programming&sca_esv=3D8cd01c0eb9e4bd9= 8&sxsrf=3DACQVn0-hf1I29ds68J-H82jhzUaYKKBomw%3A1707078684290&source=3Dhp&ei= =3DHPS_ZaG-D-2_xc8Pne2tsAo&iflsig=3DANes7DEAAAAAZcACLL5JyxgL0gJp1U0IaVFZYAR= 0N2hI&ved=3D0ahUKEwihvNDUw5KEAxXtX_EDHZ12C6YQ4dUDCA0&uact=3D5&oq=3DGPU+prog= ramming&gs_lp=3DEgdnd3Mtd2l6Ig9HUFUgcHJvZ3JhbW1pbmcyBRAAGIAEMgUQABiABDIFEAA= YgAQyBRAAGIAEMgUQABiABDIFEAAYgAQyBRAAGIAEMgUQABiABDIFEAAYgAQyBRAAGIAESLbOAV= AAWMm9AXABeACQAQCYAZ4BoAGQDqoBBDAuMTa4AQPIAQD4AQHCAgoQIxiABBiKBRgnwgIEECMYJ= 8ICBRAuGIAE&sclient=3Dgws-wiz GPU programming With my best wishes for all . Mehmet Erol Sanliturk --00000000000099cef60610944fd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 4, 2024 at 11:21= =E2=80=AFPM Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
Is anyone aware of work towards GPU pr= ogramming on FreeBSD?

Here, I am not interested in using a GPU while playing a
video game or rendering graphics on a video monitor.=C2=A0 I'm
interested in offloading single and double precision
floating-point computations to a GPU via OpenACC or OpenMP
(ala HPC).

Although using a high-end AMD Instinct MI300 would be great,
I'm looking for something a bit more affordable such as an
AMD RX 6700 XT.=C2=A0 AFAICT, this may require either porting
AMD ROCm software to FreeBSD or running it under the
linuxlator.

https://www.amd.com/en/products/software/rocm.html=

--
Steve



With my best wishes for all .


=
Mehmet Erol Sanliturk


--00000000000099cef60610944fd2-- From nobody Sun Feb 4 20:51:27 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TShWP534Rz58mXt for ; Sun, 4 Feb 2024 20:51:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TShWP3sljz4FZk for ; Sun, 4 Feb 2024 20:51:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 414KpRDp026646; Sun, 4 Feb 2024 12:51:27 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 414KpRDp026646 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1707079887; bh=ISg8xgQhILlc2YQCUGnKwJh/P3nNeUtVHcPE9TXwZUc=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=M8B1oaRBpZtxtVXYR0Ck++kEmDvHfBfeH7sZtfA7H1jIO0WnzBFL5hGmlR+b2pZfq Kld82xZIC700ugvbjjSy32Ws9yDnmni4DH/lLcUBMwGWfiQYmH4HRGOwUbopBjkMvK ii/qaN+ac+rZ7G6s26xLYAHYSas3xEXfIO/FsNXo+16OlN+NvR0EJMV+KMvDi5ETbb MSWP/gH5iWgdy46KrtzEGnEYWTlI9uA3HrY+VzLcqEnv4gIiIKHOiYo6PneWwNOnc4 NclytwpHumim50LbI1WveWGIudATQurGgx/H7sT9XyaswH5cz1CA5/IcWHOe84N+o2 1kZzw8DB5cKIA== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 414KpRRN026645; Sun, 4 Feb 2024 12:51:27 -0800 (PST) (envelope-from sgk) Date: Sun, 4 Feb 2024 12:51:27 -0800 From: Steve Kargl To: "B. E." Cc: freebsd-hackers@freebsd.org Subject: Re: GPU programming? Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4TShWP3sljz4FZk X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] See the second paragraph of my initial post. AMD provides ROCm and Nvidia supplies CUDA. These appear to be available for Windows and Linux. Are there any software/hardware drivers required to actually accomplish the offloading? -- steve On Sun, Feb 04, 2024 at 02:16:05PM -0600, B. E. wrote: > gcc (and gfortran) has supported OpenMP for a very long time via their GOMP > (pthreads underneath), not sure about LLVM based support or offloading (via > the latest supported OpenMP specification) to accelerators on FreeBSD per > se. What are you looking for in terms of OS support? > > Cheers, > Brett > > On Sun, Feb 4, 2024 at 1:02 PM Steve Kargl > wrote: > > > Is anyone aware of work towards GPU programming on FreeBSD? > > > > Here, I am not interested in using a GPU while playing a > > video game or rendering graphics on a video monitor. I'm > > interested in offloading single and double precision > > floating-point computations to a GPU via OpenACC or OpenMP > > (ala HPC). > > > > Although using a high-end AMD Instinct MI300 would be great, > > I'm looking for something a bit more affordable such as an > > AMD RX 6700 XT. AFAICT, this may require either porting > > AMD ROCm software to FreeBSD or running it under the > > linuxlator. > > > > https://www.amd.com/en/products/software/rocm.html > > > > -- > > Steve > > > > -- Steve From nobody Sun Feb 4 20:58:05 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TShg925V0z58mvC for ; Sun, 4 Feb 2024 20:58:13 +0000 (UTC) (envelope-from freebsd@ny-central.org) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on2113.outbound.protection.outlook.com [40.107.13.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TShg752Fcz4H9x for ; Sun, 4 Feb 2024 20:58:11 +0000 (UTC) (envelope-from freebsd@ny-central.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ny-central.org header.s=selector1 header.b=cOi+kT+e; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@ny-central.org designates 40.107.13.113 as permitted sender) smtp.mailfrom=freebsd@ny-central.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JnKI8cbPXr8HO8gwY/OLtABU0PvTEWPAUJ4zq+wqWCWyi6TcSB8Gtm9ehPGHuOgy5R7rOx/oP4t03KEkkQds56eBbDhHa1or87K5eTEVGm3n+8HI+g8dXUTbAIndTj1psldVOnHD2t7mIx1hK6kHGI88tmiV9Tl5u64Yc9YsAfoyPgdgCePtwwd9Fly+0sMncCMLm79EB7sMApZ/wPS92bf7tx71oQkLnrff2r+PwbrmHwpv0sv7mshmRA9JgcSQugFiR+g8zAyCa5QoTInEh/LMt7t8kh4Dzt6JUd8DOZgLzNYbFAxEssd8TWoa/8YgGki49ZdVSA+SvQ1HaOFBTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=77PU4Y5caPXRlKGWMpNkYJBRPHOW5U/7mrQ6N+024BE=; b=noeWbl3L01JG3E2qt3DttKihxjtOi+B9L6iTbKK3iNHXkVH4zal7rID5ey7LsTdjiwqDt59RkAthWlFzXkMz3A2FkKoG6tu+uCdGjQQtKsx5/IChbdJ3dZYDLNF1n6bu9DFU07tP62uccib4UHRkfem70me1zabCLwug991phyyGAAJ8EHBfAAsWvq4VEqiP08Lieldr2P6MxcxeXgZnnN7E6KD9v4gSNf1u5hT8ANA8yiOt2AtqhvJ/PbiWbJPDlb62OUG2IXZfE7QJHOuZF4zwx6DrV5mp20mCGhJ1WBDJA6s2jYsmjdUJZjgdDG+oOBOrtk7iowmNCa0fb6HNjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ny-central.org; dmarc=pass action=none header.from=ny-central.org; dkim=pass header.d=ny-central.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ny-central.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=77PU4Y5caPXRlKGWMpNkYJBRPHOW5U/7mrQ6N+024BE=; b=cOi+kT+ee0HgQ/lWeSn00yRdqtUeoKvoOwHqVE893GUYE+EX0CRrLQ34RmjTC8T/vpS9g0K+YEagsSE9BjvcJLm0u5syWV9RwABcnF2h+jcVRyTC8x6wKuzsdbTSd6RFbWTX1zB3RFLSS6v4gtkpJ52VvuwyLA/ASl0VHdGdhBA= Received: from PAXPR08MB6766.eurprd08.prod.outlook.com (2603:10a6:102:136::18) by GVXPR08MB7703.eurprd08.prod.outlook.com (2603:10a6:150:6b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.33; Sun, 4 Feb 2024 20:58:06 +0000 Received: from PAXPR08MB6766.eurprd08.prod.outlook.com ([fe80::78e:bd9:ca17:4277]) by PAXPR08MB6766.eurprd08.prod.outlook.com ([fe80::78e:bd9:ca17:4277%4]) with mapi id 15.20.7249.032; Sun, 4 Feb 2024 20:58:05 +0000 From: Christian Moerz To: "freebsd-hackers@freebsd.org" Subject: Re: GPU programming? Thread-Topic: GPU programming? Thread-Index: AQHaV5zCuDORaCuQAEiclQmcWoPkm7D6nryAgAAJ4oCAAAEZTA== Date: Sun, 4 Feb 2024 20:58:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PAXPR08MB6766:EE_|GVXPR08MB7703:EE_ x-ms-office365-filtering-correlation-id: ae2e5976-ec9d-4d0d-9a08-08dc25c3fba6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wqk24TgyaZlKjjKTUbVXvIQeeTx3x2B79aOxD2bFGOmmwLvOs6pQ6RJO8LGNJtiPFmsbK3kYQBMVZMTc51eHvRgKjdJxrE7xAYAbAZ1/XM0+RjkAQw6VxBo7Yfy0uNrWcY7FJ+V8r5tRslxGinKQLMbvtATVTWRy+gPFHLrSubVePzQpiwFG1ecSMWWZNsTZp/1OVDwLJw17A9OJx2hHEtJnDgOSK4Z5KTfVMe36EIzPpgcnICWXDQ/KPSDuDLOkS06yQa9aKDwJ7jZqUfJBX/Q3RrmOrRZLNIbIU6lvsRwUNvSezbYWC/yinL9wF0q8evdZIotEe+ey3WRZWuN86UspNIAEHnYPbNsDnQdj/doLuRiCC+XwXIbzqX+THS5sKDU4NwDt/OPaob2IF3UAljro2tJ5RqNM5ke6c6jVrzWCmERLo/pmBXLxtbXCdTFeltvD31yJ2r1TNZD40OQFyUAh464GV2xwneWxV5Sa0TT3za0VaBKdXGqebFqd9Z9BuxMuEHpFFzcU+oGTwSG9TQ+Gk1k1X7wcTUpSbFJLFKIsAWLO6/MRaPwmkJrXEjABF4XnNlm7RtRL1Rgl5S/XjAF5h8ouX7jOlnEPTH93RMI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAXPR08MB6766.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(39830400003)(346002)(396003)(376002)(366004)(136003)(230922051799003)(186009)(1800799012)(451199024)(64100799003)(5660300002)(21615005)(33656002)(8676002)(7116003)(52536014)(66556008)(166002)(66446008)(64756008)(316002)(6916009)(66476007)(76116006)(66946007)(8936002)(91956017)(38070700009)(38100700002)(55016003)(2906002)(122000001)(86362001)(966005)(478600001)(3480700007)(83380400001)(53546011)(71200400001)(41300700001)(26005)(7696005)(6506007)(9686003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?U0J5aWN3bjRRdW94TmVaOE9mQlYwRnY2WVFSSVE4SngzVTFnK1M3VzhjZU1P?= =?utf-8?B?RVk2VlpGd3Y3YUZRYU9hQXhlUHBZZGtWL2RyeUltUTRQWFVrdE1FRHRxRWFa?= =?utf-8?B?WStSZDdoWlFrMUxneFBuRXZHNUZhTEZobDZ4cVdadUEzcExoaGUybXN3MlFQ?= =?utf-8?B?RW92MUNldVcxaHdycjRNVEFUUmhNUXRFMUppRXJTY3ZxZE00YXNBSjJIRkFu?= =?utf-8?B?UlowL1dIcWc3YWpUTmJmM21Fc0dzTDBIMzlWbG9Tbmdsb0JySm9sc2dGQmZI?= =?utf-8?B?ZkdhTDNYbHFuakg4TkJ2S1hUVkNlTS9jSkVYTFV3SXUxTmNNZ3lsYk9BdG9R?= =?utf-8?B?RDFraDNiSVJnL0JFSG01MnE3TythenpEcGY1ZmR0eTBMbEtiOEFLOGUxTHJr?= =?utf-8?B?NHZSQ0c0MXpQdjZyWVZXK3B2TzZkeFY2Mmw5ODBhS09yTTlUTmpnQXJiODZB?= =?utf-8?B?MmNXQVpRUnkrZjQ2VnVDV0QxbVZSeTAyMVZRemZVK3dEVGZrMXNGOW5KOHVl?= =?utf-8?B?ZXkwL05YdGdJcFQvOE1xbGNMZXdLODY3NGJ2cHFlTGd0NWVEcXNVMWhEUmhF?= =?utf-8?B?RTFqNmt2WmdDRmRUS0VDVk0rMVN2L1FsYUM0alFDWmZlcmxCcThVVmhuc0RJ?= =?utf-8?B?WjlJUlNxdmJBQ09XOWVUUGtjNWRRTjdrVTVCVm1LZzlLSlQwd1NQbXp2YlNK?= =?utf-8?B?VFpjN3N2OWRqUXd1Q05URnhpWWpYT0FCMS9iN3AxbnUybC9ROC9ucGdkbHBL?= =?utf-8?B?V2dkbjFxNVZCa0tiRVltNzZSSjZWbklKZWtrVHhKZ2IwLzhEelRVU1hHbVpk?= =?utf-8?B?ZGo5T1o3blg3OXVkbm1HSU5NaG9Wdng3QmNmZVlZamFPRURjRGVmZnJpclZG?= =?utf-8?B?V2lJWExIRFpROWJ3WGFLdFUxMnROOTM2Y2MvZkRka21nUWt0aUVmeThYOXc2?= =?utf-8?B?UDRCTEUrbSs4MHhPamhhSGlzWUZxRmROcnF6aUh3eGxmTFYvNGN1aFo1TGxQ?= =?utf-8?B?SzVLQnNiRTBMeUcxQmxIekxKWERPMWZFZ01oSmVyalloRUk3bkwrREtGcUZO?= =?utf-8?B?eElrNFdROU43N3BZeDRkRFJpcit1dllZNVZMUU9SSHBJbldCdXZqanpmSjkw?= =?utf-8?B?dGt2VUU2UVNaZFh4Mmp6TUMvUjZjUDdxRldQTlVkQ012N3h0WXFkdktqL29j?= =?utf-8?B?VU8zNzhJWnZFNmtEbXVpbThTVGRodklWQkF2MkFheGJwTUhmeUNOYlpyUjNN?= =?utf-8?B?NW1YVTlOMmhsTVVEYTdnZHVRWUVZd1Zua2szR2MwN2xEMVh2dUd4ZTAyRzls?= =?utf-8?B?RkNLcGoyMTJWWXBGQlhIR3RaU2hvOHprbDFwUng0YitSVHNxZXdyUnNhRS9t?= =?utf-8?B?QkROYitJTzVZZTdGSlhTcWxlSUZoYmsyL1J5citlM21WLzVkdTl0OWlDY0dm?= =?utf-8?B?WkdYbFd1Rjh6a3F6QjJHZC9NcWNEQStkcS9YTHpKSkx6U0o1S2FhenhodHV3?= =?utf-8?B?cysxOHhYQk4yTUU4Q0s3b25Zc01XV093eUpkdVZOR2dQNTZ2MGpMLzVjSFRX?= =?utf-8?B?SloxcWRvRkZCV2gwWEt0NkcySHV5VHFmVGJZY2ZoeC92YzBmaFFuSitETGph?= =?utf-8?B?cEtJNWhYdkxlVElRK2E2VFZSMjNtcjNXNnBjVHJHOGh6R2tNZGo4ZjJyNjZ1?= =?utf-8?B?OUxHeVU0cFpwcElNQk1JeVFEaGpFY0hJeUlrMExtY25GOGVrR1RJKytYNHNa?= =?utf-8?B?bXdud1RYb2tQbWg5a1I3T0cxeUk2bFFGS29pRndnYWdFVVRrT2RzMytNY3Q2?= =?utf-8?B?L1ZqMXlld2JyUFdqR3NWSUFtSHJDcHlZWXUva3dVNTUwODUzZnZHaU81dnlq?= =?utf-8?B?TGVoMzhxWEg4cCtOckVKaVJUQlR3THRxczE0Nnl4eWtxU1hHTXdYRE1iUnh4?= =?utf-8?B?UVpzSDFCaFV4a3ZKeFdOZlpJSEU4L0Z1OTVjeVB0YkQvZjlBOWxLY2dsYVdC?= =?utf-8?B?VlhXOGF0NktrVW0zUFVGMHFhUTJDS1dZdmt3K1pLc1hUV1dqdHlvYndRU3Vw?= =?utf-8?B?OXF5NFlMUWpQOHJybzd1bVZlOE9rWGtNbXpESDV1UGg5M0JUSDF0NjBzK1h2?= =?utf-8?B?SFZHQ3Q5eFIyaDlFZ2pabUYyaWdOUzBDMjZ1ZkplWHQyL0dFelk0NTlhZ3Q1?= =?utf-8?B?dmc9PQ==?= Content-Type: multipart/alternative; boundary="_000_PAXPR08MB6766EFBEEF6A97A3743440DA94402PAXPR08MB6766eurp_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: ny-central.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PAXPR08MB6766.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae2e5976-ec9d-4d0d-9a08-08dc25c3fba6 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2024 20:58:05.0434 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 96573e63-211a-4cdb-be46-e3a366908d60 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UOJbuhrj9LQmag2nPriO8q3s5cOP71yTCy3ifxIgGfwsZ995K3/lzW4FJMlMjBa3HAcMF2awe8euphJGxr/Fmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7703 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[ny-central.org:s=selector1]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MISSING_XM_UA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.13.113:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.13.113:from]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[ny-central.org]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[ny-central.org:+] X-Rspamd-Queue-Id: 4TShg752Fcz4H9x --_000_PAXPR08MB6766EFBEEF6A97A3743440DA94402PAXPR08MB6766eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RldmUNCkkgYmVsaWV2ZSwgdGhpcyBpcyBvbmUgb2YgdGhlIHdvcmsgcGFja2FnZXMgb2Yg dGhlIEVudGVycHJpc2UgV29ya2luZyBHcm91cC4gSSByZWNvbW1lbmQgcmVhY2hpbmcgb3V0IHRv IEdyZWcgV2FsbGFjZS4gSGUgc2hvdWxkIGJlIGFibGUgdG8gbG9vcCB5b3UgaW4sIGlmIHlvdSdy ZSBpbnRlcmVzdGVkIGluIHBhcnRpY2lwYXRpbmcgaW4gdGhlIHdvcmsuDQoNCmh0dHBzOi8vd2lr aS5mcmVlYnNkLm9yZy9FbnRlcnByaXNlV29ya2luZ0dyb3VwDQoNCkNocmlzDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogb3duZXItZnJlZWJzZC1oYWNrZXJzQGZyZWVi c2Qub3JnIDxvd25lci1mcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmc+IG9uIGJlaGFsZiBvZiBT dGV2ZSBLYXJnbCA8c2drQHRyb3V0bWFzay5hcGwud2FzaGluZ3Rvbi5lZHU+DQpTZW50OiBTdW5k YXksIEZlYnJ1YXJ5IDQsIDIwMjQgOTo1MToyNyBQTQ0KVG86IEIuIEUuIDxlc3RyYWJkQGdtYWls LmNvbT4NCkNjOiBmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmcgPGZyZWVic2QtaGFja2Vyc0Bm cmVlYnNkLm9yZz4NClN1YmplY3Q6IFJlOiBHUFUgcHJvZ3JhbW1pbmc/DQoNClNlZSB0aGUgc2Vj b25kIHBhcmFncmFwaCBvZiBteSBpbml0aWFsIHBvc3QuICBBTUQgcHJvdmlkZXMNClJPQ20gYW5k IE52aWRpYSBzdXBwbGllcyBDVURBLiAgVGhlc2UgYXBwZWFyIHRvIGJlIGF2YWlsYWJsZQ0KZm9y IFdpbmRvd3MgYW5kIExpbnV4LiAgQXJlIHRoZXJlIGFueSBzb2Z0d2FyZS9oYXJkd2FyZSBkcml2 ZXJzDQpyZXF1aXJlZCB0byBhY3R1YWxseSBhY2NvbXBsaXNoIHRoZSBvZmZsb2FkaW5nPw0KDQot LQ0Kc3RldmUNCg0KDQoNCk9uIFN1biwgRmViIDA0LCAyMDI0IGF0IDAyOjE2OjA1UE0gLTA2MDAs IEIuIEUuIHdyb3RlOg0KPiBnY2MgKGFuZCBnZm9ydHJhbikgaGFzIHN1cHBvcnRlZCBPcGVuTVAg Zm9yIGEgdmVyeSBsb25nIHRpbWUgdmlhIHRoZWlyIEdPTVANCj4gKHB0aHJlYWRzIHVuZGVybmVh dGgpLCBub3Qgc3VyZSBhYm91dCBMTFZNIGJhc2VkIHN1cHBvcnQgb3Igb2ZmbG9hZGluZyAodmlh DQo+IHRoZSBsYXRlc3Qgc3VwcG9ydGVkIE9wZW5NUCBzcGVjaWZpY2F0aW9uKSB0byBhY2NlbGVy YXRvcnMgb24gRnJlZUJTRCBwZXINCj4gc2UuIFdoYXQgYXJlIHlvdSBsb29raW5nIGZvciBpbiB0 ZXJtcyBvZiBPUyBzdXBwb3J0Pw0KPg0KPiBDaGVlcnMsDQo+IEJyZXR0DQo+DQo+IE9uIFN1biwg RmViIDQsIDIwMjQgYXQgMTowMuKAr1BNIFN0ZXZlIEthcmdsIDxzZ2tAdHJvdXRtYXNrLmFwbC53 YXNoaW5ndG9uLmVkdT4NCj4gd3JvdGU6DQo+DQo+ID4gSXMgYW55b25lIGF3YXJlIG9mIHdvcmsg dG93YXJkcyBHUFUgcHJvZ3JhbW1pbmcgb24gRnJlZUJTRD8NCj4gPg0KPiA+IEhlcmUsIEkgYW0g bm90IGludGVyZXN0ZWQgaW4gdXNpbmcgYSBHUFUgd2hpbGUgcGxheWluZyBhDQo+ID4gdmlkZW8g Z2FtZSBvciByZW5kZXJpbmcgZ3JhcGhpY3Mgb24gYSB2aWRlbyBtb25pdG9yLiAgSSdtDQo+ID4g aW50ZXJlc3RlZCBpbiBvZmZsb2FkaW5nIHNpbmdsZSBhbmQgZG91YmxlIHByZWNpc2lvbg0KPiA+ IGZsb2F0aW5nLXBvaW50IGNvbXB1dGF0aW9ucyB0byBhIEdQVSB2aWEgT3BlbkFDQyBvciBPcGVu TVANCj4gPiAoYWxhIEhQQykuDQo+ID4NCj4gPiBBbHRob3VnaCB1c2luZyBhIGhpZ2gtZW5kIEFN RCBJbnN0aW5jdCBNSTMwMCB3b3VsZCBiZSBncmVhdCwNCj4gPiBJJ20gbG9va2luZyBmb3Igc29t ZXRoaW5nIGEgYml0IG1vcmUgYWZmb3JkYWJsZSBzdWNoIGFzIGFuDQo+ID4gQU1EIFJYIDY3MDAg WFQuICBBRkFJQ1QsIHRoaXMgbWF5IHJlcXVpcmUgZWl0aGVyIHBvcnRpbmcNCj4gPiBBTUQgUk9D bSBzb2Z0d2FyZSB0byBGcmVlQlNEIG9yIHJ1bm5pbmcgaXQgdW5kZXIgdGhlDQo+ID4gbGludXhs YXRvci4NCj4gPg0KPiA+IGh0dHBzOi8vd3d3LmFtZC5jb20vZW4vcHJvZHVjdHMvc29mdHdhcmUv cm9jbS5odG1sDQo+ID4NCj4gPiAtLQ0KPiA+IFN0ZXZlDQo+ID4NCj4gPg0KDQotLQ0KU3RldmUN Cg0K --_000_PAXPR08MB6766EFBEEF6A97A3743440DA94402PAXPR08MB6766eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iPkhpIFN0ZXZlPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+SSBiZWxpZXZlLCB0aGlzIGlzIG9u ZSBvZiB0aGUgd29yayBwYWNrYWdlcyBvZiB0aGUgRW50ZXJwcmlzZSBXb3JraW5nIEdyb3VwLiBJ IHJlY29tbWVuZCByZWFjaGluZyBvdXQgdG8gR3JlZyBXYWxsYWNlLiBIZSBzaG91bGQgYmUgYWJs ZSB0byBsb29wIHlvdSBpbiwgaWYgeW91J3JlPHNwYW4+IGludGVyZXN0ZWQgaW4gcGFydGljaXBh dGluZyBpbiB0aGUgd29yay48L3NwYW4+PHNwYW4+PC9zcGFuPjwvZGl2Pg0KPGRpdiBpZD0ibXMt b3V0bG9vay1tb2JpbGUtc2lnbmF0dXJlIiBkaXI9ImF1dG8iPg0KPGRpdiBkaXI9ImF1dG8iPg0K PHA+PGEgcmVsPSJub3JlZmVycmVyIG5vb3BlbmVyIiBocmVmPSJodHRwczovL3dpa2kuZnJlZWJz ZC5vcmcvRW50ZXJwcmlzZVdvcmtpbmdHcm91cCI+aHR0cHM6Ly93aWtpLmZyZWVic2Qub3JnL0Vu dGVycHJpc2VXb3JraW5nR3JvdXA8L2E+PGJyPg0KPC9wPg0KQ2hyaXM8L2Rpdj4NCjwvZGl2Pg0K PGhyIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+ DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwg c2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJv bTo8L2I+IG93bmVyLWZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZyAmbHQ7b3duZXItZnJlZWJz ZC1oYWNrZXJzQGZyZWVic2Qub3JnJmd0OyBvbiBiZWhhbGYgb2YgU3RldmUgS2FyZ2wgJmx0O3Nn a0B0cm91dG1hc2suYXBsLndhc2hpbmd0b24uZWR1Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBTdW5k YXksIEZlYnJ1YXJ5IDQsIDIwMjQgOTo1MToyNyBQTTxicj4NCjxiPlRvOjwvYj4gQi4gRS4gJmx0 O2VzdHJhYmRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gZnJlZWJzZC1oYWNrZXJzQGZy ZWVic2Qub3JnICZsdDtmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBHUFUgcHJvZ3JhbW1pbmc/PC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iQm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+U2VlIHRoZSBz ZWNvbmQgcGFyYWdyYXBoIG9mIG15IGluaXRpYWwgcG9zdC4mbmJzcDsgQU1EIHByb3ZpZGVzPGJy Pg0KUk9DbSBhbmQgTnZpZGlhIHN1cHBsaWVzIENVREEuJm5ic3A7IFRoZXNlIGFwcGVhciB0byBi ZSBhdmFpbGFibGU8YnI+DQpmb3IgV2luZG93cyBhbmQgTGludXguJm5ic3A7IEFyZSB0aGVyZSBh bnkgc29mdHdhcmUvaGFyZHdhcmUgZHJpdmVyczxicj4NCnJlcXVpcmVkIHRvIGFjdHVhbGx5IGFj Y29tcGxpc2ggdGhlIG9mZmxvYWRpbmc/IDxicj4NCjxicj4NCi0tIDxicj4NCnN0ZXZlPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KT24gU3VuLCBGZWIgMDQsIDIwMjQgYXQgMDI6MTY6MDVQTSAtMDYw MCwgQi4gRS4gd3JvdGU6PGJyPg0KJmd0OyBnY2MgKGFuZCBnZm9ydHJhbikgaGFzIHN1cHBvcnRl ZCBPcGVuTVAgZm9yIGEgdmVyeSBsb25nIHRpbWUgdmlhIHRoZWlyIEdPTVA8YnI+DQomZ3Q7IChw dGhyZWFkcyB1bmRlcm5lYXRoKSwgbm90IHN1cmUgYWJvdXQgTExWTSBiYXNlZCBzdXBwb3J0IG9y IG9mZmxvYWRpbmcgKHZpYTxicj4NCiZndDsgdGhlIGxhdGVzdCBzdXBwb3J0ZWQgT3Blbk1QIHNw ZWNpZmljYXRpb24pIHRvIGFjY2VsZXJhdG9ycyBvbiBGcmVlQlNEIHBlcjxicj4NCiZndDsgc2Uu IFdoYXQgYXJlIHlvdSBsb29raW5nIGZvciBpbiB0ZXJtcyBvZiBPUyBzdXBwb3J0Pzxicj4NCiZn dDsgPGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyBCcmV0dDxicj4NCiZndDsgPGJyPg0KJmd0 OyBPbiBTdW4sIEZlYiA0LCAyMDI0IGF0IDE6MDLigK9QTSBTdGV2ZSBLYXJnbCAmbHQ7c2drQHRy b3V0bWFzay5hcGwud2FzaGluZ3Rvbi5lZHUmZ3Q7PGJyPg0KJmd0OyB3cm90ZTo8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmd0OyBJcyBhbnlvbmUgYXdhcmUgb2Ygd29yayB0b3dhcmRzIEdQVSBwcm9n cmFtbWluZyBvbiBGcmVlQlNEPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBIZXJlLCBJ IGFtIG5vdCBpbnRlcmVzdGVkIGluIHVzaW5nIGEgR1BVIHdoaWxlIHBsYXlpbmcgYTxicj4NCiZn dDsgJmd0OyB2aWRlbyBnYW1lIG9yIHJlbmRlcmluZyBncmFwaGljcyBvbiBhIHZpZGVvIG1vbml0 b3IuJm5ic3A7IEknbTxicj4NCiZndDsgJmd0OyBpbnRlcmVzdGVkIGluIG9mZmxvYWRpbmcgc2lu Z2xlIGFuZCBkb3VibGUgcHJlY2lzaW9uPGJyPg0KJmd0OyAmZ3Q7IGZsb2F0aW5nLXBvaW50IGNv bXB1dGF0aW9ucyB0byBhIEdQVSB2aWEgT3BlbkFDQyBvciBPcGVuTVA8YnI+DQomZ3Q7ICZndDsg KGFsYSBIUEMpLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBbHRob3VnaCB1c2luZyBh IGhpZ2gtZW5kIEFNRCBJbnN0aW5jdCBNSTMwMCB3b3VsZCBiZSBncmVhdCw8YnI+DQomZ3Q7ICZn dDsgSSdtIGxvb2tpbmcgZm9yIHNvbWV0aGluZyBhIGJpdCBtb3JlIGFmZm9yZGFibGUgc3VjaCBh cyBhbjxicj4NCiZndDsgJmd0OyBBTUQgUlggNjcwMCBYVC4mbmJzcDsgQUZBSUNULCB0aGlzIG1h eSByZXF1aXJlIGVpdGhlciBwb3J0aW5nPGJyPg0KJmd0OyAmZ3Q7IEFNRCBST0NtIHNvZnR3YXJl IHRvIEZyZWVCU0Qgb3IgcnVubmluZyBpdCB1bmRlciB0aGU8YnI+DQomZ3Q7ICZndDsgbGludXhs YXRvci48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu YW1kLmNvbS9lbi9wcm9kdWN0cy9zb2Z0d2FyZS9yb2NtLmh0bWwiPmh0dHBzOi8vd3d3LmFtZC5j b20vZW4vcHJvZHVjdHMvc29mdHdhcmUvcm9jbS5odG1sPC9hPjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBTdGV2ZTxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCjxicj4NCi0tIDxicj4NClN0ZXZlPGJyPg0KPGJyPg0KPC9kaXY+DQo8L3Nw YW4+PC9mb250PjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_PAXPR08MB6766EFBEEF6A97A3743440DA94402PAXPR08MB6766eurp_--