From nobody Mon Sep 9 04:42:16 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 4X2Dhg1QQ2z5V5NN for ; Mon, 09 Sep 2024 04:42:27 +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 4X2Dhf6Cq9z46xB for ; Mon, 9 Sep 2024 04:42:26 +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 4894gGfa086474; Mon, 9 Sep 2024 05:42:16 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 4894gGMb086473; Mon, 9 Sep 2024 05:42:16 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> Date: Mon, 09 Sep 2024 05:42:16 +0100 Organization: Dyslexic Fish To: void@f-m.fm, freebsd-hackers@FreeBSD.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> In-Reply-To: <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> 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]); Mon, 09 Sep 2024 05:42:16 +0100 (BST) 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] X-Rspamd-Queue-Id: 4X2Dhf6Cq9z46xB void wrote: > ? really? All my -stable and -current machines are recompiled from source. > Is this really that rare? Mine too (well, I only track stable at the moment, and am only talking about 8 machines) I have too many local patches to easily do it any other way. As it is, i sync src, patches are automatically applied, then make buildworld etc... is all that's needed. Similar story for ports vs packages - too many patches (and custom options) From nobody Mon Sep 9 07:01:42 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 4X2Hnb2wyWz5Vx1Y for ; Mon, 09 Sep 2024 07:01:55 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2Hnb2VDRz4N8J; Mon, 9 Sep 2024 07:01:55 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725865315; 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=GTRevHB2z4D32Pj52JHdpxVD2A3d/6lAuzxzQPSWU2c=; b=ZgoyzM4EVuztrL63n29BQy2US4yW2D34T4eFGdLsMLVW0W15mc8de4CSYboje6xjjQdjAx kO0L3pQzroNmY/Z3D5d8Ez7YhW1+OlQSbYJS7618XXdLn43VGAZS8wAoxkXFfNUTGNOOVh hch+LqKOC88Ka8kEijhq9APtWifBGkaEtReCIYAuvoHowoY1+tb4IFuvp3sMwrw/OEJlZ1 pMQ6578S/MMEcnBhMu0WvAPUzpcgbTlyy7++9TVjo0VEkXmrcwEu/hXnTQnK3lZ/XK4oub 2aI4IY0xm++x7E3hTQzfhXMlpj5DFNIvHW/JW8lACs9qEGUgXrcOf7uAKcFj6w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725865315; a=rsa-sha256; cv=none; b=HDsecJoX1V/3YPY63HZ3ciC6giZR1MT6ZDbHePRWgPfizVpcOWODH0TTZlf8dM4r+i4sks M7XHgge5Ps/1oBQLgdDPUdsMdKE4WdRK/XTu+KA1I2w+ftryycdiHONP1pVEWTRjopPff2 aHEs/bN4R3WiMBl/dZ2ld3VurcdA51KmkweIzSuTqyFhMQ7pDGnsTx4zKe5fnun4BuV4vn vz1lsLR6tmLRClUzxPacylBF5lNUHUvcC0af8OHqlxoiuqxTLiPBOQUWAshBI4KYdNFL4g dqJJFPDL8aHgk2rCv2eeNUaDYGjzvqJDeyw1fpUO/AVToeTDGBt6AC2riJ24fA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725865315; 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=GTRevHB2z4D32Pj52JHdpxVD2A3d/6lAuzxzQPSWU2c=; b=No2VJ64zNqJYjKt31X1BtNO43gnVccwsbi2oaVIxSaS9YI9FfmOULP150Xv9PMp32QTTc3 fU8mOIJjsn2eHxwE6gbOn0muFT225P/CAZt2gAovEgCL5lROQmGbp5dICalbF4BrYudl7M lIPgqssK+Oob4AXfR8sggXy/cMSPk1wSrfgjHW9dFRbtHRelt0xw3eQbNYkEMjV5s6N/mU eqy1f+Yx/YNmpfQdCBhSS+QQG6shmVIcMa8v2WEKZQ5DXJ6ecdGbnTtiuywToDW0N4JXgi Prq8wC/y++Ydndj2pg8i5GBSArW4webYpB5zKmsfChNkanRYlkFJ4maZ7yPpNQ== 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 4X2Hnb23qNz13HR; Mon, 9 Sep 2024 07:01:55 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 1A5516580; Mon, 09 Sep 2024 08:01:54 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Mon, 9 Sep 2024 08:01:42 +0100 Message-Id: <202DD893-B152-4B38-AE9B-862E08785396@freebsd.org> References: <202409082111.488LBTtI074660@critter.freebsd.dk> Cc: Warner Losh , Kristof Provost , Alan Somers , Dmitry Salychev , Jan Knepper , FreeBSD Hackers In-Reply-To: <202409082111.488LBTtI074660@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: iPad Mail (21G93) On 8 Sep 2024, at 22:11, Poul-Henning Kamp wrote: >=20 > =EF=BB=BFWarner Losh writes: >=20 >> I did C++ in the kernel in the 4.x->7-current time frame. >=20 > The logical progression of C++ adoption would start with using a C++ > compiler as a better C compiler. I=E2=80=99m always a bit nervous about this: C=E2=80=99s struct initialiser syntax is useful for things that look like o= ptional parameters in C APIs but is invalid in C++. I believe clang and gcc s= upport it in C++ mode in some places, but I=E2=80=99m not sure where. C++ has stricter aliasing rules than C. Some things that are valid C and wil= l do the right thing with -fstrict-aliasing will incorrectly compile in C++ m= ode. C permits implicit casts from void*, C++ doesn=E2=80=99t. The last codebase I= worked on that had gone through this transition was littered with implicit c= asts which made it hard to read. At a minimum, I=E2=80=99d want to add an al= ways-inline templates wrapper around malloc that did the right thing, if not= an explicit move to new/delete. C++ places type and value names in the same namespace. There are some corner= cases where a structure and a variable have the same name and sizeof gives d= ifferent results in C and C++ modes. Compiling C as C++ will *normally* give the same output, but not always. David From nobody Mon Sep 9 07:39:09 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 4X2Jcd3wTlz5W2dq for ; Mon, 09 Sep 2024 07:39:13 +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 4X2Jcd0wQQz4SMM; Mon, 9 Sep 2024 07:39:12 +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 352E289284; Mon, 09 Sep 2024 07:39:10 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 4897d92v078621; Mon, 9 Sep 2024 07:39:09 GMT (envelope-from phk) Message-Id: <202409090739.4897d92v078621@critter.freebsd.dk> To: David Chisnall cc: Warner Losh , Kristof Provost , Alan Somers , Dmitry Salychev , Jan Knepper , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) In-reply-to: <202DD893-B152-4B38-AE9B-862E08785396@freebsd.org> From: "Poul-Henning Kamp" References: <202409082111.488LBTtI074660@critter.freebsd.dk> <202DD893-B152-4B38-AE9B-862E08785396@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" Content-ID: <78619.1725867549.1@critter.freebsd.dk> Date: Mon, 09 Sep 2024 07:39:09 +0000 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] X-Rspamd-Queue-Id: 4X2Jcd0wQQz4SMM -------- David Chisnall writes: > On 8 Sep 2024, at 22:11, Poul-Henning Kamp wrote: > > The logical progression of C++ adoption would start with using a C++ > > compiler as a better C compiler. > > Compiling C as C++ will *normally* give the same output, but not always. But do you agree that the C++ compiler's take on things make more sense than the C compiler's in these cases ? -- 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 Mon Sep 9 07:59: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 4X2K4p23j0z5W57v for ; Mon, 09 Sep 2024 08:00:10 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2K4p1cz4z4Vlq; Mon, 9 Sep 2024 08:00:10 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725868810; 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=lg6OHyZ4SJB1Rjlz8X5xxxJjHW5LV0ZGMc+KsaxoJ1c=; b=VWmNXBbBYFYLDT/r/n0/sk98M5YuzThNoSc0oQeeAIdkEVvAG0j13h1DqdGOyUIGlx5VN8 EmHmDMLnAWjn0Zr/IjU+bCb24PJWXDV8VWJ5Rw9B5FdE1BnCA5qbXxUejgw9eXzDA92hwP +60mUH6wlGTwFUEtnWqCgDum0t5MyfFDDHaTMlaH1qYTp44KgHRUPx55jjeFwCSQhez606 Qk+fhafKBuQj+ncwRJutAZfGmZZ6lJygDsfWzgw6bTWYs+lV42eA94PbMZ6rqrbHvNjWWL remPYbSq+XHwyqJpGi3uQRTdJSjhAx06l+KI/zBDl2zYu3q6PsWTkgVPY5uGWw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725868810; a=rsa-sha256; cv=none; b=aROEG2oZ2ShO/RAe2wdq0HeJ1PSi+q8+9N6/gegaGlwPUlPfkxG9SM4Xet7Zpzf/J25op4 DSj0IwRexy9FZ3h6bCGWyhuWL6hRFVZodNENq/xY0CPH+erNMGImaVNkcI8oS1TVhJllRS 4auckJfYszIoNSv48oM5HcvOnvKrB1gVKwb+B7eiG1NYaIvVftonJqpbHedSevbAKEhiBL J2sfLZXkrXjU+LgnTqudZaUjV5ZRN7gyi2H/o7YcuNoCaoE6zrRbl+Smo9aD5uiasGqJ8S 0dwEyW6CS0w/0KDHWNytL2a3Zho80ObPF9GnMUJOkjHXpQ/BpmDs7Glqx7+DeA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725868810; 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=lg6OHyZ4SJB1Rjlz8X5xxxJjHW5LV0ZGMc+KsaxoJ1c=; b=uLJrXvd8uI8y0yjVZnXpxHnVbVav/mHRSpqQQuzEeanUxQgw3t0Y126LgA5UeDwioXwz8B VCHwC3bIZDCicepnHXd7jMJdT+jHNt6nxtDMO3XSlogh0F8DHfGLQ0PMRhUxle3FCFcelr 5gpgE42TADeY4rbJBe0CY4liJiXq0adZ3ORI670LfRcSGv30VfVfzoJP8Xf8I11LYnxE3S VOJYDUIIdr/pTljfSytHVPxpGT+SubQNWjiTdvMLgFRxFFIK1/c4xqoE9UCQi/0d0Ft34d rGd8n8Buwua8HnqHyzYiSTgjY0YNBKbg+4O8J++1bHM++XmzJDrCQcHCHsbHNQ== 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 4X2K4p127Qz14D8; Mon, 9 Sep 2024 08:00:09 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 6B6DA6581; Mon, 09 Sep 2024 09:00:09 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Mon, 9 Sep 2024 08:59:58 +0100 Message-Id: <0C28DE97-D536-404E-A385-0920C12A768A@freebsd.org> References: <202409090739.4897d92v078621@critter.freebsd.dk> Cc: Warner Losh , Kristof Provost , Alan Somers , Dmitry Salychev , Jan Knepper , FreeBSD Hackers In-Reply-To: <202409090739.4897d92v078621@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: iPad Mail (21G93) On 9 Sep 2024, at 08:39, Poul-Henning Kamp wrote: >=20 > But do you agree that the C++ compiler's take on things make more sense > than the C compiler's in these cases ? I=E2=80=99m not sure I=E2=80=99ve seen many places where it makes a differen= ce. To me, most of the benefit of C++ comes from the ability to create types= that enforce invariants. For example, in snmalloc we avoid using bare void*= in most places and instead use a wrapper type that enforces the allocation s= tate machine, so invalid transitions fail to compile. Just using C-style cod= e with void* would not catch any of these bugs in C or C++ mode. David= From nobody Mon Sep 9 08:14: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 4X2KNx137Hz5W6Yf for ; Mon, 09 Sep 2024 08:14:09 +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 4X2KNw5l1Jz4XRk; Mon, 9 Sep 2024 08:14:08 +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 295E489284; Mon, 09 Sep 2024 08:14:07 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 4898E6cR079209; Mon, 9 Sep 2024 08:14:06 GMT (envelope-from phk) Message-Id: <202409090814.4898E6cR079209@critter.freebsd.dk> To: David Chisnall cc: Warner Losh , Kristof Provost , Alan Somers , Dmitry Salychev , Jan Knepper , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) In-reply-to: <0C28DE97-D536-404E-A385-0920C12A768A@freebsd.org> From: "Poul-Henning Kamp" References: <202409090739.4897d92v078621@critter.freebsd.dk> <0C28DE97-D536-404E-A385-0920C12A768A@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" Content-ID: <79207.1725869646.1@critter.freebsd.dk> Date: Mon, 09 Sep 2024 08:14:06 +0000 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] X-Rspamd-Queue-Id: 4X2KNw5l1Jz4XRk -------- David Chisnall writes: > On 9 Sep 2024, at 08:39, Poul-Henning Kamp wrote: > > > > But do you agree that the C++ compiler's take on things make more sense > > than the C compiler's in these cases ? > > I'm not sure I've seen many places where it makes a difference. To me, > most of the benefit of C++ comes from the ability to create types > that enforce invariants. I fully agree, but I am not talking about reaping "most of the benefits", I'm talking about "how to get started with C++" and if it is worth it ? -- 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 Mon Sep 9 08:20: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 4X2KXg55Y4z5W7bs for ; Mon, 09 Sep 2024 08:20:51 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2KXg30kNz4Yvx; Mon, 9 Sep 2024 08:20:51 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725870051; 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=d4v/YSh6cXAy8cj9WxmEUrtUPHNZzc5cNbRdk2MQeaw=; b=vspACIwJKNVsIYUKPr8cw9jx/+hmMlviLNnPRirWzaBXdnVjijku02I+M2ZQxrVkjPnfg+ REBMPBoU76cIMTCWiXpsJs07ieJUhIJigL9ICmRbF4mBYQaXwAJIXMakbrPQIAQRgACT0s ps4NxkAilpj1T6gefkasDU6RitJvytqD9XKwA/+dHFn24YAs35stgmXlReYSlKlyb5nfZ9 VDnNK9YqpNPdgMFyfl6XVxjdU/c8wquX1b7BUVvWimQVifguUsKICFcL/TSj2o7G0Cn6gP 77ittSCACOWG0d7bzFkueau6uBgJ3udJnTSGCax3CKiSYb2QuBCH2HfQWo5u6A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725870051; a=rsa-sha256; cv=none; b=ieM8A7LmutP8W6+MwAO9H+HLbujRCRcwvfdCxkYLhlmC80SquyaDbYk93lPr7hJHZsCbxO /LHZDbEfGaOau4ccSVcWx9lKea3SNKgry4HZSQfMGm6TcywrhI5xby+O8PYW1E2mW/h/pU 1V/JmXbhaJeEPTUnckKkpauokIWFWyth2aeKfoaoWDBMCDnDQGAEEaAeTjKVvqtmTxfMXj R7slaRNjLIWhl19g9BTbCqtfS3BAfFkF7VRifI9e8fZvENrJZblIui+xjU9xjQRCTJ7Ijx c4CfJkxWsYohgbllgCH46dPBfnKQl/kg96dDkeip993nrfX9fPGLj4bu7rhbnA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725870051; 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=d4v/YSh6cXAy8cj9WxmEUrtUPHNZzc5cNbRdk2MQeaw=; b=RVJzJk5XRXgGRKi/9o1v5GiKgG/fFsL+vKBghbobAiysPMJT8qWgq/qfAN/8YKWlpxQADi 5BMTP7GjfK5izqvVpMG/1zICFnsXLgTBI/mxG/f2qOzQL6lwFspLuYFwGiPHa8YQJK050J rMJb5Xdq98grqvJ88HRUm8OaEPXBckUGY5A+20b4wnp78JpTLgUASu/ZgabrgQWuqrDJrj Ee+y9gfsxnonNYbWkGWYDK8XiWhdgmxzuPJsSUjj6arfUFXl/9tqpx3NR0U52dW1XBzn2M pSEMrrUQdTEMstUKQrkXt1fA+FHa21lPyV2FhDNSuqyX7rnJA1rOXjelWPjDxg== 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 4X2KXg2R51z14Pp; Mon, 9 Sep 2024 08:20:51 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id E9E796582; Mon, 09 Sep 2024 09:20:49 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: The Case for Rust (in any system) Date: Mon, 9 Sep 2024 09:20:38 +0100 Message-Id: <4A27D042-FDEA-422F-96D9-CD546913C96A@freebsd.org> References: <202409090814.4898E6cR079209@critter.freebsd.dk> Cc: Warner Losh , Kristof Provost , Alan Somers , Dmitry Salychev , Jan Knepper , FreeBSD Hackers In-Reply-To: <202409090814.4898E6cR079209@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: iPad Mail (21G93) On 9 Sep 2024, at 09:14, Poul-Henning Kamp wrote: >=20 > I fully agree, but I am not talking about reaping "most of the benefits", > I'm talking about "how to get started with C++" and if it is worth it ? Aside from the pointer cast issue (which can be solved by using *slightly* m= ore C++), I don=E2=80=99t see downsides to defaulting to C++ for compilation= (comdat issues in the kernel loader aside). David From nobody Mon Sep 9 09:37: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 4X2MFQ2mmrz5WKkF for ; Mon, 09 Sep 2024 09:37:46 +0000 (UTC) (envelope-from olce@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2MFQ1V6Pz4lxh for ; Mon, 9 Sep 2024 09:37:46 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725874666; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GfHaARVzDkG5wUGHveyVXTRQ1gGmlL8a+pYaFpObOHw=; b=uGWfsjAc0XphgN8y9UXWsmTL5DLYD5NUo8018yeARFzHAybdbAIprUo7ev6d8mOELu98zI 89dc6kfmYLpEyW4NPhc8BrvyyB03ItNxI5AZ+2zh/hNiRgFrg1+hOgRrafBn5/u8j8SI5U is4Wi0tion7t62bL4KNHhGngp1o3ufiLarL2WfnbM9Z1VZ8uiaXSpcjCcLylq3aOZGpQkr uQjdQT5Z4kEjtnc5DaYMoeqNnXY6Ia/p2MAKGey7JFXYWibX5hELdq3FTkb1I8gs0LXnTo F5G62UZVmTQoYtGBU+4VHcey42qhfmXW+D8pJJmYfkBGVBxA+n0rBVkDRMzjfQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725874666; a=rsa-sha256; cv=none; b=dPMywdSHUcepG08PIl7SFuq0agV9OU8qAnuUUXjMMTMIXsqJsLLi8KnlO7AZvnOJFXKx9A XQXzkdOLJATiHqgcW2si7Gh/1PQEXe0l8iKhOrMGjBxswO6tg1LGS5FN0LkEU3N3GJ4ccK 8YeoTWvCy75l4+IsAbpFY44eEw7WvJ6KUwn8WKVZlN5ClDnYoY13UduiajpNyky4f1mWfh rzpU3+hctvYiiy8QEWaYapWsPbzgAs3beC2aWB3I4vGqrJWNt/IGmQyP5V1uQcJmbSCmse bzKd6QsIcIbuqwTiBO9Qzw8lc1uVRh7CefQCsaZrd7HjzYHfHekc7hFOSFdz5w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725874666; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GfHaARVzDkG5wUGHveyVXTRQ1gGmlL8a+pYaFpObOHw=; b=ODcHD1NAh6Zib8pmM0fW1xHK0J+GGF85CEycdnRjfY4Vr41uG/javfnKPR0XzYmTV2//o4 fddJC0FmcIyjFBgkWJDZggJDJWVMgNlUjzCiG50YefqQU6FsibpFEm5hbPnulwuedgPNHt ZAlddnvphrHsbmo5EQEAVTKMzp9IXvC25K0Iqb1of+HEv0HyHYRmoVYU06AlZfbh8Hfqgi e6N3WDKFMxkdS5KG9IusSoXDQ4DIeZzFkdWq8scIgwkfUDAQC6iZEUuKNcdLz+cIUPVyNY Yd0EoE6gm21gWU8S5CAPJy3Y468VEhvLbL6kmTJdkDrGrOAHVfEfbvP/vitlJw== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X2MFP6VPKz166R for ; Mon, 9 Sep 2024 09:37:45 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Date: Mon, 09 Sep 2024 11:37:35 +0200 Message-ID: <5500620.vKySYWdmsc@ravel> In-Reply-To: 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/signed; boundary="nextPart2129665.oBscRyyxYM"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2129665.oBscRyyxYM Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Date: Mon, 09 Sep 2024 11:37:35 +0200 Message-ID: <5500620.vKySYWdmsc@ravel> MIME-Version: 1.0 Hello Alan, > And none of them wouldn't have happened if their respective programs had been written in a > memory-safe language. > Use after free > ============== > https://cgit.freebsd.org/src/commit/?id=62f40433ab47ad4a9694a22a0313d57661502ca1 > CVE-2024-43102 FreeBSD-SA-24:14.umtx As the person who analyzed and fixed this particular bug, I must point out that I don't see how Rust could have changed anything in this case. The Use-After-Free in this bug has nothing to do with a simple pointer dereference to an object that was freed earlier in the source code sequence. Instead, it existed because of a combination of several specific factors: concurrent accesses, a lock that has to be dropped and then re-acquired, reference counting and a special reference to account for the presence of an object in a registry. Persistence in this registry is up to deletion triggered by process exit or a specific call from userland, and the object has to be returned to userland on some other specific calls in the meantime. AFAIU, this is simply way beyond what the borrow checker and "linear" types are capable of expressing. Enthusiasm is great, and I hope you'll keep it, but subliminal messages (not necessarily by you) that Rust is a panacea with respect to solving all memory problems is a disservice to everybody. It is great that, in another response, you have given explanations of why some of the bugs you initially listed would not have happened in the first place. Quickly reading through them, it seems that most do not involve mechanisms specific to Rust (the borrow checker in particular), implying that these bugs would not have existed either if the code had been written in most of the other higher-level languages. And it seems that you yourself agree with that characterization: > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. So I think we should also stay open to other options than Rust, as they may bring the vast majority of its benefits without most of its drawbacks (thanks to all people that have brought up valuable information in this thread). Thanks and regards. -- Olivier Certner --nextPart2129665.oBscRyyxYM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmbewd8ACgkQjKEwQJce JidUShAAmbYF3XzPSGg4LtSplnr4F2mIxZhykTVaRVec69Ex16S94KAKuJqesLQP PBewsIFMyR/HwDAv49nIz2pw90iOfi+gOivTkU0HgU6PPs4IDHE01bc1umWOKrCy kcLaNXMjASzbYwRZ0eGY470AmZsL1yveqW4DdbjVEZanQKIqmQUOhDk5RNjoCY5f sjIhM5FkA7YzGqBMvosa/ACPZiC/5Y0l2Rs+OdDxRGq5lBLsljXmGiZeYV2sSlvL iPqG8zwaFMqpJ6xeQredEwFpQkEmvLqEfnegisfdEpESbI3+zImoPUm7u7REAtWC CuXBw4ej6dT4GZZphvgeYD1lcVV87K6YqSHnx2ima1gozMw4W4qoNDfUZdeP4d4J bkPTLvJWsnb3V5ZT6kmCGO7RzM9IS4VavalvIN1rTCOiKqarquHKMa1KVwoI0JUe 7sTGiWLpkrjHQZ1BJfusBWoSq4cgSYHcvbW/dI5a2RRjZ0jGcw4MkI5B5KEkJP1G uIbWjvShP7VObHogz69TvorEvdENlhYviG4bOoSNdKnSzPMhoaGirn1dU/PGOVGZ 4nh0GUi4GlPC5wQKPQ8zHVh5sz/ewA0vqsCVfrgycdVu2r3yppxA/8Oxafp6v29u LieqJQ2bzAo48CB9emNG8m8FDItwz3PCtZAIt0a+4418quBT+Y0= =kgK5 -----END PGP SIGNATURE----- --nextPart2129665.oBscRyyxYM-- From nobody Mon Sep 9 13:02: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 4X2P9n4yZ3z5W3np for ; Mon, 09 Sep 2024 11:04:45 +0000 (UTC) (envelope-from ske-89@pkmab.se) Received: from mail1.bemta32.messagelabs.com (mail1.bemta32.messagelabs.com [195.245.230.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.bemta32.messagelabs.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2P9m48hJz3xp6 for ; Mon, 9 Sep 2024 11:04:44 +0000 (UTC) (envelope-from ske-89@pkmab.se) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ske-89@pkmab.se designates 195.245.230.1 as permitted sender) smtp.mailfrom=ske-89@pkmab.se X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRWlGSWpSXmKPExsVyYCl7k67HtXt pBlu3WVls3/yP0YHRY8an+SwBjFGsmXlJ+RUJrBnn1m1iLpjMXLH4xkWWBsbTTF2MXBxCAtMZ JWZsXgDlLGCUeD97NVsXIycHm4CoxL7uu8wgtrCAnsSqPZ9Zuxg5OEQE5CUWnLcHCXMK2Eocb lkPVs4ioCjx7epjMJtXwFRi7urbTCC2kICMxKVFx9hBbAmBYInOi2+YJzByLWBkWMVoWpxaVJ ZapGupl1SUmZ5RkpuYmaOXWKWbqJdaqlueWlyia6iXWF6sl1pcrFdcmZuck6KXl1qyiRHo4ZR iluYdjOuvNuofYpTkYFIS5f3XeC9NiC8pP6UyI7E4I76oNCe1+BCjDAeHkgRvxQWgnGBRanpq RVpmDjDYYNISHDxKIrxGR4HSvMUFibnFmekQqVOMilLivPlXgBICIImM0jy4NliAX2KUlRLmZ WRgYBDiKUgtys0sQZV/xSjOwagkzNsMMoUnM68EbvoroMVMQIv1dO6CLC5JREhJNTCV7y9aUv h8a51Q7kxeO9eAZZ4Hsz56mDtuuiefePHfidNsnJtSpHdYB57Q/S49JTQySVe99c9FeeW5wn4 tn05WtCoWnGgrVWSYlZS4dfOLylUMdRNz5r46Krfy5COOR9esr3es4Okyb3u7xVikM3rPswmn 7HUK1YVD7VZffMFrevrQqUm9Gi19H/Ne+n78OfOdrzBzbLqLZ2jE77qkQ2aRn3O7575bvUPo3 Fa5qI47Cj/sviTMkplX3vhgyt+k+pmPWqr3Xu3cHa/jMue0Votf2NETqcHbW6qfvTkVHfb9YL COsE/Bo9Zb2jM9U4TlF6774nFL0bV0wt+nfFxMyyWvrudbkXb2f6yk9rGuabZKLMUZiYZazEX FiQDFjEp06wIAAA== X-Env-Sender: ske-89@pkmab.se X-Msg-Ref: server-2.tower-564.messagelabs.com!1725879880!14195!1 X-Originating-IP: [192.165.7.130] X-SYMC-ESS-Client-Auth: outbound-route-from=fail X-StarScan-Received: X-StarScan-Version: 9.114.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6554 invoked from network); 9 Sep 2024 11:04:40 -0000 Received: from unknown (HELO PSY-APP020.precio.lan) (192.165.7.130) by server-2.tower-564.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Sep 2024 11:04:40 -0000 Received: from berenice.precio.lan ([172.27.68.201]) by PSY-APP020.precio.lan with Microsoft SMTPSVC(10.0.17763.1697); Mon, 9 Sep 2024 13:04:40 +0200 Received: from pkmab.se by berenice.pkmab.se with uucp id aa20239 for ; Mon, 9 Sep 2024 13:04:40 +0200 (CETDST) From: ske-89@pkmab.se Subject: Re: The Case for Rust (in any system) To: freebsd-hackers@freebsd.org In-Reply-To: <202409060825.4868PDWO042319@critter.freebsd.dk> Date: Mon, 9 Sep 24 13:02:00 GMT Message-ID: <202409091304.aa20239@berenice.pkmab.se> X-OriginalArrivalTime: 09 Sep 2024 11:04:40.0171 (UTC) FILETIME=[1111EBB0:01DB02A8] X-Spamd-Bar: - X-Spamd-Result: default: False [-1.37 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.97)[-0.974]; NEURAL_SPAM_MEDIUM(0.91)[0.905]; R_SPF_ALLOW(-0.20)[+ip4:195.245.230.0/23]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:16509, ipnet:195.245.230.0/24, country:US]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[195.245.230.1:from]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_NA(0.00)[pkmab.se]; R_DKIM_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[195.245.230.1:from]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XOIP(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[] X-Rspamd-Queue-Id: 4X2P9m48hJz3xp6 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 On 6 Sep 2024 8:25, Poul-Henning Kamp wrote: > The C-stewardship situation has become increasingly intolerable to > me, and I have practically already made up my mind, that Varnish > Cache will migrate to a defined subset of C++, roughly corresponding > to where I think C should have been by now. What might that subset be? And how come Varnish Cache started out using C at all? From nobody Mon Sep 9 11:24: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 4X2Pch5q3pz5W6Qn for ; Mon, 09 Sep 2024 11:24:36 +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 4X2Pcg62yBz41vN for ; Mon, 9 Sep 2024 11:24:35 +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 8505489284; Mon, 09 Sep 2024 11:24:33 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 489BOWk2082765; Mon, 9 Sep 2024 11:24:32 GMT (envelope-from phk) Message-Id: <202409091124.489BOWk2082765@critter.freebsd.dk> To: ske-89@pkmab.se cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-reply-to: <202409091304.aa20239@berenice.pkmab.se> From: "Poul-Henning Kamp" References: <202409091304.aa20239@berenice.pkmab.se> 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: <82763.1725881072.1@critter.freebsd.dk> Date: Mon, 09 Sep 2024 11:24:32 +0000 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] X-Rspamd-Queue-Id: 4X2Pcg62yBz41vN -------- ske-89@pkmab.se writes: > On 6 Sep 2024 8:25, Poul-Henning Kamp wrote: > > The C-stewardship situation has become increasingly intolerable to > > me, and I have practically already made up my mind, that Varnish > > Cache will migrate to a defined subset of C++, roughly corresponding > > to where I think C should have been by now. > > What might that subset be? Initially it will be "better C compiler", but then we will gradually allow more and more of C++ to be used. > And how come Varnish Cache started out using C at all? We needed /really/ tight control with calls to malloc/free to get SMP performance: None of the relevant malloc's were SMP-aware in 2006. -- 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 Mon Sep 9 12:46: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 4X2RQw3pNcz5WJW9 for ; Mon, 09 Sep 2024 12:46:16 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2RQw3CnTz4Dyr; Mon, 9 Sep 2024 12:46:16 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725885976; 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: in-reply-to:in-reply-to:references:references; bh=0hPdbqbzO7FaYvh+NC8nbVMZ9iDb0oUlTOZ85UMW7iA=; b=YH+YWiksaJhRTmZCo5MoIBLS4ogB0+f9LE/OneYDGLNmQorCAn6ianywBhYqDevaQgT8aX bbEzX8dLLwMyAF72UnDU06kD1OxGBdXJjscP77rpQVBWh0zbM+RdGOokR0s4Mi4FebLnLi ly2RJDDhNlJlrDQ39SLYbwHfvvauCAszMCf/cF4LgwpEyOGgD2cSTTp0CZ4+bC65H2MbJi 5eMK5rv04UtyMlhdBJdAK2rU9pe1j04gFvM/QvAPVP+mCZ6UkjgUWhOCUEEWD0iVvnG+R3 octjQF3hDiJxSf+ZP8R031c/PC+4BWDjWIjUpy2NBhdDUNcQve3mNMAV+zc8YQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725885976; a=rsa-sha256; cv=none; b=Fv+eBeGWN9Uznk+A3vUsqMPiyCqzIrFfMKYrWyMQYrW0ZEuAifi+ld0bgQlE6zQQ7UFibJ s7R/o/JCb8hNTRvFniof5vQYV4xo+5mIn+sXTwjRtUAJ6RrEMaRvWCzaY5b+Kxw490+iBz PQKsmZF/a9tSTLmgfIznc1gilvUXHTfRCEISisuokeI8xp715MPwAJVRCw8uVDA9c4QbLH F3JK2IsIavDNDIgTDqZJRBnxB8YD4rNkfVlcKr4OpUFbNMdGPPLJ3ZW8bGyxFTKgrGwTvQ dlWxkvG/1ByLAfC0JYWewekke/0YjmkWi+paKjh+5wet8tqDtMPEIb/F4bggag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725885976; 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: in-reply-to:in-reply-to:references:references; bh=0hPdbqbzO7FaYvh+NC8nbVMZ9iDb0oUlTOZ85UMW7iA=; b=fB+K9FVQCxO6oxuq28QzafYvkr37F+DV5HiPfjCDVQmF20ulfghSaYAABgI30bJK5S6fFo 7Mnf5XkMoiFgTrBlsCTNhk2MXCwhBiqCjW6ojSbUzebQJkTlr0czk97f6Ck6eAbtJUxFDX UHkNuGxqjT/wE1crBbp37dS5bOGvwy0yV9L7g/ZMIgr00AyROyyJtgtW8OqiCWOZ2yxXsn H9goFJiYiWXzu09gW8KAV4zjijtyqK4avQhiogPSyqU3EE9rrvIm7FBwvjCx1eo/op1R2B 84WAqdO/SCZxrwb2mN8fhy3Wns/287/PmLpwN1EgPvHdbT3gJ4fEMKGZcdDoTA== 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 4X2RQw2btNz16nZ; Mon, 9 Sep 2024 12:46:16 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 75C4D6588; Mon, 09 Sep 2024 13:46:15 +0100 (BST) From: David Chisnall Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4DECCAE9-2F68-44CA-AEF5-C7C0B93B0F69" 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 \(3776.700.51\)) Subject: Re: The Case for Rust (in any system) Date: Mon, 9 Sep 2024 13:46:04 +0100 In-Reply-To: <202409091124.489BOWk2082765@critter.freebsd.dk> Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org To: Poul-Henning Kamp References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_4DECCAE9-2F68-44CA-AEF5-C7C0B93B0F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 9 Sep 2024, at 12:24, Poul-Henning Kamp wrote: >=20 >> What might that subset be? >=20 > Initially it will be "better C compiler", but then we will gradually > allow more and more of C++ to be used. In my experience, the worst C++ code is written by people thinking in C. = The second worst is written by people thinking in Java (or Smalltalk). This is where the real problems come in. It=E2=80=99s very hard to = characterise bad C++ in terms of language features. The same language = features are used to write good and bad C++. For example, virtual inheritance is can be used to build deep = hierarchies that are painful to work with. It can also be used to build = type-erasure where an inline template does the static checking and then = forwards to a generic interface, which reduces code size. Both of these = use the same feature, but only the latter should be encouraged. In general, a lot of C++ features exist for the purpose of building = abstractions and do not need to be used directly by users of those = abstractions. David --Apple-Mail=_4DECCAE9-2F68-44CA-AEF5-C7C0B93B0F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 9 Sep 2024, = at 12:24, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote:

What might that subset be?

Initially it will be "better C compiler", but then we will = gradually
allow = more and more of C++ to be used.

In my = experience, the worst C++ code is written by people thinking in C. =  The second worst is written by people thinking in Java (or = Smalltalk).

This is where the real problems = come in.  It=E2=80=99s very hard to characterise bad C++ in terms = of language features.  The same language features are used to write = good and bad C++.

For example, virtual = inheritance is can be used to build deep hierarchies that are painful to = work with.  It can also be used to build type-erasure where an = inline template does the static checking and then forwards to a generic = interface, which reduces code size.  Both of these use the same = feature, but only the latter should be = encouraged.

In general, a lot of C++ features = exist for the purpose of building abstractions and do not need to be = used directly by users of those = abstractions.

David

= --Apple-Mail=_4DECCAE9-2F68-44CA-AEF5-C7C0B93B0F69-- From nobody Mon Sep 9 13:13: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 4X2S1z3Ttgz5WMMj for ; Mon, 09 Sep 2024 13:13:11 +0000 (UTC) (envelope-from olce@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2S1z303Xz4HqD for ; Mon, 9 Sep 2024 13:13:11 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725887591; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=e8QAPxQLgGbZz3x7iGVz+TRTnwZSVFyIFs6fdjkc1GY=; b=yoys/OcWwSuQ4qF34w63M+pOFWZnoxxVXTZ7M9admDTwAhfzAO+/CiE3TqnarIcXgRPuPC /Dyf76HEadyFDk7ivVjpu4F+tsbIJWCvgFV9jzn17E7CqbRGcNqzv/ufBqK69n+K9jR+G5 KDGmF5QQaIRnDWm4iUXQcg6oB9YnUoECioysgV51d+Go7+FG2r8MDynTHiQXyykpK84Qbx 4im1tOgkRS+KnTZFXaXj+9EqVv4LtvD6dw3ZxJodUI88Ka2Tv9u3rbPMH1PvwlRfU5TySd IkhFSez7duzpRCUf13d8OQ4Kr0DpIbaBuOpqMief3rloJy1N1p+ZH6RndtJPpQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725887591; a=rsa-sha256; cv=none; b=TWlH2+keNjgoQdUbW1c5lwdv0gov78MP1T6RTg5F4C36KmzLSsDzwPRpmy6KWMNWHQZyoz dmA9sBq8RkTewaSHs+XJjGMeO1vKRnFhoGbwKmkgT97ArfP18c+mSCWFKZX7t9CCk+NpQz Wfjpr6LziLmENsPfLJO0seu5noaxghgNXP5xpfI25yYvwcLh9r2xOywtheyTr+PhINNwQk dwSqRwWJhQszhAemRtaTPsWO1b07zaMsqs23LUqFgljAUBd6gztQWTay+JhV2Y15zXsT7z m8NzpuiUPKS6Nh2onJNW/kxb+nHMNbOUJr5OFGaNKcEZqNP8Nkfn/4M/6RkSug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725887591; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=e8QAPxQLgGbZz3x7iGVz+TRTnwZSVFyIFs6fdjkc1GY=; b=Q6uMEi+5mWtTAufEtFkovRbzDo/cYtogUV3WAVbSq8NBeFtNHlnO0N4q/h+MxLir9WjJej JkgWPeln2LEzZIJoqGnZospF+WGoHcFRcFQ/+vi528LgHErI6Jx47fLyIuBfne9SOcQjI/ nAjGJ30e0bfbdFCeCkXJo6dF/aC2+p8HJt3e8u1djRLKTHrW4crUrtJyR3FYB4Not/g4Zf crJYrE70jp7qCviKjiBslCBBmt/iXvvkwZlrOLsQ799tZNOSXFM4bwCqe5oipDbos48QOo c6xYQuObUfavjipoGokBNOLutweKfiEOmVQ+n1KQ1AVOFqXnPGgu63Nq+00bUA== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X2S1z119dz16lL for ; Mon, 9 Sep 2024 13:13:11 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Mon, 09 Sep 2024 15:13:03 +0200 Message-ID: <2611284.jQUcPV6jne@ravel> In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> 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; boundary="nextPart7709059.0tso6FeFia"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart7709059.0tso6FeFia Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Mon, 09 Sep 2024 15:13:03 +0200 Message-ID: <2611284.jQUcPV6jne@ravel> In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> MIME-Version: 1.0 Hello Poul-Henning, > But a FreeBSD system recompiling itself from source is even rarer. > (...) > Beware of selection bias. > "Somebody who compiles from src" is almost the literal definition of "committer". > In terms of all the FreeBSD running hardware out there, not even > one percent of one percent of the machines compile from src. You're most probably right. At the same time, I'm having a hard time finding this angle of the number of machines compiling 'src' even remotely relevant to the debate. As part of determining LLVM's position in FreeBSD (and, in fact, more), the crucial questions seem to me to be: For which uses do we need to compile from source and what is the importance (in the widest possible sense) of these uses to the project? To state the obvious, committers and developers have to build from source, so it must be easy for them to do so, and must *remain* so. But there is much more. Building customized version of FreeBSD is very useful to fulfill at least these needs: - Usability/Performance: Stripped-down OSes for embedded platforms, and more recently VMs. - Security: Reduce the attack surface by removing not used components. - Appliances (for the various reasons above). - Experiments: Experimental options, drivers, etc. Being able to re-build releases in a controlled environment (with their associated specific version of the compiler) is useful for maintenance (bug fixing, debugging) and security (build reproducibility). And compiling from source is likely also very valuable for attracting new developers. From an educational standpoint, it may foster adoption in the cursus of more universities, raising the exposure of students to FreeBSD and our chances to have them as developers later on. These are already prominent reasons to make sure that building from source is not only feasible, but actually *easy* to do. And I'm sure this list is not even complete. > LLVM does not belong in src by any sane criteria, and any microscopic > benefits of "tight integration" can be delivered with a "toolchain-llvm" > (meta-)port. The benefits of "tight integration" are by no means "microscopic" (easy to setup environment, reproducible builds, compiler bugs workaround, etc.). I wonder what makes you think otherwise. However, I agree that tight integration per se doesn't necessarily require having LLVM/clang's code living in 'src'. It could be achieved through something like a port, although for now it's unclear to me if exactly a port as we have today would be feasible or desirable (more on this below). The external toolchain infrastructure is an already existing step in this direction. If we chose to build on it, I think what would be missing is: - The way to record a dependency to a precise version of the compiler(s) (plus custom patches) needed to build the sources. - The ability to easily (a command away, or even automatically as part of the build) grab these compilers in binary form. - Same, but to grab their code (and apply patches) and build them with some already installed compilers (the result may be used directly to build 'src' or as a boostrap). But see more below. > We need to find a contemporary and useful answer to "What is FreeBSD?" I think you've answered part of that satisfactorily in your initial mail already: > Delivering a single consistent userland with the kernel has stood > us well for three decades, and we should stick with that. I'll add: - A system that is easy to build and tweak in practice (for developers at the very least). - A system that is self-sufficient, in the sense that, once installed on a machine, one can set it up to do whatever one would like without having to boot something else (e.g., further software installations must be possible over the network or from some USB key; so it must include some tools to support the network, etc.). - A system with looked-after architecture, quality and ease of use. I know you said "consistent" but I expressly want to state what I consider the most important aspects of that notion. >From these statements we can draw a lot of implications, assuming people agree with this list. Below, I'll limit myself to those in connection with the need to easily build from source and externalizing components out of base (for all software, not LLVM specifically). Having a port for the 'src'-required compiler(s) or other components of base certainly has advantages (the machinery to fetch code, apply patches and build already exists), but in this light also has drawbacks. First, it becomes less straightforward to work (inspect, modify, etc.) with the code to be built. If following the traditional port model, the pristine code would be fetched from upstream, and our modifications would be made available through ports tree patches. Producing the final source then requires applying the patches (the equivalent of "make patch" in ports) for each "remote" component one wants to inspect. If, instead, the project hosts already tuned source code in the form of tar balls, then there is the question of how to fetch them and unpack all files in a tree that again should preferably make sense to developers. Second, both approaches easily lose the ability to inspect the history of each remote component if not done properly. At worst, it is always possible to ship a '.git' directory, or equivalent, but recording somewhere the commit identifier and having the infrastructure to either clone the repo at the proper commit, or switch an existing checkout to it, would be much better. However, these approaches miss one important point: We don't necessarily need all upstream's histories, although it would help, but instead probably require being able to quickly check out which code was shipped with which release, or is part of some -STABLE or -CURRENT, now or at some earlier point in time, and upstream repositories obviously can't answer these questions on their own. So I think that, if we actually massively switch to external components, be they LLVM or not, we are going to need a fair amount of tooling to keep a smooth developer/security auditer/you-name-it experience with FreeBSD (those that require the source code and navigating through it). It may be that this is not deemed necessary for externalizing LLVM alone (I'm not a LLVM integrator, nor developer), but I doubt we can smoothly generalize the use of external components without it. Thanks and regards. -- Olivier Certner --nextPart7709059.0tso6FeFia Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmbe9F8ACgkQjKEwQJce Jic5Aw/9HBit2Oe218H135ZLAJY4RCxmpWhKtkcgV2jGU/uwUCxYC4m9+cD8kjWU aoPrn5gelvtHygoPdJxTS5yvRvvfRKJcWTx0+HPq01wNW6GwSRv6iUMb+swU/13g nkTViLPgzwCHRI7Ap2SZKXk9NOAJ5hVqz9F786jaVwvMRDGo9JRCw2jYnLESVqaj qG37xCp14H2p3wBUAcmTulrxesO5Be0M9ZjTxvt4+AEcEoQmzx6oUwQLBveKgD6U Un5Sh7Qef/52Y91AtO9y1IZ4MK0byuTKn+jVRYC8/cQFoplwO9fn8REAPb9O+ric ZPTl6q7+4BaGdOROkk9aou9/9RSJg2Od0iXHEQOd3rqdY3Zbn06OAKz7t/rA3ylo 57e04+4rSA448h5FxRW/3rNudRou1g47SScxs84IihSCQB7o0Lb+vw+uhtdGYi3Y 1wyDxTjrr4/WX3NzdzMyy6/bEBxQ/TgMa8suN6R+NcvYDewyFQ7t2GQpv6CVfIAO IuFyxMNqK9HR3Rdw9tufkybtZewoGhCl4QPVbUYq6Zb+bgCPSUE7YncDwa9LWRDT +jFEZ3J+EuKNSvV9AuEJZpwDG3PSoEvNvN/0SMg/k2zxITdh+XL/fGmRKT7hdKz4 r2yBnu3U0SI0it/KQ9rJ8o9IDTWt641N3NdPR9tSZvbdXD5o9Gk= =Q763 -----END PGP SIGNATURE----- --nextPart7709059.0tso6FeFia-- From nobody Mon Sep 9 13:32:23 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 4X2SSG75TRz5WQ3D for ; Mon, 09 Sep 2024 13:32:30 +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 4X2SSG3Ls0z4MMl; Mon, 9 Sep 2024 13:32:30 +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 75BBA89284; Mon, 09 Sep 2024 13:32:23 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 489DWNmO084207; Mon, 9 Sep 2024 13:32:23 GMT (envelope-from phk) Message-Id: <202409091332.489DWNmO084207@critter.freebsd.dk> To: David Chisnall cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-reply-to: From: "Poul-Henning Kamp" References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> 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: <84205.1725888743.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 09 Sep 2024 13:32:23 +0000 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] X-Rspamd-Queue-Id: 4X2SSG3Ls0z4MMl -------- David Chisnall writes: > On 9 Sep 2024, at 12:24, Poul-Henning Kamp wrote: > > = > >> What might that subset be? > > = > > Initially it will be "better C compiler", but then we will gradually > > allow more and more of C++ to be used. > > In my experience, the worst C++ code is written by people thinking in C.= = > The second worst is written by people thinking in Java (or Smalltalk). I dont disagree :-) But it's either a gradual approach or "never" because a rewrite in toto wo= nt happen. -- = 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 Mon Sep 9 14:04: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 4X2T8v6Dr0z5WTT0 for ; Mon, 09 Sep 2024 14:04:15 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2T8v5StBz4Qg1; Mon, 9 Sep 2024 14:04:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725890655; 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: in-reply-to:in-reply-to:references:references; bh=uLnzGW6nzjcrAi7dsw5Lw6XifXNbxggbt1rRyw8S8Dk=; b=pdJqZ9uQvYsz1WMLjTMCcdsOvseEyjVItZLW/ChRWx8WVBBOTmaFa25SQWwQozvkYW02ie z8wVuE3/gzwc8H93gY5nO+bFLb69hyDnS5vZNM/rPWOTSYdwiuuTjgkj5151gXx1jWatYY MH2T3hfDmlBBc1CRfIKS5b0uOGSqWK2tP0yG88EIaw11I2Kf8TjoQfsN70e4rNd/1UohHx 8kTzUUgpEDFPsZbsjPnZMAM7RmAnfw8//T3qA9wMITk1oOSAPNzE5TOrdor38ERcnBqHRC Vspy8hmoZ+sXCSZzv59knT/SpqQZu7tLTe2Ex5VqWLepwAbyRZJ1451r1eAWrw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725890655; a=rsa-sha256; cv=none; b=oVGUOpMELMGe8UHcIr15EQuulLMRxfm0aJrpBHdPwES67NT7NGkbv3s+QVvQYuW+xNxyPw pmLI3jIHOv6/WRDDppKlaqlhbMdXlcy80jInPCUG7/l8wR1CIZQXeeLt+k3g6MkCf1WDBm sYzVVIgGEnqy3lKNzqWGe1P+QVhhpi6CGBFlvH0a2iooQKPVtPn2JYp/rxEnYHRrCdtlRZ GVR++AKFmAuMu9XJQvP5yHPhW42dyVSANkZuqvQnblKsk4rhP+pbB81wSXWv4gulJvgC2d KV/KdlYr1dy39S5k8BH8YA84tPIrp7iO49lcbdQe61kmyyqcH/4uY3y6F/gSTA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725890655; 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: in-reply-to:in-reply-to:references:references; bh=uLnzGW6nzjcrAi7dsw5Lw6XifXNbxggbt1rRyw8S8Dk=; b=Q++TQN7gA9msYP0tC+6FxOqcgKnVQndWsmJcwrT1Lt++SQ5tG6KoH8wjap9QKKGd5jGcpl cOc9OPKmLZ1LmRg96U9uF8KNTkrZxRgEy1vlCHp1H4Lp16i03ttzAS7bjjQW7590IWTXGu SJVmKREbOAT6DfpTD45rMo7Ix3SJcpYWdKRMNZgTzg4CCCH809Y1HKN/HUQofpj7B27h1e 5/xc98EcffoBeAFKfstX+t5EaHFq6uZdK+SdA3WB6+ICnFSJ+yWFdxG/mltmifxPGEJ418 9X1k9rUMyzF4APx2D2h3vGf8JowOu1L06rsJam/hTcvzzLTv/GXAvIaaxQqBPA== 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 4X2T8v4nh0z1BS2; Mon, 9 Sep 2024 14:04:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 904BF658A; Mon, 09 Sep 2024 15:04:14 +0100 (BST) From: David Chisnall Message-Id: <014DBDFE-CD25-4BAC-9557-3CAC0F231FF3@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_1AE3ED46-081F-4B9D-8797-E058302870CE" 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 \(3776.700.51\)) Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Mon, 9 Sep 2024 15:04:03 +0100 In-Reply-To: <2611284.jQUcPV6jne@ravel> Cc: freebsd-hackers@freebsd.org To: Olivier Certner References: <202409031532.483FW0If007252@critter.freebsd.dk> <2611284.jQUcPV6jne@ravel> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_1AE3ED46-081F-4B9D-8797-E058302870CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 9 Sep 2024, at 14:13, Olivier Certner wrote: >=20 > Building customized version of FreeBSD is very useful to fulfill at = least these needs: I would add that Poudriere has *great* support for this. It can create = VM images and a bunch of related things. It can do this from a src tree = *or* a binary release, and can then build and install packages from = ports and add other overlays on top. I wish the release engineering team would adopt it, it=E2=80=99s far = easier for other people to reproduce the flow with Poudriere than with = the release scripts. It=E2=80=99s not perfect, but it=E2=80=99s better than any alternative = I=E2=80=99ve seen (for any OS). David --Apple-Mail=_1AE3ED46-081F-4B9D-8797-E058302870CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 9 Sep 2024, = at 14:13, Olivier Certner <olce@FreeBSD.org> = wrote:

Building customized version of FreeBSD is = very useful to fulfill at least these needs:

I would add that Poudriere has = *great* support for this.  It can create VM images and a bunch of = related things.  It can do this from a src tree *or* a binary = release, and can then build and install packages from ports and add = other overlays on top.

I wish the release = engineering team would adopt it, it=E2=80=99s far easier for other = people to reproduce the flow with Poudriere than with the release = scripts.

It=E2=80=99s not perfect, but it=E2=80=99= s better than any alternative I=E2=80=99ve seen (for any = OS).

David

= --Apple-Mail=_1AE3ED46-081F-4B9D-8797-E058302870CE-- From nobody Mon Sep 9 14:05:18 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 4X2TBL3MCFz5WTVX for ; Mon, 09 Sep 2024 14:05:30 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2TBL2Tdcz4RVP; Mon, 9 Sep 2024 14:05:30 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725890730; 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: in-reply-to:in-reply-to:references:references; bh=5EBiBPThigtU4QTaSfeKXrs1tdZHSWEuZNC3A+5+dUY=; b=cnRlB0HHzkLk6QIZ12pGwee/wdS7ojUe0Uje6GOS0rI9eQ0zMyJ4T/uGHl7HNqVlaT6fpI G8roHEl1cWyaloG7nXNV7phhTNtwVzTvZycvIcsAGujea3uWRwcDFVZ2ZkZ6Z5ktqFmp33 fLkpkn7zvM6Cu+jQbEUNUS+kYTdE/TJaOYm2Q77mV/5giBpIzrBCZkW/YkiGIvUbVVp6ze Tx2ahJZsY3NI3o0zK66QmIvFvWtL1ZVRPnaDmID0q4Fsb1loItWvMDcH3aobY6ES7yhvl9 G5qGZci8y3NdOpHfJq+VTbvs0dMy1YBBD7nW5YQTUUIc74baM31TfxaYjtFr+g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725890730; a=rsa-sha256; cv=none; b=ugqY6Vs4O5H+YqPuCkCdRmULLNsp3B2zpfO+NW9XMsEX53D/+5tmOKvdlAEtysL66s66sl LUBaGeLNq1n9MTHb4sBWxyrZ/GqKJiauhkSk9yClit50cNrEB50EALp3IHiX9qRL5mtEHd EBBDyJWsJO99iZJwngIIyTcI5erOKlPUuk9a5hBUOY2mdoHwfataF3+VLOqBZ6PJUBQerP dSMs5/qMd8UsNWssgH67CCSGSrGVzA9Z50tsmVMhecS7krIZkzwwE9I2S3D9W6VQtUktc9 uNxKUYeX4JZBnmjCGLapWBhkoAssagGRViRW5iRIcEyjgpnDuReA/4cjCqB17w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725890730; 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: in-reply-to:in-reply-to:references:references; bh=5EBiBPThigtU4QTaSfeKXrs1tdZHSWEuZNC3A+5+dUY=; b=JR7epwj10iiduuAlBjOJ52n4+CAWOhZezfb0uI7KlsIfvxanYhnjrY5wj36RPL/DddItEx 6MT/8BSpRgFLJra1DhHUOHGVoCOzo0HwcxtsHNuEYiVw3yRyh8uIFTJIf0LLHWbzf9GrJP 3aIY9Ra3r5a/0qYMvQ3A6OwZ0h4nJGyUUPkHcrfkwwsKNnPKK5I/qNWpz1KdcPCKXa/nVu OdBcQf8oEituKVo+LBxl3TbEDyOz+qbUf4+DJn4hyYbR9wC7nyEjjDuyaTXmZ6V5Rd/cyA 4uhj2xRaQh+HMHpLQnMtNri6EkgPQnkQebhr9Jyldg5d6NMluJE/PrC2/mrFPA== 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 4X2TBL23Cgz195k; Mon, 9 Sep 2024 14:05:30 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id CE4E3658B; Mon, 09 Sep 2024 15:05:29 +0100 (BST) From: David Chisnall Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F41FA23B-9308-470B-BDCF-4C679C745336" 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 \(3776.700.51\)) Subject: Re: The Case for Rust (in any system) Date: Mon, 9 Sep 2024 15:05:18 +0100 In-Reply-To: <202409091332.489DWNmO084207@critter.freebsd.dk> Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org To: Poul-Henning Kamp References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> <202409091332.489DWNmO084207@critter.freebsd.dk> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_F41FA23B-9308-470B-BDCF-4C679C745336 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 9 Sep 2024, at 14:32, Poul-Henning Kamp wrote: >=20 > David Chisnall writes: >=20 >> On 9 Sep 2024, at 12:24, Poul-Henning Kamp > wrote: >>>=20 >>>> What might that subset be? >>>=20 >>> Initially it will be "better C compiler", but then we will gradually >>> allow more and more of C++ to be used. >>=20 >> In my experience, the worst C++ code is written by people thinking in = C.=20 >> The second worst is written by people thinking in Java (or = Smalltalk). >=20 > I dont disagree :-) >=20 > But it's either a gradual approach or "never" because a rewrite in = toto wont happen. I agree, incremental change is always better. I just don=E2=80=99t want = to encourage anyone to write C++ that looks like C, because that=E2=80=99s= going to combine the frustrations people have with C and C++. A = gradual approach needs a simple step 1, but it also needs a step 2, and = then a step 3, and so on. =20 David --Apple-Mail=_F41FA23B-9308-470B-BDCF-4C679C745336 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 9 Sep 2024, = at 14:32, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote:

David Chisnall = writes:

On 9 Sep 2024, = at 12:24, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote:

What = might that subset be?

Initially it will be "better C = compiler", but then we will gradually
allow more and more of C++ to = be used.

In my experience, the worst C++ code is = written by people thinking in C. 
The second worst is = written by people thinking in Java (or Smalltalk).

I dont = disagree :-)

But = it's either a gradual approach or "never" because a rewrite in toto wont = happen.

I agree, = incremental change is always better.  I just don=E2=80=99t want to = encourage anyone to write C++ that looks like C, because that=E2=80=99s = going to combine the frustrations people have with C and C++.  A = gradual approach needs a simple step 1, but it also needs a step 2, and = then a step 3, and so on. =  

David

= --Apple-Mail=_F41FA23B-9308-470B-BDCF-4C679C745336-- From nobody Mon Sep 9 14:20:17 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 4X2TWk6Lzyz5WVrH for ; Mon, 09 Sep 2024 14:20:34 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2TWk4ZTvz4TDb; Mon, 9 Sep 2024 14:20:34 +0000 (UTC) (envelope-from eischen@vigrid.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.18.1/8.15.1/NETPLEX) with ESMTPSA id 489EKR4R044928 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Sep 2024 10:20:27 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Mon, 09 Sep 2024 10:20:28 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1C6AA24F-BB70-46F3-95BE-2D3993A8E7B7 Content-Transfer-Encoding: 7bit From: Daniel Eischen 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 (1.0) Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Mon, 9 Sep 2024 10:20:17 -0400 Message-Id: <7749E764-9EA4-4931-A3EF-370170F1DA9F@vigrid.com> References: <014DBDFE-CD25-4BAC-9557-3CAC0F231FF3@FreeBSD.org> Cc: Olivier Certner , freebsd-hackers@freebsd.org In-Reply-To: <014DBDFE-CD25-4BAC-9557-3CAC0F231FF3@FreeBSD.org> To: David Chisnall X-Mailer: iPhone Mail (21G93) 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:6062, ipnet:204.213.176.0/20, country:US] X-Rspamd-Queue-Id: 4X2TWk4ZTvz4TDb --Apple-Mail-1C6AA24F-BB70-46F3-95BE-2D3993A8E7B7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Sep 9, 2024, at 10:04=E2=80=AFAM, David Chisnall = wrote: >=20 > =EF=BB=BFOn 9 Sep 2024, at 14:13, Olivier Certner wrote= : >>=20 >> Building customized version of FreeBSD is very useful to fulfill at least= these needs: >=20 > I would add that Poudriere has *great* support for this. It can create VM= images and a bunch of related things. It can do this from a src tree *or* a= binary release, and can then build and install packages from ports and add o= ther overlays on top. >=20 > I wish the release engineering team would adopt it, it=E2=80=99s far easie= r for other people to reproduce the flow with Poudriere than with the releas= e scripts. >=20 > It=E2=80=99s not perfect, but it=E2=80=99s better than any alternative I=E2= =80=99ve seen (for any OS). +1 The ports tree never seems to have the defaults I want, it's great for setti= ng and remembering those options, then building based on those. -- DE= --Apple-Mail-1C6AA24F-BB70-46F3-95BE-2D3993A8E7B7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sep 9, 2024, at 10:04=E2=80=AFAM, David Ch= isnall <theraven@freebsd.org> wrote:

=EF=BB=BFOn 9 Sep 2024, at 14:13, Olivier C= ertner <olce@FreeBSD.org> wrote:
Building customized version of Free= BSD is very useful to fulfill at least these needs:

I would add that Poudriere h= as *great* support for this.  It can create VM images and a bunch of re= lated things.  It can do this from a src tree *or* a binary release, an= d can then build and install packages from ports and add other overlays on t= op.

I wish the release engineering team would adopt= it, it=E2=80=99s far easier for other people to reproduce the flow with Pou= driere than with the release scripts.

It=E2=80=99s n= ot perfect, but it=E2=80=99s better than any alternative I=E2=80=99ve seen (= for any OS).

+1

Th= e ports tree never seems to have the defaults I want, it's great for setting= and remembering those options, then building based on those.

=
--
DE
= --Apple-Mail-1C6AA24F-BB70-46F3-95BE-2D3993A8E7B7-- From nobody Mon Sep 9 14:21: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 4X2TXS1bCqz5WVt8 for ; Mon, 09 Sep 2024 14:21:12 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X2TXR61m5z4VJ3 for ; Mon, 9 Sep 2024 14:21:11 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 50082 invoked by uid 89); 9 Sep 2024 14:21:05 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 9 Sep 2024 14:21:05 -0000 Message-ID: <5ee1059e-cc6b-4b75-a568-b06ba3042d2d@digitaldaemon.com> Date: Mon, 9 Sep 2024 10:21:04 -0400 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 any system) To: Poul-Henning Kamp , David Chisnall Cc: Warner Losh , Kristof Provost , Alan Somers , Dmitry Salychev , FreeBSD Hackers References: <202409082111.488LBTtI074660@critter.freebsd.dk> <202DD893-B152-4B38-AE9B-862E08785396@freebsd.org> <202409090739.4897d92v078621@critter.freebsd.dk> Content-Language: en-US From: Jan Knepper In-Reply-To: <202409090739.4897d92v078621@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X2TXR61m5z4VJ3 On 9/9/24 03:39, Poul-Henning Kamp wrote: > -------- > David Chisnall writes: >> On 8 Sep 2024, at 22:11, Poul-Henning Kamp wrote: >>> The logical progression of C++ adoption would start with using a C++ >>> compiler as a better C compiler. >> Compiling C as C++ will *normally* give the same output, but not always. > But do you agree that the C++ compiler's take on things make more sense > than the C compiler's in these cases ? > Yes. From nobody Mon Sep 9 14:29: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 4X2Tjb0Qccz5WXH0 for ; Mon, 09 Sep 2024 14:29:07 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X2TjZ6wQ5z4Wsr for ; Mon, 9 Sep 2024 14:29:06 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 51200 invoked by uid 89); 9 Sep 2024 14:29:06 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 9 Sep 2024 14:29:06 -0000 Content-Type: multipart/alternative; boundary="------------7REj93NxGwsfgELJ8gCO60Mf" Message-ID: <51c6d673-fb78-4c9e-a01f-427a3cbbc1d7@digitaldaemon.com> Date: Mon, 9 Sep 2024 10:29:06 -0400 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 any system) To: David Chisnall , Poul-Henning Kamp Cc: Warner Losh , Kristof Provost , Alan Somers , Dmitry Salychev , FreeBSD Hackers References: <202409082111.488LBTtI074660@critter.freebsd.dk> <202DD893-B152-4B38-AE9B-862E08785396@freebsd.org> Content-Language: en-US From: Jan Knepper In-Reply-To: <202DD893-B152-4B38-AE9B-862E08785396@freebsd.org> 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:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X2TjZ6wQ5z4Wsr This is a multi-part message in MIME format. --------------7REj93NxGwsfgELJ8gCO60Mf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/9/24 03:01, David Chisnall wrote: > On 8 Sep 2024, at 22:11, Poul-Henning Kamp wrote: >> Warner Losh writes: >> >>> I did C++ in the kernel in the 4.x->7-current time frame. >> The logical progression of C++ adoption would start with using a C++ >> compiler as a better C compiler. > C permits implicit casts from void*, C++ doesn’t. The last codebase I worked on that had gone through this transition was littered with implicit casts which made it hard to read. At a minimum, I’d want to add an always-inline templates wrapper around malloc that did the right thing, if not an explicit move to new/delete. I have always found this to be a benefit. Where C just casts away, C++ requires to 'review' to cast and show via a *_cast < ... > mechanism that the 'cast' is actually meant that way. > C++ places type and value names in the same namespace. There are some corner cases where a structure and a variable have the same name and sizeof gives different results in C and C++ modes. > > I have never found this to be a problem. They are indeed (rare) corner cases. (I also think I have noticed that particular C++ compilers at least warns when this might happen). However, I do think if compilation would be moved from C compiler to C++ compiler that particular coding standards have do be defined and followed. The proper standard being set and followed will prevent issues. --------------7REj93NxGwsfgELJ8gCO60Mf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/9/24 03:01, David Chisnall wrote:
On 8 Sep 2024, at 22:11, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

Warner Losh writes:


I did C++ in the kernel in the 4.x->7-current time frame.

The logical progression of C++ adoption would start with using a C++
compiler as a better C compiler.

C permits implicit casts from void*, C++ doesn’t. The last codebase I worked on that had gone through this transition was littered with implicit casts which made it hard to read. At a minimum, I’d want to add an always-inline templates wrapper around malloc that did the right thing, if not an explicit move to new/delete.
I have always found this to be a benefit.
Where C just casts away, C++ requires to 'review' to cast and show via a *_cast < ... > mechanism that the 'cast' is actually meant that way. 
C++ places type and value names in the same namespace. There are some corner cases where a structure and a variable have the same name and sizeof gives different results in C and C++ modes.
I have never found this to be a problem. They are indeed (rare) corner cases. (I also think I have noticed that particular C++ compilers at least warns when this might happen).

However, I do think if compilation would be moved from C compiler to C++ compiler that particular coding standards have do be defined and followed.
The proper standard being set and followed will prevent issues.

--------------7REj93NxGwsfgELJ8gCO60Mf-- From nobody Mon Sep 9 14:30:43 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 4X2TlS0P0Wz5WXTG for ; Mon, 09 Sep 2024 14:30:44 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X2TlR6J8cz4Y9L for ; Mon, 9 Sep 2024 14:30:43 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 51484 invoked by uid 89); 9 Sep 2024 14:30:43 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 9 Sep 2024 14:30:43 -0000 Content-Type: multipart/alternative; boundary="------------aCOccR0g6VOIvU1WcRG7zgMG" Message-ID: <256401bf-1b46-467a-a44e-42fc14d20ebf@digitaldaemon.com> Date: Mon, 9 Sep 2024 10:30:43 -0400 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 any system) To: David Chisnall , Poul-Henning Kamp Cc: ske-89@pkmab.se, freebsd-hackers@freebsd.org References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> <202409091332.489DWNmO084207@critter.freebsd.dk> Content-Language: en-US From: Jan Knepper In-Reply-To: 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:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X2TlR6J8cz4Y9L This is a multi-part message in MIME format. --------------aCOccR0g6VOIvU1WcRG7zgMG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/9/24 10:05, David Chisnall wrote: > On 9 Sep 2024, at 14:32, Poul-Henning Kamp wrote: >> >> David Chisnall writes: >> >>> On 9 Sep 2024, at 12:24, Poul-Henning Kamp wrote: >>>> >>>>> What might that subset be? >>>> >>>> Initially it will be "better C compiler", but then we will gradually >>>> allow more and more of C++ to be used. >>> >>> In my experience, the worst C++ code is written by people thinking in C. >>> The second worst is written by people thinking in Java (or Smalltalk). >> >> I dont disagree :-) >> >> But it's either a gradual approach or "never" because a rewrite in >> toto wont happen. > > I agree, incremental change is always better.  I just don’t want to > encourage anyone to write C++ that looks like C, because that’s going > to combine the frustrations people have with C and C++.  A gradual > approach needs a simple step 1, but it also needs a step 2, and then a > step 3, and so on. > Second. --------------aCOccR0g6VOIvU1WcRG7zgMG Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/9/24 10:05, David Chisnall wrote:
On 9 Sep 2024, at 14:32, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

David Chisnall writes:

On 9 Sep 2024, at 12:24, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

What might that subset be?

Initially it will be "better C compiler", but then we will gradually
allow more and more of C++ to be used.

In my experience, the worst C++ code is written by people thinking in C. 
The second worst is written by people thinking in Java (or Smalltalk).

I dont disagree :-)

But it's either a gradual approach or "never" because a rewrite in toto wont happen.

I agree, incremental change is always better.  I just don’t want to encourage anyone to write C++ that looks like C, because that’s going to combine the frustrations people have with C and C++.  A gradual approach needs a simple step 1, but it also needs a step 2, and then a step 3, and so on.  

Second.

--------------aCOccR0g6VOIvU1WcRG7zgMG-- From nobody Mon Sep 9 14:32: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 4X2Tnk2t03z5WXrN for ; Mon, 09 Sep 2024 14:32:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (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 4X2Tnk0zpCz4ZGv for ; Mon, 9 Sep 2024 14:32:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id nJQesW0jO9TOUnfRZsm8xC; Mon, 09 Sep 2024 14:32:41 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id nfRXs3frAKHV8nfRYsuKWa; Mon, 09 Sep 2024 14:32:41 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=XeEqz555 c=1 sm=1 tr=0 ts=66df0709 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=EaEq8P2WXUwA:10 a=Lyp7P1eCAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=9QGJU2wy-NVzNIaPe2cA:9 a=CjuIK1q_8ugA:10 a=us27MLTdiSMbcMS-4tZE:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 970E5CA; Mon, 09 Sep 2024 07:32:39 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 8F285AF; Mon, 09 Sep 2024 07:32:39 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Jamie Landeg-Jones cc: void@f-m.fm, freebsd-hackers@FreeBSD.org Subject: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) In-reply-to: <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> Comments: In-reply-to Jamie Landeg-Jones message dated "Mon, 09 Sep 2024 05:42:16 +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 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Sep 2024 07:32:39 -0700 Message-Id: <20240909143239.8F285AF@slippy.cwsent.com> X-CMAE-Envelope: MS4xfJgGbRvTGFw5fIV0z23SkWrZG+4/+wWgY79QdNGWddRxFkNPS2FHjP6QUHtOkjSunt9hzWBDyYGcrVYgmlJTES3iam8BOcE1mAnWEVDF38Of4ByV2ftU 9wb3xIUMXGBZ5sEvxiLChVWZey2/ORS5aaeKqJ0/l63uHTY+w4hFU9DKTJ55W1X1eh4Huf2JfidmJR6JRZO3i3O2m5U6KOTA32z1qJvsUEzwlLRyaGEgzMXt kMzSTeauZj31zzr4ESEeekrNn5/za0mL5QO2GtwoBDY= 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] X-Rspamd-Queue-Id: 4X2Tnk0zpCz4ZGv In message <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net>, Jamie La ndeg-Jones writes: > void wrote: > > > ? really? All my -stable and -current machines are recompiled from source. > > Is this really that rare? > > Mine too (well, I only track stable at the moment, and am only talking about > 8 > machines) > > I have too many local patches to easily do it any other way. As it is, i sync > src, patches are automatically applied, then make buildworld etc... is all > that's needed. > > Similar story for ports vs packages - too many patches (and custom options) Those of us who build from source and build ports, whether manually or through our own poudriere, are the minority. Just visit the FreeBSD forums. I attend OpenHack here. People who do use FreeBSD use freebsd-update and binary packages. (I use freebsd-update and binary packages on some VMs at $JOB, while maintaining my own network at home as any developer does.) And that's a marketing feature of FreeBSD. Most users don't want he hassle of building and installing an O/S. And a co-worker has set up an EC2 instance (thanks cpercival@). Out in the real world people use binary updates and binary packages. We developers are an anomaly these days. Just because a few of us build from source doesn't mean the rest of the world does. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Mon Sep 9 14:37: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 4X2TvT2XjRz5WY9h for ; Mon, 09 Sep 2024 14:37:41 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X2TvT20Kvz4bHb for ; Mon, 9 Sep 2024 14:37:41 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 52592 invoked by uid 89); 9 Sep 2024 14:37:40 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 9 Sep 2024 14:37:40 -0000 Message-ID: Date: Mon, 9 Sep 2024 10:37:40 -0400 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: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) To: Cy Schubert , Jamie Landeg-Jones Cc: void@f-m.fm, freebsd-hackers@FreeBSD.org References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> <20240909143239.8F285AF@slippy.cwsent.com> Content-Language: en-US From: Jan Knepper In-Reply-To: <20240909143239.8F285AF@slippy.cwsent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X2TvT20Kvz4bHb On 9/9/24 10:32, Cy Schubert wrote: > In message <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net>, > Jamie La > ndeg-Jones writes: >> void wrote: >> >>> ? really? All my -stable and -current machines are recompiled from source. >>> Is this really that rare? >> Mine too (well, I only track stable at the moment, and am only talking about >> 8 >> machines) >> >> I have too many local patches to easily do it any other way. As it is, i sync >> src, patches are automatically applied, then make buildworld etc... is all >> that's needed. >> >> Similar story for ports vs packages - too many patches (and custom options) > Those of us who build from source and build ports, whether manually or > through our own poudriere, are the minority. Just visit the FreeBSD forums. > I attend OpenHack here. People who do use FreeBSD use freebsd-update and > binary packages. (I use freebsd-update and binary packages on some VMs at > $JOB, while maintaining my own network at home as any developer does.) > > And that's a marketing feature of FreeBSD. Most users don't want he hassle > of building and installing an O/S. > > And a co-worker has set up an EC2 instance (thanks cpercival@). > > Out in the real world people use binary updates and binary packages. We > developers are an anomaly these days. > > Just because a few of us build from source doesn't mean the rest of the > world does. > > Probably... Used to compile on every instance of FreeBSD I run. Still do on many, but have moved to using freebsd-update on some. (Just learned Saturday that is is _not_ a good idea to try to update multiple classic jails in parallel (thus at the same time) with freebsd-update. ) From nobody Mon Sep 9 14:58:43 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 4X2VjG081Qz5WdRX for ; Mon, 09 Sep 2024 15:13:54 +0000 (UTC) (envelope-from dsl@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2VjF6kLtz4h7X; Mon, 9 Sep 2024 15:13:53 +0000 (UTC) (envelope-from dsl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725894833; 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=lNVu6AoIDEbr5qZ2PhtG1WCXZ5ElmdR2f7L5JwP0Kc0=; b=FZ5MTa2zyX9JZd8XJLJ9INInnZSEALpz5dqgi4zgDLzwkhBa9Ia9qZqsJcyBHDuxYjpQ6U pl3a6LxNX/Lbn6nEa+8rcl8BUcbQ76vWQgjGnIWRNUKzpicl1hGvIM3OymyTUPzdRGWLMl dQ0bwEBfomSfkRj/DnFLLjv4h0Xe7XM2smaXiYR06ejJmDc1XqLPhl705WXVd4uaLNLIWH J2w5ZqbbbISX4h3jZUYPjB7DhDUqzofIcQHjahmgDzunoqDLRCCoS7aIxsb4p36N7XfKDu 49j/8pJDnzLcIoXS8UDH0qMK9eF5+ZJr/+M57C0A+oDsbnZqC9vTv8tdgYb3rg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725894833; a=rsa-sha256; cv=none; b=k0VxUNcTjLsO8L+88xCepaiFSQcN/CycMAuZXwj4AHDDXIgN2GZLLjfxff3bnafZIJRq02 SoFwWjtyN1OO/yEvRXY0rCRXR87rviNszSX0BCfD0a3/3414SVrszTct6Et22JOInFYpgp jMXu/O3e9gDlkaOcFFJz++nqKrStgMFrtPnM4OqZx90uOuu6qnio+NHzCcbH6n/PxZkxZZ r4kv7kocshQTQJ1zrdE8kMILfRyg0oeNACWQVe+40Dxuh410NlTQTXeXAAijmnlmffqdjX tE57TnzyQ0euYaDGePzD2hNFu45z2Qc6OCRDFZh40t1zEeHaNB9IDIZPJL9naQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725894833; 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=lNVu6AoIDEbr5qZ2PhtG1WCXZ5ElmdR2f7L5JwP0Kc0=; b=GK+n55fRnqxSU60e7CD/c7c77rYkrYkqrz/TWA6gVnLleGaWNimx8MWHL/xDzkuxMVMsoV /l6uUta4dbY4LMet8+UoxxfJj0G6C1WhU3mzXwJo7Unk58Iy1ITyNqW4fDQ44LPVLUwnpF jrwuMMxgI3/a3GE0tmCpjpxmBDzOC2WJVvpGqOh2exXxDkARGIhE2EWAN8Eg9bTP/fmiAB /oFzxuW114h+y2OVCa1Np2rCCcJ52/EFLYl2XHMJvYc+50AShGBtjn90dkMzB6ndH1P0Vx SjEX6Td7LWyCCJuW21x5lVfaoNXhOBYLB24k3VIl1PBA9UItuHoFOw+WIEmW5Q== Received: from localhost (unknown [91.226.51.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: dsl) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X2VjF3ZHqz1CSQ; Mon, 9 Sep 2024 15:13:53 +0000 (UTC) (envelope-from dsl@FreeBSD.org) References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> <202409091332.489DWNmO084207@critter.freebsd.dk> <256401bf-1b46-467a-a44e-42fc14d20ebf@digitaldaemon.com> User-agent: mu4e 1.8.13; emacs 29.4 From: Dmitry Salychev To: Jan Knepper Cc: David Chisnall , Poul-Henning Kamp , ske-89@pkmab.se, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Date: Mon, 09 Sep 2024 16:58:43 +0200 In-reply-to: <256401bf-1b46-467a-a44e-42fc14d20ebf@digitaldaemon.com> Message-ID: <868qw0uafp.fsf@peasant.bootbsd.com> 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 Jan Knepper writes: > On 9/9/24 10:05, David Chisnall wrote: > > On 9 Sep 2024, at 14:32, Poul-Henning Kamp wrote: > > David Chisnall writes: > > On 9 Sep 2024, at 12:24, Poul-Henning Kamp wrote: > > What might that subset be? > > Initially it will be "better C compiler", but then we will gradually > allow more and more of C++ to be used. > > In my experience, the worst C++ code is written by people thinking in C.= =20 > The second worst is written by people thinking in Java (or Smalltalk). > > I dont disagree :-) > > But it's either a gradual approach or "never" because a rewrite in toto = wont happen. > > I agree, incremental change is always better. I just don=E2=80=99t want= to encourage anyone to write C++ that looks like C, > because that=E2=80=99s going to combine the frustrations people have wit= h C and C++. A gradual approach needs a simple step > 1, but it also needs a step 2, and then a step 3, and so on.=20=20 > > Second. I've mentioned MISRA C++:2023 already, but would like to elaborate on my idea behind it. It forms a subset of ISO/IEC 14882:2017 (C++17) by introducing guidelines which are "directives" or "rules". At the same time each guideline falls into one of the "mandatory", "required" or "advisory" category. For example, there's a rule 13.1.1 which prohibits classes to be inherited virtually, but it's in the "advisory" category at the same time. Rule 13.3.1 states that user-declared member functions shall use the virtual, override and final specifiers appropriately. It should be less time consuming to analyze existing guidelines prepared by MISRA C++:2023 and form steps simple enough to be adopted by the project, I think. Regards, Dmitry --=20 https://wiki.freebsd.org/DmitrySalychev From nobody Mon Sep 9 15:15: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 4X2VlW5sBZz5Wf76 for ; Mon, 09 Sep 2024 15:15:51 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2VlV6jFSz4jCk for ; Mon, 9 Sep 2024 15:15:50 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=CrLWGd7o; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::b36) smtp.mailfrom=tomek@cedro.info Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e02c4983bfaso4650021276.2 for ; Mon, 09 Sep 2024 08:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1725894950; x=1726499750; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=zx6RDYu3hKnaNKrJhLdAahXdtZGy20SdovKTBwPANpM=; b=CrLWGd7o1Cb4/QAOWuWkiIrkpwbVX9F3ths4PdelCz0u8SnHRH8dXuhtXhumZFOdSH ms/1ZKiB5SrsZO5eEoJr3P8d8fBdoHrAKF4CRiX+aUPavkN9wPfsBr0H0IypMlLzSMwe wVvHphTolLJoNFsZSVeytXyOsbWDpGULBqOTMNJwAoHfA6bSKbk9cdQOWbPRPndpDcGg bVB+EpQmm07bQ5yNRT1d6enEC45yI9XQcPD4bUCiTj0p9+B8bsT0IFB72QqagVVKwUtk uDBrBAcRTWeBne6asyDtbNa0u1EPvLNPZnFEQxlAnn1eAURnmFFmsQ91nDTtQdcoWnVc rkaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725894950; x=1726499750; h=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=zx6RDYu3hKnaNKrJhLdAahXdtZGy20SdovKTBwPANpM=; b=tErh2R87FKxysDU3OfBV+XKZHYDR3dm1o+2tit+v9ceUg5BtCy548ouGi29c9Ku31g aYFxluHCAOmT2XaoMlDJ4icWJhlPRnbXO212B2pzCCnae4c7/D/Fjvxf/xqNvljz2Zw6 zL0b9pb6caKCjkq8Khl7bbiY7YAWdokkplLzAsl8e1tma5XX63KhMMEIzUjmNl7V4j3p jB8vPavynfs5TYOw6UlnTlWq15sYtqg1bYUl3t8+llZkqrUlVj8HwME/EhefwvCMKrxK dE+L8reqYbSn3//AlQ/YE6DHm8McSlatQ1GGtAZUmv1ha3c11pNjMfaVKhYX5yAVYzzP jYkA== X-Gm-Message-State: AOJu0Yxsc/G8m0bGYUMIlT0vsr5UJXeg8EanipR7lTtbfEBWzAdhVBqN feTqAV5hsEWIIZkeECUkq6/gkeJfILXg+1SnB3QdjDPtWV+QX1iznyUKZR+b0VON29BhUjsFpF8 = X-Google-Smtp-Source: AGHT+IGwGNf2mu7kuxTxxXtbM2sImINr+UebnSNW21RDeG2FFRQFQb4rE6Y6fm+YAnfkmOlNA4GPfA== X-Received: by 2002:a05:6902:1887:b0:e13:d0af:b1fd with SMTP id 3f1490d57ef6-e1d346b68abmr14060023276.0.1725894950155; Mon, 09 Sep 2024 08:15:50 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6db5c6fdaa5sm9424597b3.139.2024.09.09.08.15.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Sep 2024 08:15:49 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-e1a9b40f6b3so4847852276.1 for ; Mon, 09 Sep 2024 08:15:49 -0700 (PDT) X-Received: by 2002:a05:690c:6612:b0:6b9:7fbc:b0f7 with SMTP id 00721157ae682-6db4f79dcb4mr111204867b3.21.1725894948262; Mon, 09 Sep 2024 08:15:48 -0700 (PDT) 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: <202409031532.483FW0If007252@critter.freebsd.dk> <2611284.jQUcPV6jne@ravel> In-Reply-To: <2611284.jQUcPV6jne@ravel> From: Tomek CEDRO Date: Mon, 9 Sep 2024 17:15:36 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[cedro.info]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b36:from]; 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)[cedro.info:+] X-Rspamd-Queue-Id: 4X2VlV6jFSz4jCk Olivier touched nicely core of FreeBSD design - logic, simplicity, coherence, self sufficiency, repeatability, compartmentalization, and many more - all those come from current / historical design of the src NOT the proposed one that leads to avalanche of new problems and complications mentioned by Olivier. I fully agree here. SRC contains both source code of the operating system and all tools to build it in one place. No matter what version / medium / transportation / storage (release / commit / package / zip / tar / git / svn / whatever). This keeps things simple coherent and self sufficient. Zero dependencies nightmare for the user. Yes, building from sources is the foundation of Open-Source, and SRC that keeps both operating system along with versioned patched ready to use build tools in one place is so non-problematic that people seem to have a problem with that. What is more that simple change in design (aka "lets remove build tools from src") sounds not even like fake innovation but more like purposeful diversion - divide core component and then divide divided until project stops and people leave because others do it better anyways. I humbly assume this discussion to be more of a thought provoking experiment rather than a serious technical proposition :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Mon Sep 9 16:52: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 4X2Xvl6hLxz5TNt7 for ; Mon, 09 Sep 2024 16:53:07 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic310-11.consmr.mail.ir2.yahoo.com (sonic310-11.consmr.mail.ir2.yahoo.com [77.238.177.32]) (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 4X2Xvl3h5Lz41lN for ; Mon, 9 Sep 2024 16:53:07 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725900784; bh=MmlWz8MpHHSQoh0M+BMmdK3Q/Dmd3gF7r1hvmCP+3Ek=; h=Date:From:To:CC:Subject:In-Reply-To:References:From:Subject:Reply-To; b=fYx9O2tTMPmsgpxeIATJ1yhlLLlZzGw64riXTwil0G06ilhsgVyFmsuML1cDN8XRlcLgofGr3vMD+EqssqXDbS676wODQ1ruG0jxj9/Lgv+3PAqCtakuUnGCXyB42147fP9EEty135ZWBPyXhAyqM8VwnEbjh5zbiwH1TWNBxEvirMX8EidtQU1fKXl+49yzEunyO+aqXZZPKRgIJfQFkYGwOSsZvyR43mCuLtvB2djXLuXquiNu0K7e1Q1wMTsO7acCdIlxSeorqKlV/j+tZUlHEt4aXEWeD+OQfcDp5ns0QU3Zb9qbAcnCQmHMGeR77M6upSezx3D4AZ59qZV/kg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725900784; bh=1iJ0bkTEj/AGQghZcNsCWDkaLlF6/OabB1x5Y/feP/D=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=C5KVA5q3s7mCNaL6BI5Q+30NnyDD2NGNNxp2GXsE5z1kZAkePidgsAMljquiuG+bAsKhre3bsMajYkILf+vhjxgv6k5OGarU4wR5fKIUZrHR6jAcSJkmnVyXS4hyic4aGIXbkoCtVdsFc+Fa+3/hunnB4z0W1RNCBx6gZuSS6rIHmt6xL6y9uQ72TY7JPWajytm50HQbm8RWnueKc+KI7bC4OBkyo5OR68AwpiWPP/SnZVD+yK8s9mrryjO98hxnshkbeWXrNBmYj1SgR6hqrhggyMPrUwcuUnJFrChu7a/oH8GLu0q8ppGpvuwIv5DdFNVJIX4HVv4gccv0h+JhJg== X-YMail-OSG: RqHEI9IVM1kcDUoNN6IIEx41QzhZZWKeZXVJ6PyHZsSzX4eaoaSfVEYLFsCTAGM _1ka7cFk.1NCYyQVJizYFYJ.v_e.xwsybWkXibkeIzfqRTxtfMKpgeez8QmCGKpPXfPEw5fGjt.0 qrXxL9rthFcNigY32rHejqgVIHYhxHOdDHk6m3NwGX638b7qQHMD.e52LCowmzIc_ngvImGRCpf0 naKxdhJVYcmGkFDQPVJ9InFr3ite7h0stjPH1b5PF1oZ8x2C5USiBQL_Uag4hbsGers_N_zrPlJH PcTvyesZwfFRd_G3z0._uXfdDTyvHlmJdMUie0AO2HnLYJZzL2dYQ45fmXUvUxRoK0BL___2Yp5K G_yL7cenhktpZuNG37QmlGaEocasWnzgkTCvxoWivMAAEnr3NNpyvBQfiNN_fkFTNDJgQ3_GQVjB R2.EKD9.TI5EwcBzTa1Toc37EUL.MfpVtlXu_haBNLBteBDP44ED20B0uDoZlt3szaHOa1Ac7sAc m1xMqiXUaYAOTh_vjy_pDtiZHI7twLwjHMcnr6f9q1ySbevJf.sIWlmRKtpT_QWp0OYPopijB2c9 y1Or._.510D5PbttwhWv1LyusxmrKwy3gEoq6jdcZw_8Wt1BzkvNvbGZZL8f1.qaMkfyWeOcm7Vc 3uZbM6noV_5Uk_iyxEr4iDXLz8zCT1G_DnviAoas3WGM8G4XdRfd4fALRnGfj12PmGBK5e5MNQr3 SKu1blA.0Uv0rdDa2uGexpBWoXzTgdnNMkWYvLW1hDN0EQ5ChHpBq3j4uxmqz7hpaI6EZ4A_nD7p tV9sFWMl4xwNvz0M3_mAzCza.BH0iaMKxP5KnWduNal.RDA1WKkzPYoVCK3YTuTFnhBGC69YJa.p OpTiZvomHwm7g6_ISfd_iYt64d1erXP0SDjWFYKwMP0HvcFMXHrJswVbq4aQmM2Ge1ChxdhqRH8T MKCfppPYuk1H9UP4uHewMl5gulR7i2l5BBUplPPZT.YaCgsJTQI.3LlJ.z5puVMIREFwCczDZ48S .ilUmOCqDJ.JD5hPuvx1nmb9lzEhi1Xxx1xHUD7QjxgWetasuYaTFtydJD5czdL30A8Kya9Smg90 S8HScV3MGtXHnU0ZsV9JON0Lk4T58XAbtam01M96n37PU9Kh69Qe5Y_1JbKICQeV7z.ug_0Jaczo eAFRuAAId.bcJG3R363ojiVxohZulz7m7I66tKFNmLyMxww9uZhWkF5IRJY.EM.QYhzRjIdmpUvA 6hqZ1ZTM6yyLqOM7o5oaJifz.Kksjs9QJQsLz29Z0nW1pK74sGALi3so5Fwbtg5BfjGO2pPB1m1v m0lmVcAn542wa9VtaOQbNb46BzoHCd_DtF7vDblDm0xv3.7HU0OQ0V05fMAVsrMvVU831nyZO_.i 6ZuGOmTUMPUq63BRqPdP.n_UOB8n5eo.BNeHuogCAuWf3q_RJuwtVqpuqaBET3UtaUzOx6.j5rPU eb9BXLCZdQJy9kgy5jb5iOEcCpOPEU_x3mCUjmgLutcN8Dm7OKJvNHCKD10iMYpFpP0LeLelWXNB Z_1L1p739M1GICcBzhxU_Ez_rRFnPmpNORAbdXQSh3I4DKbM6qZN9iqAdemR4gwwuq2sD_PpegJN A1vqTF3qEE95.uVR3A5aOYH9sBQNk664oLJ9jD3Zi2_cCInbvHR_0IHvRTTo_VdGMgJ1Y.3xTzmG TQeGP7j1dUfs0aYCSGwpvkRyXuYd.XgXOnko95oQ6Ocgq0787WO5PdQa2JpPHW.6hK4xf.NteA.u blEbZf2gzB7an0Y7BS43BhKjq82bTWPUfl4r2ruFlyZFmdgIFekFziYdP6fcym7wjset7j6hpt5V jUQ0bfppKKONTXlz8FiagWpgcqptf0oie9Asu_vUckaSFkJX6qhX8hoNRQxuffUOohomIHhVsoE4 f8UIPRGiTblBHA7L.4TCuY7.FbRxVpjA16XK7.lKRfeuj9Q4A8CtUv8DFBadwsK1Bz.7MGIAS2yM pdy8hM9c0XA0ZvKv7zDNck0jmSUxr6PHdqWOMbzwCk3Co2XNf2ygpRY.Flm2NTXFkeCKQ82.cz6g ejDJgy_76gSrK4zRg3pOy6PDog0ZwFb7OIONRC0vxcWsC0YR58guGijJYgX4c3TRR1ACkzAjkZJU 6ppRyC3SieFkvB2QkuMKTJ58fk_rjI304AN7d2kOLpQMH X-Sonic-MF: X-Sonic-ID: 749399d6-ca1c-4fa9-bab0-710fa211687e Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Mon, 9 Sep 2024 16:53:04 +0000 Received: by hermes--production-ir2-6664f499fc-6rh2p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 82ba2ade21d5f56be7de27a84d4fb14e; Mon, 09 Sep 2024 16:53:03 +0000 (UTC) Date: Mon, 9 Sep 2024 19:52:58 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <8410656229.20240909195258@yahoo.com> To: Cy Schubert , Jamie Landeg-Jones CC: void@f-m.fm, freebsd-hackers@FreeBSD.org Subject: Re: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) In-Reply-To: <20240909143239.8F285AF@slippy.cwsent.com> References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> <20240909143239.8F285AF@slippy.cwsent.com> 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-Mailer: WebService/1.1.22645 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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:34010, ipnet:77.238.176.0/22, country:GB] X-Rspamd-Queue-Id: 4X2Xvl3h5Lz41lN Hello, Cy. You wrote: > Those of us who build from source and build ports, whether manually or > through our own poudriere, are the minority. I think a proportion of FreeBSD audience who build from source vs use binary is directly correlated to years of experience. If a recent Windows update prevent users for doing something and there is a samba fix... But only for latest samba version which still not in ports collection... You have only one way: rebuild your production samba package with applied patch. Things goes smooth if your production package is locally builded, you use poudriere overlay with this patch to get the same samba version with the same dependencies matching those already in production. All other way are very painfull. Binary updaters vs source builders are splitted by the point when they hit such a things. Consequently, persistent user who prefer binary update inevitably become a source builder. In my humble opinion. -- Best regards, Anthony Pankov mailto:anthony.pankov@yahoo.com From nobody Mon Sep 9 17:38: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 4X2Yx64ghpz5TVvc for ; Mon, 09 Sep 2024 17:39:22 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) (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 4X2Yx60BS2z47rX for ; Mon, 9 Sep 2024 17:39:22 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b="iJGMU/1f"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="c M3c5uU"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.144 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id D35AF1380230 for ; Mon, 9 Sep 2024 13:39:17 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-05.internal (MEProxy); Mon, 09 Sep 2024 13:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1725903557; x=1725989957; bh=T66RGLRjRlYoaCaX2e7cnnTyICovLz77Jz8U4Opqa98=; b= iJGMU/1f9nKxSpinKYzbTDGyAaZ1WdrQwUkRgVtNadyfOwzH1cpuLwWjtJahp5Kr 5VileraqjzuL8/Ut4ahqjx0mu3outfkTvJiM4hv3axbOfeiCMfliYf76SYAN/tna q5D//t1pmFlqUFsX1MJ/yGQMpGEeSmv+0yok1K9uduRwEefDwpYrXMRMI7mptZsh +htShpeCwXPhfFRCzvHIi0n/g4lrWJ7AhXQjDra3jcwXV7zPEz+mPKisovCNxMPg XmrxZ56S4NERwaoRuY/mTVFWdFJ6uva/+pxnCIninBBdVu5EAJY8KiQbbdbjmlqt MfkC4qgAU2OhUV+alA3I+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1725903557; x= 1725989957; bh=T66RGLRjRlYoaCaX2e7cnnTyICovLz77Jz8U4Opqa98=; b=c M3c5uU+WxMaBEHNHcTkY/eRVN/NlcRQMiEuPZVuX03SqK1b06lI8t3SYR2xBAyhh sAZmDUhKuu7M3v5ax49bgo2JkO2QOl47+PQYMsHX40J4CQJRATVl8O2IN7FW82D+ Imc63QGXaHHuWAenbMjSDgsIOfpN9W789nrX+sV25sDVYL0YX5xvCNsc03Vbym/Q EKVgsoKzjxo/q1SKC2iy/S0go8/MSL8UuA4nNy9YR5YBw2FwgcQnyX7BO7JHCl17 CiKB+FwuWrlAQoMKQ0vtYdOLvwbnPfR0Oe2SFytKrQFitppc0ECmmcEuwr4CKPwR MhPGXQIIc03cj5lyXaKFA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeijedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefoggffhf fvkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdq mhdrfhhmqeenucggtffrrghtthgvrhhnpeeitdefieefteeiffeffefgjeeuveffledthe ffgedtfffhfeeugffguefhkefgvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedupd hmohguvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvvggsshguqdhhrggtkhgvrhhs sehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 7C9B12E60075; Mon, 9 Sep 2024 13:39:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 Date: Mon, 09 Sep 2024 18:38:56 +0100 From: void To: freebsd-hackers@freebsd.org Message-Id: <15a38054-3a14-4eb4-a803-9ce12e413194@app.fastmail.com> In-Reply-To: <20240909143239.8F285AF@slippy.cwsent.com> References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> <20240909143239.8F285AF@slippy.cwsent.com> Subject: Re: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.02 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.73)[-0.726]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; RWL_MAILSPIKE_VERYGOOD(-0.20)[103.168.172.144:from]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.144:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; FREEMAIL_FROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4X2Yx60BS2z47rX On Mon, 9 Sep 2024, at 15:32, Cy Schubert wrote: > Those of us who build from source and build ports, whether manually or > through our own poudriere, are the minority. Just visit the FreeBSD forums. IIRC, the forums don't entertain issues raised by src builders, only -releng. This is from a while ago though, I might be wrong about that now, am happy to be corrected. > I attend OpenHack here. People who do use FreeBSD use freebsd-update and > binary packages. (I use freebsd-update and binary packages on some VMs at > $JOB, while maintaining my own network at home as any developer does.) I use freebsd-update on some VMs too. It has its place. But always poudriere for ports, as most of the VMs are internet facing, and when a vuln happens and is patched it's the fastest way to fix the situation, rather than waiting on the pkg builders. > And that's a marketing feature of FreeBSD. Most users don't want he hassle > of building and installing an O/S. Have most users been asked? > Out in the real world people use binary updates and binary packages. We > developers are an anomaly these days. I'd not consider myself a dev. That might be just me though. Is streamlining a kernel to have what you want and no more a 'dev' activity? Manually patching? > Just because a few of us build from source doesn't mean the rest of the > world does. How would you know? Who has counted the numbers? I think maybe a poll on the main site might be enlightening. I mean, I agree src builders are probably in a minority now, as freebsd-update is convenient in standard cases, but it's possibly a larger number than you think, who build from src. We'll never really know without counting. I really hope that when pkgsrc becomes dominant, that we're still able to grab src in git and checkout whats required, and build from that. It's so very versatile. -- From nobody Mon Sep 9 18:35:15 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 4X2b9g22Rlz5TfYY for ; Mon, 09 Sep 2024 18:35:19 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from smtp-8fa9.mail.infomaniak.ch (smtp-8fa9.mail.infomaniak.ch [83.166.143.169]) (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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2b9f6c0Qz4K3G; Mon, 9 Sep 2024 18:35:18 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Authentication-Results: mx1.freebsd.org; none Received: from smtp-4-0001.mail.infomaniak.ch (smtp-4-0001.mail.infomaniak.ch [10.7.10.108]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4X2b9b5QQjz2gj; Mon, 9 Sep 2024 20:35:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pyret.net; s=20231006; t=1725906915; bh=uxjRW5FF5eDxHcCpksVmhpMQCxWEJos9lk4NmwxQMzk=; h=Date:Subject:From:Reply-To:To:Cc:References:In-Reply-To:From; b=GT+Ol1GwMyOJajsX5uIqTAp9+0EFut8J+N4HG1MP+wgUYs21tKc8yZ8y78clHZC49 DL+rm+KM2574k6DoC1wxL2JZcVE0omVP+Vckp1IgVOzj3m2kSejDDs9a0GTkQzmVTU HzBXAenUvrgJfuZfVpTh47GdmXDTRY4SivQpA0Z5sJt3yPBwwU1KJxbdRa5Ubrlijh us7ulAEw5/jDKJjetFN5hWk2xA1ignedPiINQz2jYJRxN0J065/lamR/IOt6RAEeRb BF22SLBIf4f2FJvYCMnCj6RWpL5LWIpzpR2YSiWAiGBG+L0khAagOHX9c6IpIyytTp er/emoxav1/jg== Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4X2b9b2fvmzCdB; Mon, 9 Sep 2024 20:35:15 +0200 (CEST) Message-ID: Date: Mon, 09 Sep 2024 20:35:15 +0200 Subject: Re: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) From: Daniel Engberg Reply-To: Daniel Engberg To: void Cc: freebsd-hackers@freebsd.org, Cy Schubert 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_1725906915_1e15da2c3454fe16dd04729754182b2f_=_" X-WS-User-Origin: eyJpdiI6IjMvQkVlWjVQaVdNSVBZQjVuRktyU2c9PSIsInZhbHVlIjoiQmg0MGV4VFRkM3RCUWdOeW40L1pVUT09IiwibWFjIjoiNmY1YjE2MGFiYjA2ZjNjODY1MmNiMWJiNTRhZDdjODI1MmJlY2M1NmM3MDYwNGExMjdhYTNhNDNiYjlhODllOSIsInRhZyI6IiJ9 X-WS-User-Mbox: eyJpdiI6Im4wWXRoTEdSYjBxYkxLSTAvYjAwbnc9PSIsInZhbHVlIjoiSWhiUzNHYUIyMDVSZFo1SmNTU3BYUT09IiwibWFjIjoiOTdmNmFkNGMyNTIzMTgyM2JhYzg3MTdlNDY0OTg0ZmFhYmRjYmJiNGQzNzQ5NGI5ZDU5NDU2MTdkMWZlNmRmYiIsInRhZyI6IiJ9 X-WS-Location: eJxzKUpMKykGAAfpAmU- X-Mailer: Infomaniak Workspace (1.3.744) References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> <20240909143239.8F285AF@slippy.cwsent.com> <15a38054-3a14-4eb4-a803-9ce12e413194@app.fastmail.com> In-Reply-To: <15a38054-3a14-4eb4-a803-9ce12e413194@app.fastmail.com> X-Infomaniak-Routing: alpha 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:83.166.128.0/19, country:CH] X-Rspamd-Queue-Id: 4X2b9f6c0Qz4K3G --_=_swift_1725906915_1e15da2c3454fe16dd04729754182b2f_=_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2024-09-09T19:38:56.000+02:00, void wrote: >=C2=A0On= =C2=A0Mon,=C2=A09=C2=A0Sep=C2=A02024,=C2=A0at=C2=A015:32,=C2=A0Cy=C2=A0Schu= bert=C2=A0wrote: >>=C2=A0=C2=A0Those=C2=A0of=C2=A0us=C2=A0who=C2=A0build= =C2=A0from=C2=A0source=C2=A0and=C2=A0build=C2=A0ports,=C2=A0whether >>= =C2=A0=C2=A0manually=C2=A0or=C2=A0 >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2= =A0through=C2=A0our=C2=A0own=C2=A0poudriere,=C2=A0are=C2=A0the=C2=A0minorit= y.=C2=A0Just=C2=A0visit=C2=A0the >>=C2=A0=C2=A0FreeBSD=C2=A0forums. >= =C2=A0 >=C2=A0IIRC,=C2=A0the=C2=A0forums=C2=A0don't=C2=A0entertain=C2= =A0issues=C2=A0raised=C2=A0by=C2=A0src=C2=A0builders,=C2=A0 >=C2=A0 >= =C2=A0only=C2=A0-releng.=C2=A0This=C2=A0is=C2=A0from=C2=A0a=C2=A0while= =C2=A0ago=C2=A0though,=C2=A0I=C2=A0might=C2=A0be=C2=A0wrong >=C2=A0about= =C2=A0that=C2=A0now, >=C2=A0 >=C2=A0am=C2=A0happy=C2=A0to=C2=A0be=C2= =A0corrected. >=C2=A0 >>=C2=A0=C2=A0I=C2=A0attend=C2=A0OpenHack=C2= =A0here.=C2=A0People=C2=A0who=C2=A0do=C2=A0use=C2=A0FreeBSD=C2=A0use >>= =C2=A0=C2=A0freebsd-update=C2=A0and=C2=A0 >>=C2=A0=C2=A0 >>=C2=A0=C2= =A0=C2=A0binary=C2=A0packages.=C2=A0(I=C2=A0use=C2=A0freebsd-update=C2= =A0and=C2=A0binary=C2=A0packages=C2=A0on >>=C2=A0=C2=A0some=C2=A0VMs= =C2=A0at=C2=A0 >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0$JOB,=C2=A0while= =C2=A0maintaining=C2=A0my=C2=A0own=C2=A0network=C2=A0at=C2=A0home=C2=A0as= =C2=A0any=C2=A0developer >>=C2=A0=C2=A0does.) >=C2=A0 >=C2=A0I=C2= =A0use=C2=A0freebsd-update=C2=A0on=C2=A0some=C2=A0VMs=C2=A0too.=C2=A0It= =C2=A0has=C2=A0its=C2=A0place.=C2=A0But=C2=A0always >=C2=A0poudriere >= =C2=A0 >=C2=A0for=C2=A0ports,=C2=A0as=C2=A0most=C2=A0of=C2=A0the=C2=A0VMs= =C2=A0are=C2=A0internet=C2=A0facing,=C2=A0and=C2=A0when=C2=A0a=C2=A0vuln = >=C2=A0happens >=C2=A0 >=C2=A0and=C2=A0is=C2=A0patched=C2=A0it's=C2= =A0the=C2=A0fastest=C2=A0way=C2=A0to=C2=A0fix=C2=A0the=C2=A0situation,= =C2=A0rather >=C2=A0than=C2=A0waiting >=C2=A0 >=C2=A0on=C2=A0the= =C2=A0pkg=C2=A0builders. >=C2=A0 >>=C2=A0=C2=A0And=C2=A0that's=C2=A0a= =C2=A0marketing=C2=A0feature=C2=A0of=C2=A0FreeBSD.=C2=A0Most=C2=A0users= =C2=A0don't=C2=A0want >>=C2=A0=C2=A0he=C2=A0hassle=C2=A0 >>=C2=A0=C2= =A0 >>=C2=A0=C2=A0=C2=A0of=C2=A0building=C2=A0and=C2=A0installing=C2= =A0an=C2=A0O/S. >=C2=A0 >=C2=A0Have=C2=A0most=C2=A0users=C2=A0been= =C2=A0asked? >=C2=A0 >>=C2=A0=C2=A0Out=C2=A0in=C2=A0the=C2=A0real=C2= =A0world=C2=A0people=C2=A0use=C2=A0binary=C2=A0updates=C2=A0and=C2=A0binary= >>=C2=A0=C2=A0packages.=C2=A0We=C2=A0 >>=C2=A0=C2=A0 >>=C2=A0=C2= =A0=C2=A0developers=C2=A0are=C2=A0an=C2=A0anomaly=C2=A0these=C2=A0days. >= =C2=A0 >=C2=A0I'd=C2=A0not=C2=A0consider=C2=A0myself=C2=A0a=C2=A0dev.= =C2=A0That=C2=A0might=C2=A0be=C2=A0just=C2=A0me=C2=A0though.=C2=A0Is >= =C2=A0streamlining=C2=A0a >=C2=A0 >=C2=A0kernel=C2=A0to=C2=A0have=C2= =A0what=C2=A0you=C2=A0want=C2=A0and=C2=A0no=C2=A0more=C2=A0a=C2=A0'dev'= =C2=A0activity?=C2=A0Manually >=C2=A0patching? >=C2=A0 >>=C2=A0=C2= =A0Just=C2=A0because=C2=A0a=C2=A0few=C2=A0of=C2=A0us=C2=A0build=C2=A0from= =C2=A0source=C2=A0doesn't=C2=A0mean=C2=A0the=C2=A0rest >>=C2=A0=C2=A0of= =C2=A0the=C2=A0 >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0world=C2=A0does. >= =C2=A0 >=C2=A0How=C2=A0would=C2=A0you=C2=A0know?=C2=A0Who=C2=A0has=C2= =A0counted=C2=A0the=C2=A0numbers?=C2=A0I=C2=A0think=C2=A0maybe=C2=A0a >= =C2=A0poll=C2=A0on=C2=A0the >=C2=A0 >=C2=A0main=C2=A0site=C2=A0might= =C2=A0be=C2=A0enlightening.=C2=A0I=C2=A0mean,=C2=A0I=C2=A0agree=C2=A0src= =C2=A0builders=C2=A0are >=C2=A0probably=C2=A0in=C2=A0 >=C2=A0 >=C2= =A0a=C2=A0minority=C2=A0now,=C2=A0as=C2=A0freebsd-update=C2=A0is=C2=A0conve= nient=C2=A0in=C2=A0standard=C2=A0cases, >=C2=A0 >=C2=A0but=C2=A0it's= =C2=A0possibly=C2=A0a=C2=A0larger=C2=A0number=C2=A0than=C2=A0you=C2=A0think= ,=C2=A0who=C2=A0build=C2=A0from >=C2=A0src. >=C2=A0 >=C2=A0We'll= =C2=A0never=C2=A0really=C2=A0know=C2=A0without=C2=A0counting. >=C2=A0 >= =C2=A0I=C2=A0really=C2=A0hope=C2=A0that=C2=A0when=C2=A0pkgsrc=C2=A0becomes= =C2=A0dominant,=C2=A0that=C2=A0we're=C2=A0still >=C2=A0able=C2=A0to=C2= =A0 >=C2=A0 >=C2=A0grab=C2=A0src=C2=A0in=C2=A0git=C2=A0and=C2=A0checkou= t=C2=A0whats=C2=A0required,=C2=A0and=C2=A0build=C2=A0from=C2=A0that. >= =C2=A0 >=C2=A0It's=C2=A0so=C2=A0very=C2=A0versatile. >=C2=A0 >=C2= =A0-- I would imagine that for larger installs it's something inbetwee= n where you build your own "set" of packages and base with custom setti= ngs etc and then push the binaries. I would also like to remind people= that at least for ports far from all ports have runtime detection of SIM= D instructions which can cause quite a bit of a difference in performance= so setting CPUTYPE might drastically improve performance. Canonical (Ubu= ntu) are looking into providing different sets of packages depending on b= aseline so it's a thing. https://www.phoronix.com/news/Ubuntu-x86-64-v3-I= mages-Azure I also build from source btw =3D) Best regards, = Daniel --_=_swift_1725906915_1e15da2c3454fe16dd04729754182b2f_=_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 2024-09-09T19:38:56.000+02:00, void <voi= d@f-m.fm> wrote:

On Mon, 9 Sep 202=
4, at 15:32, Cy Schubert wrote:
=

  Those of us who build from source and build ports, whether manually =
or 
 through our own poudriere, are the minority. Just visit =
the FreeBSD forums. 
 
IIRC, the f=
orums don't entertain issues raised by src builders, 
only -r=
eleng. This is from a while ago though, I might be wrong about that now,
am happy to be corrected.

  I attend OpenHack here. People who do use FreeB=
SD use freebsd-update and 
 binary packages. (I use freebsd-u=
pdate and binary packages on some VMs at 
 $JOB, while mainta=
ining my own network at home as any developer does.)
=

 
I use freebsd-update on some VMs too. It has its place=
. But always poudriere
for ports, as most of the VMs are inte=
rnet facing, and when a vuln happens
and is patched it's the =
fastest way to fix the situation, rather than waiting
on the =
pkg builders.

  And that's a marketing feature of FreeBSD. Most users don't want he has=
sle
of building and installing an O/S.

Have most users been asked?

=
Out in the real world people use b= inary updates and binary packages. We
developers are an ano= maly these days.

I'd not conside= r myself a dev. That might be just me though. Is streamlining a
kernel to have what you want and no more a 'dev' activity? Manually patc= hing?

Just= because a few of us build from source doesn't mean the rest of the
world does.

How would y= ou know? Who has counted the numbers? I think maybe a poll on the
=
main site might be enlightening. I mean, I agree src builders are prob= ably in
a minority now, as freebsd-update is convenient in s= tandard cases,
but it's possibly a larger number than you thi= nk, who build from src.

We'll never really kno= w without counting.

I really hope that when pk= gsrc becomes dominant, that we're still able to
grab src in = git and checkout whats required, and build from that.
It's so= very versatile.
--
I would imagine that for larger installs it's something inbetween= where you build your own "set" of packages and base with custom settings e= tc and then push the binaries.
I would also like = to remind people that at least for ports far from all ports have runtime de= tection of SIMD instructions which can cause quite a bit of a difference in= performance so setting CPUTYPE might drastically improve performance. Cano= nical (Ubuntu) are looking into providing different sets of packages depend= ing on baseline so it's a thing. https://www.phoronix.com/news/Ubuntu-x86-64-v3-Image= s-Azure

I also bui= ld from source btw =3D)
Daniel
--_=_swift_1725906915_1e15da2c3454fe16dd04729754182b2f_=_-- From nobody Mon Sep 9 18:59: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 4X2bjp2tYtz5Tk5M for ; Mon, 09 Sep 2024 18:59: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 4X2bjn6p5yz4Qs7; Mon, 9 Sep 2024 18:59: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 B980F892DC; Mon, 09 Sep 2024 18:59:39 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 489Ixdia086264; Mon, 9 Sep 2024 18:59:39 GMT (envelope-from phk) Message-Id: <202409091859.489Ixdia086264@critter.freebsd.dk> To: Olivier Certner cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-reply-to: <2611284.jQUcPV6jne@ravel> From: "Poul-Henning Kamp" References: <202409031532.483FW0If007252@critter.freebsd.dk> <2611284.jQUcPV6jne@ravel> 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: <86262.1725908379.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 09 Sep 2024 18:59:39 +0000 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] X-Rspamd-Queue-Id: 4X2bjn6p5yz4Qs7 Olivier Certner writes: > > We need to find a contemporary and useful answer to "What is FreeBSD?" > > I think you've answered part of that satisfactorily in your initial mail= already: > > > Delivering a single consistent userland with the kernel has stood > > us well for three decades, and we should stick with that. > > I'll add: > - A system that is easy to build and tweak in practice (for developers a= t the very least). But what are the boundaries of this "system" of which you talk ? I am more or less responsible for nearly two hundred computers running FreeBSD right now. Only two of those have zero ports/packages installed, one monitors my floor heating system, the other firewalls some old crap. To me "src+kernel" is just the foundations. "A system" is what people build on top of the foundations. -- = 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 Mon Sep 9 19:02: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 4X2bnl1Xdwz5TkSC for ; Mon, 09 Sep 2024 19:03:07 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2bnk6PHrz4SHW for ; Mon, 9 Sep 2024 19:03:06 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-e05f25fb96eso5006547276.1 for ; Mon, 09 Sep 2024 12:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1725908585; x=1726513385; 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=TuW44C7NcSA9T1TKn62xFJ1deVqV5NwqBrn5nOREctQ=; b=henXZorJcx3c4yE+WdDxodOFuuEEODPr1fnfPkV66n2fMPHwF6YRQ5VeSEgnCGmkMQ aGFPifw7qF1xTS06+npfQ4C1lkOS2HvSYTSHtR4fVTB1YiWC8sMGypcmSVH5HLzp4oQ8 BNyoyw5K/CEjKcK5uUCSEMDl91PtZX/im1qPSncpFPgYzD8TJ7tXiiwCjQqGdO4WuRKs YVxBIKGNxfD8OseS7OCmTG7XVHoANMOrAegZUE2HpE4DfDI7voasotRSca5n7TGeOzhG KMQDae8hfsrxe803UjXHpQHj/zqHbdMg9hVvgj4oce2e5kkCDDc/NAWanBmIZFfuTcfa 0seA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725908585; x=1726513385; 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=TuW44C7NcSA9T1TKn62xFJ1deVqV5NwqBrn5nOREctQ=; b=kwcfMCA+kr6fF8GPVJTi3qEO1YnczAeXNmSdK5+GerRNpGku76AI2Tz7U1aB08cBVM Kv64enesnSlS7sYrB9wYmglUblMZHt76wNH0tQsCWqh061AxroP0dukqouHRaiJkm0Xk 2Yq3PWVLyLbN8KBomiV96mJoGZs5WwXg8e2abf3MRQWKNw6sCfW7BucAN2NspkKM2gsZ Kwm2zhm2eFcT6FhCWIuBb2WZggM8wg4qsQYRFKyI9Y6918IXUvB5qNhpEZZTBTUfxKBf USF3UPu3L3Pvomex7+2h5TDlr+R8MZmWYfrwZNayDxTQuFcQRclYZEaj+4MzPH9QM4Hl UcaA== X-Forwarded-Encrypted: i=1; AJvYcCUbhs7YsKfFP/cbw0nBwLI5/aCOHUdF9wf9+NWOURgHAglIACUd+/VYWRJYgWPHHMGWDNpDuxaT/Dh3Mg2dddU=@freebsd.org X-Gm-Message-State: AOJu0YzNWpW/xgidtpJQxsePltBFvCZ1p6pp88x8AVHScDC8dJfWtZJc 6vVkGqNkBYAWFxgd1y/TiSLA8rKWTYOfBeeb1eFMci7aSRzL2ERlRHjVlxphm3i3zMb8a4ijYh4 = X-Google-Smtp-Source: AGHT+IFnCS5lWrle40HUJbYpfF0i6Go8veTEg1ak28T5d9Bf3m7hcT1J/rs/O7yFqwQOenYuI7Xalg== X-Received: by 2002:a05:6902:a87:b0:e16:5343:ba5a with SMTP id 3f1490d57ef6-e1d3488bbaemr14326152276.15.1725908585158; Mon, 09 Sep 2024 12:03:05 -0700 (PDT) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e1d7ba26673sm26481276.36.2024.09.09.12.03.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Sep 2024 12:03:04 -0700 (PDT) Received: by mail-yb1-f180.google.com with SMTP id 3f1490d57ef6-e026a2238d8so4580211276.0 for ; Mon, 09 Sep 2024 12:03:04 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUjXneb3zHxugU4ugnpzYQYG8PjAX3YX3YIS8aYOEc1QwZ2x0Nne9lKWH7RanSx04AbLoIQ7IltPrznr63x7Sk=@freebsd.org X-Received: by 2002:a05:690c:2b0f:b0:6ad:219a:b67c with SMTP id 00721157ae682-6db45289321mr88511787b3.46.1725908584138; Mon, 09 Sep 2024 12:03:04 -0700 (PDT) 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: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> <20240909143239.8F285AF@slippy.cwsent.com> In-Reply-To: <20240909143239.8F285AF@slippy.cwsent.com> From: Tomek CEDRO Date: Mon, 9 Sep 2024 21:02:52 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) To: Cy Schubert Cc: Jamie Landeg-Jones , void@f-m.fm, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" 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:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X2bnk6PHrz4SHW Not really good idea to divide people in general, and here to generalize about people who build from source or use binary packages. Its good to have binary packages just to quickly setup or upgrade some machines, verify integrity, save time, etc. Its good to have src and ports to build from sources - test fixes, create or extend driver, add new port or update existing one, etc - or to read sources to understand stuff. Sometimes it is the only way possible. Binary releases are probably more convenient for desktop and cloud/vm use, source builds are more common among custom setups and embedded systems. Another place where source build is the only way is Python Virtual Environment - usually packages for FreeBSD are not provided at all and need to be compiled on site. I find it kinda funny that its several times faster to build whole FreeBSD kernel and/or base than for instance modern web browser :D I also use FreeBSD to develop various RTOS based firmwares :-) Both uses are important in Open-Source. What is the problem exactly? :D ps/2: It good to see so many folks active here on mailing lists :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Mon Sep 9 19:18: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 4X2c7d4RTMz5TmQm for ; Mon, 09 Sep 2024 19:18:37 +0000 (UTC) (envelope-from fvalasiad@proton.me) Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2c7d08DYz4VJp for ; Mon, 9 Sep 2024 19:18:36 +0000 (UTC) (envelope-from fvalasiad@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725909514; x=1726168714; bh=GGJwrjriDFGz3Sdz/P14228QVU/lIyTij81EAQ8hjvI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=XCIzGJnjX3pf1MryLP7GJ5+PKPLPf2CNpo28gj7Ki6MuzmFMn1+kttgTnNK7ZG/D8 fBic0g1DtI6n3x13NwtsLY9HL1WfWgXOGe0GF+yn7AajvVzM7DKSpTnRfgtTrUQvsX eSABAiSTYIEHfGp7HXI5A+WXyRudrEXj230f3ufsrK+iot4Tw95GKYUL9o8xtBiaEK yN106NQvy14px3+HDBylycCaielxJYGr+YTcNZ/YOrGGPHklVy2Lfa606arUXwygav JEhPEMDU7kqSx/0hN+trzOXc0rRyWS+Aa39YejvGTYnnUl3U0jJtg/bocZ8YmqwLYo eDKpHgpQfo3pA== Date: Mon, 09 Sep 2024 19:18:28 +0000 To: "theraven@freebsd.org" , "phk@phk.freebsd.dk" From: fvalasiad Cc: "ske-89@pkmab.se" , "freebsd-hackers@freebsd.org" Subject: Re: The Case for Rust (in any system) Message-ID: In-Reply-To: References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> Feedback-ID: 78761413:user:proton X-Pm-Message-ID: 0c9062cf42920b09b3e3623e6b79d45320361361 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-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:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Queue-Id: 4X2c7d08DYz4VJp -------- Original Message --------=20 On 9/9/24 15:46, David Chisnall wrote:=20 On 9 Sep 2024, at 12:24, Poul-Henning Kamp wrote:=20 What might that subset be?=20 Initially it will be "better C compiler", but then we will gradually=20 allow more and more of C++ to be used.=20 In my experience, the worst C++ code is written by people thinking in C. = =C2=A0The second worst is written by people thinking in Java (or Smalltalk= =20 In my honest opinion, this is primarily the reason why people outside of th= is space bundle up C and C++ together, treating them as if they are one and= the same, suffering from the same memory bugs. Codebases out there using C++ as if its C with classes, completely out of t= he loop regarding modern technologies. And I am talking about userland here= . I am beyond curious to see any reasonable study on C++ projects that employ= RAII, use the STL and generally speaking follow modern guidelines, that st= ill suffer from memory related CVEs. Rust looks like C++ with sane defaults, given that they aren't riddled with= technical debt. But to hold such a strong stance that it should not be use= d for any new project whatsoever, without the required data I pointed out, = seems at least ignorant. Fotis From nobody Mon Sep 9 19:45: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 4X2cl700dNz5Tqvm for ; Mon, 09 Sep 2024 19:45:55 +0000 (UTC) (envelope-from ltning-freebsd-hackers@anduin.net) Received: from mail.anduin.net (mail.anduin.net [185.42.170.45]) (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 4X2cl42QNxz4YcD for ; Mon, 9 Sep 2024 19:45:52 +0000 (UTC) (envelope-from ltning-freebsd-hackers@anduin.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=anduin.net header.s=dkim2021 header.b=31mAKfUH; dmarc=pass (policy=reject) header.from=anduin.net; spf=pass (mx1.freebsd.org: domain of ltning-freebsd-hackers@anduin.net designates 185.42.170.45 as permitted sender) smtp.mailfrom=ltning-freebsd-hackers@anduin.net DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anduin.net; s=dkim2021; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0FJk9hw+N+3Fftmix+8OhDKAtaelgiBDNO7dts9NHHM=; t=1725911152; x=1726775152; b=31mAKfUHkiYvBfMP3RBZjVvUzgpVoE340fwnhSNlVux1LPlkY8gHuhW1z9+RVVAbPxvi9tHqlXT NVx/PDZ1Ogk0QU6RBYWxhngxoL9uf7Joi4AeRjQLMzKrW9O6h0PtvRcGZtWG6QJP2Nem9bGndwEZZ cKEWs1AhtyBDHSqTDsbA+QxiIUpcy+b/I8fTqcsV6VIpTRYMe+9BI51kZ52/s8f+IUqSA1oTC/VyW w3n3igl0KUaWycsrEV6b+12DU3QPcVFgRRirIWWMLOtc6X2Xn9VGdlv5xdWOz/GwM/L8COfX8V+YW rUp1ItC4DnA1YUgTRxD/2TPwrQHgehfjWSoQ==; Received: by mail.anduin.net with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.97.1 (FreeBSD)) (envelope-from ) id 1snkKU-00000000GgV-0kc6 for freebsd-hackers@freebsd.org; Mon, 09 Sep 2024 19:45:43 +0000 Message-ID: <083e0e0c-e359-477b-9767-b0335051fab6@anduin.net> Date: Mon, 9 Sep 2024 21:45:41 +0200 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: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) Content-Language: en-US To: freebsd-hackers@freebsd.org References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> <20240909143239.8F285AF@slippy.cwsent.com> From: =?UTF-8?Q?Eirik_=C3=98verby?= In-Reply-To: <20240909143239.8F285AF@slippy.cwsent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-Spam-Score: -1.9 X-Spam-Level: - X-Spam-Report: host: mail.modirum.com | contact: hostmaster@modirum.com | scores: BAYES_00=-1.9,NO_RELAYS=-0.001 | autolearn=no autolearn_force=no, score=0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[anduin.net,reject]; R_DKIM_ALLOW(-0.20)[anduin.net:s=dkim2021]; R_SPF_ALLOW(-0.20)[+ip4:185.42.170.45/32]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:62248, ipnet:185.42.170.0/24, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[anduin.net:+] X-Rspamd-Queue-Id: 4X2cl42QNxz4YcD On 9/9/24 16:32, Cy Schubert wrote: > Just because a few of us build from source doesn't mean the rest of the > world does. I didn't think I'd reply on any of these threads, but here I go: I (or we, at work), sometimes build from source if we need a patch applied or a test run in some setting or other. We build our own ports/packages - but *not on the target system*. So for each machine we have that builds anything from source, we have a couple hundred physical and virtual ones that use binary updates: freebsd-update and pkg. It is *absolutely essential* to promote pkgbase to first-class citizen. If for none of the reasons discussed in these threads, simply because a coherent approach to installing and updating our systems would make our lives so, so, so! much easier! Right now, we have *three* sources of binaries to get a single jail up and running and keep it maintained: - downloading base.txz from somewhere to create the jail template - freebsd-update to keep host and template updated - pkg to install and maintain 3rd party packages This, in turn, makes it necessary to manage three different fetch, build, caching and distribution mechanisms. Yes we could use pkgbase in-house, but we need to run "official builds" for the base OS ("compliance", yuck!). As has been said elsewhere, and I'll spell it out: Absolutely *nothing* will be lost by moving to pkgbase and making it the default distribution, installation and updating mechanism. And absolutely nothing about that would prevent anyone from doing precisely what they're doing today, in exactly the same way. Sorry for the wall of text. There's been a lot of them lately :) /Eirik From nobody Mon Sep 9 19:49:12 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 4X2cqg502Vz5TrvS for ; Mon, 09 Sep 2024 19:49:51 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com [103.168.172.146]) (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 4X2cqf6b5Hz4ZdQ for ; Mon, 9 Sep 2024 19:49:50 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=BvGd62FH; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="H 4xKX1o"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.146 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 07B721380284 for ; Mon, 9 Sep 2024 15:49:50 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-05.internal (MEProxy); Mon, 09 Sep 2024 15:49:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1725911390; x=1725997790; bh=X9iyM7b0V6XzocC1cSzTYyiIwV3MUVmBCkfKZyICRSc=; b= BvGd62FHZVVzM+6wyRVf8eMQ62sH9PwqE9OP62+mxd1bQdeXUmHiAl3/CG7OvyJo K7GX+omQ4QTi+qdTumYg+/K7+jczksO/DLmda5wDSTuQmLthNa/gNSHCOsD04RDF Zl76WySDYfPOD00PTT3AaQ/wHo1fMsO9rSm2++w+2RtrRehstCleNfUvVAVhf6lX H5EnnMeXn28EeJDb8nihKgrgAtKGIfV0z+2HeKvYtaN2VKo1pW/4BUDlwNVPqrQS p5G+vrBgodCjb3ZgHy7ghDKF8u5U9kIKAhKXeYjXqS2aGhxnrGBxIqD/l/zSJ6T6 85Ye/uGX+PdfGEJ7UP+6JA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1725911390; x= 1725997790; bh=X9iyM7b0V6XzocC1cSzTYyiIwV3MUVmBCkfKZyICRSc=; b=H 4xKX1oCy+ELPN61vVADhRstPGsg6cDgHOKR7If6yDP4hl7gDtVMjy9LitYNZeDkb 9Lzl8JMc+YBGT5UcFg5YbFrzhdKXJYWL30kvmCTZy3mrOjmEJp3MsymPfbD0gv2L 8O6Txbo9Jk13F0QOF2qLUeD/K7w1N4lT5TxBSjN+5VIFAFy1EL6EA0GFxC/ZcOtu JEwGbPGULLEMfZVUFlyf26pC90NiLXx531UA78+G+N+fie9Nv7cT2lewf1ICQ5mR kezmmvMxa2LZPyumleB+23S4FMuWzuNZvkw+NjZIC4FdG7urGQ0jEgKwJSHCU9sT BrcX4tKQIVP2i8KUMyEOA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeijedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofggff fhvffkjghfufgtgfesthejredtredttdenucfhrhhomhepvhhoihguuceovhhoihgusehf qdhmrdhfmheqnecuggftrfgrthhtvghrnhepiedtfeeifeetiefffeefgfejueevffeltd ehffegtdffhfefuefggfeuhfekgfdvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepud dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqhhgrtghkvghr shesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id C5DD92E60075; Mon, 9 Sep 2024 15:49:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 Date: Mon, 09 Sep 2024 20:49:12 +0100 From: void To: freebsd-hackers@freebsd.org Message-Id: <94809bad-8c45-4520-a24a-fd6afa5b2c85@app.fastmail.com> In-Reply-To: <202409081302.488D2UvB069580@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.08 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.146:from]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FREEMAIL_FROM(0.00)[f-m.fm]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4X2cqf6b5Hz4ZdQ On Sun, 8 Sep 2024, at 14:02, Poul-Henning Kamp wrote: > Beware of selection bias. > > "Somebody who compiles from src" is almost the > > literal definition of > "committer". I build from src all the time and have never committed. > In terms of all the FreeBSD running hardware out > there, not even > one percent of one percent of the machines > compile from src. How have you measured this? I've never been asked. Surely I'm not alone. >From this and other threads there seems to be a lot of "stands to reason" sentiment without any actual data... Wouldn't it be better to make decisions based on data? --- From nobody Mon Sep 9 20:26: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 4X2df62KFXz5TxJx for ; Mon, 09 Sep 2024 20:26:38 +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 4X2df52Hdjz4hSJ; Mon, 9 Sep 2024 20:26:37 +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 6BA9A89284; Mon, 09 Sep 2024 20:26:35 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 489KQYNL088354; Mon, 9 Sep 2024 20:26:34 GMT (envelope-from phk) Message-Id: <202409092026.489KQYNL088354@critter.freebsd.dk> To: fvalasiad cc: "theraven@freebsd.org" , "ske-89@pkmab.se" , "freebsd-hackers@freebsd.org" Subject: Re: The Case for Rust (in any system) In-reply-to: From: "Poul-Henning Kamp" References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> 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: <88352.1725913594.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 09 Sep 2024 20:26:34 +0000 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] X-Rspamd-Queue-Id: 4X2df52Hdjz4hSJ -------- fvalasiad writes: > Codebases out there using C++ as if its C with classes, completely out o= f > the loop regarding modern technologies. And I am talking about userland = here. There are two cases here. But here we are talking about bringing an existing mature C codebase into the Century of the Fruitbat, without doing a total rewrite in one go. The first step is to get (relevant parts of) the code into a C++ compiler. Steps two to N are: Reap tangible benefits by employing features of C++ language as that becomes possible and sensible (ie: as the C++ specific runtime environment becomes available). "C with classes" is a very sensible step along that (long) journey IMO. But if we were talking a new green-field project that would be utterly sil= ly. Poul-Henning PS: C++ was called "C with classes" first time I heard about it in 1985 :-= ) -- = 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 Mon Sep 9 21:06: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 4X2fYg6jZLz5V3fF for ; Mon, 09 Sep 2024 21:07:51 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2fYf3vQnz4mVm for ; Mon, 9 Sep 2024 21:07:50 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=UDGFKCQ1; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1725916062; 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: in-reply-to:in-reply-to:references:references; bh=Wte3yqLRMvstERVRa9DAWv0p157sA3thKAPN56nENoc=; b=UDGFKCQ1nFG1TSemZLu13oR/NhBY4uRQEOcBVnKq9JXOgRhDojUZayGH2NBQUAIpvtcm68 V5vCAIjjMK4f5Y9M3IwUQybY3R5G6Jt91g3n7kL87SWjhjyH8z6JpJ8vFg7RCSQAry6CB6 xHYKQHZcedxXNZ85tY0bWBP6ay/YwHFG6EkNqegAiw9YcbasuksD2+fCGSEiQELYb70I2m FuHJNVo1BVQF8+ZE6cBcoujyreqCFaSRvx/11iLvdnfVbXW+C+anGYBZ240E6EwbvmHiiW vF/iCu7Zg25yxLCjBjsebptlV3EUVgGmiEfEhqNoY3rY2iu5pyUL1IWxiVmphg== Date: Mon, 09 Sep 2024 23:06:48 +0200 From: Alexander Leidinger To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-Reply-To: <202409081302.488D2UvB069580@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> Message-ID: <1aa702e57e63f927b687212820e97f8c@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_5904a5b84bb3ee38f1c7f3903bb27412"; micalg=pgp-sha256 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.73 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.63)[-0.628]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; HAS_ORG_HEADER(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4X2fYf3vQnz4mVm This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_5904a5b84bb3ee38f1c7f3903bb27412 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-09-08 15:02, schrieb Poul-Henning Kamp: > -------- > Alexander Leidinger writes: > > I'm only going to answer two bits from your email: > >> > The source tree became our citadel: "FreeBSD is src". If something >> > was not in src, it was not FreeBSD. >> >> We are way past that too, FreeBSD is src+ports+docs(+community). > > Nope. > > The only reason the Rust advocates need to bring this up is /precisely/ > because that is not the case. > > If it were, they would just have added ports. So you are promoting a Linux-distro style model? >> In your world. And in the world of some other people. But there are a >> lot of worlds where this is not true. I have systems which are updated >> from src, and use only packages which are build locally. > > Beware of selection bias. This argument goes in both directions. > "Somebody who compiles from src" is almost the literal definition of > "committer". No. - specific needs for a kernel which can not be satisfied with GENERIC - specific needs / interest for optional stuff (maybe also as part of hardening) - specific needs / interest to exclude some stuff (maybe also as part of hardening) - ... For nothing of this I need to be a committer, or even to be a contributor. > In terms of all the FreeBSD running hardware out there, not even > one percent of one percent of the machines compile from src. > > (Hint: Consumer electronics and server farms running FreeBSD) Netflix/Sony or other vendors providing a product have their own way of handling this... I don't think we should include those in this part of the argument. And server farms may exactly be the case of compiling from source (once, and distributing this via their own freebsd-update or shared obj, or whatever mechanism, with the reason being local patches or specific kernel builds or whatever). Surely not all, but some of them. Enough of them to be relevant to consider. Yes, we surely have much more people using our binary-only possibilities than it was the case 20 years ago when I joined FreeBSD, but there are enough people out there that we can not neglect an update from src. And I was not talking about each _machine_ compiling their own stuff, but there are surely more _sites_ which compile their own stuff than one percent of one percent. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_5904a5b84bb3ee38f1c7f3903bb27412 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmbfY3YACgkQEg2wmwP4 2IYfLhAAiGfy8qimD6y1tQC9V0VNYVLuV6XyPDCI8kfNcyvvofKGyNTGFJz8XT31 0CigdWVr0XbdSHna61TB6+0PpzGxn7j2QAre+m4Qw30FxrbGcZ93NBU/V/KKJvrX w0E1E5Gs8gS/HCh4jENnrcFqRegwow29LaEZNsUciNyWPICiY+s/cA4KY8s0Xsrb vE23f+lnkkphJtr8WgMcNEOzKnkNWuHhxF0ZM54TAvCRJXs3p725/PejEGgn6WKO fAD67kjT0nnXWgssFj5D7vJZbDGB1TYn9BTBM/ykEoElenrvitbibXPOErC+kIzS vD8RDEuGtTMzcZu/YhWb4Rpnc0A9WhCvQ0+5YVNDEVNd8GtYlcRzQxeSin0pUTwA Fj6e2iyS7bLy6Yszp8aYGcEetpUrKFjpSPeWWvz3jvxyB/MylxsQJ1OztGYwCeKF cLUuaG6MJ9QCUvIe29FA3cokbfIbIYwL6ZOrm6q5WuES1ZwmcDpQadq7PcNDKSRs QZUlMkZaIwEGOFvjQC3kw0L7yL9Zpv272YeJ3GXQefDND1QCbDTDKUzgHrrQcs4P GgeireOM57dQd2lvFU5AGmt3vmlmR4oDLk2dChDt1r0bcmp1Qd3VQTNrbmOx0zkf mYmex4WmQACriVGtfJfl+zZF5Km1uhBqrbUFdik2d7ZuwMVhINw= =O8E8 -----END PGP SIGNATURE----- --=_5904a5b84bb3ee38f1c7f3903bb27412-- From nobody Mon Sep 9 21:11: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 4X2ff61P6bz5V3qp for ; Mon, 09 Sep 2024 21:11:42 +0000 (UTC) (envelope-from kevans@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2ff60y9Lz4q0j for ; Mon, 9 Sep 2024 21:11:42 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725916302; 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: in-reply-to:in-reply-to:references:references; bh=rABvhXLxy0CMyAiws1Y3gzm4F7aHmGb2JTTUQ49D4aM=; b=s1S5QNzxbCvZSdiAQAg2y+gdILIsqmJaZfRqn0AI3lWsKtHmpBe7rRoM/zsACcNXX58ujb FV4KqBaAy+R14+SwSon/z/B/n5jeUfu9B6GR4ZDM/XneSGLVwu6pbRgZIBut7ZNnh8NWNr MXeCnj07bVio62yjCv0HvWpE1YxNtBgRFpUJI5KoSPmjisTsv2MK7gM92+Ic2yPdAQRTUh UYhFgNmcTyM2KUq2gKRiS0Bxwk7ZIIIUfsQiEGzONuOb1MP50o+no/If41LNRlOpxCK0Ds OHahIFiUupi7m8HxDKdAhq5fpkMoG23famzXUIgIlLbWv54vkuOl70YqNcAzhA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725916302; a=rsa-sha256; cv=none; b=kp+8dvWv04+Kyy0M2DfUZ7T3TQoeUJjm4u42/KcxPVtEW8qQM/uTkwQL6Pl0g4gLnDgfH+ J0EzLtNvHiuf0EtybNtkcsmWY3ptHwt96795QbV5z5jVWdex1K0ebb0QLjBjSqstE8AAG1 qhDEp6GGXXgOu6bZSCPpAhuoBZaE4ne0i13kp/KgV+cWYIur2UJzxYS7rkXSpvrhpLs+ed 6fR81F2Z5e63pvmymm8FF/zNfeOofKFqfqf6vRMdnI5Snrrch7cHvG9x6UoQf5B0fLSuQc gFJZ9ZQoVga/i634ApJlaagntC8VAePL5TIQYcL1QC6GXnVzOUm6GW4Kwo4wtg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725916302; 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: in-reply-to:in-reply-to:references:references; bh=rABvhXLxy0CMyAiws1Y3gzm4F7aHmGb2JTTUQ49D4aM=; b=PWP3XotGg0RwID4d3nw3uNR2rvTPIE60YJGMb9e50RWoKpwqyX0eu2UTM8ZY8eVNET3G+R 4GwQwk4YbtHdELeVWLBHaWOESNzqloYTI+I8rNBtwkgW7HE4VUPf5PMra6PhaFrDffovAf SHPs8T1Dp0kROU819DtTzyG5TKNlB7EtCf8VPxTM6F7vihnxKFBnNX9azhAqOm+DPgYKB6 bFTpS4nFV6n+Yu86vehNrF7D8EVtutlkaO1M1GsrH7kWj5T8nZFdQN+31L5Frz4etjnF1/ FCpR3tYgN8a1EczwVQxVGRA/jFHLTtTzucYr1vdQCehnTUK7jt/iQL5dnfJ93Q== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X2ff56YsMz1LPm for ; Mon, 9 Sep 2024 21:11:41 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> Date: Mon, 9 Sep 2024 16:11:40 -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 any system) To: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/5/24 13:09, Alan Somers wrote: > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. > > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. > > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: > [... snip ...] If even half of the energy that has gone into these threads would've been spent on a proof-of-concept rust-xtoolchain implementation with some motivating cases instead, we'd be in a lot better place to actually have these conversations. Thanks, Kyle Evans From nobody Mon Sep 9 21:26:42 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 4X2fzh6VM7z5V6Bd for ; Mon, 09 Sep 2024 21:26:56 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2fzh4gXFz4tR1 for ; Mon, 9 Sep 2024 21:26:56 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e1d0e74f484so5136711276.2 for ; Mon, 09 Sep 2024 14:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1725917216; x=1726522016; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8fzm+T/AjZg7UHkQ0sgE2H9h0Uq4qJoU5PclOH3Uxuo=; b=IS5qIMO/CcAoJAwuY/JRKEBfO0hYjquTBM6Jyep87qMQAXvU+Nd0hxHL80XwPxJKnK qSSnsA2ndX53ELvS2M9SYkAUzz4MB8hrZi45n0SvbrQEzXdTZnIOXBUUOWLL0cElcUjJ Rg2O5KPHR+RhLNnHvyWCOozD3HVygqe2cD7gfV9T2xpiq8HQRseJG6IhqDya6aU1SwJc t9gpQXPg8T0iSzb0bY3ZINaVDavL7ZoIeHUqpUBFw3lvQCkK0gwoh7G7c2dR2/nZjl2W V+L2ZBlPMUz+cEQDIHUK2X6j9QZnPapKBOsG4X+6xNOE10KdaifV/nP0xTLbbaooZeXv JZFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725917216; x=1726522016; h=content-transfer-encoding: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=8fzm+T/AjZg7UHkQ0sgE2H9h0Uq4qJoU5PclOH3Uxuo=; b=WoFjj/ZxXEOYnPkkgutoZry8uw1JvxOs0+V19T3g/Lq1bDYSTsrxOrbqGrse/MhBGz pS4QtHYJGNtlBaL3bYNeZcAjS0E4oOFKcw3IWWhVd2hdWXIr0u3hNIOItsErps5vaf56 9NMeZYkptEtH1fXZqNdlUYd5SqMgbIB8l0LdtHVwS4d/YlW7iofKYVfE9T7J//6L0ky4 69Gh9Xjup6XpzgkQ2Mq/EXxeoVUEm17ob3w1raSVZC/mV5D+CLpnctJs4ZBOftXoBXDC ZRGPgiiQk4oc7QB4qQDQ+4XY+gUvqJ1nw/rBWm5tSgwoBkZ+odRXWhUxlzEgH8rq8oRV MOtQ== X-Forwarded-Encrypted: i=1; AJvYcCVVnrAmo1OTrrBJ3//vT8Fu0Rwc/Q1Mezgk7vmZvPwoQ/rKRsWMGFrdOwZywFVc8/MGxlngat36/aBQKiin22s=@freebsd.org X-Gm-Message-State: AOJu0Yz27XkGmohz7QQT4v8ZDMsyMp1sOdoi1MMwz02leqzwIomGaaTG PBBWy+llqkV9yIO5bwJyc+r9fjq9JT8Pjw9ul1c93z+CYlpZd7G6lNha2S+se/rciH+Z+WuHTnQ = X-Google-Smtp-Source: AGHT+IERmc4p5tImjCw8ByNR5zJuaC5NUKtpuWBr1oTx2BQYCPbKpxt7CewGMszcFtfEQ5NY9M6/dw== X-Received: by 2002:a05:6902:905:b0:e12:97d9:4204 with SMTP id 3f1490d57ef6-e1d349f1235mr12115528276.41.1725917215708; Mon, 09 Sep 2024 14:26:55 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e1d7ba0453dsm73224276.16.2024.09.09.14.26.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Sep 2024 14:26:55 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id 3f1490d57ef6-e0875f1e9edso4486607276.1 for ; Mon, 09 Sep 2024 14:26:55 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCX80y7zhTNysXIBnBlkgjr3z8509AlT8/DaOnVlIoSiYmYQl9PrmY+fqaYfiNU2YZXmRCz+tPNrFfCNlTtxomI=@freebsd.org X-Received: by 2002:a05:6902:2612:b0:e13:c10d:85d with SMTP id 3f1490d57ef6-e1d3487085amr11420050276.7.1725917214808; Mon, 09 Sep 2024 14:26:54 -0700 (PDT) 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: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> In-Reply-To: <1aa702e57e63f927b687212820e97f8c@Leidinger.net> From: Tomek CEDRO Date: Mon, 9 Sep 2024 23:26:42 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Alexander Leidinger Cc: Poul-Henning Kamp , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X2fzh4gXFz4tR1 On Mon, Sep 9, 2024 at 11:08=E2=80=AFPM Alexander Leidinger wrote: > Am 2024-09-08 15:02, schrieb Poul-Henning Kamp: > > -------- > > Alexander Leidinger writes: > > > > I'm only going to answer two bits from your email: > > > >> > The source tree became our citadel: "FreeBSD is src". If something > >> > was not in src, it was not FreeBSD. > >> > >> We are way past that too, FreeBSD is src+ports+docs(+community). > > > > Nope. > > > > The only reason the Rust advocates need to bring this up is /precisely/ > > because that is not the case. > > > > If it were, they would just have added ports. > > So you are promoting a Linux-distro style model? I am afraid this is the underlying message and I am happy to see a lot of resistance here :-) --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Mon Sep 9 22:12:57 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 4X2h124d46z5VDx6 for ; Mon, 09 Sep 2024 22:13:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2h122qdRz43xh for ; Mon, 9 Sep 2024 22:13:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5c251ba0d1cso76310a12.3 for ; Mon, 09 Sep 2024 15:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725919988; x=1726524788; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zuKaSjlIBRfQg+VHknaBwlFzx3VNjBkHlt0OXC4mgqk=; b=AAfzKfD2RjzorMBJUaX2qbdmmgITQQz3IRoS2DvvK79X7j7CWcoGRu/Za2Zd54DcLq 48q95B4HQHyRKcjm/nGb2p3njPU1zhSCjs/xsxrpMg7OuJcLGdm464y142NkGIcxjOh4 8Tlg8RhOxeRfQ3lNkCxooPJake01v3lrxAp/kLq6aj87LfgRDq6IJ2ahiD3LonTGSqkQ cfZuD0qckCJ4sLXhqrgtr3Nt1DJb+6bgy2+nuaFY8wIOWuiK6guC6B1kfQM+O9RMTCjG vFY6UM0xZTHBicXva8GYdGk5r8+mlsm7G36gM3h2sM+SAgQxAs0IoSjJ464r03VlvKYs QjjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725919988; x=1726524788; h=content-transfer-encoding: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=zuKaSjlIBRfQg+VHknaBwlFzx3VNjBkHlt0OXC4mgqk=; b=YuGr/xu77vMIXAah4ZsbadB0erDkoutJeOxOSO/BimmqdyBVcOMWZPBOwMvX5IaH+D pmkrTVemXqtxlKEPe8uyIlEA2eEpR9sToCi7nyCWoVVOs0VBnuehuuzZj08GjNWl+nIr iMw49QdA4bFihzf83cxmIxCllOyQNcwcSgcZmNPWCkUUyAiGwrWr0JA7kQfraiG7d7/E MMPQAEJTFvi4dGFObNv2ohgM/EfXnvdoQwhJ5KlmmVud7wWkAmXTBwnOkEy/8Vhg6aij CRCFcgdTDMW0fv8/XcFbAYBtcsroRYCu0wsbDWc9xr8rBjgMJ3NjLdIuxBth1xZhefaa 51uQ== X-Forwarded-Encrypted: i=1; AJvYcCV1YQPuMiXAeDTRhDiOXUfYKySHefpT2dOLLdFZUlyuhESmxUsg6M+/4lQkoUCaaGRpQ3xDFH1mTVEVYXoMvK4=@freebsd.org X-Gm-Message-State: AOJu0YycnRIZGikoQplmjJUPzu9vorFrSart0Yks+TSu/bVnp+w9NANi gerXfF6qSQofGR+AMR/+LuwWSaLXY+WKFLHvukgp9VQa2pCefMWUFjwqhu9pBbE0k792/Tjlu7Q mQWcyGnOCog6JNZkz7t9Hw8BfF/9IHFY= X-Google-Smtp-Source: AGHT+IEbNjnT5Hoz89x9jPr/xcsazHGB5qEadhCSV3XGwUPyLL3PUPi5e98pHiSr/PRsL9dp5Ybsiowc8LDNNDrDRWo= X-Received: by 2002:a05:6402:210e:b0:5bf:7dc:bbaa with SMTP id 4fb4d7f45d1cf-5c3dc7b830bmr8546994a12.26.1725919988213; Mon, 09 Sep 2024 15:13:08 -0700 (PDT) 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: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Mon, 9 Sep 2024 15:12:57 -0700 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Tomek CEDRO Cc: Alexander Leidinger , Poul-Henning Kamp , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4X2h122qdRz43xh On Mon, Sep 9, 2024 at 2:27=E2=80=AFPM Tomek CEDRO wrote= : > > On Mon, Sep 9, 2024 at 11:08=E2=80=AFPM Alexander Leidinger > wrote: > > Am 2024-09-08 15:02, schrieb Poul-Henning Kamp: > > > -------- > > > Alexander Leidinger writes: > > > > > > I'm only going to answer two bits from your email: > > > > > >> > The source tree became our citadel: "FreeBSD is src". If somethin= g > > >> > was not in src, it was not FreeBSD. > > >> > > >> We are way past that too, FreeBSD is src+ports+docs(+community). > > > > > > Nope. > > > > > > The only reason the Rust advocates need to bring this up is /precisel= y/ > > > because that is not the case. > > > > > > If it were, they would just have added ports. > > > > So you are promoting a Linux-distro style model? Although I have no idea how many build from sources, I do think being able to do so is one of the best features of FreeBSD. I would never want to try and build a Linux distro from sources. I just built a Linux kernel and it took about 24hrs on the old hardware I h= ave. (Don't worry. I've only gone over to the "dark side" temporarily;-) As for build times, I already find "make buildworld" takes way too long for me, so adding another ginormous compiler won't make much difference. (I depend on the universe machines, if/when I need to do a full buildworld.= ) I suspect most that do builds from sources will find a machine that can do = it (or just let in run for days while they do other things). I'll stay out of the language debate, I know nothing about Rust. I only hop= e. if you do invest resources in it, that it remains useful for some time. (I remember when CS grads of another Ontario U. would come out with programming skills in Euclid and Turing. Then they would discover no one else on the planet used these languages.) rick > > I am afraid this is the underlying message and I am happy to see a lot > of resistance here :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > From nobody Mon Sep 9 22: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 4X2h6m3WYRz5VFfW for ; Mon, 09 Sep 2024 22:18:08 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 4X2h6m0vPPz44ny; Mon, 9 Sep 2024 22:18:08 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725920279; x=1726586945; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=vN/rfkakh0DMerMNhBAMNGYZrOeA9+mgGL3CdYNs71w=; b=eG00GWtNcKxyDENihoZCs6fvHiDn24aP3VYQhp6UuAEsy2a4umcOdgOvDnqbUjhSIYMBrS46 u0PTwFNWQNSfwtk58BEtLcvmYjDxau544cmE04dzy62EN480NQDZfr6lQu8K1O0sRlW/CArHQG NQPPRuJJWiDiUnWIVp6SS8RPyLXCS5T0RN+if8vFFWTK6hI8I41rxFUsfgos63YBY8ApvUDCg1 8UZTu9zjBwlUXkz2PAz06U7G6+tpkdfecil802xfYifFjsko+5jWdT8Wrx/mveUS0gSz+iR9da h1OVDFhVKjY5y2rTYpUS39HG8VyFM13UHDOKfJQPH141F19A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725920279; x=1726586945; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:author:from: subject:date:to:cc:resent-author:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-reply-to:resent-message-id:in-reply-to: references:mime-version:content-type:content-transfer-encoding: content-disposition:content-id:content-description:message-id: mail-followup-to:openpgp:blahblahblah; bh=vN/rfkakh0DMerMNhBAMNGYZrOeA9+mgGL3CdYNs71w=; b=vTpPwTfbl4XCeNrtlg5gVVq8Ev3jHzOL8Xbp2gAsjxdgCCM3mdw5Ue451rfX81xJNsekZNQ5 fByrUVVgaWITBg== Date: Tue, 10 Sep 2024 00:15:41 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Dmitry Salychev Cc: Jan Knepper , David Chisnall , Poul-Henning Kamp , ske-89@pkmab.se, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <20240909221541.pjyw_h6H@steffen%sdaoden.eu> In-Reply-To: <868qw0uafp.fsf@peasant.bootbsd.com> References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> <202409091332.489DWNmO084207@critter.freebsd.dk> <256401bf-1b46-467a-a44e-42fc14d20ebf@digitaldaemon.com> <868qw0uafp.fsf@peasant.bootbsd.com> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. 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:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4X2h6m0vPPz44ny 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 Dmitry Salychev wrote in <868qw0uafp.fsf@peasant.bootbsd.com>: ... |I've mentioned MISRA C++:2023 already, but would like to elaborate on my |idea behind it. It forms a subset of ISO/IEC 14882:2017 (C++17) by ... |For example, there's a rule 13.1.1 which prohibits classes to be |inherited virtually, but it's in the "advisory" category at the same |time. Rule 13.3.1 states that user-declared member functions shall use |the virtual, override and final specifiers appropriately. ... ..only to mention that somehow the order of the C++ keywords virtual and override are bogus unless (last and only version i truly ready aka bought the book was '98) i have been hitten by a compiler bug. I used to use preprocessor macro things for clarity aka "explicity", but when newer standards came the order was reversed, i know have (horrors!) use wrapper macros to be able to place the keyword correctly, that is either include/su/code.h:# define su_OVRX(X) virtual X or include/su/code.h:# define su_OVRX(X) X override and thus src/su/.main.cxx: OVRX(~a_md__sade(void)) {} or src/su/.main.cxx: OVRX(up property(prop prop) const){ instead of, as before the advent of override ovrx ~a_md__sade(void){} or ovrx up property(prop prop) const){..} *What a mess*!! I mean *is* override an override of virtual, then why is it placed that [fecal]. That is just [fecal]. If they really abolish the preprocessor at some later point, all bets are off. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Sep 9 21:31: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 4X2h6n0rndz5VFcY for ; Mon, 09 Sep 2024 22:18:09 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 4X2h6m0vLRz44mT for ; Mon, 9 Sep 2024 22:18:08 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sdaoden.eu header.s=citron header.b=ZirfEl4O; dkim=pass header.d=sdaoden.eu header.s=orange header.b=tAMtPEFB; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1725920279; x=1726586945; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:mime-version: content-type:content-transfer-encoding:author:from:subject:date:to:cc: resent-author:resent-date:resent-from:resent-sender:resent-to:resent-cc: resent-reply-to:resent-message-id:in-reply-to:references:mime-version: content-type:content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=6YYpMYq31kl7Q3JhhOMb+RFPk/MEVm6JFpn3Qwa5AKk=; b=ZirfEl4OV51TPA0QhI7JW3Zo+yu5J0KCfZmXQnfhYKeSyZ4nN0xu6lkKpvM8BWXgRHK3v7ZM WTNIYRvTaNjrdovGvhC6Ao5hjKjb2ToNJYhc22NJjIFPNoilTJ026um86PH326sCpEXHZV5XWT eQGo1waLD5E21NiEYwX9G/fa6IruXf7pC1gtMoRA9hmn2HkaxMlAdxJNKCUfU9Yt36+guesyRZ 06Dv551ZZh6DABcRA+5QvTo9uW6gUBVQuiZvN6HC7bOcMwH7VJdSYnlPid2j97P9Ykr4NPfhmO B6rXsyUaCPqOa3mt7YeQyy6Plf27VTFljUvdbrqCMpCDR8+Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1725920279; x=1726586945; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:mime-version: content-type:content-transfer-encoding:author:from:subject:date:to:cc: resent-author:resent-date:resent-from:resent-sender:resent-to:resent-cc: resent-reply-to:resent-message-id:in-reply-to:references:mime-version: content-type:content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=6YYpMYq31kl7Q3JhhOMb+RFPk/MEVm6JFpn3Qwa5AKk=; b=tAMtPEFBATznxzgXH+dWR3yenPjCkD78bOisL65AcXLy69Ie11A5Xm9mJKeo5YlootsOcxir jA7r45phszIBAQ== Date: Mon, 09 Sep 2024 23:31:07 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Paul Floyd Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <20240909213107.XGD3_v0I@steffen%sdaoden.eu> In-Reply-To: <9adc3619-bc38-4fe7-bf16-20e0dfb3b619@gmail.com> References: <20240905194529.3szOViVM@steffen%sdaoden.eu> <9adc3619-bc38-4fe7-bf16-20e0dfb3b619@gmail.com> User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. 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-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; R_SPF_ALLOW(-0.20)[+a]; R_DKIM_ALLOW(-0.20)[sdaoden.eu:s=citron,sdaoden.eu:s=orange]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; DMARC_NA(0.00)[sdaoden.eu]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[sdaoden.eu:+] X-Rspamd-Queue-Id: 4X2h6m0vLRz44mT Paul Floyd wrote in <9adc3619-bc38-4fe7-bf16-20e0dfb3b619@gmail.com>: |On 05-09-24 19:45, Steffen Nurpmeso wrote: |> Alan Somers wrote in | |>|The real takeaway here is that C is no longer sufficient for writing |>|high quality code in the 2020s. Everyone needs to adapt their tools. |>=20 |> I *totally* speak against this. |> Quite the opposite i claim that C was safe already fifty years | |Is that a joke? Do you have any evidence? It sounds like wishful=20 |thinking to me. | |When I explain to my young colleagues that learnt to code in Java and=20 |Rust how K&R C function definitions "worked", their eyes open wide in=20 |amazement. Yes, OpenBSD has started using prototypes in perl lately. I still do not do that in the rare cases i use perl. I came over (Basic, DOS batch, J(ava)Script) perl, JAVA, C++ to C and never used prototype-less C myself, K&R, you really, really have a point here. Despite that it is unfortunate but true that prototypes in C and also C++ not seldom do not tell the truth because bit enumerations are missing, and so you have integers of various widths as "bit carriers" through which completely unchecked bits are then passed. Or at least in C, which does not support "easy super-class cast"s, you also very often have to dumb-cast to meet prototyped arguments, which is then an error shall the assumption break at a future time. (For example, assume stupid name hierarchy IOStream{bla;}; OutputStream{IOStream super;bla;}; TextOutputStream{OutputStream super;bla;}; and in order to call a function which takes IOStream* you likely will brute-force cast a TextOutputStream instead of writing &TOS->super.super, for which, it is clear, you also have a naming rule in place.) *Or* you have to create a dedicated macro series which does the cast proper, then also using C-style aka manually stricked [RT]TI aka type information, i think GTK uses this. In short, object hierarchies and casting etc never was on the agenda of ISO C, which results in aggressive and dangerous casts. You know, there quite some relief could have been achieved very easily, best even explicit, with say a new "super" or "base" keyword (super is C++ so that it bad). |> ago, it is just that the occasional one does not realize it. |> *Nothing* prevents you from using a string object instead of |> direct memory accesses, a vector object instead of arrays managed |> via realloc(), and all that. *Nothing |> If *you* do not do that that is your fault and you are a bad |> programmer; moreover, you should not be allowed to vote in |> a democratic environment (surely you do not read all the |> magazines and newspapers, and watch or hear to policital |> emissions, in order to build yourself a *real* opinion), be |> enabled to drive a car, and what else not. | |I'm not sure that I follow your argument. Are you saying that you can=20 |build memory safety into C code and that if someone doesn't so they are= =20 |a bad programmer? What's the point - why not just use a memory safe=20 |language? Because Floyd means pink not paul, hah! But answering your question i would say it does not make much of a difference to me -- *if* i can go the way i want -- regarding safety, but a lot regarding runtime and infrastructural overhead. For example most of the development time i compile with tcc that is 334640 bytes and links to almost nada. #?0|kent:built$ ll tcc#20240731-1.pkg.tar.zst -rw-rw---- 1 ports ports 273285 Aug 3 22:11 tcc#20240731-1.pkg.tar.zst #?0|kent:built$ ll gcc#14.2.0-1.pkg.tar.zst -rw-rw---- 1 ports ports 67854914 Aug 1 21:59 gcc#14.2.0-1.pkg.tar.zst #?0|kent:built$ ll clang#18.1.8-1.pkg.tar.zst -rw-rw---- 1 ports ports 74166358 Jun 22 21:26 clang#18.1.8-1.pkg.tar.zst #?0|kent:built$ ll llvm#18.1.8-1.pkg.tar.zst -rw-rw---- 1 ports ports 136797237 Jun 22 23:57 llvm#18.1.8-1.pkg.tar.zst #?0|kent:built$ ll compiler-rt#18.1.8-1.pkg.tar.zst -rw-rw---- 1 ports ports 3378581 Jun 23 00:02 compiler-rt#18.1.8-1.pkg.ta= r.zst Unfortunately pcc is dead, it detected things that clang and gcc did not (via warning options etc). tcc is very bad in such. And then there is other overhead. For example if you have a vector type then in JAVA an at() (iirc) access always asserts the offset, and throws an ArrayIndexOutOfBoundsException (iirc) if that is invalid. If you do that in C, you can ASSERT() the offset. Or, if you know that the offset could be invalid, either create a at_checked() or what accessor or add the check in your code. Or, if you have a string and want to resize it, you can check against overflow, inline, and let the compiler optimize away most the nonsense that effectively there is, for example INLINE boole n_string_get_can_book(uz len){ return (S(uz,S32_MAX) - ALIGN_Z(1) > len); } INLINE boole n_string_can_book(struct n_string *self, uz len){ return (n_string_get_can_book(len) && S(uz,S32_MAX) - ALIGN_Z(1) - len > self->s_len); } Or, you compact memory allocations by allocating an object plus additional room for whatever, one of the posted CVEs was like that, ie do "buf =3D &(sp =3D ALLOC(sizeof(*sp) + LEN))[1]". This is not possible if you have to live with language managed objects, may they be safe. Except for C++, which is (much too) flexible, and allows one to create stuff like for example #define su_MEM_NEW_HEAP(T,VP) new(VP, su_S(su_NSPC(su)mem::johnny*,su_NIL= )) T via inline void *operator new(size_t sz, void *vp, NSPC(su)mem::johnny const = *j){ UNUSED(sz); UNUSED(j); return vp; } via struct johnny; (ie *unfortunately* overloading works like that only). and then the reverse via #define su_MEM_DEL_HEAP(TP) su_NSPC(su)mem::del__heap(TP) #define su_MEM_DEL_HEAP_PRIVATE(T,TP) (su_ASSERT((TP) !=3D su_NIL), (TP)-= >~T()) via template static void del__heap(T *tptr){ ASSERT_RET_VOID(tptr !=3D NIL); tptr->~T(); } In general all shit, unfortunately. Anyway with that you *can* create aka manage objects in whatever memory chunk you want. And, to me, i use objects whenever i can, which consist of other objects, etc, and then i delete (or destruct, say) the objects i hold, and they delete (or destruct, anyway) they consist of, and in the end there is no memory leak. Memory leaks or buffer overruns i usually do not produce. But i *do* produce logical errors like su_idec(): FIX: signed negative overflow would return S64_MAX - else + else{ res =3D U64_MAX; - rv &=3D ~su_IDEC_STATE_SEEN_MINUS; + rv &=3D ~S(u32,su_IDEC_STATE_SEEN_MINUS); + } or a_colour_mux(): HORRIBLE FIX! Assign correct pointer (=CE=A7=CE=AC=CF= =81=CE=B7=CF=82 =CE=9A=CE=B1=CF=81=CE=B1=CF=87=CF=81=CE=B9=CF=83=CF=84=CE= =B9=CE=B1=CE=BD=CE=AF=CE=B4=CE=B7=CF=82).. - }else + }else if(a_COLOUR_TAG_IS_SPECIAL(ctag)) cmp->cm_tag =3D ctag; + else + cmp->cm_tag =3D NIL; and in that latter, indeed, a big fat C++ constructor that simply initializes all members *even though* it directly thereafter sets them to other values would have avoided it. (But these are so *horrible* things that i often try to circumvent the condition by creating specialized constructor which result in a partial initialized object, which would then, i think, not be possible in a "safe" language, at least easily.) |A+ |Paul Trio sang "Los Paul" (du mu=C3=9Ft im voll in die Eier hauen, eh, "you have to hit him hard in the testicles") over fourty years ago. They meant Paul Breitner by then, but, still.. --End of <9adc3619-bc38-4fe7-bf16-20e0dfb3b619@gmail.com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Tue Sep 10 00:19: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 4X2kqB05QSz5VwCy for ; Tue, 10 Sep 2024 00:19:50 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X2kq90wVJz4QFQ for ; Tue, 10 Sep 2024 00:19:49 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=digitaldaemon.com; spf=pass (mx1.freebsd.org: domain of jan@digitaldaemon.com designates 162.217.114.50 as permitted sender) smtp.mailfrom=jan@digitaldaemon.com Received: (qmail 29727 invoked by uid 89); 10 Sep 2024 00:19:46 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 10 Sep 2024 00:19:46 -0000 Message-ID: <68c1bed4-45ae-4a2b-8061-7c49abac67f7@digitaldaemon.com> Date: Mon, 9 Sep 2024 20:19:46 -0400 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: It's not Rust, it's FreeBSD (and LLVM) To: Rick Macklem , Tomek CEDRO Cc: Alexander Leidinger , Poul-Henning Kamp , freebsd-hackers@freebsd.org References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> Content-Language: en-US From: Jan Knepper In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: / X-Spamd-Result: default: False [-0.10 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_SHORT(-0.99)[-0.992]; NEURAL_HAM_LONG(-0.67)[-0.667]; NEURAL_SPAM_MEDIUM(0.65)[0.653]; DMARC_POLICY_ALLOW(-0.50)[digitaldaemon.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:162.217.114.48/28]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[jan]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,cedro.info] X-Rspamd-Queue-Id: 4X2kq90wVJz4QFQ On 9/9/24 18:12, Rick Macklem wrote: > On Mon, Sep 9, 2024 at 2:27 PM Tomek CEDRO wrote: >> On Mon, Sep 9, 2024 at 11:08 PM Alexander Leidinger >> wrote: >>> Am 2024-09-08 15:02, schrieb Poul-Henning Kamp: >>>> -------- >>>> Alexander Leidinger writes: >>>> >>>> I'm only going to answer two bits from your email: >>>> >>>>>> The source tree became our citadel: "FreeBSD is src". If something >>>>>> was not in src, it was not FreeBSD. >>>>> We are way past that too, FreeBSD is src+ports+docs(+community). >>>> Nope. >>>> >>>> The only reason the Rust advocates need to bring this up is /precisely/ >>>> because that is not the case. >>>> >>>> If it were, they would just have added ports. >>> So you are promoting a Linux-distro style model? > Although I have no idea how many build from sources, I do think being > able to do so is one of the best features of FreeBSD. It is one of the great features. It is well structured. It is well documented. It is relatively easy to accomplish. > I would never want to try and build a Linux distro from sources. > I just built a Linux kernel and it took about 24hrs on the old hardware I have. > (Don't worry. I've only gone over to the "dark side" temporarily;-) Likewise... Once was enough... :-) From nobody Tue Sep 10 00:36: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 4X2lBl66Tvz5W2kJ for ; Tue, 10 Sep 2024 00:36:47 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X2lBl5ZPZz4Trv for ; Tue, 10 Sep 2024 00:36:47 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 31734 invoked by uid 89); 10 Sep 2024 00:36:47 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 10 Sep 2024 00:36:47 -0000 Content-Type: multipart/alternative; boundary="------------OQzwbbr9AH3DlA4Ja7AN00wi" Message-ID: Date: Mon, 9 Sep 2024 20:36:46 -0400 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 any system) To: fvalasiad , "theraven@freebsd.org" , "phk@phk.freebsd.dk" Cc: "ske-89@pkmab.se" , "freebsd-hackers@freebsd.org" References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> Content-Language: en-US From: Jan Knepper In-Reply-To: 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:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X2lBl5ZPZz4Trv This is a multi-part message in MIME format. --------------OQzwbbr9AH3DlA4Ja7AN00wi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/9/24 15:18, fvalasiad wrote: > I am beyond curious to see any reasonable study on C++ projects that employ RAII, use the STL and generally speaking follow modern guidelines, that still suffer from memory related CVEs. > It is what many, including myself, have done for the last ~3.5 decades... Rarely suffer any memory related CVEs. This is also due to the use of shared_ptr <>, unique_ptr <>, etc, the use of analyzers, such as Coverity, SonarQube, etc, etc, etc. When we deal with them, mostly during development testing, it is often because somebody is maintaining legacy code that has not been developed by them, and the person who originally developed the code it is no longer available. Of course we deal with some C++ code that originally was written 30+ years ago, which has undergone several revisions to meet newer C++ standards. New code is developed following the C++20 (2020) standards. However, it certainly takes effort to have all the noses of the team members pointing to the the same standard...  Code Review enforces it and force those who lag to redesign their code to modern standards. --------------OQzwbbr9AH3DlA4Ja7AN00wi Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/9/24 15:18, fvalasiad wrote:
I am beyond curious to see any reasonable study on C++ projects that employ RAII, use the STL and generally speaking follow modern guidelines, that still suffer from memory related CVEs.
It is what many, including myself, have done for the last ~3.5 decades...

Rarely suffer any memory related CVEs. This is also due to the use of shared_ptr <>, unique_ptr <>, etc, the use of analyzers, such as Coverity, SonarQube, etc, etc, etc. When we deal with them, mostly during development testing, it is often because somebody is maintaining legacy code that has not been developed by them, and the person who originally developed the code it is no longer available.

Of course we deal with some C++ code that originally was written 30+ years ago, which has undergone several revisions to meet newer C++ standards.

New code is developed following the C++20 (2020) standards.

However, it certainly takes effort to have all the noses of the team members pointing to the the same standard...  Code Review enforces it and force those who lag to redesign their code to modern standards.

--------------OQzwbbr9AH3DlA4Ja7AN00wi-- From nobody Tue Sep 10 01:05:44 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 4X2lrJ6VMJz5W5yZ; Tue, 10 Sep 2024 01:05:52 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2lrH62PYz4Xrg; Tue, 10 Sep 2024 01:05:51 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=daMs+lUl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::134 as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5365cc68efaso2934780e87.1; Mon, 09 Sep 2024 18:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725930349; x=1726535149; darn=freebsd.org; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=9Nr+PMWJ0cvFk9krbCuHyFG2/xuUijibH8ER+7a1Gek=; b=daMs+lUl2JvLETVKX9X9xRrOgIwHzoaiXx/s6ROKvZ4Blwka+wA45pwh2xg6FWnI4z fjdaxHGelNWDkmTtjBH/ZY3TCIUvqv+i9GHBLTisMJtKarHZecKeJH2b3NWxTFlN+HD1 kJYYFXJ/Coj4uA9XeNS5H/k7fL0/sWuEROIu1lqXkhYGtp6H7i7v+Y44YZNvbw0NU5Of 9QMgwZIFydv1NONCxoqqlb2/hT7xrGUNtMZEcyXJGhDok8Sbfo6toTxUnUNVdq2t0SMR 0o/x2X3alIyD5vpaOKtRsJ4Ujn5XpbY0xGRmdqxBbDAaCbehy/9f8sVk0/XpIscpglQD Ny9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725930349; x=1726535149; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9Nr+PMWJ0cvFk9krbCuHyFG2/xuUijibH8ER+7a1Gek=; b=UhPyebZPMzaUOMKmF/DJnkVmw2nrMiePgVfveP/l6oXcZOsFccjoId7anVs0RLAzcm N9xM0Bw6dyg50MGv590355VXT5+TyzfWmzKT3T9CoQ34w4iTmw7IBFai5d2S7POALcH0 EYCKZRDtjotKXUcayoKxn7Mkem/M5cyzYHfxVJBuYxFk+67GU7foRvXl4bHb/Yw/KhiS DqUq5a7G2KCiICiXtZadwpyqanDSSg1A9h+ilAuFI/g7WEOSV1nD7YJA55HBu55EMLdH XBQ3BHEucb+fiwL1g3hCLrXjMYkcggXA8YduzxTd1S5dnEsHDisOOODqgJx3thyFX/an PMBw== X-Forwarded-Encrypted: i=1; AJvYcCV84kkRkeWISeXlDgn2jfzvfw6a5m75CCF5GX+RbRF2F9Nf3p7sU7LeuEztrN1L/J8Z/kobLM4px7/4quM=@freebsd.org, AJvYcCXylIcOAr5hAKXI3Xn9MeVZfBXI76kRHMVQl9s26VpAXN0ZMtOA4pBpHTMsmGm0x97ag5J0S6xRYsBiVH3UqWw=@freebsd.org X-Gm-Message-State: AOJu0Yz0PpwA33HLZkmemvzZ1NHCfLPV5lwCmDPHFifgDfyIrtFGDVYv Jb+fOtzCtJgrcsa7ZUyW1OwhD4m0A/ODcSL4pHTWQ57O+jCBXVFLCwVuFG2O X-Google-Smtp-Source: AGHT+IFgmynDElvygkAMoUaHF9Nx9iG/peV6DgXkFUjzvvnKTA+tvW8l0ViqB0ZX33ODbvZM9xiTKw== X-Received: by 2002:a05:6512:1110:b0:52d:b150:b9b3 with SMTP id 2adb3069b0e04-536587b545dmr8620481e87.32.1725930348584; Mon, 09 Sep 2024 18:05:48 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5365f8cb6fbsm922220e87.134.2024.09.09.18.05.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Sep 2024 18:05:48 -0700 (PDT) Date: Tue, 10 Sep 2024 04:05:44 +0300 From: Vadim Goncharov To: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tcpdump-workers@lists.tcpdump.org, tech-net@NetBSD.org Cc: Alexander Nasonov Subject: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240910040544.125245ad@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-Spamd-Bar: --- X-Spamd-Result: default: False [-3.17 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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]; NEURAL_HAM_SHORT(-0.17)[-0.169]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::134:from]; RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-hackers@freebsd.org,freebsd-net@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4X2lrH62PYz4Xrg Hello! We don't need ELF relocations! We want better loop control! No so little parameters, Verifier! Leave our code alone! -- Ping Floyd I've recently had some experience with Linux's ePBF in it's XDP, and this l= eft quite negative impression. I was following via https://github.com/xdp-proje= ct/xdp-tutorial and after 3rd lesson was trying to create a simple program for searching TCP timestamp option and incrementing it by one. As you know, eBPF tool stack consists of at least clang and eBPF verifier in the kernel, and after two d= ozen tries eBPF verifier still didn't accept my code. I was digging into verifier sources, and the abysses opened in front of me! Carefully and boringly going via disassembler and verifier output, I've found that clang optimizer ignor= es just checked register - patching one byte in assembler sources (and target = .o) did help. I've filed https://github.com/iovisor/bcc/issues/5062 with details if one curious. So, looking at eBPF ecosystem, I must say it's a Frankenstein. Sewn from go= od, sometimes brilliant parts, it's a monster in outcome. Verifier is in it's o= wn right, compiler/optimizer is in it's own right... But at the end you even don't have a high-level programming language! You must write in C, relative= ly low-level C, and restricted subset of C. This requires very skilled professionals - it's far from something not even user-friendly, but at least sysadmin-friendly, like `ipfw` or `iptables` firewall rules. Thus I looked at the foundation of eBPF architecture, with which presupposi= tions in mind it was created with. In fact, it tries to be just usual programming after checks - that is, with all that pointers. It's too x86-centric and Linux-centric - number of registers was added just ten. So if you look at t= he GitHub ticket above, when I tried to add debug to program - you know, just specific `printf()`s - it failed verifier checks again because compiler now had to move some variables between registers and memory, as there is limit = on just 5 arguments to call due to limit of 5 registers! And verifier, despite being more than 20,000 lines of code, still was not smart enough to track i= nfo between registers and stack. So, if we'd started from beginning, what should we do? Remember classic BPF: it has very simple validator due to it's Virtual Machine design - only forw= ard jumps, checks for packet boundaries at runtime, etc. You'd say eBPF tries f= or performance if verifier's checks were passed? But in practice you have to t= oss in as much packet boundary checks as near to actual access as possible, or verifier may "forget" it, because of compiler optimizer. So this is not of much difference for checking if access is after packet in classic BPF - the same CMP/JUMP in JIT if buffer is linear, and if your OS has put packet in several buffers, like *BSD or DPDK `mbuf`'s, the runtime check overhead is negligible in comparison. Ensuring kernel stability? Just don't allow arbitrary pointers, like origin= al BPF. Guaranteed termination time? It's possible if you place some restrictions. = For example, don't allow backward jumps but allow function calls - in case of stack overflow, terminate program. Really need backward jumps? Let's analyze for what purpose. You'll find these are needed for loops on packet contents. Solve it but supporting loops in "hardware"-controlled loops, which can't be infinite. Finally, platforms. It's beginning of sunset of x86 era now - RISC is comin= g. ARM is now not only on mobiles, but on desktops and servers. Moreover, it's era of specialized hardware accelerators - e.g. GPU, neural processors. Even general purpose ARM64 has 31 register, and specialized hardware can implement much more. Then, don't tie to Linux kernel - BPF helpers are very rigid interface, from ancient era, like syscalls. So, let's continue *Berkeley* Packet Filter with Berkeley RISC design - hav= ing register window idea, updated by SPARC and then by Itanium (to not waste registers). Take NetBSD's coprocessor functions which set is passed with a context, instead of hardcoded enums of functions - for example, BPF maps = is not something universal, both NetBSD and FreeBSD have their own tables in firewall. Add more features actually needed for *network* processor - e.g. 128-bit registers for IPv6 (eBPF axed out even BPF_MSH!). And do all of this in ful= ly backwards-compatible way - new language should allow to run older programs from e.g. `tcpdump` to run without any modifications, binary-compatible (again, eBPF does not do this - it's incompatible with classiv BPF and uses a translator from it). Next, eBPF took "we are masquerading usual x86 programming" way not only ju= st in assembly language. They have very complex ELF infrastructure around it w= hich may be not suitable for every network card - having pc-addressed literals, = as in RISC processors allows for much simpler format: just BLOB of instruction= s. BPF64 adds BPF_LITERAL "instruction" of varying length (it's interpreted by just skipping over contents as if it was jump), which, if have special signatures and format, allow for this BLOB of instructions to contain some metadata about itself for loading, much simpler than ELF (esp. with DWARF). Then, ecosystem. eBPF defines functions callable from user code like: > enum bpf_func_id___x { BPF_FUNC_snprintf___x =3D 42 /* avoid zero */ }; That is, ancient syscall-like way of global constant, instead of context. A "context" here is the structure passed with code to execution which contains function pointers of what is available to this user code, in spirit of NetBSD's `bpf_ctx_t` for their BPF_COP/BPF_COPX extensions. This is not only provides better way than "set in stone" syscall-like number, but BPF64 goes further and defines an "packages" in running kernel with namespaces to allow e.g. Foo::Bar::baz() function to call Foo::quux() from another BPF program, populating ("linking") it's context with needed function without relocation= s. These "packages" expected to be available to admin in e.g. sysctl tree, with descriptions, versioning and other attributes. Some other quotes about how restricted eBPF is: > First, a BPF program using bpf_trace_printk() has to have a GPL-compatibl= e license. > Another hard limitation is that bpf_trace_printk() can accept only up to = 3 input arguments (in addition to fmt and fmt_size). This is quite often pr= etty limiting and you might need to use multiple bpf_trace_printk() invocat= ions to log all the data. This limitation stems from the BPF helpers abilit= y to accept only up to 5 input arguments in total. > Previously, bpf_trace_printk() allowed the use of only one string (%s) ar= gument, which was quite limiting. Linux 5.13 release lifts this restriction= and allows multiple string arguments, as long as total formatted output do= esn't exceed 512 bytes. Another annoying restriction was the lack of suppor= t for width specifiers, like %10d or %-20s. This restriction is gone now as= well > Helper function bpf_snprintf > Outputs a string into the str buffer of size str_size based on a format s= tring stored in a read-only map pointed by fmt. > > Each format specifier in fmt corresponds to one u64 element in the data a= rray. For strings and pointers where pointees are accessed, only the pointe= r values are stored in the data array. The data_len is the size of data in = bytes - must be a multiple of 8. > > Formats %s and %p{i,I}{4,6} require to read kernel memory. Reading kernel= memory may fail due to either invalid address or valid address but requiri= ng a major memory fault. If reading kernel memory fails, the string for %s = will be an empty string, and the ip address for %p{i,I}{4,6} will be 0. Not= returning error to bpf program is consistent with what bpf_trace_printk() = does for now. > > Returns > > The strictly positive length of the formatted string, including the trail= ing zero character. If the return value is greater than str_size, str conta= ins a truncated string, guaranteed to be zero-terminated except when str_si= ze is 0. > > Or -EBUSY if the per-CPU memory copy buffer is busy. > > static long (* const bpf_snprintf)(char *str, __u32 str_size, const char = *fmt, __u64 *data, __u32 data_len) =3D (void *) 165; So. In summary: BPF64 has not only traditional ("firewall on network packet= s") area of use but also suitable - and having goals to design in mind - for: * non-network. e.g. syscall arguments checking * network protocols passing untrusted code which can be run by other side in restricted sandbox (e.g. muSCTP custom (de)compression rules) * an alternative to https://capnproto.org/rpc.html for multi-method calls on high-latency links (e.g. MQTT5-like and/or for environments when Cap=E2=80=99n Proto itself is not applicable, e.g. no direct connect= ions) I've put a sketch of design to https://github.com/nuclight/bpf64 with files: * The `nuc_ts_prog_kern.c` (and it's include `nuc_ts_common_kern_user.h`) is XDP/eBPF program (for Linux 6.5) for parsing TCP packet and incrementing it's Timestamp option, if any, recording statisitics intop eBPF map. * The `nuc_ts_incr.baw` (and it's include `nuc_ts_incr.bah`) is the equival= ent program doing the same thing, but in a new BPF64 Assembler Wrapper langua= ge, not yet written and subject to change. Note this is a lower-level language than C, viewed as intermediate solution until BPF64 becomes stable, after which more higher-level language (higher than C) should be written, at le= ast as expressible as `tcpdump` (`libpcap`) one. * `bpf64spec.md` for draft of Specification, but currently it's more in a "a draft of draft" state :-) I am requesting comments about this architecture before implementing, especially from people knowledgeable in JIT compilers, because, though while I see BPF64 much more simpler than eBPF (probably just several man-months to implement), my sabbatical has ended - and design mistakes are much harder to fix when implementation already exists. --=20 WBR, @nuclight From nobody Tue Sep 10 03:42:53 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 4X2qKd3g9wz5WVkK for ; Tue, 10 Sep 2024 03:43:01 +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 4X2qKd0fQfz4tLt for ; Tue, 10 Sep 2024 03:43:00 +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 48A3gsHY040420; Tue, 10 Sep 2024 04:42:54 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 48A3grF2040419; Tue, 10 Sep 2024 04:42:53 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202409100342.48A3grF2040419@donotpassgo.dyslexicfish.net> Date: Tue, 10 Sep 2024 04:42:53 +0100 Organization: Dyslexic Fish To: jamie@catflap.org, Cy.Schubert@cschubert.com Cc: void@f-m.fm, freebsd-hackers@FreeBSD.org Subject: Re: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> <20240909143239.8F285AF@slippy.cwsent.com> In-Reply-To: <20240909143239.8F285AF@slippy.cwsent.com> 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]); Tue, 10 Sep 2024 04:42:54 +0100 (BST) 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] X-Rspamd-Queue-Id: 4X2qKd0fQfz4tLt Cy Schubert wrote: > Those of us who build from source and build ports, whether manually or > through our own poudriere, are the minority. Just visit the FreeBSD forums. > I attend OpenHack here. People who do use FreeBSD use freebsd-update and > binary packages. (I use freebsd-update and binary packages on some VMs at > $JOB, while maintaining my own network at home as any developer does.) > > And that's a marketing feature of FreeBSD. Most users don't want he hassle > of building and installing an O/S. Sure, I realise that. And I'm not knocking binary installs - indeed installing from a 2.2.6-release CD was how I got into FreeBSD, and I stuck to that method for a while. In fact, at the time, I had an intranet site at ICL (where I worked at the time) titled something like "Install your own unix operating system in just 40 minutes"), where I raved about how easy and quick it was! > Out in the real world people use binary updates and binary packages. We > developers are an anomaly these days. > > Just because a few of us build from source doesn't mean the rest of the > world does. I know, but many of the comments here have implied just about no-one builds from source. I just wanted to readdress that balance. Hell, one comment said if I compile from source, I must be a committer, but I've yet to find that commit bit :-) I don't mind that there's a focus on binary distributions; I don't mind if source building gets a bit trickier; I just hope source building remains a viable route for those of us who aren't part of the FreeBSD organisation. We may be a minority, but there are still a number of us here! Cheers, Jamie From nobody Tue Sep 10 04:06: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 4X2qrD0GPsz5WYyQ for ; Tue, 10 Sep 2024 04:06:04 +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 4X2qrC5t64z4xC2; Tue, 10 Sep 2024 04:06:03 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: X-Catflap-Envelope-To: cy@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 48A460iv042730; Tue, 10 Sep 2024 05:06:01 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 48A4608k042729; Tue, 10 Sep 2024 05:06:00 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202409100406.48A4608k042729@donotpassgo.dyslexicfish.net> Date: Tue, 10 Sep 2024 05:06:00 +0100 Organization: Dyslexic Fish To: void@f-m.fm, daniel.engberg.lists@pyret.net Cc: freebsd-hackers@FreeBSD.org, cy@FreeBSD.org Subject: Re: Binary updates (was Re: It's not Rust, it's FreeBSD (and LLVM)) References: <202409031532.483FW0If007252@critter.freebsd.dk> <3845d980-7160-4819-82a4-db2281828c8c@app.fastmail.com> <202409090442.4894gGMb086473@donotpassgo.dyslexicfish.net> <20240909143239.8F285AF@slippy.cwsent.com> <15a38054-3a14-4eb4-a803-9ce12e413194@app.fastmail.com> 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]); Tue, 10 Sep 2024 05:06:01 +0100 (BST) 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] X-Rspamd-Queue-Id: 4X2qrC5t64z4xC2 Daniel Engberg wrote: > I would also like to remind people that at least for ports far from > all ports have runtime detection of SIMD instructions which can cause > quite a bit of a difference in performance so setting CPUTYPE might > drastically improve performance. Very much this! (I didn't mention it in earlier replies for danger of being called a "ricer", but I only add -march=native, not any other ricer flags!) Cherrs, Jamei From nobody Tue Sep 10 06:30: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 4X2v2d6yQMz5ThjL for ; Tue, 10 Sep 2024 06:30:17 +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 4X2v2d3Fmcz42FL for ; Tue, 10 Sep 2024 06:30:17 +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 F0B8C892DA; Tue, 10 Sep 2024 06:30:14 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48A6UEvY090552; Tue, 10 Sep 2024 06:30:14 GMT (envelope-from phk) Message-Id: <202409100630.48A6UEvY090552@critter.freebsd.dk> To: Alexander Leidinger cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-reply-to: <1aa702e57e63f927b687212820e97f8c@Leidinger.net> From: "Poul-Henning Kamp" References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.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" Content-ID: <90550.1725949814.1@critter.freebsd.dk> Date: Tue, 10 Sep 2024 06:30:14 +0000 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] X-Rspamd-Queue-Id: 4X2v2d3Fmcz42FL -------- Alexander Leidinger writes: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > So you are promoting a Linux-distro style model? No. But you already knew that. Please try to be less inflamatory. -- 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 Tue Sep 10 06:38: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 4X2vDY3J09z5TjnM; Tue, 10 Sep 2024 06:38:53 +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 4X2vDY296Gz44db; Tue, 10 Sep 2024 06:38:53 +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 81BCB892DA; Tue, 10 Sep 2024 06:38:51 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48A6cor2090591; Tue, 10 Sep 2024 06:38:50 GMT (envelope-from phk) Message-Id: <202409100638.48A6cor2090591@critter.freebsd.dk> To: Vadim Goncharov cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tcpdump-workers@lists.tcpdump.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative In-reply-to: <20240910040544.125245ad@nuclight.lan> From: "Poul-Henning Kamp" References: <20240910040544.125245ad@nuclight.lan> 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: <90589.1725950330.1@critter.freebsd.dk> Date: Tue, 10 Sep 2024 06:38:50 +0000 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] X-Rspamd-Queue-Id: 4X2vDY296Gz44db -------- Vadim Goncharov writes: > I've put a sketch of design to https://github.com/nuclight/bpf64 with files: Counter proposal: 1. Define the Lua execution environment in the kernel. 2. Add syscall to submit a precompiled Lua program (as bytecode) 3. Add syscall to execute submitted Lua program And yes: I'm being 100% serious. If we are going to reinvent "Channel Programs" 67 years after IBM came up with them for their 709 vacuum tube computer, at the very least we should use a sensible language syntax. Poul-Henning -- 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 Tue Sep 10 07:14: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 4X2w171nY9z5TpTB for ; Tue, 10 Sep 2024 07:14:03 +0000 (UTC) (envelope-from kp@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2w171JSsz49rM; Tue, 10 Sep 2024 07:14:03 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725952443; 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=LX2O6eMYpQRoK1dnpfBaYDk0q75Cm1Q9LzXwlRHJ1E0=; b=cWagP8AVViYMdxcxAvoF/wENYIVH+Cq5GkGpIyzCR8kqkX1Y9+XjyIMXKU5R88kpsGhEnR dLhrguBQI3qyYuwbmQeE9zcpkNXnZHUDMoO1hxfgvsnTGaAQpzeN18BeJj9XzsC/QnzHIq hgNtvhpwfttX33rYkfGkDBlwXOvo/a0ABDJ2hhMYt5vpMqIOYgeZT5nWqntihfHaIk2U4U lLfqAv01UJNJy4b+Qq8dvxlGEFdcuZJSAcfc2PfPR4QEXxFSZkOAaxfQmdkWQRYCHTD7h0 F8eVBddDfSA3on5O2RHTkM4FU8u9RB0V4ZS09NoeIcaxeAFUZ5bmvCJ8nhkj7g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725952443; a=rsa-sha256; cv=none; b=FK9uTN1ssbUhHVlS/fg0NlqyNrv3k1yaGH89AfIozGneuFyMgUSqscGrpeutVAifhCckun N9yvcZmWbQ2jTfdcsv/K/GbFFySOglbUQ1tPOY517fV6WoN3oiqIvNQ2LYfiBhOrDalqFd 2S7z/JsDNg2QPgOGNWCTRqwYUZ9GNH9scWQW6QpQCj6t+F8ZXa/BkEDMlVYK0vZOiE7HVb 4khNxUWIymKHHiGCY8ytwRMD2BHZZ3MAVKPjm82iBJnULTrKJHWdVHaDU3/lidWOToHABv R0ec6P5vyvQ9rx4KGcjimYMVZXHFO1fTkrxKBoDhKSFJSnYtUlRCaw7k/cgSeA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725952443; 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=LX2O6eMYpQRoK1dnpfBaYDk0q75Cm1Q9LzXwlRHJ1E0=; b=K1ZQvKkNOOV7A2GpHkuRBSWeUDL1CPOcsgyrPiXUlWFgkm5vGOOtSeoupWP/tFYlHeDhkg WQ61kR4NgvfQoLdq39jTx63VD+qxwphypJC/PfOXLGGa98V/qNU2Sg8nfHcWLKgpwttqZu 9k5puTDHHCavMZjRrE7QUQmz+u3RAf9pR0wwu5F1axBkjUOOluhc4eOzn2xuBoqIll4tTm x1EqbIKPB5kScWCB2JDFmlOfNcoSggjxhr+mBhuotcAIYFpEIvzMOXzs9bxYjdZMkMDRl8 maAtxaKSb9FkGyPWzmeFXlc8O3kmBe1KNobBI58vNxTPlHTMj2xK4qp2TTjArQ== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X2w1709bVzJtm; Tue, 10 Sep 2024 07:14:02 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 349374C793; Tue, 10 Sep 2024 09:14:01 +0200 (CEST) From: Kristof Provost To: Steve Kargl Cc: freebsd-hackers@freebsd.org Subject: Re: New lock-order reversal Date: Tue, 10 Sep 2024 09:14:00 +0200 X-Mailer: MailMate (1.14r5937) Message-ID: <0C85EBE5-53CD-414D-8B18-6E1F768DB58A@FreeBSD.org> In-Reply-To: References: <72AF10E0-CB5A-4CB6-A50A-30A06DB7EA03@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="=_MailMate_F7C264A3-A6E7-4CA2-8308-345028A6D4FF_=" Content-Transfer-Encoding: 8bit --=_MailMate_F7C264A3-A6E7-4CA2-8308-345028A6D4FF_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6 Sep 2024, at 19:15, Steve Kargl wrote: > On Fri, Sep 06, 2024 at 06:49:48PM +0200, Kristof Provost wrote: >> I’ve had another look at this, and while I can probably avoid this >> for >> setting the tunnel function (basically by assuming setting it never >> fails or >> is already done, which is currently the case), I’m not happy with >> the only >> solution I see on the removal side (i.e. “don’t, just trust that >> the socket >> will be closed soon”). > > Thanks for the patch. I'll add to my kernel when I rebuild it. > Unfortuantely, I have way too little understanding about locking > within the kernel to be of much help. > I’m not very happy with that first patch. Can you try [https://reviews.freebsd.org/D46615](https://reviews.freebsd.org/D46615) and [https://reviews.freebsd.org/D46616](https://reviews.freebsd.org/D46616) instead? (That first patch is just cleanup, but you’ll probably want it to avoid conflicts.) Best regards, Kristof --=_MailMate_F7C264A3-A6E7-4CA2-8308-345028A6D4FF_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 6 Sep 2024, at 19:15, Steve Kargl wrote:

On Fri, Sep 06, 2024 at 06:49:48PM = +0200, Kristof Provost wrote:

I=E2=80=99ve had another look at this, and while I can probably avoid= this for
setting the tunnel function (basically by assuming setting it never fails= or
is already done, which is currently the case), I=E2=80=99m not happy with= the only
solution I see on the removal side (i.e. =E2=80=9Cdon=E2=80=99t, just tru= st that the socket
will be closed soon=E2=80=9D).

Thanks for the patch. I'll add to my kernel= when I rebuild it.
Unfortuantely, I have way too little understanding about locking
within the kernel to be of much help.


I=E2=80=99m not very happy with that first patch.

Can you try https://reviews.freebsd.org/D46615 and https://reviews.freebsd.org/D46616 instead?

(That first patch is just cleanup, but you=E2=80=99ll pro= bably want it to avoid conflicts.)

Best regards,
Kristof

--=_MailMate_F7C264A3-A6E7-4CA2-8308-345028A6D4FF_=-- From nobody Tue Sep 10 07:42:37 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 4X2wfP5Qhtz5TvfM for ; Tue, 10 Sep 2024 07:42:53 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2wfN3YZRz4G2Z for ; Tue, 10 Sep 2024 07:42:52 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none Received: from remote (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: alexander@leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id CA7D788B0; Tue, 10 Sep 2024 09:42:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1725954163; 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: in-reply-to:in-reply-to:references:references; bh=7hDOEop0KmXKdMTn3qLXLz6EDDRLLSonX+NoFlVle50=; b=iC89Me9iIjnGUSQ3xRnovGoXU3kdZ/EzOmkmRS/KD5SXzTAPcKLcm0cAO9Buh26bIy1omV Z9IsIxRc4DgDGw9h9/0gYi6wz+amcqty+Hj/7xDjrGd2nJ3dtDQvl2NjZOf01msgAKRYFw CyZI1ZdzfW0fuckK5hfjmN+nfySjjgN0iLWr04lKo401tTdMDXZK+HphjBgHtFupYlvNko sge7FY8MNNIVIKBKyi6pJltnxfgaDfy6xiLjYedJTrrljVz49QlDDiDNYvNSaX1hKE0uI2 aI2bsx8goHQ1uej6o/fKm2q1R1F0gcoyY7xsHyWRnk3iHEYn92KcJ4kFDmOinw== From: Alexander Leidinger To: "Poul-Henning Kamp" CC: Date: Tue, 10 Sep 2024 09:42:37 +0200 Message-ID: <191dae269c8.2805.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> In-Reply-To: <202409100630.48A6UEvY090552@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> <202409100630.48A6UEvY090552@critter.freebsd.dk> Subject: Re: It's not Rust, it's FreeBSD (and LLVM) 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="191dae26abb594b2805a276edc" 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:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Queue-Id: 4X2wfN3YZRz4G2Z This is a multi-part message in MIME format. --191dae26abb594b2805a276edc Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Hi, It was a serious question. As you say "no", I fail to understand what you propose. Please explain it in more detail, our cognitive picture of what is meant by your proposal does not seem to match. Or my picture of a Linux distro is not similar to what your picture of a Linux distro looks like. Bye, Alexander. -- Send from a mobile device, please forgive brevity and misspellings. Am 10. September 2024 08:31:45 schrieb "Poul-Henning Kamp" : > -------- > Alexander Leidinger writes: >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > >> So you are promoting a Linux-distro style model? > > No. > > But you already knew that. > > Please try to be less inflamatory. > > -- > 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. --191dae26abb594b2805a276edc Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi, 

It was a serious question. As you say "no", I fail to understand what y= ou propose. Please explain it in more detail, our cognitive picture of what= is meant by your proposal does not seem to match. Or my picture of a Linux= distro is not similar to what your picture of a Linux distro looks like.&n= bsp;

Bye, 
Alexander. 

--&n= bsp;
Send from a mobile device, please forgive brevi= ty and misspellings.

Am 10. September 2024 08:31:45 schrieb "Poul-Henning Kamp= " <phk@phk.freebsd.dk>:

--------
Alexander Leidinger writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156= )

So you are promoting a Linux-distro style model?

No.

But you already knew that.

Please try to be less inflamatory.

-- 
Poul-Henning Kamp       | UNIX since Zilog= Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP sinc= e RFC 956
FreeBSD committer       | BSD since 4.3-ta= hoe    
Never attribute to malice what can adequately be explaine= d by incompetence.

--191dae26abb594b2805a276edc-- From nobody Tue Sep 10 08:05:53 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 4X2x901kpRz5TyMJ for ; Tue, 10 Sep 2024 08:05:56 +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 4X2x8z6Pnxz4JsQ for ; Tue, 10 Sep 2024 08:05:55 +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 F123489284; Tue, 10 Sep 2024 08:05:53 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48A85rho091525; Tue, 10 Sep 2024 08:05:53 GMT (envelope-from phk) Message-Id: <202409100805.48A85rho091525@critter.freebsd.dk> To: Alexander Leidinger cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-reply-to: <191dae269c8.2805.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> From: "Poul-Henning Kamp" References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> <202409100630.48A6UEvY090552@critter.freebsd.dk> <191dae269c8.2805.fa4b1493b064008fe79f0f905b8e5741@Leidinger.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" Content-ID: <91523.1725955553.1@critter.freebsd.dk> Date: Tue, 10 Sep 2024 08:05:53 +0000 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] X-Rspamd-Queue-Id: 4X2x8z6Pnxz4JsQ -------- Alexander Leidinger writes: > It was a serious question. As you say "no", I fail to understand what you > propose. Please explain it in more detail, our cognitive picture of what is > meant by your proposal does not seem to match. Or my picture of a Linux > distro is not similar to what your picture of a Linux distro looks like. Linux is only a kernel, and that finnish dude does not care a hoot what executable PID=1 might or might not be or do. FreeBSD is a kernel /and/ a filesystem full of programs, scripts and other files, which cosplays as a complete, high quality and usable, UNIX system[1], on which you can run the programs you want/need/care for. Poul-Henning [1] Because somebody somewhere still defends the trademark. -- 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 Tue Sep 10 08:47:37 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 4X2y5L1Tr6z5V5yy for ; Tue, 10 Sep 2024 08:47:50 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2y5K6Z1Pz4Q6M; Tue, 10 Sep 2024 08:47:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725958069; 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: in-reply-to:in-reply-to:references:references; bh=KHeRwUTazRMsaRXOB8UwABprU0oOO76oAUyB5lQ6pyM=; b=QNoIBCuPUKDLHD4YBo8NPWQ+CwIScKRT5qrMwoDk6GmDjjdcEcTsdyF76Cv/26ktUlT6Md 7yxC5mv3MSrvzvVOOZtbgc+iMLxQoaD3MlfG+nI0ursBR0IZs26rL/cDQx25GXwvDavgBO 9ZhKOWIqJXDh4tf8jvvyLwlO4Y7GRSHoCMVmEfhvvOwgX85t6+7pQH8NqEaiR3EY30g1va e3LqSzkux5H3XOmeRO6yqEHi5gRwbpIbCDnlHsU977g9jJeccCi69enAAhnXaNjBMRjT3D kV4/TQ+TTv1R/lfz0D7pG+xsgjK+DKJoHrO2Duj20g4NgLipX2vGhJaFBJcEqA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725958069; a=rsa-sha256; cv=none; b=N5wSvKo+2sH1xP3oSmo+RXcm2dCzwHWWqDVhCXDqhfFKd9nL7fJNz7XyfsB90OY0uHweWC q9aBuXlkigB/NFpSZYrtPc3mcwdJ2qLym5fAMpkC2R4JX4VDcxqASQwq3n5vmLzSQb9WvM a53UnHDRLidikac8VQSz53ZTqIbwsjsfuQEb5HwltH/VBSedZnghaJGOy92DYfoFsEUGbT 67SaN7tTfcAbJa8y5OCZdIBTF5ph8jjLimYsYBzzIWpqRQCRM7kFmf8QmwQe2Um82ww0Ob V5e+G24lzbZek3YFiIgW5wAuq7n4itynSehNV8lBZy6eDaeHSBBjBkZL3Gmv9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725958069; 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: in-reply-to:in-reply-to:references:references; bh=KHeRwUTazRMsaRXOB8UwABprU0oOO76oAUyB5lQ6pyM=; b=sIJBuPLSiNnE3mTpx5e0U4qJD+TszEUScGM6jWrswOQA2/t5SV6b9Qiae2BHmgJJlvmCMK e25VSP2U+t+mkpCxp43kONi/5GskezJEq1Gw6AhBOOUVfXEQCvUR9TP4bptRTHa632WU9q dO4ypG8QOmoiYoPHFAVM1N+dFBGUxWnkefEMu5/FE0myTPzDeoh53bNUVDYdDqDPCL6j0J wweoR8vxOj+bUW8h/hjg+Z74nZHRyaPWGdXvoxLNyUwZSzhjTSaaDH7cQRbAmPl7loKzfD AXQEulAzqx8nCkUsU1Y5ySggu+E7HfOP3BJAV9uWj1bXLxZ+8YnS73O4r/NGqA== 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 4X2y5K60Y5zKgR; Tue, 10 Sep 2024 08:47:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 9327465B3; Tue, 10 Sep 2024 09:47:48 +0100 (BST) From: David Chisnall Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6E17609B-F3BE-4E6A-B88D-4B638A5172DD" 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 \(3776.700.51\)) Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Tue, 10 Sep 2024 09:47:37 +0100 In-Reply-To: Cc: Tomek CEDRO , Alexander Leidinger , Poul-Henning Kamp , freebsd-hackers@freebsd.org To: Rick Macklem References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_6E17609B-F3BE-4E6A-B88D-4B638A5172DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 9 Sep 2024, at 23:12, Rick Macklem wrote: >=20 > As for build times, I already find "make buildworld" takes way too = long > for me, so adding another ginormous compiler won't make much = difference. As with so many other things, this would be addressable if someone had = the time to do it. A single developer at Microsoft can edit the code = and build their own custom Windows VM image on a fairly low-end laptop, = in spite of the fact that most laptops don=E2=80=99t have enough disk = space for a full git clone of the Windows source tree. This is possible = because of a combination of two things: - git-vfs lets you have a local view of a remote git repo and fetches = files on demand as they=E2=80=99re accessed. Don=E2=80=99t run `grep` = over your source tree! - A build system that has cloud caching, so if you have changed one = file you=E2=80=99ll rebuild everything that depends on that file but = download the artefacts for everything else. It=E2=80=99s a bit sad that building Windows typically takes a developer = less time than building FreeBSD. The engineering effort involved in the = second part is huge though. It would probably need the Foundation to = pay someone to work on it for a year (I think this would be well worth = the investment, but that=E2=80=99s another discussion). I=E2=80=99m not = sure if bmake can be extended enough to support this (Buck2 looks to be = the most promising of the new build systems designed around this model = but it hasn=E2=80=99t yet had a stable release and comes with big =E2=80=98= do not use this yet=E2=80=99 warnings). This would also need = infrastructure to make sure each commit to head or a stable branch was = built in a trusted environment and pushed to the caches (and that random = developers=E2=80=99 builds did not). David --Apple-Mail=_6E17609B-F3BE-4E6A-B88D-4B638A5172DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 9 Sep 2024, = at 23:12, Rick Macklem <rick.macklem@gmail.com> = wrote:

As for build times, I already find "make = buildworld" takes way too long
for me, = so adding another ginormous compiler won't make much = difference.

As with so = many other things, this would be addressable if someone had the time to = do it.  A single developer at Microsoft can edit the code and build = their own custom Windows VM image on a fairly low-end laptop, in spite = of the fact that most laptops don=E2=80=99t have enough disk space for a = full git clone of the Windows source tree.  This is possible = because of a combination of two things:

 - = git-vfs lets you have a local view of a remote git repo and fetches = files on demand as they=E2=80=99re accessed.  Don=E2=80=99t run = `grep` over your source tree!
 - A build system that has = cloud caching, so if you have changed one file you=E2=80=99ll rebuild = everything that depends on that file but download the artefacts for = everything else.

It=E2=80=99s a bit sad that = building Windows typically takes a developer less time than building = FreeBSD.  The engineering effort involved in the second part is = huge though.  It would probably need the Foundation to pay someone = to work on it for a year (I think this would be well worth the = investment, but that=E2=80=99s another discussion).  I=E2=80=99m = not sure if bmake can be extended enough to support this (Buck2 looks to = be the most promising of the new build systems designed around this = model but it hasn=E2=80=99t yet had a stable release and comes with big = =E2=80=98do not use this yet=E2=80=99 warnings).  This would also = need infrastructure to make sure each commit to head or a stable branch = was built in a trusted environment and pushed to the caches (and that = random developers=E2=80=99 builds did = not).

David

= --Apple-Mail=_6E17609B-F3BE-4E6A-B88D-4B638A5172DD-- From nobody Tue Sep 10 09:05: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 4X2yV21hH7z5V7q0 for ; Tue, 10 Sep 2024 09:05:46 +0000 (UTC) (envelope-from olce@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X2yV20zGyz4T4W; Tue, 10 Sep 2024 09:05:46 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725959146; 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: in-reply-to:in-reply-to:references:references; bh=D2fSB6WOxSCJwL2KZHlylk2zqtoua9RCPuHiZm1hUB8=; b=KGr0sTkdDcAzWMM639BQj79s1UVx4IeKdExsjkHDfaZ9vNPNeQ/9rQt8QHK3t0bQJXn97l Uq/EVvb5DUo2gqpauSRJGHfSn12LXm9iMHzZEk1TRiqKtk5VWgIS3clzgJ+NIkHIYXxaSZ xqBUvn/bpHYPyC4rgSNz5cyawFLthnGi0KuYs5HA/jWD27MdB5MfrJ3y2li+csJgDf9VmC GaOS83Y8F46w9p4j4tcdAVhFnEQcHmGYGM6eLti83P9uShNdX4lwaPFY0s3FTDqcaOH19K vBpBzonZy/uXFNFsJuuc7dv9koVzAy2zgkww/MPpQgv0cDTfNcERZhLSAIjzVQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725959146; a=rsa-sha256; cv=none; b=lG8u4vu/EVMITcVVO4Pnfyvia0pegZMNgMLldu7i+71R+wl3OLR7LjkpfN9kG+4IoVS14J j+iYguwT2mnNvSy2OYO5kxhKpmF4FQuFxg+WhLApmbJMERA5w4pQ9/wEgY8sM/15DTFw56 T3FfjonT+fpG5d3QMBKbx7ihve2edPlk5bj8WFS2BtAMXhvGc1Dou46cch9i27pGjtD0vf iYJfVQuxQ3YM5apNN1HQSKgJ3vG7QMuLIbP4iwFA4zZv9KS4se3hMbTy7WAVyzQL2J0gPc WQ8Vmahqi9vT9fDC/HllGuRPpUjTC+KaY851PHeRwEASr2737wfzazKFiPjIuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725959146; 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: in-reply-to:in-reply-to:references:references; bh=D2fSB6WOxSCJwL2KZHlylk2zqtoua9RCPuHiZm1hUB8=; b=vk1hdsersdGqEXOreMrw01bD1Mu18mVZlILEZQ9KaKPxEAsDf0tMEEdlwq1yLtVOA96Gyu lTSEHs/YL1sPrTE9uDhTITWfb2ESl+3JkVSJCPGOeSzN3Y5xqyuA+ki6A/GXr4TgYHc5xf P9UMF9K7u2WKjir5lYZsV/KkTN0hAbcONrTUHXQ9SZR363ifiNTkxOgvBKeX9UQVYyai7v foF2WUKv3T5deoXWzoF6i7pF2Mw+2RKAHCZ04B0W58raxF8Pg5sQ523ZCQ4f0M2DQnLeqN mv+tyF7raSJxl2gpM4LMCxCPef1G8pdSZ4M7kgNtlPYeBxo3xRyZNNFJ73Hk0w== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X2yV14hrKzM1C; Tue, 10 Sep 2024 09:05:45 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Tue, 10 Sep 2024 11:05:38 +0200 Message-ID: <2372745.viN5riZIyJ@ravel> In-Reply-To: <202409091859.489Ixdia086264@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> <2611284.jQUcPV6jne@ravel> <202409091859.489Ixdia086264@critter.freebsd.dk> 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; boundary="nextPart2111829.mIT35NG9lc"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2111829.mIT35NG9lc Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Tue, 10 Sep 2024 11:05:38 +0200 Message-ID: <2372745.viN5riZIyJ@ravel> In-Reply-To: <202409091859.489Ixdia086264@critter.freebsd.dk> MIME-Version: 1.0 >> - A system that is easy to build and tweak in practice (for developers a= t the very least). > But what are the boundaries of this "system" of which you talk ? In the quote to which you responded, "system" simply designates FreeBSD, or= the "base system" to be even more explicit. I have not accurately described what this "system" should include, simply b= ecause I don't believe it can be delimited precisely ex abrupto in all gene= rality, as this depends on a lot of factors (amount of people; what they ar= e willing and able to work on; which upstreams project exist, can be used, = and are cooperative; technology evolutions; our collective project directio= n; etc.). That's why I gave some high-level view of what I think the project is and s= hould remain, and without which its nature would be considerably altered (I= 'd really like to hear other's points of view). And I contend that this vi= ew is more important than the precise detail of whether we have this or tha= t as "base". However, according to that view, I'm more or less coming to the conclusion = that FreeBSD should include the compiler. Which doesn't mean its code has = to *live* in the 'src' git repository, nor does it mean we cannot rebuild F= reeBSD without using pre-packaged binary or an earlier build from source. Before elaborating further, I'd like to expand a bit on my earlier list of = what FreeBSD is/should be. I had written this, in particular: > - A system that is self-sufficient, in the sense that, once installed on = a machine, one can set it up to do whatever one would like without having t= o boot something else (e.g., further software installations must be possibl= e over the network or from some USB key; so it must include some tools to s= upport the network, etc.). > - A system that is easy to build and tweak in practice (for developers at= the very least). I would add that "self-sufficient" also means that it can be easily built e= ntirely from source from itself and other commonly available systems. And = also, as developed at the end of my previous mail, that it is easy to obtai= n a workable view of all the source. =20 > I am more or less responsible for nearly two hundred computers > running FreeBSD right now. Only two of those have zero ports/packages > installed, one monitors my floor heating system, the other firewalls > some old crap. >=20 > To me "src+kernel" is just the foundations. >=20 > "A system" is what people build on top of the foundations. That's one possible view of a system, which is consumer-oriented rather tha= n developer or software-project-oriented. And I could return the question = to you: What's the limit of your "system"? One computer? Your network? A gr= oup of machines owned by someone? Or accomplishing some special task? Does = it include the network (routers, cables, etc.)? Does it include your ISP? = These different groupings can always be seen as foundations of other, bigge= r ones. Without more context, I don't see how this foundation/system disti= nction is going to be fruitful. By "system", or FreeBSD base, I mean code written, overseen and/or managed = by the people comprising the FreeBSD project, with the goals listed in my p= revious mail. I think that's the fundamental difference with ports: Ports = are... ports of software developed externally (which doesn't prevent some p= orters to contribute to upstream), not necessarily tied to FreeBSD's code, = not having the same quality insurance, nor the same coding policies or rele= ase schedules, and not collectively maintained by members of the project (a= t least, we do not promise that; of course, members are individually free t= o participate to whatever upstream project they like). There is no denying that for lots of (most?) tasks, being able to run these= ports is a pre-requisite, it's just that we are not responsible for their = development. What porters are responsible for is ensuring that we can buil= d and run these softwares on top of FreeBSD, with varying degrees of qualit= y (depending on the size of upstream, the number of porters for each projec= t, their level of engagement, etc.). This sometimes entails participating = to upstream development, but does not require setting, e.g., the full archi= tecture or roadmap of these projects. So, while we as a group are not living in an isolated island for sure, and,= e.g., should strive to maintain good working relationship with other proje= cts, we are not (and cannot) be the developers or maintainers of all useful= software. But we have to be so for software that we consider part of Free= BSD. Of course, code that is our own (provided, again, that it is needed to fulf= ill the high-level principles), i.e., for which there's no upstream and no = changes happen that aren't done or fully reviewed by project members (well,= this may be slightly idealistic, but hey...), belongs to 'src'. =46inally, we have the kind of middle-ground comprising upstream projects, = such as LLVM, which AFAICT are growing in number. As long as we consider t= hem to be needed in FreeBSD ("base") according to the high-level principles= , we are responsible for them functioning correctly and consistently with t= he rest of the system, even if we are not the primary developers. So, we a= lso "own" this code, albeit differently to code entirely in our hands. And= it should be maintained collectively. From commits and internal discussio= ns, I can identify more or less correctly the (small) group of FreeBSD peop= le working on LLVM in FreeBSD. If, for some reason, these people would sto= p working on it, we would have a problem, to which I expect the project as = a whole would respond with actively trying to find a solution (some would i= nvest more time to work on it, and/or we would try to find external people = who can, or we would switch to another toolchain, etc.). If, for some reas= on, let's say, Firefox would lose enough of its developers to have its viab= ility threatened, I don't expect us (as a project) to react to that as Fire= fox is not part of base. This doesn't exclude having a project response to= the difficulty of *porting* some software that we deem very important for = the ecosystem, occasionally or in a longer term fashion. This is only my view, but I have the feeling it is implicitly shared by man= y. I'm very interested in hearing whether it is more or less conform to re= ality and what people think about it as of now and for FreeBSD's future. That said, I also think this debate is mostly independent from the possibil= ity of building FreeBSD without having to rebuild a full compiler every tim= e. It is however relevant to the proposal of removing LLVM's code from 'sr= c', as this has bad consequences (according to the principles I listed) tha= t we probably can, and should, remedy with tooling, although, as the saying= goes, the daemon is in the details. Thanks and regards. =2D-=20 Olivier Certner --nextPart2111829.mIT35NG9lc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmbgC+IACgkQjKEwQJce Jiekqg//Qkpz81a9uLWWWXPPpwJ355VlZFitQ9Cz0OvY0qf3oOVjfsy1sgzW/S81 s8pUk2nDUHw/mPhLsNgp7NjI9NzDMs1m66IWJgfI/tzsfkoVflN6uJ5zrDCLdMKy NsT2h0fpzkZn4JGBksb9wsq84S3yaOTLcvGQlYj/c81pogHklYXbmdDX+5emYh8e SuhrV/9ANViKAIbYlg4KRmyL9ocWK2/I6i30otlrvZq8AxoqUDDJj2fKvYv/b6fR k8HYAYIninxIzYjod31H/vxAWcfIfU3FvVdj/ZE9ZNKApAAysi4lYRaVpRSmUyWT gVVJIVujseW7PvimJQc0+/X78JQwWWE+yOymIu/bVF8j/DUwBMDCzL5BcsbOFtxk /V9JKcgeDJSEmxBOx1x0mzn2YKtO+qU3gE3MtSu6RS8rZ5HtJP7Ap+GJVdKrs6f4 huy3gZLN5EHOR4PbSNiPhljwash3A8gRfZjw7SvXcBbHA1clVUAjgS8YgpNgifem EezJM0odNmpZchUlbJM7kzGtZo16XlujZWfgVlZOdbiwU4IUgGgkJKZgSgsNFflV ksicOndvgh2v4OP3xlxDXVvfD8+5JhWbiwl42OLTrflMRgkibZnGAMezz983HKWO ibBVoxM3rq5GEsX1jNNQYqjSJ8ZH36gLT/5RvxoFLtSiW+8gvuI= =OPAQ -----END PGP SIGNATURE----- --nextPart2111829.mIT35NG9lc-- From nobody Tue Sep 10 11:45:57 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 4X323032y3z5WK1c; Tue, 10 Sep 2024 11:46:04 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X32300fVhz4t3M; Tue, 10 Sep 2024 11:46:04 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2f75c0b78fbso6881101fa.1; Tue, 10 Sep 2024 04:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725968760; x=1726573560; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=WBkYJiNc2Nbz4EKv3F00lPQUtex0LWZeDlyUvZRnzLo=; b=eLmSAbnTTmxkV1BYRPvdL8ihc6tJk78BhA7fTqW43ezwpZsIQF8yfzUR5q57j1m8Hq PmxxvQ9gnR6I520lqhsrN/HSU7toU+Zrkr09eVhW3sckiEanD3a1G8lVWkEUG5LaPLwZ wK1imPmbTOizLqPsE9QlI8S0hIRosQxxfP9YksLVp0VdJxH209h/fTY9ExMaPIfXCBov eS+Gw18luw4/s7PvnFdRiHZgXRz5nBwYLsHkn+cF64Lil9lNdQl6SElKTmEejMRY5Up5 cYANsZPrZ33iOgqJJW5I0E2HFST3rkuuuGbnyovpEq9+T3A4WYJ4YMeBiFqrci9eHXRU CG9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725968760; x=1726573560; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WBkYJiNc2Nbz4EKv3F00lPQUtex0LWZeDlyUvZRnzLo=; b=ITJmRrJAdnu++v3tPrkUoF9eSjrR8477wAgf7CZy5FV/U8xju4VpffAXrUBWSGX+yT VzZfc183gY8ZAD95hgLRPkAOQBNymtS65AWbscY4aMakUqu/PS6zZG6fzZ6vuPxDQkeS /n6r2yOM2YXLnXQWAOOTJFcNYBmNMvwkhiJ9+bgg5p0h5apd8VD8greF+3omjn4AHLUP lT4jjbSxeNNiLu1Yiw+NkDiLETRMkCVF29yIyyLA7Z3JdXH/EGLBMtGH24KLqp0RMTfY 21I+iqlRe96t9GeP5HBzb/tILoBZiulOkcHijdSRSlsWNYJ6wP0SEDnclIJZLrceXYpZ Mt2w== X-Forwarded-Encrypted: i=1; AJvYcCXABsXwFqB9228+lHx1x/NRaTNdGIhiAtvPEsG+ym0Qe7PTj6I1BmoO7P5N26nDz3+bC9sqLFi+imd0r48=@freebsd.org, AJvYcCXN/5rVKkRrdRC8xfQ4EvjUmuH9gjlcBFLDaK+BC2oxZ1Xyq8PU1B5rJ+LiV2I/2nMA7y5jLuSxU3oIYoTgpkI=@freebsd.org X-Gm-Message-State: AOJu0YyG7smioDa/4fInc26m+OFrnDfxv8+P0t+VgXwsk5SopzV5x55O zy2qQI/hEhuqgYkObWZ5LKpAV2NILwU3IPybXGSvkDtSoJ69xTFm X-Google-Smtp-Source: AGHT+IGT6G/PcabgIwPjGt4XifTh3HHZgQq37Ig9miee4qJLIrWgIe6f17r20iP9+oq+FYhtHbvv5A== X-Received: by 2002:a05:651c:1a0c:b0:2f7:6653:8046 with SMTP id 38308e7fff4ca-2f766538106mr45293161fa.25.1725968759775; Tue, 10 Sep 2024 04:45:59 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f75c07c539sm11600861fa.88.2024.09.10.04.45.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 04:45:59 -0700 (PDT) Date: Tue, 10 Sep 2024 14:45:57 +0300 From: Vadim Goncharov To: "Poul-Henning Kamp" , tcpdump-workers@lists.tcpdump.org Cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240910144557.4d95052a@nuclight.lan> In-Reply-To: <202409100638.48A6cor2090591@critter.freebsd.dk> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-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] X-Rspamd-Queue-Id: 4X32300fVhz4t3M On Tue, 10 Sep 2024 06:38:50 +0000 "Poul-Henning Kamp" wrote: > -------- > Vadim Goncharov writes: > > > I've put a sketch of design to https://github.com/nuclight/bpf64 > > with files: > > Counter proposal: > > 1. Define the Lua execution environment in the kernel. > > 2. Add syscall to submit a precompiled Lua program (as bytecode) Anyone who thinks "any generic bytecode" misses the main point, see below. > 3. Add syscall to execute submitted Lua program > > And yes: I'm being 100% serious. Well, preparing spec/letter in a rush I probably forgot the main reason for BPF (and successors) to exist thinking it's obviuos: safety. Let's restate: *BPF* allows UNTRUSTED user code to be executed SAFELY in kernel. It's easy for your Lua code (or whatever) code to hang kernel by infinite loop. Or crash it by access on arbitrary pointer. That's why original BPF has no backward jumps and memory access, and eBPF's nightmare verifier walks all code paths and check pointers. And that's why DTrace also has it's own VM and bytecode in kernel (see https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-924.pdf Chapter 7) Your "counter proposal" was essentially available for all these decades in form "oh, just write KLD in C instead of that limited tcpdump". > If we are going to reinvent "Channel Programs" 67 years after IBM > came up with them for their 709 vacuum tube computer, at the very > least we should use a sensible language syntax. Don't know what that is, quick googling shows something modern on AMQP. But Lua at least doesn't have *sensible* syntax, Perl or Tcl much better. And I'm surprised why Fort, being available in loader, wasn't ported for all these years. -- WBR, @nuclight From nobody Tue Sep 10 11:51:08 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 4X329L5v4rz5WKPk; Tue, 10 Sep 2024 11:51:34 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X329L2Jp1z3xp0; Tue, 10 Sep 2024 11:51:34 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 48ABpNLb021367; Tue, 10 Sep 2024 12:51:23 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from smtpclient.apple ([89.248.30.154]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 48ABpI43065562; Tue, 10 Sep 2024 12:51:18 +0100 (BST) (envelope-from rb@gid.co.uk) 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 \(3776.700.51\)) Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative From: Bob Bishop In-Reply-To: <202409100638.48A6cor2090591@critter.freebsd.dk> Date: Tue, 10 Sep 2024 12:51:08 +0100 Cc: Vadim Goncharov , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , tcpdump-workers@lists.tcpdump.org, "tech-net@netbsd.org" , Alexander Nasonov Content-Transfer-Encoding: quoted-printable Message-Id: <2F9BBCAE-C0EA-43E7-B371-AE3FF733E72E@gid.co.uk> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3776.700.51) 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:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4X329L2Jp1z3xp0 Hi, > On 10 Sep 2024, at 07:38, Poul-Henning Kamp = wrote: >=20 > -------- > Vadim Goncharov writes: >=20 >> I've put a sketch of design to https://github.com/nuclight/bpf64 with = files: >=20 > Counter proposal: >=20 > 1. Define the Lua execution environment in the kernel. >=20 > 2. Add syscall to submit a precompiled Lua program (as bytecode) >=20 > 3. Add syscall to execute submitted Lua program >=20 > And yes: I'm being 100% serious. >=20 > If we are going to reinvent "Channel Programs" 67 years after IBM > came up with them for their 709 vacuum tube computer, at the very > least we should use a sensible language syntax. +1 We did something like this at $work years ago with FORTH, to do weird = things in a driver. > Poul-Henning >=20 > --=20 > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe =20 > Never attribute to malice what can adequately be explained by = incompetence. >=20 -- Bob Bishop rb@gid.co.uk From nobody Tue Sep 10 12:24: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 4X32ty5v0Yz5WPS0; Tue, 10 Sep 2024 12:24:10 +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 4X32ty309fz442f; Tue, 10 Sep 2024 12:24:10 +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 0A68489284; Tue, 10 Sep 2024 12:24:08 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48ACO7oj094058; Tue, 10 Sep 2024 12:24:07 GMT (envelope-from phk) Message-Id: <202409101224.48ACO7oj094058@critter.freebsd.dk> To: Vadim Goncharov cc: tcpdump-workers@lists.tcpdump.org, freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative In-reply-to: <20240910144557.4d95052a@nuclight.lan> From: "Poul-Henning Kamp" References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> 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-ID: <94056.1725971047.1@critter.freebsd.dk> Content-Transfer-Encoding: 8bit Date: Tue, 10 Sep 2024 12:24:07 +0000 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] X-Rspamd-Queue-Id: 4X32ty309fz442f -------- Vadim Goncharov writes: > It's easy for your Lua code (or whatever) code to hang kernel by > infinite loop. Or crash it by access on arbitrary pointer. Lua has pointers now ? > Your "counter proposal" was essentially available for all these decades > in form "oh, just write KLD in C instead of that limited tcpdump". You're yelling at the guy who implemented a (very fast!) firewall where the rules were compiled to C code in a KLD. > > If we are going to reinvent "Channel Programs" 67 years after IBM > > came up with them for their 709 vacuum tube computer, at the very > > least we should use a sensible language syntax. > > Don't know what that is, quick googling […] Well, you probably should do some more research then, because unawareness of history is /the/ major cause of pointlessly repeating mistakes. -- 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 Tue Sep 10 12:59: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 4X33gR2X2Yz5WT26; Tue, 10 Sep 2024 12:59:15 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X33gR1bPhz487P; Tue, 10 Sep 2024 12:59:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725973155; 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: in-reply-to:in-reply-to:references:references; bh=52WhLO+OOHHelT2Ulj2UpeO8k0p2xywwOt9PKUFdeUE=; b=Z9leBlhmFM1wChnwg8J+UYDNYI79vTXSLsfTgdJJEXM21aXDvdIedF4jMih1Sc8fZNkLAO jhV7+IsLEg0wk00SVmpRYo4hj5EjlJt8MXXRzg7G4fzPq73nCIeqs5YYYKkh+igF1vZi/5 L804Mq/G8taMah23Et0VIZ8OH9ZiIJT4EkD2enMxWmakB8Yl60PcQHeG5O0KoM6lHVnS3L U36iIZ578yTmEDfaK2R3+FvYTRsHN7NyvqH1Uo7pJ5NRKtlu+2jBWsSiHE4UB/Xrv5JGuH c/zGstZ5ZbIly10xanfW2yAN0X3jA47l/ilTzoA0xMqMxh1uhA9p3VyLkt9BQA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725973155; a=rsa-sha256; cv=none; b=EPHvqxYtQCoIHtuF6ELe6d98c6hcy6ZTAffa6LfPF4ZEMaKjVZMM7FS/yaDtPF0U/9Wj/T zEnYrlAs0rsdrRQE4oxgxcknTcqFUe5V893KkgDF2Iid22HDVvC6nn/41n9u6qcr/gix1V 7C5uEzfDERYUr8ymKHvFFsvCqBKdsd6nRJftshmxD5eFcn25dBEW3EJPey7ZxnU9KZm5us 1j1z3rGA2LsBNm8OZtraxZ+/nOd0LeGbp30vj/UM2i/W8mOd/6lEBh8Y/V7UvNh+MxdmLT PsMGCSg8rcMkl5a9uxP+xXZCEomHbYR871vc/onLG8rGWUOz10WyaE5/U8+/mw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725973155; 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: in-reply-to:in-reply-to:references:references; bh=52WhLO+OOHHelT2Ulj2UpeO8k0p2xywwOt9PKUFdeUE=; b=XPXxoJsZW7hScfl6faNRdizk8iNIMDcmwRx20lDNX2XGUlHp7BNFeCsT5OyHfcG+EGsbs3 9LUlhAqs+VDtS85Akd351XwffW8FkkfXjezE+XD9L+PhNGKOjjwldUvvlUMpK4Omz3kRWP PRl9pCTfsKazovqSwBGfUHzjTJaKQonVzi9G9bG5/hK8J1ezTaCzYdXHcWdLEXI/KvpwNy SAe0fogKCY8Q6ZUzFQ0Thkx8I4LJ7q81fFqJcO9mNW90aerrwz57g2K7MtrGRSQQ5be2Uk 9/ntKjaddeVAB1YIJNtDQRrAdtUHdQyBqDQCnCMNQEw9FeNO63xxLUOCJfOC4A== 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 4X33gR10JPzRMq; Tue, 10 Sep 2024 12:59:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id A6A0065B5; Tue, 10 Sep 2024 13:59:13 +0100 (BST) From: David Chisnall Message-Id: <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_568E13D8-1F5C-410F-B911-1402B36B059B" 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 \(3776.700.51\)) Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Date: Tue, 10 Sep 2024 13:59:02 +0100 In-Reply-To: <20240910144557.4d95052a@nuclight.lan> Cc: Poul-Henning Kamp , tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov To: Vadim Goncharov References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_568E13D8-1F5C-410F-B911-1402B36B059B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 10 Sep 2024, at 12:45, Vadim Goncharov = wrote: >=20 > It's easy for your Lua code (or whatever) code to hang kernel by > infinite loop. Or crash it by access on arbitrary pointer. That's why > original BPF has no backward jumps and memory access, and eBPF's > nightmare verifier walks all code paths and check pointers. I=E2=80=99m not convinced by the second: Lua has a GC=E2=80=99d heap, = you=E2=80=99d need to expose FFI things to it that did unsafe things, = and that=E2=80=99s equally a problem for eBPF. The first is not a problem. The Lua interpreter has a bytecode limit. = You can define a bounded number of bytecodes that it will execute. The = problem comes from the standard library. Things like string.gmatch can = have high-order polynomial complexity and so it=E2=80=99s possible for a = Lua program that executes a small number of bytecodes to create a string = that takes a vast amount of time to match on. Again, this is also a = problem for eBPF if you expose a similar function, the solution is to = not expose functions with large data-dependent runtimes to untrusted = script. More generally, there are a lot of problems with interpreting or JITing = untrusted code in the kernel in *any* runtime. Speculative execution = makes it easy to use these as primitives to leak kernel secrets, either = via timing of the programs themselves, using the JIT to generate = gadgets, or by leaking data via cache priming. Both eBPF and Lua have these problems. The thing I would like to see for our current use of semi-trusted Lua in = the kernel (ZFS channel programs) is a way of exposing them (under = /dev/something) as file descriptors and modifying the ioctls that run = them to take a file descriptor argument. I would like to separate the = two operations: - Load a channel program. - Run a channel program. In the post-Spectre world, the former remains a privileged operation. = Even though Linux pretends it isn=E2=80=99t, allowing arbitrary (even = arbitrary constrained) code to run in the kernel=E2=80=99s address space = is a problem. Invoking such code; however, should follow the same rules = as everything else. A trusted entity should be able to load a pile of = Lua / eBPF / BPF64 / whatever programs into the kernel and then set up = permissions so that sandboxed programs (and jails) can use a defined = subset of them. David --Apple-Mail=_568E13D8-1F5C-410F-B911-1402B36B059B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 10 Sep = 2024, at 12:45, Vadim Goncharov <vadimnuclight@gmail.com> = wrote:

It's easy for your Lua code (or whatever) = code to hang kernel by
infinite loop. Or crash it by access on arbitrary pointer. = That's why
original BPF has no backward jumps and memory access, and = eBPF's
nightmare verifier walks all code paths and check = pointers.

I=E2=80=99m not = convinced by the second: Lua has a GC=E2=80=99d heap, you=E2=80=99d need = to expose FFI things to it that did unsafe things, and that=E2=80=99s = equally a problem for eBPF.

The first is not a = problem.  The Lua interpreter has a bytecode limit.  You can = define a bounded number of bytecodes that it will execute.  The = problem comes from the standard library.  Things like string.gmatch = can have high-order polynomial complexity and so it=E2=80=99s possible = for a Lua program that executes a small number of bytecodes to create a = string that takes a vast amount of time to match on.  Again, this = is also a problem for eBPF if you expose a similar function, the = solution is to not expose functions with large data-dependent runtimes = to untrusted script.

More generally, there are = a lot of problems with interpreting or JITing untrusted code in the = kernel in *any* runtime.  Speculative execution makes it easy to = use these as primitives to leak kernel secrets, either via timing of the = programs themselves, using the JIT to generate gadgets, or by leaking = data via cache priming.

Both eBPF and Lua have = these problems.

The thing I would like to see = for our current use of semi-trusted Lua in the kernel (ZFS channel = programs) is a way of exposing them (under /dev/something) as file = descriptors and modifying the ioctls that run them to take a file = descriptor argument.  I would like to separate the two = operations:

 - Load a channel = program.
 - Run a channel = program.

In the post-Spectre world, the former = remains a privileged operation.  Even though Linux pretends it = isn=E2=80=99t, allowing arbitrary (even arbitrary constrained) code to = run in the kernel=E2=80=99s address space is a problem.  Invoking = such code; however, should follow the same rules as everything else. =  A trusted entity should be able to load a pile of Lua / eBPF / = BPF64 / whatever programs into the kernel and then set up permissions so = that sandboxed programs (and jails) can use a defined subset of = them.

David

= --Apple-Mail=_568E13D8-1F5C-410F-B911-1402B36B059B-- From nobody Tue Sep 10 13:09:15 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 4X33v465Hpz5WTtq; Tue, 10 Sep 2024 13:09:20 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X33v44LG2z4Dl6; Tue, 10 Sep 2024 13:09:20 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-5365cc68efaso3536809e87.1; Tue, 10 Sep 2024 06:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725973759; x=1726578559; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=RkKU7OzzhXolcRcGkGudy213qu3KY/KqHoqUnGVQTPQ=; b=TjIKSiuTIbl6+zsrcY5WHuTne3sayhEsaq05ctDTCdwWOYxKF6lAy0HYjJjFX2tnpK NOluUSyHTxtCEGgxuaf9rIuaUSlkgaRmV7KHAVuYiziMa3eO8Gb4SDPAu2S55CTrF0kH uKVqfwSuHVNzK8Q99JfhPa7dao4cMpzcj2J6lCITJ3h4u7TDASUsyeDmZUDF7tghluZr B0IICSZd0FeYH5ECePlPRK4dMpuCA/AT7nHOzXsBUVryealF17IlnaJK+XmHxCice0aQ RUK+5BjVLR0WDYerZMLnj0d4vjb1ojcfEdL38KFldCgyVHzh7l0JmafqYGCkFvFFmrJL wx4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725973759; x=1726578559; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RkKU7OzzhXolcRcGkGudy213qu3KY/KqHoqUnGVQTPQ=; b=R8jy9qfeNQDxpDKAx52YW0XlvljEN4VblyOX3P32nv2sHS8j2gClezwdpryv3L6y5I KZuBH2vniCjn0R5c6ZO9fRwVJAJyhogJxwE0KnjK3u9UNmDeuU8y2pFoBjmLOuJ/e2G6 Lz82S4Mba9TgMRweggBOGN6lZu4hQrjxm3MdUTyQkJG/XqypOsdqKDddBAZyiZiwk3mj XN8XysnFkwPTd/DUAByG1KcNUvm+EYUYxEEHdhqhcNzvud8FPm8iNUm7zzT5mbnjsYtC HKhT4fdtuZwjPN0ML98Id9m+9l1IhL0KytgeJcH2QA9ZSJOl5QfaePFnTjwsqS86joGy b/7g== X-Forwarded-Encrypted: i=1; AJvYcCVezgU/L3uEP2R0J3jz+xMcVCeVg0GWQv1GO6nTm2h5lc7SUMB0cP7DGQK8Oh6A9Z/1glVwcGPCf4reNUmcszQ=@freebsd.org, AJvYcCXrCqD/Cda2K/UO+KmO4HKjVu/0UM0o93RVDlvwND7ww9aoYsIxZwVRemcJYkC3SdISd6uWfvwWb3qnv0Q=@freebsd.org X-Gm-Message-State: AOJu0YzhHOXgk5vkBqIvh3Jq8jKMhIe5mozxg4Im/YoL6dgLtC8kEM05 3bF+6KL3zMyxsV1Nl9MycWzFMJT/YNC2j5gVib4AENlNxKRiydzE X-Google-Smtp-Source: AGHT+IHCZSlqVTBTlUDxjG0SinNhtLNa+Ng/lDo/GxAOb0zVvoslx8qbRLU0qLFsfO+55WpvVTXp2Q== X-Received: by 2002:a05:6512:15a7:b0:535:6992:f2c3 with SMTP id 2adb3069b0e04-536587f5ce0mr10817602e87.41.1725973758289; Tue, 10 Sep 2024 06:09:18 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5365f90c306sm1153853e87.245.2024.09.10.06.09.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 06:09:18 -0700 (PDT) Date: Tue, 10 Sep 2024 16:09:15 +0300 From: Vadim Goncharov To: "Poul-Henning Kamp" Cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240910160915.55ff579b@nuclight.lan> In-Reply-To: <202409101224.48ACO7oj094058@critter.freebsd.dk> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <202409101224.48ACO7oj094058@critter.freebsd.dk> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-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] X-Rspamd-Queue-Id: 4X33v44LG2z4Dl6 On Tue, 10 Sep 2024 12:24:07 +0000 "Poul-Henning Kamp" wrote: > -------- > Vadim Goncharov writes: >=20 > > It's easy for your Lua code (or whatever) code to hang kernel by > > infinite loop. Or crash it by access on arbitrary pointer. =20 >=20 > Lua has pointers now ? It's implementation has. Do you have mathematical verifier of such loaded bytecode proving it's C interpreter will have no side effects during it's running? > > Your "counter proposal" was essentially available for all these > > decades in form "oh, just write KLD in C instead of that limited > > tcpdump". =20 >=20 > You're yelling at the guy who implemented a (very fast!) firewall > where the rules were compiled to C code in a KLD. That's exactly the way which must be avoided. See 5.2 of https://www.usenix.org/legacy/events/bsdcon02/full_papers/lidl/lidl.pdf > > > If we are going to reinvent "Channel Programs" 67 years after IBM > > > came up with them for their 709 vacuum tube computer, at the very > > > least we should use a sensible language syntax. =20 > > > > Don't know what that is, quick googling [=E2=80=A6] =20 >=20 > Well, you probably should do some more research then, because > unawareness of history is /the/ major cause of pointlessly repeating > mistakes. You're either trolling or completely misunderstand the problem domain.=20 <> (c) https://www.ece.ucdavis.edu/~vojin/CLASSES/EEC272/S2005/Papers/IBM-A= rchitecture-Bashe_sep81.pdf This has nothing to do with BPF at all. Go and read original papers on kernel filters and why they're *such* restricted, e.g. Van Jacobson's paper on BPF/tcpdump, aforementitioned paper on BSD/OS's IPFW (esp. section 5.7 on loops), etc. --=20 WBR, @nuclight From nobody Tue Sep 10 13:35: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 4X34T438Tyz5WXxb; Tue, 10 Sep 2024 13:35:20 +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 4X34T418FPz4Jjs; Tue, 10 Sep 2024 13:35:19 +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 1B79B89284; Tue, 10 Sep 2024 13:35:12 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48ADZBhq094507; Tue, 10 Sep 2024 13:35:11 GMT (envelope-from phk) Message-Id: <202409101335.48ADZBhq094507@critter.freebsd.dk> To: David Chisnall cc: Vadim Goncharov , tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative In-reply-to: <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> From: "Poul-Henning Kamp" References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@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" Content-ID: <94505.1725975311.1@critter.freebsd.dk> Date: Tue, 10 Sep 2024 13:35:11 +0000 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] X-Rspamd-Queue-Id: 4X34T418FPz4Jjs David Chisnall writes: > The thing I would like to see for our current use of semi-trusted Lua in > the kernel (ZFS channel programs) is a way of exposing them (under > /dev/something) as file descriptors and modifying the ioctls that run > them to take a file descriptor argument. I would like to separate the > two operations: > > - Load a channel program. > - Run a channel program. > > In the post-Spectre world, the former remains a privileged operation. > Even though Linux pretends it isn't, allowing arbitrary (even > arbitrary constrained) code to run in the kernel's address space > is a problem. Invoking such code; however, should follow the same rules > as everything else. A trusted entity should be able to load a pile of > Lua / eBPF / BPF64 / whatever programs into the kernel and then set up > permissions so that sandboxed programs (and jails) can use a defined > subset of them. That would be a great way to do it. -- 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 Tue Sep 10 13:44:47 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 4X34h56SKpz5WYnp; Tue, 10 Sep 2024 13:44:53 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X34h54cG5z4Lj6; Tue, 10 Sep 2024 13:44:53 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5344ab30508so6086811e87.0; Tue, 10 Sep 2024 06:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725975892; x=1726580692; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=K+m/jXapYzzXBOdJT5EyQSuIHmGF1QSU2be+dgGMMww=; b=T6GVpJhbQSx6/URyN6PPzxi7ypP0zKtbikTBd0H5C9buGHazTYPowuBPGKO/hFk4XP RmK/tIa7ObKa8Ohx4JGDYXaa+Jz1Y5aoIRWI0rl6eFtvhsQYVVpxYIoA3Iwe98Ut0cgL /5QYuXkpwOJwWPr9WeedzPTRZyY06sISA0YgUrKv4jvxdYHXxkldsD7nv6HKARCGn5Zn s6L5/t8AwBJZRgrJMW+xVatWop+XA9RqEE3VSa1hJN1+3Hj1YmFttByuqAD2w8ZEbzhK aBdqAzDR0msKUEkRr3jGk/JXcJ9rV0Fr2ak77Ze2Lzxz68vg5VGO4fJMGOA8iMBMBu8n jIPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725975892; x=1726580692; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K+m/jXapYzzXBOdJT5EyQSuIHmGF1QSU2be+dgGMMww=; b=eRnu3sc67XvxB61xInDithI9dlO0j2b92NPLWxkctx8zAPd6xp4RJxDLRVip3RxfP6 uQTKK/PSTJmL2XGULIRODsPb+sI48Ts+O/vwG9VtzwdELuEX81LDBbECeaJUTQ52fABo uq+KdjibZh8/FbVGQMBo87Xqh9cGNf/7bjvnphJPYRCmc8+FH19j9bwM2oyQtNm6Hfff GxtFRAB8nG291wyN/KTUG0EaesxBaK9QLZB8eUbfOKyyjgQhWuCpTjQvqDiDGvm8drP9 GjnC+SL8Cx1lE2ifxIPuTJh9OxkhjXMhWLFcxw86nHIC0RqdFXIPErRd+zuKVNx1Orda 47cg== X-Forwarded-Encrypted: i=1; AJvYcCUh5bIP+W0j+lThDKRqnVFX9x8FIb07Panuy+C3XdokX/T8X2q/mJq7DKNphg2I9rIqiEIPGYGEDPhOnEU=@freebsd.org, AJvYcCUy8S3ov+JBxkFjigWHd305wMfVfsuPznmYyOkLh9+PdLwyTSH2OU/BeYpsyoPCYKs3b1w5JnexmYI+TuE5TMDK@freebsd.org, AJvYcCVvzCBXJs5H8FmmzA8hVsotBtIkuFrRJ1aAIyL3COpv40nNt18rEFLXz+gk7C25VunqVD2KncbxTXpy2AA=@freebsd.org X-Gm-Message-State: AOJu0YzZlyIwa40T9zfgx94clsP5S/v0mkdPfW2ce3f2u95Rf6xMdVxO p3s/0aKZVSJMnEx21v4p+YmUiLYYYJ1iheTUU9Fkmx8t6gX+DdTM4C522jRD X-Google-Smtp-Source: AGHT+IF1I+H9IpV3UVoCM8UL/JKt5Oi6jnQ8OUUoZY6/7NCvz13NY+Q89FJXXtqaMIAOsUoRddtaMw== X-Received: by 2002:a05:6512:3e0e:b0:536:628d:20e with SMTP id 2adb3069b0e04-5366bb48633mr1099505e87.29.1725975891203; Tue, 10 Sep 2024 06:44:51 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5365f912ee5sm1181543e87.301.2024.09.10.06.44.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 06:44:50 -0700 (PDT) Date: Tue, 10 Sep 2024 16:44:47 +0300 From: Vadim Goncharov To: David Chisnall Cc: Poul-Henning Kamp , tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240910164447.30039291@nuclight.lan> In-Reply-To: <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-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] X-Rspamd-Queue-Id: 4X34h54cG5z4Lj6 On Tue, 10 Sep 2024 13:59:02 +0100 David Chisnall wrote: > On 10 Sep 2024, at 12:45, Vadim Goncharov > wrote: > >=20 > > It's easy for your Lua code (or whatever) code to hang kernel by > > infinite loop. Or crash it by access on arbitrary pointer. That's > > why original BPF has no backward jumps and memory access, and eBPF's > > nightmare verifier walks all code paths and check pointers. =20 >=20 > I=E2=80=99m not convinced by the second: Lua has a GC=E2=80=99d heap, you= =E2=80=99d need to > expose FFI things to it that did unsafe things, and that=E2=80=99s equall= y a > problem for eBPF. Not quite. For eBPF (and BPF64) there must be not just FFI but special wrappers or even written from scratch functions keeping in mind they work for restricted environment. Lua, of course, does not have such thing - it will be needed to reimplement standard library. > The first is not a problem. The Lua interpreter has a bytecode > limit. You can define a bounded number of bytecodes that it will > execute. The problem comes from the standard library. Things like > string.gmatch can have high-order polynomial complexity and so it=E2=80= =99s > possible for a Lua program that executes a small number of bytecodes > to create a string that takes a vast amount of time to match on. > Again, this is also a problem for eBPF if you expose a similar > function, the solution is to not expose functions with large > data-dependent runtimes to untrusted script. In BPF64 some safety belts are supposed - e.g. on CALL/RET time is checked, and if exceeded, program is marked unsafe and disabled. > More generally, there are a lot of problems with interpreting or > JITing untrusted code in the kernel in *any* runtime. Speculative > execution makes it easy to use these as primitives to leak kernel > secrets, either via timing of the programs themselves, using the JIT > to generate gadgets, or by leaking data via cache priming. >=20 > Both eBPF and Lua have these problems. > [...] > - Run a channel program. >=20 > In the post-Spectre world, the former remains a privileged operation. > Even though Linux pretends it isn=E2=80=99t, allowing arbitrary (even > arbitrary constrained) code to run in the kernel=E2=80=99s address space = is a > problem. Invoking such code; however, should follow the same rules > as everything else. A trusted entity should be able to load a pile > of Lua / eBPF / BPF64 / whatever programs into the kernel and then > set up permissions so that sandboxed programs (and jails) can use a > defined subset of them. I am not an experience assembler user and don't understand how Spectre works - that's why I've written RFC letter even before spec finished - but isn't that (Spectre) an x86-specific thing? BPF64 has more registers and primarily target RISC architectures if we're speaking of JIT. For BPF64 I've did separate stack as register window exactly to mitigate ROP and it's gadgets. And BPF64 is meant as backwards-compatible extension of existing BPF, that is, it has bytecode interpreter (for(;;) switch/case) as primary form and JIT only then - thus e.g. JIT can be disabled for non-root users in case of doubt. eBPF can't do this - it always exists in native machine code form at execution, bytecode is only for verifier stage. ^^ that's fallback if you say "safe JIT is impossible", but may be you have advices on how to do architecture to still do it safe? As BPF64 looks doable improvement for us in much lower resource investment than even to *porting* eBPF to *BSD. > The thing I would like to see for our current use of semi-trusted Lua > in the kernel (ZFS channel programs) is a way of exposing them (under > /dev/something) as file descriptors and modifying the ioctls that run > them to take a file descriptor argument. I would like to separate > the two operations: >=20 > - Load a channel program. Didn't hear about, looked at the zfs-program(8) and see no reason why these are called "channel" programs (just to please some old farts?) and even reason for them to run in kernel, for same userland-utilities-achi= evable things, seems doubtful. --=20 WBR, @nuclight From nobody Tue Sep 10 14:29: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 4X35gT2FPTz5VtlY; Tue, 10 Sep 2024 14:29:25 +0000 (UTC) (envelope-from jhibbits@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X35gT1Kzyz4S4b; Tue, 10 Sep 2024 14:29:25 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725978565; 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=s3GEIp6Pm27U5X0WQLnTgbvAeltQZEvg1PejEPUlfp4=; b=cvzKdpS4y/XM6wOWOoHbMXAfIppBsl9X8BwqQ7AAqXW9pzvE+Mh62dMSLS4zmRQFjqS7TC rJeGxdzDesn8wxJ9WriGDftWQ3/eScH7FuaOtfSyvY1CstweHpu+twpgaBSK+C2z+STb9j PYhDr9+p6ZfHxcw1iCHoGrUkXddxcBjtL62/ZBH7R8ATRpSyB7gHuTcWFYy1IW7JnDM/4d fidKR9umuA/kYDU126QBHKYfHg/n+JXg/G+FFasoY9dHwcGFlcIDmdUH5hJCcFl/ZAMMUM U4OhAeef162Db9/sXDHWiPK9DS7thAOdoDc1VzdvwOKa7U9/OYJ7bHka09AbvQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725978565; a=rsa-sha256; cv=none; b=Fq/+YRBojozG5185gbYrB4r+d2lR0/MQva7scfwLKpaTniOKBoEEozKQosyfIe3k9/fiOg iUfKTPTiC2gc4XKgS6rZcl8777Or5eSd2ogz8WOQWDz/mW466GvmI9LRqJ9v8AQK3VYAgL JameTunSlRMuBT9YYhBa1Mc2Pkp4M3JYtDWJgC05N3hqiPdgwy1wsx8AidE3a8vxjuaM0g 00dUPQmsCdmYI6rrJeRNEFOjFP58tIayCoAu4H/T7nqk+LZVLhj3X0Lq8UcGzJBZC0agCT wLRRp7/KieJOK+CnoTX0pkuGsn2cIv+WlLFbinc+SISv/zfMczKicT1QL28CDw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725978565; 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=s3GEIp6Pm27U5X0WQLnTgbvAeltQZEvg1PejEPUlfp4=; b=Ra7qVGw7JRrPb3O11lG8B9ZCMgsWRLRnu+hxI9LzTpoMvXWrXHoVaNHjaoKCogDwhCeeox EkKSXQXELolYnR7SnAAhu1hA0ynYmsNTaxFTiDUHlJpmcPsr5LJZiFVloRfW1IOzlRaBqE 82PXpn0ggAO8bPlZF8AY9f+p3qHYIE/W173ykWFViTdNQu8Ayh+QIQHWW20y+ds80B1i/P UsOkNKeHV4pyrsxNNh9U7T0IjzD7otF8lke3h6Hoqt1QDJLr5XQNXCYuC57hig7zUcDwH8 LqzrUhQbcfzifoP/XyKQOD6VLnLplPUz9DBuYk8klPkqbBafjnlfGogNDPE5hg== Received: from ralga.knownspace (ip-163-182-7-56.dynamic.fuse.net [163.182.7.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhibbits) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X35gS5DtpzSJp; Tue, 10 Sep 2024 14:29:24 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Tue, 10 Sep 2024 10:29:19 -0400 From: Justin Hibbits To: David Chisnall Cc: Vadim Goncharov , Poul-Henning Kamp , tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240910102919.7d8927d0@ralga.knownspace> In-Reply-To: <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; powerpc64le-unknown-linux-gnu) 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 On Tue, 10 Sep 2024 13:59:02 +0100 David Chisnall wrote: > On 10 Sep 2024, at 12:45, Vadim Goncharov > wrote: > >=20 > > It's easy for your Lua code (or whatever) code to hang kernel by > > infinite loop. Or crash it by access on arbitrary pointer. That's > > why original BPF has no backward jumps and memory access, and eBPF's > > nightmare verifier walks all code paths and check pointers. =20 >=20 > I=E2=80=99m not convinced by the second: Lua has a GC=E2=80=99d heap, you= =E2=80=99d need to > expose FFI things to it that did unsafe things, and that=E2=80=99s equall= y a > problem for eBPF. >=20 > The first is not a problem. The Lua interpreter has a bytecode > limit. You can define a bounded number of bytecodes that it will > execute. The problem comes from the standard library. Things like > string.gmatch can have high-order polynomial complexity and so it=E2=80= =99s > possible for a Lua program that executes a small number of bytecodes > to create a string that takes a vast amount of time to match on. > Again, this is also a problem for eBPF if you expose a similar > function, the solution is to not expose functions with large > data-dependent runtimes to untrusted script. >=20 > More generally, there are a lot of problems with interpreting or > JITing untrusted code in the kernel in *any* runtime. Speculative > execution makes it easy to use these as primitives to leak kernel > secrets, either via timing of the programs themselves, using the JIT > to generate gadgets, or by leaking data via cache priming. >=20 > Both eBPF and Lua have these problems. >=20 > The thing I would like to see for our current use of semi-trusted Lua > in the kernel (ZFS channel programs) is a way of exposing them (under > /dev/something) as file descriptors and modifying the ioctls that run > them to take a file descriptor argument. I would like to separate > the two operations: >=20 > - Load a channel program. > - Run a channel program. >=20 > In the post-Spectre world, the former remains a privileged operation. > Even though Linux pretends it isn=E2=80=99t, allowing arbitrary (even > arbitrary constrained) code to run in the kernel=E2=80=99s address space = is a > problem. Invoking such code; however, should follow the same rules > as everything else. A trusted entity should be able to load a pile > of Lua / eBPF / BPF64 / whatever programs into the kernel and then > set up permissions so that sandboxed programs (and jails) can use a > defined subset of them. >=20 > David >=20 This sounds a lot like IBM i / OS400 / System/360, or even Singularity from Microsoft, which uses a trusted JIT or AOT compiler to convert arbitrary bytecode to constrained machine code, so the machine code translator becomes the only trusted party, to accept or reject the arbitrary source (byte)code from the user. - Justin From nobody Tue Sep 10 14:32: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 4X35lZ4fQvz5Vvq9; Tue, 10 Sep 2024 14:32:58 +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 4X35lZ24jdz4Vq2; Tue, 10 Sep 2024 14:32:58 +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 9C8EE892DA; Tue, 10 Sep 2024 14:32:56 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48AEWu1q094702; Tue, 10 Sep 2024 14:32:56 GMT (envelope-from phk) Message-Id: <202409101432.48AEWu1q094702@critter.freebsd.dk> To: Vadim Goncharov cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative In-reply-to: <20240910160915.55ff579b@nuclight.lan> From: "Poul-Henning Kamp" References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <202409101224.48ACO7oj094058@critter.freebsd.dk> <20240910160915.55ff579b@nuclight.lan> 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: <94700.1725978776.1@critter.freebsd.dk> Date: Tue, 10 Sep 2024 14:32:56 +0000 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] X-Rspamd-Queue-Id: 4X35lZ24jdz4Vq2 -------- Vadim Goncharov writes: > On Tue, 10 Sep 2024 12:24:07 +0000 > "Poul-Henning Kamp" wrote: > > > Lua has pointers now ? > > It's implementation has. As does (e)BPF's implementation. > > You're yelling at the guy who implemented a (very fast!) firewall > > where the rules were compiled to C code in a KLD. > > That's exactly the way which must be avoided. See 5.2 of > https://www.usenix.org/legacy/events/bsdcon02/full_papers/lidl/lidl.pdf I didn't agree with them then, and I dont agree with them now :-) In my implementation, the ipfw(8) worked *precisely* the same as it always did, just a little slower because it had to run the C-compiler. Later I used the same trick in Varnish, where the "VCL" configuration language is compiled into a shared library, a major performance gain. > You're either trolling or completely misunderstand the problem domain. > [wiki quote] > This has nothing to do with BPF at all. Go and read original papers on > kernel filters and why they're *such* restricted, e.g. Van Jacobson's > paper on BPF/tcpdump, aforementitioned paper on BSD/OS's IPFW (esp. > section 5.7 on loops), etc. Yes, I read those papers when they were fresh, and I still think I know more about this problem domain than you will ever have to learn. I will admit that I have not run channel programs on a 709 myself, I only got into that game on a 4381. I also wrote my own prototype eBPF around 1996-97, in an attempt to deal with some obscure protocols, but I gave up on it, precisely because BPF was a "toy" language so it couldn't do what I needed. There are two fundamental questions: A) How powerful do you want the downloaded bytecode to be ? B) What syntax to you express it in ? There are basically two possible answers to A. Either the downloaded code is "real", which means it can include loops, function calls etc. or it is a "toy" which relies on Brinch-Hansen's "all arrows point to the right" argument to prove that it will always terminate. Obviously there is a lot of stuff you cannot do with a "toy", but it is a valid trade-off. VJ had no trouble making BPF a "toy": He lost no functionality, and it made it easier/possible to convince people that this would not cause the same problems as IBM channel programs did. I made VCL a "toy", also because no functionality was lost, and it eliminated a very obvious way for webmasters, not the worlds best programmers to begin with, to shoot their own feet. Personally I think it should be a "securelevel" like setting if FreeBSD's channel programs should be allowed to loop: We supply code, not policy. But that question is /entirely/ separate from the second question. The answer to that is that you can write them in /any/ programming language you want, as long as the interpreter for the resulting (byte-)code an spot attempts to jump backwards, and refuse to do so, if so configured. And that is why I say: If we're going to do this, let us do it with Lua: It's already in our tree and it will do the job nicely. After all, we dont want to make another mess like ACPI, do we ? Poul-Henning -- 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 Tue Sep 10 14:41:20 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 4X35xS59cdz5VwYD for ; Tue, 10 Sep 2024 14:41:32 +0000 (UTC) (envelope-from gavin@gavinhoward.com) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X35xQ2yYYz4XPG for ; Tue, 10 Sep 2024 14:41:30 +0000 (UTC) (envelope-from gavin@gavinhoward.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gavinhoward.com header.s=protonmail3 header.b=z2SUQFVi; dmarc=pass (policy=quarantine) header.from=gavinhoward.com; spf=pass (mx1.freebsd.org: domain of gavin@gavinhoward.com designates 185.70.40.136 as permitted sender) smtp.mailfrom=gavin@gavinhoward.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gavinhoward.com; s=protonmail3; t=1725979287; x=1726238487; bh=RW67wIDS5bvUOHOvpr1ZNJ6nwIqNKEwC+/c3JJKCTbg=; h=Date:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=z2SUQFVifKU8tRcBry+p5VQGi32KwoBLA1lAcd5+RdeNwBPEAWDffoLD7elBNNN7c HoY1FwxICh5VVq6nCtUSRvy02L+Lb1FBQU/2ddprPcLxXCDW46Jn1F6xquj/8eB8Hb ARc7hVUZqWaq5tnyA318LP6rJaUkTwbsZtVmlXzExUokFHSjKdomNlWhoVRkkBuwMt kWQ39P9kRgRyqHTWFaI1fUkPS0Ll4lU91wveIuDPFFISLI45QpYiNPdr1Kv2Y/NbBb ecCsCsOELDPXynXwWrAhcWQxZwst5FzVEXBCgW4ypneIVMx25VQiJW7Ec3bM/gTAv8 gw5TRvOlYSUfA== Date: Tue, 10 Sep 2024 14:41:20 +0000 From: "Gavin D. Howard" Cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tcpdump-workers@lists.tcpdump.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: In-Reply-To: <20240910040544.125245ad@nuclight.lan> References: <20240910040544.125245ad@nuclight.lan> Feedback-ID: 18790518:user:proton X-Pm-Message-ID: d4caef58d7e64cc697c44701208132b07bb0c1ca 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-Spamd-Bar: -- X-Spamd-Result: default: False [-2.19 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gavinhoward.com,quarantine]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.40.136:from]; R_DKIM_ALLOW(-0.20)[gavinhoward.com:s=protonmail3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[gavin]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gavinhoward.com:+] X-Rspamd-Queue-Id: 4X35xQ2yYYz4XPG Hello, New user here, not a contributor. > Ensuring kernel stability? Just don't allow arbitrary pointers, like orig= inal BPF. > Guaranteed termination time? It's possible if you place some restrictions= . For > example, don't allow backward jumps but allow function calls - in case of > stack overflow, terminate program. Really need backward jumps? Let's anal= yze > for what purpose. You'll find these are needed for loops on packet conten= ts. > Solve it but supporting loops in "hardware"-controlled loops, which can't= be > infinite. If I understand Turing-completeness correctly, the "no backward jumps but allow recursion and quit on stack overflow" is exactly equivalent to having non-infinite loops. I'm not entirely sure, but I think the lack of backwards jumps would be "simple" to check on LLVM IR: just make sure that a basic block does not jump, directly or indirectly, to a basic block that dominates it. [1] [1]: https://en.wikipedia.org/wiki/Dominator_(graph_theory) And then the stack overflow mechanic would be an entirely runtime check, which is safer than pure static checking. But the good thing about this is that FreeBSD could use LLVM IR as the BPF64 language, which means any language that compiles to LLVM is a possible target. As for restricting access, I think it would be possible to check the instructions in LLVM IR for any unsafe instructions or calls to restricted functions. The downsides: * Someone would need to write an LLVM analyze pass or whatever they're called. Maybe more than one. * The kernel would need the ability to compile LLVM IR, making LLVM part of the Ring 0 domain. =09* Either that, or someone builds an LLVM-to-bytecode translator. =09* But the analysis pass(es) must still live in the kernel. * There would need to be tutorials or some docs on how to write whatever language so that backwards jumps are avoided. Please take my words with a full dose of salt; I'm not an expert on this or on FreeBSD goals. Gavin Howard From nobody Tue Sep 10 14:49: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 4X367F0QB9z5VwwC for ; Tue, 10 Sep 2024 14:50:01 +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 4X367D32ZCz4YkQ; Tue, 10 Sep 2024 14:50:00 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 48AEnni9008978; Tue, 10 Sep 2024 23:49:49 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1725979789; bh=5LRx4bIIJlK9u6Jw6dHQW4OmwthwukK9ex16GmzILyY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=HzuPUO2BfltyyPpXq2Dn4SRRBiNfgzM4cQWQjAEnwnieFHM5WLYqtj2yrVGSz6cXC /0X3G4C4ta7jMFDqJaEZz/DUN7zQPqa9SQ29iiJQr37c3Y5UcFS6A0hG/TpAbffxhp SWjzNor1bAZCjW+7HFUtTqGITknWJYfUe/VRSQZE= Date: Tue, 10 Sep 2024 23:49:49 +0900 From: Tomoaki AOKI To: Kyle Evans Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-Id: <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> In-Reply-To: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> References: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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-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] X-Rspamd-Queue-Id: 4X367D32ZCz4YkQ On Mon, 9 Sep 2024 16:11:40 -0500 Kyle Evans wrote: > On 9/5/24 13:09, Alan Somers wrote: > > By now I expect that most of you have seen the long list of new > > security advisories that just came out. Strikingly, all were the > > result of memory handling errors. And none of them wouldn't have > > happened if their respective programs had been written in a > > memory-safe language. > > > > In fact, of all the C bug fixes that I've been involved with (as > > either author or reviewer) since May, about three quarters could've > > been avoided just by using a better language. > > > > The real takeaway here is that C is no longer sufficient for writing > > high quality code in the 2020s. Everyone needs to adapt their tools. > > Programmers who don't will increasingly come to resemble experimental > > archaeologists, i.e. people who learn flintknapping to "keep the > > knowledge alive". Such people are valuable, but definitely niche. I > > for one don't want my career to go in that trajectory. > > > > To summarize, here's the list of this week's security advisories, and > > also some other recent C bug fixes of my own involvement: > > [... snip ...] > > If even half of the energy that has gone into these threads would've > been spent on a proof-of-concept rust-xtoolchain implementation with > some motivating cases instead, we'd be in a lot better place to actually > have these conversations. > > Thanks, > > Kyle Evans Shawn would be working on the PoC now. Let's see how it goes. The worst is that the work is rejected AFTER it's almost done. It's clearly wastes of times/efforts. My guess about this thread is that it is needed to determine what is acceptable, what's not, what's needed to be confirmed. Clarifying the above as much as possible before starting the work is a good thing. Now we know how many pros&cons exists, and what are proposed as possible alternatives. Unfortunately, it's still "chaotic" and maybe need some more times. And discussions are ongoing at forums.frebsd.org, too. [1] It already is quite a long thread. [1] https://forums.freebsd.org/threads/the-case-for-rust-in-the-base-system.92024/ -- Tomoaki AOKI From nobody Tue Sep 10 14:58:25 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 4X36KB534yz5Vxnp; Tue, 10 Sep 2024 14:58:38 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X36KB4M8tz4bZ8; Tue, 10 Sep 2024 14:58:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725980318; 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: in-reply-to:in-reply-to:references:references; bh=RgfWg2bulIbwtlV/4Gjmiz25NxsSSsRKimR8IwQMrQE=; b=Yqjp1onLc6T66JnXpukvkLGCGByhHTqXQ/326gFljqWs22byt1+e31gu+GCi/qbx1Qe6is 19z0z9mVS66YgQnLUcS8Fz5A2RX2KYusseSh5luBCoLs5aUugArFyS9I70IO7MGUA5Kz6d lWjLGexiEHflu+Vbtgb4qeqaKpr5cLMisHU7Nt47w8Kmuudk3TS1OHJwwx85Ru4oJ156U3 l8R7uKdnkjq0HlcgFFQlrd8u+/TqjRFjvd30cVT72QopUl2IpcAEUxhWyC0YYCJIvhnkP5 +zeQyqQpg+Q9/lmtGm4wXowi5s2CZYfEBp0XtFOFICzaDFaX6K+LnUTLU+uS+A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725980318; a=rsa-sha256; cv=none; b=r7J1AAmkrkm88Vv2xWg8U5zAVGa+oX4cpBbaBVKACfFD7x3NRSIVu05KyQwMQL5yG2WZyt Q3mPi9W6FkJr+qTpzJlpVZ6BiGdlc9ekOH8MGH46zWjkNV+CNRQlHBabZvH/r3O4sUHqPs 6c5dUmvpMZEEEBSJvn23ioPLwYjA7g0f7v+EuPSR3yDVoDFZpMFonBC5rg7cI7ceP/yn8s 1NtdgdOcRPVVpI6xEKbTSMOWiFonw7QgqQcRTBkUe3K7Ez/rW+p2WYCZ4BpkwfiQ1bjFmS j/LAwD8cbfSJUr7cvByrmKoDrbTBfDjDrLRVzVeYYxnVZO7f2gk2DsaP+GPMqw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725980318; 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: in-reply-to:in-reply-to:references:references; bh=RgfWg2bulIbwtlV/4Gjmiz25NxsSSsRKimR8IwQMrQE=; b=q7NHQXHrOSUosQwO+DzcksYTdwz4obEKP7ay6HIibVp7dwPFksuNRXj5sP48Tj396u9aAp +nWPswQuT7dFtKGmNEIWLzx/QaAzKaNUQzQO1Q5d+vPgTD7sJgK4u5kTgexTYzKf7h8dus 3DspqJvgkEq+rSS/7k55rXxyOGUICY3pRc0cAuvGsfhelj0rqRi3CTGFuO9+eqT1T9xBJz RSASC+aARtnuWwLKcKyhPz3StD71XHDdzb8aEOzcFcQkv3JnUsQ/7PY/Ya2SZ9yA4fr+6i 7JB2X+kMw0q+nvd1HxmuuP55rhSdwyT28vfUxIZjLQS5ihaUonNv4WbU0fZbiA== 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 4X36KB3VKczSKG; Tue, 10 Sep 2024 14:58:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id DA1E365B7; Tue, 10 Sep 2024 15:58:36 +0100 (BST) From: David Chisnall Message-Id: <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_C79A00F0-FADC-4B5C-84B5-8912A75C117E" 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 \(3776.700.51\)) Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Date: Tue, 10 Sep 2024 15:58:25 +0100 In-Reply-To: <20240910164447.30039291@nuclight.lan> Cc: Poul-Henning Kamp , tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov To: Vadim Goncharov References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_C79A00F0-FADC-4B5C-84B5-8912A75C117E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 10 Sep 2024, at 14:44, Vadim Goncharov = wrote: >=20 > I am not an experience assembler user and don't understand how Spectre > works - that's why I've written RFC letter even before spec finished - = but > isn't that (Spectre) an x86-specific thing? BPF64 has more registers > and primarily target RISC architectures if we're speaking of JIT. No, speculative execution vulnerabilities are present in any CPUs that = do speculative execution that does not have explicit mitigations against = them (i.e. all that have shipped now). Cache side channels are present = in any system with caches and do not have explicit mitigations (i.e. all = that have shipped so far). Mitigations around these things are an active research area, but so far = everything that=E2=80=99s been proposed has a performance hit and = several of them were broken before anyone even implemented them outside = a simulator. > And BPF64 is meant as backwards-compatible extension of existing BPF, > that is, it has bytecode interpreter (for(;;) switch/case) as primary > form and JIT only then - thus e.g. JIT can be disabled for non-root > users in case of doubt. eBPF can't do this - it always exists in = native > machine code form at execution, bytecode is only for verifier stage. This has absolutely no impact on cache side channels. The JIT makes = some attacks harder but prime-and-probe attacks are still possible. BPF can be loaded only by root, who can also load kernel modules and map = /dev/[k]mem, and FreeBSD does not protect the root <-> kernel boundary. Please read some of the (many) attacks on eBPF to better understand the = security landscape here. It=E2=80=99s a *very* hard problem to solve. David --Apple-Mail=_C79A00F0-FADC-4B5C-84B5-8912A75C117E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 10 Sep = 2024, at 14:44, Vadim Goncharov <vadimnuclight@gmail.com> = wrote:

I am not an experience assembler user and = don't understand how Spectre
works - = that's why I've written RFC letter even before spec finished - = but
isn't = that (Spectre) an x86-specific thing? BPF64 has more registers
and = primarily target RISC architectures if we're speaking of JIT.

No, speculative execution = vulnerabilities are present in any CPUs that do speculative execution = that does not have explicit mitigations against them (i.e. all that have = shipped now).  Cache side channels are present in any system with = caches and do not have explicit mitigations (i.e. all that have shipped = so far).

Mitigations around these things are an = active research area, but so far everything that=E2=80=99s been proposed = has a performance hit and several of them were broken before anyone even = implemented them outside a simulator.

And BPF64 is meant as = backwards-compatible extension of existing BPF,
that = is, it has bytecode interpreter (for(;;) switch/case) as = primary
form = and JIT only then - thus e.g. JIT can be disabled for non-root
users = in case of doubt. eBPF can't do this - it always exists in = native
machine = code form at execution, bytecode is only for verifier stage.

This has absolutely no impact = on cache side channels.  The JIT makes some attacks harder but = prime-and-probe attacks are still possible.

BPF = can be loaded only by root, who can also load kernel modules and map = /dev/[k]mem, and FreeBSD does not protect the root <-> kernel = boundary.

Please read some of the (many) = attacks on eBPF to better understand the security landscape here. =  It=E2=80=99s a *very* hard problem to = solve.

David

= --Apple-Mail=_C79A00F0-FADC-4B5C-84B5-8912A75C117E-- From nobody Tue Sep 10 15:11:54 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 4X36cX1ZS3z5W0PP for ; Tue, 10 Sep 2024 15:11:56 +0000 (UTC) (envelope-from kevans@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X36cW6q4gz4g42; Tue, 10 Sep 2024 15:11:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725981116; 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=Q8bvsp5fuAR2BhfKqkhSovNQ58jEVyS49XViHKvHa44=; b=D2LhrX9r5Hhqh+yIuK6+c1sLOrJ5cde60oCkSKREX4d64Jy3Qt/tNQlWFcNwHboWSGb56O L1/2cJk3XMDxqbAPfS8bjxbqZsp72vC5X/byXTCxqZLkvlG5udJtPgMqbH3yYNRxQYKOS/ atlIbDGzD/pErXc6/OrG3X3V5TPFt++bmAmf0cpT20Tx3wFR8TfMxgBAnaB02rC4bSnv6u EfmjI4OB2M9lRQVNhtJJ5j9SrDhoC1UIzovJziX/5KnHYRXdB5yYZm5sNL76yynXWeiSgd BggGM8fr1eEgQM4CkbitqTbGzgRVEh4/J5S+GhIho6bnQuHMmyDIU92UxpLgYQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725981116; a=rsa-sha256; cv=none; b=k2Wu6Z14Zh/ASyJlLCh6kwf/Zb5xfLBqkQNb2NlNlVw/i1RbU+CgGO8qOuTMR+f6DxWxf/ yzLy6+0UCivqEQR8AhoyMbiYQ9ZZoa1OwZYJbx1RtlNNSsz+WSMMFNBuEG9ByazOB3uHp4 ugf37Hup0Yiq15NCnWnjEhy2n8fZfurjxaQXHwmhx5EhAVFkIo/zIncsmjCj+OPCkx6DP/ HAukyKZ3tlKIsl3SpyQVk7awSUjFlv6R41tHNDFfFBC95uHEQDpCgPKcuOUdTMdTe8qjxh pU791w6Gr+INFgZim/AqIaBB1dU4809c6mOidqX3q5tonyUN81uhouugqvD57A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725981116; 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=Q8bvsp5fuAR2BhfKqkhSovNQ58jEVyS49XViHKvHa44=; b=wgKm+WmI6Siwq90dp4pNnjeZvH+PD4+vm1CXoF6Ln4QNp30hLjeiJBxGn5JJZ0CRFZ7nk1 RUcvtsytxp6STNl4ha2pb5GIloHRuQGwEiVc5acxvBTOGGE2B0kR4bJI1ywC6ygNsUqfbW 5uePEGkuqi27B7QaYXJXwo8Rcq5QFdUpECyoZYAxNBstFDFO4+72IFZfQfY/nV+i0LKNJP lCnP5IfIIjkZxCIZR7s7re/vLwdH/xW2JcO0FLIgDO9tsg/rxYXreQfS7m3AU30s45VEEC /iI9wcwukoZDRZfG+V1+3XKpMaIN7cVFf7cFjCvZncDocpdJ7La2cM2gFFMVuw== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X36cW4ly1zTLR; Tue, 10 Sep 2024 15:11:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Tue, 10 Sep 2024 10:11:54 -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 any system) To: Tomoaki AOKI Cc: freebsd-hackers@freebsd.org References: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> Content-Language: en-US From: Kyle Evans In-Reply-To: <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/10/24 09:49, Tomoaki AOKI wrote: > On Mon, 9 Sep 2024 16:11:40 -0500 > Kyle Evans wrote: > >> On 9/5/24 13:09, Alan Somers wrote: >>> By now I expect that most of you have seen the long list of new >>> security advisories that just came out. Strikingly, all were the >>> result of memory handling errors. And none of them wouldn't have >>> happened if their respective programs had been written in a >>> memory-safe language. >>> >>> In fact, of all the C bug fixes that I've been involved with (as >>> either author or reviewer) since May, about three quarters could've >>> been avoided just by using a better language. >>> >>> The real takeaway here is that C is no longer sufficient for writing >>> high quality code in the 2020s. Everyone needs to adapt their tools. >>> Programmers who don't will increasingly come to resemble experimental >>> archaeologists, i.e. people who learn flintknapping to "keep the >>> knowledge alive". Such people are valuable, but definitely niche. I >>> for one don't want my career to go in that trajectory. >>> >>> To summarize, here's the list of this week's security advisories, and >>> also some other recent C bug fixes of my own involvement: >> > [... snip ...] >> >> If even half of the energy that has gone into these threads would've >> been spent on a proof-of-concept rust-xtoolchain implementation with >> some motivating cases instead, we'd be in a lot better place to actually >> have these conversations. >> >> Thanks, >> >> Kyle Evans > > Shawn would be working on the PoC now. Let's see how it goes. > > The worst is that the work is rejected AFTER it's almost done. > It's clearly wastes of times/efforts. > IMO if (general) you did enough work that you're angry about it being rejected, then you probably did way more than you should've for the stage we're at. If you're rewriting major utilities/daemons for a PoC / talking point, then you're doing it wrong. > My guess about this thread is that it is needed to determine what is > acceptable, what's not, what's needed to be confirmed. > Except it's been increasingly clear even before this discussion fired up again that a large chunk of the people involved don't have a good point of reference to even have this discussion. You're wearing them down on the topic before you even have something to point at and say "Hey, this is what it might look like" and maybe a roadmap for some of the low-hanging fruit for things we can improve with it. > Clarifying the above as much as possible before starting the work is > a good thing. Now we know how many pros&cons exists, and what are > proposed as possible alternatives. Unfortunately, it's still "chaotic" > and maybe need some more times. > > And discussions are ongoing at forums.frebsd.org, too. [1] > It already is quite a long thread. > > > [1] > https://forums.freebsd.org/threads/the-case-for-rust-in-the-base-system.92024/ > I'd go as far as to say that none of this is all that useful until we can evaluate how much pain we're in for in trying to add this dependency, but we're apparently more interested in discussing it to death without putting in the effort to demonstrate the feasibility through bare minimum integration. It's not very encouraging for future work in the area between that and also that the request made months ago for something tangible to point at to discuss further was answered by exactly one person who's already terribly busy. It's great that he's trying to make time, but you would've thought from these threads that *someone*, *anyone* would have made time with all of this demonstrated passion if they really cared enough to push it forward. We've been able to use C++ in base in a safer fashion for years and that simply has not happened, so one has to question the interest in alternatives. Thanks, Kyle Evans From nobody Tue Sep 10 15:17: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 4X36kj54Gbz5W0jd; Tue, 10 Sep 2024 15:17:17 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X36kh6wg7z4h7w; Tue, 10 Sep 2024 15:17:16 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5365b71a6bdso5150035e87.2; Tue, 10 Sep 2024 08:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725981434; x=1726586234; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=W+EtQAWIcFr+qyUilH/Xt2d7xpL9Fl6f8mgiQAu4olk=; b=O55e2XG+xisoVf3uMiBEdhWfYniaXzAQYrUJHVg1sXj+MGRDanOdQtICsuv2TplTUd 361DPWCVnIWoTon7NGA5ZFKuCwah9rllLz2PgBDZ5irWsyjMNvBGlV4zL1RSEG9AGc1K cqJEb2v3amcci6zXKiGeSsGF7J1tttOMVTCXGB7OTZrHsFKlNamq49nFO52z2aJoVCau qYS/8MbEzTkiVBWd6eN/zj5EMlRnU4OUZQ6wA/LcAIZ2MK3TGfFBx0dy7VSGo9RfDXnu 71K/kQN2Naz+TxI3d0kqtx2jK5+kHCZVZB9UmVSjSVft0Htg1CsizUjN1s2Pis5IiEDa c8ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725981434; x=1726586234; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=W+EtQAWIcFr+qyUilH/Xt2d7xpL9Fl6f8mgiQAu4olk=; b=nhnhVMjkVhbtgyGerv/WRmZ6ndHTbdBeB1YerOkPrdYsbUp+9pfggG+d5ebzXDupzX SNVNtyxo5DB6XjZ9iaHz441XZchTvtILLfzQqO0ibs3D6iY+Vky+2J7x0gLCqob7xWCA j0V0SwqY42VwSkwQKoTHv6EdCpq0415eqcv++FfBK5F3mUXwmZQBa4VrZU2JbrM9p/Hl pQt/z312SqP3iMMPpIGwj1axb1gYujizwFW2fUWxIAoLRhDXT7uxmoZoHicoHLZzl6tx 9IHWEe8vZl4LaUM8E3CNODNks45tenshhhkLuZeQrVIB4PiK/JyW5Y0MxxHooag5Atnt IsjQ== X-Forwarded-Encrypted: i=1; AJvYcCUBrZXLR5iL++2H5jTPRqk24AzFLTFq+nhBgOtGpW6la2Jo5125JwEVlVHTVydGUunpyTsumveEuwYKSL7ezUE=@freebsd.org, AJvYcCV/6pcIHgaoxKppqu7x19+k1dC7jaMNwXUoVjAyP6Rcwnj44SECl2i57W1dI1As7Q1IuvjU6a2DxYWdVEg=@freebsd.org X-Gm-Message-State: AOJu0YxorJ8tM1QPfCYVH3paHt3Gxxx7OdtWyIfkil/ZctV41tMyvebk B4eWRJ1FE0MGH4j+RKYUW1frAQgw0q8FWJu9Y/Vi+/eN8xnuRPOT X-Google-Smtp-Source: AGHT+IHB+HtNqR5Mhpl+gR9Q78EPAz5C5X6JRviKpNPloEM6ML1p7/WA+anUT0/yPZnqvpaJWeXDyw== X-Received: by 2002:a05:6512:2215:b0:534:5453:ecda with SMTP id 2adb3069b0e04-536587ae6c8mr9702590e87.23.1725981433978; Tue, 10 Sep 2024 08:17:13 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5365f86925asm1198726e87.31.2024.09.10.08.17.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 08:17:13 -0700 (PDT) Date: Tue, 10 Sep 2024 18:17:11 +0300 From: Vadim Goncharov To: "Gavin D. Howard" Cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tcpdump-workers@lists.tcpdump.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240910181711.5d324ac5@nuclight.lan> In-Reply-To: References: <20240910040544.125245ad@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-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] X-Rspamd-Queue-Id: 4X36kh6wg7z4h7w On Tue, 10 Sep 2024 14:41:20 +0000 "Gavin D. Howard" wrote: > Hello, > > New user here, not a contributor. > > > Ensuring kernel stability? Just don't allow arbitrary pointers, > > like original BPF. Guaranteed termination time? It's possible if > > you place some restrictions. For example, don't allow backward > > jumps but allow function calls - in case of stack overflow, > > terminate program. Really need backward jumps? Let's analyze for > > what purpose. You'll find these are needed for loops on packet > > contents. Solve it but supporting loops in "hardware"-controlled > > loops, which can't be infinite. > > If I understand Turing-completeness correctly, the "no backward jumps > but allow recursion and quit on stack overflow" is exactly equivalent > to having non-infinite loops. Sure, but then look at practical usefulness: suppose you have stack of 32 frames (current limit of eBPF and BPF64). Then you can have only 31 iterations on a loop, loosing ability to call more functions from loop body. > I'm not entirely sure, but I think the lack of backwards jumps would > be "simple" to check on LLVM IR: just make sure that a basic block > does not jump, directly or indirectly, to a basic block that > dominates it. [1] > > [1]: https://en.wikipedia.org/wiki/Dominator_(graph_theory) > > And then the stack overflow mechanic would be an entirely runtime > check, which is safer than pure static checking. > > But the good thing about this is that FreeBSD could use LLVM IR as the > BPF64 language, which means any language that compiles to LLVM is a > possible target. > > As for restricting access, I think it would be possible to check the > instructions in LLVM IR for any unsafe instructions or calls to > restricted functions. > > The downsides: > > * Someone would need to write an LLVM analyze pass or whatever they're > called. Maybe more than one. > * The kernel would need the ability to compile LLVM IR, making LLVM > part of the Ring 0 domain. > * Either that, or someone builds an LLVM-to-bytecode > translator. Well, using LLVM were supposed for higher-level languages when bytecode is no longer experimental, utilizing full power of optimizer, but for direct using... let's see how they use it in Linux currently: 1) you write .c code, relatively low-level/restricted, with eBPF .h-s 2) clang turns .c into LLVM IR file (yes, this step is separate, may be things has changed since then, but at least it was so) 3) file with LLVM IR turned to eBPF bytecode in ELF file 4) ELF .o loaded by ip(8) or specialized loader into kernel 5) verifier checks it and most probably will return error to you :) 6) bytecode is JIT-compiled in kernel and then may be run Linux people are in mood "let's throw more man-months instead of thinking of better design", eBPF infrastructure consists of hundreds of thousandls lines of code, but seems that utilizing LLVM IR directly required too much resources even from them so was rejected. > * But the analysis pass(es) must still live in the kernel. > * There would need to be tutorials or some docs on how to write > whatever language so that backwards jumps are avoided. So BPF64 took simplicity pass: while you have tutorials etc. it's still very hard to write (non-toy) code that passes verifier. I think a language where you do not need backward jumps but have usable constructs (so you just can't write bad code), even BAW, is a better way to go than try to train people to fight with unnecessary Cerber. > Please take my words with a full dose of salt; I'm not an expert on > this or on FreeBSD goals. BPF64 is not FreeBSD-only, you can see several non-FreeBSD mailing lists here. It can be cross-platform and independent enough to be implemented in e.g. network card or switch, for performance - having more registers allows to achieve better results then eBPF for same goal. -- WBR, @nuclight From nobody Tue Sep 10 15:17:20 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 4X36ky03xGz5W0r6 for ; Tue, 10 Sep 2024 15:17:30 +0000 (UTC) (envelope-from gavin@gavinhoward.com) Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X36kw40kyz4hFT for ; Tue, 10 Sep 2024 15:17:28 +0000 (UTC) (envelope-from gavin@gavinhoward.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gavinhoward.com header.s=protonmail3 header.b=2taXJyjF; dmarc=pass (policy=quarantine) header.from=gavinhoward.com; spf=pass (mx1.freebsd.org: domain of gavin@gavinhoward.com designates 185.70.43.17 as permitted sender) smtp.mailfrom=gavin@gavinhoward.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gavinhoward.com; s=protonmail3; t=1725981445; x=1726240645; bh=oe7643bp6zNhqP8zU1cutUeUStT3vDukutWnVlZ4VTU=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=2taXJyjF3AkSbb6kWVsVe2mMm5E3D16GjBBTReuNNnJzTx+5yMV1tNC4MGyz9Uap/ F5XsEba6YLrLUR1ylaHfU7Qwgv+7MVvJhEKyr2CoHKSVDznhWQMrh7xPlx4nJ6guMu KAnzhLvMfHsQwHTSJw6d9aS8Wz2XFxh+i4X+evv12tHzhJmonUCuWhyD4t1l471z3Y 0UhKJYmarkgFMI3EzgQZ6f2WEfCMQrjbuTdfB9/rmK7h7RVr2IAFrhMCNe1C433n5h jnYqAypTv7dwjJIJnLeF+wDZg9v6JNcYAQv9enbg2NIs6SxHp2GGtUlsA3RS01kDSN qXUi7OYxZ0OeQ== Date: Tue, 10 Sep 2024 15:17:20 +0000 To: "freebsd-hackers@FreeBSD.org" From: "Gavin D. Howard" Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-ID: In-Reply-To: References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> Feedback-ID: 18790518:user:proton X-Pm-Message-ID: 78a69d9b187e201ff4d026cbdbc9dc3e2852f9c6 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="b1_GMloHLZAdCOv3wCbUUs2gmIHrUTZ5gDXerucDpu1vg" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.06 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.959]; DMARC_POLICY_ALLOW(-0.50)[gavinhoward.com,quarantine]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.43.17:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; R_DKIM_ALLOW(-0.20)[gavinhoward.com:s=protonmail3]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEFALL_USER(0.00)[gavin]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_EQ_ADDR_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_PHPMAILER_SIG(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; DKIM_TRACE(0.00)[gavinhoward.com:+] X-Rspamd-Queue-Id: 4X36kw40kyz4hFT This is a multi-part message in MIME format. --b1_GMloHLZAdCOv3wCbUUs2gmIHrUTZ5gDXerucDpu1vg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T24gVHVlc2RheSwgU2VwdGVtYmVyIDEwdGgsIDIwMjQgYXQgMjo0NyBBTSwgRGF2aWQgQ2hpc25h bGwgPHRoZXJhdmVuQEZyZWVCU0Qub3JnPiB3cm90ZToKCj4gT24gOSBTZXAgMjAyNCwgYXQgMjM6 MTIsIFJpY2sgTWFja2xlbSA8cmljay5tYWNrbGVtQGdtYWlsLmNvbT4gd3JvdGU6Cj4KPj4gQXMg Zm9yIGJ1aWxkIHRpbWVzLCBJIGFscmVhZHkgZmluZCAibWFrZSBidWlsZHdvcmxkIiB0YWtlcyB3 YXkgdG9vIGxvbmcKPj4gZm9yIG1lLCBzbyBhZGRpbmcgYW5vdGhlciBnaW5vcm1vdXMgY29tcGls ZXIgd29uJ3QgbWFrZSBtdWNoIGRpZmZlcmVuY2UuCj4KPiBBcyB3aXRoIHNvIG1hbnkgb3RoZXIg dGhpbmdzLCB0aGlzIHdvdWxkIGJlIGFkZHJlc3NhYmxlIGlmIHNvbWVvbmUgaGFkIHRoZSB0aW1l IHRvIGRvIGl0LiBBIHNpbmdsZSBkZXZlbG9wZXIgYXQgTWljcm9zb2Z0IGNhbiBlZGl0IHRoZSBj b2RlIGFuZCBidWlsZCB0aGVpciBvd24gY3VzdG9tIFdpbmRvd3MgVk0gaW1hZ2Ugb24gYSBmYWly bHkgbG93LWVuZCBsYXB0b3AsIGluIHNwaXRlIG9mIHRoZSBmYWN0IHRoYXQgbW9zdCBsYXB0b3Bz IGRvbuKAmXQgaGF2ZSBlbm91Z2ggZGlzayBzcGFjZSBmb3IgYSBmdWxsIGdpdCBjbG9uZSBvZiB0 aGUgV2luZG93cyBzb3VyY2UgdHJlZS4gVGhpcyBpcyBwb3NzaWJsZSBiZWNhdXNlIG9mIGEgY29t YmluYXRpb24gb2YgdHdvIHRoaW5nczoKPgo+IC0gZ2l0LXZmcyBsZXRzIHlvdSBoYXZlIGEgbG9j YWwgdmlldyBvZiBhIHJlbW90ZSBnaXQgcmVwbyBhbmQgZmV0Y2hlcyBmaWxlcyBvbiBkZW1hbmQg YXMgdGhleeKAmXJlIGFjY2Vzc2VkLiBEb27igJl0IHJ1biBgZ3JlcGAgb3ZlciB5b3VyIHNvdXJj ZSB0cmVlIQo+IC0gQSBidWlsZCBzeXN0ZW0gdGhhdCBoYXMgY2xvdWQgY2FjaGluZywgc28gaWYg eW91IGhhdmUgY2hhbmdlZCBvbmUgZmlsZSB5b3XigJlsbCByZWJ1aWxkIGV2ZXJ5dGhpbmcgdGhh dCBkZXBlbmRzIG9uIHRoYXQgZmlsZSBidXQgZG93bmxvYWQgdGhlIGFydGVmYWN0cyBmb3IgZXZl cnl0aGluZyBlbHNlLgo+Cj4gSXTigJlzIGEgYml0IHNhZCB0aGF0IGJ1aWxkaW5nIFdpbmRvd3Mg dHlwaWNhbGx5IHRha2VzIGEgZGV2ZWxvcGVyIGxlc3MgdGltZSB0aGFuIGJ1aWxkaW5nIEZyZWVC U0QuIFRoZSBlbmdpbmVlcmluZyBlZmZvcnQgaW52b2x2ZWQgaW4gdGhlIHNlY29uZCBwYXJ0IGlz IGh1Z2UgdGhvdWdoLiBJdCB3b3VsZCBwcm9iYWJseSBuZWVkIHRoZSBGb3VuZGF0aW9uIHRvIHBh eSBzb21lb25lIHRvIHdvcmsgb24gaXQgZm9yIGEgeWVhciAoSSB0aGluayB0aGlzIHdvdWxkIGJl IHdlbGwgd29ydGggdGhlIGludmVzdG1lbnQsIGJ1dCB0aGF04oCZcyBhbm90aGVyIGRpc2N1c3Np b24pLgoKSSBoYXZlIHdyaXR0ZW4gYSBidWlsZCBzeXN0ZW0gdGhhdCBJIHVzZWQgdG8gd2FudCBG cmVlQlNEIHRvIGFkb3B0IHNvbWVkYXksIGFuZCBpdCB3aWxsIGhhdmUgcmVtb3RlIGJ1aWxkIGNh Y2hpbmcuIEhvd2V2ZXIsIGFmdGVyIGxvb2tpbmcgYXQgaG93IEZyZWVCU0QgZG9lcyB0aGUgYnVp bGQsIEknbSBub3Qgc3VyZSBob3cgbXVjaCBidWlsZCBjYWNoaW5nIHdpbGwgaGVscC4gQnV0IEkg YW0gYSBuZXcgdXNlciwgbm90IGFuIGV4cGVydCwgc28gSSBjb3VsZCBiZSB3cm9uZy4KCldoYXQg SSBmb3VuZCBpcyB0aGF0IHRoZSBzcmMgdHJlZSBpcyBjb21waWxlZCBpbnRvIC91c3Ivb2JqLiBJ IHByZXN1bWUgb2JqZWN0IGZpbGVzIGZyb20gcHJldmlvdXMgY29tcGlsZXMgYWxsb3cgZm9yIGlu Y3JlbWVudGFsIHJlYnVpbGRzLiBJIHRoaW5rIHdlIHdvdWxkIGhhdmUgdG8gbWVhc3VyZSBob3cg bXVjaCBpbmNyZW1lbnRhbCBjb21waWxlcyBoZWxwIHRoZSBidWlsZCB0aW1lcywgYnV0IEkgc3Vz cGVjdCB0aGF0IGJ1aWxkIGNhY2hpbmcgd29uJ3QgaGVscCBzaW1wbHkgYmVjYXVzZSBpZiBhIGZp bGUgY2hhbmdlcywgaXQgYW5kIGl0cyBkb3duc3RyZWFtIGRlcGVuZGVudHMgd2lsbCBiZSBidWls dCBhbnl3YXksIGJ1aWxkIGNhY2hpbmcgb3Igbm90LgoKVGhlIG9uZSBwbGFjZSBpdCBtaWdodCBo ZWxwIGlzIGEgZnVsbCByZWJ1aWxkLiBJJ20gbm90IG9wdGltaXN0aWMgdGhhdCBmdWxsIHJlYnVp bGRzIGhhcHBlbiB0aGF0IG9mdGVuLiBFdmVuIGlmIHRoZXkgZG8sIHdvdWxkIGl0IGJlIHdvcnRo IHRvdWNoaW5nIHRoZSBuZXR3b3JrIGR1cmluZyBhIGJ1aWxkPwoKTm93IGFzIGZvciB0aGUgZW5n aW5lZXJpbmcgZWZmb3J0LCB5ZXMsIGl0IHdvdWxkIHJlcXVpcmUgYSBsb3QsIGJ1dCB0aGVyZSdz IG9ubHkgdHdvIGhhcmQgcGFydDogbWFraW5nIHRoZSBidWlsZCBzeXN0ZW0gaGVybWV0aWMgKGFs dGhvdWdoIHRoYXQgY2FuIGVhc2lseSBiZSBkb25lIG5vbnBvcnRhYmx5IHVzaW5nIGphaWxzKSBh bmQgbWFraW5nIHRoZSBidWlsZCBbcmVwcm9kdWNpYmxlXShodHRwczovL3JlcHJvZHVjaWJsZS1i dWlsZHMub3JnLykuIFRoZSByZXN0IG9mIGl0IGlzIGp1c3QgdGVkaW91cyBidXN5d29yaywgYXQg bGVhc3QgaWYgdGhlIGJ1aWxkIHN5c3RlbSBpcyBkZXNpZ25lZCBjb3JyZWN0bHkuCgpPbmUgb2Yg dGhvc2UgdGVkaW91cyBqb2JzIGlzIHRvIGVzc2VudGlhbGx5IHJlaW1wbGVtZW50IGFsbCBvZiB0 aGUgYnVpbGQgc3lzdGVtICh0YWxraW5nIGFib3V0IHRoZSBNYWtlZmlsZXMsIG5vdCBibWFrZSkg b25jZSB0aGUgbmV3IGJ1aWxkIHN5c3RlbSAoYm1ha2UgcmVwbGFjZW1lbnQpIGlzIHJlYWR5LiBB bmQgdGhlbiwgZXZlbiB3aGVuIHRoYXQncyBkb25lLCB0aGVyZSB3aWxsIGJlIGEgZGF5IHdoZW4g ZWl0aGVyIGJvdGggc2V0cyBvZiBidWlsZCBzY3JpcHRzIGFyZSBzdXBwb3J0ZWQsIG9yIGV2ZXJ5 b25lIG9uIC1DVVJSRU5UIGp1c3Qgc3dpdGNoZXMgb3Zlcm5pZ2h0LgoKSW4gb3RoZXIgd29yZHMs IHJlcGxhY2luZyB0aGUgYnVpbGQgc3lzdGVtIHdvdWxkIGJlIGRpc3J1cHRpdmUuIEV2ZW4gdGhv dWdoIEkgaGF2ZSBvbmUgdGhhdCBJJ2QgbGlrZSBGcmVlQlNEIHRvIHVzZSwgSSBhY3R1YWxseSBk ZWNpZGVkIGFnYWluc3QgY29udGludWluZyB0aGF0IGVmZm9ydC4KCj4gSeKAmW0gbm90IHN1cmUg aWYgYm1ha2UgY2FuIGJlIGV4dGVuZGVkIGVub3VnaCB0byBzdXBwb3J0IHRoaXMKCkl0IHByb2Jh Ymx5IGNhbiwgYnV0IEkgdGhpbmsgdGhlcmUgYXJlIGVhc2llciBwYXRocy4KCj4gKEJ1Y2syIGxv b2tzIHRvIGJlIHRoZSBtb3N0IHByb21pc2luZyBvZiB0aGUgbmV3IGJ1aWxkIHN5c3RlbXMgZGVz aWduZWQgYXJvdW5kIHRoaXMgbW9kZWwgYnV0IGl0IGhhc27igJl0IHlldCBoYWQgYSBzdGFibGUg cmVsZWFzZSBhbmQgY29tZXMgd2l0aCBiaWcg4oCYZG8gbm90IHVzZSB0aGlzIHlldOKAmSB3YXJu aW5ncykuCgpZZXMsIEJ1Y2syIGlzIHRoZSBtb3N0IHByb21pc2luZywgYnV0IGl0J3Mgd3JpdHRl biBpbiBSdXN0LCBzbyBpZiBCdWNrMiB3ZXJlIGFkb3B0ZWQsIFJ1c3Qgd291bGQgaGF2ZSB0byBi ZWNvbWUgcGFydCBvZiBzcmMgb3IgYW4gZXh0ZXJuYWwgdG9vbGNoYWluLgoKVGhhdCdzIG9uZSBv ZiB0aGUgaGFyZGVzdCB0aGluZ3MgYWJvdXQgYnVpbGQgc3lzdGVtczogdGhleSBhcmUgYSBkZXBl bmRlbmN5IGZvciBldmVyeXRoaW5nLCBidXQgdGhleSBoYXZlIGRlcGVuZGVuY2llcyB0b28uCgo+ IFRoaXMgd291bGQgYWxzbyBuZWVkIGluZnJhc3RydWN0dXJlIHRvIG1ha2Ugc3VyZSBlYWNoIGNv bW1pdCB0byBoZWFkIG9yIGEgc3RhYmxlIGJyYW5jaCB3YXMgYnVpbHQgaW4gYSB0cnVzdGVkIGVu dmlyb25tZW50IGFuZCBwdXNoZWQgdG8gdGhlIGNhY2hlcyAoYW5kIHRoYXQgcmFuZG9tIGRldmVs b3BlcnPigJkgYnVpbGRzIGRpZCBub3QpLgoKQ29tcGxldGVseSBhZ3JlZS4gQnV0IGlmIEZyZWVC U0QgaGFzIENJL0NELCB0aGVuIHRoYXQgY291bGQgYmUgd2hhdCBwdXNoZXMuIElmIG5vdCwgdGhl biBhZGRpbmcgdGhlIGJ1aWxkIGNhY2hlcyB3b3VsZCBiZSBhIGdvb2QgZXhjdXNlIHRvIGFkZCBp dC4KCkhvd2V2ZXIsIHRoZSByZWFzb24gQnVjazIgd29ya3Mgc28gd2VsbCBpcyBiZWNhdXNlIGl0 IGRvZXMgdGFrZSBidWlsZHMgZnJvbSByYW5kb20gZGV2ZWxvcGVycyBhbmQgcHVzaGVzIHRoZW0g dG8gdGhlIGJ1aWxkIGNhY2hlcy4gSXQgY2FuIGRvIHRoaXMgYmVjYXVzZSB0aGUgInJhbmRvbSIg ZGV2ZWxvcGVycyBhcmUgbm90IHRydWx5IHJhbmRvbSwgYnV0IEZhY2Vib29rIGVtcGxveWVlcy4g QW5kIGl0IGJ1aWxkcyB0aG9zZSByYW5kb20gZGV2ZWxvcGVycycgc3R1ZmYgcmVtb3RlbHkgaW4g c2FuZGJveGVzLgoKSWYgRnJlZUJTRCdzIGJ1aWxkIGNhY2hlcyB3b24ndCB3b3JrIGxpa2UgdGhh dCwgSSdtIG5vdCBzdXJlIGhvdyB1c2VmdWwgdGhleSB3b3VsZCBiZSBiZWNhdXNlIGRldmVsb3Bl cnMgd2hvIHdvdWxkIHB1bGwgZnJvbSBvdGhlcnMgZm9yIHRlc3RpbmcgYW5kIHJldmlldyB3b3Vs ZCBhbGwgaGF2ZSB0byBidWlsZCB0aGUgc2FtZSBmaWxlcy4gQnV0IGlmIEZyZWVCU0QgZGV2cyBj b3VsZCBwdXNoIHRvIHRoZSBidWlsZCBjYWNoZSwgb3IgZXZlbiBiZXR0ZXIsIGhhdmUgdGhlIHNl cnZlciBidWlsZCB0aGVpciBjaGFuZ2VzIGZvciBldmVyeW9uZSBlbHNlLCBJIHRoaW5rIHRoYXQg d291bGQgYmUgdGhlIG1vc3QgZWZmZWN0aXZlIHRpbWUgc2F2aW5ncyBmb3IgZGV2cy4gSnVzdCBi dWlsZGluZyBIRUFEIG9yIC1TVEFCTEUgd291bGQgbm90IHNhdmUgbXVjaCwgSU1PLgoKR2F2aW4g SG93YXJk --b1_GMloHLZAdCOv3wCbUUs2gmIHrUTZ5gDXerucDpu1vg Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij48YnI+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiIGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayBw cm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSI+DQogICAgPGRpdiBjbGFzcz0icHJvdG9u bWFpbF9zaWduYXR1cmVfYmxvY2stdXNlciBwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0 eSI+T24gVHVlc2RheSwgU2VwdGVtYmVyIDEwdGgsIDIwMjQgYXQgMjo0NyBBTSwgRGF2aWQgQ2hp c25hbGwgJmx0O3RoZXJhdmVuQEZyZWVCU0Qub3JnJmd0OyB3cm90ZToNCiAgICAgICAgPC9kaXY+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9InByb3Rvbm1haWxfcXVvdGUiPg0KICAgICAg ICAgICAgT24gOSBTZXAgMjAyNCwgYXQgMjM6MTIsIFJpY2sgTWFja2xlbSAmbHQ7cmljay5tYWNr bGVtQGdtYWlsLmNvbSZndDsgd3JvdGU6PGJyPjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48ZGl2PjxzcGFuIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogU291cmNlQ29kZVByby1SZWd1 bGFyOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiPkFzIGZvciBidWlsZCB0aW1lcywgSSBhbHJlYWR5IGZpbmQg Im1ha2UgYnVpbGR3b3JsZCIgdGFrZXMgd2F5IHRvbyBsb25nPC9zcGFuPjxiciBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFNvdXJjZUNvZGVQcm8tUmVndWxh cjsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PHNwYW4gc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBTb3VyY2VDb2RlUHJvLVJlZ3VsYXI7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyI+Zm9yIG1lLCBzbyBhZGRpbmcgYW5vdGhlciBnaW5vcm1vdXMgY29tcGls ZXIgd29uJ3QgbWFrZSBtdWNoIGRpZmZlcmVuY2UuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFNvdXJjZUNvZGVQcm8tUmVndWxhcjsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxi cj48ZGl2PkFzIHdpdGggc28gbWFueSBvdGhlciB0aGluZ3MsIHRoaXMgd291bGQgYmUgYWRkcmVz c2FibGUgaWYgc29tZW9uZSBoYWQgdGhlIHRpbWUgdG8gZG8gaXQuICZuYnNwO0Egc2luZ2xlIGRl dmVsb3BlciBhdCBNaWNyb3NvZnQgY2FuIGVkaXQgdGhlIGNvZGUgYW5kIGJ1aWxkIHRoZWlyIG93 biBjdXN0b20gV2luZG93cyBWTSBpbWFnZSBvbiBhIGZhaXJseSBsb3ctZW5kIGxhcHRvcCwgaW4g c3BpdGUgb2YgdGhlIGZhY3QgdGhhdCBtb3N0IGxhcHRvcHMgZG9u4oCZdCBoYXZlIGVub3VnaCBk aXNrIHNwYWNlIGZvciBhIGZ1bGwgZ2l0IGNsb25lIG9mIHRoZSBXaW5kb3dzIHNvdXJjZSB0cmVl LiAmbmJzcDtUaGlzIGlzIHBvc3NpYmxlIGJlY2F1c2Ugb2YgYSBjb21iaW5hdGlvbiBvZiB0d28g dGhpbmdzOjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jm5ic3A7LSBnaXQtdmZzIGxldHMgeW91 IGhhdmUgYSBsb2NhbCB2aWV3IG9mIGEgcmVtb3RlIGdpdCByZXBvIGFuZCBmZXRjaGVzIGZpbGVz IG9uIGRlbWFuZCBhcyB0aGV54oCZcmUgYWNjZXNzZWQuICZuYnNwO0RvbuKAmXQgcnVuIGBncmVw YCBvdmVyIHlvdXIgc291cmNlIHRyZWUhPC9kaXY+PGRpdj4mbmJzcDstIEEgYnVpbGQgc3lzdGVt IHRoYXQgaGFzIGNsb3VkIGNhY2hpbmcsIHNvIGlmIHlvdSBoYXZlIGNoYW5nZWQgb25lIGZpbGUg eW914oCZbGwgcmVidWlsZCBldmVyeXRoaW5nIHRoYXQgZGVwZW5kcyBvbiB0aGF0IGZpbGUgYnV0 IGRvd25sb2FkIHRoZSBhcnRlZmFjdHMgZm9yIGV2ZXJ5dGhpbmcgZWxzZS48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2Pkl04oCZcyBhIGJpdCBzYWQgdGhhdCBidWlsZGluZyBXaW5kb3dzIHR5cGlj YWxseSB0YWtlcyBhIGRldmVsb3BlciBsZXNzIHRpbWUgdGhhbiBidWlsZGluZyBGcmVlQlNELiAm bmJzcDtUaGUgZW5naW5lZXJpbmcgZWZmb3J0IGludm9sdmVkIGluIHRoZSBzZWNvbmQgcGFydCBp cyBodWdlIHRob3VnaC4gJm5ic3A7SXQgd291bGQgcHJvYmFibHkgbmVlZCB0aGUgRm91bmRhdGlv biB0byBwYXkgc29tZW9uZSB0byB3b3JrIG9uIGl0IGZvciBhIHllYXIgKEkgdGhpbmsgdGhpcyB3 b3VsZCBiZSB3ZWxsIHdvcnRoIHRoZSBpbnZlc3RtZW50LCBidXQgdGhhdOKAmXMgYW5vdGhlciBk aXNjdXNzaW9uKS48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxicj48L2Rpdj5JIGhhdmUgd3Jp dHRlbiBhIGJ1aWxkIHN5c3RlbSB0aGF0IEkgdXNlZCB0byB3YW50IEZyZWVCU0QgdG8gYWRvcHQg c29tZWRheSwgYW5kIGl0IHdpbGwgaGF2ZSByZW1vdGUgYnVpbGQgY2FjaGluZy4gSG93ZXZlciwg YWZ0ZXIgbG9va2luZyBhdCBob3cgRnJlZUJTRCBkb2VzIHRoZSBidWlsZCwgSSdtIG5vdCBzdXJl IGhvdyBtdWNoIGJ1aWxkIGNhY2hpbmcgd2lsbCBoZWxwLiBCdXQgSSBhbSBhIG5ldyB1c2VyLCBu b3QgYW4gZXhwZXJ0LCBzbyBJIGNvdWxkIGJlIHdyb25nLjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDAp OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9kaXY+PGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi PldoYXQgSSBmb3VuZCBpcyB0aGF0IHRoZSBzcmMgdHJlZSBpcyBjb21waWxlZCBpbnRvIC91c3Iv b2JqLiBJIHByZXN1bWUgb2JqZWN0IGZpbGVzIGZyb20gcHJldmlvdXMgY29tcGlsZXMgYWxsb3cg Zm9yIGluY3JlbWVudGFsIHJlYnVpbGRzLiBJIHRoaW5rIHdlIHdvdWxkIGhhdmUgdG8gbWVhc3Vy ZSBob3cgbXVjaCBpbmNyZW1lbnRhbCBjb21waWxlcyBoZWxwIHRoZSBidWlsZCB0aW1lcywgYnV0 IEkgc3VzcGVjdCB0aGF0IGJ1aWxkIGNhY2hpbmcgd29uJ3QgaGVscCBzaW1wbHkgYmVjYXVzZSBp ZiBhIGZpbGUgY2hhbmdlcywgaXQgYW5kIGl0cyBkb3duc3RyZWFtIGRlcGVuZGVudHMgd2lsbCBi ZSBidWlsdCBhbnl3YXksIGJ1aWxkIGNhY2hpbmcgb3Igbm90LjwvZGl2PjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdi KDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9k aXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 NSwgMjU1KTsiPlRoZSBvbmUgcGxhY2UgaXQgbWlnaHQgaGVscCBpcyBhIGZ1bGwgcmVidWlsZC4g SSdtIG5vdCBvcHRpbWlzdGljIHRoYXQgZnVsbCByZWJ1aWxkcyBoYXBwZW4gdGhhdCBvZnRlbi4g RXZlbiBpZiB0aGV5IGRvLCB3b3VsZCBpdCBiZSB3b3J0aCB0b3VjaGluZyB0aGUgbmV0d29yayBk dXJpbmcgYSBidWlsZD88YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigw LCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+Tm93IGFzIGZv ciB0aGUgZW5naW5lZXJpbmcgZWZmb3J0LCB5ZXMsIGl0IHdvdWxkIHJlcXVpcmUgYSBsb3QsIGJ1 dCB0aGVyZSdzIG9ubHkgdHdvIGhhcmQgcGFydDogbWFraW5nIHRoZSBidWlsZCBzeXN0ZW0gaGVy bWV0aWMgKGFsdGhvdWdoIHRoYXQgY2FuIGVhc2lseSBiZSBkb25lIG5vbnBvcnRhYmx5IHVzaW5n IGphaWxzKSBhbmQgbWFraW5nIHRoZSBidWlsZCA8YSB0aXRsZT0icmVwcm9kdWNpYmxlIiBocmVm PSJodHRwczovL3JlcHJvZHVjaWJsZS1idWlsZHMub3JnLyIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0i bm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciI+cmVwcm9kdWNpYmxlPC9hPi4gVGhlIHJlc3Qg b2YgaXQgaXMganVzdCB0ZWRpb3VzIGJ1c3l3b3JrLCBhdCBsZWFzdCBpZiB0aGUgYnVpbGQgc3lz dGVtIGlzIGRlc2lnbmVkIGNvcnJlY3RseS48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xv cjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5P bmUgb2YgdGhvc2UgdGVkaW91cyBqb2JzIGlzIHRvIGVzc2VudGlhbGx5IHJlaW1wbGVtZW50IGFs bCBvZiB0aGUgYnVpbGQgc3lzdGVtICh0YWxraW5nIGFib3V0IHRoZSBNYWtlZmlsZXMsIG5vdCBi bWFrZSkgb25jZSB0aGUgbmV3IGJ1aWxkIHN5c3RlbSAoYm1ha2UgcmVwbGFjZW1lbnQpIGlzIHJl YWR5LiBBbmQgdGhlbiwgZXZlbiB3aGVuIHRoYXQncyBkb25lLCB0aGVyZSB3aWxsIGJlIGEgZGF5 IHdoZW4gZWl0aGVyIGJvdGggc2V0cyBvZiBidWlsZCBzY3JpcHRzIGFyZSBzdXBwb3J0ZWQsIG9y IGV2ZXJ5b25lIG9uIC1DVVJSRU5UIGp1c3Qgc3dpdGNoZXMgb3Zlcm5pZ2h0LjwvZGl2PjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBj b2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsiPkluIG90aGVyIHdvcmRzLCByZXBsYWNpbmcgdGhlIGJ1aWxkIHN5 c3RlbSB3b3VsZCBiZSBkaXNydXB0aXZlLiBFdmVuIHRob3VnaCBJIGhhdmUgb25lIHRoYXQgSSdk IGxpa2UgRnJlZUJTRCB0byB1c2UsIEkgYWN0dWFsbHkgZGVjaWRlZCBhZ2FpbnN0IGNvbnRpbnVp bmcgdGhhdCBlZmZvcnQuPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9InByb3Rvbm1haWxfcXVvdGUiPjxkaXY+SeKAmW0gbm90IHN1cmUgaWYg Ym1ha2UgY2FuIGJlIGV4dGVuZGVkIGVub3VnaCB0byBzdXBwb3J0IHRoaXM8L2Rpdj48L2Jsb2Nr cXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5JdCBwcm9iYWJseSBjYW4sIGJ1dCBJIHRoaW5rIHRo ZXJlIGFyZSBlYXNpZXIgcGF0aHMuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj48ZGl2PihCdWNrMiBsb29rcyB0 byBiZSB0aGUgbW9zdCBwcm9taXNpbmcgb2YgdGhlIG5ldyBidWlsZCBzeXN0ZW1zIGRlc2lnbmVk IGFyb3VuZCB0aGlzIG1vZGVsIGJ1dCBpdCBoYXNu4oCZdCB5ZXQgaGFkIGEgc3RhYmxlIHJlbGVh c2UgYW5kIGNvbWVzIHdpdGggYmlnIOKAmGRvIG5vdCB1c2UgdGhpcyB5ZXTigJkgd2FybmluZ3Mp LjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PlllcywgQnVjazIgaXMgdGhl IG1vc3QgcHJvbWlzaW5nLCBidXQgaXQncyB3cml0dGVuIGluIFJ1c3QsIHNvIGlmIEJ1Y2syIHdl cmUgYWRvcHRlZCwgUnVzdCB3b3VsZCBoYXZlIHRvIGJlY29tZSBwYXJ0IG9mIHNyYyBvciBhbiBl eHRlcm5hbCB0b29sY2hhaW4uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGF0J3Mgb25lIG9m IHRoZSBoYXJkZXN0IHRoaW5ncyBhYm91dCBidWlsZCBzeXN0ZW1zOiB0aGV5IGFyZSBhIGRlcGVu ZGVuY3kgZm9yIGV2ZXJ5dGhpbmcsIGJ1dCB0aGV5IGhhdmUgZGVwZW5kZW5jaWVzIHRvby48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9InByb3Rv bm1haWxfcXVvdGUiPjxkaXY+VGhpcyB3b3VsZCBhbHNvIG5lZWQgaW5mcmFzdHJ1Y3R1cmUgdG8g bWFrZSBzdXJlIGVhY2ggY29tbWl0IHRvIGhlYWQgb3IgYSBzdGFibGUgYnJhbmNoIHdhcyBidWls dCBpbiBhIHRydXN0ZWQgZW52aXJvbm1lbnQgYW5kIHB1c2hlZCB0byB0aGUgY2FjaGVzIChhbmQg dGhhdCByYW5kb20gZGV2ZWxvcGVyc+KAmSBidWlsZHMgZGlkIG5vdCkuPC9kaXY+PC9ibG9ja3F1 b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+Q29tcGxldGVseSBhZ3JlZS4gQnV0IGlmIEZyZWVCU0Qg aGFzIENJL0NELCB0aGVuIHRoYXQgY291bGQgYmUgd2hhdCBwdXNoZXMuIElmIG5vdCwgdGhlbiBh ZGRpbmcgdGhlIGJ1aWxkIGNhY2hlcyB3b3VsZCBiZSBhIGdvb2QgZXhjdXNlIHRvIGFkZCBpdC48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkhvd2V2ZXIsIHRoZSByZWFzb24gQnVjazIgd29ya3Mg c28gd2VsbCBpcyBiZWNhdXNlIGl0IGRvZXMgdGFrZSBidWlsZHMgZnJvbSByYW5kb20gZGV2ZWxv cGVycyBhbmQgcHVzaGVzIHRoZW0gdG8gdGhlIGJ1aWxkIGNhY2hlcy4gSXQgY2FuIGRvIHRoaXMg YmVjYXVzZSB0aGUgInJhbmRvbSIgZGV2ZWxvcGVycyBhcmUgbm90IHRydWx5IHJhbmRvbSwgYnV0 IEZhY2Vib29rIGVtcGxveWVlcy4gQW5kIGl0IGJ1aWxkcyB0aG9zZSByYW5kb20gZGV2ZWxvcGVy cycgc3R1ZmYgcmVtb3RlbHkgaW4gc2FuZGJveGVzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ SWYgRnJlZUJTRCdzIGJ1aWxkIGNhY2hlcyB3b24ndCB3b3JrIGxpa2UgdGhhdCwgSSdtIG5vdCBz dXJlIGhvdyB1c2VmdWwgdGhleSB3b3VsZCBiZSBiZWNhdXNlIGRldmVsb3BlcnMgd2hvIHdvdWxk IHB1bGwgZnJvbSBvdGhlcnMgZm9yIHRlc3RpbmcgYW5kIHJldmlldyB3b3VsZCBhbGwgaGF2ZSB0 byBidWlsZCB0aGUgc2FtZSBmaWxlcy4gQnV0IGlmIEZyZWVCU0QgZGV2cyBjb3VsZCBwdXNoIHRv IHRoZSBidWlsZCBjYWNoZSwgb3IgZXZlbiBiZXR0ZXIsIGhhdmUgdGhlIHNlcnZlciBidWlsZCB0 aGVpciBjaGFuZ2VzIGZvciBldmVyeW9uZSBlbHNlLCBJIHRoaW5rIHRoYXQgd291bGQgYmUgdGhl IG1vc3QgZWZmZWN0aXZlIHRpbWUgc2F2aW5ncyBmb3IgZGV2cy4gSnVzdCBidWlsZGluZyBIRUFE IG9yIC1TVEFCTEUgd291bGQgbm90IHNhdmUgbXVjaCwgSU1PLjxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PkdhdmluIEhvd2FyZDxicj48L2Rpdj4NCiAgICA8L2Rpdj4= --b1_GMloHLZAdCOv3wCbUUs2gmIHrUTZ5gDXerucDpu1vg-- From nobody Tue Sep 10 16:06:57 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 4X37r70PR0z5W5S1 for ; Tue, 10 Sep 2024 16:07: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 4X37r63JWmz4vR5; Tue, 10 Sep 2024 16:07:01 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 48AG6v9l025028; Wed, 11 Sep 2024 01:06:58 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1725984418; bh=Vi9k+/xbIWBB3UAbXtnp7BA6jlzBUcdK8Z36W/RrG4c=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=tqdEfO4ip2gGOGUrXLf6Q+kDuR6SFQ/rpFH2wlZKs+qXA0bqR/fPnkng83GvgKNe5 sJD4F/IT/SgM3nB0Ces1ev1P+Z4UHgJe8rMPlZ3nJOXIMxr/08RcHPyUbcsxWRT6Nz O5yq8HQu6OB2rPliKzplHMQzNfFAFUJE5M6cnlgI= Date: Wed, 11 Sep 2024 01:06:57 +0900 From: Tomoaki AOKI To: Kyle Evans Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-Id: <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> In-Reply-To: References: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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-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] X-Rspamd-Queue-Id: 4X37r63JWmz4vR5 On Tue, 10 Sep 2024 10:11:54 -0500 Kyle Evans wrote: > On 9/10/24 09:49, Tomoaki AOKI wrote: > > On Mon, 9 Sep 2024 16:11:40 -0500 > > Kyle Evans wrote: > > > >> On 9/5/24 13:09, Alan Somers wrote: > >>> By now I expect that most of you have seen the long list of new > >>> security advisories that just came out. Strikingly, all were the > >>> result of memory handling errors. And none of them wouldn't have > >>> happened if their respective programs had been written in a > >>> memory-safe language. > >>> > >>> In fact, of all the C bug fixes that I've been involved with (as > >>> either author or reviewer) since May, about three quarters could've > >>> been avoided just by using a better language. > >>> > >>> The real takeaway here is that C is no longer sufficient for writing > >>> high quality code in the 2020s. Everyone needs to adapt their tools. > >>> Programmers who don't will increasingly come to resemble experimental > >>> archaeologists, i.e. people who learn flintknapping to "keep the > >>> knowledge alive". Such people are valuable, but definitely niche. I > >>> for one don't want my career to go in that trajectory. > >>> > >>> To summarize, here's the list of this week's security advisories, and > >>> also some other recent C bug fixes of my own involvement: > >> > [... snip ...] > >> > >> If even half of the energy that has gone into these threads would've > >> been spent on a proof-of-concept rust-xtoolchain implementation with > >> some motivating cases instead, we'd be in a lot better place to actually > >> have these conversations. > >> > >> Thanks, > >> > >> Kyle Evans > > > > Shawn would be working on the PoC now. Let's see how it goes. > > > > The worst is that the work is rejected AFTER it's almost done. > > It's clearly wastes of times/efforts. > > > > IMO if (general) you did enough work that you're angry about it being > rejected, then you probably did way more than you should've for the > stage we're at. If you're rewriting major utilities/daemons for a PoC / > talking point, then you're doing it wrong. Angry or not does not at all matter here. Proceeding wrong direction because of insufficient discussion and consensus is the waste of time. Introducing brand-new language(s) into base is quite a large movement. So my guess is that now is still the time for "brainstorming" before starting actual and effective discussions. > > My guess about this thread is that it is needed to determine what is > > acceptable, what's not, what's needed to be confirmed. > > > > Except it's been increasingly clear even before this discussion fired up > again that a large chunk of the people involved don't have a good point > of reference to even have this discussion. You're wearing them down on > the topic before you even have something to point at and say "Hey, this > is what it might look like" and maybe a roadmap for some of the > low-hanging fruit for things we can improve with it. Again, I think now is still at the time (phase/state) of brainstorming. Non-chaotic brainstorming is in many cases useless. > > Clarifying the above as much as possible before starting the work is > > a good thing. Now we know how many pros&cons exists, and what are > > proposed as possible alternatives. Unfortunately, it's still "chaotic" > > and maybe need some more times. > > > > And discussions are ongoing at forums.frebsd.org, too. [1] > > It already is quite a long thread. > > > > > > [1] > > https://forums.freebsd.org/threads/the-case-for-rust-in-the-base-system.92024/ > > > > I'd go as far as to say that none of this is all that useful until we > can evaluate how much pain we're in for in trying to add this > dependency, but we're apparently more interested in discussing it to > death without putting in the effort to demonstrate the feasibility > through bare minimum integration. What's making it difficult is that Rust is still a "moving goal". No standards yet. So we have some more time until it settles. > It's not very encouraging for future work in the area between that and > also that the request made months ago for something tangible to point at > to discuss further was answered by exactly one person who's already > terribly busy. It's great that he's trying to make time, but you > would've thought from these threads that *someone*, *anyone* would have > made time with all of this demonstrated passion if they really cared > enough to push it forward. Unfortunately, right, maybe. But the direction Shawn noted for his PoC seems becoming better than the start of these brainstorming. > We've been able to use C++ in base in a safer fashion for years and that > simply has not happened, so one has to question the interest in > alternatives. Yes, C++ is already in our base toolchain. But unfortunately, C++ doesn't seem to be treated as memory-safe language. [2] So switching to C++ can cause future (governmental) pressures for rewriting with another language again. [2] https://www.techrepublic.com/article/white-house-report-memory-safe-programming-languages/ Regards. > > Thanks, > > Kyle Evans > -- Tomoaki AOKI From nobody Tue Sep 10 16:13: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 4X37zj4qc7z5W6kX for ; Tue, 10 Sep 2024 16:13:37 +0000 (UTC) (envelope-from ararslan@comcast.net) Received: from resqmta-h2p-547392.sys.comcast.net (resqmta-h2p-547392.sys.comcast.net [IPv6:2001:558:fd02:2446::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X37zh4p2Jz3xtG for ; Tue, 10 Sep 2024 16:13:36 +0000 (UTC) (envelope-from ararslan@comcast.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=comcast.net header.s=20190202a header.b=uX9Y9AqZ; dmarc=pass (policy=quarantine) header.from=comcast.net; spf=pass (mx1.freebsd.org: domain of ararslan@comcast.net designates 2001:558:fd02:2446::4 as permitted sender) smtp.mailfrom=ararslan@comcast.net Received: from resomta-h2p-555031.sys.comcast.net ([96.102.179.206]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-h2p-547392.sys.comcast.net with ESMTPS id o3OGs9oMPfY5Io3UksK96p; Tue, 10 Sep 2024 16:13:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1725984814; bh=X7vE8eAVUqrm06cO9kIeBxEJeX7TjWPXdvoyvWIvkK0=; h=Received:Received:From:Content-Type:Mime-Version:Subject: Message-Id:Date:To:Xfinity-Spam-Result; b=uX9Y9AqZiAeyVtS2gtlWAMdVhBWhBQH5pAMir1n9gs/lcFAh0bd5yjPGuhiu7WQla nD2ym3tHFClre/eM4OocAR+N+LiBOVtKNooxrVk5Htdq4tWeA5vrQmqtBP90wr3ntF gmx2JFNEJnW5qQvmQ7k5LFyN7zzZSZw56Y8VQ0KZNVJFCVv/B8bHOUDvav3AU2blHb M+qybfDj1nQWBditr1rgp8RTO/pc/dqRjJx0atbznZndLHFzd3m0w6UiV2iYhGS9Lc zeEMtDcrek63bEkj0YfFmwdxMzIHjQS9lgyJwobmZBXvuEyeep3Nyk4WemT1OeOMi6 TYUMJv7w2XQMQ== Received: from smtpclient.apple ([67.160.29.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-h2p-555031.sys.comcast.net with ESMTPSA id o3UhsxkLezavyo3Ujshc1w; Tue, 10 Sep 2024 16:13:33 +0000 From: Alex Arslan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 \(3776.700.51\)) Subject: Wrong OSABI for GCC from Ports Message-Id: Date: Tue, 10 Sep 2024 09:13:21 -0700 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3776.700.51) X-CMAE-Envelope: MS4xfHtkTVV0ERBHPT2/YmKeAyYMXtdkMQKW8dE5UrWJ5zE+3uBzUdznrVgXZtcaH/HMiAMS963efnhjadoJXQ+5OwiOnqY6h7guFpStBQ5IottPzSWCN0/U WbJ64jB122xh3qsN+biPsifueJSp9LZDbRMv83lER5it4HWrp0Cb+JnihYA4egmdJ5rZR5TFnfwEv5Uk/m/wogZY6DIWqgE19ZU= X-Spamd-Bar: / X-Spamd-Result: default: False [0.16 / 15.00]; HFILTER_HELO_5(3.00)[resqmta-h2p-547392.sys.comcast.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[comcast.net,quarantine]; R_DKIM_ALLOW(-0.20)[comcast.net:s=20190202a]; R_SPF_ALLOW(-0.20)[+ip6:2001:558:fd02:2446::/64]; NEURAL_SPAM_SHORT(0.16)[0.161]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[comcast.net]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[comcast.net:dkim]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[comcast.net:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[comcast.net]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2001:558:fd02:2446::4:from,96.102.179.206:received] X-Rspamd-Queue-Id: 4X37zh4p2Jz3xtG I noticed that GCC and its associated libraries, when installed from pkg on FreeBSD 14.1 AArch64, have an OS/ABI value of NONE (0) rather than FreeBSD (9), as reported by readelf --file-header. I also observed this when cross compiling GCC for FreeBSD 13.2 AArch64 on Alpine Linux; I assumed it was an issue with the cross compilation setup until I realized that the one from pkg exhibited the same thing. This does not seem to occur with x86_64, neither from pkg nor cross compiled. Does anyone know why this would happen and whether it could be addressed with a patch to GCC? Apologies if this is already known and has been discussed somewhere. Thanks! From nobody Tue Sep 10 17:07:23 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 4X39Bk36Swz5WDPC for ; Tue, 10 Sep 2024 17:08:14 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X39Bk05M3z466Q for ; Tue, 10 Sep 2024 17:08:14 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1725988091; 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: in-reply-to:in-reply-to:references:references; bh=UsdBMQL+CBasyJjWau8ZofgknC2381O1JMo9UIwXQAs=; b=0rJo/NzTFaim/KS0busRWWuFRapeOumLKFvd2Yd4lJtCyx/zJyDDyFHkxiPsbKv1WXhLlR INB2KAKJUnJjFcf6mnnWlKInygN5AY8Mi0tNvQVrrn/KHx/gyv2tZJeX+rSmoZeJ3KsiRS K26lO/9a8GuAHBgfJ7NakwCLd4vjzc3X0S6NUW2ATa/SGxrSSUh2gGNtpTqSXrpf7XoSZo 8mdBlQ484kHfDzT+oWgwucF8e7UrsaTI+OP91Qp5Dzma5ahun/0nvWG/nQmIBOw8eXPEyP vOIldqPIA9JinkS+ljxcfB+Lpuo3F+COJr0zxZEO+WVcYemrDEAlYtJgfRvpGg== Date: Tue, 10 Sep 2024 19:07:23 +0200 From: Alexander Leidinger To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-Reply-To: <202409100805.48A85rho091525@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> <202409100630.48A6UEvY090552@critter.freebsd.dk> <191dae269c8.2805.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> <202409100805.48A85rho091525@critter.freebsd.dk> Message-ID: <5bd1352cab2bfd2e0e3b4f88e76036f0@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_583bc33717d972fa67ab4b409d782917"; micalg=pgp-sha256 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:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Queue-Id: 4X39Bk05M3z466Q This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_583bc33717d972fa67ab4b409d782917 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-09-10 10:05, schrieb Poul-Henning Kamp: > -------- > Alexander Leidinger writes: > >> It was a serious question. As you say "no", I fail to understand what >> you >> propose. Please explain it in more detail, our cognitive picture of >> what is >> meant by your proposal does not seem to match. Or my picture of a >> Linux >> distro is not similar to what your picture of a Linux distro looks >> like. > > Linux is only a kernel, and that finnish dude does not care a hoot > what executable PID=1 might or might not be or do. And a Linux _distro_ is a kernel /and/ a filesystem full of programs, scripts and other files, which cosplays as a complete, high quality (depending on who you ask) and usable, UNIX system[1], on which you can run the programs you want/need/care for. I might add, that a linux distro is also a set of packages which form the above. And by telling FreeBSD is ports you gave me the impression, that you want to say that we should move away from src is base and to move to "a set of packages handled by the ports collection". I also understand it to blur the lines between pkgbase and packages from ports and make it possible to install parts of the basesystem from ports... which to me looks like what I just described in this paragraph as a linux distro. > FreeBSD is a kernel /and/ a filesystem full of programs, scripts > and other files, which cosplays as a complete, high quality and > usable, UNIX system[1], on which you can run the programs you > want/need/care for. > > Poul-Henning > > [1] Because somebody somewhere still defends the trademark. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_583bc33717d972fa67ab4b409d782917 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmbgfNkACgkQEg2wmwP4 2IbHoBAAoaa89+Gx9d3vTFU4pH2YNeDLLL2eqSYSBXf9EesdWz4tR4D5bRk5pKxh KD2M+142GF9T9SMhLMlpGSXvEoP81Vx3eP/peN1j461GtXznKWIIi2EMKAXFCibE MWY1nTJu2BhCh1OqxR0anOGJ7xcwjp1+PYtfgIcdzErfTMp4bn0FPgq0IiPF4WxJ vrcozTUlAYmXiHn+iKz4Ewp1674cqWEe1g7CkCJyTWUgecnuZoMmu6pNbufwX3La 63pldVrSjqT5ASUzVJbuS3Qp72lLpjQxN5qw3N1kXEFlhxx2RTXcepPANL2GgRgT YSSJUjAIEIm6K4Ar2hsqRS6UWAXNq+XMcis3+KRgQ7Mp2KU4EM3PU1bgd0LO3Gmf UMui/wr2Y2dEYow1sMWSu2YW+/rJTydbCa3oLlQI+A7uNVd7OLR00x8ocvzHN5Ef ZsW4cMSpS8t5btBJyIApz7uryCle9LUtDwTTqV4+irjHHvDiIXQH3LFjK1b1QR1w YsV4GhribQtX5MZ98IHT0X5pYo+qE0zPk+7yEjOE+bEPsvtMCzthn6KkC7mG56bV x9hNezguQ8MuMs30TQnWYB0KjkzDzemPZh5OQorVVRC0XxrCMCjz2g+x1+8cRQov T8WYxYHfy6FpGsNNUP9hEunIB5ZB3A6LDKTSdLrRCOt6K1qHgpY= =dWg3 -----END PGP SIGNATURE----- --=_583bc33717d972fa67ab4b409d782917-- From nobody Tue Sep 10 17:35:01 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 4X39pd1zpDz5WH7S for ; Tue, 10 Sep 2024 17:35:53 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X39pc3gNfz49nH; Tue, 10 Sep 2024 17:35:52 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1725989750; 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: in-reply-to:in-reply-to:references:references; bh=LlCpHHNR+YYxJCZSt23qLIfc0U+CaptRUuGCAcu+fyw=; b=IL9vS4VNbYGzu4R3x82xXjYLt+Lpr6dXlbaiEcMg2fasj2Nrk1Th4FOOc9QQmz7cGUghXv CYGsq73R0S9nZxUwcht+qxaRuNW3S81mGmz3K//Lbb3S+hwFJCiC5NP/Ec9cG3YgYTVX/3 pKjh5kH/3quep0E1xhctWvaN0ODygFklVkrOReOFe8+FTDEJhLKfIoO2h405Tum/EeTDGr 3oUrPYZTW17InQ3D6Bdl39HsAAUzF8zQGX23ziRLhnoCiLPNfkRtkMefgGolXzUGcojfjy eZht1kIwIApHSUAM88Cg2bIIQ3+9XID6654XnJh0hq0wCLdISm43cvzvmNh6sw== Date: Tue, 10 Sep 2024 19:35:01 +0200 From: Alexander Leidinger To: Olivier Certner Cc: Poul-Henning Kamp , freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-Reply-To: <2372745.viN5riZIyJ@ravel> References: <202409031532.483FW0If007252@critter.freebsd.dk> <2611284.jQUcPV6jne@ravel> <202409091859.489Ixdia086264@critter.freebsd.dk> <2372745.viN5riZIyJ@ravel> Message-ID: <1fc46e4362bd11816d63027ec8cb8f09@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_69c8eedef1f663d2e98b9ba660ea59f6"; micalg=pgp-sha256 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:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Queue-Id: 4X39pc3gNfz49nH This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_69c8eedef1f663d2e98b9ba660ea59f6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-09-10 11:05, schrieb Olivier Certner: [your point of view] > This is only my view, but I have the feeling it is implicitly shared by > many. I'm very interested in hearing whether it is more or less > conform to reality and what people think about it as of now and for > FreeBSD's future. I share a similar point of view. The difference is ... below. > That said, I also think this debate is mostly independent from the > possibility of building FreeBSD without having to rebuild a full > compiler every time. It is however relevant to the proposal of > removing LLVM's code from 'src', as this has bad consequences > (according to the principles I listed) that we probably can, and > should, remedy with tooling, although, as the saying goes, the daemon > is in the details. IMO it doesn't hurt to move the toolchain out of src, as long as we have a port, e.g. freebsd/toolchain-for-version-X (or whatever we want to call it), which is buildable on all supported release we want to support the build of FreeBSD-X. As we support to build FreeBSD also on Linux and OS-X, we would also need to have support to make it not too hard to build said toolchain on those systems. And I go even further, I would not only mind to install a port for a compiler, I would also be ok to install a port to install a tool which handles the build (replacing make in src). I would be ok to run "pkg install/update X Y Z" to be able to do "cd /usr/src; do_build freebsd && do_install freebsd". I fully agree that it should be easy to build the base system, to do what we do today, and I think is would be beneficial if apart from "make installworld" if we could also update via "pkg upgrade". I think we could provide what we provide currently while at the same time reap some benefits from having those parts managed in ports. IMO there are a lot of benefits with such an approach, be it system hardening, compile time, and more. I would not want to move everything to ports (toolchain yes, build system yes, now that we switched to DMA: sendmail yes, openssl/kerberos no -> too much integration with other parts), but I would not mind having a ports-like approach for src separate from ports (I don't know if pkgbase fits this or not, I haven't looked at it, but if I can define a pkg repo for base and populate it from e.g. "make pkgrepo DESTDIR=xxx" or similar and then just need to run pkg upgrade that would be nice). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_69c8eedef1f663d2e98b9ba660ea59f6 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmbgg1QACgkQEg2wmwP4 2IZz2BAAiXiD5ZAL2Gloc2AZgEKpd7jQqAc3Tx52BadmNt7W+ru/V2Lduckpp9KS iWP8nVOepMzyZpQVH2hV+Uv0Ql9OAowoscsLOlNEA+hwRluzHaBf/P11Fv7wRT50 DSw9Ygar1e2BtYNk7BkjGADcH5XJ29AgvzLepKnONYTShFC2kpzpPtBnuDTHvRN0 GuM8kDoeWV7kxrB/wVvI8F/kx+HysaEdfQog/2RcWN2/ovv7mXbdzlyhKgCM5WA0 Tt5fvmVCMnaSj0gbqcLvcgiekRECxgf3UEwwCUbhDBVhqa3dIp3Dx9LM4i2nCnzz 8+IMTUOYHVVZkRLh3EzMmuugXOBmC83Fo9I7moHtoQ3nttkS2mMIgX+PHLTNxgS4 TPjAClkhBgce7Hfgc2PshBtJ4rcVj8ocjpC3n1DbnUN7ZYq0NCFhjXAS4nhV0NFZ XXHiCWOXgBqB1srx/U3P17B/N49EXWOw6K60/xWgx7BHbkgsvW0a2gKn04DrgOKz uwo/KVd54yOTKulsy8Lz+9Vg4IvFazTXmMHynnBxEn2YGfivwxNEGyqE3aMGQOwe WlfnRci0orwF3OIpSFxJsJNmXw47bY5GKz/8D4dxEPizO8v4Fp09uDL6uqY+zVSd 7BUdyC9ywyBzZbhZyH2K7CxtyE7l0SNvllhIKqBOu6p5riuiXr8= =/63J -----END PGP SIGNATURE----- --=_69c8eedef1f663d2e98b9ba660ea59f6-- From nobody Tue Sep 10 18:17: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 4X3Bkb1W9Jz5WMfS for ; Tue, 10 Sep 2024 18:17:27 +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 4X3BkY5zxKz4KlY; Tue, 10 Sep 2024 18:17:25 +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 D5B7089284; Tue, 10 Sep 2024 18:17:23 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48AIHLMj096285; Tue, 10 Sep 2024 18:17:21 GMT (envelope-from phk) Message-Id: <202409101817.48AIHLMj096285@critter.freebsd.dk> To: Kyle Evans cc: Tomoaki AOKI , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-reply-to: From: "Poul-Henning Kamp" References: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> 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: <96283.1725992241.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Sep 2024 18:17:21 +0000 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] X-Rspamd-Queue-Id: 4X3BkY5zxKz4KlY Kyle Evans writes: > We've been able to use C++ in base in a safer fashion for years and that= = > simply has not happened, so one has to question the interest in alternat= ives. Have you already forgotten groff ? We used to have groff in src for the man-pages. Groff was written in C++ and since it was a "bootstraptool", any breakage was high visibility. If you look over the commitlogs, you find lots commits like: commit 504de8da7e199124a8c798b87d22e86bd57adaea Author: Marcel Moolenaar Date: Wed May 22 01:04:42 2002 +0000 = Don't build doc on ia64. No groff in sight. and = commit 2d15e757812c1653497b1079e95ef260dc3db1d6 Author: David E. O'Brien Date: Mon Nov 8 19:00:22 2010 +0000 = Back out r214961 for skeleton.c -- it broke the groff build. and many more, until we finally had enough: commit 738919c0391b99947b758d85f6a8636be1886fbb Author: Baptiste Daroussin Date: Wed Jun 7 23:00:34 2017 +0000 = Remove groff from base = All manpages in base are now compatible with mandoc(1), all roff docu= mentation will be relocated in the doc tree. man(1) can now use groff from the = ports tree if it needs. = Also remove checknr(1) and colcrt(1) which are only useful with groff= . = Approved by: (no objections on the mailing lists) I dont know or think that C++ was the root cause of all this trouble, maybe even far from, but I think we got vaccinated against C++ in src just the same. Poul-Henning -- = 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 Tue Sep 10 18:23: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 4X3Bt35G1Qz5WNP0 for ; Tue, 10 Sep 2024 18:23:55 +0000 (UTC) (envelope-from kevans@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3Bt34MV8z4MHx; Tue, 10 Sep 2024 18:23:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725992635; 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=dBu/g2lta+TPSWR4rzmd90f/+0eXRA+rYdvfXDDk+1k=; b=SuIs9ED5gy9Gvq9jQmd70ZO373ENcK0K+TixGKZyUx5ZtYu5Qdh3FG8b1J7art42TbkGdl I0xlE8+ihFaeS4zSm6LRqfVjI6mvip4v3PM87IAxG6rHgMILh+cgWz1F87WufoKB9X2JvI CICgyrdbufIRPwIu1iTk/br258djdL7b/5aBLQ5sI4fv4gmok6GteR6F8hj7xwrj3XkWzM WGaXvfbNmTzFQNKNcvZ28W8+Pu5tjEvEEWdfDiNRa61RvQOyzNXTHYSV1om1KWhhwHvFMg kDFMqYhng6g8XxISw8LMPtLEwwXuf5hG4iK6nq9ERDf5aRYj9FbEYuWzutasCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725992635; a=rsa-sha256; cv=none; b=Z6JaleW8FCPPmF83c6ZxUWHbRfBbxiJdDRZL75/hczCP/+bcXzqeaYO1vmPq9pNTHzGZ0X 7N5UdlQlQSSVSDEHHHadqs+P4vDWsoVjEbdEHGRepMfgTVDs5JJ/LhJ+PWtZPwFhO9Er2w uNZ8Q1M5FB5aliMVyHuNAmIV4PZUQKymw+h9pRhhbMdUVXmtxUTMdatIOr5cpjRepJsBgj TnZHnbjgOCaCljbRLM0U0oxQdq3j9s33adXd3fy8wngzNx0Pz/O9XYPOlVjH50xgJBR9TU x52vA4WuWSwtXqmekm8DewqAS2NOow+0ykih0Fr/G+0kdDN1GX8oJLkevMCqpQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725992635; 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=dBu/g2lta+TPSWR4rzmd90f/+0eXRA+rYdvfXDDk+1k=; b=C+4FH9coPEr2aZFvmPQ3rAOn2XIBOq73puQQpd3VesQZl2oePv8QkPGN4v2pQ8utmCxIS6 GaM+ywPSS/AdEpucBBanmmooWN3t/ldUFmPL8QhuhIQ/gauYEGvElD3SiQEREsx+qOuCjR zEenOE36c3y5/NqRaBYX1TcjE+sZHrNkh84SMgpfUsOxFxvoRUF1XIGnWjAtBhM1sNVDyU urUA8nj6E2BNfeoUKd49xR3N9fZocLyPGJCytziN1v+f1CyKexD0m6J0bmi+03UdoIBnzK Yc8D9fri3Vywi03ZrTSyf4TQx4YaZmJzo3eX4YN6f1/Bx3JUhvnjwpzweyUD6w== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X3Bt31pYWzY4G; Tue, 10 Sep 2024 18:23:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Tue, 10 Sep 2024 13:23:52 -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 any system) To: Tomoaki AOKI Cc: freebsd-hackers@freebsd.org References: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> Content-Language: en-US From: Kyle Evans In-Reply-To: <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/10/24 11:06, Tomoaki AOKI wrote: > On Tue, 10 Sep 2024 10:11:54 -0500 > Kyle Evans wrote: > >> On 9/10/24 09:49, Tomoaki AOKI wrote: >>> On Mon, 9 Sep 2024 16:11:40 -0500 >>> Kyle Evans wrote: >>> >>>> On 9/5/24 13:09, Alan Somers wrote: >>>>> By now I expect that most of you have seen the long list of new >>>>> security advisories that just came out. Strikingly, all were the >>>>> result of memory handling errors. And none of them wouldn't have >>>>> happened if their respective programs had been written in a >>>>> memory-safe language. >>>>> >>>>> In fact, of all the C bug fixes that I've been involved with (as >>>>> either author or reviewer) since May, about three quarters could've >>>>> been avoided just by using a better language. >>>>> >>>>> The real takeaway here is that C is no longer sufficient for writing >>>>> high quality code in the 2020s. Everyone needs to adapt their tools. >>>>> Programmers who don't will increasingly come to resemble experimental >>>>> archaeologists, i.e. people who learn flintknapping to "keep the >>>>> knowledge alive". Such people are valuable, but definitely niche. I >>>>> for one don't want my career to go in that trajectory. >>>>> >>>>> To summarize, here's the list of this week's security advisories, and >>>>> also some other recent C bug fixes of my own involvement: >>>> > [... snip ...] >>>> >>>> If even half of the energy that has gone into these threads would've >>>> been spent on a proof-of-concept rust-xtoolchain implementation with >>>> some motivating cases instead, we'd be in a lot better place to actually >>>> have these conversations. >>>> >>>> Thanks, >>>> >>>> Kyle Evans >>> >>> Shawn would be working on the PoC now. Let's see how it goes. >>> >>> The worst is that the work is rejected AFTER it's almost done. >>> It's clearly wastes of times/efforts. >>> >> >> IMO if (general) you did enough work that you're angry about it being >> rejected, then you probably did way more than you should've for the >> stage we're at. If you're rewriting major utilities/daemons for a PoC / >> talking point, then you're doing it wrong. > > Angry or not does not at all matter here. > Proceeding wrong direction because of insufficient discussion and > consensus is the waste of time. > > Introducing brand-new language(s) into base is quite a large movement. > So my guess is that now is still the time for "brainstorming" before > starting actual and effective discussions. > It's really not a large movement, though, to get the bare basics done to evaluate a new language. As stated repeatedly, we don't need the toolchain for a new language in base and the new language wouldn't be in the 'default on' path. That's not exactly a huge commitment, then you talk about where it needs to go from there (preferably as part of pre-commit discussion, but also ongoing as you want to try and expand). > >>> My guess about this thread is that it is needed to determine what is >>> acceptable, what's not, what's needed to be confirmed. >>> >> >> Except it's been increasingly clear even before this discussion fired up >> again that a large chunk of the people involved don't have a good point >> of reference to even have this discussion. You're wearing them down on >> the topic before you even have something to point at and say "Hey, this >> is what it might look like" and maybe a roadmap for some of the >> low-hanging fruit for things we can improve with it. > > Again, I think now is still at the time (phase/state) of brainstorming. > Non-chaotic brainstorming is in many cases useless. > We'll have to agree to disagree on that, I don't really see much productive vs. slightly different phrasings of the same arguments. > >>> Clarifying the above as much as possible before starting the work is >>> a good thing. Now we know how many pros&cons exists, and what are >>> proposed as possible alternatives. Unfortunately, it's still "chaotic" >>> and maybe need some more times. >>> >>> And discussions are ongoing at forums.frebsd.org, too. [1] >>> It already is quite a long thread. >>> >>> >>> [1] >>> https://forums.freebsd.org/threads/the-case-for-rust-in-the-base-system.92024/ >>> >> >> I'd go as far as to say that none of this is all that useful until we >> can evaluate how much pain we're in for in trying to add this >> dependency, but we're apparently more interested in discussing it to >> death without putting in the effort to demonstrate the feasibility >> through bare minimum integration. > > What's making it difficult is that Rust is still a "moving goal". > No standards yet. So we have some more time until it settles. > That doesn't stop anyone from doing the basic xtoolchain integration. > >> It's not very encouraging for future work in the area between that and >> also that the request made months ago for something tangible to point at >> to discuss further was answered by exactly one person who's already >> terribly busy. It's great that he's trying to make time, but you >> would've thought from these threads that *someone*, *anyone* would have >> made time with all of this demonstrated passion if they really cared >> enough to push it forward. > > Unfortunately, right, maybe. > But the direction Shawn noted for his PoC seems becoming better than > the start of these brainstorming. > > >> We've been able to use C++ in base in a safer fashion for years and that >> simply has not happened, so one has to question the interest in >> alternatives. > > Yes, C++ is already in our base toolchain. > But unfortunately, C++ doesn't seem to be treated as memory-safe > language. [2] So switching to C++ can cause future (governmental) > pressures for rewriting with another language again. > > [2] > https://www.techrepublic.com/article/white-house-report-memory-safe-programming-languages/ > > Regards. > >> >> Thanks, >> >> Kyle Evans >> > > From nobody Tue Sep 10 19:04: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 4X3CnC4Lk6z5WT67; Tue, 10 Sep 2024 19:04:47 +0000 (UTC) (envelope-from alnsn@yandex.ru) Received: from forward501d.mail.yandex.net (forward501d.mail.yandex.net [178.154.239.209]) (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 4X3CnC1c43z4SDZ; Tue, 10 Sep 2024 19:04:47 +0000 (UTC) (envelope-from alnsn@yandex.ru) Authentication-Results: mx1.freebsd.org; none Received: from mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:2d4c:0:640:de18:0]) by forward501d.mail.yandex.net (Yandex) with ESMTPS id 5D0AF608E9; Tue, 10 Sep 2024 22:04:43 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id e4oBfACoCKo0-nXAlgKWZ; Tue, 10 Sep 2024 22:04:42 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1725995082; bh=3E8FQYsPiOVQqyKRmki79OX4khwQPIv/cFy4p19RpQs=; h=Message-ID:Subject:References:To:From:In-Reply-To:Cc:Date; b=AstHlPfEJDQ59hdwaIZQTCj4D1L3wuaW+vTKo8Y3AZ4vgvq0nOYkvxFbFqOrDzo3V KxGtNabuZWlviT0cvlnfeGzE/S7nIasiIE7yMOfNdfVmzc1I1mTYL+FzC7xbfadNJF /e5akAtRl++SrhgB3XJcVtzTVcoEVOgdeBWXFKJY= Date: Tue, 10 Sep 2024 20:04:40 +0100 From: Alexander Nasonov To: Poul-Henning Kamp Cc: Vadim Goncharov , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <202409101224.48ACO7oj094058@critter.freebsd.dk> <20240910160915.55ff579b@nuclight.lan> <202409101432.48AEWu1q094702@critter.freebsd.dk> 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 In-Reply-To: <202409101432.48AEWu1q094702@critter.freebsd.dk> 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:200350, ipnet:178.154.224.0/19, country:RU] X-Rspamd-Queue-Id: 4X3CnC1c43z4SDZ Poul-Henning Kamp wrote: > A) How powerful do you want the downloaded bytecode to be ? ... > There are basically two possible answers to A. > > Either the downloaded code is "real", which means it can include > loops, function calls etc. or it is a "toy" which relies on > Brinch-Hansen's "all arrows point to the right" argument to prove > that it will always terminate. BPF can be easily modified to have functions and calls but it will increase worst case execution complexity to quadratic and the stack growth will have to be watched closely: - always jump forward (within the current function), - always call backwards (outside of the current function). Backward jumps (within the current function) can be implemented with some kind of slowly closing door. For instance, in packet filtering, the first backward jump disables access to the first byte, the second backward jump disables access to the second byte, etc. In general, it will require a special counter but BPFJIT compiler should be able to spot simple loops that process at least one byte on each iteration and minimise runtime overhead. > ... > The answer to that is that you can write them in /any/ programming > language you want, as long as the interpreter for the resulting > (byte-)code an spot attempts to jump backwards, and refuse to > do so, if so configured. I guess it will work for a simple single-pass interpreter that generates bytecode as it reads source code but anything more complicated may reshuffle bytecode and some forward jumps may become backward jumps etc. > And that is why I say: If we're going to do this, let us do > it with Lua: It's already in our tree and it will do the > job nicely. Lua is a good choice, IMO but we likely need a subset of Lua (e.g. no metatables, no C or paused GC with a periodic lua_State rotations to collect garbage). Alex From nobody Tue Sep 10 19:41: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 4X3Dbg2f3yz5WYHY for ; Tue, 10 Sep 2024 19:41:35 +0000 (UTC) (envelope-from olce@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3Dbg2B35z4XLf; Tue, 10 Sep 2024 19:41:35 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725997295; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P+UoNGj6dZqpJKNv4Z6lY+rdbNhxUAXladIIALl2LFU=; b=n4BpSNgMMqB+rRlovwhAveWxblO5a6QK+Lo6c6eE0iEjG+WXN9/GUkbmTMapReBg2KXCHe Kv1xxlicZag7y9SlZLjUfmaUmuRTvaxdq3dpaTFrQcru3obAje5IlfhOKxXEz3GYoVt/7g dROU5gK+NSHVxc3xawlv/JYR92QztvXUmxa0tL0JT1a/nfcIHUcHutG5dLc0Fu/wuUkuhX vm2nl6TYDmNze15HRjxOizB9a9vAs4dNIZiSxhyXMf7FDFjHnZq7SIcvABKvJ5Z1ZUWvXu GZ66q5N9nbc+W6dm8C+n3taS1ySQY0FQ+z4meALkrTmLxSZjpXsG+FK/cHNflQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725997295; a=rsa-sha256; cv=none; b=cPgwozyTOLqZl0rfItn30Dk/F2N+6jl8hHHBSSEVuOQy/Zv5JLe7EW/eTDA0N00d9luBAO yEwgjA4qxrx8zkrhq5oykpwvj7kLTwv2HykJWhLcY9N4370m8VyquO1eAl/vLvTWnQbIIO KIjjYc32FVLRoJtQqRoNVR5nMBZ+hkiPbT2zrLqZwKBTsILdwDh4SjfnlESGX39BYIn7lO I10J/2O5cSlBOIj4C/js2hGA+2UmzcHfJNFbpZVjcg8LsZsa7dpwMQSjqwdLYYyuMBOwZ1 /P+cBOvRiuubIZeKmpjmgUnsFXyLj5RlzAYv+CJwEQZzEl3XToZ3Ii222wU/Fw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725997295; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P+UoNGj6dZqpJKNv4Z6lY+rdbNhxUAXladIIALl2LFU=; b=TFFr2Vy4PpPbyK+Gor7O6jcHZVKhXKqyebzxzWCYRcUEQZWcBksQIG5wagWeuruvPAfoOW 1ZvJILCpHdixPe8uby8PskMQ7QHok5kcn/VPUPsUIEGkiUgFqkkieswfPTatMExLxqMUQu nI3I8QOjPuYIDt1ujVKRfFV1N8+wkgDR9rHkDaQ1NV4LI4swh1QFT+Ntuu3KAJRtuAmH1k 1kprBz2NIOpKcydNqr2F6PJgMta/v2e3EBW4AQi35fPQXVWXmlmi7l+Y/10Ob5/uSK6WP3 Ifc3D3GzAcTrMjBPz0tvklhhLJqMaSibKs/NTwXhqgFZj5u5tby/7wkxdce9Zg== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X3Dbf6kcSzXGK; Tue, 10 Sep 2024 19:41:34 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Alexander Leidinger , freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Tue, 10 Sep 2024 21:41:27 +0200 Message-ID: <6292298.r39cKavRk3@ravel> In-Reply-To: <1fc46e4362bd11816d63027ec8cb8f09@Leidinger.net> References: <202409031532.483FW0If007252@critter.freebsd.dk> <2372745.viN5riZIyJ@ravel> <1fc46e4362bd11816d63027ec8cb8f09@Leidinger.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; boundary="nextPart1823591.ysvEpUY7yo"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1823591.ysvEpUY7yo Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Date: Tue, 10 Sep 2024 21:41:27 +0200 Message-ID: <6292298.r39cKavRk3@ravel> In-Reply-To: <1fc46e4362bd11816d63027ec8cb8f09@Leidinger.net> MIME-Version: 1.0 > IMO it doesn't hurt to move the toolchain out of src (...) > > (...) I would not want to move everything to ports (...), but I would not > mind having a ports-like approach for src (...) To clarify and be sure we are on the same page, I also don't mind what you describe *provided* there is appropriate tooling to easily: - Get all the code part of base, and not only for building it. - Navigate its history, both for code changes but also integration in base for upstream projects (upstream history is nice, but not enough). In other words, I insist on having the same ease of use that we have today with everything in a single repository. Being able to just build base *is not enough*. Else, moving things to ports is going to cause important pain for several use cases such as code inspection and auditing, collaborative maintenance of code moved to ports, understanding why/whether some changes have impact on some components, system consistency, etc. > (I don't know if pkgbase fits this or not, I haven't looked at it, but if I > can define a pkg repo for base and populate it from e.g. "make pkgrepo > DESTDIR=xxx" or similar and then just need to run pkg upgrade that would be > nice). I haven't used it personally, but from what I read, I expect what you describe to be exactly its main supported use case. Thanks and regards. -- Olivier Certner --nextPart1823591.ysvEpUY7yo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmbgoOcACgkQjKEwQJce JicPsA/+KSd3vIZKhk+jIZWnypwgypLSmh85LoSsALRJcEO7Qi1v/kiAe2RuD9Gr y5iGzs3KChihX+91X7lm8WDQttG5fgOliJ/pqqrHSRArs2fWp0wBd5o7XJ5K4iKO TinpY77gsBoTHnBFNwWmr5C/SgP0ZpOmWqXN5ApWDAuMdQ7tfVo4FV8IwNNYwoOn i17NVYSQEemtQKR5Jqan5/pFhi0YAV0bgiTSEcIu6t0fkJ+UIuZ5Q7lAvCdLD6pe x5rkwpoo0EtC6UY5bqqVL8IPK8/alRvsY9WtPsH4BHGg42SZaVKhqMnTq8bRqjSb gY198LkXstiAULecjCgVNNtmmwO2Gfx4PW6KwOeqbKGjkbj8GLfRnTFheb85tMp8 GSsBoICZphqeyC+usP8iOmGdkSiTe0RHuZAbBPViyFaYiJoX7Q4sUPjlaaHc/bSj JcMGRssDMnhwITwPS5w6FTFxVUz3j/1HDJUt3m/JR3gMSRbGd0CPCcjdzIGmcKiR IIb94TXoTbrC0+nazKInX2l+3UjJ3fDF0hujWEzUuQ9y2kmn8EOnuZppRN/ZXjfg UWpT+a28ZAJJw3Y93cF6GVW27nD0YFed4nDFf8znNsm0fANEhc14TeLqCssEVmrI aSanZsXG9O2hCPfjvE4305kLjjoXWQj9VaYUyXY3P48T8vNbzJ4= =ubsq -----END PGP SIGNATURE----- --nextPart1823591.ysvEpUY7yo-- From nobody Tue Sep 10 21:06:08 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 4X3GTV6GfKz5Wjfs for ; Tue, 10 Sep 2024 21:06:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3GTV4cKHz4jFV for ; Tue, 10 Sep 2024 21:06:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f41.google.com with SMTP id ca18e2360f4ac-82a238e0a9cso279884139f.3 for ; Tue, 10 Sep 2024 14:06:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726002381; x=1726607181; 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=ok14TRDWZyHCZBmIyQj+mcOIdBb8sntooKRhQy6dGZ4=; b=ibyQx3169sa86IXeUO6VAHhDzt1J0HcXTvjlWtQyT73OptvScKVOixHnhuFTqYzVJP cWcF4vQjJGFEyAjZ9mLYEpEOZlyhYS5D3HOPBghkwBj+aMkHoR65D8QP2yW0hI2ou+9k 7oVNU/eE738XTFzwciQqh4fGV9w0DwKtz62NLgeoS2siIcyJUv61rUUjasTBT7C8d6dl LACqDn+fBdmExLSUDqpIm3JEQR1GhYmCcOhJormwKr3QPWGMQXNkb3roJ6Z+uarCrSZh nMCppI0IPF/kpqJ0MaSm/RIkEM2ZDg5begRzZ1KIEf/mfN3TptMWlx3DeZBIHfmKdLee /b+w== X-Gm-Message-State: AOJu0Yyl8uxuXFDjRUBio3IDsxy5h2aLULvdmLjgnAzdzSDZ6OQdhiiM aGVnArqcUP4ERLtICxmQChve3Ioy9J8Tfrh6OA8/OBzIQil8nYOZsTUNlBWemYHt3sU+FVyTGAR R5PhLNuWHc84/GB7DhSxRQhXGWvBFaw== X-Google-Smtp-Source: AGHT+IEz+HZQwvKEXcC0zW33XTrHryQgzIppesY6V/PXgE3bDLPo1WQENQaF+rmvXrkU6bugpUedtg8u2MRqI9nf2TQ= X-Received: by 2002:a05:6602:1648:b0:82d:d07:daaa with SMTP id ca18e2360f4ac-82d0d07db9cmr13970939f.4.1726002380863; Tue, 10 Sep 2024 14:06:20 -0700 (PDT) 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: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> <202409101817.48AIHLMj096285@critter.freebsd.dk> In-Reply-To: <202409101817.48AIHLMj096285@critter.freebsd.dk> From: Ed Maste Date: Tue, 10 Sep 2024 17:06:08 -0400 Message-ID: Subject: Re: The Case for Rust (in any system) To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" 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:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X3GTV4cKHz4jFV On Tue, 10 Sept 2024 at 14:17, Poul-Henning Kamp wrote: > > I dont know or think that C++ was the root cause of all this trouble, > maybe even far from, but I think we got vaccinated against C++ in > src just the same. We have Clang and friends, devd, zfsd, atf and kyua stuff, dtc, pmc tools, config, users, and rs as C++ in src. At least some of these started off as C programs. From nobody Tue Sep 10 22:12: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 4X3Hxt0Zhpz5TfHl; Tue, 10 Sep 2024 22:12:34 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) 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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3Hxs4cWVz4sWw; Tue, 10 Sep 2024 22:12:33 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2f025b94e07so50790821fa.0; Tue, 10 Sep 2024 15:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726006351; x=1726611151; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=VQklzI5f+UhE/4HXXB6RHKU+J3Qo/ASreqA6+yuuQMA=; b=Gt0Mxk0EpZN59+KWga6Y85o6QJxPxRtDzMbNCHMxOpiO95o/UbDHjCCMYrjGqeIu7I 6EVZDtyxrXexv/aKlQBVKWCfvz+YmoJMuTk20Iuz80tjI7KS3diMT+yDBZghH4SlK6+0 7vNouIrF8WU3PrIOuDzHKfZyudU2vMPdiEyRFBPVtm8NJPkCuww9BZKwlnm3zsL6eTiQ lJHMWVFumb9aqhaHr5oxWd/UKf79Tk4pu+kDoLVi5p2SRacCxoGBztvLqGmCwqVUpQ0f 41p8A6rARrO8fy/7iFLPQ2EX57k+xDRpUh8msj8o9zwdCSa5JvamrHhJDzCM8yAeevZE aG4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726006351; x=1726611151; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VQklzI5f+UhE/4HXXB6RHKU+J3Qo/ASreqA6+yuuQMA=; b=FrWGWSlI4V3C/Y5L7RHRSZ88lRJqCqQ44c8jPsOjgh/JlTg8/cjjy2vTpr2xwqWqLW 1xqlqDpWV8357RJycWFzS5yTsQEwXDi2pVcXZv3LHcoUeEz4lX/VmTsvaqZFysW9gSTV s5ID/WErJj0fR6yBT6+ZsCoNBG1Rl6/osSwKfp06Ov0alR/GWqNXEKGSeHE+FkipS3pn NMVpl68rsT1wuu+GeEbHVukVud5Ri6Fie5o5U3/97UaoqieywVsiK44zx4jeh4eAVsH1 rNUplXNXShVR7mYYN4qwixMgkpRuBPx2FwxKmLaxHdMsURLY4dH1MIiD3/zjiSj/azNP vkEA== X-Forwarded-Encrypted: i=1; AJvYcCUXyhl85uihZ4xjmNCvxgw17NL/6on20C7C+DJyGBs/HvOzIvL5HVYPlh3vj35o3OzEEpxXp4Omsr9pQeeCSSwe@freebsd.org, AJvYcCX+g+SUU4VBC6hqQRhaoGw/K6YNNGZyKCWdY1y2RTiuZJsKefVZ9xAuO2gIoh7r1lk6tT17vBviGrqpC+c=@freebsd.org, AJvYcCXfLs0EFHjn8KXuPPelq99ALzOXy1TOAcVLhxFuESmpvVFWMxBuEj1iqCkteUYCV+liXHKVGslHkagEidc=@freebsd.org X-Gm-Message-State: AOJu0YzSy9AGJhXKHBVk7pjrgB96buI3IoxqhmPrxrzqoyTyXXWMTQvZ o/O1jYKXV2n9QZHMqWoObZ31hPPniboiPuYefbUctmApXTQPewTDnWqsHZjW X-Google-Smtp-Source: AGHT+IHV0riUgCN7WGyLkuUPPbvyKnE92FLj4+LbmsITqsigNsHw13jPjtefeDp//sUQyk2pW6hqNA== X-Received: by 2002:a05:651c:1a0b:b0:2f7:6653:8044 with SMTP id 38308e7fff4ca-2f76653812dmr52539331fa.20.1726006350849; Tue, 10 Sep 2024 15:12:30 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f75c07cf5esm13208111fa.86.2024.09.10.15.12.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 15:12:30 -0700 (PDT) Date: Wed, 11 Sep 2024 01:12:28 +0300 From: Vadim Goncharov To: David Chisnall Cc: Poul-Henning Kamp , tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240911011228.161f94db@nuclight.lan> In-Reply-To: <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-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] X-Rspamd-Queue-Id: 4X3Hxs4cWVz4sWw On Tue, 10 Sep 2024 15:58:25 +0100 David Chisnall wrote: > On 10 Sep 2024, at 14:44, Vadim Goncharov > wrote: > >=20 > > I am not an experience assembler user and don't understand how > > Spectre works - that's why I've written RFC letter even before spec > > finished - but isn't that (Spectre) an x86-specific thing? BPF64 > > has more registers and primarily target RISC architectures if we're > > speaking of JIT. =20 >=20 > No, speculative execution vulnerabilities are present in any CPUs > that do speculative execution that does not have explicit mitigations > against them (i.e. all that have shipped now). Cache side channels > are present in any system with caches and do not have explicit > mitigations (i.e. all that have shipped so far). >=20 > Mitigations around these things are an active research area, but so > far everything that=E2=80=99s been proposed has a performance hit and sev= eral > of them were broken before anyone even implemented them outside a > simulator. >=20 > > And BPF64 is meant as backwards-compatible extension of existing > > BPF, that is, it has bytecode interpreter (for(;;) switch/case) as > > primary form and JIT only then - thus e.g. JIT can be disabled for > > non-root users in case of doubt. eBPF can't do this - it always > > exists in native machine code form at execution, bytecode is only > > for verifier stage. =20 >=20 > This has absolutely no impact on cache side channels. The JIT makes > some attacks harder but prime-and-probe attacks are still possible. Wait, do you want to say that problem is not in JIT, that is, that current BPF (e.g. tcpdump) present in the kernel - are also vulnerable? Also, let's classify vulnerabilities. Is speculative execution vulnerability the same as cache side channels? In any case, what impact is? E.g. attacker could leak secrets, but *where* would them leak? BPF typically returns one 32-bit number as a verdict (often as just boolean), is it really attack vector? That is, may be solution is just "don't give read access to BPF-writable memory segments to untrusteds". Next, if problem is with timing, then isn't that enough to just restrict BPF code on having access to timers with resolution high enough? > BPF can be loaded only by root, who can also load kernel modules and > map /dev/[k]mem, and FreeBSD does not protect the root <-> kernel > boundary. Wrong. It is possible for decades to do `chmod a+r /dev/bpf*` and run tcpdump as non-root, which will load BPF code into kernel. Is *that* also a vulnerability, and if so, why it was never reported? > Please read some of the (many) attacks on eBPF to better understand > the security landscape here. It=E2=80=99s a *very* hard problem to solve. =20 Finally, the most big (in effort) question: suppose we limited to trusted root user etc. so it's of no concern. Are there now any objections/suggestions/comments on (rest of) BPF64 ? --=20 WBR, @nuclight From nobody Tue Sep 10 22:52:08 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 4X3Jqg3pQjz5Tm0b for ; Tue, 10 Sep 2024 22:52:15 +0000 (UTC) (envelope-from Lowell@Be-Well.Ilk.Org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4X3Jqf3zDvz40J0 for ; Tue, 10 Sep 2024 22:52:14 +0000 (UTC) (envelope-from Lowell@Be-Well.Ilk.Org) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=be-well.ilk.org header.s=selector header.b=g5FFnWF4; dmarc=pass (policy=none) header.from=ilk.org; spf=pass (mx1.freebsd.org: domain of Lowell@Be-Well.Ilk.Org designates 23.30.133.173 as permitted sender) smtp.mailfrom=Lowell@Be-Well.Ilk.Org Received: from lowell-Ubuntu.lan (lowell-Ubuntu.lan [172.30.250.95]) by be-well.ilk.org (Postfix) with ESMTP id 74B70115FD; Tue, 10 Sep 2024 18:52:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=be-well.ilk.org; s=selector; t=1726008733; bh=jdfy8oo5k6VeSnbmmPZsCQL7aMh2pyuflqdzy7AJj2A=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=g5FFnWF4iY8akONWQeagd0btxA2GjcdUzfAYNKjyVZeQMYjjFiH4nlywXkPKxmRvd ycIn3sU4gFiOzKzXZf4tqedyF5EcoOVLtHQMXT8QQdmn2dPXFAwWThae3EPXcZ3H5c r1hxjafofhl3IsqN32lr/0ayfd1G0jl5k+5MnGcI= Received: by lowell-Ubuntu.lan (Postfix, from userid 1147) id 5ED3510803DD; Tue, 10 Sep 2024 18:52:08 -0400 (EDT) From: Lowell Gilbert To: Alexander Leidinger Cc: Poul-Henning Kamp , freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-Reply-To: <1aa702e57e63f927b687212820e97f8c@Leidinger.net> (Alexander Leidinger's message of "Mon, 09 Sep 2024 23:06:48 +0200") References: <202409031532.483FW0If007252@critter.freebsd.dk> <908e7c45fbcea4634427b8d065bb2f20@Leidinger.net> <202409081302.488D2UvB069580@critter.freebsd.dk> <1aa702e57e63f927b687212820e97f8c@Leidinger.net> Date: Tue, 10 Sep 2024 18:52:08 -0400 Message-ID: <448qvzdsvb.fsf@Be-Well.Ilk.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 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.39 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[ilk.org,none]; FORGED_SENDER(0.30)[freebsd-lists@Be-Well.Ilk.Org,Lowell@Be-Well.Ilk.Org]; R_SPF_ALLOW(-0.20)[+a:c]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:23.30.0.0/15, country:US]; MISSING_XM_UA(0.00)[]; R_DKIM_PERMFAIL(0.00)[be-well.ilk.org:s=selector]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[freebsd-lists@Be-Well.Ilk.Org,Lowell@Be-Well.Ilk.Org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[be-well.ilk.org:~] X-Rspamd-Queue-Id: 4X3Jqf3zDvz40J0 Alexander Leidinger writes: > Am 2024-09-08 15:02, schrieb Poul-Henning Kamp: >> -------- >> Alexander Leidinger writes: >> I'm only going to answer two bits from your email: >> >>> > The source tree became our citadel: "FreeBSD is src". If something >>> > was not in src, it was not FreeBSD. >>> We are way past that too, FreeBSD is src+ports+docs(+community). >> Nope. >> The only reason the Rust advocates need to bring this up is >> /precisely/ because that is not the case. >> If it were, they would just have added ports. > So you are promoting a Linux-distro style model? As I read it, PHK was saying that this is why a "Linux-distro style model" would not work for adding Rust kernel support to FreeBSD at this time. The "this" in my previous paragraph and in the quoted bits isn't entirely clear to me, but the effort of maintaining Rust bindings for kernel functionality seems to be a significant part of the apparent problem. Be well. From nobody Tue Sep 10 23:05: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 4X3K6s624kz5Tn5V; Tue, 10 Sep 2024 23:05:25 +0000 (UTC) (envelope-from rob.fx907@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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3K6s2thtz4268; Tue, 10 Sep 2024 23:05:25 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a8d2b4a5bf1so177810666b.2; Tue, 10 Sep 2024 16:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726009523; x=1726614323; darn=freebsd.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lxaC1kdp70ZxV3KhRBwEMA5ciML5mPC6AyD8PtVl0sQ=; b=kLq1X+gCCrUQAJJaAkCqbGcSTEZHY9cvmHKdUTUFndDY/T1HTTrRt0u+8Cs93F8M9X uHxW++6AlYWnjXkfVMTnEiT614VeNsZv6wUImzv7unqwbN2WWJtNxBUi4W5Cvi3EkzhV 6NU6ODFJLgJ0FOd7QLE0wyOJNjFASs6bKwXEcN11IDL3YyCvJe1SrynK22nJkOKR7wvF d7pDv9SUG3ryLdpOtcULL8EeZTQ9zeQrlmjrWvC1RDI7Tf3OR84j4flkfI+JrXk8Rxf5 hjl98BABFt44dqDQQ5lWzvKZVzfX+2hfTiMmnXjQzpOY3LTZA+hab5JLNo9taieV5PhY mSsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726009523; x=1726614323; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lxaC1kdp70ZxV3KhRBwEMA5ciML5mPC6AyD8PtVl0sQ=; b=PY/IgHulPwi3VauhmS+qt1KIZPzkc7Bi6GxdQf83naGM1ODd9kRdZ8l2y/L7Utn4zB DDaHXqjKz3TPQCJBfhl8K76mmXZhiojN+u2q9dhLbVwXOOb2HlzyUqQAEJA29Q9S3klG Ph71rR8GxFk9PrjN523AeXRvbno19mlzOOF/jq93aZ5w6jAUP9nv6fenFc2i0z1B+gmo rgr3ldwm7CTGMBbDgeUpDhODfIbzc2pjfTmsPlcQRuu5d1HzRp0mlgH3878vRkVhvJw5 AitMmk95wTdOENZke7+aC88XkhfCT4LLkNaKGYXruTBFPNQEFqyhSwfJ8h+/zHfMhKnB X+Cg== X-Forwarded-Encrypted: i=1; AJvYcCUg9TU2r0kns0kO8tgvGJxIFxuMmLNVPrpyVp+jZE4BSlRgSGIZ462Cz729fCWoaRi1SptFK3/rXYzEcGk=@freebsd.org, AJvYcCVBh/aO361mgc/x6YZ22lxe+FNANYZy+dgia8i/s9EwWRIeF2UGTw3WMj5Esc2oWm9azDgVtatV/z7x6I8gYjow@freebsd.org, AJvYcCVO32wBtAyJEhvVq7jkboSbUPPcdTOck2vkjH8E4+0K91bxRl5kM/ifW97+No/xWa+xZs6oBphixvU9g6U=@freebsd.org X-Gm-Message-State: AOJu0YzxSISue3ez/7tVjxonI74ZkVjTe14ihc7kuEext4zTjV1qHYY5 92bj5EaBIxpHMBdVnaLDrEBrJfRtBVWXvlBBL7NRniBw9F6Pym8Eqvj5uBFc4YS23bz0unGv/9I tB5x2gMDGpApQVTurRI1WnvDfx4A= X-Google-Smtp-Source: AGHT+IHZii59aDQK4QI8qZz8O0y3eAwMpxF/hv2Me7NMwX/JK67b7rovaAf8S362Hp23Z8LjUTKKIGV9KyCum8Ktx00= X-Received: by 2002:a17:907:e651:b0:a7a:97ca:3056 with SMTP id a640c23a62f3a-a900482f97dmr100131666b.16.1726009522387; Tue, 10 Sep 2024 16:05:22 -0700 (PDT) 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 Received: by 2002:a17:907:7b06:b0:a7a:caa2:b01 with HTTP; Tue, 10 Sep 2024 16:05:21 -0700 (PDT) In-Reply-To: <20240911011228.161f94db@nuclight.lan> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> <20240911011228.161f94db@nuclight.lan> From: Rob Wing Date: Tue, 10 Sep 2024 15:05:21 -0800 Message-ID: Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative To: Vadim Goncharov Cc: David Chisnall , Poul-Henning Kamp , "tcpdump-workers@lists.tcpdump.org" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov Content-Type: multipart/alternative; boundary="0000000000007602a90621cbe8a7" 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4X3K6s2thtz4268 --0000000000007602a90621cbe8a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Doesn't NetBSD have Lua in the kernel...anyone have any experience with it? re BPF64: looks like hand waving, proposing two unwritten languages that extends an ISA that is still being drafted by IETF...hmm you can make anything look good on paper but the devil is in the details...which there are plenty of On Tuesday, September 10, 2024, Vadim Goncharov wrote: > On Tue, 10 Sep 2024 15:58:25 +0100 > David Chisnall wrote: > > > On 10 Sep 2024, at 14:44, Vadim Goncharov > > wrote: > > > > > > I am not an experience assembler user and don't understand how > > > Spectre works - that's why I've written RFC letter even before spec > > > finished - but isn't that (Spectre) an x86-specific thing? BPF64 > > > has more registers and primarily target RISC architectures if we're > > > speaking of JIT. > > > > No, speculative execution vulnerabilities are present in any CPUs > > that do speculative execution that does not have explicit mitigations > > against them (i.e. all that have shipped now). Cache side channels > > are present in any system with caches and do not have explicit > > mitigations (i.e. all that have shipped so far). > > > > Mitigations around these things are an active research area, but so > > far everything that=E2=80=99s been proposed has a performance hit and s= everal > > of them were broken before anyone even implemented them outside a > > simulator. > > > > > And BPF64 is meant as backwards-compatible extension of existing > > > BPF, that is, it has bytecode interpreter (for(;;) switch/case) as > > > primary form and JIT only then - thus e.g. JIT can be disabled for > > > non-root users in case of doubt. eBPF can't do this - it always > > > exists in native machine code form at execution, bytecode is only > > > for verifier stage. > > > > This has absolutely no impact on cache side channels. The JIT makes > > some attacks harder but prime-and-probe attacks are still possible. > > Wait, do you want to say that problem is not in JIT, that is, that > current BPF (e.g. tcpdump) present in the kernel - are also vulnerable? > Also, let's classify vulnerabilities. Is speculative execution > vulnerability the same as cache side channels? In any case, what impact > is? E.g. attacker could leak secrets, but *where* would them leak? BPF > typically returns one 32-bit number as a verdict (often as just > boolean), is it really attack vector? That is, may be solution is just > "don't give read access to BPF-writable memory segments to untrusteds". > > Next, if problem is with timing, then isn't that enough to just > restrict BPF code on having access to timers with resolution high > enough? > > > BPF can be loaded only by root, who can also load kernel modules and > > map /dev/[k]mem, and FreeBSD does not protect the root <-> kernel > > boundary. > > Wrong. It is possible for decades to do `chmod a+r /dev/bpf*` and run > tcpdump as non-root, which will load BPF code into kernel. Is *that* > also a vulnerability, and if so, why it was never reported? > > > Please read some of the (many) attacks on eBPF to better understand > > the security landscape here. It=E2=80=99s a *very* hard problem to sol= ve. > > Finally, the most big (in effort) question: suppose we limited to > trusted root user etc. so it's of no concern. Are there now any > objections/suggestions/comments on (rest of) BPF64 ? > > -- > WBR, @nuclight > > --0000000000007602a90621cbe8a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Doesn't NetBSD have Lua in the kernel...anyone have any experience with= it?

re BPF64:

looks like hand = waving, proposing two unwritten languages that extends an ISA that is still= being drafted by IETF...hmm

you can make anything= look good on paper but the devil is in the details...which there are plent= y of

On Tuesday, September 10, 2024, Vadim Goncharov <vadimnuclight@gmail.com> wrot= e:
On Tue, 10 Sep 2024 15:58:25 +0100
David Chisnall <theraven@FreeBSD.org> wrote:

> On 10 Sep 2024, at 14:44, Vadim Goncharov <vadimnuclight@gmail.com>
> wrote:
> >
> > I am not an experience assembler user and don't understand ho= w
> > Spectre works - that's why I've written RFC letter even b= efore spec
> > finished - but isn't that (Spectre) an x86-specific thing? BP= F64
> > has more registers and primarily target RISC architectures if we&= #39;re
> > speaking of JIT.=C2=A0
>
> No, speculative execution vulnerabilities are present in any CPUs
> that do speculative execution that does not have explicit mitigations<= br> > against them (i.e. all that have shipped now).=C2=A0 Cache side channe= ls
> are present in any system with caches and do not have explicit
> mitigations (i.e. all that have shipped so far).
>
> Mitigations around these things are an active research area, but so > far everything that=E2=80=99s been proposed has a performance hit and = several
> of them were broken before anyone even implemented them outside a
> simulator.
>
> > And BPF64 is meant as backwards-compatible extension of existing<= br> > > BPF, that is, it has bytecode interpreter (for(;;) switch/case) a= s
> > primary form and JIT only then - thus e.g. JIT can be disabled fo= r
> > non-root users in case of doubt. eBPF can't do this - it alwa= ys
> > exists in native machine code form at execution, bytecode is only=
> > for verifier stage.=C2=A0
>
> This has absolutely no impact on cache side channels.=C2=A0 The JIT ma= kes
> some attacks harder but prime-and-probe attacks are still possible.
Wait, do you want to say that problem is not in JIT, that is, that
current BPF (e.g. tcpdump) present in the kernel - are also vulnerable?
Also, let's classify vulnerabilities. Is speculative execution
vulnerability the same as cache side channels? In any case, what impact
is? E.g. attacker could leak secrets, but *where* would them leak? BPF
typically returns one 32-bit number as a verdict (often as just
boolean), is it really attack vector? That is, may be solution is just
"don't give read access to BPF-writable memory segments to untrust= eds".

Next, if problem is with timing, then isn't that enough to just
restrict BPF code on having access to timers with resolution high
enough?

> BPF can be loaded only by root, who can also load kernel modules and > map /dev/[k]mem, and FreeBSD does not protect the root <-> kerne= l
> boundary.

Wrong. It is possible for decades to do `chmod a+r /dev/bpf*` and run
tcpdump as non-root, which will load BPF code into kernel. Is *that*
also a vulnerability, and if so, why it was never reported?

> Please read some of the (many) attacks on eBPF to better understand > the security landscape here.=C2=A0 It=E2=80=99s a *very* hard problem = to solve.

Finally, the most big (in effort) question: suppose we limited to
trusted root user etc. so it's of no concern. Are there now any
objections/suggestions/comments on (rest of) BPF64 ?

--
WBR, @nuclight

--0000000000007602a90621cbe8a7-- From nobody Tue Sep 10 23:47: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 4X3L3g4wZ9z5TtpP; Tue, 10 Sep 2024 23:47:43 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3L3f3QfJz476k; Tue, 10 Sep 2024 23:47:42 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=JQpQoezA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2f6580c2bbfso2953571fa.1; Tue, 10 Sep 2024 16:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726012060; x=1726616860; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=pLn0PIT2lwV+Djl805vfqvUiLnwCki2KPcUPimdE1mU=; b=JQpQoezARMrUdMigjLsU/NfW1PkDPD6Aa9gI/PQhObE02NfRyrPdaSQ6vRkXU6R1zh T4Hc2rNqRXGal/sCKKcfjsi+5bEtq/CH5VxpE1dxlIrbVNRCVlTy+sKUQlNGCYDIyHKt DSAbTF2ygoqINrpt0Q7nQjtKIrwbT74stMHfRuMq5bzd8LQc/uyL9TCyxIkXC9b7kBUq odIfyHokp6V8hKB8PA4pVxI8OyBrSO2oDPMx9qdvji/4kMGrYyJgsoesh22JqwDg8pvG VhkJoS0xSKqGEoHzKpQz6ThNEtoX0LniyRwVEOBDVsFNNzD3lnfmSWKjd4k6Mu3YWX8i 2VyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726012060; x=1726616860; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pLn0PIT2lwV+Djl805vfqvUiLnwCki2KPcUPimdE1mU=; b=QPN1tM80O+C4c0E87P9QyQURC4x8kaRGbxu9upCwovByDg6whRVKwoE9CiLvJRzfaq /UNIAbT/2JpQPlmH5hMrvkgbSPoK2H2+49f/Zyx+BK6TAponmTMK2oxsLQgO0Uf1cPTp wHqvoPFieJb3E9EvDsumbsS4Yt0lFlnfK2ltE64jjluE85jZkBmb6popiHyST5ZJjpT0 EzP1K+O/EcQCtdodk74OfVm5jSXvge/jg+fZznB8YxVgPpOJsiWgrSqJDVJkvanCnvoK nGNXwCen6XZzrr9QKyfIs6DKwNIobXfAjqiizk0MWMrgExAPfz021udRvJ363j81jBbg mNrw== X-Forwarded-Encrypted: i=1; AJvYcCUIhjJ1GZRlt1kOYsVRvTaHCzQjlfvbcTtK8BKhqFe3kZkHEiJhKqxtcZCLTJS+aBRfmTIIWkqzTNbgXPw=@freebsd.org, AJvYcCVGNoZBKdqC15RKc8pIdSRYdRHvNZEwXWp/DYG/M7jHLEJ9WAfooxVtC96a7itePRGsqdXi4RZRslml18s=@freebsd.org, AJvYcCWi2SotehQSxWaJ+u/mW/Uy3+8KQqFrcZwNTgqAXdIMErrwUVs/6G1MPBqbA9KD+ggZoDpepqnrCjMQN2jviU1B@freebsd.org X-Gm-Message-State: AOJu0Yxn37B/OcQfcfcOqHSvFDY8bWdY/BnkM1Um1u5lrUdTof1O4iK8 1m7P/Z4gp1qvWrCip2T/qb0aU8xtwa5eBPbpxDP7EwywWd0lrORHEGjD4OjM X-Google-Smtp-Source: AGHT+IFS3vPrdngBZPNcSrE198Tqj5S5aP4CHm4pOYWmA1awgaVQ++udPn+7VFedXQGZ7dqVjpIOBQ== X-Received: by 2002:a05:6512:1387:b0:536:552e:5d36 with SMTP id 2adb3069b0e04-5366b91f158mr1474569e87.12.1726012059924; Tue, 10 Sep 2024 16:47:39 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5365f90d482sm1362675e87.262.2024.09.10.16.47.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2024 16:47:39 -0700 (PDT) Date: Wed, 11 Sep 2024 02:47:35 +0300 From: Vadim Goncharov To: Rob Wing Cc: David Chisnall , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" Subject: That's how (why) BSD is dying (Was: BPF64) Message-ID: <20240911024735.37522532@nuclight.lan> In-Reply-To: References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> <20240911011228.161f94db@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; 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]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-hackers@freebsd.org,freebsd-net@freebsd.org]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; 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::22c:from] X-Rspamd-Queue-Id: 4X3L3f3QfJz476k On Tue, 10 Sep 2024 15:05:21 -0800 Rob Wing wrote: > Doesn't NetBSD have Lua in the kernel...anyone have any experience > with it? Lua is not suitable for the discussed problem domains, don't listen to those who did not read material and did not understand short descriptions. > re BPF64: >=20 > looks like hand waving, proposing two unwritten languages that > extends an ISA that is still being drafted by IETF...hmm What's the point to waste resources on writing thing that is known to be not accepted to base system from the very beginning? FreeBSD already had precedent when a *ready* code framework was rejected be some FreeBSD users' enemy, leaving FreeBSD users to suck with absolutely *no* alternative (yep, sensors) - as ridiculous as if it was to say "current BSD firewalls are inferior to Linux so we'll better sit without that bad code (and firewall) AT ALL". Yes, the situation in networking for us was for many years - and still is - exactly so. This is exactly the way how to loose market competition and die - just don't try to innovate and do something better than competitor; then you find yourself porting compatibility layers after decades of rot, like Netlink or Linuxulator ABI, in a try to at least hobble with a cane instead of lying in a coma. > you can make anything look good on paper but the devil is in the > details...which there are plenty of So do you have to say something constructive on the real subject? Or even bikesheds are in short supply now? > On Tuesday, September 10, 2024, Vadim Goncharov > wrote: >=20 > > On Tue, 10 Sep 2024 15:58:25 +0100 > > David Chisnall wrote: > > =20 > > > On 10 Sep 2024, at 14:44, Vadim Goncharov > > > wrote: =20 > > > > > > > > I am not an experience assembler user and don't understand how > > > > Spectre works - that's why I've written RFC letter even before > > > > spec finished - but isn't that (Spectre) an x86-specific thing? > > > > BPF64 has more registers and primarily target RISC > > > > architectures if we're speaking of JIT. =20 > > > > > > No, speculative execution vulnerabilities are present in any CPUs > > > that do speculative execution that does not have explicit > > > mitigations against them (i.e. all that have shipped now). Cache > > > side channels are present in any system with caches and do not > > > have explicit mitigations (i.e. all that have shipped so far). > > > > > > Mitigations around these things are an active research area, but > > > so far everything that=E2=80=99s been proposed has a performance hit = and > > > several of them were broken before anyone even implemented them > > > outside a simulator. > > > =20 > > > > And BPF64 is meant as backwards-compatible extension of existing > > > > BPF, that is, it has bytecode interpreter (for(;;) switch/case) > > > > as primary form and JIT only then - thus e.g. JIT can be > > > > disabled for non-root users in case of doubt. eBPF can't do > > > > this - it always exists in native machine code form at > > > > execution, bytecode is only for verifier stage. =20 > > > > > > This has absolutely no impact on cache side channels. The JIT > > > makes some attacks harder but prime-and-probe attacks are still > > > possible. =20 > > > > Wait, do you want to say that problem is not in JIT, that is, that > > current BPF (e.g. tcpdump) present in the kernel - are also > > vulnerable? Also, let's classify vulnerabilities. Is speculative > > execution vulnerability the same as cache side channels? In any > > case, what impact is? E.g. attacker could leak secrets, but *where* > > would them leak? BPF typically returns one 32-bit number as a > > verdict (often as just boolean), is it really attack vector? That > > is, may be solution is just "don't give read access to BPF-writable > > memory segments to untrusteds". > > > > Next, if problem is with timing, then isn't that enough to just > > restrict BPF code on having access to timers with resolution high > > enough? > > =20 > > > BPF can be loaded only by root, who can also load kernel modules > > > and map /dev/[k]mem, and FreeBSD does not protect the root <-> > > > kernel boundary. =20 > > > > Wrong. It is possible for decades to do `chmod a+r /dev/bpf*` and > > run tcpdump as non-root, which will load BPF code into kernel. Is > > *that* also a vulnerability, and if so, why it was never reported? > > =20 > > > Please read some of the (many) attacks on eBPF to better > > > understand the security landscape here. It=E2=80=99s a *very* hard > > > problem to solve. =20 > > > > Finally, the most big (in effort) question: suppose we limited to > > trusted root user etc. so it's of no concern. Are there now any > > objections/suggestions/comments on (rest of) BPF64 ? > > > > -- > > WBR, @nuclight > > > > =20 --=20 WBR, @nuclight From nobody Wed Sep 11 00:55:15 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 4X3MYg3jnNz5V4q7; Wed, 11 Sep 2024 00:55:19 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3MYf6729z4KQ4; Wed, 11 Sep 2024 00:55:18 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a8d2daa2262so386447966b.1; Tue, 10 Sep 2024 17:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726016116; x=1726620916; darn=freebsd.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8OOORre1APQx/atxC+Yz/cGDDA5j4dnQedINsPQZPgY=; b=e/9kOjgBAW3I4UV61UIh0+zCFF57kqptx7lJ2pW+bEnVktLGehRFkqmqYLERHUu+PC i++waLqMkdr/n11GW+CpE+jH+tXOpgOVtbpmjU51GI0Vr0DIoabgfD6VPVIGyqFaEHfz VW4iOhHGfQdweH0ogA5MoVk+CbJVUn8FDLjYvHOl39lOEZfnlGZaqc9moxXJURsWGZUf kFS4ZtL9yWSpuxBqiF4UyOK9yg+1KKmS5S7Ib3uAmWV4OivNi2+gbVfbU7NU1o2DbSy/ WPNen6uZQLZBqY5kcIW/GkzAIHMwP+X/eJF0uddI7EjToX5G55QuHNRjBbFALJ4T9lzM I+NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726016116; x=1726620916; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8OOORre1APQx/atxC+Yz/cGDDA5j4dnQedINsPQZPgY=; b=CGnF44KOGXK16puzY1PMIKsC7uTMo4e7KQIk9Of0SRvYxJGF3Oj8Td+VvmbsfCEsjE 2gJrvbWqfryyV0EHMGUbTytNUKpn+jon3DleeEYsZTmePdEGOMKaueV0bSPtsm/9GBMy UdRfOoydtkp1S8VzLtd4nPezYu9OKMJFPskn+W5u/uJTB1IC9ChRyZotg2tSxqzflh/q 605japAzLW9AyYZDYIQOnnzDjIUVEjmm1aRmsXiEUKsIKYeYhmv2FbhQuEsH7/ATCyyd c+4KqK1IVKKNm28eoMw0eUuEBEazwNSvinrF71yS+g0RR9gIS9FKSa5tcvyZHy0M8CRv wzHw== X-Forwarded-Encrypted: i=1; AJvYcCU+wxA7KYH9RV9QIBeEGIy7ECE1u+EjOzMvPpNIge9/WXIrcxyJgvBTYvLDv1mC5/al2mSUyzaEhplxeRg=@freebsd.org, AJvYcCUaO9YA9C/dqpNl1QMixaLMXQ7j4DVddkAEFahIHWYHE94aMVeg72L5RV0gygnNbClLa4vwqudWu+q1spdE9PQ1@freebsd.org, AJvYcCWpBgeD2TQG+G/+GnhKPgwZfMa93zliMA0ODrP0jagEOrOEE4ZJi80U/nWHvYKjAWONvgKj+Nrpob/lMV4=@freebsd.org X-Gm-Message-State: AOJu0YzV3w27Ny9AbzVb6lKPL3jiHAAq76F94GnOAAQkxY666MhHNpS/ eSI8o/+JT26GBMdH7RtZPf2qeJDmCWyronNZDqmhsUKASGtxqVOoKvLtUQkx7QK2s9j3kjgcOIe EaD4NlnqZWE9YrWrRPnTdSXGfoqc= X-Google-Smtp-Source: AGHT+IEljO2MLm6QccSzBgyWmdCPtGh+yfzDLn1w3uiLQkvzazIAbScpIEH5p/CExvXJBgcWdWKJZvI55cF3wAf/f6s= X-Received: by 2002:a17:907:2d1e:b0:a8d:2faf:d341 with SMTP id a640c23a62f3a-a8ffaaafbc7mr233657166b.10.1726016115968; Tue, 10 Sep 2024 17:55:15 -0700 (PDT) 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 Received: by 2002:a17:907:7b06:b0:a7a:caa2:b01 with HTTP; Tue, 10 Sep 2024 17:55:15 -0700 (PDT) In-Reply-To: <20240911024735.37522532@nuclight.lan> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> <20240911011228.161f94db@nuclight.lan> <20240911024735.37522532@nuclight.lan> From: Rob Wing Date: Tue, 10 Sep 2024 16:55:15 -0800 Message-ID: Subject: Re: That's how (why) BSD is dying (Was: BPF64) To: Vadim Goncharov Cc: David Chisnall , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" Content-Type: multipart/alternative; boundary="0000000000007811300621cd713b" 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4X3MYf6729z4KQ4 --0000000000007811300621cd713b Content-Type: text/plain; charset="UTF-8" On Tuesday, September 10, 2024, Vadim Goncharov wrote: > > > What's the point to waste resources on writing thing that is known to > be not accepted to base system from the very beginning? what's the point of talking about thing you're never going to write/finish even if it was accepted? Or even bikesheds are in short supply now? have you considered calling it eBPF++ or BPF128? at any rate, don't claim the sky is falling on the grounds that I think your proposal is far fetched if you think you've got a great idea and have a need for it, then write it and use it - if other people adopt it, even better all the best to your endeavors and don't let the naysayers hold you back -Rob --0000000000007811300621cd713b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tuesday, September 10, 2024, Vadim Goncharov <vadimnuclight@gmail.com> wrote:
What's the point to waste resources on writing thing that is known to be not accepted to base system from the very beginning?=C2=A0<= div>
what's the point of talking about thing you're n= ever going to write/finish even if it was accepted?

Or even bikesheds are in short supply now?<= /blockquote>
=C2=A0
have you considered calling it eBPF++ or = BPF128?

at any rate, don't claim the sky is fa= lling on the grounds that I think your proposal is far fetched
if you think you've got a great idea and have a need for i= t, then write it and use it - if other people adopt it, even better

all the best to your endeavors and don't let the nays= ayers hold you back

-Rob
--0000000000007811300621cd713b-- From nobody Wed Sep 11 03:22:08 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 4X3QqP2v9Qz5VxWv for ; Wed, 11 Sep 2024 03:22:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 4X3QqN176Fz4ZGt for ; Wed, 11 Sep 2024 03:22:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IpKGfAqn; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1726024941; bh=J6Cy86K7/NaVoy6LvZDbAdejPDxHoYo77COzBD/Vm/k=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=IpKGfAqn4/+5ZOVHoNBMk5iJbcBZql8VI03fw8uRcen9623R1bzrHs3TtZexh9s1FD9MjglWBQWIqg01TqXMW5CFCBGEbTWqI2vPgC8FEtZ0PEI0Q8SEkVpwZ/o0te4Kik5rX6eYMtc0qoSK7E6fIiv9bNL5yNX5Al+/B+EiUfzFkatBOpE3SyluUJneDMmRBNtQvtjX7x39EL0JJ2jZipm2HL7G98RSuouDz+lHR1hhuBoYHVXezjvvg89c3dsiYV9llESTlJphztFKXOJSlB8y/OOSliz/TN0xIFHZxmauPohS8FNk6icgk5x3q+BPXcBxMPhmrUIyuwApkSQwYg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1726024941; bh=+dXrpS1H8X46KPXtkBlsJnuBsteE6HPX8kG7J8OXcrx=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QZ/bj0KUGY4B9IXU2Z+C6CC4YFwkJV9j/cqUCAPJzyrKCzAU8P89zNlu9rEEzJX8GGq5l1ViTdhouB91KYuEpPDk7jeouq41JL6rnVXN+6VXx1Na74eK5lNAWqMns0YLn1DfmKf2+azU1XNKZwZ0VQo/u9ktf78wJ1AXgfStHNtZxl2oYp1SIklMU3R9Pxo9imSN7kIvy2ebk+SiZ4tyM6JQpvZb+t3h3VnrCeuEK+ZezDdds0sXXTlGdXiFKY4j1qeBC0jl7W4jgNEcf68RNR3xNzf0a3WdfEn5FzZZ+ZaKpjeTPaKWsNJucATDMGgrI/qITFtO32SBboC1NSrhyQ== X-YMail-OSG: MqOThhkVM1loWqTaTgkiWja4ZJZZV_JUlZhZj_2XnInTQ58YTunI9e_wjNNOB31 k1lwsBw6f4cwmDsGL0H7NaDxO_jNhqHu2UoAjU8eHmS4gOXqaOJSaLSyFkaBcIQU9pkNKqDH3jCD MFOkQV9.SXd1t2u3ESvqKYr5k_bhey6MFXf4Lz9h50ymGFlBZOaEVSDNo3YWNPEvaeaAb8hxAbIr YHv8x_gHx3smCE3uCz2jpnC_0oWtFqOCQ53YpPw0pOmyrP304CozoIdwVVDHjTF8zSLqBus72a7t Gn6Br.8DqA2ONm1qBgZc13wPX3ObaZpQ8yNjLTIwWlJdLpLDw8DY7oyn19pGzMY24fdM.03Llwg1 W4ZhyvCZjguwfvzR_PoQUiRY6Kk_UcjxBWgHQ4F1Y_cKvDrUA7mNBi9Ub7mhSL2qRJaEzO5cZTnS KAwjH_4WLS.dbydZz0STYJcUz6iepZV.fLz_oqXhOXENuEVaJNKH6iOhvkr4K5glL2KWpUpODzH. kbZTPFr9lpMPXvBetqT5rpfsSCAbxSflqCZu6bOo8rvvvw3WXJSL7cyaUdfssO0izF2ZHecglnId M2tUU96KIIjl7KtT7CecxNBt5D98ZDl1awtcqkzmHrV1nxAjhht8s3mebySOHAKEhdE5Vo1S9tAh Lh0gPxKeErgC5ogMX1RDaqhK_v0cpxpZ_3iJdn95_j.MxDP8z0.wqpLXk6kEnFw2XcRCwSjR4ZLd rsw6TfuiKu8HVdTJXLjA0RAdNUlDXT6ghfevq7rYqCExAqhJqScrditBHo0UagjLHId.qIHSorQt we.rOzyfcR.0xrzEDlLXaSEJH9jI_9PR2VClosd2aeFhHbMm01RqWzu3T9gziGj53IqreZ1BO7gy WEOhxNX9zHoMeNrEPgpao1pKlMCGpdGLfXwYwKTTCnCmNvNOfZOrD7tP.LIeBfj4OEqK_xDjsHpi mcaas9VqwSNzJD.pjfSxt1dGx9ZK_suTjW3oYL1mgzXPIdzIKiSfrNjN4lowPHYqA9ezJ74qBQtr bYex2TwEcvaBvCWT3IYrDp7UIQEWalwLRkNxsPqQyXWaC_rPIPPCRHSPX1b921E2VlmxCah.Rv88 Ogohax4ZhqNyIIA7KtWj8qGPKEdjXWLCTvveNvt0wG6k45J7k.4pGi6kOhCcaGo1zlF5.qTGXxbd m8GAt02DpGJ._w87QhMclhEatu3ZJVnaa4nuwFl2DyaRzXKdQ2IGxmppEx2.Y6ZIJrJhssQHPFEt MGaDoF8eG260MHvzGpJ1NTz.l2XI4ivdTmIBMjQheGMst.RirR4Y0jhKH_OXDWcU5Gt4FeIdy2tX Xq84pSwJgIrvTmkgIiSYtwj2Pj38JEEs.UbQeK7zvAjts4QrqlcSOO63kywdXtVv8t7EjNQI0avf o6Pn830LJBBy2e7xQTET6V2Ku26fbdvCUSHUt2jAlG2InTT7KBqq9QT62ZOxxldYnnD5.bOptuVG 7lhiuXEh7frd_MbvExrISfNVFViWAdjNKvDYKCDSqFCpTK24gsOMR.IlyE3h2zeem8hNn2QwwtMq fWWwbjs0X08hv3Tj.PzQ.aDIEJFe8Z5PV4fJW1ttfXAQ1nsePMi_S7irWkDjb_ih_t8i_wVf7Agi SKsCIKXtdilgYyVNHz69yEaBn29QOUawa0bHdexXtXzRzVfu.emyPdWbJqdjW_mXThOMmqt0iAqA 2gSMORqPXDfoTpWhuGZZJuptlUVmUyMDulIF3bqgdgN9k19AhJdnhUXAa5gN7Ry7NxfEl1qwVIGr XWBbYyamokpMMuZQb9wHof0xxjOWpvy01EfYG9STCwk.wVe1_kON9QB3MAZS01Bs0FsUclxJnR_R i6b8NOV_rvuqRzGeLUZ3M9ZW75HM2hoXse.bNFL70WmRvkTeRZJvlGsov.HPj_qFrtGN86FaeV8F nnohfsRh8CcF5nI0CRFp99aQ13Cf7CEIl3Ny.91oxgmRxGwTxy41u4blU5yfhCm_Fefpv0SMTnpt MbvPN6izV0ogTWUw38tx6UVOvAovjuWlpS5SUi7yN4_kbuBMwXOX1rusYm7XKSj5vZR80k2jMuUO iumWIsOEOzfonKm111pnPpMGRgbRu9E0x9tBrrWYnqs2SmRvCFuJVBPtliRZrxVMMWdwg5PPXnqJ NFdKISrC4GtDQjG_TPEi9OdH9UpQSUpzIDoHICcLX_jYc7loq8ix5bld9m9KE19qWhUZVoj.F0dx U3IAsEJawplJlH5_BTkuu4v9QNvHqojH93aCzA98Q3fCTt_rzD5j1JK3ln28w_O.AGjJKXJGDMA- - X-Sonic-MF: X-Sonic-ID: 13209775-5d21-41ec-8d5c-940de6283c11 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 11 Sep 2024 03:22:21 +0000 Received: by hermes--production-gq1-5d95dc458-5n5gs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e804b2985fd072b5b493a89e7be6a131; Wed, 11 Sep 2024 03:22:19 +0000 (UTC) From: Mark Millard 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 \(3776.700.51\)) Subject: What rust claims about FreeBSD support (as an example involved in picking languages) Message-Id: Date: Tue, 10 Sep 2024 20:22:08 -0700 To: freebsd-hackers X-Mailer: Apple Mail (2.3776.700.51) References: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.06 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.94)[0.942]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from] X-Rspamd-Queue-Id: 4X3QqN176Fz4ZGt [Please view this as just illustrating a technical issue involved, not as some sort of objection on my part to various ideas that have been expressed.] Using rust as an example to illustrate a more general issue that might be involved in picking languages . . . https://doc.rust-lang.org/nightly/rustc/platform-support.html reports its support tier structure relative to FreeBSD as: (for 32-bit I'll only list armv7 information) Tier 2 with Host Tools: x86_64-unknown-freebsd 64-bit FreeBSD Tier 3 with std and host checkmarked (=E2=9C=93): aarch64-unknown-freebsd ARM64 FreeBSD armv7-unknown-freebsd Armv7-A FreeBSD powerpc64-unknown-freebsd PPC64 FreeBSD (ELFv1 and ELFv2) Tier 3 with no checkmarks (nor * nor ? for std): powerpc64le-unknown-freebsd PPC64LE FreeBSD riscv64gc-unknown-freebsd RISC-V FreeBSD Tier 2 with Host tools is described via: QUOTE Tier 2 targets can be thought of as "guaranteed to build". The Rust = project builds official binary releases of the standard library (or, in = some cases, only the core library) for each tier 2 target, and automated = builds ensure that each tier 2 target can be used as build target after = each change. Automated tests are not always run so it's not guaranteed = to produce a working build, but tier 2 targets often work to quite a = good degree and patches are always welcome! Tier 2 target-specific code is not closely scrutinized by Rust team(s) = when modifications are made. Bugs are possible in all code, but the = level of quality control for these targets is likely to be lower. See = library team policy for details on the review practices for standard = library code. Tier 2 targets with host tools additionally support running tools like = rustc and cargo natively on the target, and automated builds ensure that = the host tools build as well. This allows the target to be used as a = development platform, not just a compilation target. For the full = requirements, see Tier 2 with Host Tools in the Target Tier Policy. All tier 2 targets with host tools support the full standard library. NOTE: The rust-docs component is not usually built for tier 2 targets, = so Rustup may install the documentation for a similar tier 1 target = instead. END QUOTE Tier 3 is described via: QUOTE Tier 3 targets are those which the Rust codebase has support for, but = which the Rust project does not build or test automatically, so they may = or may not work. Official builds are not available. For the full = requirements, see Tier 3 target policy in the Target Tier Policy. The std column in the table below has the following meanings: =E2=80=A2 =E2=9C=93 indicates the full standard library is = available. =E2=80=A2 * indicates the target only supports no_std development. =E2=80=A2 ? indicates the standard library support is unknown or a = work-in-progress. Tier 3 target-specific code is not closely scrutinized by Rust team(s) = when modifications are made. Bugs are possible in all code, but the = level of quality control for these targets is likely to be lower. See = library team policy for details on the review practices for standard = library code. The host column indicates whether the codebase includes support for = building host tools. END QUOTE I've not looked up the status of any other languages but I think the above may illustrate the considerations involved sufficiently. Some languages may be fairly easy to self support. Others might require upstream to have some sufficient degree of support before it would be viable overall/long-term for FreeBSD to depend on it across a range of platforms, especially FreeBSD Tier 1 platforms. An issue for my example (rust) is that as long as FreeBSD has aarch64 as Tier 1 in FreeBSD terms, might it be that the rust Tier 3 status of aarch64-unknown-freebsd could be a problem? Can FreeBSD cover the gap or lead rust to change the rust Tier 3 status to, say, rust Tier 2 with Host Tools for aarch64, matching x86_64-unknown-freebsd ? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Sep 11 05:32: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 4X3TjN4wC9z5WDcb for ; Wed, 11 Sep 2024 05:32:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 4X3TjM2vZgz4pDv for ; Wed, 11 Sep 2024 05:32:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CcgbrchD; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1726032741; bh=sYMECBaXflitWzjKDsUCqRWascWLilmCU40SjnDQOiI=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=CcgbrchDtfw7iUbZR7RATbRNfd60Eyhf8nX5oPd2EGlYg4DQ6mWoNxLsqvrotNTldh5+G/WESXxUI2Z3icsAAwoiK9zTc8Y+lAGa0tymmvwvQTThdMOLy5YOK53bhq9Ghc/63nTzD2Ion/RxNS89kj0YqRpzuxLMhfDxDKRWdo8MgDuRicDNhPTWR6LnNWQr9NCgFBKZqy41EGE/s9xqljLwCsIyvl61v7MTxLbk0i3taoV5iWFVem+4G451FKeKG01eeR+3PZUgIHR/G3H+x/oRRtDCYDf7QURe5Iu6x0MnfQ3mny/vO7ko6KInzKxPNrdg7OUTQpkhhWt4SVwxxA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1726032741; bh=BZwBcfmoPotFmc4tG3yBSz0DSxnfdGEi64hV3VDZ5Sm=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=raAKwHueo6PC6BCTFdPwYav3WpKDxIvu0gY3MSnwbjNJlFnXMq7WJ3VmDMN9n2+OF0HD32+NHXqe1H6usNuX9w+oYruB8dH4JT+0uuO2VyauPRVl6ePjNDM22zBTnZ6Ples8XcB41M5VBi1dz1CJP55feE252QBa0RDTMZQ7t5Y/3zxFDOfnvyuliMA60w3fiEA1V7pudW04XZMOBpimJPCMkRZL/S3+X5afmNZrBi1u5L7+qzOW3cI7t7TTXJ5qlcN4SeoOdTEmI+v+uNJ/I1p3NLXjLLlS+nfiZl4LdqNdTUdBbY/Gn4dW5Tks1osZ9BxQIcEQ1BnOfvc2FweKqg== X-YMail-OSG: RwpPFWEVM1kUgO5OXtNCXNnbDqBQS6xHwC3xEif59Jf9X9J7829ozl1PjYIHphW sh_nxaobk67Y3ji6dF16BmDmExWAFeslPmct2H8B0pNr.TuHd7EuwSoaf7pXLwMgnNEQ_JznSot9 O_Y4X1DySUJ.KJfMM3jJkSrFIjYGFpJYWDoHWauQ4DUXOeaAMVzRgcyhRjpceFQ.m0KAET2lpqR8 H6PrVwV4hiA6p65JDjQ0JORG5collXKK.Zgl5e_DpNPewJgszVOV6KDPusbSor8_9pXFj_dxGuY4 VoPLZaQIpsKHNX4snfXl3Z5VIr_bmgJMcw1BZfA0.q6hb_wPOQggj9zsox6o_QUVnoo_azMLqoMo YdbByhjTeoW.xEx7ycxiluXH4A_kyz.1Pv09XAjXtMGfgQ3GzqM9PpUkjjhq4gz9_US0Sv1D.J7R 30ZHkYd_GCYcTOCCWiWIumFczINRJp4No5VtcSlXSmdqRsAlT0.qTNsDEaF1Wu0VOaAh7yQAhhDp phsZCmKaewLoZRN7E0Xgl9Q770bQWf8TXhVDsSiPCTWx8dfhI7ZgwB1jkncT1lhMPubq8l8rLeDu JvOGSqG2uiTrJ7ywnQlBxiiRhY3_CN_JvaV8SN0ILANiWL8onlEawlarkJ0L8FHfarUH8UuSolLS mwA6bkImpNZTTP2F289kCoq7bf0aWaB495W9fMfeKyOWiKS8OdVPJIGmNSh73p_PqoaNs2d3BblV EaV.XC.zZKnSAZfin._4mdqPLImai.5XIuPY5LO_mOdd4x6VXRGUs9khHxhlIFBT10C7emq2pA5c MJ9d_kq1JxKWGT_eKmxVXKDJQ6bnI2gKki7M0AxHS0tNnvwFVk6.6vsoxTBZkNcKpwkYemg0oQol eoTLQOd8veAJfMy0kKYe9g5k_QwpdIrGjBmtKFDUz5zUzDrItTXMJRkFMqqMRQ._6yRO.HojGAy2 mg70S1VJMrc4dzZNkQJvhj1iUSxnSuZ20eTbI2Lv1kQ5xmGD.x3xLCW0sBtvvqmNB487cTPqrnnM 2.4w8qzVVeHM47pt9vaynmF0yVgScEi.QQbgO8NpkiCSFt7OgU5o2ORnO1PpuRBQHu2hm7ROrej0 1G6O6_r_HEcaDYE_QLeuSckxIwpByELbFOteKj1jvaBDUYI_gutvlPMo90owIMA0ndoPrJvD6HKz 8qZ.9HY2KSuLWcxkhiaENgxYkEgo6GTpLb17EGkmwp7_PRehwuEk.01HFYh118.PUYbAMhxmMl1H MX9YX54ru6TYyWVfq696VG5w2pP8wNeVfN03P0CQ5njinRAEabHYZ_dhuGhWOAoSdXhQGthNZCJm GO7FyqILre6z3_k5ejLCYjbqV9T7GIEWFxUzs7ywv3nG_j0.0Douok91n3NAXmZhUNpUSalkKUR_ _klezpXfNni_L1Ft0eT.ET9R89llhhdAz8faOYc4LrfTvzM9X07SWZ14nKHOFHZwDWB8M0MEGoUZ gcm7JOfhv_OSdPt7yIm_8pkkbt2PL.GBKwebwhDE4EDzhkryhmkIMBnTHW0TWYiZ_Cve42vwj6w_ L7KwPNOn3QxCACzDKfQz6_7purVuyZFG0c1dJgaZ8XdkhGQ84L1gUF5M3OCrDz.psjkYC655jgpw yxfP.L6BgQqzsseIgpURh6CbwnQMO.ifvurUac49CPzA1TJnd3x863xSEmtPGrQs7Vs6Lh4j9CEG fdUjx2d3z9NpIw5TuJBt1AkApLCgqK8g2ZAT_Gbturz60C6Sz_a69ODHwM8AJBnAeNB4.nnsdxs0 0qZ4wNzO9XdHgKmdZ3t.0qgoqAK17TIQNJFkh8Blze9lviokZILjaNhAK_n4BK.UsDNeSJztMoaT AasWm9fVhOrSN1FT46l_.x2YYOdd8v5SN.F7v1rtnnenk.NdpIgwbGBMSRZCKsLoT7Lo4xZUGNue WpvQLGQ_KRZ.J8cbK1PeiDnlqNBh.CI6UlY.81nmQmI_GKLaNtVlhUp5G0z4zp..2wGc1rUkuWWS Hqn3oI90PHJEnT8HutWJexW6PMqBeKdTlLh4PvB_bqZPCQRpklGp4uWCgqRzXG6l.kJoWczkauKR rti42MGDIRyr_xrSgOFgzvuU_MHiZrsSxt.nDh.7rgabUWyTXNYuSFkQTqXnjJ_379bFMwQmy3MF ftWBklmxS.3z.iBtFhc5FpP8v8mBNS9uNnyMmUok8W1e.8k9riv_X_dOhESsvG3l5YT2qnpwV5Fe XOOGz2trA9dFK3svtxsuS X-Sonic-MF: X-Sonic-ID: 3bcf35b9-ef3e-4afb-97f5-174e02bcf05f Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 11 Sep 2024 05:32:21 +0000 Received: by hermes--production-gq1-5d95dc458-sd55t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 27ce536fe55c2342d90297511312bc8e; Wed, 11 Sep 2024 05:32:15 +0000 (UTC) From: Mark Millard 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 \(3776.700.51\)) Subject: Re: What rust claims about FreeBSD support (as an example involved in picking languages) Date: Tue, 10 Sep 2024 22:32:05 -0700 References: To: freebsd-hackers In-Reply-To: Message-Id: <9F4DBD51-E706-44BD-A243-C08E6535D80D@yahoo.com> X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; APPLE_MAILER_COMMON(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from] X-Rspamd-Queue-Id: 4X3TjM2vZgz4pDv [I had not read the rust Tier information prior to what lead to the use of the material in the original note. I continued to read after my note and I ran into Tier 2 and Tier 3 criteria relative to PR communication that I'm adding this time.] On Sep 10, 2024, at 20:22, Mark Millard wrote: > [Please view this as just illustrating a technical > issue involved, not as some sort of objection on my > part to various ideas that have been expressed.] >=20 >=20 > Using rust as an example to illustrate a more general > issue that might be involved in picking languages . . . >=20 > https://doc.rust-lang.org/nightly/rustc/platform-support.html reports > its support tier structure relative to FreeBSD as: > (for 32-bit I'll only list armv7 information) >=20 >=20 > Tier 2 with Host Tools: >=20 > x86_64-unknown-freebsd 64-bit FreeBSD >=20 >=20 > Tier 3 with std and host checkmarked (=E2=9C=93): >=20 > aarch64-unknown-freebsd ARM64 FreeBSD > armv7-unknown-freebsd Armv7-A FreeBSD > powerpc64-unknown-freebsd PPC64 FreeBSD (ELFv1 and ELFv2) >=20 >=20 > Tier 3 with no checkmarks (nor * nor ? for std): >=20 > powerpc64le-unknown-freebsd PPC64LE FreeBSD > riscv64gc-unknown-freebsd RISC-V FreeBSD >=20 >=20 > Tier 2 with Host tools is described via: >=20 > QUOTE > Tier 2 targets can be thought of as "guaranteed to build". The Rust = project builds official binary releases of the standard library (or, in = some cases, only the core library) for each tier 2 target, and automated = builds ensure that each tier 2 target can be used as build target after = each change. Automated tests are not always run so it's not guaranteed = to produce a working build, but tier 2 targets often work to quite a = good degree and patches are always welcome! >=20 > Tier 2 target-specific code is not closely scrutinized by Rust team(s) = when modifications are made. Bugs are possible in all code, but the = level of quality control for these targets is likely to be lower. See = library team policy for details on the review practices for standard = library code. >=20 > Tier 2 targets with host tools additionally support running tools like = rustc and cargo natively on the target, and automated builds ensure that = the host tools build as well. This allows the target to be used as a = development platform, not just a compilation target. For the full = requirements, see Tier 2 with Host Tools in the Target Tier Policy. >=20 > All tier 2 targets with host tools support the full standard library. > NOTE: The rust-docs component is not usually built for tier 2 targets, = so Rustup may install the documentation for a similar tier 1 target = instead. > END QUOTE >=20 >=20 > Tier 3 is described via: >=20 > QUOTE > Tier 3 targets are those which the Rust codebase has support for, but = which the Rust project does not build or test automatically, so they may = or may not work. Official builds are not available. For the full = requirements, see Tier 3 target policy in the Target Tier Policy. >=20 > The std column in the table below has the following meanings: > =E2=80=A2 =E2=9C=93 indicates the full standard library is = available. > =E2=80=A2 * indicates the target only supports no_std development. > =E2=80=A2 ? indicates the standard library support is unknown or a = work-in-progress. >=20 > Tier 3 target-specific code is not closely scrutinized by Rust team(s) = when modifications are made. Bugs are possible in all code, but the = level of quality control for these targets is likely to be lower. See = library team policy for details on the review practices for standard = library code. >=20 > The host column indicates whether the codebase includes support for = building host tools. > END QUOTE >=20 >=20 > I've not looked up the status of any other languages > but I think the above may illustrate the considerations > involved sufficiently. >=20 > Some languages may be fairly easy to self support. Others > might require upstream to have some sufficient degree of > support before it would be viable overall/long-term for > FreeBSD to depend on it across a range of platforms, > especially FreeBSD Tier 1 platforms. >=20 > An issue for my example (rust) is that as long as FreeBSD > has aarch64 as Tier 1 in FreeBSD terms, might it be that > the rust Tier 3 status of aarch64-unknown-freebsd could > be a problem? Can FreeBSD cover the gap or lead rust to > change the rust Tier 3 status to, say, rust Tier 2 with > Host Tools for aarch64, matching x86_64-unknown-freebsd ? The following quotes are from: https://doc.rust-lang.org/rustc/target-tier-policy.html Tier 3 context's note on PR communication relative to maintaining the Tier 3 target: QUOTE =E2=80=A2 Tier 3 targets must not impose burden on the authors of = pull requests, or other developers in the community, to maintain the = target. In particular, do not post comments (automated or manual) on a = PR that derail or suggest a block on the PR based on a tier 3 target. Do = not send automated messages or notifications (via any medium, including = via @) to a PR author or others involved with a PR regarding a tier 3 = target, unless they have opted into such messages. =E2=80=A2 Backlinks such as those generated by the issue/PR = tracker when linking to an issue or PR are not considered a violation of = this policy, within reason. However, such messages (even on a separate = repository) must not generate notifications to anyone involved with a PR = who has not requested such notifications. END QUOTE Sounds like aarch64-unknown-freebsd being rust Tier 3 might have more support issues than I was originally thinking from what I'd read earlier, given the constraints on some Tier 3 communication. Tier 2 (with or without Host Tools) context's note on PR communication relative to ensuring that tests pass for the Tier 2 target: QUOTE =E2=80=A2 Tier 2 targets must not impose burden on the authors of = pull requests, or other developers in the community, to ensure that = tests pass for the target. In particular, do not post comments = (automated or manual) on a PR that derail or suggest a block on the PR = based on tests failing for the target. Do not send automated messages or = notifications (via any medium, including via @) to a PR author or others = involved with a PR regarding the PR breaking tests on a tier 2 target, = unless they have opted into such messages. =E2=80=A2 Backlinks such as those generated by the issue/PR = tracker when linking to an issue or PR are not considered a violation of = this policy, within reason. However, such messages (even on a separate = repository) must not generate notifications to anyone involved with a PR = who has not requested such notifications. END QUOTE Sounds like x86_64-unknown-freebsd being rust Tier 2 with Host Tools might have more support issues than I was originally thinking from what I'd read earlier, given the constraints on some Tier 2 communication relative to passing tests. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Sep 11 05:54: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 4X3VCR6qXzz5WGpq for ; Wed, 11 Sep 2024 05:54:59 +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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3VCQ14Zpz4r5w for ; Wed, 11 Sep 2024 05:54:58 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ea+0aIw4; 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-42cbaf9bfdbso20450745e9.0 for ; Tue, 10 Sep 2024 22:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726034096; x=1726638896; 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=OTQnDDJUiN/A4rMpqtd3+GlNwyIzPhyvz3ysPPUu8ek=; b=Ea+0aIw4oWH5iZlUAj8oo3Vbtc11s5YM2fFvyrmeKHf+KUyUok1dRmoYkO96dQiFJz aJsoD5Ni/i81pqZFyQrEWzGy5Zbzm88vOu9QxDbbJipXisWqEKouJ4bEJXBl6sid2Ts8 fSjmXTEhBkaSNiw7LYrAdK0/gg0qa5za/tGTDcmmfamz/2YqzioIMkXDNGke3qHuexc0 /NXGGtC71hlVwLrospLENZa5hIN5MBLytM+NPi9ROdtUykoxcnIcecYEJdpogPIirZwG dgzfGQ1Me01Eja70vPPi7tMvWVb83mlIePcq3L3WpEMptARBfQKGKp02QANV9dcCoMU5 SZ2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726034096; x=1726638896; 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=OTQnDDJUiN/A4rMpqtd3+GlNwyIzPhyvz3ysPPUu8ek=; b=w+zVgJjCi0byi0jkHH4iq8WKyoi2Fcc76ZEFnzV5qLs5Tw2ndkOgN89RyLCalInWeJ PdJruLetEVZCCLjIuZ2zu/UFCQJELxDX6UWcEANdU3eALB6TBUmBTCDhos5+RufANPjb Nb/pa6Ky/e5tjdvz7dtgpDnLMbvvqJeLF7J85QhKP6nFr1eLh++OLkOhmjm+v1hW3ya6 KMw/217NeU2KtA4ACtKfdVcPI4LMP4ImrLHeM1ora8Ho6so3rYwMokhGsQsNGiTbS4V3 A7spMtqWk2tWC+oOuJQ1OW5wTN6Oz3GYPJCgUsfg/PHYyrD+W2r+8M8pSjMQ5MzM02iY mN1w== X-Gm-Message-State: AOJu0YzN6Oq8o01DOTaUk/Y69W1Vk4viUjlv5Go5YNndmqEiYZTGwCD8 7XLEx6R8WdLVYq2awwyLQ4KQhOG5g5tSqda0Sf05XgCzM4kbDsm0FgzM/Q== X-Google-Smtp-Source: AGHT+IH3vr2EsvUrUQsQ/YJ67kqQo+jkDrNNO+tn7kbKKKCe1FFqr8muUAuhtwSZ9XrAm8pY50s4ig== X-Received: by 2002:adf:e242:0:b0:371:8c19:f5e6 with SMTP id ffacd0b85a97d-378896a3e97mr10904192f8f.40.1726034096270; Tue, 10 Sep 2024 22:54:56 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-378956d3796sm10540757f8f.80.2024.09.10.22.54.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Sep 2024 22:54:55 -0700 (PDT) Message-ID: Date: Wed, 11 Sep 2024 05:54:55 +0000 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 any system) To: freebsd-hackers@freebsd.org References: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> Content-Language: en-US From: Paul Floyd In-Reply-To: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; 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: 4X3VCQ14Zpz4r5w On 06-09-24 07:02, David Chisnall wrote: > On 5 Sep 2024, at 22:13, Alan Somers wrote: >> >> I used to check it, years ago. But I gave up. The UI is too hard to >> use and false alarms are both too frequent and too hard to suppress. >> Plus, it's a real drag that I can't run the tool myself. Instead, I >> need to wait for the next scheduled run. > > In general, it’s very hard to add static analysis to existing projects. The property that you want is that there are no *new* static analyser errors in a new commit, but that’s requires tracking all of the existing ones. In CHERIoT RTOS, we run the clang analyser in CI as one of the checks that must pass before a PR can be merged. This is possible because we started doing it very early on. It may be possible for some individual parts of FreeBSD, but when we started with Coverity I looked at the reports and the first ten I looked at were all false positives. There are probably some serious issues in there but the effort to find them is high. For a new project, that cost is a small incremental cost in each commit and code review (if the analyser finds something, reviewer has to agree that it’s a false positive). Beware of the confimation bias false positives as well, where the tool is correct but the developer wants to believe that their code is correct. The main problem with static analysis is complexity. As I understand it they only perform analysis at function scope. Since the output is explained step by step you can usually see why it went wrong. One common thing that I see is that in one place it reports a size to be within a certain range and then later reports an out of bounds access with a different size. Because of its vision of local scope it doesn't see that the size can't change between the two (assuming monothrededness). A+ Paul From nobody Wed Sep 11 06:16: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 4X3Vh84xKVz5WJby for ; Wed, 11 Sep 2024 06:16:24 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3Vh74nswz4vk5 for ; Wed, 11 Sep 2024 06:16:23 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=ALYZSouJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-3780c8d689aso3990639f8f.0 for ; Tue, 10 Sep 2024 23:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726035381; x=1726640181; 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=UlE9+qaGhuDAH/T3elWIcF4HjMSnJnK5hJEi7F4R/nw=; b=ALYZSouJ74+/nIjm77vlymveHv1EEqgzQVx9jXI2XLSZUkG/g5D9kd33jJdNPv6Cyl D7sB4c0w6VzBzo/OsTqOc5C4pbSXypPriLudoTMapfL+WSkFS/DQOX/Z6TZ4zTZ70Wid FCkNZw+qa2Fr85xNK1cy+szXBAXXZByuefQjYqPfRGI7PMuVRYMDljn+dUD6Blf6VMI9 FsW0xbDV3vnkCyJP/tw/4fSxgkkD8h3JRwnQDdb/NQZ2rtOe/mOEcouJZuZj4ZQr8ukj xamRstqxOfqqnDwowJSytyBJuyhp8uDr/4/Pm0PJzIedqaT6XSryL7brLS1XR5xJ2qZE 6dAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726035381; x=1726640181; 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=UlE9+qaGhuDAH/T3elWIcF4HjMSnJnK5hJEi7F4R/nw=; b=gdljAnlUn5xfM3fs5NoMAzojBS6Sbj5HCAgEehorC6F1/H5M0o8cV5NVYqSYni8dFg zeHIoK8UkZtMrcWOF1BdrY3DN8codROsB8hmggLl2/e88Vo5Es6mQKRFl8/hIz1d1mxy AiixqSYNaocBgnXR+6Kwxu81S7U/mojla5gDUGqlp7PK/QnEs1bhyr2hoY9VC+fiT2u/ 31Kwo93J4bhRoxhaUHFeF4Y7vV38bh9JsKHu/H/ZrRCU7CuGifq8hU7h8vGIMzRGnbD2 v7X9XioKljQdOWLn2wNkJivKc37OgkiiJzOCtYbfjHjbVJIHeZsimFnvXKcR46BBnFrZ ZwzA== X-Gm-Message-State: AOJu0Yyd/J+uZ+5qnUlt/k2Bg6IdhC/tE9jDGJfsxVxGByvc2CEbcDPY eY9iW6TGHGfRV2A59FwRMZnPd+Wtp/yfYdE6J7NFZhuYB8q+IfIjJeE8zA== X-Google-Smtp-Source: AGHT+IFffPJVCilpbHZgx9UBARFqOlS4RGwNA+N0GnQOdmq8GJOyZaSFwRPkroGI7mr+sQ8mQcxM+w== X-Received: by 2002:adf:f74c:0:b0:374:caf6:ca2f with SMTP id ffacd0b85a97d-37889675924mr10825929f8f.45.1726035380617; Tue, 10 Sep 2024 23:16:20 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42cb58d815esm101786265e9.31.2024.09.10.23.16.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Sep 2024 23:16:20 -0700 (PDT) Message-ID: <80b39d72-860f-4306-b954-05e1b6c5eaa3@gmail.com> Date: Wed, 11 Sep 2024 06:16:19 +0000 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 any system) To: freebsd-hackers@freebsd.org References: <202409060725.4867P3ul040678@critter.freebsd.dk> <4E4FB8CC-A974-42C4-95D5-2E1E4BF681AD@freebsd.org> <202409060825.4868PDWO042319@critter.freebsd.dk> Content-Language: en-US From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; 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::42e:from] X-Rspamd-Queue-Id: 4X3Vh74nswz4vk5 On 06-09-24 13:24, Jan Knepper wrote: > Second this. > > Not surprised... > > I have done this as long as C++ as been around and it always made for > better code in the end. > > Truly, this is one of the easy things that could be done with FreeBSD > code, and probably would help quite a bit improving the code. This is roughly what happened with GCC. Back in the days of GCC 2 there was a strong bias towards C (and against C++). That was one of the reasons for the fork and eventual take over by EGCS. Sometime later, around 2008, GCC started switching to using C++ compilation rather than C compilation. See https://lwn.net/Articles/542457/ A+ Paul From nobody Wed Sep 11 06:49:12 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 4X3WQ40nbfz5Vsm4 for ; Wed, 11 Sep 2024 06:49:16 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3WQ34MKFz50BK for ; Wed, 11 Sep 2024 06:49:15 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=NbLo5nRM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-374d29ad870so3959489f8f.3 for ; Tue, 10 Sep 2024 23:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726037354; x=1726642154; 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=u7d0f2vxPYCVduiT0t5b2aIaNUefTX17mi7HsvGEdYk=; b=NbLo5nRMRIwFRvPtvZqUJxKl1CwhC7mv2rCfNGK9tkJNkZaCcFA+ss5e5E9uy5buMc SmoAkOAMKiGF38j1QCDLjQRlsGodfEv2p7cfbPV/Xjx2NDkGeFR78TzAywmsAE+lDvFS MLmiJ6XQmCwYbxaAdUkxVwmrxbace60WgdD+D4GPTawYxxJgC1tyQXb4CpoDt7IC1HoQ COxdV7zdRVhOhVHQmqsuc7fscUPiVkwTto4TZIXjNbtFTkqr5Yo67wHhYd6s0e9u551b EoxOZFqsCKf2HfxR/GxrhTaw7JzCssYPYkehXMaWrTBgHDCQKY60EKuTT9Rtwq+RV9bR A7sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726037354; x=1726642154; 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=u7d0f2vxPYCVduiT0t5b2aIaNUefTX17mi7HsvGEdYk=; b=kuTRTszqgSczra3a8z81I71spEHDMVgowGzRY5XtiQX+qIIeLBTFme91zow18QEuS/ tyNMu5IwgViHq23zOYIzVboVApB14HTZwtBN5rzNd6xzmMyafn1fKviFS9TGgLNVmw9I ZzCY8GNti/HtrTonQgn30abp1XAWF74Vsb2QfAnD79MQ/zY6DuXw86atQQquIn3qf3Hq /SuzY+DXNa9kzZTdNbBr1TohLdmSw3CgBUUpaZWgBgx9m1HQiz/aFoWvvgio74jzbBMB CDY0ukolLbbkxWgBXpCbBEgBNr2BeACg0f9Ml9wZdPn7cy+EP7GIW2dwX78xBjWWHYWd XUZA== X-Gm-Message-State: AOJu0YyBHW37ntEl6CM9FObiAqtMw4Rm+1Kw4Z6QIj4Zc97YCax2foZQ ZmzjOAAgDcxqXwegecOIyZ//ZNAX5vqplA1FJeXb8NRElExKZmj1uVtUYA== X-Google-Smtp-Source: AGHT+IFtMtmwq0ktMEzY3vBrX18ozM3+TV9g4uMJC+688VZOCDl+5yX9lO1sS4ka7SxQ3h1NdVOXWg== X-Received: by 2002:adf:f60a:0:b0:371:83ac:fec1 with SMTP id ffacd0b85a97d-378895b79f8mr11038336f8f.1.1726037353926; Tue, 10 Sep 2024 23:49:13 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-378956d374fsm10712225f8f.86.2024.09.10.23.49.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Sep 2024 23:49:13 -0700 (PDT) Message-ID: <4fb5a7ec-41dc-43ed-8abe-97208013c941@gmail.com> Date: Wed, 11 Sep 2024 06:49:12 +0000 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 any system) To: freebsd-hackers@freebsd.org References: <20240905194529.3szOViVM@steffen%sdaoden.eu> <9adc3619-bc38-4fe7-bf16-20e0dfb3b619@gmail.com> <20240909213107.XGD3_v0I@steffen%sdaoden.eu> Content-Language: en-US From: Paul Floyd In-Reply-To: <20240909213107.XGD3_v0I@steffen%sdaoden.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; 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]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; 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::42e:from] X-Rspamd-Queue-Id: 4X3WQ34MKFz50BK On 09-09-24 21:31, Steffen Nurpmeso wrote: > Despite that it is unfortunate but true that prototypes in C and > also C++ not seldom do not tell the truth because bit enumerations > are missing, and so you have integers of various widths as "bit > carriers" through which completely unchecked bits are then passed. Non sequitur. This is due to the C and C++ type system, nothing to do with prototypes. > Or at least in C, which does not support "easy super-class cast"s, C++ has a stricter type system than C. That makes doing wrong things a bit more difficult > |I'm not sure that I follow your argument. Are you saying that you can > |build memory safety into C code and that if someone doesn't so they are > |a bad programmer? What's the point - why not just use a memory safe > |language? > > Because Floyd means pink not paul, hah! Is this the infants school playground? You just lost your last shred of credibility. > But answering your question i would say it does not make much of > a difference to me -- *if* i can go the way i want -- regarding > safety, but a lot regarding runtime and infrastructural overhead. > For example most of the development time i compile with tcc that > is 334640 bytes and links to almost nada. > > #?0|kent:built$ ll tcc#20240731-1.pkg.tar.zst > -rw-rw---- 1 ports ports 273285 Aug 3 22:11 tcc#20240731-1.pkg.tar.zst > > #?0|kent:built$ ll gcc#14.2.0-1.pkg.tar.zst > -rw-rw---- 1 ports ports 67854914 Aug 1 21:59 gcc#14.2.0-1.pkg.tar.zst > > #?0|kent:built$ ll clang#18.1.8-1.pkg.tar.zst > -rw-rw---- 1 ports ports 74166358 Jun 22 21:26 clang#18.1.8-1.pkg.tar.zst > #?0|kent:built$ ll llvm#18.1.8-1.pkg.tar.zst > -rw-rw---- 1 ports ports 136797237 Jun 22 23:57 llvm#18.1.8-1.pkg.tar.zst > #?0|kent:built$ ll compiler-rt#18.1.8-1.pkg.tar.zst > -rw-rw---- 1 ports ports 3378581 Jun 23 00:02 compiler-rt#18.1.8-1.pkg.tar.zst > > Unfortunately pcc is dead, it detected things that clang and gcc > did not (via warning options etc). tcc is very bad in such. IMO tcc is simply godawful. I would not touch it with a bargepole. I did once look at a tcc bug. I gave up as I felt that it wasn't worth trying to fix and obsolete port. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274211 A C compiler that can't compile hello world. [More ranting and crappy C macros deleted. Plonk.] A+ Paul From nobody Wed Sep 11 07:03:08 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 4X3WkK26k3z5Vv1J for ; Wed, 11 Sep 2024 07:03:21 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3WkK0c9vz52lc; Wed, 11 Sep 2024 07:03:21 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726038201; 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=lhxG3AwTS/xSOvvf9bOci9BXlo6RlD56OQuUKJxL5Pg=; b=NNVhWox9ON3yYr8rQ/yYfqBHrnUUIBMkIu4e2mAgJMMDlydJesg3LSdPhEwcJIGu9A2vw1 MR98pmLckQ1G80oo8S7c071THg0UCNtp7JL6+0S2rbKuCMlBJ6UGkFvCBpkJpWHmJAfQoP nP37njjV5mHSSv37Hhg1BR/TvLgHIm3ittjFejo4kElpmC0l/V1/zdbx0LJ8LwCz9y8RMm 8oPVOzZuqPnAZCo2QcZhWmk4oxp802PK5wpD0tpKPEFQNmSMvGzZl03pl+aM5ddNoWW2jn 492JQEaKOdsQtBg+OgHOLA6TuW+J2F9NykLtw7APP3dvmbXokGsvj4HzFm6CrQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1726038201; a=rsa-sha256; cv=none; b=pLBGI0QfBFpiKbCXarqhokS2DRjXLukKLNV255aqcLzhyWz0wqja6c6ykkLcyVK4lEvijX 3ryM6ByyudRp0NIRlWwKRUHm4fwqhiQgqgBzHJKjREC+B7EwROt7lqnfWZ0NG5LOV6HfY3 Y8diDCSfyxUrptCwf/8H3BJZRCHTcHR7x5ya07DkRXiIRUCw9qSdf9rK93CiSt40yZz2Bj k7GML3S5uznp4MXNImvYwRVTp44E5CzOJxciOKSbKGH4n/KDDllplPOsHy7EASBMvCR7V2 H3qlD1E96OHsf7YpirL0k57zygSl6urLcCnU47CszWSr7SAV1IwTkNwxCiUJ4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726038201; 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=lhxG3AwTS/xSOvvf9bOci9BXlo6RlD56OQuUKJxL5Pg=; b=mNj/SRld3D+lOaNR88/XwElqmODrgvDYFKdC4VWqBBnIfYK1yetQUP4j4PDsfKXnbHQT3d 5/GyH00uZCQn++/UB692aIyhFOlGpaG+YZnutIwK3rOGt07zU8fwunAjIvvH3hJW7H5Hez qnj5pFP5Z+7I/U/7b9gFgWwltooflopBGZfXXm/aWM2RVeIURC2gF+tgous7YYijiX3Bli sPmQyeYt5/nA60wApHMhWXT3tTMRxXcz+b5YuDFznWv8p117S3xLuFkMPU8Kz1Bh34rohY o+/VSph/VFEXDOsRKGHa65wWZUOkNGyWtHc9zT7jLGbdEiQ31pczm2UQQ5oMPA== 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 4X3WkJ73v0z144P; Wed, 11 Sep 2024 07:03:20 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 1CF5065DA; Wed, 11 Sep 2024 08:03:20 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: What rust claims about FreeBSD support (as an example involved in picking languages) Date: Wed, 11 Sep 2024 08:03:08 +0100 Message-Id: <5B5C8A56-3266-457A-A72C-075D5A3D6BF5@freebsd.org> References: Cc: freebsd-hackers In-Reply-To: To: Mark Millard X-Mailer: iPad Mail (21G93) On 11 Sep 2024, at 04:22, Mark Millard wrote: >=20 > An issue for my example (rust) is that as long as FreeBSD > has aarch64 as Tier 1 in FreeBSD terms, might it be that > the rust Tier 3 status of aarch64-unknown-freebsd could > be a problem? Can FreeBSD cover the gap or lead rust to > change the rust Tier 3 status to, say, rust Tier 2 with > Host Tools for aarch64, matching x86_64-unknown-freebsd ? I think this is an important problem, but I see it as a bootstrapping proble= m. There=E2=80=99s no point adding Rust to the base system unless we have pe= ople who are good at writing Rust code and who understand the language well w= ho want to contribute. If we have such people, they are in a good position t= o improve upstream rustc=E2=80=99s FreeBSD support. The same thing happened with Clang. It was written for OS X and ported to Li= nux. I fixed a bunch of small bugs early on where FreeBSD=E2=80=99s calling c= onventions were not quite Linux or not quite OS X, as did a bunch of other p= eople who cared about FreeBSD. This became a much more exciting thing to do o= nce there was a path to Clang replacing GCC in the base system and the Found= ation funded some of the work. By the time we flipped the switch, LLVM had a= FreeBSD buildbot and we had infrastructure to do ports exp runs with now cl= ang versions. David= From nobody Wed Sep 11 08:47:20 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 4X3Z3p5TXpz5W88T for ; Wed, 11 Sep 2024 08:48:38 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3Z3p1dqBz46mx; Wed, 11 Sep 2024 08:48:38 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1726044495; 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: in-reply-to:in-reply-to:references:references; bh=oA2tTlu26rVogXSptzzXkkZhqhk9G5bnmH4HcTWKYS0=; b=hWeaMos6LR9wq8Qt+9t/0QzTvPsApEJdoU6pj6Np0eVAqaFNqvWru637z5MJhCxv+VPkxL kEquCdEHjboLdKvnUPbKLjwwzZLMQkKIQZzVnbiRWxnbHfX0azSH3C/xDNswKVchpZxJjr 2qYFYEGZR+VqiEcYMxGIZFHt3am36akctt06oaNCVdgO9fC7FexoxKCc/Rfj8bU/3bqt/c 9iaYtU6jT8CcpP77pqDuA+rMIZ+EEPeLrWXV01CM/uJYwXRQ2Z7We6Zyw3vLnKdFnK6AdW /uzcJ6A6Ae5VZgtUB9fb6Up+qXfy5IeZUk5HKHPZbxaDOWJebHoRjE6BubUGEA== Date: Wed, 11 Sep 2024 10:47:20 +0200 From: Alexander Leidinger To: Olivier Certner Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) In-Reply-To: <6292298.r39cKavRk3@ravel> References: <202409031532.483FW0If007252@critter.freebsd.dk> <2372745.viN5riZIyJ@ravel> <1fc46e4362bd11816d63027ec8cb8f09@Leidinger.net> <6292298.r39cKavRk3@ravel> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_fb1255fc750c2cc4b451a7a88b31938f"; micalg=pgp-sha256 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:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Queue-Id: 4X3Z3p1dqBz46mx This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_fb1255fc750c2cc4b451a7a88b31938f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-09-10 21:41, schrieb Olivier Certner: >> IMO it doesn't hurt to move the toolchain out of src (...) >> >> (...) I would not want to move everything to ports (...), but I would >> not >> mind having a ports-like approach for src (...) > > To clarify and be sure we are on the same page, I also don't mind what > you describe *provided* there is appropriate tooling to easily: > - Get all the code part of base, and not only for building it. > - Navigate its history, both for code changes but also integration in > base for upstream projects (upstream history is nice, but not enough). > > In other words, I insist on having the same ease of use that we have > today with everything in a single repository. Being able to just build > base *is not enough*. Else, moving things to ports is going to cause > important pain for several use cases such as code inspection and > auditing, collaborative maintenance of code moved to ports, > understanding why/whether some changes have impact on some components, > system consistency, etc. I consider src, ports, and docs as separate repos, not as one repo (we can branch them separately, that's the point of distinction for me). With that POV I do not think it is pragmatic to have the toolchain in the same repo. I understand that it's convenient and less painful, and pragmatic in regards to what you have mentioned, to keep it within a repo in our control (like now, just in parallel to ports/src/doc). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_fb1255fc750c2cc4b451a7a88b31938f Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmbhWScACgkQEg2wmwP4 2IbmAQ//ZIbJR2jJwmvJb/uW9mGz6YPg4tbsBaE8F1wqCYYYZKIpzyGIMPWo56Bo W6ug3FP8Nenz81QHfk2plfk16HAoYV8zorM40Ank2PjnP/RqYYD79C9xZ7sLdKQQ Sa+BCPVdU+C5vWc61kgoRF9RYC5dwZ0HcrhzU4zmuwf91MLzkG9poNK5L2zQQTzt pcLsxqazljYvd6eqmnkx6d418ezmVV+35MXydQpq74/7I8cqbRcdbS9mntTL5Uxr 1D3aw+FyTinEUek9AubTMGORawucquOKJGmo3aq+NrZXALY8ERwF/BkJLMKDN17o kdL5MJ9qI4zoCUzv19BFoaR2QsxLpUFm2F9l4Ayh9rS0NKAVmLH4hjP6gy1cGdVo blLCrLeNh3rqBpr+SR0yOHxAbxWEcaC3ZIXB0zufTFPzZxJXcPXzlKb/hUtWcpwx yNc2VpDZktf18OK7KXpFibqAiy8U4JtNV1rmO6j+2fOPscJS92/1+ioWJxoqRxIk 7gzfCDssc1HSDRzm6zrcuWO6hdyQHa/KwfRjFshUI9fhfsWvda0sxp2hSNdMUqNr pGCvs6CbxtFGkIOWvY4QaHeQtNEzrZdnDSs+63t2kNKrk1fNtWq84iaq3E9nLAne ltylvT4ur8zVnCUd9PlrNXws4sGSvmOeYVvuasPIYr1smigL/tU= =FC0a -----END PGP SIGNATURE----- --=_fb1255fc750c2cc4b451a7a88b31938f-- From nobody Wed Sep 11 09:05:18 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 4X3ZRB6BRCz5WB2X; Wed, 11 Sep 2024 09:05:26 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3ZRB04qPz4BHx; Wed, 11 Sep 2024 09:05:26 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XZDy8rHe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5366fd6fdf1so2272410e87.0; Wed, 11 Sep 2024 02:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726045524; x=1726650324; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=aygyrhQ+/cZDvRSNjzEqcDkc5n4UHMSS0q3kDo8ROik=; b=XZDy8rHeoSRNIob10aLzEwgev209wHvm0C9hqPI8yrGq5+Pqownx9/gjdI0pXltJdR ZnhHKHivvTvARAXuGkuh7otMDmTlXMXISO1yl+UaVwIN72GzK65qKm0NP8gZILBui1Zp dsGJurnd8HlHtq2jcl1AA7TGY+X6t2dc3hYgh8PYjfcsgFIRuYMjtHJW4AKLkVaz2O4O ddnUPVN5XZXT7efl2ITc7zR7NtjbleU0hyY44HCAJ53JrKjzg/J2F+RSmM8CiCAfydVY vaw1P3AyVTeeLdjdxncU4R9XE51xlKPgACeD8+YB6x7csXSgteH3UUQO6bNkOEo7r/vk CgjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726045524; x=1726650324; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aygyrhQ+/cZDvRSNjzEqcDkc5n4UHMSS0q3kDo8ROik=; b=a8h6jY1OEQYvExg+gxcBH+tiAsVIyV9C3CL87QjwRPxZBVwT3oCV7Sac9tlH6pfz99 AzFv1KNzYv2acMDBJT2MX7vJAo7QHhfbdMfmTICBQmHYsJo1Ousg6vT4n1HBUnHYKLwV g5IxDCVxe65G/qcLu2r8TTJl7BDTZZaxUjmgVyGJjEzZ4rZI+9WXJI3KKtmV+TWtbDBB u0+e2ltH+y75SU4H09d/3E6SSg8c1/ipyyLqrbSgAdCY1vlGZVfupGrxneC+kOnTAQbc sLviSzLz2xEKMws0wMeddpzkzQxtHRY4e7W2qiueo1OPw5ExPBenHhEHnxWR2bi3I4dK Ty6Q== X-Forwarded-Encrypted: i=1; AJvYcCU9O2gsRL2NL9BKC3i0VaJhTuMnlu0/XwRydalh3F1obUngb/MLHEDQ41xs6/Mq1mR8frUawRoMPgOtW87nAID3@freebsd.org, AJvYcCUfnW5Ccji0temXzlyfHjObcGTWBmJjmu49Bm4UYaKAezK2xEKTj9rBci/KhnddgdoxCfySysqTjCCe5qs=@freebsd.org, AJvYcCWpzp9DwEFJzU0jpe7tlTucwb8MFjStk/1avOuTdn4vPjcrimbUVbAD38Y5kkxJMLeUy8aK7PgqtC/Xwsg=@freebsd.org X-Gm-Message-State: AOJu0YwmCX2pMGd5uuieeQq6NHed7hx4j1Rl1HGBMULQ0FRGOscNfT3W LpTGY17PVs7KLhz8nw40PSz1o9SLgPGsMF0xbano+X/B6wEo0wrV X-Google-Smtp-Source: AGHT+IHFLBaXxhDXONnQW29ANP0GW0U6/BDTTyLArumdV+Kh1qEDoKIpQr+cVHC495aTj9UXrGCLEQ== X-Received: by 2002:a05:6512:3989:b0:535:3ce5:6173 with SMTP id 2adb3069b0e04-536587f6087mr11930442e87.37.1726045523447; Wed, 11 Sep 2024 02:05:23 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5365f912ee5sm1513806e87.301.2024.09.11.02.05.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Sep 2024 02:05:23 -0700 (PDT) Date: Wed, 11 Sep 2024 12:05:18 +0300 From: Vadim Goncharov To: Philip Paeps Cc: David Chisnall , Poul-Henning Kamp , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240911120518.1ba191b5@nuclight.lan> In-Reply-To: References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> <20240911011228.161f94db@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-Spamd-Bar: --- X-Spamd-Result: default: False [-3.55 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.55)[-0.554]; 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]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-hackers@freebsd.org,freebsd-net@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from]; RCPT_COUNT_SEVEN(0.00)[7]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4X3ZRB04qPz4BHx On Wed, 11 Sep 2024 10:14:44 +0800 Philip Paeps wrote: > On 2024-09-11 06:12:28 (+0800), Vadim Goncharov wrote: > > David Chisnall wrote: > >> BPF can be loaded only by root, who can also load kernel modules > >> and map /dev/[k]mem, and FreeBSD does not protect the root <-> > >> kernel boundary. > > > > Wrong. It is possible for decades to do `chmod a+r /dev/bpf*` and > > run tcpdump as non-root, which will load BPF code into kernel. Is > > *that* also a vulnerability, and if so, why it was never reported? > > This is equivalent to chmod a+w /dev/mem. > > Unwise configuration decisions are not vulnerabilities. But then a possibility to give this to non-root is. And many things are considered vulnerabilitites even if they are only available to root - for example, when root can be tricked into running malicious code etc. (unconscious) actions without direct intention. Equivalency of classic BPF to writable /dev/mem is too loud and controversial statement. Demonstrate how it can be done on stock FreeBSD 13 with /dev/bpf available to attacker (e.g. `sudo tcpdump` allowed). -- WBR, @nuclight From nobody Wed Sep 11 11:01:12 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 4X3d0s2Xf9z5WPq7 for ; Wed, 11 Sep 2024 11:01:17 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3d0r3GX3z4VYL for ; Wed, 11 Sep 2024 11:01:16 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=KGxk24pa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::329 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-42cae4eb026so42745095e9.0 for ; Wed, 11 Sep 2024 04:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726052475; x=1726657275; 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=e9wcYK4mV5NMZmFKz/mkF0wkspgJCJ0nJz2LxfBd0sM=; b=KGxk24pacXm0tGif5bEmW0pudpgnMweZJz0WDnoIla8+/OwGh3BpZMhW3g1i0HUvF0 tYXyGsVBXXndZ71kp0DXnfXlYijB+sUPw11jiDH0rTM3LePHhvcjPNRtomhAHUvXJUM4 p6F4hHMgG2yD5CEjqGjSRXwHyaIVnTa0MlRQKzdfsFqhsDIpqgVhLQH34/5wpjXpIsH9 E5rwTQDqxRJ9TSsE9BjQCkRi3BZyH0pCwrCxH25hHNydFpKbVX41FB5Q2mzGjEteuuL5 lNnjz3Ei7UEqIX9gM94uM+fQQJpZd+pDgHkhyMHpdM6EbDZNMlMVvn4NHD5i9is7eSn6 faVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726052475; x=1726657275; 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=e9wcYK4mV5NMZmFKz/mkF0wkspgJCJ0nJz2LxfBd0sM=; b=xJbM94rEMo6l5ZW4u2vesnEKVpbOX56oB9yLEBkyTsqzs3ydnhIeJNNkIlVFrEQmKM 0JQ0dkYtL+1YzU65rR9apX5AZlWDKJ20CvhADwaTzAXx5Hhwuo6s9I40CsSDitZGT0+h W4UPJVVdN8BnkcGjP87VrzhOsqiccKwyOlVyuoxdCSTsHBNFdBCY5DdQ60r3DPpAfBfW F5/rddsrAuqXZrZNbVtIo1ERJFdWXhhqtyjfw4QUZ45Cbnc4lZCe858q1jnL/RAW0JL3 n2CZe8HpzNVt1m1xqyrWLAZTRa3uE4qPDzSbayW10bl/P9tdo5YmtY93hzXSOsQYxGc3 MIfw== X-Gm-Message-State: AOJu0Yyv54PFGFxjE8z9pDYaRnsXcmsfTKnR+Zz5xanlXypBQWZBRuou u3jim1WoZOMwr8wVgDOM/FCKIl3d7MvoWXv4cTe2buIGO3FBORTennhkLQ== X-Google-Smtp-Source: AGHT+IEfi6lyr8l5EdX5pnz3RPO5fzaYg+GuqJLQioOcNiNZb3hyuxm+THBvPen8s/4pAxH5IkXdyA== X-Received: by 2002:a05:600c:3151:b0:42c:af2a:dcf4 with SMTP id 5b1f17b1804b1-42caf2adf70mr96950535e9.27.1726052473864; Wed, 11 Sep 2024 04:01:13 -0700 (PDT) Received: from ?IPV6:2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb? ([2a01:cb15:801f:7500:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42cb2a08a1dsm119753195e9.1.2024.09.11.04.01.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Sep 2024 04:01:13 -0700 (PDT) Message-ID: <883ce7f6-b5f4-4dc1-9309-f1d3e6333b60@gmail.com> Date: Wed, 11 Sep 2024 11:01:12 +0000 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 any system) 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.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.951]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; 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]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; 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::329:from] X-Rspamd-Queue-Id: 4X3d0r3GX3z4VYL On 06-09-24 08:16, Antranig Vartanian wrote: > One issue with Oberon (and its marketing) is that it relies on a “Garbage > Collector”, which is not that nice for a low-level system programming language. > However, I learned lately that the GC can be fine-tuned to make it hardcoded > during compile time instead of runtime. > > My team is also willing to write a PoC of simple FreeBSD programs in Oberon as > a proof that it works. I already have a PoC of a kernel module in Oberon that > compiles on FreeBSD using voc. > > My point is: yes, we do need better languages. Yes, we do need memory-safety > and better tooling. But is Rust the answer? > > Don’t want to sound like “bragging” but the Rust ecosystem is very new > while us, Wirthians, have been doing memory-safe programming since > the 80s. That's interesting. Does it support all Oberon dialects? I bet it would satisfy most people that want small and fast compilers. A+ Paul From nobody Wed Sep 11 11:21:09 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 4X3dS230wdz5WS1f; Wed, 11 Sep 2024 11:21:22 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3dS20pX2z4ZLd; Wed, 11 Sep 2024 11:21:22 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726053682; 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=f/2x/6NihxJiRrA1BaJGxpPygChNh4vd66EqRwfJEzQ=; b=maL8AuBoi5mVYQcLONv0iPiXg1fht+yMMOqm+CvjlIZ2TPrHMi9ZGyCYl5/f41yk6lW7Ay 4mjJu9HugSIlQ1+4tOkAibwKGMlrQ+aidcxmwVTsF1FZypo8zwcL2E5WGyEJT9GSQNfEvC ni0nvX7vJ5/yCuP12pxQMzj0+ALztRT4/cOkyoyCwY1/DNddFKiB3hTQaNYh2VD2IBCobf iKEHH1G7R4z+CIklTRRDHpXu45QqIFDseS8HhawIAdMxu2GqQXiMntMKiSKkBNkFjdogjD x+9oJ9iH+tQk1UKkcUiSY655Jbz5QchC2Zi66/Gqzt1txr3BGFNIpyE5FEjePw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1726053682; a=rsa-sha256; cv=none; b=nNimEszrCpoKTZ6eJJWhwAeIkHo2A24DEDAvdgJiivd1FIqwZNiub/Z33EjNyXsaSfcuzE dWVBYhhJWEX9/1AHuHv1SaKHBABu083XiZ01F0xJeAvjCALDdUXxhft3lGGr31/gTvucwk wDQPhpMr6wDBhw0cmw2w7T9f/Finaagu948QHlNKzRuFyn5TNGTtknKMcXhHG0UkI9gPMr VjgPnE6pvjG++rumuCEv61882Bjp0slSS3X3lWOuKkRSs0dh7laeX/i1FK+Gl9SmUbunDf YbgQ3NhMijzjqnw4CDXWmRs9TPiZU+7bZ5tkgal32K4YyI4ITRIdAqvaGnaPbw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726053682; 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=f/2x/6NihxJiRrA1BaJGxpPygChNh4vd66EqRwfJEzQ=; b=Jx69LwcELMGUEZggBBlBAssiSMYuDvjr1egy2h9mJd5tLnEClD0COIoplTIy+c5um90GK2 LgvMFdJAlTs7hEWr+K51Cv3bcv1yeYOvGe6sqQJH+1iFjLKSmCzF3DAGDcX2v8C7GbHkfO oJotKy9VmdeIT0K5hUUaKSom344zvg7gtnUcg8P9Sacu1gS9+9dS+K8Fvd9I8px6LO/OXi vGtbjK5016UmhsxxHEoPPJeGUdRF4TrLgmAUNtSUqedLuY7/wwZneASy9wRiAqIL8Nd6Pp DdXKeIWcov6be5miBqLrA7901hcnqcWWPFGMoppQwFB1cdx3Jm3wVHYSFWS2Gw== 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 4X3dS20FYrz18Zn; Wed, 11 Sep 2024 11:21:21 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id F245D65DC; Wed, 11 Sep 2024 12:21:20 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Chisnall 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 (1.0) Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Date: Wed, 11 Sep 2024 12:21:09 +0100 Message-Id: References: <20240911120518.1ba191b5@nuclight.lan> Cc: Philip Paeps , Poul-Henning Kamp , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, tech-net@netbsd.org In-Reply-To: <20240911120518.1ba191b5@nuclight.lan> To: Vadim Goncharov X-Mailer: iPad Mail (21G93) On 11 Sep 2024, at 10:06, Vadim Goncharov wrote: >=20 > But then a possibility to give this to non-root is. And many things are > considered vulnerabilitites even if they are only available to root - > for example, when root can be tricked into running malicious code etc. > (unconscious) actions without direct intention. When the root user intentionality changes some thin from a secure default to= an insecure setting, it is not a security vulnerability in the system that s= hipped the safe defaults.=20 > Equivalency of classic BPF to writable /dev/mem is too loud and > controversial statement. Demonstrate how it can be done on stock > FreeBSD 13 with /dev/bpf available to attacker (e.g. `sudo tcpdump` > allowed). Two things to unpick here. First: Demanding a proof of concept before you accept that something is a vulnerabi= lity is how you build insecure systems. Ask the Matrix team how well that at= titude has worked for them in the last few weeks. You build secure systems b= y defining a threat model and then evaluating primitives against that threat= model, not by throwing together a bunch of primitives and saying =E2=80=98w= ell, *I* can=E2=80=99t assemble them into an exploit and so no one can=E2=80= =99. Second, there are documented attacks on eBPF that give the equivalent of *re= ad* access to /dev/mem. This is why BPF is restricted to root. We have a thr= eat model. The threat model says that we do not need to ensure that BPF cann= ot leak kernel data indirectly because only the user who has the ability to l= eak kernel data directly can use it and this user has a simpler way of achie= ving the same result. If you allow non-root users to run code (native or aga= inst any virtual machine) then you are changing the threat model. You *must*= prevent users from leaking kernel data that they could not leak via existin= g mechanisms. The two most common attacks using eBPF are generally in the following two ca= tegories: - Use eBPF to mount a speculative execution attack on the kernel. Please re= ad up on what these can do. No one should be building a thing that runs code= in the kernel without understanding speculative, cache, and timing side cha= nnels. - Use eBPF to build a set of gadgets that you can then use to go from one m= emory-safety bug in the kernel to arbitrary-code execution. This is the threat landscape in which something in the same space as eBPF mu= st exist. A proposed design should *start* with an explanation of how it mit= igates both of these categories of attack. David From nobody Wed Sep 11 17:47: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 4X3p1r5qpdz5V2bP for ; Wed, 11 Sep 2024 17:47:44 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3p1r13Shz4MRB for ; Wed, 11 Sep 2024 17:47:44 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-502c8f50c5dso33767e0c.0 for ; Wed, 11 Sep 2024 10:47:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726076861; x=1726681661; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MNaEf4l2q9f/C1FVYg50YXSpz3kKGxD4eJ1X0UFBTIo=; b=EBc5B4GT7ouErANqMIjjniTzEDwdwL47FXBp0a20LPIcATiW9qdRO7Hmx5kVO+2Ad+ B9+FomMP1MRR1tQtB4MP7Tv8dzOQ7vbp4fbEUxYPlmU5KE7VmaJsWBrkDHAA4EQYlELS nsNLLhAqP+5OQVs4qwqciu6pl/T0M4Hzmb2avyHKp7J+EqRJ2DJcM8pB+3OKFRHGGkb3 yWTlVX56YdpDjULpzQw5BVa17LhXcG9O3E9cSog67kgiFC97lrdIfSpLY36gvqPCXVcM 9Z/aPlz/I/9YCCYt4qyAuRLqB4Qm1LmV5/1xXrBshptRg7W+6inW7IjSkSVPYmEFoi51 hyxg== X-Gm-Message-State: AOJu0YxHk4ZnqxkqSdMrbgqK2uJp+b7FxSoLhLOTq/8bMbZ8wTU9g7Fg bsqbvoBxh99WY3zo4W+zTQnX5tJBuun6MkmAyTEaLEwhLa0j2mqIcfXwdskDXgcvNja3tU5tzbo NIhgH2s2uQbypmPQbiqKf9xF/JxLlLw== X-Google-Smtp-Source: AGHT+IGSFdT/wxnbiyUqYQqZKJa/TDUB4QK3GY2/W2vddtlWB6wPbSV6RqzKHN21/h8ZhN2z5tjyj4js5GF5vLWGH3U= X-Received: by 2002:a05:6122:1306:b0:4f5:254e:e111 with SMTP id 71dfb90a1353d-5032d40e6a1mr500791e0c.7.1726076861170; Wed, 11 Sep 2024 10:47:41 -0700 (PDT) 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 From: Alan Somers Date: Wed, 11 Sep 2024 11:47:29 -0600 Message-ID: Subject: Clang's MemorySanitizer in userland? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.87 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-0.98)[-0.976]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.05)[-0.049]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.221.173:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.221.173:from] X-Rspamd-Queue-Id: 4X3p1r13Shz4MRB Has anybody successfully used Clang's MemorySanitizer in userland? I'm trying to search for uinitialized memory usage in ZFS. Rather than use KMSan in the kernel, I would prefer to use ztest in userland. But I'm having trouble getting it to work. The main limitation is that every single shared library needs to be rebuilt with MemorySanitizer enabled. Another limitation is that I haven't figured out how to properly link shared libraries that are using MemorySanitizer. And a third limitation is that MemorySanitizer will alert for false positives for syscalls that it doesn't know about. sysctl seems to be one of those. So if anybody has yet used it successfully, I'd love to see your work as an example. From nobody Wed Sep 11 20:05: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 4X3s4R3x59z5VqdG for ; Wed, 11 Sep 2024 20:05:11 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3s4Q6CJYz4bDj for ; Wed, 11 Sep 2024 20:05:10 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=IZ1+L29o; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-374c4c6cb29so183189f8f.3 for ; Wed, 11 Sep 2024 13:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726085109; x=1726689909; 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=EFH0fj4fzn8NMZBm6UvNTGjtgkYsC5iIHizHn/xmpjs=; b=IZ1+L29o5O7x+2UJgsZAJbvBgfX7pH5Lc0CS97YTx2kjs5AIY+X2oo3j3GWxK2yv5Q Qmx7wfW7wuhSsCovnWOaCB5P5vOQz8ISa0LUodQhcPl4D0pR9rtJkrArwc7OGiMhoFLA XMpJZk9ThNt3jI5Af1hYwK5k7/0kizjXZYh5z8eXr773xsLPjjzlir1JC0EMlqsQU640 O48xfYii0dZan1lqKmOnoKpUW9QcAeE+BrvBcpRzXEIrXidZb15GIC3TL0wqTBVoq83h 6A9wLDKYJe6f26wgS1XVY3MmmT6W10++++ibQjoH5KS9wBFNlpEh5n729GOfVuQtbuDN MNew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726085109; x=1726689909; 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=EFH0fj4fzn8NMZBm6UvNTGjtgkYsC5iIHizHn/xmpjs=; b=GgV7Kim8jS1bGd+tCAY8X8vFRoyy1t34ilJf2zdSWC6ZEkewc0W4h5BYnyKBE6H9Re bXHlR4Teijeg8kpaNOpqdZj0QEtJGec8BXRqceO6ZE2/4sf9YTrMD3E22OyHg8WVL5dB wmISzCQjQg6cLLnp460gIQkwa3aJ1o5j+/2ZWzFt6DENzmPPpGWAZFDnpWwYPqRu1TDA +hCcWb1uZ4gM25ec6bFHaJxxSB0DU9rfMSgTDI4eLk1Cw8+gXD+vnLsl/wEpF/RR/oLR zsnn3S+7FQupRWJo7HK1FmXuuDSM8o0VL0v2h9Y+J9e/b01sdtUZn1cXhD19A6J19T5B ZHXA== X-Gm-Message-State: AOJu0YwLs3fiOQQ3Xn+j6OlxlKz2QGQ4dhYBWUwtpsM+YIP52QqxpI7A UBtypb2wTb+JnCTM9oqIxSzdX9/YH9I9t3qtRv1a4NpivSNreRpGjAplLA== X-Google-Smtp-Source: AGHT+IHLMx9VaS+5sEW028I5VYOBonGZfufqi0nsBv0sV7UxDqPwV4lep2MrrccjAQ3HA1gYsIma/Q== X-Received: by 2002:adf:f2d1:0:b0:374:bec7:8f with SMTP id ffacd0b85a97d-378c2d034dfmr268190f8f.28.1726085108615; Wed, 11 Sep 2024 13:05:08 -0700 (PDT) Received: from smtpclient.apple ([2a01:cb15:801f:7500:c179:9a31:82e2:c2d0]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3789564aef9sm12405772f8f.5.2024.09.11.13.05.07 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Sep 2024 13:05:08 -0700 (PDT) From: Paul Floyd 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 \(3731.700.6.1.2\)) Subject: Re: Clang's MemorySanitizer in userland? Date: Wed, 11 Sep 2024 22:05:00 +0200 References: To: FreeBSD Hackers In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3731.700.6.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; 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]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42b:from] X-Rspamd-Queue-Id: 4X3s4Q6CJYz4bDj Have you tried Valgrind? I don=E2=80=99t have much experience with MSAN - Valgrind takes all my = spare time. A+ Paul From nobody Wed Sep 11 20:36:54 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 4X3snR1mrhz5Vv08 for ; Wed, 11 Sep 2024 20:37:15 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3snQ4cDQz4f8c for ; Wed, 11 Sep 2024 20:37:14 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=ultimatedns.net header.s=mx99 header.b=ZwiHUPf4; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 48BKat7m043266; Wed, 11 Sep 2024 13:37:01 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1726087022; x=1726087622; r=y; bh=inpfjgDKlGio5x05/fP7XbnSSFwX037IyGpC6kiAI6o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZwiHUPf4sJnWcXS9LrieX2/4W/NwStS3BAhvbK6GRTSP8MSlz4N70HRcMAAqPae4A 0oT7i96Edv1a9JgeKouYr3xxyVp1DWnCb7+DyDiQ5xsBh9ffMARTZpD3R+JFcyoLBZ iMESBkf/yrvOsQ1iQdeDkpzlK5P3eVGdHDWSS85kLsv4cnO79lkA5Zl45QZTpC9Bxb Yg0yqlQmDHHxiWqXMulE7ZIpzAGYaEFaDC6W3ZpLoveMBHP/X28GuYJtCPbLyoqBdz WFeF06kI2RMfmw2xWQetJ7KnQOJHug1GJOxMbH60lWrF5C8PikEISJPCzRm0B+5Tna qoWk+GNP+e/gA== 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 Date: Wed, 11 Sep 2024 13:36:54 -0700 From: Chris To: Cy Schubert Cc: Jan Knepper , Mark Delany , freebsd-hackers@freebsd.org Subject: Re: Rust: kernel vs user-space In-Reply-To: <20240904221522.63E0366@slippy.cwsent.com> References: <0.2.0-final-1725440949.866-0xb4bb20@qmda.emu.st> <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com> <20240904221522.63E0366@slippy.cwsent.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.80 / 15.00]; R_DKIM_REJECT(1.00)[ultimatedns.net:s=mx99]; R_SPF_ALLOW(-0.20)[+ip4:24.113.41.81/29]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; FROM_HAS_DN(0.00)[]; local_wl_ip(0.00)[24.113.41.81]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[ultimatedns.net:-] X-Rspamd-Queue-Id: 4X3snQ4cDQz4f8c On 2024-09-04 15:15, Cy Schubert wrote: > In message <78BC157F-6E30-49C4-931D-9EB539BD0322@digitaldaemon.com>, Jan > Kneppe > r writes: >> D >> >> www.dlang.org > > The problem with D is data structure definitions need to also be mirrored > (duplicated) in D. For example, when 64-bit inodes were implemented D > failed to build and generate any code. The reason for this was > ufs/ufs/inode.h now defined 64-bit inodes while the D representation as > provided by the D language were still 32-bit. I had opened an issue with > upstream regarding this. To this day they still haven't figured out how to > implement 64-bit inodes on newer FreeBSD systems while maintaining 32-bit > inode backward compatibility on older FreeBSD systems (as FreeBSD > implemented this using ifunc). > Well, why about B? https://en.wikipedia.org/wiki/B_(programming_language) Sorry. I remembered using this *many* years ago, and couldn't resist adding it to the list. :-) --Chris > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 > > >> >> >> >> ManiaC++ >> Jan Knepper >> >> > On Sep 4, 2024, at 05:09, Mark Delany wrote: >> >=20 >> > =EF=BB=BFI hesitate to step into this discussion but is it worth making th= >> e distinction between >> > Rust in the kernel and Rust in user-space? >> >=20 >> > I can see the argument for introducing a "safer" language into the kernel a >> = >> nd there are >> > very few candidates available: perhaps only Rust, C++ and Zig. Clearly if t >> = >> hat step is to >> > be made, it probably should pick one language and run with it. >> >=20 >> > That's one discussion. >> >=20 >> > As for user-space, I find the rationale for Rust as the one-true-language-= >> after-C far less >> > compelling as many CLIs and server programs can just as well be written in= >> more accessible >> > languages such as go or perl or java or... >> >=20 >> > Frankly I no longer write any CLI or server code in C even after decades o= >> f doing so >> > because the trade-off between development costs and performance is far les= >> s compelling in >> > user-space. If my once-a-week invocation of a command requires a bit more m >> = >> emory and CPU >> > than one written in C, is that really important compared to how much easie= >> r the command is >> > to maintain and enhance? >> >=20 >> > Point being, on the matter of introducing Rust to FreeBSD, I think the dis= >> tinction between >> > kernel and user-space is worth keeping in mind as they are quite different= >> problems. >> >=20 >> >=20 >> > Mark. >> >=20 >> >> From nobody Wed Sep 11 21:26: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 4X3ttb4K8hz5W1l8 for ; Wed, 11 Sep 2024 21:26:47 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3ttZ6YmWz4nB1 for ; Wed, 11 Sep 2024 21:26:46 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=PGEmcAjJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of aryeh.friedman@gmail.com designates 2607:f8b0:4864:20::a33 as permitted sender) smtp.mailfrom=aryeh.friedman@gmail.com Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-502af8a83daso109972e0c.1 for ; Wed, 11 Sep 2024 14:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726090006; x=1726694806; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=RCFLjLn2tCdYMEN4bP2hn7EyGc41kLZVlASoIPxvGow=; b=PGEmcAjJe1nPsBycd7f8kIUqDnAqt3qbpyZu/4uJlx8zAzpDpemHJaT+bPB4vd1d/T BDRlbiuxw1t49hTumshhRRY0fPPL9ImtS7nBhtaX2KEbba9UOXBA9sy1bC+S4U9edkpW qfg2jlNf8tHloNA2CtG/bLzfl8gyCnWbHjHPdBOfuDSsfEtDabqUqGRBoTsU7GQ5bLqV 80jO2OJbcIxazo3HSCQXaO2kT1IMutuIeAAQdp6yVqUgjGZR/8KgUEuKngwwVJBProNo 7OhkwGcEF+wOLZVdwplkIiCYNYcsO9gEPO9TyYHdrA8/2ag40r2Afsfw/W18TO3m4Hde b0Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726090006; x=1726694806; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=RCFLjLn2tCdYMEN4bP2hn7EyGc41kLZVlASoIPxvGow=; b=otT2Gw1RgiS2H5RlCq2Xhq/csFwInLkdehJ9OCRhcrpqN3hK8A2Zk8kjRbjlYydJD2 1Y2w4914TnPdKw6qrtsED3N4+Ko9Cf2i6ET4oqvXpkiNB/wzPkBmntvtvnVU6ItMBH1U thWsXT0WaleAvEngT5B74mNCWX3k5YChhz3L/Kdee+QHsNLL4oUrD92no9uzumkb5cX8 8KETz/NGhidVSRV3aMXlmiIjGDGV6SnSy4peBV0rrBsjWpwB5y7N0jZHZcnIVVTzVvKV hfy3iN9O+GpgwiNP8CKfH1fTA1pRzG9/gEOrFbaOsEDRqE4O6LeT8CTFwCJu78/h7t4F fsAA== X-Gm-Message-State: AOJu0Yy03jmySt1oa8Zs7Ivj3XzgExgxq01g7+YE0qk7J/6RYDFQXHo0 0buDs3s0BA72Vd7pBe4y3khJQDN+fCSKOIb2uCIb6aWzJ3qIKyNjGtTigC3GeYPdj4qvETEDoFT pAhQUhNqdS28rvqNbRE7T/K+Ass3ewg== X-Google-Smtp-Source: AGHT+IFh0Kt7jJhAVkJTP6tJLmxe0svjm3yjXIHrq5LAddk7QXILhX96ujd9hZgw5dw4XJOfrsN6wKMKEA1rmBkcy6o= X-Received: by 2002:a05:6122:1310:b0:501:3b5:ae01 with SMTP id 71dfb90a1353d-5032d41a85cmr1052569e0c.5.1726090005506; Wed, 11 Sep 2024 14:26:45 -0700 (PDT) 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 From: Aryeh Friedman Date: Wed, 11 Sep 2024 17:26:34 -0400 Message-ID: Subject: Some rather stupid questions about Rust and FreeBSD To: FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.971]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a33:from] X-Rspamd-Queue-Id: 4X3ttZ6YmWz4nB1 Let's start with the only thing I know about Rust is it is some language that is all the rage among in some corners and not in others. I have built it in ports before when just setting a normal old XFCE4 desktop and looked at some sample code in it from that I will say: 1. It takes FOREVER to compile 2. The code looks no better than portable assembly and if that is the case why does it need to be in the kernel when there is already a perfectly good portable assembly already there known as C? So to help me understand all this fuss can people tell the journalistic (who, what, when, how and why) for the following: 1. What exactly is Rust? 2. What's all the fuss about it over (both here and the larger computing community)? 3. What is the entire debate about ports vs. base and why should a normal user care? -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From nobody Wed Sep 11 22:41: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 4X3wYJ68qZz5WBsx for ; Wed, 11 Sep 2024 22:41:56 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3wYJ1xPyz411g; Wed, 11 Sep 2024 22:41:56 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=ultimatedns.net header.s=mx99 header.b=EL98ovVO; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 48BMfmkY088476; Wed, 11 Sep 2024 15:41:54 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1726094514; x=1726095114; r=y; bh=MG5RAkMtN8mPptIiAeUl4OijFYDN5vlrwUV4bIlgPv8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=EL98ovVOMY4vFZTPRXtC+0RDpSdTloFBAk+gOTAkYJpapxtw8n7ZDWuhBRViB8UvD B2qDm2L4G37SLjsG84bh9KonhowSZ8szNmOvZ//d7P0V7hpWgHKwB0+zewadn25OPd kzS/c3wHGQfKREu3lBAEEHc2GL5Y+zJPv3psIuC7VJ1dQRL5n1m4/D+GogKNZEEq+Q Wp0fwrOESveSCKuztwOOPRPbwR3nBPEchYq1Rm9CvhXzDrUwC+1TeDOM3kI/0BBToy UXpc4bnJVECT+dgH4f8qpsnyvhXJy6IrzaFVnkQFU/Uu4MAFQ37dHkTFpCyl2Z74kZ R6qepMPUyjScQ== 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 Date: Wed, 11 Sep 2024 15:41:48 -0700 From: Chris To: Alan Somers Cc: Warner Losh , FreeBSD Hackers Subject: Re: The Case for Rust (in any system) In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.80 / 15.00]; R_DKIM_REJECT(1.00)[ultimatedns.net:s=mx99]; R_SPF_ALLOW(-0.20)[+ip4:24.113.41.81/29]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[ultimatedns.net:-] X-Rspamd-Queue-Id: 4X3wYJ1xPyz411g On 2024-09-05 13:36, Alan Somers wrote: > On Thu, Sep 5, 2024 at 2:16 PM Warner Losh wrote: >> >> >> >> On Thu, Sep 5, 2024 at 12:10 PM Alan Somers wrote: >>> >>> By now I expect that most of you have seen the long list of new >>> security advisories that just came out. Strikingly, all were the >>> result of memory handling errors. And none of them wouldn't have >>> happened if their respective programs had been written in a >>> memory-safe language. >> >> >> FreeBSD represents hundreds of thousands or millions of man hours >> in its current form (depending on how you measure it). It has evolved >> over 30 years. To get to the same level of maturity in a rust rewrite would >> take a similar amount of time. But even if it took an order of magnitude >> less because rust is that much better, that represents a huge pool of >> manpower that don't seem to be hanging out around the project just >> waiting for something to do. > > Sure. I for one am not volunteering to rewrite CTL next week. > >> >> Where do the resources for this come from? Without enough resources, >> the rewrites will be crap and nobody will want to use them (or maybe even >> FreeBSD). The rewrites to date have lost functionality (though maybe not >> functionality that's important) relative to what they replace. > > Which rewrites are you thinking of? > >> >> So great, we should switch to rust. But so far we have no way to do that >> incrementally (other than a parallel build system, which isn't very >> FreeBSDish). >> And if we can't even find the resources to do that minimal level of work, >> how >> can the rest possibly be robustly undertaken? >> >> Warner > > Your point is obvious; FreeBSD is too big to rewrite the whole thing. > But my point stands: new projects (whether inside of FreeBSD or not) > should almost always be using a safe language. And any component that > needs a major overhaul anyway should probably also be written in a > safe language, too. I don't think the problem is the language. C has proven to be an extremely powerful and capable language. If it were made impotent enough to prevent people from making mistakes. Would it be potent enough to do what needs to be done? IOW the people that use it are the problem. Not the language. Is *any* language that prevents one from shooting themselves in the foot powerful enough to be of any value? I say not. It will always be a matter of quality control, and until humans are made to be infallible. This will thread will continue. I know, I know, it's all philosophical, but still... --Chris From nobody Wed Sep 11 23:02:10 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 4X3x0w2V1Xz5WFsk for ; Wed, 11 Sep 2024 23:02:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3x0v3mqqz44TN for ; Wed, 11 Sep 2024 23:02:23 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.50 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-ot1-f50.google.com with SMTP id 46e09a7af769-710f388621fso165784a34.1 for ; Wed, 11 Sep 2024 16:02:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726095742; x=1726700542; h=content-transfer-encoding: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=q+uxACpCog/kvjjour6DP0ZKgqAzzfyDt5YZzInNi0Y=; b=PGaEx7PgUHqW9Ah5Viv3mn62UJBiDX7yZoGhoKeNimezrBijjtcOMlDG9YCtEITuEl 3fknP+vtnGPhjXlltY7DtSYz5wXgmDoWQGmJQvc3zzVB0WJWESSlocjiTGk8MglYrC4L XsIh+LZvsEt6Qs16EdS8OEmDsUq3JVNQpq13utbkv8B/jEtwasI+zYWLbl90Z1o4rH5q lTWRqZx9KYnBQn/3YPWK2zm7DCZIJixZeBaLhceSEsyJ74S227cJw7TUinYLlMCnI6D5 snnaP/lQZvDQGO4Ok8PInlqjCf9DIzDct3l7AfFENCar8oHxCUhPQTHrsLVIWbDy21wo NqLg== X-Gm-Message-State: AOJu0YyxQfbFx8rJKI5/tzFeFCtO92Nyl2PJaLTn3jDlTp/05R8SsRss LO2ZuNUNv0hU8/wDQMEcMaHM0S9yJfQZFiWsmpj7XN/t7chruB6OgdDzcmynn2vaU2AYUxtBpPd NLHUfDZu+2UmZdwvMRF9eomT/d8XriAbe X-Google-Smtp-Source: AGHT+IG6qU0Qa2rtxrcfUnicH2XyhS2qI2ElFplRP8j4AqtRZKzDwtpU9pjdfb4+hDAFlloJproLdDwjbOBaYawev4I= X-Received: by 2002:a05:6808:2f08:b0:3df:1625:d993 with SMTP id 5614622812f47-3e071b0b6dfmr750172b6e.34.1726095742224; Wed, 11 Sep 2024 16:02:22 -0700 (PDT) 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: Alan Somers Date: Wed, 11 Sep 2024 17:02:10 -0600 Message-ID: Subject: Re: Some rather stupid questions about Rust and FreeBSD To: Aryeh Friedman Cc: FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.15 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.94)[-0.938]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; NEURAL_HAM_MEDIUM(-0.22)[-0.217]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.210.50:from]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; R_DKIM_NA(0.00)[]; FREEFALL_USER(0.00)[asomers]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.50:from] X-Rspamd-Queue-Id: 4X3x0v3mqqz44TN On Wed, Sep 11, 2024 at 3:26=E2=80=AFPM Aryeh Friedman wrote: > > Let's start with the only thing I know about Rust is it is some > language that is all the rage among in some corners and not in others. > I have built it in ports before when just setting a normal old XFCE4 > desktop and looked at some sample code in it from that I will say: > > 1. It takes FOREVER to compile I assume you mean lang/rust. It does take FOREVER to compile, because it builds its own version of LLVM. That's why I suggest adding it to ALLOW_MAKE_JOBS_PACKAGES , if you're using Poudriere. Ordinary Rust programs generally compile at a similar speed as C programs. Slower than Go, but faster than C++. > 2. The code looks no better than portable assembly and if that is the > case why does it need to be in the kernel when there is already a > perfectly good portable assembly already there known as C? I don't know if you're being serious or trolling. I ought to assume the former, but if you genuinely can't tell the difference between Rust and assembly source code then you obviously haven't looked at one or the other for more than a few seconds. So I think you must be exaggerating, and you really mean "Rust looks no more or less readable than C". For a good example of why Rust (and other modern languages) can be more readable than C, compare these examples, which sort an array: in C =3D=3D=3D=3D int compare(const void* a, const void* b) { return (*(int*)a - *(int*)b); } int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 }; int n =3D sizeof(arr) / sizeof(arr[0]); qsort(arr, n, sizeof(int), compare); in Rust =3D=3D=3D=3D=3D=3D=3D let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]; arr.sort(); The most visible difference is that C needed a comparison function to be provided, and that function must be defined far away from where the sort happens. With Rust, the comparison operator is a property of the data type (technically, it's defined by the data type's PartialOrd implementation, which can be derived automatically for most structs but can also be manually implemented). But readability isn't the important part. Notice that in C, the programmer must tell qsort * The size of the array * The size of each element * The name of the comparison function Each of those is error-prone. Stuff like that is a common source of bugs in C code. But Rust tracks it automatically. > > So to help me understand all this fuss can people tell the > journalistic (who, what, when, how and why) for the following: > > 1. What exactly is Rust? It's a compiled, strongly and statically typed, memory-safe, systems programming language. It first appeared 9 years ago, sponsored mostly by Mozilla. Mozilla was interested because web browsers are too complicated to reliably program in C/C++, but too performance-critical for other memory-safe contemporary languages like Java or Go. > 2. What's all the fuss about it over (both here and the larger > computing community)? The computing community in general is excited because Rust really hits a programming language design sweet spot. Modern features like modules and procedural macro make Rust highly productive. Its safety features make Rust code more reliable than C/C++ code. And yet most of that safety is achieved at compile-time, incurring 0 runtime overhead. So Rust is faster than other memory-safe languages like Java and Go. Crucially, it isn't memory-managed like those two, so it's suitable for systems programming and even for embedded systems. > 3. What is the entire debate about ports vs. base At this time, there is absolutely no reason not to use Rust for programs that will live in ports. Nobody is arguing about that. However, there is quite a lot of code in the base. Much of it can't move to ports, because it's too tightly coupled to the kernel or to other stuff in base. And the fact that we ship our own compilers in base limits the base to sh, C and C++ (plus a little bit of Lua). That limitation is a big impediment to both our productivity and our code quality. Some of us would like to use better languages in the base (mostly Rust, but Go and Oberon fans have chimed in too), but it just isn't possible. Making it possible would require either: 1) Importing the Rust toolchain into contrib/ (currently the least favored option, because compile times are too long) 2) Allowing some parts of the base to depend on an external toolchain (what Shawn Webb is currently working on) 3) Being more like Linux, meaning that the base system will slim down to be little more than a kernel while many other programs move to ports. > and why should a normal user care? It probably won't make a difference to a pure desktop user or a non-programming sysadmin. If anything, they'll just notice that their operating system of choice gets less buggy. Error messages might look a little bit different. The size of the .iso download might increase. But it will make a big difference to developers, even occasional ones. We'll all be more productive, and we'll build a higher-quality product. Occasional developers will have more confidence that their changes won't cause regressions. I hope that helps. From nobody Wed Sep 11 23:13:44 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 4X3xGF0qFHz5WHMP for ; Wed, 11 Sep 2024 23:13:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3xGD6Gltz45rj for ; Wed, 11 Sep 2024 23:13:56 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-49bc672bb46so144477137.2 for ; Wed, 11 Sep 2024 16:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726096436; x=1726701236; h=content-transfer-encoding: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=6GtGqPGax+vMplbKTN+HdWckoxjHFlMpGdluodONGGk=; b=T+LEjlkLolKqeC0cZrAOXVeHqfzUi0jhbj1HQ0hN1z+EK3ADUUyIP1pHPm7vwh3t4e mSYUkRi8eEdfbVD6+noVrzxPJvD0mKTH9flzI0S9IHlNrDlJ20IWdxtjOcJbxEM3gRSj m7iD3gzAHPr+gak14r6Fse3gvupbRLZktstNlYFg3i9flTWHJafmW0WX1YcMVKpmcB85 pRxRTZrTqluRKvlZ3ZRZKnJucfxBWiNI9pLvEEviN9HUN9anFcoLMqtbL1oTKu7pGBvr tZoJY1xLCitrrWYKRjN1Id/JX8WqI8Hx4f3lyZ2nNTQxgX/+nT3zi0sWbqrgqPWYelqG e1RQ== X-Forwarded-Encrypted: i=1; AJvYcCXIuMFnJJUQSsFrRgqL+R2YVakQyucZTyyyryASKZwvmAGkdQ3mw7bmLd1kdqNc64DtNqsvyTbOkwdFabWKTZA=@freebsd.org X-Gm-Message-State: AOJu0YxxHq5fAuEaSYMtBardNvrQv6pKqs7Bo7ZEsXMQycxrlW4jTAXr GBOkJ38OBjLPZimJDG72RsbhcRBB6z//3KYRvTwX4Oix2rOZ4F4j/5mG+xL2IazCYQ0l/pJStjM 6sk8/CqMxPC0H5ptb4d7CDAcLYPN91A== X-Google-Smtp-Source: AGHT+IEhJ4adGR/ob7jgPhVH4oCQfiUaYuQmhQjvnIW40oSXEoFWAzq//KCbVBQFy1IAhK0qjYuRtSIgn6jTE1ZCFd0= X-Received: by 2002:a05:6102:4424:b0:49a:1ccd:35c7 with SMTP id ada2fe7eead31-49d4155e8dfmr1303891137.19.1726096435771; Wed, 11 Sep 2024 16:13:55 -0700 (PDT) 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: Alan Somers Date: Wed, 11 Sep 2024 17:13:44 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Chris Cc: Warner Losh , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X3xGD6Gltz45rj On Wed, Sep 11, 2024 at 4:41=E2=80=AFPM Chris wrot= e: > > On 2024-09-05 13:36, Alan Somers wrote: > > On Thu, Sep 5, 2024 at 2:16=E2=80=AFPM Warner Losh wro= te: > >> > >> > >> > >> On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM Alan Somers wrote: > >>> > >>> By now I expect that most of you have seen the long list of new > >>> security advisories that just came out. Strikingly, all were the > >>> result of memory handling errors. And none of them wouldn't have > >>> happened if their respective programs had been written in a > >>> memory-safe language. > >> > >> > >> FreeBSD represents hundreds of thousands or millions of man hours > >> in its current form (depending on how you measure it). It has evolved > >> over 30 years. To get to the same level of maturity in a rust rewrite = would > >> take a similar amount of time. But even if it took an order of magnitu= de > >> less because rust is that much better, that represents a huge pool of > >> manpower that don't seem to be hanging out around the project just > >> waiting for something to do. > > > > Sure. I for one am not volunteering to rewrite CTL next week. > > > >> > >> Where do the resources for this come from? Without enough resources, > >> the rewrites will be crap and nobody will want to use them (or maybe e= ven > >> FreeBSD). The rewrites to date have lost functionality (though maybe n= ot > >> functionality that's important) relative to what they replace. > > > > Which rewrites are you thinking of? > > > >> > >> So great, we should switch to rust. But so far we have no way to do th= at > >> incrementally (other than a parallel build system, which isn't very > >> FreeBSDish). > >> And if we can't even find the resources to do that minimal level of wo= rk, > >> how > >> can the rest possibly be robustly undertaken? > >> > >> Warner > > > > Your point is obvious; FreeBSD is too big to rewrite the whole thing. > > But my point stands: new projects (whether inside of FreeBSD or not) > > should almost always be using a safe language. And any component that > > needs a major overhaul anyway should probably also be written in a > > safe language, too. > I don't think the problem is the language. C has proven to be an extremel= y > powerful and capable language. If it were made impotent enough to prevent > people from making mistakes. Would it be potent enough to do what needs t= o be > done? > IOW the people that use it are the problem. Not the language. Is *any* > language > that prevents one from shooting themselves in the foot powerful enough to= be > of any value? I say not. It will always be a matter of quality control, a= nd > until humans are made to be infallible. This will thread will continue. > I know, I know, it's all philosophical, but still... "Memory safety =3D=3D restrictive training wheels" is just a common misconception. I've personally written 100k SLOC in Rust and I've very rarely found anything that the compiler "won't let me do". (TBH It does very rarely happen, because of certain patterns that the borrow checker doesn't understand, but the extra effort I've had to spend to overcome those cases is dwarfed by the effort that I would've expended to solve the same problems in C). And if you *really* need to break the rules, there's always the `unsafe` keyword. If you've never used a more modern systems programming language than C, then I encourage you to try one out for a few months. You won't regret it. -Alan From nobody Wed Sep 11 23:57:17 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 4X3yDM44CTz5VtfM; Wed, 11 Sep 2024 23:57:23 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3yDM25B7z4FPd; Wed, 11 Sep 2024 23:57:23 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2f7528f4658so3540351fa.3; Wed, 11 Sep 2024 16:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726099041; x=1726703841; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=BTPaR5wX0V190g/8+LMON57KsrpCZmF7qQI/FvvC2Eo=; b=PzmCM5AwJk1+Q33RogTWyofj6rh8QWyOOeG2ic+sqIhpV+4MUS336FCYh9UMVgM2ij 6/YOIHwh8IvPdJ34RqSDqHWspqPesiUwKw19rhDOEo/N51SvBI226a5v1PjAq9a7LTlP g8OBsBbcMFr8+qgcDf29puSLcQUQ8FQ0Z3pEAnVO+t5W7qGtYIHMc2g3yPuvlpTDjHbu 0Uan+7ktxA+qncYUpCdI5TE6nJEIT/uB6GdKUV1k9wNPilc+XuZ7eKSMN32FbbY3bzPt x8/etQq60KBVO1K8NTrkIb71ZzzZkkH61yjanLojZ9QBz5upmbjSCTk50aXkNAyYBRRX 11Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726099041; x=1726703841; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BTPaR5wX0V190g/8+LMON57KsrpCZmF7qQI/FvvC2Eo=; b=Ty+wEIgCCgpYQFMwkygd6eOe+7ImdCuVr+JKgJl/xHBM7G7DgCRlEO5TQtUvj5PjcW DR9E6iTnI8aOtrbBueg2+FNeQ8pSf/vV5meZgchEwPr4VOlJcbwoBD+9+H47ViqNCiLH vO+kwwaPQEq/sUdw7/cZbIUspobfXFd2wvuXNocsBiLwDRcSvhXzDRermzvLPQqoAQK/ JqUUeewsRp2rTUod60VqgLxJBFXbGdhrdHHwHLGxiopGW8fRSmNi8mnjjFlfOTCQ7wZ9 3ASt7IM2uCbqKojS9N6e0T220fLECh21O5mDafeSAa7AmAcoSz0e0NmYToREz+HhxNYj c2vQ== X-Forwarded-Encrypted: i=1; AJvYcCVL8OZtSsiUnabVOX1pjaihQjzwv0PTnukQzOXxLEw6/JB51GNwMKm1ed3Xga1TsSnBsL9TshTjm3zEraM=@freebsd.org, AJvYcCVQ7NSSj1FXVG/MxG4zFSvIWQZMK2IeXke47w0ORiSHbW28ieGhtOcHMmkqbrk1bQ8KoJ1fD5JjgOKKWiA2c0mX@freebsd.org, AJvYcCWNMiTIVfl3EJD1J+o9PFxAQe4hgMzoyW5EIHFYuTGgENrUTLa7slAr2vQ2VQvbjNY77gUQ7VGcgKiqGnk=@freebsd.org X-Gm-Message-State: AOJu0Yyar0aj7zuPTn/Kgrk4Qnrv9VAbfOy5KD/QOwuUJcDx2GteMKCC XE404ntEafb2c5pI9a8Bupxet00EjyH4NelqF9GDnCoF8cGbpDTosPc93YEh X-Google-Smtp-Source: AGHT+IEB8ksEThG5HzDJjvPwwBoIofOrfOch9Ucn/tK7deg+YJt5CHaIIOQyMT9bCCvQTwHNfo1qfA== X-Received: by 2002:a05:651c:2105:b0:2f3:ac52:416b with SMTP id 38308e7fff4ca-2f787f33a2cmr3863201fa.35.1726099040895; Wed, 11 Sep 2024 16:57:20 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f75bfe6aecsm17094201fa.5.2024.09.11.16.57.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Sep 2024 16:57:20 -0700 (PDT) Date: Thu, 12 Sep 2024 02:57:17 +0300 From: Vadim Goncharov To: David Chisnall Cc: Philip Paeps , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, tech-net@netbsd.org Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240912025717.455295f1@nuclight.lan> In-Reply-To: References: <20240911120518.1ba191b5@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-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] X-Rspamd-Queue-Id: 4X3yDM25B7z4FPd On Wed, 11 Sep 2024 12:21:09 +0100 David Chisnall wrote: > On 11 Sep 2024, at 10:06, Vadim Goncharov > wrote: > >=20 > > But then a possibility to give this to non-root is. And many things > > are considered vulnerabilitites even if they are only available to > > root - for example, when root can be tricked into running malicious > > code etc. (unconscious) actions without direct intention. =20 >=20 > When the root user intentionality changes some thin from a secure > default to an insecure setting, it is not a security vulnerability in > the system that shipped the safe defaults.=20 This is just not true. See, for example, FreeBSD-SA-17:06.openssh for vulnerability disabled by default, and workaround proposed to return to default (disabled) state. > > Equivalency of classic BPF to writable /dev/mem is too loud and > > controversial statement. Demonstrate how it can be done on stock > > FreeBSD 13 with /dev/bpf available to attacker (e.g. `sudo tcpdump` > > allowed). =20 >=20 > Two things to unpick here. First: >=20 > Demanding a proof of concept before you accept that something is a > vulnerability is how you build insecure systems. Ask the Matrix team > how well that attitude has worked for them in the last few weeks. You > build secure systems by defining a threat model and then evaluating > primitives against that threat model, not by throwing together a > bunch of primitives and saying =E2=80=98well, *I* can=E2=80=99t assemble = them into an > exploit and so no one can=E2=80=99. >=20 > Second, there are documented attacks on eBPF that give the equivalent > of *read* access to /dev/mem. This is why BPF is restricted to root. Stop. Just stop, and re-read carefully. You (and perhaps Philip) confusing two things: BPF and eBPF (and BPF64 third), all completely different beasts. Last two letters in this thread, I was talking about classic BPF existing in *BSD for decades (on FreeBSD allowed to have permissions on dev/bpf*). So you assert that THIS classic BPF also vulnerable to aforementioned attacks, and thus SA must be issued, just like that FreeBSD-SA-17:06.openssh, with a fix (at least preventing changing default permissions) of hole existing for *decades*. This is too strong assertion to be accepted without proofs, and as I can deduce from your other words and readings about Spectre (see below), this statement is not true (classic /dev/bpf is not vulnerable). > We have a threat model. The threat model says that we do not need to > ensure that BPF cannot leak kernel data indirectly because only the > user who has the ability to leak kernel data directly can use it and > this user has a simpler way of achieving the same result. If you > allow non-root users to run code (native or against any virtual > machine) then you are changing the threat model. You *must* prevent > users from leaking kernel data that they could not leak via existing > mechanisms. >=20 > The two most common attacks using eBPF are generally in the following > two categories: >=20 > - Use eBPF to mount a speculative execution attack on the kernel. > Please read up on what these can do. No one should be building a > thing that runs code in the kernel without understanding speculative, > cache, and timing side channels. >=20 > This is the threat landscape in which something in the same space as > eBPF must exist. A proposed design should *start* with an explanation > of how it mitigates both of these categories of attack. Again, you are talking about eBPF here, not classic BPF. So far Spectre was mentioned as example of those speculative, cache, and timing side channels: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) refers to mitigations e.g. in Firefox - https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/ with key phrase "The precision of performance.now() has been reduced from 5=CE=BCs to 20=CE= =BCs," So to prevent this class of attacks you need to deprive untrusted code from (precise) timers. And if we then go eBPF sources, we see at https://elixir.bootlin.com/linux/v6.10/source/include/uapi/linux/bpf.h#L1884 * u64 bpf_ktime_get_ns(void) * Description * Return the time elapsed since system boot, in nanoseconds. * Does not include time the system was suspended. * See: **clock_gettime**\ (**CLOCK_MONOTONIC**) This is because eBPF is used in Linux as one-catch-all for tracing and profiling - they do not have DTrace. And we have. And BPF don't need to be DTrace and don't need timers. Thus, we can conclude, your eBPF assertion is simply not applicable to *BSD classic BPF, and consequently, to current state of BPF64 which don't include any timers or time sources available to user code at all. > - Use eBPF to build a set of gadgets that you can then use to go > from one memory-safety bug in the kernel to arbitrary-code execution. This requires further explanations (including to ensure we're not mixing things again). As far as I can see currently, this is also not applicable to BPF64 due to lack of pointers. --=20 WBR, @nuclight From nobody Thu Sep 12 00:11: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 4X3yXQ27mNz5VwXd for ; Thu, 12 Sep 2024 00:11:18 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3yXN5L10z4JQS; Thu, 12 Sep 2024 00:11:16 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-49bcf6b9b64so146396137.1; Wed, 11 Sep 2024 17:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726099875; x=1726704675; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZoyTEu8SLmnGS5TrYh141y9+0cQNU1jdkhHPCNY6Xfw=; b=D+6lXjj+XSh188W0E5N6eSHFXwV0pIQyRRj1H9xElnt5p7a48Cd/7lBq0q87li1hdm XAUcrqQVnpYm+JKLK94Zu6KDxzF7Hy5x/8GcJGQCYarOO524B8OdcxL8nvDK7JHybRYR JQAtxHJoX6q8ZDAMBPB3SP+PSr9CCGo7FJeT/G1jK7SAXUYTTtQbJrEN9/TKvZwFwz32 QH+M38AOLr6D+FuHsxi4BtWSt93jYR0hjj/P7qM+08jBZtE5PsV7a4D3jHLDIMQauSXn 4J3mUlsf6VdfHAh9fvm7oXpiy4ZG/siychcdLYw4jTZ5WbCHF7lE1UzbmZLQ6nxi5QRv riRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726099875; x=1726704675; h=content-transfer-encoding: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=ZoyTEu8SLmnGS5TrYh141y9+0cQNU1jdkhHPCNY6Xfw=; b=iBnapl3G+TsR1gdDPSaWkoDRQTnF1U4c5tiUqBjD4rurOKPuBzlScFZljeTvuFkccm 7U4hUUqB7nSxv3jrga1PnmLK506PE4YIsU5dXodXW9CTmB9Es69GssfYNL0mWSe2sMAU HIWilxth/PvR191TDkWiozW+uaPgi8a9dDQK4WQhmFLu1BipJSwmMl5ca1C8nlAGTrWb oGgmlXS4Vz7+3s8FqYR/bH+e+WfnOJJsWS6M6fc6bCcQYQERC9T46v6J4XBM6tP5ZiL9 bm4k85oc+94N3qBPg3FsdJRotfn9wcMNSBq63+V+5mFTDZSEYppr+78rmH9kh8eAdPWy NJgg== X-Gm-Message-State: AOJu0YxHWadeRYwiaUaAISPW3on4k3If+yZtviKTCSTjzWdrHOFoH7Q+ sQzNSCaTHfZsi7xalvTSpxPjaex5CM/KryBcf/jYbl6m9ty00JCbVT61kPgfi8CKsmVamFEMn+7 TwVa1BLawiX2WymJg7xqUVgp0AwTDQw== X-Google-Smtp-Source: AGHT+IFNyWX3+Z+xWva6ZAWoaU+df/DZy8kmHJeHj6uvVbnwkKhmqG3a/xkHfQvGEef4o/1dKpi06CZ1rRsPrirHE7Y= X-Received: by 2002:a05:6102:2920:b0:492:a93d:7cab with SMTP id ada2fe7eead31-49d41460d54mr1533603137.1.1726099874603; Wed, 11 Sep 2024 17:11:14 -0700 (PDT) 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: Aryeh Friedman Date: Wed, 11 Sep 2024 20:11:03 -0400 Message-ID: Subject: Re: Some rather stupid questions about Rust and FreeBSD To: Alan Somers Cc: FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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] X-Rspamd-Queue-Id: 4X3yXN5L10z4JQS On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers w= rote: > > 2. The code looks no better than portable assembly and if that is the > > case why does it need to be in the kernel when there is already a > > perfectly good portable assembly already there known as C? > > I don't know if you're being serious or trolling. I ought to assume > the former, but if you genuinely can't tell the difference between > Rust and assembly source code then you obviously haven't looked at one > or the other for more than a few seconds. If I had wanted to troll instead of genuinely out of pure curosity I could of compared all three languages to a language I am currently writting to use in a forth come PhD thesis that is purefly function, gate level (with abstractions allowed), has no explicit flow control except for calling functions and few other really oddball things. But I am not going to say anything more about that and instead focus on why I made the comment I did: 1. C when super optimized has about a 2 to 1 ratio between expressions and emitted machine instructions but it self is semantically much easier to deal with then assembly and the fact it is a high level language means it in theory portable to any machine a compiler is implemented on. 2. I consider assembly fairly high level actually compared to the topic I am not trolling on (I am at the level of building UTM's from gates) > So I think you must be > exaggerating, and you really mean "Rust looks no more or less readable > than C". For a good example of why Rust (and other modern languages) > can be more readable than C, compare these examples, which sort an > array: > > in C > =3D=3D=3D=3D > int compare(const void* a, const void* b) { > return (*(int*)a - *(int*)b); > } I completely agree pointers are evil and that's why I (like Rust it appears) *ONLY* allow arrays and array references not direct pointers into physical address space. This way we still have the advantage of being able to use base+offset addressing modes instead of having the language processor/executor compute absolute addresses at run time. > > int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 }; > int n =3D sizeof(arr) / sizeof(arr[0]); > qsort(arr, n, sizeof(int), compare); So C is not OO (what a surprise ;-)) but it does do one thing right is it separates out the concerns of storage from processing at the lowest levels (hard to get above that level and that is why I use Java for my freelancing work). Which when working in any language is a good idea but since C is not OO we are stuck with naked function calls (no harm in that) > > in Rust > =3D=3D=3D=3D=3D=3D=3D > let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]; > arr.sort(); The fact the data structure even worries about behaviour instead of being passable to objects is asking for it (this is from my software engineering hat). Also the fact there is no explicit size of the array defined since if it is static a Turing complete process can be implemented on it but if it is dynamic how do you keep from overflowing the storage allocated to it (aka buffer overflow). > * The size of the array Very good idea from the resource management POV > * The size of each element Again correct call for an OS level language. > * The name of the comparison function Separation of concerns *STANDARD* software engineering. > > Each of those is error-prone. Stuff like that is a common source of > bugs in C code. But Rust tracks it automatically. At the cost of coupling stuff far too tightly it appears. From nobody Thu Sep 12 00:26: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 4X3ysn4Gflz5Vym1; Thu, 12 Sep 2024 00:26:21 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3ysm1GqYz4M7X; Thu, 12 Sep 2024 00:26:20 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jwlbnWxx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2f75b13c2a8so5057741fa.3; Wed, 11 Sep 2024 17:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726100778; x=1726705578; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=cYoWHowlaxUIxtahmcQwJ2VDHGzi1OZKXzI/rYfVDfY=; b=jwlbnWxxnS3GL55mBLX7gZVXBFiLGIH6ljRENO0LaB7+MvHFU6HyLoxk2xjm9r1MVG nzOupoNR1juC06bUH7ztouZ8OmeDJvm3ANvXie/aJT2eAkM4oHbKxa+KA35IStImsB80 VkbAHPu2Z1ac6pcJp0QQcE3oQ8tpKuaJlpg2kYTMn4Nx9Q6sQP2YCidDnKVEFZysF08X cw0sBym2ZtBI3luefdW57cQ+CZBBxzhB787cmzTOR8pOTnoBKh0Dcy6AYgF7QT5G4LaD OBhNy9/nGF0UXanf595IigXVJNpZT9MhASvXk+VqVFJ/AB0YypWP+29jbiSOsvxMVfgl 859g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726100778; x=1726705578; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cYoWHowlaxUIxtahmcQwJ2VDHGzi1OZKXzI/rYfVDfY=; b=QHuYbXeqzgI6Usji1e+EsSYrqy/hSedlFg8knMbInCtcLzYGAtkGWkKZQubNHHgUpd KdI25OwI+gIlDsxlwm/nqpGxGu6prGxEmJ6Q4fCU11HawmiDJzm7SkW9Rx2xFQwoQwZu d0dXCfD1tAaY9lfMJKSSIT0MJzR7OJRdBX7UUuAHDuC1eFBXslqJG9aQDSY0aTj6m+D7 kfAa1P28kD3Q0e6wJ10/iBh6kL71AMXl3z625mUFmsqTQ2g5VtIAe1/oAEnaibFQhElE 2fr/mhd/p1FPEDS1DW46WS0RYdOay8ViQSnjC6RqSsVz2jmYlMgg8TJrZuO8Rac7gQJJ mt5w== X-Forwarded-Encrypted: i=1; AJvYcCXA9etlJIVR002cenHH3bT6WDke6MlfLSnoxs9gerNtSntBDhCXik4xncyF7FaU/vd4pS4NnyALtnZ81LhS/fQ=@freebsd.org, AJvYcCXLT6KCfkdn3b141C114OgYlBzyBQda5gqEGQJUDpAtQdKGm/du4106tMPPzp31W6EpPHBtYIn2G5lQHwU=@freebsd.org X-Gm-Message-State: AOJu0YykR4+1ZRuVWKuiyv71VpVMllbdl9PvhLUu0F5MV+DyVLQfHYmH AHkR7HYAdTzpsuYC6FMdLqaO+xsnv6efYvqhKRlbmB/swlz7JdIU X-Google-Smtp-Source: AGHT+IFG03hcxcakfjwOaJGlKdhk0XrccinW5TqrwyPuUhlOiQiPNISLM95vPsD6s52zTxb4QtHeBw== X-Received: by 2002:a2e:a553:0:b0:2f7:631a:6e21 with SMTP id 38308e7fff4ca-2f787ed5c6amr4932251fa.24.1726100777473; Wed, 11 Sep 2024 17:26:17 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f75c008f6csm17091391fa.59.2024.09.11.17.26.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Sep 2024 17:26:17 -0700 (PDT) Date: Thu, 12 Sep 2024 03:26:14 +0300 From: Vadim Goncharov To: Rob Wing Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" Subject: Re: That's how (why) BSD is dying (Was: BPF64) Message-ID: <20240912032614.36796b03@nuclight.lan> In-Reply-To: References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> <20240911011228.161f94db@nuclight.lan> <20240911024735.37522532@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) 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-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::233:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-hackers@freebsd.org,freebsd-net@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4X3ysm1GqYz4M7X On Tue, 10 Sep 2024 16:55:15 -0800 Rob Wing wrote: > On Tuesday, September 10, 2024, Vadim Goncharov > wrote: > > > > > > What's the point to waste resources on writing thing that is known > > to be not accepted to base system from the very beginning? > > > what's the point of talking about thing you're never going to > write/finish even if it was accepted? Because - and I've written that from the beginning - wrong architecture will cost too much if your code already exists, than if fixed before that. So I've received worthy feedback describing problems; not that were good solutions yet, though... > Or even bikesheds are in short supply now? > > have you considered calling it eBPF++ or BPF128? Well, first it was called fBPF as next letter from eBPF, and for 128 it lacks 128 bit arithmetics. Then I realized that for some things there will be different implementations in different kernels, e.g. for atomic(9) operations, so better to call generic common thing neutral BPF64 and e.g. fBPF be FreeBSD dialect, nBPF for NetBSD dialect... > at any rate, don't claim the sky is falling on the grounds that I > think your proposal is far fetched Not you. FreeBSD already had precedent when already written and committed code framework for device sensors was removed: https://lists.freebsd.org/pipermail/cvs-src/2007-October/082398.html and that happened by exactly the same person with similar tone (not you). ...well, ok, there were some really technical arguments in that case e.g. about sysctl_add_oid() but that was the most technical of them, all other being same arrogant rant. Anyway, such cases are very demotivating from contributing. > if you think you've got a great idea and have a need for it, then > write it and use it - if other people adopt it, even better > > all the best to your endeavors and don't let the naysayers hold you > back Well, what I really need is a technical help for areas I don't know, as obviously I won't be able to write entire ecosystem alone. For example, I don't know how many registers are available to a function in a kernel on an ARM, MIPS and RISC-V. If I allocate too much, then somebody will have trouble implementing JIT on such machine, as I don't have such hardware. And e.g. https://en.wikipedia.org/wiki/MIPS_architecture says 2 registers are for kernel - OK, and what if we are kernel itself? :-) Do we need Thread Pointer of Global Pointer, or we can stash them to stack? Etc. -- WBR, @nuclight From nobody Thu Sep 12 00:36: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 4X3z5p59XBz5W1Wk for ; Thu, 12 Sep 2024 00:36:46 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3z5n2xk2z4QTZ; Thu, 12 Sep 2024 00:36:45 +0000 (UTC) (envelope-from estrabd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=WWUuZKyH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of estrabd@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=estrabd@gmail.com Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5c3d20eed0bso396494a12.0; Wed, 11 Sep 2024 17:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726101404; x=1726706204; 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=Mq5aCm6rtzNA7ZguL1ETepzlauDVV+9YuD8v9vBqcDA=; b=WWUuZKyHSwkZ4/PPx5XxvoqqF07f5Z5o2hIFE8ka5MQcCdWq3idXeS02MW2WsnhaK+ UrZNu3K0gxmo5eHW4aS6pX218tBBsmFM2+khrS4UJSYUqkirl39s/QT2zT6zqbJpOnEE 4+gv34NYeFjQ4SL80/1SjZ0FQj/48bizkNxf/+SZHG6pm+w4OIow77u0wi+mQpCK2IXg pHH7y3Rri/bMWnNeasZl6nE2Q32jf8hX18uQCH2STUNvDAjY1K+6OQW1/374DNi9UBf6 15Lmg9H9HUpHjE4yIft4NRnOT5/hzngnVKYrOlSd9tkwsj3IvJOsSHMA75bgGf5BlQNh 7LXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726101404; x=1726706204; 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=Mq5aCm6rtzNA7ZguL1ETepzlauDVV+9YuD8v9vBqcDA=; b=RO26uLDeoltGXvlFRXhGjqwWrgvLO6lSJoMB0RBuun/by3L+9wNIlc8clT6afMrW6f nt4cm9yMKlpknE/HNi5dZWns9LuOMpsSaWpOLbdcsXjxVP54RTuUu9hxmRXB6cpwQMbR kKaNtk0CjvIpgZ18JhR7DBu4o6TaGY9mL5qrcVIJ9gj08BYdW89kHPbZHKhsXPOqJSiF uLAi81qzwcetmV32oeweHpe7znL9nQe7x9PPj8UooZw8QBRfpzRrUVuiDFznGbqTErVR IkXYcCP3XHiG53HKwcY1Wy+Ou2wT9j/yEQW0LoAALtt0CjoRKEwN1du/DiV+OQ1HhEmZ EX/Q== X-Forwarded-Encrypted: i=1; AJvYcCVRE6btORK2v5aL7YximPXuJGM4uA+sL7iNDW6Op2EzmE5YvZy46n2ihtTNfkvx0rNuLFc5IORcSIbhAqaefNA=@freebsd.org X-Gm-Message-State: AOJu0YzUiQA+SHjAoLE+utyODN3tGVjAKIVtlQBhyjf/k4H/I1Zhu/Ep XtjMsj/9MXWa/ZE9LcEMVjO8+y3ORtLuzhHYaBdZiYZFevkv7rNF+NiJUaV4Rznq1cmzVMFjAVH JpIkFf7m58vpbA2BOeetg1nGgZhU= X-Google-Smtp-Source: AGHT+IGJ3z2QmrjzrePFn6ILb13wBoPWGZnKm8yR+CzpjlbyrrVq1/bZvKIvtaZlDRKvprkdAHZwlGyTP2Mb50ZNjqE= X-Received: by 2002:a17:907:26c3:b0:a72:50f7:3c6f with SMTP id a640c23a62f3a-a9029432757mr82081666b.14.1726101403534; Wed, 11 Sep 2024 17:36:43 -0700 (PDT) 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: Wed, 11 Sep 2024 19:36:06 -0500 Message-ID: Subject: Re: Some rather stupid questions about Rust and FreeBSD To: Aryeh Friedman Cc: Alan Somers , FreeBSD Mailing List Content-Type: multipart/alternative; boundary="000000000000010f730621e14d99" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; 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]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4X3z5n2xk2z4QTZ --000000000000010f730621e14d99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It doesn't matter the technicalities, Rust enthusiasts are looking for relevancy in a post-language wars world; and they think falsely that their only recourse is to invade established camps. I feel sorry for them in a lot of ways, but this is the time for them to be discovering problem domains or creating solutions that Rust is uniquely good for; and not copying or corrupting established technical communites. Augmenting FreeBSD *somehow* is not a legitimate problmem domain nor is it something uniquely solved by Rust. Don't be a solution in search of a problem is my best advice to the Rust community - unfortunately much of the low hanging problems have been picked; but there are plenty of slightly less easy problems to solve. So, this is ideologically and existentially driven, and rational arguments are not enough (FreeBSD is not experiencing this alone). Setting extremely hard boundaries, in charity, is the only answer. I am a mere casual but consistent user of FreeBSD from a long time ago, and I very strongly support all firm (but charitable) opposition to Rust being required to run FreeBSD. Cheers, Brett On Wed, Sep 11, 2024 at 7:11=E2=80=AFPM Aryeh Friedman wrote: > On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers = wrote: > > > > 2. The code looks no better than portable assembly and if that is the > > > case why does it need to be in the kernel when there is already a > > > perfectly good portable assembly already there known as C? > > > > I don't know if you're being serious or trolling. I ought to assume > > the former, but if you genuinely can't tell the difference between > > Rust and assembly source code then you obviously haven't looked at one > > or the other for more than a few seconds. > > If I had wanted to troll instead of genuinely out of pure curosity I > could of compared all three languages to a language I am currently > writting to use in a forth come PhD thesis that is purefly function, > gate level (with abstractions allowed), has no explicit flow control > except for calling functions and few other really oddball things. > But I am not going to say anything more about that and instead focus > on why I made the comment I did: > > 1. C when super optimized has about a 2 to 1 ratio between expressions > and emitted machine instructions but it self is semantically much > easier to deal with then assembly and the fact it is a high level > language means it in theory portable to any machine a compiler is > implemented on. > > 2. I consider assembly fairly high level actually compared to the > topic I am not trolling on (I am at the level of building UTM's from > gates) > > > So I think you must be > > exaggerating, and you really mean "Rust looks no more or less readable > > than C". For a good example of why Rust (and other modern languages) > > can be more readable than C, compare these examples, which sort an > > array: > > > > in C > > =3D=3D=3D=3D > > int compare(const void* a, const void* b) { > > return (*(int*)a - *(int*)b); > > } > > I completely agree pointers are evil and that's why I (like Rust it > appears) *ONLY* allow arrays and array references not direct pointers > into physical address space. This way we still have the advantage of > being able to use base+offset addressing modes instead of having the > language processor/executor compute absolute addresses at run time. > > > > > int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 }; > > int n =3D sizeof(arr) / sizeof(arr[0]); > > qsort(arr, n, sizeof(int), compare); > > So C is not OO (what a surprise ;-)) but it does do one thing right is > it separates out the concerns of storage from processing at the lowest > levels (hard to get above that level and that is why I use Java for my > freelancing work). Which when working in any language is a good idea > but since C is not OO we are stuck with naked function calls (no harm > in that) > > > > > in Rust > > =3D=3D=3D=3D=3D=3D=3D > > let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]; > > arr.sort(); > > The fact the data structure even worries about behaviour instead of > being passable to objects is asking for it (this is from my software > engineering hat). Also the fact there is no explicit size of the > array defined since if it is static a Turing complete process can be > implemented on it but if it is dynamic how do you keep from > overflowing the storage allocated to it (aka buffer overflow). > > > * The size of the array > > Very good idea from the resource management POV > > > * The size of each element > > Again correct call for an OS level language. > > > * The name of the comparison function > > Separation of concerns *STANDARD* software engineering. > > > > > Each of those is error-prone. Stuff like that is a common source of > > bugs in C code. But Rust tracks it automatically. > > At the cost of coupling stuff far too tightly it appears. > > --000000000000010f730621e14d99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It doesn't matter the technicali= ties, Rust enthusiasts are looking for relevancy in a post-language wars wo= rld; and they think falsely that their only recourse is to invade establish= ed camps.

I feel sorry for them in a lot of w= ays, but this is the time for them to be=20 discovering problem domains or creating solutions that Rust is uniquely goo= d for; and not copying or corrupting established technical communites. Augmenting FreeBSD somehow is no= t a legitimate problmem domain=20 nor is it something uniquely solved by Rust. Don't be a solution in=20 search of a problem is my best advice to the Rust community -=20 unfortunately much of the low hanging problems have been picked; but=20 there are plenty of slightly less easy problems to solve.
<= br>
So, this is ideologically and existentially driven, and ratio= nal arguments are not enough (FreeBSD is not experiencing this alone). Sett= ing extremely hard boundaries, in charity, is the only answer. I am a mere = casual but consistent user of FreeBSD from a long time ago, and I very stro= ngly support all firm (but charitable) opposition to Rust being required to= run FreeBSD.

Cheers,
Brett
<= /div>

On Wed, Sep 11, 2024 at 7:11=E2=80=AFPM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
On Wed, Sep 11, 20= 24 at 7:02=E2=80=AFPM Alan Somers <asomers@freebsd.org> wrote:

> > 2. The code looks no better than portable assembly and if that is= the
> > case why does it need to be in the kernel when there is already a=
> > perfectly good portable assembly already there known as C?
>
> I don't know if you're being serious or trolling.=C2=A0 I ough= t to assume
> the former, but if you genuinely can't tell the difference between=
> Rust and assembly source code then you obviously haven't looked at= one
> or the other for more than a few seconds.

If I had wanted to troll instead of genuinely out of pure curosity I
could of compared all three languages to a language I am currently
writting to use in a forth come PhD thesis that is purefly function,
gate level (with abstractions allowed), has no explicit flow control
except for calling functions and=C2=A0 few other really oddball things.
But I am not going to say anything more about that and instead focus
on why I made the comment I did:

1. C when super optimized has about a 2 to 1 ratio between expressions
and emitted machine instructions but it self is semantically much
easier to deal with then assembly and the fact it is a high level
language means it in theory portable to any machine a compiler is
implemented on.

2. I consider assembly fairly high level actually compared to the
topic I am not trolling on (I am at the level of building UTM's from gates)

> So I think you must be
> exaggerating, and you really mean "Rust looks no more or less rea= dable
> than C".=C2=A0 For a good example of why Rust (and other modern l= anguages)
> can be more readable than C, compare these examples, which sort an
> array:
>
> in C
> =3D=3D=3D=3D
> int compare(const void* a, const void* b) {
>=C2=A0 =C2=A0 =C2=A0 return (*(int*)a - *(int*)b);
> }

I completely agree pointers are evil and that's why I (like Rust it
appears) *ONLY* allow arrays and array references not direct pointers
into physical address space.=C2=A0 =C2=A0This way we still have the advanta= ge of
being able to use base+offset addressing modes instead of having the
language processor/executor compute absolute addresses at run time.

>
> int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 };
> int n =3D sizeof(arr) / sizeof(arr[0]);
> qsort(arr, n, sizeof(int), compare);

So C is not OO (what a surprise ;-)) but it does do one thing right is
it separates out the concerns of storage from processing at the lowest
levels (hard to get above that level and that is why I use Java for my
freelancing work).=C2=A0 =C2=A0Which when working in any language is a good= idea
but since C is not OO we are stuck with naked function calls (no harm
in that)

>
> in Rust
> =3D=3D=3D=3D=3D=3D=3D
> let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66];
> arr.sort();

The fact the data structure even worries about behaviour instead of
being passable to objects is asking for it (this is from my software
engineering hat).=C2=A0 =C2=A0Also the fact there is no explicit size of th= e
array defined since if it is static a Turing complete process can be
implemented on it but if it is dynamic how do you keep from
overflowing the storage allocated to it (aka buffer overflow).

> * The size of the array

Very good idea from the resource management POV

> * The size of each element

Again correct call for an OS level language.

> * The name of the comparison function

Separation of concerns *STANDARD* software engineering.

>
> Each of those is error-prone.=C2=A0 Stuff like that is a common source= of
> bugs in C code.=C2=A0 But Rust tracks it automatically.

At the cost of coupling stuff far too tightly it appears.

--000000000000010f730621e14d99-- From nobody Thu Sep 12 01:33: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 4X40MT24HBz5W9qh for ; Thu, 12 Sep 2024 01:33:41 +0000 (UTC) (envelope-from vishwin@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X40MT1ZWnz4bw1; Thu, 12 Sep 2024 01:33:41 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726104821; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=2rFgi46dp/uuAkkRyuecMK0blojZlQeDoIIUOwvUbsE=; b=iZ28Ahc1BOMinXf9O07DFecfv+lYoeVoVtepsNHeDs4Xx0Wsk0apz8js3ao2lVKDqkKodq xo+ur7KqjKBflfGlSVHDb/MeN84PBxyJyxpxg5H3+alhk20/AIUkfpI6vFYwOSssI9SSVx VN2G+MFXHn4/CQACAeBjGKnwBZ3c7pXxmHqlZDgf/X0E4BMhD+vNCov3G+M1maZ0urJXSx Qt/Ij2JXMPSCm7h9bBa4dYuK576dovtOLJYFE1gLMcEgWMDCBc3LE4oDPjVO8L4y71f4Y4 55f5Qvue+cc7QbcnuVPR/pOxz0bFtn4JRVLyJlkPTpKOUBVAsufoj5iO6UcL8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1726104821; a=rsa-sha256; cv=none; b=U8qvADAFQx3tIYZsSiZ6DqD+QJ9tID0ZRZHgghgBmZfiyEpEIrdNsjzwRrIQO30qV+7bO4 iF93A3p09kamwz+v3ntkNxZ6kjEFVEjHA+Ub9xQ1VbPDVs5zolhJhnKZAneGBW0WgLUBGk YUy7QZNxWGQl0uoHLSSaf1Z6Zz9Z1KLJF46Kq+u+7NC8A8jsdhCEhjHHvIMZGkXpdO/PSH WCLvQgaFG6NpJBzTDSug8XrUcsB/INtCf7Rq+ld/OJFdV2dW/ULjzsdeLGhp9PcuRCiL6A rFj3p0/N60MptiXDZWYh0onBBCZcN9jw40lMFgRZ5UU26WdveTiFJjgE7ylmAA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726104821; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=2rFgi46dp/uuAkkRyuecMK0blojZlQeDoIIUOwvUbsE=; b=NgzPb3cB3uEt5WxBjjtOTReetDPrj5WuSG2EpgFArpEa1AzD5vtE3AkwL4JUef4cSnwkqJ m/zBZjhk2ddVJkM/HuagokGViFKSxnMfyIKEnqjCqNnHSDSkRfzzwP8kku0miVjwQsM1+k 2q07QJlBwlBOgRIKvzAmG9QUpkxJrWP46S2KnOVysk4FksjXI6Vs2meTEfCjCgGvnDEFw7 nia9QqELmB+kRERsatPaNs14/VYCqFcEoMGXiq5fBitw94aE/SplVUSb+ozXWyAUoFc4Ks XKO3mFd6dbPILx20BhEuTY11JI9301LERlvnkCjSsRg9KoooUcGoPjQ3GolQoA== Received: from [0.0.0.0] (unknown [IPv6:2601:98a:d00:c180:461e:a1ff:fe02:14dc]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X40MS5wMNz1RgY; Thu, 12 Sep 2024 01:33:40 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <33fc2e5d-f135-4770-9ba6-cfae3a4ad120@freebsd.org> Date: Wed, 11 Sep 2024 21:33:39 -0400 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: Some rather stupid questions about Rust and FreeBSD To: Alan Somers , Aryeh Friedman Cc: FreeBSD Mailing List References: Content-Language: en-US From: Charlie Li Autocrypt: addr=vishwin@freebsd.org; keydata= xjMEZFWWqBYJKwYBBAHaRw8BAQdAINFDmM+bgGkT1C4nD5a3BxgcH8Xnx5qTJbPuIBxD57LN MkNoYXJsaWUgTGkgKEZyZWVCU0QgUHJvamVjdCkgPHZpc2h3aW5ARnJlZUJTRC5vcmc+wpkE ExYKAEEWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIbAwUJA+3ogAULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgAAKCRBnj5NgWEFcyllaAP9CGICFEvTUOv5BYh/H8m49VJ87a/wd 0obeQfVBnS464AD9FopTHbjEs0HDV0ZYmJPxzJIznjumsj9gBxX0bBqqTgzOOARkVZaoEgor BgEEAZdVAQUBAQdA6BUWuG5RuT0vmtoDyCUUqiJGdtd78GM5ic3kw2AntSADAQgHwn4EGBYK ACYWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIbDAUJA+3ogAAKCRBnj5NgWEFcyn55 AP9ezKDCUgHqAq6JX976abb9pYdbSjxxNJqnrjgNkfhgIQD/QhR+fgnUHhcGTMBy+pYHZUGH 5DCuITsK1U4+v252uws= Organization: FreeBSD Project In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------09chxmLnKvo31bpReFePsscJ" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------09chxmLnKvo31bpReFePsscJ Content-Type: multipart/mixed; boundary="------------A2I0QCXLFXoF2TDqTWzgkfws"; protected-headers="v1" From: Charlie Li To: Alan Somers , Aryeh Friedman Cc: FreeBSD Mailing List Message-ID: <33fc2e5d-f135-4770-9ba6-cfae3a4ad120@freebsd.org> Subject: Re: Some rather stupid questions about Rust and FreeBSD References: In-Reply-To: --------------A2I0QCXLFXoF2TDqTWzgkfws Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QWxhbiBTb21lcnMgd3JvdGU6DQo+IE9uIFdlZCwgU2VwIDExLCAyMDI0IGF0IDM6MjbigK9Q TSBBcnllaCBGcmllZG1hbiB3cm90ZToNCj4+IDEuIEl0IHRha2VzIEZPUkVWRVIgdG8gY29t cGlsZQ0KPiANCj4gSSBhc3N1bWUgeW91IG1lYW4gbGFuZy9ydXN0LiAgSXQgZG9lcyB0YWtl IEZPUkVWRVIgdG8gY29tcGlsZSwgYmVjYXVzZQ0KPiBpdCBidWlsZHMgaXRzIG93biB2ZXJz aW9uIG9mIExMVk0uICBUaGF0J3Mgd2h5IEkgc3VnZ2VzdCBhZGRpbmcgaXQgdG8NCj4gQUxM T1dfTUFLRV9KT0JTX1BBQ0tBR0VTICwgaWYgeW91J3JlIHVzaW5nIFBvdWRyaWVyZS4gIE9y ZGluYXJ5IFJ1c3QNCj4gcHJvZ3JhbXMgZ2VuZXJhbGx5IGNvbXBpbGUgYXQgYSBzaW1pbGFy IHNwZWVkIGFzIEMgcHJvZ3JhbXMuICBTbG93ZXINCj4gdGhhbiBHbywgYnV0IGZhc3RlciB0 aGFuIEMrKy4NCj4gDQpydXN0YyAobGFuZy9ydXN0KSBzdXBwb3J0cyB1c2luZyBhbiBleGlz dGluZyBMTFZNIHRvb2xjaGFpbiANCihkZXZlbC9sbHZtKikuIFNpbmNlIExMVk0gOC4wLCB0 aGUgUnVzdCBQcm9qZWN0IG1haW50YWluIHRoZWlyIGNvcHkgb2YgDQpMTFZNIG5lYXJseSB0 aGUgc2FtZSB3YXkgd2UgZG8gaW4gYmFzZSwgYW5kIGFzIHN1Y2ggdHJhY2sgdGhlIGxhdGVz dCB0d28gDQpyZWxlYXNlIGJyYW5jaGVzLiBVc2luZyB0aGUgUE9SVF9MTFZNIG9wdGlvbiBp biB0aGUgcG9ydCByZWR1Y2VzIHRoZSANCmJ1aWxkIHRpbWUgc2lnbmlmaWNhbnRseSAoZnJv bSBub3QgYnVpbGRpbmcgTExWTSkgd2l0aCBubyBjaGFuZ2UgaW4gDQpydW50aW1lIGJlaGF2 aW91ci4NCg0KLS0gDQpDaGFybGllIExpDQouLi5ub3BlLCBzdGlsbCBkb24ndCBoYXZlIGFu IGV4aXQgbGluZS4NCg== --------------A2I0QCXLFXoF2TDqTWzgkfws-- --------------09chxmLnKvo31bpReFePsscJ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZuJE8wUDAAAAAAAKCRBnj5NgWEFcyoKe AP41519CIKeuKvKGLKeGUEN+IRDwaSjYU4D3ix9rdISp0AD/XAQ4PoHYSHU3yrKohanaGPqUdP4Z kZ2qNRl6YLRMtgU= =qK4a -----END PGP SIGNATURE----- --------------09chxmLnKvo31bpReFePsscJ-- From nobody Thu Sep 12 01:38:18 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 4X40T35V5nz5WB8v for ; Thu, 12 Sep 2024 01:38:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X40T33mmHz4dj6; Thu, 12 Sep 2024 01:38:31 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-502bb8ebd2aso146868e0c.1; Wed, 11 Sep 2024 18:38:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726105110; x=1726709910; 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=QIkANoCnhHWZYoHMsui9TYUJQ4mQlINDb7OhbdYTfFg=; b=j/2vH/27lp4D7A+yEDp+PXkPmmMN3k0wNCinCmoScUGAxL8RrjHvM1UgJm4PZZnun6 0CjbxXIRR2C0QOK48pmbhkaeIyW4aE9RmE5+oIt/OzBY4ymKcWvnfQ8sLeV8gcTgadWH H6F/wQ6QfA55SQnekwa2/rT7adogUyCRsayXy+0MWU2+PJzKLqulVhDmz43HHJMJMNCP 6rq+pfVtCGVCHtbCsuzd7jwUjH+QLntBep4rbYmLVZ4VJT2o//1nOSM2ytDpr5/qAj7+ lS6RlWqMb4HK6GaoJnU0RxmaHcIw4DVBZ3gDzqoIjHgfr7nUG5BbMdJ//bCw72zcLaxe xl5Q== X-Forwarded-Encrypted: i=1; AJvYcCXeAS7MiDUDo7IghcN9PiKHLlMd2ZxNhQiVB40it6edwbxxq+RXGdW94lYEM6lVJwR7blGNp8C0rJjB7HjfNvY=@freebsd.org X-Gm-Message-State: AOJu0YyUXJigMtXb+3XGxvKBQ0nXneiRih8O++l1FzyRqr8nY6TdF4IE pq85tL5Hs/RCPZwoHUpEPj87glOd9api66DJcAfZfQtRrFFsUPsiVBa/rLr9Krstu1IU4tI9Ohk bWRJjvYZYJgruOY67X3g2BI1dseJUVA== X-Google-Smtp-Source: AGHT+IGTrYz2R0bTt9T6O8tyrmiEfYoSXk1Wx4XeurZykN3xRCagGuk8+GqHYfgkvu45PAzStMqsSW+tU6xi97+caOI= X-Received: by 2002:a05:6122:a02:b0:4f6:b610:61bf with SMTP id 71dfb90a1353d-5032d4bbf94mr1336918e0c.8.1726105109970; Wed, 11 Sep 2024 18:38:29 -0700 (PDT) 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: <33fc2e5d-f135-4770-9ba6-cfae3a4ad120@freebsd.org> In-Reply-To: <33fc2e5d-f135-4770-9ba6-cfae3a4ad120@freebsd.org> From: Alan Somers Date: Wed, 11 Sep 2024 19:38:18 -0600 Message-ID: Subject: Re: Some rather stupid questions about Rust and FreeBSD To: Charlie Li Cc: Alan Somers , Aryeh Friedman , FreeBSD Mailing List Content-Type: multipart/alternative; boundary="000000000000ecc7140621e229a6" 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_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X40T33mmHz4dj6 --000000000000ecc7140621e229a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 11, 2024, 7:33=E2=80=AFPM Charlie Li wrot= e: > Alan Somers wrote: > > On Wed, Sep 11, 2024 at 3:26=E2=80=AFPM Aryeh Friedman wrote: > >> 1. It takes FOREVER to compile > > > > I assume you mean lang/rust. It does take FOREVER to compile, because > > it builds its own version of LLVM. That's why I suggest adding it to > > ALLOW_MAKE_JOBS_PACKAGES , if you're using Poudriere. Ordinary Rust > > programs generally compile at a similar speed as C programs. Slower > > than Go, but faster than C++. > > > rustc (lang/rust) supports using an existing LLVM toolchain > (devel/llvm*). Since LLVM 8.0, the Rust Project maintain their copy of > LLVM nearly the same way we do in base, and as such track the latest two > release branches. Using the PORT_LLVM option in the port reduces the > build time significantly (from not building LLVM) with no change in > runtime behaviour. > Oh, sweet. I need to try that out. What's the downside? Do you know why it isn't the default? > --000000000000ecc7140621e229a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 11, 2024, 7:33=E2=80=AFPM Charlie Li <<= a href=3D"mailto:vishwin@freebsd.org">vishwin@freebsd.org> wrote:
Alan Somers wrote:=
> On Wed, Sep 11, 2024 at 3:26=E2=80=AFPM Aryeh Friedman wrote:
>> 1. It takes FOREVER to compile
>
> I assume you mean lang/rust.=C2=A0 It does take FOREVER to compile, be= cause
> it builds its own version of LLVM.=C2=A0 That's why I suggest addi= ng it to
> ALLOW_MAKE_JOBS_PACKAGES , if you're using Poudriere.=C2=A0 Ordina= ry Rust
> programs generally compile at a similar speed as C programs.=C2=A0 Slo= wer
> than Go, but faster than C++.
>
rustc (lang/rust) supports using an existing LLVM toolchain
(devel/llvm*). Since LLVM 8.0, the Rust Project maintain their copy of
LLVM nearly the same way we do in base, and as such track the latest two release branches. Using the PORT_LLVM option in the port reduces the
build time significantly (from not building LLVM) with no change in
runtime behaviour.

=
Oh, sweet.=C2=A0 I need to try that out. What's the d= ownside? Do you know why it isn't the default?
<= div class=3D"gmail_quote">
--000000000000ecc7140621e229a6-- From nobody Thu Sep 12 01:51: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 4X40mM5gzCz5WDwr for ; Thu, 12 Sep 2024 01:51:47 +0000 (UTC) (envelope-from d@l.ynx.fr) Received: from mailer.daserv.fr (daserv.fr [91.121.223.74]) (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 4X40mL1CRtz4jYd for ; Thu, 12 Sep 2024 01:51:45 +0000 (UTC) (envelope-from d@l.ynx.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ynx.fr header.s=YNX_KEY header.b=hMEE8zeP; dmarc=pass (policy=reject) header.from=ynx.fr; spf=pass (mx1.freebsd.org: domain of d@l.ynx.fr designates 91.121.223.74 as permitted sender) smtp.mailfrom=d@l.ynx.fr Received: from [127.0.0.1] (unknown [192.168.199.7]) (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) (No client certificate requested) by mailer.daserv.fr (Postfix) with ESMTPSA id 02A42874D for ; Thu, 12 Sep 2024 03:51:35 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mailer.daserv.fr 02A42874D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ynx.fr; s=YNX_KEY; t=1726105897; bh=ft7REDbherQXRazCvxC/RLqmy3XNrx23cRzuXuJJvac=; h=Date:From:To:Subject:In-Reply-To:References; b=hMEE8zePZ3ioBpN+hRT6DPMezBegydWasm2JedGh2VTHwEFw+EliMwiERFaRhwdpR eXV9aaGcL8+DgljKNzGDsXThkgJgV8gxoEnbQ20n0xNBznBofjbn7bkM2x65QkxlJ8 bUymSS8fGaXBiS0exqYwvfhUdko9XNN3u7Ffopao= Date: Thu, 12 Sep 2024 01:51:28 +0000 From: DaLynX To: freebsd-hackers@freebsd.org Subject: Re: Some rather stupid questions about Rust and FreeBSD In-Reply-To: References: Message-ID: <2B36D92F-FC9F-488E-85E1-978D67F5BE24@l.ynx.fr> 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=----M8FKJ23YGJG3QUX0RL3T45WV8U17VS Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ynx.fr,reject]; R_DKIM_ALLOW(-0.20)[ynx.fr:s=YNX_KEY]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.74]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ynx.fr:+] X-Rspamd-Queue-Id: 4X40mL1CRtz4jYd ------M8FKJ23YGJG3QUX0RL3T45WV8U17VS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 12 septembre 2024 00:11:03 UTC, Aryeh Friedman a =C3=A9crit : >On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers wrote: >> >> in Rust >> =3D=3D=3D=3D=3D=3D=3D >> let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]; >> arr=2Esort(); > >The fact the data structure even worries about behaviour instead of >being passable to objects is asking for it (this is from my software >engineering hat)=2E Also the fact there is no explicit size of the >array defined since if it is static a Turing complete process can be >implemented on it but if it is dynamic how do you keep from >overflowing the storage allocated to it (aka buffer overflow)=2E > >> * The size of the array > >Very good idea from the resource management POV > >> * The size of each element > >Again correct call for an OS level language=2E > >> * The name of the comparison function > >Separation of concerns *STANDARD* software engineering=2E > >> >> Each of those is error-prone=2E Stuff like that is a common source of >> bugs in C code=2E But Rust tracks it automatically=2E > >At the cost of coupling stuff far too tightly it appears=2E > Hi, I am more of an IT security guy by trade and just do programming for fun b= ut I have played with Rust=2E I think your worries are very legitimate but = come from a lack of knowledge or understanding of the language=2E - Size questions are not absent from the language=2E They are explicit=2E = Even more than in C (I do not need to know the arch to know that an u32 is = 32 bit and a u64 is 64=2E)=2E They do not appear at the sort function level= because it is automatically taken into account by the compiler through typ= ing=2E - The vector we are looking at here (which technically is automatically ty= ped as a Vector, I believe) is a container class, pretty much like the= STL's vector in C++=2E It keeps track of its length (and capacity, whic= h you can also work with if you need to be precise about that)=2E - You seem to worry that the sort function is implemented at the data stru= cture level, like you would do by putting a method in a class, coupling too= tightly to your taste behaviour with structure=2E This is not really the c= ase=2E Rust works with traits: there is an Ord trait, for which you provide= an implementation for the types you want to work with, then the sort funct= ion automatically applies to any type implementing that trait=2E You seem to think the sort function is defined in the vector's class becau= se you look at the "=2E" like it accessed the member of a C struct=2E It is= not=2E That's just syntaxic sugar=2E The sort function is implemented sepa= rately, agnostically, taking anything that implements the Ord trait as argu= ments=2E So that behaviour is totally separate from the data structure, and= applies to a Vector of anything that implements an Ord trait (a comparison= function)=2E (Actually you can work with a PartialOrd too if you don't have a total ord= er, with some extra precautions=2E) And of course you can just use vec=2Esort_by(f) if you want to provide a s= pecific comparison function that is different from the one in the Ord trait= for your data type=2E So if you prefer to keep the separation explicit tha= t way, you can=2E It's just coding guidelines=2E As I said, I think the points you raise are most pertinent and legitimate= =2E But making your opinion of another language just based on brief example= s sent to you by email will never be enough to let you construct a complete= , accurate and thus fair opinion of it=2E So to anyone who doesn't know rust I advise to take some time to look at i= t and play with it=2E That's how we all learn=2E I hope that's constructive=2E Kind regards, DaLynX ------M8FKJ23YGJG3QUX0RL3T45WV8U17VS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Le 12 septembre 2024 00:11:03 = UTC, Aryeh Friedman <aryeh=2Efriedman@gmail=2Ecom> a =C3=A9crit :
= >On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers <asomers@freebsd= =2Eorg> wrote:
>>
>> in Rust
>> =3D=3D=3D=3D= =3D=3D=3D
>> let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]= ;
>> arr=2Esort();
>
>The fact the data structure even= worries about behaviour instead of
>being passable to objects is ask= ing for it (this is from my software
>engineering hat)=2E Also the fa= ct there is no explicit size of the
>array defined since if it is sta= tic a Turing complete process can be
>implemented on it but if it is = dynamic how do you keep from
>overflowing the storage allocated to it= (aka buffer overflow)=2E
>
>> * The size of the array
&g= t;
>Very good idea from the resource management POV
>
>&g= t; * The size of each element
>
>Again correct call for an OS l= evel language=2E
>
>> * The name of the comparison function<= br>>
>Separation of concerns *STANDARD* software engineering=2E>
>>
>> Each of those is error-prone=2E Stuff like th= at is a common source of
>> bugs in C code=2E But Rust tracks it a= utomatically=2E
>
>At the cost of coupling stuff far too tightl= y it appears=2E
>

Hi,

I am more of an IT security guy b= y trade and just do programming for fun but I have played with Rust=2E I th= ink your worries are very legitimate but come from a lack of knowledge or u= nderstanding of the language=2E

- Size questions are not absent from= the language=2E They are explicit=2E Even more than in C (I do not need to= know the arch to know that an u32 is 32 bit and a u64 is 64=2E)=2E They do= not appear at the sort function level because it is automatically taken in= to account by the compiler through typing=2E

- The vector we are loo= king at here (which technically is automatically typed as a Vector<u32&g= t;, I believe) is a container class, pretty much like the STL's vector<T= > in C++=2E It keeps track of its length (and capacity, which you can al= so work with if you need to be precise about that)=2E

- You seem to = worry that the sort function is implemented at the data structure level, li= ke you would do by putting a method in a class, coupling too tightly to you= r taste behaviour with structure=2E This is not really the case=2E Rust wor= ks with traits: there is an Ord trait, for which you provide an implementat= ion for the types you want to work with, then the sort function automatical= ly applies to any type implementing that trait=2E

You seem to think = the sort function is defined in the vector's class because you look at the = "=2E" like it accessed the member of a C struct=2E It is not=2E That's just= syntaxic sugar=2E The sort function is implemented separately, agnosticall= y, taking anything that implements the Ord trait as arguments=2E So that be= haviour is totally separate from the data structure, and applies to a Vecto= r of anything that implements an Ord trait (a comparison function)=2E
(Actually you can work with a PartialOrd too if you don't have a total or= der, with some extra precautions=2E)

And of course you can just use = vec=2Esort_by(f) if you want to provide a specific comparison function that= is different from the one in the Ord trait for your data type=2E So if you= prefer to keep the separation explicit that way, you can=2E It's just codi= ng guidelines=2E

As I said, I think the points you raise are most pe= rtinent and legitimate=2E But making your opinion of another language just = based on brief examples sent to you by email will never be enough to let yo= u construct a complete, accurate and thus fair opinion of it=2E

So t= o anyone who doesn't know rust I advise to take some time to look at it and= play with it=2E That's how we all learn=2E

I hope that's constructi= ve=2E

Kind regards,
DaLynX


------M8FKJ23YGJG3QUX0RL3T45WV8U17VS-- From nobody Thu Sep 12 02:00:42 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 4X40yv0dBqz5WFq7 for ; Thu, 12 Sep 2024 02:00:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X40yt6606z4l3t for ; Thu, 12 Sep 2024 02:00:54 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-502fbf07c47so135475e0c.3 for ; Wed, 11 Sep 2024 19:00:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726106454; x=1726711254; h=content-transfer-encoding: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=w2ZV8CkwHtzJk9ax51kyi+TuCydYK3N7M9Gup9t8EfE=; b=DXU+UUQPDabRUIioUpO8YPvDSw+STBcMkX3r6nMK0oWyHaa/cpVwwDP6GJEEQ4EewF mJZfoCjyU8Y5zvpy6vdPMWd/Os4w6HWiCfyDBvUaiy8PgTnINGMxGcqrMXtGMGRcgsql CX/J/AzdoMUQNQTgCagukQrAjckuG3s7puSFHF+6u5QE0QqGomSvXcbNzHmFsvHK4B8q 3v/HKbwCtxUX1Wb+z+6i2QN/Lbrai71z1d/PIc05gqaEd/z2qGCWn1AuDeogRWCkwsBp 1KHibXv3FXkWmjH1K4eAsStseGG2yjd6xQAW2Zi3tucTZEslsLANEoiWNPqnPV4BA5+1 6T6Q== X-Forwarded-Encrypted: i=1; AJvYcCVFWEi2MUvVOfJvYKxBrWIHOTcwBRv0SfwIPqo8pTE1nUBFGXCxR2wb2YuFBOAQwWu2aNRRr9yMWMi+xUk34eQ=@freebsd.org X-Gm-Message-State: AOJu0YyQFBzOsyJvUQzAAsaDambc/rb1QK+VJ6+/0iio72V4h5wd0LXO ddMeZO1WXApyFt8hRwcEME0R4O9Ys2MasfUkZZcELMWOBOve+xZmnHTDDpPd7Mv0jtYr0/5ygF5 ZxjcHtowdtLuqv4dAwiqAU14eIYwRNA== X-Google-Smtp-Source: AGHT+IGRhbUz1nKeuT73KF6mHVhEyKWcoqC8Oca8/NWGknt5lUP6dp1uHJzMkPhYdp0d7lyqFmmTVbEeQxQuoz6XIks= X-Received: by 2002:a05:6122:1ad3:b0:500:fa6b:b878 with SMTP id 71dfb90a1353d-5032d389bf7mr1368216e0c.3.1726106453674; Wed, 11 Sep 2024 19:00:53 -0700 (PDT) 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: Alan Somers Date: Wed, 11 Sep 2024 20:00:42 -0600 Message-ID: Subject: Re: Some rather stupid questions about Rust and FreeBSD To: "B. E." Cc: Aryeh Friedman , FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X40yt6606z4l3t On Wed, Sep 11, 2024 at 6:36=E2=80=AFPM B. E. wrote: > > It doesn't matter the technicalities, Rust enthusiasts are looking for re= levancy in a post-language wars world; and they think falsely that their on= ly recourse is to invade established camps. Nobody is invading anything. Myself and the other Rust boosters have been involved with FreeBSD for longer than Rust has existed. > > I feel sorry for them in a lot of ways, but this is the time for them to = be discovering problem domains or creating solutions that Rust is uniquely = good for; and not copying or corrupting established technical communites. A= ugmenting FreeBSD somehow is not a legitimate problmem domain nor is it som= ething uniquely solved by Rust. Don't be a solution in search of a problem = is my best advice to the Rust community - unfortunately much of the low han= ging problems have been picked; but there are plenty of slightly less easy = problems to solve. Systems programming IS the problem domain that Rust is uniquely good for. Nor do we have a solution in search of a problem. As I've explained elsewhere on this list (but you can 100% be forgiven for overlooking; there've been a lot of posts), I've already encountered many problems within FreeBSD that could've easily been solved by Rust. Being experienced with both C and Rust, but being forced to use the former, feels like a real handicap. To recap: * I considered writing the fusefs test suite in Rust. It would've been well-suited. But I was forced to do it in C++ instead. * I tried to write a prometheus exporter for CTL in Rust. But when I realized that the API is unstable, I had to abandon using ports, which meant that I had to abandon using Rust, and use C instead. * I had to fix several file-parsing and memory-handling bugs in ctld. Just to help myself understand the code, I rewrote part of it in Rust. The portion that I rewrote took about 5.5x less code and was free of memory-handling bugs. But I can't finish it, because the src tree currently only allows C and C++. * ALL of the recent security advisories involved memory handling bugs. We obviously can't rewrite all of the affected components overnight, but those SAs should serve as a wake-up call that C is insufficient for developing reliable and secure software. Any components that we can rewrite will improve the quality of our project. > > So, this is ideologically and existentially driven, and rational argument= s are not enough (FreeBSD is not experiencing this alone). Setting extremel= y hard boundaries, in charity, is the only answer. I am a mere casual but c= onsistent user of FreeBSD from a long time ago, and I very strongly support= all firm (but charitable) opposition to Rust being required to run FreeBSD= . I've noticed that the most vociferous opposition to using Rust in FreeBSD comes from users like yourself: casual users who do little to no development of FreeBSD. If you aren't a developer, then what are you afraid of? Longer compile times when updating your desktop from src? If Shawn Webb's project works out, then you won't have to worry about that. A larger .iso for installation? Even the smallest thumb drives are now larger than our dvd image. Please explain to me: what negative impact do you foresee for yourself? -Alan > > Cheers, > Brett > > On Wed, Sep 11, 2024 at 7:11=E2=80=AFPM Aryeh Friedman wrote: >> >> On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers wrote: >> >> > > 2. The code looks no better than portable assembly and if that is th= e >> > > case why does it need to be in the kernel when there is already a >> > > perfectly good portable assembly already there known as C? >> > >> > I don't know if you're being serious or trolling. I ought to assume >> > the former, but if you genuinely can't tell the difference between >> > Rust and assembly source code then you obviously haven't looked at one >> > or the other for more than a few seconds. >> >> If I had wanted to troll instead of genuinely out of pure curosity I >> could of compared all three languages to a language I am currently >> writting to use in a forth come PhD thesis that is purefly function, >> gate level (with abstractions allowed), has no explicit flow control >> except for calling functions and few other really oddball things. >> But I am not going to say anything more about that and instead focus >> on why I made the comment I did: >> >> 1. C when super optimized has about a 2 to 1 ratio between expressions >> and emitted machine instructions but it self is semantically much >> easier to deal with then assembly and the fact it is a high level >> language means it in theory portable to any machine a compiler is >> implemented on. >> >> 2. I consider assembly fairly high level actually compared to the >> topic I am not trolling on (I am at the level of building UTM's from >> gates) >> >> > So I think you must be >> > exaggerating, and you really mean "Rust looks no more or less readable >> > than C". For a good example of why Rust (and other modern languages) >> > can be more readable than C, compare these examples, which sort an >> > array: >> > >> > in C >> > =3D=3D=3D=3D >> > int compare(const void* a, const void* b) { >> > return (*(int*)a - *(int*)b); >> > } >> >> I completely agree pointers are evil and that's why I (like Rust it >> appears) *ONLY* allow arrays and array references not direct pointers >> into physical address space. This way we still have the advantage of >> being able to use base+offset addressing modes instead of having the >> language processor/executor compute absolute addresses at run time. >> >> > >> > int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 }; >> > int n =3D sizeof(arr) / sizeof(arr[0]); >> > qsort(arr, n, sizeof(int), compare); >> >> So C is not OO (what a surprise ;-)) but it does do one thing right is >> it separates out the concerns of storage from processing at the lowest >> levels (hard to get above that level and that is why I use Java for my >> freelancing work). Which when working in any language is a good idea >> but since C is not OO we are stuck with naked function calls (no harm >> in that) >> >> > >> > in Rust >> > =3D=3D=3D=3D=3D=3D=3D >> > let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]; >> > arr.sort(); >> >> The fact the data structure even worries about behaviour instead of >> being passable to objects is asking for it (this is from my software >> engineering hat). Also the fact there is no explicit size of the >> array defined since if it is static a Turing complete process can be >> implemented on it but if it is dynamic how do you keep from >> overflowing the storage allocated to it (aka buffer overflow). >> >> > * The size of the array >> >> Very good idea from the resource management POV >> >> > * The size of each element >> >> Again correct call for an OS level language. >> >> > * The name of the comparison function >> >> Separation of concerns *STANDARD* software engineering. >> >> > >> > Each of those is error-prone. Stuff like that is a common source of >> > bugs in C code. But Rust tracks it automatically. >> >> At the cost of coupling stuff far too tightly it appears. >> From nobody Thu Sep 12 02:45: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 4X41yw0tDFz5WN9f for ; Thu, 12 Sep 2024 02:46:00 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X41yv5m5wz4rhp; Thu, 12 Sep 2024 02:45:59 +0000 (UTC) (envelope-from estrabd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a8d29b7edc2so57313266b.1; Wed, 11 Sep 2024 19:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726109158; x=1726713958; 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=2B5X1MS234gR6dGZxAxyOQHXmX5kgV9HeuZUIWaBitU=; b=dSG57HJEiGewOUsCuzjQfsyPGWeR70A2LwxeJnPlDmx3lfynW6vxrFOzupa0Xd7Kqr MKmOBPlnxDgnrTViTNd7dzQ5LpzvvLnLNX4J2EcEy2ojqVafDoLWZOQfYF+PFJ1Jgqba yp79VHW5Ows8JqD8F6VWpUo1ZEyOFQyT88zMh4gNFHJ1vS1lDJj2s01aczsk+q/Wp44u KWse5kAvPV6WdXGXj2PQJ8TT1Lh2gwlCxJSM/bQ9BgLVR20w6XM575VRx+1r3sGffn59 DSczb/2NL8I0SwTXBGHKljMt/GmVByC4d9DWZwtL2rpGMPQbVqDgLAjXsEIR3I/6MHMB XgbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726109158; x=1726713958; 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=2B5X1MS234gR6dGZxAxyOQHXmX5kgV9HeuZUIWaBitU=; b=GVfjNaNqMWqdrHdbJfpKNzGH+FiN765pJG+Z1EWcSC4LObFRcuHWKqPhB2p2OT9BXo nPX5U/6yP3kBzeEuiVM/YVhoLlOHerUhxkndRnmxI+/zPh2gUGJjAeM9ROaST6PHiyT8 K23fniINexvxF0ga1pcUF1kzCOneAtFK3ga+bMsoTAANi0NW2tA+wngRkKIwZUpV9qJa 7f8SSj/wYkd2tA6DSWdOpxcZfdbTHYrFKQNNwDOfY0+cdtfgFVYYtF07u2tdVWrMX5yk HuDJmfzzi2/vI5WdzKIm6ydxI9036TZj3Wrtn04rWZa0Bz04sT+nY/uX5z4DhrZV0Hi5 cTtA== X-Forwarded-Encrypted: i=1; AJvYcCVXuSxKaYGlr/daLO9L3uvrd/6Yu+EfQaCFSjirbfz4y3BLs/vTQHmE+dWviqdWN2Z2v4GO4ff/H+oEzL2e878=@freebsd.org X-Gm-Message-State: AOJu0Yya+kOYerbIjIyEEp1unYc29kmFf6rX7CSp/auKMVraEcNMznDX EsdNmsJNKhSrdntvsztAM3kwz72C+v9Y/moe6643gep5chOKQooao5vvYhwdc87Re1nIkvrxGoP t1W1srMTH6zMcTQ01mVqaw3G3qimqHg== X-Google-Smtp-Source: AGHT+IECHsEgArqJxWakxYUJb7yLYf8KZfHM58yM0V83Lu5MykT+k2QrlKXb5M+Cg602/ZNhjvkVinQ/+ZPbbqHFY9U= X-Received: by 2002:a17:907:e2cf:b0:a8c:d6a3:d03a with SMTP id a640c23a62f3a-a902947d3f4mr109679766b.21.1726109157931; Wed, 11 Sep 2024 19:45:57 -0700 (PDT) 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: Wed, 11 Sep 2024 21:45:21 -0500 Message-ID: Subject: Re: Some rather stupid questions about Rust and FreeBSD To: Alan Somers Cc: Aryeh Friedman , FreeBSD Mailing List Content-Type: multipart/alternative; boundary="00000000000033c0130621e31bc6" 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_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4X41yv5m5wz4rhp --00000000000033c0130621e31bc6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 11, 2024 at 9:00=E2=80=AFPM Alan Somers w= rote: > On Wed, Sep 11, 2024 at 6:36=E2=80=AFPM B. E. wrote: > > > > It doesn't matter the technicalities, Rust enthusiasts are looking for > relevancy in a post-language wars world; and they think falsely that thei= r > only recourse is to invade established camps. > > Nobody is invading anything. Myself and the other Rust boosters have > been involved with FreeBSD for longer than Rust has existed. > > > > > I feel sorry for them in a lot of ways, but this is the time for them t= o > be discovering problem domains or creating solutions that Rust is uniquel= y > good for; and not copying or corrupting established technical communites. > Augmenting FreeBSD somehow is not a legitimate problmem domain nor is it > something uniquely solved by Rust. Don't be a solution in search of a > problem is my best advice to the Rust community - unfortunately much of t= he > low hanging problems have been picked; but there are plenty of slightly > less easy problems to solve. > > Systems programming IS the problem domain that Rust is uniquely good > for. Nor do we have a solution in search of a problem. As I've > explained elsewhere on this list (but you can 100% be forgiven for > overlooking; there've been a lot of posts), I've already encountered > many problems within FreeBSD that could've easily been solved by Rust. > Being experienced with both C and Rust, but being forced to use the > former, feels like a real handicap. To recap: > > * I considered writing the fusefs test suite in Rust. It would've > been well-suited. But I was forced to do it in C++ instead. > * I tried to write a prometheus exporter for CTL in Rust. But when I > realized that the API is unstable, I had to abandon using ports, which > meant that I had to abandon using Rust, and use C instead. > * I had to fix several file-parsing and memory-handling bugs in ctld. > Just to help myself understand the code, I rewrote part of it in Rust. > The portion that I rewrote took about 5.5x less code and was free of > memory-handling bugs. But I can't finish it, because the src tree > currently only allows C and C++. > * ALL of the recent security advisories involved memory handling bugs. > We obviously can't rewrite all of the affected components overnight, > but those SAs should serve as a wake-up call that C is insufficient > for developing reliable and secure software. Any components that we > can rewrite will improve the quality of our project. > > > > > > So, this is ideologically and existentially driven, and rational > arguments are not enough (FreeBSD is not experiencing this alone). Settin= g > extremely hard boundaries, in charity, is the only answer. I am a mere > casual but consistent user of FreeBSD from a long time ago, and I very > strongly support all firm (but charitable) opposition to Rust being > required to run FreeBSD. > > I've noticed that the most vociferous opposition to using Rust in > FreeBSD comes from users like yourself: casual users who do little to > no development of FreeBSD. If you aren't a developer, then what are > you afraid of? Longer compile times when updating your desktop from > src? If Shawn Webb's project works out, then you won't have to worry > about that. A larger .iso for installation? Even the smallest thumb > drives are now larger than our dvd image. Please explain to me: what > negative impact do you foresee for yourself? > This ^ Cheers, Brett > > -Alan > > > > > Cheers, > > Brett > > > > On Wed, Sep 11, 2024 at 7:11=E2=80=AFPM Aryeh Friedman > wrote: > >> > >> On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers > wrote: > >> > >> > > 2. The code looks no better than portable assembly and if that is > the > >> > > case why does it need to be in the kernel when there is already a > >> > > perfectly good portable assembly already there known as C? > >> > > >> > I don't know if you're being serious or trolling. I ought to assume > >> > the former, but if you genuinely can't tell the difference between > >> > Rust and assembly source code then you obviously haven't looked at o= ne > >> > or the other for more than a few seconds. > >> > >> If I had wanted to troll instead of genuinely out of pure curosity I > >> could of compared all three languages to a language I am currently > >> writting to use in a forth come PhD thesis that is purefly function, > >> gate level (with abstractions allowed), has no explicit flow control > >> except for calling functions and few other really oddball things. > >> But I am not going to say anything more about that and instead focus > >> on why I made the comment I did: > >> > >> 1. C when super optimized has about a 2 to 1 ratio between expressions > >> and emitted machine instructions but it self is semantically much > >> easier to deal with then assembly and the fact it is a high level > >> language means it in theory portable to any machine a compiler is > >> implemented on. > >> > >> 2. I consider assembly fairly high level actually compared to the > >> topic I am not trolling on (I am at the level of building UTM's from > >> gates) > >> > >> > So I think you must be > >> > exaggerating, and you really mean "Rust looks no more or less readab= le > >> > than C". For a good example of why Rust (and other modern languages= ) > >> > can be more readable than C, compare these examples, which sort an > >> > array: > >> > > >> > in C > >> > =3D=3D=3D=3D > >> > int compare(const void* a, const void* b) { > >> > return (*(int*)a - *(int*)b); > >> > } > >> > >> I completely agree pointers are evil and that's why I (like Rust it > >> appears) *ONLY* allow arrays and array references not direct pointers > >> into physical address space. This way we still have the advantage of > >> being able to use base+offset addressing modes instead of having the > >> language processor/executor compute absolute addresses at run time. > >> > >> > > >> > int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 }; > >> > int n =3D sizeof(arr) / sizeof(arr[0]); > >> > qsort(arr, n, sizeof(int), compare); > >> > >> So C is not OO (what a surprise ;-)) but it does do one thing right is > >> it separates out the concerns of storage from processing at the lowest > >> levels (hard to get above that level and that is why I use Java for my > >> freelancing work). Which when working in any language is a good idea > >> but since C is not OO we are stuck with naked function calls (no harm > >> in that) > >> > >> > > >> > in Rust > >> > =3D=3D=3D=3D=3D=3D=3D > >> > let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66]; > >> > arr.sort(); > >> > >> The fact the data structure even worries about behaviour instead of > >> being passable to objects is asking for it (this is from my software > >> engineering hat). Also the fact there is no explicit size of the > >> array defined since if it is static a Turing complete process can be > >> implemented on it but if it is dynamic how do you keep from > >> overflowing the storage allocated to it (aka buffer overflow). > >> > >> > * The size of the array > >> > >> Very good idea from the resource management POV > >> > >> > * The size of each element > >> > >> Again correct call for an OS level language. > >> > >> > * The name of the comparison function > >> > >> Separation of concerns *STANDARD* software engineering. > >> > >> > > >> > Each of those is error-prone. Stuff like that is a common source of > >> > bugs in C code. But Rust tracks it automatically. > >> > >> At the cost of coupling stuff far too tightly it appears. > >> > --00000000000033c0130621e31bc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 11, 2024 at 9:00=E2=80=AF= PM Alan Somers <asomers@freebsd.o= rg> wrote:
estrabd@gmail.com> wrote:
>
> It doesn't matter the technicalities, Rust enthusiasts are looking= for relevancy in a post-language wars world; and they think falsely that t= heir only recourse is to invade established camps.

Nobody is invading anything.=C2=A0 Myself and the other Rust boosters have<= br> been involved with FreeBSD for longer than Rust has existed.

>
> I feel sorry for them in a lot of ways, but this is the time for them = to be discovering problem domains or creating solutions that Rust is unique= ly good for; and not copying or corrupting established technical communites= . Augmenting FreeBSD somehow is not a legitimate problmem domain nor is it = something uniquely solved by Rust. Don't be a solution in search of a p= roblem is my best advice to the Rust community - unfortunately much of the = low hanging problems have been picked; but there are plenty of slightly les= s easy problems to solve.

Systems programming IS the problem domain that Rust is uniquely good
for.=C2=A0 Nor do we have a solution in search of a problem.=C2=A0 As I'= ;ve
explained elsewhere on this list (but you can 100% be forgiven for
overlooking; there've been a lot of posts), I've already encountere= d
many problems within FreeBSD that could've easily been solved by Rust.<= br> Being experienced with both C and Rust, but being forced to use the
former, feels like a real handicap.=C2=A0 To recap:

* I considered writing the fusefs test suite in Rust.=C2=A0 It would've=
been well-suited.=C2=A0 But I was forced to do it in C++ instead.
* I tried to write a prometheus exporter for CTL in Rust.=C2=A0 But when I<= br> realized that the API is unstable, I had to abandon using ports, which
meant that I had to abandon using Rust, and use C instead.
* I had to fix several file-parsing and memory-handling bugs in ctld.
Just to help myself understand the code, I rewrote part of it in Rust.
The portion that I rewrote took about 5.5x less code and was free of
memory-handling bugs.=C2=A0 But I can't finish it, because the src tree=
currently only allows C and C++.
* ALL of the recent security advisories involved memory handling bugs.
We obviously can't rewrite all of the affected components overnight, but those SAs should serve as a wake-up call that C is insufficient
for developing reliable and secure software.=C2=A0 Any components that we can rewrite will improve the quality of our project.


>
> So, this is ideologically and existentially driven, and rational argum= ents are not enough (FreeBSD is not experiencing this alone). Setting extre= mely hard boundaries, in charity, is the only answer. I am a mere casual bu= t consistent user of FreeBSD from a long time ago, and I very strongly supp= ort all firm (but charitable) opposition to Rust being required to run Free= BSD.

I've noticed that the most vociferous opposition to using Rust in
FreeBSD comes from users like yourself: casual users who do little to
no development of FreeBSD.=C2=A0 If you aren't a developer, then what a= re
you afraid of?=C2=A0 Longer compile times when updating your desktop from src?=C2=A0 If Shawn Webb's project works out, then you won't have t= o worry
about that.=C2=A0 A larger .iso for installation?=C2=A0 Even the smallest t= humb
drives are now larger than our dvd image.=C2=A0 Please explain to me: what<= br> negative impact do you foresee for yourself?

This ^

Cheers,
Brett
=
=C2=A0

-Alan

>
> Cheers,
> Brett
>
> On Wed, Sep 11, 2024 at 7:11=E2=80=AFPM Aryeh Friedman <aryeh.friedman@gmail.com= > wrote:
>>
>> On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers <asomers@freebsd.org> = wrote:
>>
>> > > 2. The code looks no better than portable assembly and i= f that is the
>> > > case why does it need to be in the kernel when there is = already a
>> > > perfectly good portable assembly already there known as = C?
>> >
>> > I don't know if you're being serious or trolling.=C2= =A0 I ought to assume
>> > the former, but if you genuinely can't tell the differenc= e between
>> > Rust and assembly source code then you obviously haven't = looked at one
>> > or the other for more than a few seconds.
>>
>> If I had wanted to troll instead of genuinely out of pure curosity= I
>> could of compared all three languages to a language I am currently=
>> writting to use in a forth come PhD thesis that is purefly functio= n,
>> gate level (with abstractions allowed), has no explicit flow contr= ol
>> except for calling functions and=C2=A0 few other really oddball th= ings.
>> But I am not going to say anything more about that and instead foc= us
>> on why I made the comment I did:
>>
>> 1. C when super optimized has about a 2 to 1 ratio between express= ions
>> and emitted machine instructions but it self is semantically much<= br> >> easier to deal with then assembly and the fact it is a high level<= br> >> language means it in theory portable to any machine a compiler is<= br> >> implemented on.
>>
>> 2. I consider assembly fairly high level actually compared to the<= br> >> topic I am not trolling on (I am at the level of building UTM'= s from
>> gates)
>>
>> > So I think you must be
>> > exaggerating, and you really mean "Rust looks no more or= less readable
>> > than C".=C2=A0 For a good example of why Rust (and other= modern languages)
>> > can be more readable than C, compare these examples, which so= rt an
>> > array:
>> >
>> > in C
>> > =3D=3D=3D=3D
>> > int compare(const void* a, const void* b) {
>> >=C2=A0 =C2=A0 =C2=A0 return (*(int*)a - *(int*)b);
>> > }
>>
>> I completely agree pointers are evil and that's why I (like Ru= st it
>> appears) *ONLY* allow arrays and array references not direct point= ers
>> into physical address space.=C2=A0 =C2=A0This way we still have th= e advantage of
>> being able to use base+offset addressing modes instead of having t= he
>> language processor/executor compute absolute addresses at run time= .
>>
>> >
>> > int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 };
>> > int n =3D sizeof(arr) / sizeof(arr[0]);
>> > qsort(arr, n, sizeof(int), compare);
>>
>> So C is not OO (what a surprise ;-)) but it does do one thing righ= t is
>> it separates out the concerns of storage from processing at the lo= west
>> levels (hard to get above that level and that is why I use Java fo= r my
>> freelancing work).=C2=A0 =C2=A0Which when working in any language = is a good idea
>> but since C is not OO we are stuck with naked function calls (no h= arm
>> in that)
>>
>> >
>> > in Rust
>> > =3D=3D=3D=3D=3D=3D=3D
>> > let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66];
>> > arr.sort();
>>
>> The fact the data structure even worries about behaviour instead o= f
>> being passable to objects is asking for it (this is from my softwa= re
>> engineering hat).=C2=A0 =C2=A0Also the fact there is no explicit s= ize of the
>> array defined since if it is static a Turing complete process can = be
>> implemented on it but if it is dynamic how do you keep from
>> overflowing the storage allocated to it (aka buffer overflow).
>>
>> > * The size of the array
>>
>> Very good idea from the resource management POV
>>
>> > * The size of each element
>>
>> Again correct call for an OS level language.
>>
>> > * The name of the comparison function
>>
>> Separation of concerns *STANDARD* software engineering.
>>
>> >
>> > Each of those is error-prone.=C2=A0 Stuff like that is a comm= on source of
>> > bugs in C code.=C2=A0 But Rust tracks it automatically.
>>
>> At the cost of coupling stuff far too tightly it appears.
>>
--00000000000033c0130621e31bc6-- From nobody Thu Sep 12 03:31: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 4X42zr70Mcz5WVTR for ; Thu, 12 Sep 2024 03:31:52 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X42zr4Kspz3y5L; Thu, 12 Sep 2024 03:31:52 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa35.google.com with SMTP id 71dfb90a1353d-50108b373d2so168102e0c.2; Wed, 11 Sep 2024 20:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726111911; x=1726716711; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iMJeSSuCU5Kcd/gigDzTxduKcK22QcWss3OJkj/nFig=; b=SitCFhzt3eocSPDxDI6B4MAlf/InPRfYpeQ2wcVZVEbMykYdYHjR97pvM2dZ/H3a16 8ZyOL3ZQDvkyKaurIxO6W6ywdY1+EC+JIykT0J+92dd4Brqu/ftRVEa1ed9Y6eRhHTKM TaVMtQzp7uxZgC2JCRXAurDTHwajosqC3Ei1H5jHHUY6hlh8ydXfZYCVUX5rwLTUyrAP 0Lafeckz8Zbx4EuSxqZjuP6hvsbqyAK7IAzxfPrujmCOBC/W2AIdirTxbjWvQDZLE6pp 5H+C9eJgyuU1gkARCXpD3/VRsE9jxhhjILuBdudYUak5xGD4uqamZtxuIy3voI82kRxI RTSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726111911; x=1726716711; h=content-transfer-encoding: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=iMJeSSuCU5Kcd/gigDzTxduKcK22QcWss3OJkj/nFig=; b=e06icuIJgBaxc7P8NDCeAexpeDdK+LzKcDFL2hMVZWZCMbLLRRNwKhiectwKNDAlVU GKO08Q7iF1Jnx7p5f3/4beIiGLTQ8kWRJMA6NRuApKlZEBDme/jj6NRp9GOz6wqYbRan k8tWrDQWxv7RUetyQa6RgQjlTID+/TipYyWaoKjMII6mTzbUt5w19toA/iakNctaD6L7 STGJoMewxjJr0uNcYpTOyuJi0tBxd71u5ecv3rw9n3A8Cz+W1+2Jb9G7iYJjVPUHM7eV n8gQtLS1A9qq4Pg2nJByFjFDXKYMBkQnttCsSEHurI2F4OMvkwaMxYKzndDXsOIIb/Lp ILsA== X-Forwarded-Encrypted: i=1; AJvYcCV3zFS4vVBmZ1U2B/06OJVFifht44XiaX4bmti3gK4wOS+7PZYmot2QkDQqco/sN4I43yXm321E7NudGrpdxII=@freebsd.org X-Gm-Message-State: AOJu0YwN4T5XlWVp2XMSoJLE7EkUYbtGp0Hz5YovaDrpEiQTTmTl/iTF CE8+Pby0eYAARYR9D/mqQt0rKiocE5+2tuWKNwO9oY/SML/j+8cDVR626Q/3IfPj5XVFn7qGrtZ CcFONx1PTKNiDXOnexrXVbyc5BEQ= X-Google-Smtp-Source: AGHT+IEiwy5T1PD4A453KT5LQKZXl3LB8jBbt4yBm3BCMCWeMldbX51thZaRewoAXW+hNm1t5w1alJNduH4JTy2z6S8= X-Received: by 2002:a05:6122:1306:b0:4ed:26:790a with SMTP id 71dfb90a1353d-5032d40b436mr1543369e0c.4.1726111911232; Wed, 11 Sep 2024 20:31:51 -0700 (PDT) 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: Aryeh Friedman Date: Wed, 11 Sep 2024 23:31:40 -0400 Message-ID: Subject: Re: Some rather stupid questions about Rust and FreeBSD To: "B. E." Cc: Alan Somers , FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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] X-Rspamd-Queue-Id: 4X42zr4Kspz3y5L On Wed, Sep 11, 2024 at 10:45=E2=80=AFPM B. E. wrote: >> I've noticed that the most vociferous opposition to using Rust in >> FreeBSD comes from users like yourself: casual users who do little to >> no development of FreeBSD. If you aren't a developer, then what are >> you afraid of? Longer compile times when updating your desktop from >> src? If Shawn Webb's project works out, then you won't have to worry >> about that. A larger .iso for installation? Even the smallest thumb >> drives are now larger than our dvd image. Please explain to me: what >> negative impact do you foresee for yourself? > > > This ^ I am starting to be sorry I ever decided to ask such "stupid questions". But to dismiss any and all critics as not being developers and thus don't count, to be incredibly arrogant (something I would have done a few decades ago). It is often best to assume absolutely nothing about the person's skills until proven otherwise. I get the feeling I didn't get a similar answer is I showed beyond all doubt your claims about my background were unfounded. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From nobody Thu Sep 12 04:51: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 4X44lw2QN9z5Whfy for ; Thu, 12 Sep 2024 04:51:40 +0000 (UTC) (envelope-from vishwin@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X44lw14f1z485Q; Thu, 12 Sep 2024 04:51:40 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726116700; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=5xA7D2KdOfSjvbv8qnuYm7Yp9DItZiW5f9l+ThNHOD0=; b=vEhmH0GjO+XLtCfK/gqB4UNMHXzP/Tfa3CWynGzhSJEgcfkM3vd5e31+sVDXCV2LgBN2Op 4dFyKxePZaMEtayvHyQgygX4T3sEVUvE/n5yMcS3wVuW1yermQcAWk776QWuFSjSYcmara /DnAPtl8zEFGWI03hIS9yvPqA4YjA8ONmWeWHAErhmOlt41pcwD4TCRLfMBJc84c+zUggF +lz2cUwgrlFXCWCURbNqSwahWk5oc/i6Kys/YsI9RAk+d1ujXL10C4Wha0/wKkfZvoq/Jz Np4YMfyJgr5f+FkNNVk8WKabKpSZ1haRQOE8YWdLwRVFlkxr10R2t5zzevZkHA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1726116700; a=rsa-sha256; cv=none; b=CmUeYbGq/eaZrbZOdTzLj2r88KTXYDqnRQkbP7+OuILi8QDMkkgEYGkNXl1nq2Zhd6uj99 kBsmXXzDv7RpysLFpgLbT0U3QJf9yeYnrj5rH5/x04I40IXjykcRGlmk7Q9E0OJeeMe5g/ 3CZDd7uo2QbPlEevE3uxXl3BBIpcG5FHiswjcCsF2OC9qzGI41T0eTOUppuxN99gqta9yf jdJ+psI1BObZRT6KO2GtUqiF3EmXbIfG9zId7P95N0/aVQOBT6jfQ7a9v51cWbX6GcPUVs vsuyEhP4wrg1hJzXzior67AQ4OoWBPG9GPNL2wLFypuvt7OBZSjrmO/HM8ScJg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726116700; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=5xA7D2KdOfSjvbv8qnuYm7Yp9DItZiW5f9l+ThNHOD0=; b=yGZUPsGPLtYA9vLLCrxMGjQyGeKpTlRUt/dyYlgLFOEe7G9qeuhg0IpwEqUbz8bCt8MKjS vuEreKR2eVI9Z2L4w8BeGgKjjB62XUFAz6vBN7XxUE6fjOTRYFDW2oRHLcKaVoTJMhWOE9 tvaVuFFN5r6ljI9zqNEX9jj4DfW9nX6zvR7kjfltITfy9lWz7d8ay5YUVe3cXwBx9kR4b8 IE5VM7zEvm+od465n0Rzbb76t2CetdbbqzykY6SOqhCBH6dscGxnnsU2pvU0wTbk2qg5La FKP3gTalaqtEgejlymp8aMeOc45DMtaLGhY0KAyOscuF5l/USw8fE9YaEfcyJg== Received: from [0.0.0.0] (unknown [IPv6:2601:98a:d00:c180:461e:a1ff:fe02:14dc]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X44lv5r7BzGV7; Thu, 12 Sep 2024 04:51:39 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <1f5eba26-b757-4358-b7cf-9ac89024a570@freebsd.org> Date: Thu, 12 Sep 2024 00:51:35 -0400 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: Some rather stupid questions about Rust and FreeBSD To: Alan Somers Cc: Aryeh Friedman , FreeBSD Mailing List References: <33fc2e5d-f135-4770-9ba6-cfae3a4ad120@freebsd.org> Content-Language: en-US From: Charlie Li Autocrypt: addr=vishwin@freebsd.org; keydata= xjMEZFWWqBYJKwYBBAHaRw8BAQdAINFDmM+bgGkT1C4nD5a3BxgcH8Xnx5qTJbPuIBxD57LN MkNoYXJsaWUgTGkgKEZyZWVCU0QgUHJvamVjdCkgPHZpc2h3aW5ARnJlZUJTRC5vcmc+wpkE ExYKAEEWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIbAwUJA+3ogAULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgAAKCRBnj5NgWEFcyllaAP9CGICFEvTUOv5BYh/H8m49VJ87a/wd 0obeQfVBnS464AD9FopTHbjEs0HDV0ZYmJPxzJIznjumsj9gBxX0bBqqTgzOOARkVZaoEgor BgEEAZdVAQUBAQdA6BUWuG5RuT0vmtoDyCUUqiJGdtd78GM5ic3kw2AntSADAQgHwn4EGBYK ACYWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIbDAUJA+3ogAAKCRBnj5NgWEFcyn55 AP9ezKDCUgHqAq6JX976abb9pYdbSjxxNJqnrjgNkfhgIQD/QhR+fgnUHhcGTMBy+pYHZUGH 5DCuITsK1U4+v252uws= Organization: FreeBSD Project In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------u30u71O9cjw2j8kvI7BHWThi" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------u30u71O9cjw2j8kvI7BHWThi Content-Type: multipart/mixed; boundary="------------RMdNhomH960GbUL27XqkXyhi"; protected-headers="v1" From: Charlie Li To: Alan Somers Cc: Aryeh Friedman , FreeBSD Mailing List Message-ID: <1f5eba26-b757-4358-b7cf-9ac89024a570@freebsd.org> Subject: Re: Some rather stupid questions about Rust and FreeBSD References: <33fc2e5d-f135-4770-9ba6-cfae3a4ad120@freebsd.org> In-Reply-To: --------------RMdNhomH960GbUL27XqkXyhi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QWxhbiBTb21lcnMgd3JvdGU6DQo+IE9uIFdlZCwgU2VwIDExLCAyMDI0LCA3OjMz4oCvUE0g Q2hhcmxpZSBMaSB3cm90ZToNCj4gICAgIHJ1c3RjIChsYW5nL3J1c3QpIHN1cHBvcnRzIHVz aW5nIGFuIGV4aXN0aW5nIExMVk0gdG9vbGNoYWluDQo+ICAgICAoZGV2ZWwvbGx2bSopLiBT aW5jZSBMTFZNIDguMCwgdGhlIFJ1c3QgUHJvamVjdCBtYWludGFpbiB0aGVpciBjb3B5IG9m DQo+ICAgICBMTFZNIG5lYXJseSB0aGUgc2FtZSB3YXkgd2UgZG8gaW4gYmFzZSwgYW5kIGFz IHN1Y2ggdHJhY2sgdGhlIGxhdGVzdA0KPiAgICAgdHdvDQo+ICAgICByZWxlYXNlIGJyYW5j aGVzLiBVc2luZyB0aGUgUE9SVF9MTFZNIG9wdGlvbiBpbiB0aGUgcG9ydCByZWR1Y2VzIHRo ZQ0KPiAgICAgYnVpbGQgdGltZSBzaWduaWZpY2FudGx5IChmcm9tIG5vdCBidWlsZGluZyBM TFZNKSB3aXRoIG5vIGNoYW5nZSBpbg0KPiAgICAgcnVudGltZSBiZWhhdmlvdXIuDQo+IA0K PiANCj4gT2gsIHN3ZWV0LsKgIEkgbmVlZCB0byB0cnkgdGhhdCBvdXQuIFdoYXQncyB0aGUg ZG93bnNpZGU/IERvIHlvdSBrbm93IHdoeSANCj4gaXQgaXNuJ3QgdGhlIGRlZmF1bHQ/DQo+ IA0KV2VsbCwgaXQncyBub3QgdGhlIGRlZmF1bHQgdXBzdHJlYW0gOi1QIFRoZSBwb3J0IG9w dGlvbiB3YXMgcmVzdXJyZWN0ZWQgDQphZnRlciBhIGxvbmcgd2hpbGUgYW5kIGlzIG1haW50 YWluZWQgYnkgeW91cnMgdHJ1bHkuDQoNClNvbWUgaGlzdG9yeTogVGhlIHJ1c3RjIGNvbmZp Zy50b21sIGhhcyBhbHdheXMgaGFkIHRoZSBhYmlsaXR5IHRvIA0KKG9wdGlvbmFsbHkpIHNw ZWNpZnkgYSBwYXRoIHRvIGxsdm0tY29uZmlnLiBUaGUgcG9ydCBvcHRpb24gd2FzIA0Kb3Jp Z2luYWxseSByZW1vdmVkIGR1cmluZyAxLjIyLjEsIGF0IHdoaWNoIFJ1c3QgdXBzdHJlYW0g dHJhY2tlZCB0aGVpciANCipmb3JrKiBvZiBMTFZNIHRydW5rLCBhdCB0aGUgdGltZSB0aGUg ZGV2ZWxvcG1lbnQgZm9yIDcuMCAoNi4wIHdhcyB0aGUgDQpsYXRlc3QgcmVsZWFzZSkuIFJ1 c3QgYWRkZWQgYW4gQVBJIGludG8gdGhlaXIgTExWTSBmb3JrIHRoYXQgZ2Vja29AIA0Kc29m dHdhcmUgc3RhcnRlZCB0byB1c2UsIHNvIGJ1aWxkaW5nIGdlY2tvQCBzb2Z0d2FyZSB1c2lu ZyBhbiBleHRlcm5hbCANCkxMVk0tcGlsbGVkIHJ1c3RjIHdvdWxkIGZhaWwuIE9uY2UgUnVz dCBzdGFydGVkIHRyYWNraW5nIExMVk0gOC4wIA0KcmVsZWFzZSBicmFuY2gsIHRoaXMgcHJv YmxlbSB3ZW50IGF3YXkgYW5kIHRoZWlyIGN1cnJlbnQgbWFpbnRlbmFuY2UgDQpwcmFjdGlj ZSBzaW1pbGFyIHRvIHVzIGluIGJhc2UgWzBdIHN0YXJ0ZWQuDQoNClNvbWVvbmUgc3RhcnRl ZCB0byByZXN1cnJlY3QgdGhlIFBPUlRfTExWTSBvcHRpb24gaW4gdGhlIHBvcnQgYXMgYSBw aGFiIA0KcmV2aWV3IGR1cmluZyB0aGUgaW50ZXJ2ZW5pbmcgcGVyaW9kIGJ1dCBkaWRuJ3Qg Z28gYW55d2hlcmUgcXVpY2sgDQpiZWNhdXNlIEVOT1RFTk9VR0hFWUVCQUxMUy4gSXQgdG9v ayB1bnRpbCBtZSB3YWtpbmcgdXAgZnJvbSBhIGZldmVyIA0KZHJlYW0gb24gdGhpcyBzdWJq ZWN0IChhbmQgb2YgY291cnNlIHdhbnRpbmcgdG8gcmVkdWNlIHBvcnQgYnVpbGQgdGltZSkg DQp0byBnaXZlIGl0IHRoZSBhZGRpdGlvbmFsIHdvcmsgYW5kIHRlc3RpbmcgbmVlZGVkIHRv IHJlY2VpdmUgYmxlc3NpbmcgDQpmb3IgdGhpcyBvcHRpb24gdG8gcmV0dXJuLg0KDQpUaGUg b25seSBkb3duc2lkZSBpcyBhIG1pbm9yIG5pdCBvdmVyIHRoZSBXQVNNIHRhcmdldCBidW5k bGluZyBMTEQgdGhhdCANCnVwc3RyZWFtIHByb2JhYmx5IGRpZG4ndCBjYXRjaCBidXQgd2Ug aGF2ZSBtaXRpZ2F0ZWQgaXQgaW4gdGhlIHBvcnQuIEFuZCANCmFnYWluLCB0aGUgYWZvcmVt ZW50aW9uZWQgYnVpbGQgZmFpbHVyZXMgb24gZ2Vja29AIHNvZnR3YXJlIGhhdmUgbG9uZyAN CmJlZW4gcmVzb2x2ZWQgd2l0aCB0aGUgY2hhbmdlZCBMTFZNIHRyYWNraW5nIHByYWN0aWNl Lg0KDQpbMF0gaHR0cHM6Ly9ydXN0Yy1kZXYtZ3VpZGUucnVzdC1sYW5nLm9yZy9iYWNrZW5k L3VwZGF0aW5nLWxsdm0uaHRtbA0KDQotLSANCkNoYXJsaWUgTGkNCi4uLm5vcGUsIHN0aWxs IGRvbid0IGhhdmUgYW4gZXhpdCBsaW5lLg0K --------------RMdNhomH960GbUL27XqkXyhi-- --------------u30u71O9cjw2j8kvI7BHWThi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZuJzVwUDAAAAAAAKCRBnj5NgWEFcyrw0 AP9NbfuRASYpoXTgiv/L3HGS170lBgJ+7rCMV1fhCaRGCwEA8uB9St5vBbQg6GTvp3PGScKsdMav uEZxyuD/371Vdgo= =NLfm -----END PGP SIGNATURE----- --------------u30u71O9cjw2j8kvI7BHWThi-- From nobody Thu Sep 12 04:57: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 4X44v256DMz5WjFq for ; Thu, 12 Sep 2024 04:57:50 +0000 (UTC) (envelope-from vishwin@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X44v24Wjsz4BK1; Thu, 12 Sep 2024 04:57:50 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726117070; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=CMHyPvwpBMnezEc4g6GwFYCi3MyzzQrh4LHtzrknXLU=; b=nCQwOOESQlr3YZ3mUPBtJYixEyvr3UBWiG4dkcOQGZhxOAAYHiTbVQENjvHYANFaFiZbjV 7mYJQpuivNM0rErTJbkBhCMuda4Qo4emu0s2FuvtywNO8wGKFh2noq7FJjlcTpbDlr/A6+ INDHoK7/IPL2BDDH4raKbduCb+ZZFX+E0TYgT8gh9NYwTjURYkQn++zv7O58VRSxggidIS QPRhGvkn2joAW5rAV8B9GRnwvAa4VScxND2h+AzszPS1Ee7ufiDts3cQNCEmQYZ8mhTs0z kC4P8qOgBm5oMcMw3S28t5HHTiLoCcxLxQ3MRXpq0pRcYIssHgFyTU3ykvbm0A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1726117070; a=rsa-sha256; cv=none; b=S3EpBV6S8WjnSyRUVex89sA18p52zf7RF4ZTs7ZuLBUzEIo7n4Iobdlh5qUONmFni+I7ZO mratv7empZ/OWq23isUrL67earTDsFHOsBn+2NbaCrYsc+dKjNZ4SvnsehGnh3qlNtDhzn n3Zk77SBoqn+UFfO2FmsalerPbnFiEH1n3jFC72Iadt3aOe1zEFHkiBdxEDAs12SI55Rms RpPMRb1Xxg/P+X3u1Nc8Wpw2UUP8ZIKq1QlajnekAOp2Vrq8y5gaOEGV+9VJOCGDjYB1F3 /YfatTmzsN5gmNFpnBKd1tZ9tKL1DVfHhyQShmPLpoiO4v6e1936+bTvo/B/3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726117070; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=CMHyPvwpBMnezEc4g6GwFYCi3MyzzQrh4LHtzrknXLU=; b=DCqkq+ADDvG8h3ltBmT3IW7EkzPVqQoOMKuFwiSSHCTkL3bO2modI2pHIu6Vy6GgHO1hlG cV8GAWxepGv9Vn94vqhhvNf8zDhJh4sviJtK54sCxZh3BugtHfNTCgA/uYQtnn93JU1Ila OxngQuo2wA2YN2Zg0WO0Kjj2ohT33ieTSOvams/phKas42JEpNNp0S7qUcy8I/JBruqocF HDHP4/EHEmw9FlbRSUTM0x5ifCLCg5rOaobhz+Fn4MfDFyWRr6npInfPipvqeKRJ0M+yRm Ud7VYWF6S9dUlR0gzCVjLRmy4zZUL/FMQCtbtDVpsW3IOGbeaEgJ/AaU70OTAQ== Received: from [0.0.0.0] (unknown [IPv6:2601:98a:d00:c180:461e:a1ff:fe02:14dc]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X44v16QS0zGLQ; Thu, 12 Sep 2024 04:57:49 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <946fe6a0-3390-4d53-91d9-b66a2c2fd8f6@freebsd.org> Date: Thu, 12 Sep 2024 00:57:46 -0400 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: Some rather stupid questions about Rust and FreeBSD From: Charlie Li To: Alan Somers Cc: Aryeh Friedman , FreeBSD Mailing List References: <33fc2e5d-f135-4770-9ba6-cfae3a4ad120@freebsd.org> <1f5eba26-b757-4358-b7cf-9ac89024a570@freebsd.org> Content-Language: en-US Autocrypt: addr=vishwin@freebsd.org; keydata= xjMEZFWWqBYJKwYBBAHaRw8BAQdAINFDmM+bgGkT1C4nD5a3BxgcH8Xnx5qTJbPuIBxD57LN MkNoYXJsaWUgTGkgKEZyZWVCU0QgUHJvamVjdCkgPHZpc2h3aW5ARnJlZUJTRC5vcmc+wpkE ExYKAEEWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIbAwUJA+3ogAULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgAAKCRBnj5NgWEFcyllaAP9CGICFEvTUOv5BYh/H8m49VJ87a/wd 0obeQfVBnS464AD9FopTHbjEs0HDV0ZYmJPxzJIznjumsj9gBxX0bBqqTgzOOARkVZaoEgor BgEEAZdVAQUBAQdA6BUWuG5RuT0vmtoDyCUUqiJGdtd78GM5ic3kw2AntSADAQgHwn4EGBYK ACYWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIbDAUJA+3ogAAKCRBnj5NgWEFcyn55 AP9ezKDCUgHqAq6JX976abb9pYdbSjxxNJqnrjgNkfhgIQD/QhR+fgnUHhcGTMBy+pYHZUGH 5DCuITsK1U4+v252uws= Organization: FreeBSD Project In-Reply-To: <1f5eba26-b757-4358-b7cf-9ac89024a570@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------mdBOsInsxQLScOIX2e0eAbuU" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------mdBOsInsxQLScOIX2e0eAbuU Content-Type: multipart/mixed; boundary="------------wdO29KGfRx3AWm9AeQwSp7C9"; protected-headers="v1" From: Charlie Li To: Alan Somers Cc: Aryeh Friedman , FreeBSD Mailing List Message-ID: <946fe6a0-3390-4d53-91d9-b66a2c2fd8f6@freebsd.org> Subject: Re: Some rather stupid questions about Rust and FreeBSD References: <33fc2e5d-f135-4770-9ba6-cfae3a4ad120@freebsd.org> <1f5eba26-b757-4358-b7cf-9ac89024a570@freebsd.org> In-Reply-To: <1f5eba26-b757-4358-b7cf-9ac89024a570@freebsd.org> --------------wdO29KGfRx3AWm9AeQwSp7C9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Q2hhcmxpZSBMaSB3cm90ZToNCj4gQWxhbiBTb21lcnMgd3JvdGU6DQo+PiBPaCwgc3dlZXQu wqAgSSBuZWVkIHRvIHRyeSB0aGF0IG91dC4gV2hhdCdzIHRoZSBkb3duc2lkZT8gRG8geW91 IGtub3cgDQo+PiB3aHkgaXQgaXNuJ3QgdGhlIGRlZmF1bHQ/DQo+Pg0KPiBUaGUgb25seSBk b3duc2lkZSBpcyBhIG1pbm9yIG5pdCBvdmVyIHRoZSBXQVNNIHRhcmdldCBidW5kbGluZyBM TEQgdGhhdCANCj4gdXBzdHJlYW0gcHJvYmFibHkgZGlkbid0IGNhdGNoIGJ1dCB3ZSBoYXZl IG1pdGlnYXRlZCBpdCBpbiB0aGUgcG9ydC4gQW5kIA0KPiBhZ2FpbiwgdGhlIGFmb3JlbWVu dGlvbmVkIGJ1aWxkIGZhaWx1cmVzIG9uIGdlY2tvQCBzb2Z0d2FyZSBoYXZlIGxvbmcgDQo+ IGJlZW4gcmVzb2x2ZWQgd2l0aCB0aGUgY2hhbmdlZCBMTFZNIHRyYWNraW5nIHByYWN0aWNl Lg0KPiANCkkgZm9yZ29yIHRvIG1lbnRpb24sIHRoZSBjaG9zZW4gZGV2ZWwvbGx2bSogbmVl ZHMgYXQgbGVhc3QgQ0xBTkcsIA0KQ09NUElMRVJfUlQsIExJVCBhbmQgTExEIG9wdGlvbnMg ZW5hYmxlZC4gTmVlZCB0byBkb3VibGUgY2hlY2sgd2hpY2ggDQpleGFjdCBvcHRpb25zIGJ1 dCBJIGdvdCBiaXQgd2hlbiBJIGRpZG4ndCBoYXZlIExJVCBlbmFibGVkLg0KDQotLSANCkNo YXJsaWUgTGkNCi4uLm5vcGUsIHN0aWxsIGRvbid0IGhhdmUgYW4gZXhpdCBsaW5lLg0K --------------wdO29KGfRx3AWm9AeQwSp7C9-- --------------mdBOsInsxQLScOIX2e0eAbuU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZuJ0ygUDAAAAAAAKCRBnj5NgWEFcyid1 AQCumT5qfEIlqNWWhFPv71CxsQOaLpulrNltEtmRJb25xgD+LAsTIADXRbO2q/blrIK5bEs8O/mr tMnlB9qn04fLaQs= =TfuV -----END PGP SIGNATURE----- --------------mdBOsInsxQLScOIX2e0eAbuU-- From nobody Thu Sep 12 06:29: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 4X46x95FlDz5TyKw for ; Thu, 12 Sep 2024 06:29:49 +0000 (UTC) (envelope-from gavin@gavinhoward.com) Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X46x73pnWz4Lm6 for ; Thu, 12 Sep 2024 06:29:47 +0000 (UTC) (envelope-from gavin@gavinhoward.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gavinhoward.com header.s=protonmail3 header.b=Hy0rupHV; dmarc=pass (policy=quarantine) header.from=gavinhoward.com; spf=pass (mx1.freebsd.org: domain of gavin@gavinhoward.com designates 185.70.43.17 as permitted sender) smtp.mailfrom=gavin@gavinhoward.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gavinhoward.com; s=protonmail3; t=1726122582; x=1726381782; bh=QAmKSSQaggjol4eYGFjGxy/LBpMgE7fM0GWTXEcHwJE=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Hy0rupHVYBcIvYUlU9w7JRe70p39vmqfmyOAzxFVuFh2HyxGktF8IwUPPbf9nCWSa q27aemlnCM4pRXWTJjYQu3J0CPoECBKn0Pg5WRPV4RAEBsxCxXtI/l+rbjGw2ctr8z EesxeQKqyciCezU8TaRS7d2VrFL3U/eRA1jnefC4s747lZsux9ii65qpZ/nAdILen4 XNODJrRrtuQHfU0eZgf3zAl75O1XOrSFQ8BDExuyjkr1dkZq4zBn5X73YsD89lnCfN 6Nsm38lCmvq5PRF3S1pXnC4tV+YUxQjxrFn4zfFdpj5tjuwV76EAEToUwEc3My/L7k UHRFoXp+wpmXQ== Date: Thu, 12 Sep 2024 06:29:38 +0000 To: "freebsd-hackers@FreeBSD.org" From: "Gavin D. Howard" Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: In-Reply-To: <20240910181711.5d324ac5@nuclight.lan> References: <20240910040544.125245ad@nuclight.lan> <20240910181711.5d324ac5@nuclight.lan> Feedback-ID: 18790518:user:proton X-Pm-Message-ID: 8d0760b21a122fadbb2d01b393e1cdf20d5127c6 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-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gavinhoward.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; R_DKIM_ALLOW(-0.20)[gavinhoward.com:s=protonmail3]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.43.17:from]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[gavin]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gavinhoward.com:+] X-Rspamd-Queue-Id: 4X46x73pnWz4Lm6 > > If I understand Turing-completeness correctly, the "no backward jumps > > but allow recursion and quit on stack overflow" is exactly equivalent > > to having non-infinite loops. > > Sure, but then look at practical usefulness: suppose you have stack of > 32 frames (current limit of eBPF and BPF64). Then you can have only 31 > iterations on a loop, loosing ability to call more functions from loop > body. That is true. However, I wonder if everyone is going at this the wrong way. More specifically, I wonder if we are targeting the entirely wrong level. Maybe verifying bytecode or some other low-level code form is just too hard. What if it were easier just to provide a higher level language that had enough restrictions to be just barely not Turing-complete. To test that idea, I did a quick experiment. I have been working on a language called Yao for the past three years. One feature I planned for the future was the ability to restrict what packages and keywords are available at compile time. I had already put in the plumbing, but I just hadn't implemented it. But I decided to quickly implement it as an experiment. First, I needed a stack limit: https://git.yzena.com/Yzena/Yc/commit/99c822bf7b Now, you can run this: ``` $ ./release/yc yao --max-stack-depth=3D32