From nobody Tue Aug 27 21:38:30 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 4WtgsB6t1vz5MRhN for ; Tue, 27 Aug 2024 21:38:38 +0000 (UTC) (envelope-from fvalasiad@proton.me) Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch [185.70.43.167]) (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 4Wtgs93nS4z502h for ; Tue, 27 Aug 2024 21:38:37 +0000 (UTC) (envelope-from fvalasiad@proton.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=proton.me header.s=protonmail header.b=fp5JjyX4; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (mx1.freebsd.org: domain of fvalasiad@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=fvalasiad@proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1724794714; x=1725053914; bh=lT+zbsSihLAspkr4Hs8La352o2OHZDD2UgdVwVuJ0VM=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=fp5JjyX4m+9Tai20u3ed2zCyfSgPeDD86tIiOUx7S+EzLwzCkTfdOv4xDMKPN4cx4 IadECvSrNqUGe9nNoK7qKmL4T0cZlnyNybFUNneKreSYusxK23oae2rthe5UZC9oJD b9ln9x/hjoeCd51+wXIMhXUZF+Us8pIJWe59fakKrgWn/7BC3WMhaqgcs9kJf952EX vrkY9tFOSBzWyqkurIAVN3iXHORxHOWsFyRx5zW85CCpVfUybNxDNzo6wo2NzGrt4G 3Q0yZUTd1GL4jB+0VKXlNnUCK2NJ3Rxuj5uSgMJVUybFYX07E3IR6cHbvOYITdrzwC EPoWtGoIH+bMg== Date: Tue, 27 Aug 2024 21:38:30 +0000 To: "freebsd-hackers@freebsd.org" From: fvalasiad Subject: Detecting the death of the last LWP of a tracee process. Message-ID: Feedback-ID: 78761413:user:proton X-Pm-Message-ID: f4cef449edf760e5e9ea998361afb9770a204b48 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_Z82RnqYrddNBhaUJF68kUZUCoa4XDscVOUT3WKmA" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[proton.me,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.43.167:from]; R_DKIM_ALLOW(-0.20)[proton.me:s=protonmail]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; 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)[proton.me:+] X-Rspamd-Queue-Id: 4Wtgs93nS4z502h This is a multi-part message in MIME format. --b1_Z82RnqYrddNBhaUJF68kUZUCoa4XDscVOUT3WKmA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8gZXZlcnlvbmUhCgpJIGFtIHBvcnRpbmcgbXkgc28gZmFyIGxpbnV4LW9ubHkgRk9TUyBw cm9qZWN0IFtidWlsZCByZWNvcmRlcl0oaHR0cHM6Ly9naXRodWIuY29tL2Z2YWxhc2lhZC9idWls ZC1yZWNvcmRlcikgdG8gRnJlZUJTRCAidW5vZmZpY2lhbGx5IiwgYXMgaWYsIGluIG15IG93biBw ZXJzb25hbCBmb3JrIGFuZCBub3QgdGhlIHBhcmVudCBvcmdhbml6YXRpb24ncyB1cHN0cmVhbSBy ZXBvc2l0b3J5LgpBbGwgZm9yIGZ1biBpbiBteSBwZXJzb25hbCB0aW1lLCB1bmNlcnRhaW4gaWYg YW5kIHdoZW4gaXQncyBnb25uYSBiZSBtZXJnZWQgdXBzdHJlYW0uCgpBcyB5b3UgY2FuIHByb2Jh Ymx5IGd1ZXNzIGl0IHV0aWxpemVzIHB0cmFjZSgyKSwgYW5kIEkgYW0gZmFjaW5nIHNvbWUgaXNz dWVzIHdpdGggaXQuCgptYW5wYWdlIHN0YXRlcyB0aGlzIGFib3V0IHRoZSBQVFJBQ0VfTFdQIGZs YWc6Cgo+IE5vdGUgdGhhdCBuZXcgcHJvY2Vzc2VzIGRvIG5vdCByZXBvcnQgYW4gZXZlbnQgZm9y Cj4gdGhlIGNyZWF0aW9uIG9mIHRoZWlyCWluaXRpYWwJdGhyZWFkLCAgYW5kICBleGl0aW5nCj4g cHJvY2Vzc2VzIGRvIG5vdCByZXBvcnQgYW4gZXZlbnQgZm9yIHRoZSB0ZXJtaW5hdGlvbgo+IG9m IHRoZSBsYXN0IHRocmVhZC4KClRoaXMgaXMga2luZCBvZiBhIGJ1bW1lciBmb3IgbXkgdG9vbCdz IG5lZWRzLiBJbiBjYXNlIGFueW9uZSBpcyB1bmZhbWlsaWFyIHdpdGggdGhyZWFkcyBpbiBsaW51 eCwgdGhleSBhcmUgZXNzZW50aWFsbHkgcHJvY2Vzc2VzIGFuZCB0aGVyZSBpcyBubyBkaXN0aW5j dGlvbiBiZXR3ZWVuIHRoZW0uIFRyeWluZyB0byBtaW5pbWl6ZSB0aGUgY29uZGl0aW9uYWwgY29t cGlsYXRpb24gb2YgbXkgcHJvamVjdCB0byBtYWtlIG1haW50YWluaW5nIGl0IGVhc2llciwgSSB0 b29rCmFkdmFudGFnZSBvZiB0aGUgZmFjdCB0aGF0IExXUHMgaGF2ZSB1bmlxdWUgc3lzdGVtLXdp ZGUgSURzLCBhbG1vc3QgY29tcGxldGVseQppZ25vcmluZyB0aGUgZGlzdGluY3Rpb24gYW1vbmdz dCBwcm9jZXNzZXMgYW5kIExXUHMgaW4gbXkgdG9vbC4uLi4KClRoaXMgdGhvdWdoIHJ1aW5zIGV2 ZXJ5dGhpbmcsIGFzIEkgY2Fubm90IHByb3Blcmx5IGNsZWFuIHRoZSBwcm9jZXNzJyBsYXN0IExX UCBzdGF0ZQp3aXRob3V0IGtub3dpbmcgaXRzIElEIHVwb24gZXhpdC4gTWFucGFnZSBzdGF0ZXMg dGhhdCB5b3Ugc2hvdWxkIGRvIHRoYXQgdGhyb3VnaCBub3JtYWwKcHJvY2VzcyBzaWduYWxzLCBi dXQgb25jZSB0aGUgcHJvY2VzcyBzZW5kcyB0aGUgV0VYSVRFRCBzaWduYWwsIHRoZSBwcm9jZXNz IGFuZCBhbGwgaW5mbwp3aXRoIGl0KG5hbWVseSwgaXRzIGxhc3QgTFdQJ3MgSUQpIGlzIGdvbmUu IEN1cmlvdXMgaWYgdGhlcmUgaXMgYSB3b3JrYXJvdW5kIGJlc2lkZXMgYWRkaW5nCmV4dHJhIHN0 YXRlLgoKQWRkaXRpb25hbGx5LCBpZiBhbnlvbmUgY291bGQgaGVscCBleHBsYWluIHdoYXQgUFRf R0VUX1NDX1JFVCdzIGRvdWJsZSByZXR1cm4gdmFsdWUgaXMgYWxsIGFib3V0LiBIb3cgY2FuIGEg dHJhZGl0aW9uYWwgc3lzdGVtIGNhbGwgbGlrZSBvcGVuKDIpIGhhdmUgdHdvIHJldHVybiB2YWx1 ZXM/CgpUaGFua3MgZm9yIHlvdXIgYXR0ZW50aW9uIQpGb3Rpcw== --b1_Z82RnqYrddNBhaUJF68kUZUCoa4XDscVOUT3WKmA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPkhlbGxvIGV2ZXJ5b25lITwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPkkgYW0g cG9ydGluZyBteSBzbyBmYXIgbGludXgtb25seSBGT1NTIHByb2plY3QmbmJzcDs8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vZnZhbGFzaWFkL2J1aWxkLXJlY29yZGVyIiB0aXRsZT0iYnVpbGQg cmVjb3JkZXIiPmJ1aWxkIHJlY29yZGVyPC9hPiB0byBGcmVlQlNEICJ1bm9mZmljaWFsbHkiLCBh cyBpZiwgaW4gbXkgb3duIHBlcnNvbmFsIGZvcmsgYW5kIG5vdCB0aGUgcGFyZW50IG9yZ2FuaXph dGlvbidzIHVwc3RyZWFtIHJlcG9zaXRvcnkuPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPkFsbCBmb3IgZnVuIGluIG15 IHBlcnNvbmFsIHRpbWUsIHVuY2VydGFpbiBpZiBhbmQgd2hlbiBpdCdzIGdvbm5hIGJlIG1lcmdl ZCB1cHN0cmVhbS48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAw LCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+QXMgeW91IGNhbiBw cm9iYWJseSBndWVzcyBpdCB1dGlsaXplcyBwdHJhY2UoMiksIGFuZCBJIGFtIGZhY2luZyBzb21l IGlzc3VlcyB3aXRoIGl0LjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPm1hbnBhZ2Ugc3Rh dGVzIHRoaXMgYWJvdXQgdGhlIFBUUkFDRV9MV1AgZmxhZzo8YnI+PGJyPjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXItbGVmdDogM3B4IHNvbGlkIHJnYigyMDAsIDIwMCwgMjAwKTsgYm9yZGVyLWNv bG9yOiByZ2IoMjAwLCAyMDAsIDIwMCk7IHBhZGRpbmctbGVmdDogMTBweDsgY29sb3I6IHJnYigx MDIsIDEwMiwgMTAyKTsiPjxwcmU+Tm90ZSB0aGF0Jm5ic3A7bmV3IHByb2Nlc3NlcyBkbyBub3Qg cmVwb3J0IGFuIGV2ZW50IGZvcg0KdGhlIGNyZWF0aW9uIG9mIHRoZWlyCWluaXRpYWwJIHRocmVh ZCwgJm5ic3A7YW5kICZuYnNwO2V4aXRpbmcNCnByb2Nlc3NlcyBkbyBub3QgcmVwb3J0IGFuIGV2 ZW50IGZvciB0aGUgdGVybWluYXRpb24NCm9mIHRoZSBsYXN0IHRocmVhZC48L3ByZT48L2Jsb2Nr cXVvdGU+PGJyPlRoaXMgaXMga2luZCBvZiBhIGJ1bW1lciBmb3IgbXkgdG9vbCdzIG5lZWRzLiBJ biBjYXNlIGFueW9uZSBpcyB1bmZhbWlsaWFyIHdpdGggdGhyZWFkcyBpbiBsaW51eCwgdGhleSBh cmUgZXNzZW50aWFsbHkgcHJvY2Vzc2VzIGFuZCB0aGVyZSBpcyBubyBkaXN0aW5jdGlvbiBiZXR3 ZWVuIHRoZW0uIFRyeWluZyB0byBtaW5pbWl6ZSB0aGUgY29uZGl0aW9uYWwgY29tcGlsYXRpb24g b2YgbXkgcHJvamVjdCB0byBtYWtlIG1haW50YWluaW5nIGl0IGVhc2llciwgSSB0b29rPGJyPmFk dmFudGFnZSBvZiB0aGUgZmFjdCB0aGF0IExXUHMgaGF2ZSB1bmlxdWUgc3lzdGVtLXdpZGUgSURz LCBhbG1vc3QgY29tcGxldGVseTxicj5pZ25vcmluZyB0aGUgZGlzdGluY3Rpb24gYW1vbmdzdCBw cm9jZXNzZXMgYW5kIExXUHMgaW4gbXkgdG9vbC4uLi48YnI+PGJyPlRoaXMgdGhvdWdoIHJ1aW5z IGV2ZXJ5dGhpbmcsIGFzIEkgY2Fubm90IHByb3Blcmx5IGNsZWFuIHRoZSBwcm9jZXNzJyBsYXN0 IExXUCBzdGF0ZTxicj4gd2l0aG91dCBrbm93aW5nIGl0cyBJRCB1cG9uIGV4aXQuIE1hbnBhZ2Ug c3RhdGVzIHRoYXQgeW91IHNob3VsZCBkbyB0aGF0IHRocm91Z2ggbm9ybWFsPGJyPnByb2Nlc3Mg c2lnbmFscywgYnV0IG9uY2UgdGhlIHByb2Nlc3Mgc2VuZHMgdGhlIFdFWElURUQgc2lnbmFsLCB0 aGUgcHJvY2VzcyBhbmQgYWxsIGluZm8gPGJyPndpdGggaXQobmFtZWx5LCBpdHMgbGFzdCBMV1An cyBJRCkgaXMgZ29uZS4gQ3VyaW91cyBpZiB0aGVyZSBpcyBhIHdvcmthcm91bmQgYmVzaWRlcyBh ZGRpbmc8YnI+IGV4dHJhIHN0YXRlLjxicj48YnI+QWRkaXRpb25hbGx5LCBpZiBhbnlvbmUgY291 bGQgaGVscCBleHBsYWluIHdoYXQgUFRfR0VUX1NDX1JFVCdzIGRvdWJsZSByZXR1cm4gdmFsdWUg aXMgYWxsIGFib3V0LiBIb3cgY2FuIGEgdHJhZGl0aW9uYWwgc3lzdGVtIGNhbGwgbGlrZSBvcGVu KDIpIGhhdmUgdHdvIHJldHVybiB2YWx1ZXM/PGJyPiA8c3Bhbj48L3NwYW4+PGJyPlRoYW5rcyBm b3IgeW91ciBhdHRlbnRpb24hPGJyPjxzcGFuPkZvdGlzPGJyPjwvc3Bhbj48L2Rpdj4= --b1_Z82RnqYrddNBhaUJF68kUZUCoa4XDscVOUT3WKmA-- From nobody Tue Aug 27 21:52: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 4Wth941P5Hz5MSwT for ; Tue, 27 Aug 2024 21:52:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4Wth93549Lz52wl for ; Tue, 27 Aug 2024 21:52:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 47RLq9Oh008271; Wed, 28 Aug 2024 00:52:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 47RLq9Oh008271 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 47RLq9JD008270; Wed, 28 Aug 2024 00:52:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 28 Aug 2024 00:52:09 +0300 From: Konstantin Belousov To: fvalasiad Cc: "freebsd-hackers@freebsd.org" Subject: Re: Detecting the death of the last LWP of a tracee process. Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home 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: 4Wth93549Lz52wl On Tue, Aug 27, 2024 at 09:38:30PM +0000, fvalasiad wrote: > Hello everyone! > > I am porting my so far linux-only FOSS project [build recorder](https://github.com/fvalasiad/build-recorder) to FreeBSD "unofficially", as if, in my own personal fork and not the parent organization's upstream repository. > All for fun in my personal time, uncertain if and when it's gonna be merged upstream. > > As you can probably guess it utilizes ptrace(2), and I am facing some issues with it. > > manpage states this about the PTRACE_LWP flag: > > > Note that new processes do not report an event for > > the creation of their initial thread, and exiting > > processes do not report an event for the termination > > of the last thread. > > This is kind of a bummer for my tool's needs. In case anyone is unfamiliar with threads in linux, they are essentially processes and there is no distinction between them. Trying to minimize the conditional compilation of my project to make maintaining it easier, I took > advantage of the fact that LWPs have unique system-wide IDs, almost completely > ignoring the distinction amongst processes and LWPs in my tool.... > > This though ruins everything, as I cannot properly clean the process' last LWP state > without knowing its ID upon exit. Manpage states that you should do that through normal > process signals, but once the process sends the WEXITED signal, the process and all info > with it(namely, its last LWP's ID) is gone. Curious if there is a workaround besides adding > extra state. When waitpid(2) reports the process exit, you should have only one LWP left in your registry of the process' threads. Clean it. > > Additionally, if anyone could help explain what PT_GET_SC_RET's double return value is all about. How can a traditional system call like open(2) have two return values? Some syscalls return two values, e.q. pipe(2), which needs to return fds for in and out pipes. Less visible, fork(2) returns zero for child process, but also the parent pid as an additional value, not exposed by C wrapper. On 32bit arches, lseek(2) needs to return 64bit result, which requires two registers. Same for read(2)/write(2). From nobody Tue Aug 27 22:03: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 4WthQG2j7Vz5MTPg for ; Tue, 27 Aug 2024 22:03:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4WthQF35VMz54hj for ; Tue, 27 Aug 2024 22:03:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 47RM3fFG008582; Wed, 28 Aug 2024 01:03:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 47RM3fFG008582 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 47RM3fUU008573; Wed, 28 Aug 2024 01:03:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 28 Aug 2024 01:03:41 +0300 From: Konstantin Belousov To: fvalasiad Cc: "freebsd-hackers@freebsd.org" Subject: Re: Detecting the death of the last LWP of a tracee process. Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.87 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.870]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4WthQF35VMz54hj On Wed, Aug 28, 2024 at 12:52:09AM +0300, Konstantin Belousov wrote: > On Tue, Aug 27, 2024 at 09:38:30PM +0000, fvalasiad wrote: > > Hello everyone! > > > > I am porting my so far linux-only FOSS project [build recorder](https://github.com/fvalasiad/build-recorder) to FreeBSD "unofficially", as if, in my own personal fork and not the parent organization's upstream repository. > > All for fun in my personal time, uncertain if and when it's gonna be merged upstream. > > > > As you can probably guess it utilizes ptrace(2), and I am facing some issues with it. > > > > manpage states this about the PTRACE_LWP flag: > > > > > Note that new processes do not report an event for > > > the creation of their initial thread, and exiting > > > processes do not report an event for the termination > > > of the last thread. > > > > This is kind of a bummer for my tool's needs. In case anyone is unfamiliar with threads in linux, they are essentially processes and there is no distinction between them. Trying to minimize the conditional compilation of my project to make maintaining it easier, I took > > advantage of the fact that LWPs have unique system-wide IDs, almost completely > > ignoring the distinction amongst processes and LWPs in my tool.... > > > > This though ruins everything, as I cannot properly clean the process' last LWP state > > without knowing its ID upon exit. Manpage states that you should do that through normal > > process signals, but once the process sends the WEXITED signal, the process and all info > > with it(namely, its last LWP's ID) is gone. Curious if there is a workaround besides adding > > extra state. > When waitpid(2) reports the process exit, you should have only one LWP left > in your registry of the process' threads. Clean it. Slight correction: process can exit with more than one thread still running. You should clean all threads belonging to the exited process. > > > > > Additionally, if anyone could help explain what PT_GET_SC_RET's double return value is all about. How can a traditional system call like open(2) have two return values? > > Some syscalls return two values, e.q. pipe(2), which needs to return fds > for in and out pipes. Less visible, fork(2) returns zero for child process, > but also the parent pid as an additional value, not exposed by C wrapper. > > On 32bit arches, lseek(2) needs to return 64bit result, which requires > two registers. Same for read(2)/write(2). From nobody Tue Aug 27 22:19: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 4Wthmc6DgPz5MVvP for ; Tue, 27 Aug 2024 22:19:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4Wthmb64tSz57Gw for ; Tue, 27 Aug 2024 22:19:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 47RMJaXD009226; Wed, 28 Aug 2024 01:19:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 47RMJaXD009226 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 47RMJa4t009225; Wed, 28 Aug 2024 01:19:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 28 Aug 2024 01:19:36 +0300 From: Konstantin Belousov To: fvalasiad Cc: freebsd-hackers@freebsd.org Subject: Re: Detecting the death of the last LWP of a tracee process. Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.77 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; NEURAL_HAM_SHORT(-0.79)[-0.795]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4Wthmb64tSz57Gw On Tue, Aug 27, 2024 at 10:04:43PM +0000, fvalasiad wrote: > > > > > > > On Wednesday, August 28th, 2024 at 12:52 AM, Konstantin Belousov wrote: > > > On Tue, Aug 27, 2024 at 09:38:30PM +0000, fvalasiad wrote: > > > > > Hello everyone! > > > > > > I am porting my so far linux-only FOSS project build recorder to FreeBSD "unofficially", as if, in my own personal fork and not the parent organization's upstream repository. > > > All for fun in my personal time, uncertain if and when it's gonna be merged upstream. > > > > > > As you can probably guess it utilizes ptrace(2), and I am facing some issues with it. > > > > > > manpage states this about the PTRACE_LWP flag: > > > > > > > Note that new processes do not report an event for > > > > the creation of their initial thread, and exiting > > > > processes do not report an event for the termination > > > > of the last thread. > > > > > > This is kind of a bummer for my tool's needs. In case anyone is unfamiliar with threads in linux, they are essentially processes and there is no distinction between them. Trying to minimize the conditional compilation of my project to make maintaining it easier, I took > > > advantage of the fact that LWPs have unique system-wide IDs, almost completely > > > ignoring the distinction amongst processes and LWPs in my tool.... > > > > > > This though ruins everything, as I cannot properly clean the process' last LWP state > > > without knowing its ID upon exit. Manpage states that you should do that through normal > > > process signals, but once the process sends the WEXITED signal, the process and all info > > > with it(namely, its last LWP's ID) is gone. Curious if there is a workaround besides adding > > > extra state. > > > > When waitpid(2) reports the process exit, you should have only one LWP left > > in your registry of the process' threads. Clean it. > By registry are you referring to a registry that exists in the system and accessed somehow, like with sysctl, or are you telling me that I should indeed keep a registry about which threads belong to which processes in the code? :D. > > Doing so won't significantly complicate things, but extra state is extra state, so just wondered if it could be avoided somehow! Since you are saying that you need to clear the state, you alread have the state recorded somewhere. > > > > > Additionally, if anyone could help explain what PT_GET_SC_RET's double return value is all about. How can a traditional system call like open(2) have two return values? > > > > > > Some syscalls return two values, e.q. pipe(2), which needs to return fds > > for in and out pipes. Less visible, fork(2) returns zero for child process, > > but also the parent pid as an additional value, not exposed by C wrapper. > > > > On 32bit arches, lseek(2) needs to return 64bit result, which requires > > two registers. Same for read(2)/write(2). > > I see, so for syscalls with a single return value, is it safe to assume that it's always going to be at sr_retval[0]? For lseek/read/write etc it depends on the architecture. From nobody Thu Aug 29 07:10: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 4WvXWJ2K3Hz52cgt; Thu, 29 Aug 2024 07:11:08 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from fhigh3-smtp.messagingengine.com (fhigh3-smtp.messagingengine.com [103.168.172.154]) (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 4WvXWH4kY7z3y2D; Thu, 29 Aug 2024 07:11:07 +0000 (UTC) (envelope-from thj@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="e NLRsGa"; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 103.168.172.154 is neither permitted nor denied by domain of thj@freebsd.org) smtp.mailfrom=thj@freebsd.org Received: from phl-compute-02.internal (phl-compute-02.nyi.internal [10.202.2.42]) by mailfhigh.nyi.internal (Postfix) with ESMTP id C46D11151ACC; Thu, 29 Aug 2024 03:11:00 -0400 (EDT) Received: from phl-imap-07 ([10.202.2.97]) by phl-compute-02.internal (MEProxy); Thu, 29 Aug 2024 03:11:00 -0400 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=1724915460; x= 1725001860; bh=hcEq6pG6VQd1GkPokNZla/8P/m3bwMktYM/6Y1KC6MY=; b=e NLRsGa9n0iZy8zZFe6JRPsNsgqVKr+ItEPSRViaKIhe5yqe7BXGyKaCjvETd0ymZ K+SKiXPsJ/RYii33tEil4daUDPkH7xvU0uO+lbL25Lou/urMlcjxRAG/4y8TuEXl WMDKMQr3dS5uyf3KsbHDUztoU7ztjx7npUwlIheUwLi8I+fVBZdJsP+b5J4rYNr2 Gcu0Os0PWVUt2zUc4cStOxHy6wT099c95muEyQ8oofz2DKIf26oVogSny0W2gfpB ZwMxpGh98+lko0zXv7M8UJ8vWjK/lUlNgukHjICA7tuSOli9jIkh7+RqdtkMUTAw iOJ+5LwJ1j7mhPbVaIOvQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeffedguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefoggffhffvkfgjfhfutgfgsehtqhertdertdej necuhfhrohhmpedfvfhomhculfhonhgvshdfuceothhhjhesfhhrvggvsghsugdrohhrgh eqnecuggftrfgrthhtvghrnhephfevgfevueefiedtvdehkeevgffftdefhedtleehieff geetleffveelgfdviedunecuffhomhgrihhnpehfihhstghhlhdruggvnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhjhesfhhrvggvsghs ugdrohhrghdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpth htoheprgigvghlrdhrrghusegthhgrohhsuddruggvpdhrtghpthhtohepfhhrvggvsghs ugdqhhgrtghkvghrshesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehfrhgvvggssh guqdhhrghrugifrghrvgesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ib75146ab:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1E54ABA006E; Thu, 29 Aug 2024 03:11:00 -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: Thu, 29 Aug 2024 08:10:39 +0100 From: "Tom Jones" To: "Axel Rau" , freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Message-Id: <65c16902-d8d5-4a79-ae77-e097da2eb9d6@app.fastmail.com> In-Reply-To: <30B9438F-FC5F-43CA-9A81-5E75F01017F0@Chaos1.DE> References: <30B9438F-FC5F-43CA-9A81-5E75F01017F0@Chaos1.DE> Subject: Re: USBasp no longer works with FreeBSD 14.1 / avrdude 7.3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.25 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.964]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm1]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.154:from]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; 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]; FREEFALL_USER(0.00)[thj]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-hardware@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[messagingengine.com:+] X-Rspamd-Queue-Id: 4WvXWH4kY7z3y2D Can you create a bug to track this and assign it to me (thj@) ?=20 I see the same error with a chv32 programmer, but as a regression it is = more important to track down than new hardware being weird.=20 On Mon, Aug 19, 2024, at 19:23, Axel Rau wrote: > Hi, > > Once a year, I flash some ATtinys. > For ATtin861, i use USBasp from https://www.fischl.de/usbasp/ . > USBasp worked fine with FreeBSD 13.2 / avrdude 7.0 [1] > Now after upgrading the OS and avrdude, it fails: > - - - > usbd_set_config_index: could not read device status: USB_ERR_STALLED > ugen0.2: at usbus0 > umodem0 on uhub0 > umodem0: on usbus0 > umodem0: data interface 1, has no CM over data, has break > ugen0.2: at usbus0 (disconnected) > umodem0: at uhub0, port 5, addr 22 (disconnected) > umodem0: detached > - - - > > [2][3]. > > Any tips welcome, > Axel > > PS: > [1]=20 > > [2] > > [3]=20 > > --- > PGP-Key: CDE74120 =E2=98=80 mobile: +49 160 7568212 > computing @ chaos claudius > > > Attachments: > * t861.log > * error.log > * usb.dump --=20 - Tom From nobody Thu Aug 29 20:21: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 4Wvt380rp3z52YYg for ; Thu, 29 Aug 2024 20:21:24 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 4Wvt3736D1z4K14 for ; Thu, 29 Aug 2024 20:21:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=U26hCDMj; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::12c as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-il1-x12c.google.com with SMTP id e9e14a558f8ab-39d2256ee95so4984295ab.2 for ; Thu, 29 Aug 2024 13:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1724962882; x=1725567682; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IIekfUKm5EdZNUfxQBqlFDNeFJKz1WvP2dD5vj1ZT1A=; b=U26hCDMjlW+BrK9pmL5YkTo+UAc/5kj+op04YCCY93yVoB3/T57BiXdpm9fuqXYbtt QRmerPYGgiDx8Pf3zGn5TLWt96BgXuhMUy28FJAREfOsCNTwcDi9V94WxkIHeAv1Ci1Z wuCABWcoDewhDcrSNO1feNxlYtE9dfdPkC507RNuopMP0tr03Hf8m5jYJCJJqWSCqJic ZlMwE4SfgbI8ht5Px7ZtlGySU2H7xA4dThLn6pN2Y4k33CaVbE8Up32eFc+CsCVgyeQ6 F+ypqTj49a2gp33QL34TM4G8A+YlbGehevW3yMt0gewEhIVS/VxZoD+faelisfCnBvUj /Nsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724962882; x=1725567682; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IIekfUKm5EdZNUfxQBqlFDNeFJKz1WvP2dD5vj1ZT1A=; b=lExTCDjDisi8rAQQtR7PtQIDXvPwPEq1SvrsMHq+mB3i5xkNF1ovBs+avBq9T9sC5G dEE/pMSD8kI8RpjSCXt2ekRzOF0NKYr4gZfI30RnslZQcNj/v5GALqJYQBbSIijcG7RV nFfUZn6+LwmBgkOV/6HgLfsdYfrP2dfTWX/BS1xOeD9ENZE0dCjbdgO4ZwDvbA/nrLdh VklqPTSYGREIPK9xvmRt9LImZdXxRPK6HZ8P+zMoPMjO5Z4RlkljMijizMyVQGktiQJm V93v48XAxXMmN35nEhdkjD2P90wyGgJMu0yQKQMlecOUAb7d2At0kSrEBHva5CbQiqRu dklA== X-Gm-Message-State: AOJu0YyG9ul3SPAStx6/aQMQpNGSNb8UX+JOoqmQaVMhFAjtbe1EP9DR A9CRQpboK96VmbTPsNcKtsJtTwavJXV8pWpOJ7syEadyuUwpb5/WtqF8bHLOnw4= X-Google-Smtp-Source: AGHT+IFTQhhGMQ1y7lAr4R7j2dCqFYzkc7GNkcbVY0ln5RM7KA8w8C9C6oSphciWqHIwGISMChEJSQ== X-Received: by 2002:a05:6e02:1a0e:b0:39b:33a8:2730 with SMTP id e9e14a558f8ab-39f377df024mr51185785ab.8.1724962881865; Thu, 29 Aug 2024 13:21:21 -0700 (PDT) Received: from mutt-hbsd (174-24-73-190.clsp.qwest.net. [174.24.73.190]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-39f3af969dfsm4636585ab.14.2024.08.29.13.21.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 13:21:21 -0700 (PDT) Date: Thu, 29 Aug 2024 20:21:20 +0000 From: Shawn Webb To: Alan Somers Cc: FreeBSD Hackers Subject: Re: A Demo of rust-in-base Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc 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; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mad2rcwhuximkfrn" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.09 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12c:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[hardenedbsd.org:+] X-Rspamd-Queue-Id: 4Wvt3736D1z4K14 --mad2rcwhuximkfrn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Alan et al, I apologize for the silence on my end. It has been a busier two months than anticipated. In that time, I've been entertaining some thoughts on Rust in base support. ${LIFE} is starting to calm down again, and I do believe I'll be able to start the research in time in September. I will be splitting my free time between this and studying for my OSCP cert. So, to those thoughts, in list form (in no particular order): 1. Use of Rust compiler toolchain support will be for userland components in an opt-in fashion. Meaning, all userland components written in Rust will be optional. 2. It does not make sense to perform a vendor import of the Rust compiler toolchain and standard libraries. All Rust code in the src tree must be built from an external toolchain. 3. I believe the notion of an external toolchain could be abstracted such that we can support any optional userland component written in a language supported by that external toolchain. This would imply that other alternative languages could be supported with minimal work (Zig, TypeScript, Python, Java, etc.) 4. We could provide auto-detection mechanisms for determining which external toolchains are available, their language support, etc. The initial proof-of-concept would likely be limited to Rust to save on time and complexity. 5. As the work matures, and perhaps as a requisite for eventual inclusion, we could land support for more than Rust. This might be a step too far, but hey, it's one of the thoughts I had. 6. So all of this wrapped up means that: A. This is NOT a call to rewrite everything in Rust. This work will only permit NEW, OPTIONAL components to be written. B. Other languages/toolchains/ecosystems could be supported, not just Rust. C. Initial focus is on userland components. Rust in the kernel is out of scope for this initial proof-of-concept. D. I would like to see Rust in the kernel. That would be a good next area of focus once userland support reaches some level of maturity. My first goal will be to get a better understanding of src.git/Makefile and src.git/Makefile.inc1. As I study that, I'll also study your work, Alan. I really appreciate the time you have taken. I might reach out to you and Warner directly for further questions. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc On Sun, Aug 04, 2024 at 11:55:26AM UTC, Alan Somers wrote: > Due to all of the recent discussion of using Rust for code in the > FreeBSD base, I've put together a demo of what it might look like. It > demonstrates: >=20 > * Interspersing Rust crates through the tree (usr.bin/nfs-exporter, > cddl/usr.bin/ztop, etc) rather than in some special directory. > * Build integration for all Rust crates. You can build them all with > a single "cargo build" command from the top level, and test them all > with a single "cargo test". > * Wholly new programs written from scratch in Rust (ztop plus three > Prometheus exporters) > * Old programs rewritten in Rust with substantial new features (gstat and= fsx) > * Libs (freebsd-libgeom and freebsd-libgeom-sys) > * Commits that reconcile the dependencies of multiple crates, so as to > minimize duplicate dependency versions (5764fb383d4 and 1edf2e19e50) > * Vendoring all dependencies, direct and transitive, to ensure > internet-independent and reproducible builds (37ef9ffb6a6). This > process is automated and requires almost no manual effort. Note: > don't panic if you look in the "vendor" directory and see a bunch of > crates with "windows" in the name. They're all just empty stubs. > * All Rust object files get stored in the "target" directory rather > than /usr/obj. Today, if you want them to be stored in /usr/obj the > best way is to use a symlink, though there's WIP to add > MAKEOBJDIRPREFIX-like functionality to Cargo. >=20 > It does NOT demonstrate: >=20 > * Integrating the Rust build system with Make. Warner has some ideas > about how to do that. > * Pulling rustc into contrib. This tree requires an external Rust toolch= ain. > * Building any cdylib libraries with Rust. That's useful if you want > a C program to call a Rust library, but I don't have any good examples > for it. > * kernel modules. As already discussed, those are hard. > * Any Rust crates that involve private APIs, like CTL stuff. Those > are among the most tantalizing programs to move from ports to base, > but nobody's written any yet, because Rust-in-base doesn't exist yet. >=20 > Also, I want to address a question that's popped up a few times: > backwards-compatibility. There is a fear that Rust code needs to be > updated for each new toolchain release. But that's not true. It > hasn't been true for most crates since Rust 1.0 was released about a > decade ago. A few exotic crates required "nightly" features after > that, but they are very few in number these days, and none of them are > included in this branch's vendored sources. What Rust _does_ do is it > releases a new toolchain about every six weeks. Each new release > typically includes a few new features in the standard library and they > often add more compiler warnings, too. Sometimes they include wholly > new compiler features, but they are _always_ backwards compatible with > existing syntax. Roughly every three years, Rust publishes a new > "Edition". Rust Editions are very similar to C++ versions. i.e. Rust > 2018 is to Rust 2021 as C++14 is to C++17. New editions can include > backwards-incompatible syntax changes, but each crate always knows > which Edition it uses. Crates of different Editions can be linked > together in the same build. This branch, for example, contains crates > using Editions 2015, 2018, and 2021. >=20 > If you have any questions about what Rust in Base would look like, > please examine this branch. And if you've never used Rust before, I > highly encourage you to try it. It really is the best new > systems-program language for decades. IMHO, it's the only one that's > a compelling replacement for C++ in all new applications, and C in > most. >=20 > https://github.com/asomers/freebsd-src/tree/rust-in-base-demo >=20 --mad2rcwhuximkfrn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmbQ2C8ACgkQ/y5nonf4 4foYYw/9Hn62TRrKoAiOYER/khW8WjZR+7IKgOguGHFbA6ajMKmjrlpE/2n9srJ1 5jyV4WSuV6w5C4Ghrvf8ZBBrx/CPURXsgZ/Mk7p7edqjkpbXjgGmdwwAJeaB/jLn /VwKXe7v0KbTRxwtOeuoCNYC31kty9J1UOpWEXwdW9/qJ84k9/cdcGNOiHNlstP1 mRYUPPZQZJSk9QQ3EsjemA/TtJCZHhnyba/HlwANApaW+XO0tg0f2HAaUyALXKZw W4dvdh8wu0IeSaG4sLItYjYNoHifl3xWvgJaSkCnyuKrhwM+ez7qU6lCkGRAZ0Oq MnLPBMICLuxLPiMvzFKApi/2IUmKHVnbMari9lCv4dUFNQt01h8v5FyuNRdVQ140 x/N5CATqvXsKRSuN3TmHxmgcP8SY0qN/TR67QECyzIY6nWD9BihNWDU5L1WHe2Do o0yz8hJ9p9VUgkN006Rl86fy6iP5o2C3IdNXaWk0/t6juBJMN+Hcs++q4bbjjRwQ iArK4sCk2ehg8ygp3WEnJ/SZuZHsCC69vveOcMgfUEPFBq4K6x92WmAVJFETqc+P NtfLKw6/FnsZRl3S3mJmyxhVPJtabCx5K8lxNjWeeOxtU4IeBKkepTS7GuYK/0u4 qJg9TYJbln939bNYYpQFE0l2UUukwbUlcrCmMkw3F88BRh1lUjc= =GVJD -----END PGP SIGNATURE----- --mad2rcwhuximkfrn-- From nobody Thu Aug 29 20:43: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 4WvtYT3V7Sz52bfc for ; Thu, 29 Aug 2024 20:44:13 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WvtYS2q7Rz4MBP for ; Thu, 29 Aug 2024 20:44:12 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay-org.20230601.gappssmtp.com header.s=20230601 header.b="uvOZH5v/"; dmarc=pass (policy=quarantine) header.from=iitbombay.org; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::52c as permitted sender) smtp.mailfrom=bakul@iitbombay.org Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-7cd94fb88cbso116351a12.2 for ; Thu, 29 Aug 2024 13:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1724964251; x=1725569051; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BnmPLgYoBJc0DJ/9hmNHHyVD4SP3XntisuzQGFPhklc=; b=uvOZH5v/mPYEncf9soIxJ+WAnibm6mwwY6qzZ55ZpUtGwoj2L1d/0hiZC0C/PNC+TF EpJ0N7ZXGTUuTMWgV/LlLecscf1lMLG+f8mx+pUsLES2psQCmqiIkVWARt8p19tZxf4q 3Hn61sXhZ6iKqLkH2kBrdq8Y+WVH39+a1L36sg9AxWFJ9/7EAL9R0QbH6s3uiW4k0x9a geW5iswfMF0Hnrghn1By08CgoREkOFOOf/Eotfdg6WjCSIZ0GjkzxfL3SL67ApVf6ajq ygVN9HUyzWP6D7D1gmEupVFFd/4WtBcNnhYb9FAJTkKqlOguesKdP57N5O3d1/gC3qK2 JmHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724964251; x=1725569051; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BnmPLgYoBJc0DJ/9hmNHHyVD4SP3XntisuzQGFPhklc=; b=uTrA3LQr9dCgtw5El7w6uMK4WRq9fDlsJ2lM+1caOWc2/Uj3fpKFjQP+C114vA71Am 5jTVnMQIEALW6bI+/OV4Ku0B6pDIvJyTny99uOS35/jt//1dGGeeyh4TRnyVOXlWJUoz xYgoU05EtxyWhuEZ3Pwye8nm+TFfbQy6xOtWj1OLAY+aEGUMmgSFJrFX2XtaY0MhSXBu Jq9RUEOKYzZ3BKwj4HrgXyCG2Of0npPA7CMSvEOeWoEy7DLWzqBw+kSQ4URfA6qZyDhT EHoFjGpiqhCWrhAplX6pbBFjY66YspekiUWMn5PpIzms6nga4VvwWSkvU6nnTATaCSrq CL+g== X-Forwarded-Encrypted: i=1; AJvYcCVifLBP4nr0o6MitWZN4NUxGB1bEzzy70PR+QHDZQZjdDMz9JpuxIK7rKxuGJdscwZR7RAs1i3juUHhb55IhzY=@freebsd.org X-Gm-Message-State: AOJu0YyHcrfYxbJQQk0BtmIfT0r+r+vTUE7woZgXsenv/z+u8NHjILjz Nv0wM7NWSbT56IpzomHPMtPklMvQOAP4qlyxXgmh9SMKotiZxI1cqaZ9dhsu0RWqx5dGZU7Ch2o = X-Google-Smtp-Source: AGHT+IG+jwncsJMSdQ7OFFMapT5aGkNSP0WAE28Nx2ydzXQ4+v8sloYfSOCvhZusPVnG6895Ex4kOQ== X-Received: by 2002:a17:90a:de92:b0:2c2:d11b:14dd with SMTP id 98e67ed59e1d1-2d855d3d621mr2474195a91.0.1724964250666; Thu, 29 Aug 2024 13:44:10 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2d844489545sm4728237a91.0.2024.08.29.13.44.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2024 13:44:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: A Demo of rust-in-base From: Bakul Shah In-Reply-To: <202408050841.4758fWV1056499@critter.freebsd.dk> Date: Thu, 29 Aug 2024 13:43:58 -0700 Cc: Alan Somers , Warner Losh , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <202408041800.474I0HUM050473@critter.freebsd.dk> <202408041820.474IKjVV050602@critter.freebsd.dk> <202408041904.474J4b9e050871@critter.freebsd.dk> <202408042038.474KcKrD052069@critter.freebsd.dk> <202408050841.4758fWV1056499@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.977]; DMARC_POLICY_ALLOW(-0.50)[iitbombay.org,quarantine]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[iitbombay-org.20230601.gappssmtp.com:+]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[bakul]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52c:from] X-Rspamd-Queue-Id: 4WvtYS2q7Rz4MBP On Aug 5, 2024, at 1:41=E2=80=AFAM, Poul-Henning Kamp = wrote: >=20 > -------- > Alan Somers writes: >=20 >> If the fusefs test suite were external, [...] >> Any user running the tests would need to build the >> port about once per month, if they track stable/13. [...] >=20 > I understand that, and I share your pain: I've been > there myself with code I have maintained for customers. >=20 > But isn't this a transient problem ? I would expect fusefs, > like everything else, to settle down over time ? >=20 > Also: How many people are we talking about, world-wide ? >=20 > A dozen ? Four dozens ? >=20 > Adding Rust to src would inconvenience /everybody/, every time they > do a "make buildworld". >=20 > The solution is not to add Rust to src. >=20 > The solution is to get rid of the "Src is the holy ivory tower, > everything else is barbarians" mentality, which have gotten us into > trouble with ISDN, ATM, Perl and much else over the years. Amen!= From nobody Thu Aug 29 20:55: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 4WvtpN1dvgz52cSP for ; Thu, 29 Aug 2024 20:55:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) (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 4WvtpM6skjz4NmL for ; Thu, 29 Aug 2024 20:55:23 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-846b934981aso76672241.3 for ; Thu, 29 Aug 2024 13:55:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724964922; x=1725569722; 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=EWDY6z36HJeBErzeCXBdbOXfFuWKzBqfI1paEQmXAvQ=; b=ffzQ1JXcoWOxJx5k+kdqZNMKl6kN0zxpcpnWrCO/PlmgQXuVZlOKJF3oF1xYo/vM4I 0RnDvH04k6TLawdiS6/N9x8autWnEAcSOjgbAJliozBltWUqod15PpUdmYHdakGfWgS0 iZyahtoiyyDqrkWfYDLnvA4prTclteViWg5RDM/FCk5fOO+1WT89lgJ7BJRzKLY07NPs XoygzCjzDyIW58LS371FQwrwa5dEMosTpRKz49SFD+mTkttoRCC8cb8byCS+B2pdSpRJ VvRzIe2ZzbkVWFYCtfuY7cOvACfAlZmuVDBULdRYRe+4tdqSlERgbqdb5IA+BHcXvDb8 edDg== X-Gm-Message-State: AOJu0YxJSJeRy2rC4UAMg0K869Qlbsbi734Mfxrx7Ay2qzU+LVhkAw0b o7y3m+j270DtwwdUefnZkUpp7JaroxSEYlDIRnGYxeeW8sB9zGNTvJe/cexQySfP9F8tluJ/evt Oz4e+AwkOSIP4dtMl4d32ppYDvPXXwQ== X-Google-Smtp-Source: AGHT+IG8g+/oOVfJip356EGYWMzsGmuiraxFnieZl9GbxWlHocNc9sZmerRtkXfL4Wa+JR8gB1b5WKHsVqnhKK+qD1E= X-Received: by 2002:a05:6102:d8d:b0:48f:de85:2b4c with SMTP id ada2fe7eead31-49a5af35cebmr4718332137.23.1724964922355; Thu, 29 Aug 2024 13:55: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: Thu, 29 Aug 2024 14:55:10 -0600 Message-ID: Subject: Re: A Demo of rust-in-base To: Shawn Webb Cc: 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: 4WvtpM6skjz4NmL On Thu, Aug 29, 2024 at 2:21=E2=80=AFPM Shawn Webb wrote: > > Hey Alan et al, > > I apologize for the silence on my end. It has been a busier two months > than anticipated. In that time, I've been entertaining some thoughts > on Rust in base support. ${LIFE} is starting to calm down again, and I > do believe I'll be able to start the research in time in September. I > will be splitting my free time between this and studying for my OSCP > cert. > > So, to those thoughts, in list form (in no particular order): > > 1. Use of Rust compiler toolchain support will be for userland > components in an opt-in fashion. Meaning, all userland components > written in Rust will be optional. > 2. It does not make sense to perform a vendor import of the Rust > compiler toolchain and standard libraries. All Rust code in the src > tree must be built from an external toolchain. > 3. I believe the notion of an external toolchain could be abstracted > such that we can support any optional userland component written in > a language supported by that external toolchain. This would imply > that other alternative languages could be supported with minimal > work (Zig, TypeScript, Python, Java, etc.) > 4. We could provide auto-detection mechanisms for determining which > external toolchains are available, their language support, etc. The > initial proof-of-concept would likely be limited to Rust to save on > time and complexity. > 5. As the work matures, and perhaps as a requisite for eventual > inclusion, we could land support for more than Rust. This might be > a step too far, but hey, it's one of the thoughts I had. > 6. So all of this wrapped up means that: > A. This is NOT a call to rewrite everything in Rust. This work will > only permit NEW, OPTIONAL components to be written. > B. Other languages/toolchains/ecosystems could be supported, not > just Rust. > C. Initial focus is on userland components. Rust in the kernel is > out of scope for this initial proof-of-concept. > D. I would like to see Rust in the kernel. That would be a good > next area of focus once userland support reaches some level of > maturity. > > My first goal will be to get a better understanding of > src.git/Makefile and src.git/Makefile.inc1. As I study that, I'll also > study your work, Alan. I really appreciate the time you have taken. I > might reach out to you and Warner directly for further questions. Relying on an external toolchain and allowing for future external toolchains other than Rust sounds like a really good plan. Conceivably we could even ditch our Lua import and use the same mechanism for that (but please, save Lua discussion for a separate flame war ;) ). I anticipate that the next big decisions will be "what components are so important that they musn't require an external toolchain?" and "how much cargo crate bloat is too much?". But we can cross those bridges when we come to them. I look forward to seeing your work, and please don't hesitate to ask for help. -Alan From nobody Thu Aug 29 21:07: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 4Wvv5F4HQzz52ckP for ; Thu, 29 Aug 2024 21:08:17 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.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 4Wvv5D4RFsz4PvD; Thu, 29 Aug 2024 21:08:16 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1724965688; 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=i1voYYXFd5PXRTag4lFbHG5u5NqjVWf/l9pyJCm5YbA=; b=LA5rltJ/LVbURkppaPqgHUGcomCDYgFOZqRsnkBH8k2kDqSuLb4lyDBZJ6xQ7KnUIAGyAw YnYG/p1o/tFqDBxJ5mz5Oolizc9fUbqKWB2Qg+e8a1VbLk4/QUvy4BAB2ryY1DIQ93JNl1 3bQcMHUiUpw+NURx5S2udZAB8QEoc/U= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 43b23985 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 29 Aug 2024 21:08:08 +0000 (UTC) Date: Thu, 29 Aug 2024 23:07:01 +0200 From: Emmanuel Vadot To: Alan Somers Cc: Shawn Webb , FreeBSD Hackers Subject: Re: A Demo of rust-in-base Message-Id: <20240829230701.9790a7957f4dd6fc3c511d22@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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:12876, ipnet:212.83.128.0/19, country:FR] X-Rspamd-Queue-Id: 4Wvv5D4RFsz4PvD On Thu, 29 Aug 2024 14:55:10 -0600 Alan Somers wrote: > On Thu, Aug 29, 2024 at 2:21?PM Shawn Webb w= rote: > > > > Hey Alan et al, > > > > I apologize for the silence on my end. It has been a busier two months > > than anticipated. In that time, I've been entertaining some thoughts > > on Rust in base support. ${LIFE} is starting to calm down again, and I > > do believe I'll be able to start the research in time in September. I > > will be splitting my free time between this and studying for my OSCP > > cert. > > > > So, to those thoughts, in list form (in no particular order): > > > > 1. Use of Rust compiler toolchain support will be for userland > > components in an opt-in fashion. Meaning, all userland components > > written in Rust will be optional. > > 2. It does not make sense to perform a vendor import of the Rust > > compiler toolchain and standard libraries. All Rust code in the src > > tree must be built from an external toolchain. > > 3. I believe the notion of an external toolchain could be abstracted > > such that we can support any optional userland component written in > > a language supported by that external toolchain. This would imply > > that other alternative languages could be supported with minimal > > work (Zig, TypeScript, Python, Java, etc.) > > 4. We could provide auto-detection mechanisms for determining which > > external toolchains are available, their language support, etc. The > > initial proof-of-concept would likely be limited to Rust to save on > > time and complexity. > > 5. As the work matures, and perhaps as a requisite for eventual > > inclusion, we could land support for more than Rust. This might be > > a step too far, but hey, it's one of the thoughts I had. > > 6. So all of this wrapped up means that: > > A. This is NOT a call to rewrite everything in Rust. This work will > > only permit NEW, OPTIONAL components to be written. > > B. Other languages/toolchains/ecosystems could be supported, not > > just Rust. > > C. Initial focus is on userland components. Rust in the kernel is > > out of scope for this initial proof-of-concept. > > D. I would like to see Rust in the kernel. That would be a good > > next area of focus once userland support reaches some level of > > maturity. > > > > My first goal will be to get a better understanding of > > src.git/Makefile and src.git/Makefile.inc1. As I study that, I'll also > > study your work, Alan. I really appreciate the time you have taken. I > > might reach out to you and Warner directly for further questions. >=20 > Relying on an external toolchain and allowing for future external > toolchains other than Rust sounds like a really good plan. > Conceivably we could even ditch our Lua import and use the same > mechanism for that (but please, save Lua discussion for a separate > flame war ;) ). If you're saying that it means that you've never looked at how lua works. > I anticipate that the next big decisions will be > "what components are so important that they musn't require an external > toolchain?" and "how much cargo crate bloat is too much?". But we can > cross those bridges when we come to them. I look forward to seeing > your work, and please don't hesitate to ask for help. >=20 > -Alan >=20 Isn't the next big decision "How to handle external rust toolchain" ? Because without this solved everything all you rust lovers said in this (and previous) thread is irrelevant. Cheers, --=20 Emmanuel Vadot From nobody Thu Aug 29 21:16:05 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WvvGg3kyXz5MRXy for ; Thu, 29 Aug 2024 21:16:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 4WvvGg1Fqcz4Rkm for ; Thu, 29 Aug 2024 21:16:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2d3c0d587e4so854276a91.2 for ; Thu, 29 Aug 2024 14:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1724966186; x=1725570986; 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=4VzIHlDHfYal3QgR5sqnQmPT8r2wo+19ZMiFV0WU3Hc=; b=HvjSfrWzz5SIZd1w6vGlq9Lq9qBaeKukspkzU3zXiorPRNPYJwhTjuBB9xoILm3VBv SR6vRJWys2nDFKroL5DpmXsDvqRrZMvlJNm+lnbuzDgpfM9MMZoZ6xTp5KosI336vbjS iTEYxZDsVeKUBcfGv/K3KQ00IwuvnXAsASXfIzWtHH4XXwmjKLFZldAGtDrg+Q8ILghI 0zhADOcP+D7sPmmthE8QH6iOR1bkXpL3zFvFn2++Ef/Nw/nqGbh7gOhAwwmXOSDUrE2A 9tRfiSAjMemEkIZRAXgiqUhsN+3idowlNivEUm1JS+RpBT84RYbdbMfzpMQlRLoOADhA c9Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724966186; x=1725570986; 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=4VzIHlDHfYal3QgR5sqnQmPT8r2wo+19ZMiFV0WU3Hc=; b=F9+VI0dXhVNHqoV8JHRCEQPDVE4O91j5/nVVhuTVh2kmZv8NuevGWwXpDVHg1hV06i d1SakLqKuyliOZheoC8tCf4aUJxwAx9QYpxXuYjpH95iuQvOMED290sAyeSW8e76qTyX HMsgdTb/8sFbFMFAtofqUdGYcO2mZuFpZ1DkaSi1zd0vlYgDiU7+9zs4AVN/3OPuwyju XpZyaHmDuWEHnEl1Fse4ybstmwMdi7wWxvQb950WWMnbSvRvc36usYYKCpfvoBaqFLZq Aw/I+5Ms39zfIT1rVQydYQ0nWdjPPVIW1uXpNY+mFa8drJDTNE7Cg5gIItEQr1S0AT8h tcrw== X-Forwarded-Encrypted: i=1; AJvYcCVhFX3n78ZzIemOidZim3hb4Q3tPmgPYZwxe+1dZtKUPA7BlvwcymtqchXPqUlW739HN6+eZ6pIE/RGpN04WWg=@freebsd.org X-Gm-Message-State: AOJu0YzQNrE2JJreJiUlHNEefusQjyOPsW34qFpzux5EjbpgIE1Z8p45 aPWeXLhzebdJ2AOTesThNkwENNge7vYlI6avV5WC5dWXCmExImK6/JI3TXgvm77r1tkHQ1RT5+5 KK1tLP9ozCIUOhhAno8cu2V6I6tAqIvn03LK1OnnSjYf4jMmA X-Google-Smtp-Source: AGHT+IFvbBuO7M+/HH8keJsY915e2Sx2yRE51OUWStLZmt/5wFNzN7lzMydRAf5PKeOhfr3Axg/UefTSoyr7TAoPLnI= X-Received: by 2002:a17:90a:d812:b0:2d3:c4d3:de19 with SMTP id 98e67ed59e1d1-2d855d45b7amr4452391a91.0.1724966185566; Thu, 29 Aug 2024 14:16:25 -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: Warner Losh Date: Thu, 29 Aug 2024 15:16:05 -0600 Message-ID: Subject: Re: A Demo of rust-in-base To: Alan Somers Cc: Shawn Webb , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000bdad180620d8fcb2" 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: 4WvvGg1Fqcz4Rkm --000000000000bdad180620d8fcb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 29, 2024, 2:55=E2=80=AFPM Alan Somers wro= te: > On Thu, Aug 29, 2024 at 2:21=E2=80=AFPM Shawn Webb > wrote: > > > > Hey Alan et al, > > > > I apologize for the silence on my end. It has been a busier two months > > than anticipated. In that time, I've been entertaining some thoughts > > on Rust in base support. ${LIFE} is starting to calm down again, and I > > do believe I'll be able to start the research in time in September. I > > will be splitting my free time between this and studying for my OSCP > > cert. > > > > So, to those thoughts, in list form (in no particular order): > > > > 1. Use of Rust compiler toolchain support will be for userland > > components in an opt-in fashion. Meaning, all userland components > > written in Rust will be optional. > > 2. It does not make sense to perform a vendor import of the Rust > > compiler toolchain and standard libraries. All Rust code in the src > > tree must be built from an external toolchain. > > 3. I believe the notion of an external toolchain could be abstracted > > such that we can support any optional userland component written in > > a language supported by that external toolchain. This would imply > > that other alternative languages could be supported with minimal > > work (Zig, TypeScript, Python, Java, etc.) > > 4. We could provide auto-detection mechanisms for determining which > > external toolchains are available, their language support, etc. The > > initial proof-of-concept would likely be limited to Rust to save on > > time and complexity. > > 5. As the work matures, and perhaps as a requisite for eventual > > inclusion, we could land support for more than Rust. This might be > > a step too far, but hey, it's one of the thoughts I had. > > 6. So all of this wrapped up means that: > > A. This is NOT a call to rewrite everything in Rust. This work will > > only permit NEW, OPTIONAL components to be written. > > B. Other languages/toolchains/ecosystems could be supported, not > > just Rust. > > C. Initial focus is on userland components. Rust in the kernel is > > out of scope for this initial proof-of-concept. > > D. I would like to see Rust in the kernel. That would be a good > > next area of focus once userland support reaches some level of > > maturity. > > > > My first goal will be to get a better understanding of > > src.git/Makefile and src.git/Makefile.inc1. As I study that, I'll also > > study your work, Alan. I really appreciate the time you have taken. I > > might reach out to you and Warner directly for further questions. > > Relying on an external toolchain and allowing for future external > toolchains other than Rust sounds like a really good plan. > It's the only way it could work. Importing rust with its current level of maturity and lag is logistically impossible or nearly so.rust doesn't have a long enough support timeline to work well with our stable branches. Llvm is tricky enough... Conceivably we could even ditch our Lua import and use the same > mechanism for that (but please, save Lua discussion for a separate > flame war ;) ). That can't possibly work since we build it into the loader with changes that are unavoidable. There's no flame war, it's just impossibile. The situation is entirely different. But the lua import is the easiest of all the vendor imports I do. Warner I anticipate that the next big decisions will be > "what components are so important that they musn't require an external > toolchain?" and "how much cargo crate bloat is too much?". But we can > cross those bridges when we come to them. I look forward to seeing > your work, and please don't hesitate to ask for help. > Managing these things in a FreeBSD context will be challenging and i look forward to the results we get. Warner -Alan > > --000000000000bdad180620d8fcb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 29, 2024, 2:55=E2=80=AFPM Alan Somers <= asomers@freebsd.org> wrote:
On Thu, Aug 29, 2024 at 2:21=E2=80= =AFPM Shawn Webb <shawn.webb@hardenedbsd.org> wrote: >
> Hey Alan et al,
>
> I apologize for the silence on my end. It has been a busier two months=
> than anticipated. In that time, I've been entertaining some though= ts
> on Rust in base support. ${LIFE} is starting to calm down again, and I=
> do believe I'll be able to start the research in time in September= . I
> will be splitting my free time between this and studying for my OSCP > cert.
>
> So, to those thoughts, in list form (in no particular order):
>
> 1. Use of Rust compiler toolchain support will be for userland
>=C2=A0 =C2=A0 components in an opt-in fashion. Meaning, all userland co= mponents
>=C2=A0 =C2=A0 written in Rust will be optional.
> 2. It does not make sense to perform a vendor import of the Rust
>=C2=A0 =C2=A0 compiler toolchain and standard libraries. All Rust code = in the src
>=C2=A0 =C2=A0 tree must be built from an external toolchain.
> 3. I believe the notion of an external toolchain could be abstracted >=C2=A0 =C2=A0 such that we can support any optional userland component = written in
>=C2=A0 =C2=A0 a language supported by that external toolchain. This wou= ld imply
>=C2=A0 =C2=A0 that other alternative languages could be supported with = minimal
>=C2=A0 =C2=A0 work (Zig, TypeScript, Python, Java, etc.)
> 4. We could provide auto-detection mechanisms for determining which >=C2=A0 =C2=A0 external toolchains are available, their language support= , etc. The
>=C2=A0 =C2=A0 initial proof-of-concept would likely be limited to Rust = to save on
>=C2=A0 =C2=A0 time and complexity.
> 5. As the work matures, and perhaps as a requisite for eventual
>=C2=A0 =C2=A0 inclusion, we could land support for more than Rust. This= might be
>=C2=A0 =C2=A0 a step too far, but hey, it's one of the thoughts I h= ad.
> 6. So all of this wrapped up means that:
>=C2=A0 =C2=A0 A. This is NOT a call to rewrite everything in Rust. This= work will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0only permit NEW, OPTIONAL components to be w= ritten.
>=C2=A0 =C2=A0 B. Other languages/toolchains/ecosystems could be support= ed, not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0just Rust.
>=C2=A0 =C2=A0 C. Initial focus is on userland components. Rust in the k= ernel is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0out of scope for this initial proof-of-conce= pt.
>=C2=A0 =C2=A0 D. I would like to see Rust in the kernel. That would be = a good
>=C2=A0 =C2=A0 =C2=A0 =C2=A0next area of focus once userland support rea= ches some level of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0maturity.
>
> My first goal will be to get a better understanding of
> src.git/Makefile and src.git/Makefile.inc1. As I study that, I'll = also
> study your work, Alan. I really appreciate the time you have taken. I<= br> > might reach out to you and Warner directly for further questions.

Relying on an external toolchain and allowing for future external
toolchains other than Rust sounds like a really good plan.
=

It's the only= way it could work. Importing rust with its current level of maturity and l= ag is logistically impossible or nearly so.rust doesn't have a long eno= ugh support timeline to work well with our stable branches. Llvm is tricky = enough...=C2=A0

Conceivably we could even ditch our Lua import and use the same
mechanism for that (but please, save Lua discussion for a separate
flame war ;) ).=C2=A0

<= div dir=3D"auto">That can't possibly work since we build it into the lo= ader with changes that are unavoidable. There's no flame war, it's = just impossibile. The situation is entirely different.=C2=A0

But the lua import is the easiest of = all the vendor imports I do.

Warner=C2=A0


I anticipate that the next big decisions will be
"what components are so important that they musn't require an exte= rnal
toolchain?" and "how much cargo crate bloat is too much?".= =C2=A0 But we can
cross those bridges when we come to them.=C2=A0 I look forward to seeing your work, and please don't hesitate to ask for help.
<= /div>

Managing these thi= ngs in a FreeBSD context will be challenging and i look forward to the resu= lts we get.

Warner=C2=A0=

-Alan

--000000000000bdad180620d8fcb2-- From nobody Thu Aug 29 21:19: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 4WvvL30dsCz5MRvF for ; Thu, 29 Aug 2024 21:19:23 +0000 (UTC) (envelope-from linimon@portsmon.org) Received: from MTA-11-4.privateemail.com (mta-11-4.privateemail.com [198.54.127.104]) (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 4WvvL24vqDz4Sbx; Thu, 29 Aug 2024 21:19:22 +0000 (UTC) (envelope-from linimon@portsmon.org) Authentication-Results: mx1.freebsd.org; none Received: from mta-11.privateemail.com (localhost [127.0.0.1]) by mta-11.privateemail.com (Postfix) with ESMTP id 4C85518000A4; Thu, 29 Aug 2024 17:19:19 -0400 (EDT) Received: from APP-19 (unknown [10.50.14.243]) by mta-11.privateemail.com (Postfix) with ESMTPA; Thu, 29 Aug 2024 17:19:17 -0400 (EDT) Date: Thu, 29 Aug 2024 16:19:17 -0500 (CDT) From: Mark Linimon To: Alan Somers , Shawn Webb Cc: FreeBSD Hackers Message-ID: <513777314.1483783.1724966357189@privateemail.com> In-Reply-To: References: Subject: Re: A Demo of rust-in-base 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: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev67 X-Originating-Client: open-xchange-appsuite X-Virus-Scanned: ClamAV using ClamSMTP 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:22612, ipnet:198.54.127.0/24, country:US] X-Rspamd-Queue-Id: 4WvvL24vqDz4Sbx > On 08/29/2024 3:55 PM CDT Alan Somers wrote: > Relying on an external toolchain and allowing for future external > toolchains other than Rust sounds like a really good plan. Coincidentally, earlier today I was audting the wiki page https://wiki.freebsd.org/ExternalToolchain which seems like it discusses some of these issues. The last content update was 2020, so I assume it needs updating. mcl From nobody Fri Aug 30 04:52: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 4Ww5NY4s12z5PZ7x for ; Fri, 30 Aug 2024 04:52:13 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [199.15.120.13]) (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 4Ww5NX72c3z4616; Fri, 30 Aug 2024 04:52:12 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fullermd@over-yonder.net designates 199.15.120.13 as permitted sender) smtp.mailfrom=fullermd@over-yonder.net Received: from draco.over-yonder.net (c-174-180-135-60.hsd1.ms.comcast.net [174.180.135.60]) (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 mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 4Ww5NP46gjzDs8; Thu, 29 Aug 2024 23:52:05 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 4Ww5NN4SWBz4mH; Thu, 29 Aug 2024 23:52:04 -0500 (CDT) Date: Thu, 29 Aug 2024 23:52:04 -0500 From: "Matthew D. Fuller" To: Alan Somers Cc: freebsd-hackers@freebsd.org Subject: Re: Announcing freebsd-rustdate Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/2.2.13 (2024-03-09) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.13 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_SPAM_SHORT(0.17)[0.166]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:33069, ipnet:199.15.120.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[over-yonder.net]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4Ww5NX72c3z4616 > Maybe I can try and get a real project setup over the weekend, I mostly did, but didn't mention it; setup a project at https://launchpad.net/freebsd-rustdate with the current trunk at https://code.launchpad.net/~fullermd/freebsd-rustdate/trunk Also put up a new 0.6.2 patch release with a fix to updating permissions on existing directories (when appropriate), and various minor code fiddling. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From nobody Fri Aug 30 10:56: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 4WwFTQ07zZz52b1n for ; Fri, 30 Aug 2024 10:56:58 +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 4WwFTP546wz4fGC for ; Fri, 30 Aug 2024 10:56:57 +0000 (UTC) (envelope-from ltning-freebsd-hackers@anduin.net) Authentication-Results: mx1.freebsd.org; none 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:Cc: References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: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=cXCbXW8EUPlVQ5rmR0PVopmODXLWNkyE2aBPLiOeZ/4=; t=1725015417; x=1725879417; b=BZ8drvnPkaDcAw5dyx/4AobXK4T8iLi4qlIoJdmGNgJhod5QOYVu8FZi3GbwdcbsEnt4K3B+xKx QikER0P7Y4bp/kekE2Os90Ph0kKP/zSwdaF/5RWCbIhz/BE6V/ceM9KcCrcCqDvLtq28R/IT7e2dW LrLxbExl3vnDE0SfXL8x1cyQ1UqVhznprIUWtC+Ed6jJtzwB9tOfchadgtoAeb3tz5mNOWQDUOuWy 9I7d3M0DjvDqsrQwjoAtPT6sa1g0BmLEb02HRbXSGXr+0pXkUDEYMXI5oYROIDT8eVqXyiPGkcItA 2oHUNrDL2QB2w1DBX5za2UvrDlQey0zsEh1A==; Received: by mail.anduin.net with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.97.1 (FreeBSD)) (envelope-from ) id 1sjzJG-0000000087n-2178; Fri, 30 Aug 2024 10:56:56 +0000 Message-ID: Date: Fri, 30 Aug 2024 12:56:36 +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: Announcing freebsd-rustdate Content-Language: en-US To: freebsd-hackers@freebsd.org References: Cc: fullermd@over-yonder.net From: =?UTF-8?Q?Eirik_=C3=98verby?= In-Reply-To: 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,T_SCC_BODY_TEXT_LINE=-0.01 | autolearn=ham autolearn_force=no, score=-0.01 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:62248, ipnet:185.42.170.0/24, country:EE] X-Rspamd-Queue-Id: 4WwFTP546wz4fGC On 30.08.2024 06:52, Matthew D. Fuller wrote: >> Maybe I can try and get a real project setup over the weekend, > > I mostly did, but didn't mention it; setup a project at > > https://launchpad.net/freebsd-rustdate > > with the current trunk at > > https://code.launchpad.net/~fullermd/freebsd-rustdate/trunk > > > Also put up a new 0.6.2 patch release with a fix to updating > permissions on existing directories (when appropriate), and various > minor code fiddling. Any hope of seeing this in ports? Then I could actually play with it at some scale around here.. /Eirik From nobody Fri Aug 30 11:08: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 4WwFl72kXjz52cVG for ; Fri, 30 Aug 2024 11:08:51 +0000 (UTC) (envelope-from otis@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 4WwFl7299Kz4h4N; Fri, 30 Aug 2024 11:08:51 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725016131; 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=Ejs1mvjItbaBxnpIftLNeXL8gUlOpknR+4Q9l9pd8KQ=; b=JKaPPRKwUEWLiGQg5bY3R0K+IuGwjpZgY5n5gR+/Dp2DKAW2qGH3Dmb8aTetcS+7dWeX8F DnX+MVSftPrcIFwrjvbWKj8fbLTq+7Prmpjgtec5ZYMAhMnpskwwDSwSDFd/OQi+Zu9cwt /zBGBDkA+ibas5Gbsn6hJMQrBENJcY8NUdtTmL+z4UOlfKImlB5a7FX+dMiQ93smkIB5S+ a68NaOl0UON233WRhhGFl8/HQ7vwPbQqKoSrTl69z9P7ErsVcpRSu141mKpo9FOJ+71nl2 /PVSlVjipOO2/YRXU0+lJyFLaQ9hoN1XscpaWnOPbITm379+C5et6z8ezlGXIQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725016131; a=rsa-sha256; cv=none; b=RVrwfAbjql6XrfrVOpY5rAXeWNuqGk9KYvqHurMV4vQx5y84A+6LY0sfko4dOoPgheZSvP CUxypYVfafedDVnP8j+0dlQMc4oqv0S7W6nHvS4qDQEW5VJW5qSz70zsqMcwo5qnhiYe9G oa246/BlvuMZ5Q+LUkudY4blrJ9WLR2oqDCZmcheDgC9L8EA0BJzrJ2Afa99Fl1Q2pOdad 99WVvhWUGlL3g4lA9lcj8KE3pMIg3NPnsV6xLTftgkclGr92m/+zXzh9wMCwoj4W9ZV15o p+gaatP9ksBci0y2u7gTrH+Qdlz5JE0aQRzPgI4AxQkUJLWZo8WOCDaFUsrhLg== 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=1725016131; 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=Ejs1mvjItbaBxnpIftLNeXL8gUlOpknR+4Q9l9pd8KQ=; b=LVQ9j17WdqnfpZapBr1EuJlxn9HeWzuiJGHRfh1jWiMkG6uZTMbjeCiMzbmXzk8UFX/KJO RtPtm3hafDXTlUvvzrUdJ1eFOW0TqyrycmR9ryTkfD/BR2OXCC4P0pu67qs4x/JtPocrce 9Qb4xA6GfTBUa10Zzn3HddbKka1+/Wiy2ZNNPrX9MehpLlzN4p05NURt4hrSfK0b3P0ZXh 8fLFL9dQPjzfqaPJ1xkxxaI3ACPdy3XbQ/eRrbs1HjMc37OabGXHNBSDau0yYW/1ZOi4kR XVvQ4d3FqvjeiiQdrdGIdvg6JpE4EaVDJZaKxI/3Gnp2AYVwmuolcBEnCZtPhQ== Received: from ns2.wilbury.net (ns2.wilbury.net [92.60.51.55]) (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 "svc.wilbury.net", Issuer "E6" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WwFl70rqjz13Dm; Fri, 30 Aug 2024 11:08:51 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (gw-t.owhome.net [87.197.133.183]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 64B1261F8D; Fri, 30 Aug 2024 13:08:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Announcing freebsd-rustdate From: Juraj Lutter In-Reply-To: Date: Fri, 30 Aug 2024 13:08:37 +0200 Cc: FreeBSD Hackers , fullermd@over-yonder.net Content-Transfer-Encoding: quoted-printable Message-Id: <3A39D68A-D0E9-4D49-B12D-2AB905EC5494@FreeBSD.org> References: To: =?utf-8?Q?Eirik_=C3=98verby?= X-Mailer: Apple Mail (2.3776.700.51) Hi, > On 30 Aug 2024, at 12:56, Eirik =C3=98verby = wrote: >=20 > On 30.08.2024 06:52, Matthew D. Fuller wrote: >>> Maybe I can try and get a real project setup over the weekend, >> I mostly did, but didn't mention it; setup a project at >> https://launchpad.net/freebsd-rustdate >> with the current trunk at >> https://code.launchpad.net/~fullermd/freebsd-rustdate/trunk >> Also put up a new 0.6.2 patch release with a fix to updating >> permissions on existing directories (when appropriate), and various >> minor code fiddling. >=20 > Any hope of seeing this in ports? Then I could actually play with it = at some scale around here.. The port can be made if there would be a =E2=80=9Crelease=E2=80=9D = tarball. Now the code is accessible via Bazaar only. =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Fri Aug 30 15:11: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 4WwM7P4Bjzz5Mkxl for ; Fri, 30 Aug 2024 15:11:45 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [IPv6:2604:3a00:2:1::2:13]) (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 4WwM7P03Ghz43Hm; Fri, 30 Aug 2024 15:11:44 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Authentication-Results: mx1.freebsd.org; none Received: from draco.over-yonder.net (draco.over-yonder.net [IPv6:2001:470:1f0f:11ae::5]) (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 mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 4WwM7F1tpWzF1l; Fri, 30 Aug 2024 10:11:37 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 4WwM7C4pWkz5JM; Fri, 30 Aug 2024 10:11:35 -0500 (CDT) Date: Fri, 30 Aug 2024 10:11:35 -0500 From: "Matthew D. Fuller" To: Juraj Lutter Cc: Eirik =?iso-8859-1?Q?=D8verby?= , FreeBSD Hackers Subject: Re: Announcing freebsd-rustdate Message-ID: References: <3A39D68A-D0E9-4D49-B12D-2AB905EC5494@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3A39D68A-D0E9-4D49-B12D-2AB905EC5494@FreeBSD.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/2.2.13 (2024-03-09) 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:33069, ipnet:2604:3a00::/32, country:US] X-Rspamd-Queue-Id: 4WwM7P03Ghz43Hm On Fri, Aug 30, 2024 at 01:08:37PM +0200 I heard the voice of Juraj Lutter, and lo! it spake thus: > > The port can be made if there would be a “release” tarball. Now the > code is accessible via Bazaar only. ?? There've been release tarballs on the site since before the bzr branch was even pushed somewhere visible. > > On 30 Aug 2024, at 12:56, Eirik Øverby > > wrote: > > > > Any hope of seeing this in ports? Then I could actually play with > > it at some scale around here.. I'm holding back a bit on that currently on the theory that it'd be likely to pull in some less early-adopter-y types. I want to get some more feedback and bug reports (or better, non-bug reports ;) from the sorta people who read -hackers before it gets sprung on the sorta people who don't. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From nobody Fri Aug 30 15:22:24 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 4WwMN22k1bz5Ml3R for ; Fri, 30 Aug 2024 15:22:42 +0000 (UTC) (envelope-from otis@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 4WwMN22CgNz44gQ; Fri, 30 Aug 2024 15:22:42 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725031362; 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=5yzvyRhED+MUnCaElzIbQgHyyBsPxcRmur3HgfrRA4Q=; b=pe1ChaIhVft4/WqZJFJUe8GMqZFQvzWUfKdaMyktEXge7oWxwp00YAaeadZ9+O2D2q/qhY JA/pwjF8VD4WgDYwmpk9HF/SEd3FTHKggnBmFrBjAUcfk+qld7ciSIcmIwlEuk9xLPvorw GzqeRRWJF0VYD918oDnepSnEWunp1SOgpAlQqiafAlvXso7xgwdubFsTjdlgaoHsNk3GUr 5RmFOwa4149eqtAIxZSf+3mMaEazouF4qRpAlBLBBTLWg8a+k8wSevMHAxB4WfhxhtcmgO lpR19HWHs+PVx/TfQRlYuu7VFFTP3oWntYwtj45IwGDWH20R9pzap68/sT9xEg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725031362; a=rsa-sha256; cv=none; b=PDAx+4KYUjdHpBZJIVoYJsbXQPm0Jj/4XXDhjNaRUb/ZphwC0ckedQm3YBOZuUoXLm77tX gXn0cEM0RIAUo4OXA150JrQKUjKzNyuqVi6JQgNC7DaXkzJXBFFcoqh40rtTL7iMUjRdHR S6SW3q4+JH3ph7xdQZC0zQ+HefgbOkwnC2aYj3hC9r9L+7yd2zoD8RenQG8lsQvSVkhda6 oNbU4jKyrigovEV8hVIuUQXJkg/eS7ZFCOZJisjEskSSyY2FbAbGOupOTHxTKm1DNSHLoG veqCqM3+Vd62Q9PqDSc/0bvzLCF6mu7cOWhlMeMLoeaG2lE33Cz1Dmy9c2M93A== 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=1725031362; 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=5yzvyRhED+MUnCaElzIbQgHyyBsPxcRmur3HgfrRA4Q=; b=LpHPpXu/lC2N+2tKcI5ggmWnws/hoa19B1YXYTgatdIrNNUxXkswGFOQ0bwJvMSqyjjLf7 SU2onHP2yhrx8H7nhb4hd9y6kPDiXLfAh11oplbRsA+puWRw+8/4hmFlVddyFQgDeYG0MV OUKr+o+5reiXphCPn1cSUJGXStDEuWM2v6iAcik9n146Uq4vd6fQwVmBFxd1zOgFAqx9oY QZ7Sf+LdK/33ss3jlFUBBp1QamQzJi0+yvSFOGYAkCrFxJFOJ0ZCqOiJWftqcpRsRdM7ri 5b7p6iQFrVSgnvOVEhBD3N3tcP3bz4vWn2TbUy3srxxjMEOCvoZkj/jVtN0wyg== Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6]) (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 "svc.wilbury.net", Issuer "E6" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WwMN212Fbz18DG; Fri, 30 Aug 2024 15:22:42 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (gw-t.owhome.net [87.197.133.183]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id D47B0620AB; Fri, 30 Aug 2024 17:22:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Announcing freebsd-rustdate From: Juraj Lutter In-Reply-To: Date: Fri, 30 Aug 2024 17:22:24 +0200 Cc: =?utf-8?Q?Eirik_=C3=98verby?= , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <641109DB-9D12-4A0D-AA28-BE868F7DD6C2@FreeBSD.org> References: <3A39D68A-D0E9-4D49-B12D-2AB905EC5494@FreeBSD.org> To: "Matthew D. Fuller" X-Mailer: Apple Mail (2.3776.700.51) > On 30 Aug 2024, at 17:11, Matthew D. Fuller = wrote: >=20 > On Fri, Aug 30, 2024 at 01:08:37PM +0200 I heard the voice of > Juraj Lutter, and lo! it spake thus: >>=20 >> The port can be made if there would be a =E2=80=9Crelease=E2=80=9D = tarball. Now the >> code is accessible via Bazaar only. >=20 > ?? There've been release tarballs on the site since before the bzr > branch was even pushed somewhere visible. I=E2=80=99ve only looked to launchpad (pardon my ignorance). =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Sun Sep 1 00:00: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 4WxBqN1Rr8z5TWP6; Sun, 01 Sep 2024 00:00:48 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WxBqM4khVz43Lr; Sun, 1 Sep 2024 00:00:47 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725148847; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=DEAticYWSpDMCy6Gf/wNbVxud+L0bKovl3lBkTu6fHk=; b=HgZkAmq5jpdX16Tti1QjMZ1i4NkvfyZlCGfYPnq5/pwzzIGBBHOFBpkhvwmDh8MziMggPs 189YVImOUErytPpjNmwYJhgbPbFHBw2ODnsvvQl/XZxfBTs3jUmozPpPB83cgEIVdIzzgD GrNV/oOUB2stkWGtC/ctvDbeeu6aFvpu/h6NrdlfJeYmiBWh+7qVk7oMXHIGZHpJ5Pvl7/ SRSlAgMaTZFgxZua1d7Vww5E9Ehe28m+DajbUSmZNjUeJZYHKLYFOdpvt50/fCpsKfEVE2 2k3j4/WTGCZsMn4gllCPAaD1KlaZAeVtZBLdAOeocsCvFh0MfkvWN4oMVfhr4w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725148847; a=rsa-sha256; cv=none; b=PgAB4mhO+7Ldsl651GrGVSuvZv5sHDWSVvraZx8C5PX2uwK1oEuqLEWYiMky2WZJ5vn9Z0 t4iGD0y91/vneBsmQ95aio0UFdbEP9VvAQ5HNdgLe2wRingDpm+cppDEpU3JspWBeZRIEk X+SULSJEdhvRBVFghg9coEeM61ThiuVMVzDp2LBEEmYWJ2b+XlUQmspRd6aZ5l0HB+ALqr FdoPlEcL+MIk/r8dXOTkJKMFQ5iX4dSe33drdlZbI80l034hXABuasQ0O9mAdLhXFNNUNP kz7q2h7mfZkv7KVr1flfI5GfkwjVbjMiAyRNRBufAZW5R+HaD1XEyNTdU3L2pQ== 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=1725148847; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=DEAticYWSpDMCy6Gf/wNbVxud+L0bKovl3lBkTu6fHk=; b=pX2gvzX/zUQYB7appBkaP6TYHk39bBp8/hsS143fvw+40wcDFwVoYHANbuPI8626fh1j4l zHJ9cVp0b0AGjYgLU4d02sZRFYHpkPJRfD2dCzPoPGR+osrCnK9DwPOJEEDbxjsKUfHAej geWU9zmGnn0esM81h2mOftahYPLqWImaCOsP1G4N9dNgeBkZm5u9fRopH/XgoLRymVLo1J 8pmhOEW+xsyZ/+/AmWvU4481kqDFbFzmk6WQOrhiAuRegrqqsM3c3cMceibWk9BvPA0apP yT4Qf7sTZ5d054upkf0woPkLEToF6KRscY2ltIS/+o+R4rL5RV3+cxrO5GIC7w== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 6CCD21917E; Sun, 01 Sep 2024 00:00:47 +0000 (UTC) To: freebsd-status-calls@FreeBSD.org Subject: Call for 2024Q3 status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20240901000047.6CCD21917E@freefall.freebsd.org> Date: Sun, 01 Sep 2024 00:00:47 +0000 (UTC) From: Lorenzo Salvadore 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 Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is September, 30th 2024 for work done since the last round of quarterly reports: July 2024 - September 2024. I would like to remind you that reports are published on a quarterly basis and are usually collected during the last month of each quarter, You are also welcome to submit them even earlier if you want, and the earlier you submit them, the more time we have for reviewing. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The following methods are available to submit your reports: * submit a review on Phabricator and add the group "status" to the reviewers list. You should put your reports in the directory doc/website/content/en/status/report-2024-07-2024-09/ (create it if it is missing); * submit a pull request at . You should put your reports in the directory doc/website/content/en/status/report-2024-07-2024-09/ (create it if it is missing); * send an email to status-submissions@FreeBSD.org including your report. An AsciiDoc template is available at . We look forward to seeing your 2024Q3 reports! Thanks, Lorenzo Salvadore (on behalf of status@) From nobody Sun Sep 1 20:50: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 4WxkY7279Lz5PRWQ for ; Sun, 01 Sep 2024 20:50:19 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WxkY651Tsz45pT for ; Sun, 1 Sep 2024 20:50:18 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725223818; 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=BzMPsMZ3y1L7E7ili7Ja5wWX7NpfCVb5rip85v97dr0=; b=B247ovL89SZBgnA9a80jedeA+Vv8a2MuCkvbVP2GFipGcrKmuXVWhxHpuLIZHwfGr6Hixi OExFw2QNRlB7zLbrQCxuePiIYvtXVxrgYDTOR/ezY5xktCkZwdio1Y8/F7SbBGW98uThTW nXRzpPZj+D75zzwj6fOl3xlwnBUsfOW8+/EP+h5IFNtAT36unOtaeB2s7/NbuTxLT7NdNv YgjueI8dAgEoQtGl5ErPa0Yw08VbmSX3dR4oc7KeLj5FI42xJ8ShFnQ8kU761xIDJIuzUZ 6eCnFappvZihO+yWli5aWZkw+TCwPs2GhlYl5FYuzbkmoXzHmApnQUyqSyLs2w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725223818; a=rsa-sha256; cv=none; b=uDTF0yKJQhwLHDKpWqYjuKUD6+vI0Tuzz8AKkOphYB5XIkFTn60cXxT5Hz9DGMbT9uzZbl wKodYr+kemAwC2qF53ousD38FUHGFSrfZkVtd7QZCsq8LdnVDLbAow0XnY2fDPa1wZDCpe BM5OAQh1dQByg1bb+MU3YFUb4DB0K6qrYkCNdKeqyq4qwm3KSqnWcHXvRI0B//qd35JJF+ 75LjCIXZ7cJIbfFhiRCSd1H9Oa63MPHvOmsnAVZSJmq9RjK4u9xJDhqECPA/GuEEt/k8XB j0Ns+ebnzz/x2chNSBlNSJ+F7s2XNWBtuVrMB0nN/hG8J7AC8QrGUS0ZwVh+2Q== 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=1725223818; 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=BzMPsMZ3y1L7E7ili7Ja5wWX7NpfCVb5rip85v97dr0=; b=qFSPQhTW6svJ0SYMvKF1ul/D42yXlC4kvBxxiwKjwH3qQccs1JT9RUGaAuQCVVSpujInmC FUkK1oAhaQPXUGTqPlWs9531nqp/yMgV3M042k8y3lK/+IR+yL9uVTYsq/ErCSqqDUgmdC ETSdRjCs1ibnDqVx8gmR5eQuxTl9PCRRWVM1OccHxo/qKI42AxkIvl3kCtC9rWKRF8TsGN 9AxgOnKi8E/jKsrCs0iLI1g66dBl6URuXfxDPAeX/3P857zeOJ/wVrlR3VExh9lEe23uR0 KN6B/JNVCUsrfDsKTodqB2wG2TotWMfMjZ8VdA41hJA8oeWliuyCDUxfGWhzaA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 9B8831B7E1; Sun, 01 Sep 2024 20:50:18 +0000 (UTC) Date: Sun, 1 Sep 2024 22:50:16 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: makefs -t ffs makes too large image Message-ID: References: <1781435895.20240822135231.ref@yahoo.com> <1781435895.20240822135231@yahoo.com> <334195982.20240822182405@yahoo.com> <70579701-7457-46b1-9329-a51eddec51de@aetern.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/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ye43xs7wbdoepxrc" Content-Disposition: inline In-Reply-To: <70579701-7457-46b1-9329-a51eddec51de@aetern.org> --ye43xs7wbdoepxrc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Fri, Aug 23, 2024 at 12:39:26AM UTC, Yuri Pankov wrote: >Anthony Pankov wrote: >> Hello Miroslav, >> >> You are genius! >> >> But the situation is a very frustrating. It is a default system and I did nothing to turn the compression on. >> So I was absolutely sure that compression is off. >> >> I'm sorry. >> Nevertheless having compression on by default is a very weird decision and is fully unexpected for me. I've never seen a big warning about default value of this vital parameter will be inverted. >> >> On 12 -STABLE: >> >> # zfs get compression >> NAME PROPERTY VALUE SOURCE >> ps2 compression off default >> >> On 14-STABLE >> >> # zfs get compression >> NAME PROPERTY VALUE SOURCE >> tank compression on default >> tank/bsdsrc compression on default > >It came in with the following openzfs commit and probably no one really >noticed as installer turns on compression by default, so I was going to >say it was always that way until I looked up the change :-) > >commit 56fa4aa96eb3875f254e93eaef646ea20ba187f9 >Author: Rich Ercolani >Date: Thu Mar 3 13:43:38 2022 -0500 > > Default to ON for compression > > A simple change, but so many tests break with it, > and those are the majority of this. > > Reviewed-by: George Melikov > Reviewed-by: Brian Behlendorf > Signed-off-by: Rich Ercolani > Closes #13078 > >And it looks like it's in FreeBSD starting with 14.0: > >$ git branch -a --contains 56fa4aa96eb3875f254e93eaef646ea20ba187f9 >* main > remotes/origin/HEAD -> origin/main > remotes/origin/main > remotes/origin/pull/956/merge > remotes/origin/releng/14.0 > remotes/origin/releng/14.1 > remotes/origin/stable/14 > Hi folks, It's maybe also worth mentioning that compression by default makes ZFS faster. Allan Jude had some numbers for the default (lz4) in the presentation he did while implementing zstd[1]. It can be a bit surprising though, but hopefully it's a good one.;) Yours, Daniel Ebdrup Jensen 1: https://papers.freebsd.org/2018/bsdcan/jude-zfs_zstd/ --ye43xs7wbdoepxrc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmbU04hfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87pMCAgAhyyiK1ZfqMhvtP40GdcFly7boMIL+ukg/2QHK4rEicZ0WbZ+EtDI+7GE DEyBGkbPJiy8yljTCtI3dVqBHqehqwRJwrAybdV+JBGhFrX23vnVi3XxcK9EDB14 sze349oJ1YlSN6582eR+metv41jnJF/3dqIcraH9CbIuWY/dNm9W3pBoYKIT71br MpCvj3074my9XW2nBvmdN4uyphJEX04J93TiOPPXp2mSYRmB/nO5waou4h3LaTMl ApbeLkUxrZkoI4JkikQPNEOYl/gV1VNqKMwjaIzs/1yfHUTTJxQTqjaPx8iCGkaX wSRtasKu3NTHUHQ2TJa77/xyb79FGA== =H+03 -----END PGP SIGNATURE----- --ye43xs7wbdoepxrc--