From nobody Tue Jan 30 13:30:54 2024 X-Original-To: freebsd-arch@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 4TPQzV02fTz58rNH for ; Tue, 30 Jan 2024 13:31:02 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from thyme.eden.le-Fay.ORG (THYME.EDEN.LE-FAY.ORG [81.187.47.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4TPQzT21QQz4brZ for ; Tue, 30 Jan 2024 13:31:01 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=thyme header.b=LcMluT1x; dmarc=none; spf=pass (mx1.freebsd.org: domain of lexi@le-fay.org designates 81.187.47.194 as permitted sender) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (IRIS.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106::18]) by thyme.eden.le-Fay.ORG (Postfix) with ESMTP id 8CC9E2A687 for ; Tue, 30 Jan 2024 13:30:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=thyme; t=1706621454; bh=Pqw0l7i0VpKAOmufgZq4xOtpb3VH484EfTvI0V2OOhg=; h=Date:From:To:Subject; b=LcMluT1xT7PIu6SIUEupwHJceD7Hv513O3kHK7nQIK7TplWI434nak7o+15mDBKYX TKPb97/d119e3o+Iu5BilT1XLXMRKnuqyZIZyiT8qyGSiGtusCrRHeDCDkdz5CnjwL HEkeoBWX3/b/df8ZKqfr8CIZWimQ7ZSEimMsrric= Received: from ilythia.eden.le-fay.org (ILYTHIA.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:104:3::101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 801D489A9 for ; Tue, 30 Jan 2024 13:30:54 +0000 (GMT) Date: Tue, 30 Jan 2024 13:30:54 +0000 From: Lexi Winter To: freebsd-arch@freebsd.org Subject: improving C++ libc headers Message-ID: Mail-Followup-To: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nJjOCEOJipdTs2Bi" Content-Disposition: inline X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.49 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=thyme]; R_SPF_ALLOW(-0.20)[+ip4:81.187.47.194:c]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; ASN(0.00)[asn:20712, ipnet:81.187.0.0/16, country:GB]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[le-fay.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[le-fay.org:+] X-Rspamd-Queue-Id: 4TPQzT21QQz4brZ --nJjOCEOJipdTs2Bi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi list, i am considering working up a patch to improve C++ libc headers in FreeBSD. the problem with the current headers (which come from clang/libc++) is that this code compiles: ------ #include auto main() -> int { exit(0); } ------ this should be a compile-time error, because does not declare ::exit[0]. however, it works because is implemented like this: ------ #include // exposes ::exit() namespace std { using ::exit; // ... } ------ i would like to replace this with an implementation that does this instead: ------ namespace std { extern "C" void exit(int); // ... } ------ i have done a very quick proof of concept for this and it does work; there are some more complicated edge cases, but nothing that can't be dealt with from what i can see. but before i put any amount of significant effort into this, i'd like to check if this is something that is likely to be merged. to address some potential objections: - i don't believe this can be handled upstream in libc++, because some of these headers require knowledge of the implementation - needs to know about 'struct __sFILE', for example. - "import std" should solve this properly, but there are a lot of implementation issues with this and it's not clear if/when it will ever be supported; in the mean time, the existing standard headers should behave correctly. [0] https://www.eel.is/c++draft/cstdlib.syn#header:%3Ccstdlib%3E [1] https://cgit.freebsd.org/src/tree/contrib/llvm-project/libcxx/include/cstdlib --nJjOCEOJipdTs2Bi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmW4+gsACgkQDHqbqZ41 x5n1RAv/X0qs0gIRVtIM7tAfxJi7CFPmEgWH4crfPIpEQT+X3SfgDSO0HAMvleqt POidCb2xwAZ9xJ4AFBd0dL8U/BUfEfG4pRRkllku2SfQdf1VTx+gKi1kfNXnzWUq pEdZQSTI+oTy1lHraddimLV6aM+UrTH6KLCenwhkZcCtP5q11LiG7k3JJjfGKVYo vhlXWMz5qCy3tjU13/XeAP7BiuqCbcnwrJSa4Hxe8COOMwMmyl75BRIV1x/46ODG Xbnlv/poxl1bS0XwjYp+PkLFA6nR3jcb1P04mxcZqnF0fqAvGHTNVfI5/OXhHbZM H3jLHzpDRoTl9hyAGiL5uEPgWVatG4Qyjdteffk1HYupcEjr6TSOliCD0BGPGdLe UwN+EjnuIymRmbN0oLMGoSvRV5QkTig4DaaKSmiyHDYco8iZ2pmTg3mqnv0Pa3uI adXelkf2/GOgXWGkp1MO4du7Xr3hisdN565H3WbGTfhBbCl3N6GXdPdo6YJo3OJ2 WmwaP51e =so+Z -----END PGP SIGNATURE----- --nJjOCEOJipdTs2Bi-- From nobody Tue Jan 30 19:12:16 2024 X-Original-To: freebsd-arch@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 4TPZYT2hCTz59Npv for ; Tue, 30 Jan 2024 19:12:29 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPZYT0sXwz4YNt for ; Tue, 30 Jan 2024 19:12:29 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-5ceb3fe708eso2666798a12.3 for ; Tue, 30 Jan 2024 11:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706641948; x=1707246748; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=9Vd/fWk58W/7iGNGuy5+bW4dTk/9Mk4M5m4QO6FcNMo=; b=JOFs3tZXja3fWuB1otTo6HLNxJGnr2UCumipbDD4qIUzHy/xo7PHpgVoGLmsfATH0d X38+dLylFAIeNp9jIN/ejMtu95Rg+BRZH0K986JMxLjrlPl0hU/2YacHNTEwAk5/Bl01 NSon73smFPv9J62kkyRUxVzFiUWhmsnYJErVrHzTJocyn6zxxlNpe0SyIXxUtfQrxcPZ Jwms2BVQQveqm/eV5TIq4L4SgEfBbOtGdxbFrQL2pNN38wx/FsHYivWzJNTxFU5epJXJ 9zTmMSPNzb2+GrPQVjpi3Ysh1iKJwmNuPNzXVE9TOC7qC25StZrpuYoGVnPtyY9XzWkj NuMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706641948; x=1707246748; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9Vd/fWk58W/7iGNGuy5+bW4dTk/9Mk4M5m4QO6FcNMo=; b=IBZnjlWOlPowQRonOXSt5iHbHt52Ymn3AHANn2D1NTCxtMnIUpPaLChb00DKGB5lE3 MiNPsmMMh0BDrF5M40EYXAgIYRdE9Q6cIjAAHQhLEv0NdxZl71m9i6jenZvJt5yzI665 kHb9iesDTmrzLIbMZz46Egcgvu7Vs1OKkAEOx3J4s5bIKjnLLdnhRBxWrQZtP+c4uhPV 8xyA4EMXbPFioVSZTNU6MR/Qsmx9956SrlWgPrzCBU677dWltOv0ckk+wu+XIFs29bkF /toBWDVHp3lsWjleqesqgfyUMNjptYYatirydz3VWOoPoN1OgCz/ZlvXHJ2Rmps1NnTO KPPQ== X-Gm-Message-State: AOJu0YxdrIgGspI92IfhMJpUmdozeHh6o1D4/f/XV4Jr2SVD/byGQWw4 eymyIYUwdmujvkaVwZ6B6V+zAE+qIpMqfPbKLt31JyoDDv0E60ALfFLbE4E6 X-Google-Smtp-Source: AGHT+IHJt2d4bbvlTQr3Bs7/rtArvGAzUtFZ3V4IG6IQq8Lfe3Ntht+rfhArofvVDFN+syN8tV9ZLQ== X-Received: by 2002:a17:902:ed04:b0:1d7:2403:ed20 with SMTP id b4-20020a170902ed0400b001d72403ed20mr6614099pld.16.1706641947464; Tue, 30 Jan 2024 11:12:27 -0800 (PST) Received: from smtpclient.apple (c-73-109-44-219.hsd1.wa.comcast.net. [73.109.44.219]) by smtp.gmail.com with ESMTPSA id 4-20020a170902ee4400b001d8ceaa1a5bsm4731175plo.304.2024.01.30.11.12.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jan 2024 11:12:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Enji Cooper List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: improving C++ libc headers Date: Tue, 30 Jan 2024 11:12:16 -0800 Message-Id: <7D5B040A-688E-47EA-8BF6-04AA18477399@gmail.com> References: Cc: freebsd-arch@freebsd.org In-Reply-To: To: Lexi Winter X-Mailer: iPhone Mail (21C66) X-Rspamd-Queue-Id: 4TPZYT0sXwz4YNt 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] > On Jan 30, 2024, at 05:31, Lexi Winter wrote: >=20 > =EF=BB=BFhi list, >=20 > i am considering working up a patch to improve C++ libc headers in FreeBSD= . >=20 > the problem with the current headers (which come from clang/libc++) is > that this code compiles: >=20 > ------ > #include > auto main() -> int { > exit(0); > } > ------ >=20 > this should be a compile-time error, because does not declare > ::exit[0]. however, it works because is implemented like > this: >=20 > ------ > #include // exposes ::exit() >=20 > namespace std { > using ::exit; > // ... > } > ------ >=20 > i would like to replace this with an implementation that does this > instead: >=20 > ------ > namespace std { > extern "C" void exit(int); > // ... > } > ------ >=20 > i have done a very quick proof of concept for this and it does work; > there are some more complicated edge cases, but nothing that can't be > dealt with from what i can see. >=20 > but before i put any amount of significant effort into this, i'd like to > check if this is something that is likely to be merged. >=20 > to address some potential objections: >=20 > - i don't believe this can be handled upstream in libc++, because some > of these headers require knowledge of the implementation - > needs to know about 'struct __sFILE', for example. >=20 > - "import std" should solve this properly, but there are a lot of > implementation issues with this and it's not clear if/when it will > ever be supported; in the mean time, the existing standard headers > should behave correctly. >=20 > [0] https://www.eel.is/c++draft/cstdlib.syn#header:%3Ccstdlib%3E > [1] https://cgit.freebsd.org/src/tree/contrib/llvm-project/libcxx/include/= cstdlib Hi Lexi! That=E2=80=99s an interesting proposal! Given that this is a third-party library, I think it=E2=80=99s best to submi= t this proposal and patches up to the LLVM project (there are some folks in t= he FreeBSD project who are connected to LLVM, but arch is a wider distributi= on of folks and might not overlap with those individuals). The proposal woul= d be beneficial to multiple OSes=E2=80=94not just FreeBSD. Moreover, you mig= ht be able to convince others in the LLVM project to work with you to achiev= e the desired outcome sooner. Thank you again for sharing and starting this discussion! Cheers! -Enji From nobody Wed Jan 31 04:03:17 2024 X-Original-To: freebsd-arch@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 4TPpLH4yQ9z58Kjn for ; Wed, 31 Jan 2024 04:03:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPpLG09Qvz4T7c for ; Wed, 31 Jan 2024 04:03:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=W+vvpWsY; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706673811; bh=I2tSetqriSRsU0A4shNmGctLcuaS942seYehQYb6ZZc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=W+vvpWsY3nyqtPff+6MvJb8ThkLlczmkgpfZdt6bQAvJn+tkC3Oi9GCZsAX7n3u1zkwr3rBuW7JSU0/0otdylOO3qcWxp1heUJSD/04HtEVTm+7UKhtMo6kZfQbmif3hJ2nwswWQtYodKBt/sWFN1isnVSJHB/hKCVqOG9EPOXl8yXNJm3sOnDkopEpBcImv2NhkAYoVKj1YMjU4sDwevpOn+3b3E7fpMjpLMG/s4ZfmSiXiKuvc101j4Q1zMgkbu3rNjQIXRZwMPVIk9MUoc0GZgk0Dy9S5Eg6xxNbA/h/rWmnJqH/58NtsJ58l1KSz/zn2/209bzyH2ndJEtDPyg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706673811; bh=wMa1HUSjg3AeJa6d3/4Mf0MhBZVheSBDpN7I9Sg2zWe=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=rl5wvtV9GtOTFeNfkd9DbsJCWAbdsNZPETSD6A4y19NuWpKPDoK+kLxH/aToQc+S9cduq9nwCItFQTndAhUYRULk11QPXqlTMcERUcPlDJEUZIvQvL2Rp7hq2b/rb2YaVej+arT5Rnc/loP41d5VGtKGcOJunUplzmEpwcrfmAUh7kIIWlkZ6B50NkGQ7Ob2J53lLXXMMzOEXYqu/8MqMYWM5Z6hyqyig67LtNbig0ySZj72rcVbYxh0Gg+lrm6s6XSaeZrUZ5JmWIZ4YNngHctxyu8HuY3mT6P9T484byJee8BcFhkRSQmhPP7mawPKXP9gZxU4u4esA5quqzRZJg== X-YMail-OSG: l8hUhxEVM1kYZPXr7upEAA1OVI0zORSKS_pVmgVEtCxNcE5RcWFqG2hSMDd2ivg Zh.TGe3RJna0SrAt7vlQ9E5aIT97QaGFx2bwgkamQC7yJnPQO9sn1Dd2Fc03A_B8pZP5w.FTozMs LFALk9VhM7Qvjy2nNNsyOY8zJTWsOIRT1sKmDqwTSC7bQiRo7Wahsa22XNPLovMhfwGWfF5GpyAh lIeEXJhsE5BATOWguSQAYmsexYOeHH_G8bDT7Pq4V80VIkJ9VCdLEwT6lRgNQWk_4qHfLSbSiXQC QIii5yczFNs5N9WTDSVuY02BT3ypr2pTGAWcWlpageqqmWYoreaj_boxwqwgb93VHp4synJgg.EM 4Z2LvlrDq7j5tKlLbjS8d0vtLOpjeqlIO7149fXSRB3GwlynVeJ3regsOL1mmBY2PQ5OIyXvzBV7 P1.Xy2FEggiod75WZw7RGgDf4glDIg8ATRdKKX.WOZo7E0cHDgKVtbhjRe1dbsyaWKFik61VA4yS aGYLXiQReH2gNqurK_Lnk6s3UCjsMIXBa6tPk3AFywZ91Iq2MnQUauIJwf9uL1OCanCenL7hHG2U xohO7kmMdQuvaSo5KT8trY.OnfztqWpkPiUuSnL2EuXFCh_8L75lElJdr5j7B0q6rz9QUhLIbeXF R2utRhUnnkAaiJG5I1PqEHXpmPjmXVWBOq3HC9.VXjIgx6oIPhQFQ7QwggnqpbiPcTZ0xEv4Fa0b TRckHB7JXE6KJBwsqHoZkF1DeHyjQiRCoxO9iSUn1lksT1zHFNF7eETC37ezrXGbh.TZ3vEuHaHT 1NuEFHC8l9fmk7tdhxedwYZnThGC.Atvbxnpr3nnB2AT_Pm3UTdJbPUrq9Wj.VhO7Z0B4GuoUsQ2 0MRBXlnLewGQPCg_UTWCDCf8Lwj9I7pd6qbgLaLaW1Rf8uFI19hze2JcpKaXIM8UofYwVc8b9VK5 RlMxbkP.pOcNzf_RiTl3Pcw_japVZAlHI4wwOzHgo.kW7q34vs57IXNqmdLUet9g7KAQ5Kj_ck_G HIjWtzFfq6OkbLe5UOd5f8pBm1e.XjH8hG.BT9xoqdsENRmTNGkUcm.lt19K0J.Rv20XqnPQpSEb yYqczVvPODxW4sL4MC_nZNRO9mmP5dB8XD54fZZDHytkvVupLGd4AJyLmiN15RahpimPNigh3lyS DtBIJMOsLDfvZCIuC5KVSCmMN1nl96PVPu0nj.u.wXMMrgLpzRwhjerzFS00GkhKlyhyc1ZizZeH T_BvCao4q_9sNtpH4Bu3nNHt41gdlrkn4kT23WOKsbPQIZje.IlJNXZLrUzcl0V6KzMlZ2EQTw5H qLslRiOx92vLjyFtTlrTPiOSIAy24QmT1DpiEob70X0fqzyBiYKbrQgxBfJL0JKDY..S1Ki4mLcn uvbWoOuLSQOxYhoTmwvoeH9PxBlo9sdaqPW_CpgPgGXBb_VWIFQI7.pLoq5Csk.N6avIHn.5MZp_ Nhj5TNoP_3BeHx2618by963vBYm2bdHH6wvIawCxOWKuopmCZ.rXRb5oFVhXdvI5wycjn7mplJV_ TvoXOWzgR7TsBmRqg8kvNyFxPI6EfVzV4Jjs3wkgFFha_mwHd5KLtL.22dyklxYchaiedpOoyEjg bt9zWiMCcwAWYSpBpPBgkrkjXrjLGn0rHdVjZNzuD4mXmvfPPs_TEuV2crkMb1UJ3O3S28nGWxoJ w71AcnrKspcVJwEXTbj9KRzTD3P518Yb_nYgMOSfossaYx0JdpRQ.5uUinu_41u1LUPiD6.lElTB 7jAIOjmKV4k73IZVvFLKCuROlEyQz8LORjY0w.IcoznhjyWWgi7mt8hTV6GnWMnuCLek57DVhodV Qz_IFTY58h1yz3Y9Q0XnTVoRAU8Dcxqo3raQyV1kq.1brbDsjEg13FSdAQgwQtNy6RVOk931puhe uGS31sNfjNy3_F43aW3KEMZVBbOORFTTW.f7FNZ8I9oyxxGjRIwxL5DkVSuk.RWgQQ_hhRsFROZy QMUQvBcIOjPuEK6SU8DhboUT0csqQmtztWcStQP.JyqSmPHvxlQREq_RpPn30XC73XCSkE9WmYZc 9qdbbxzmBU2BIdFdxD7XcnzdAGEfRKYu2FzVjo4TYKCL1YVGFiD9G.FDz0zcVZkaZ3aY_ewbNxIM weijlWK9dUVrg7jcUa7VyK8.4OKQQzYWAoVtDUTdSbLq69z2EjmR5xjud0gUJBnzM1Hsi8wW4Sa0 HyTMC0eINY4SMdfU.eZC6W.HUZ0YDAhqfnQPQhLrebKPvUOKnFhSwgb4u2xP6VzQmJMJ1zLTUysM - X-Sonic-MF: X-Sonic-ID: 3ce1740a-bc32-4b93-a76e-3f5cabc07a04 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 31 Jan 2024 04:03:31 +0000 Received: by hermes--production-gq1-5c57879fdf-bmngc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 37666b961d2c1e85780587e9efb364b1; Wed, 31 Jan 2024 04:03:28 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: RE: improving C++ libc headers Message-Id: Date: Tue, 30 Jan 2024 20:03:17 -0800 To: lexi@le-fay.org, freebsd-arch X-Mailer: Apple Mail (2.3774.300.61.1.2) References: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.948]; MV_CASE(0.50)[]; SUBJECT_ENDS_SPACES(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from] X-Rspamd-Queue-Id: 4TPpLG09Qvz4T7c Lexi Winter wrote on Date: Tue, 30 Jan 2024 13:30:54 UTC : > i am considering working up a patch to improve C++ libc headers in = FreeBSD. >=20 > the problem with the current headers (which come from clang/libc++) is > that this code compiles: >=20 > ------ > #include > auto main() -> int { > exit(0); > } > ------ >=20 > this should be a compile-time error, because does not declare > ::exit[0]. however, it works because is implemented like > this: While I like the removal of header pollution, various C++ standard vintages have explicit wording that it is not an error for "C++ headers for C library facilities" (the for-C ones that are named) to be this way: QUOTE of an example: It is unspecified whether these names (. . .) are first declared in the global namespace scope and are then injected into namespace std by explicit using-declarations. END QUOTE > ------ > #include // exposes ::exit() >=20 > namespace std { > using ::exit; > // ... > } > ------ >=20 > i would like to replace this with an implementation that does this > instead: >=20 > ------ > namespace std { > extern "C" void exit(int); > // ... > } > ------ >=20 > i have done a very quick proof of concept for this and it does work; > there are some more complicated edge cases, but nothing that can't be > dealt with from what i can see. >=20 > but before i put any amount of significant effort into this, i'd like = to > check if this is something that is likely to be merged. >=20 > to address some potential objections: >=20 > - i don't believe this can be handled upstream in libc++, because some > of these headers require knowledge of the implementation - > needs to know about 'struct __sFILE', for example. >=20 > - "import std" should solve this properly, but there are a lot of > implementation issues with this and it's not clear if/when it will > ever be supported; in the mean time, the existing standard headers > should behave correctly. >=20 > [0] https://www.eel.is/c++draft/cstdlib.syn#header:%3Ccstdlib%3E > [1] = https://cgit.freebsd.org/src/tree/contrib/llvm-project/libcxx/include/cstd= lib =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 31 08:57:50 2024 X-Original-To: freebsd-arch@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 4TPwsr73KMz58nl7 for ; Wed, 31 Jan 2024 08:57:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPwsr6X0Xz45y8; Wed, 31 Jan 2024 08:57:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706691472; 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=e5GTy9bWLFSnpHQrm3E0e1YpiWIFG+qn/bbUKekvxrQ=; b=ihkBWq4BuD59bk1Xn6ZCzptTNVwo99vW5f47DdWPx7RbUz5GTOp3uHzbFfQx7BfjWtR3k4 48/c1E1zZvz+ybK7/ZVpMxA8qN+vMjfzlDuHT3rrjzbl3+EDBESU8BEc3mm417py3nEfM3 1MQl0OtHWgg+DSJFKCg1c+jo2bPGb4WuYQqHP6zfidw8G7tyjtBAu0u9p3llTtfW4jK21Y KvrEUKiTGH/g+P01Gj6k7qtWxKuclOfQhdJygKBwwvXmkdF84+9CnJeFiJXdClDOq2csfq NKZbW3cdLETKcjLYCdTDnCqLqqa+OVUL0R3Xyy1KSqyP+05FN6ntc0HmS5i05Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706691472; 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=e5GTy9bWLFSnpHQrm3E0e1YpiWIFG+qn/bbUKekvxrQ=; b=oOX64uCfbPf107ibA69uKyqgnCOfpiXaNqSEVNwcTC0qmk+W4/QaXT5s/N7GP9gD4dQtBu PazZDq2WJLSMpsYa46Mmo+6aud0u8unTPyTEsH0LMnlIuxnV16Wk5tvLwG1HrL1pyoNkKc QL69uEoDkTdNyQcM3yNmrqqueXw13yLZECKzyMp3c2S9Q/QuBrJNA/Dgq6S+lPNkvXuybA ibaKKHv/4Rn1l345U4z/S8wgUqyqhPqy5ooy6+fe/5swEcKRZS2lhmxo9Hst6sWYGxn8xL PfZu+/MHBzuA9ZutIe9/XPfiDsYRJvYFXj/GWgqpkRGNRA+aRIlA7E1VFbeQ4w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706691472; a=rsa-sha256; cv=none; b=SMcuc+qmzs8cw+X0+6+pKWal/RTd7GulnOG1yVMFlGWCHglprvk0nkOoBQS8ThrxrCltXd d6IWckWEYvdm2hCxTd0u8PM462XgnQ03sozDQFlTsgbjtRu/xa3PCHuA7KVGyF9Wx98YcT J4jgYGa1Gcb7P8KLPFzJMXnlL0q9jEQiVfdNrwinBmDmn3GW4VbLqZ/DeFsx/Gd2jj/8JZ ILZ7K6IMNWMiyXh652fKt/9+lMDLpE/71e+AfO5XmJb8vgl/hUJ0ZSn3qWluylduXVs9AC PfJRNQdc19MMISR3l5RLi7MRQIFeMQ5ML1TeOQUzG8S3+w5Fkmk2MxlKxJXuig== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TPwsr4sT0zYwh; Wed, 31 Jan 2024 08:57:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1617457032; Wed, 31 Jan 2024 09:57:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\)) Subject: Re: improving C++ libc headers From: Dimitry Andric In-Reply-To: Date: Wed, 31 Jan 2024 09:57:50 +0100 Cc: lexi@le-fay.org, freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <89B65722-4397-41D1-971A-7C79C8C4A5FE@FreeBSD.org> References: To: Mark Millard X-Mailer: Apple Mail (2.3731.700.6.1.1) On 31 Jan 2024, at 05:03, Mark Millard wrote: >=20 > Lexi Winter wrote on > Date: Tue, 30 Jan 2024 13:30:54 UTC : >=20 >> i am considering working up a patch to improve C++ libc headers in = FreeBSD. >>=20 >> the problem with the current headers (which come from clang/libc++) = is >> that this code compiles: >>=20 >> ------ >> #include >> auto main() -> int { >> exit(0); >> } >> ------ >>=20 >> this should be a compile-time error, because does not = declare >> ::exit[0]. however, it works because is implemented like >> this: >=20 > While I like the removal of header pollution, various > C++ standard vintages have explicit wording that it is > not an error for "C++ headers for C library facilities" > (the for-C ones that are named) to be this way: >=20 > QUOTE of an example: > It is unspecified whether these names (. . .) are first > declared in the global namespace scope and are then > injected into namespace std by explicit using-declarations. > END QUOTE Yeah, this is completely unrealistic, and will break a huge amount of programs for little gain. -Dimitry From nobody Wed Jan 31 14:31:38 2024 X-Original-To: freebsd-arch@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 4TQ4H11H1Lz58dN0 for ; Wed, 31 Jan 2024 14:31:41 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ4H10qscz4ssq; Wed, 31 Jan 2024 14:31:41 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706711501; 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=lJ9qIGKxtBRUvAKDPcsZ4m1g2D3/k4msJtaBK99W/9A=; b=M1xUKYyJqE34oK/c1UpHozLD9Zml2+5fLrdlI811NIwV5N3jq5DbpJAdCXdux2+TCcDINN T2dlyCldmjemgIvaZT7kyFACLfBywB6OaejlX7FxqTy3eddEUBLBReCGqdwhgFh/6hQrYg G4fPj0SfbUbQi8XvPv1lThbxZFhhN+uhORjW5sZZuV/LTJL9pwpdF//DJ/JAB7fGN/juim 5i/NHcIu8hmX4G1u+qAHLAl0pElUyGpzYUmz/uE3FtlRYl4tat56qiK5aJe+WGvQNhxDy7 BdPBGQOlFmrYVh69ds9w5At0N3D+OUs/XjdZ9Eg+ePMKHZvrkpIaCLS+J7rXJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706711501; 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=lJ9qIGKxtBRUvAKDPcsZ4m1g2D3/k4msJtaBK99W/9A=; b=V23i8vP7TBWGRR13+oHLRPmt4JwtVyGz4NCwueQmdvfBVOHmC+Ir19RCgxRhSOxH7yxEM+ 7rWtzPmKrn4hZHpTfxZt5ZvRhhAqVTWw2u49ZH/IyfxMDvb3asgmmeKV8YEH8syF1HC/3R 7CjAFp5oKQ+JDA3IuVO/BAnM4J3tJyUZjrF6D21JFY2EYLatDB5bISfblqS+fk+3aByHlF 8NdqD3/pHWk6jwwBgzdJyAijkfzBlIwkcY4mwTDwPGuU1NTFly+k76s9j7KGRrcCjzGAXb p0zDASo0BkP/nMKW0Y9xwRDDdbyMRUrjs/sKrVla87uMuL2iaBF7ReIU4bi8ng== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706711501; a=rsa-sha256; cv=none; b=mojDbcMS4XsLRM2mhoP30lKC7iVfkql8GzjXwOxKdKzKuB/n2i4fcxu89/C3kGd8+TAgF9 BnCXkqcmy+IN5qi7NLQeqlk3Wmk8g0EWxKWY3PDKcbJIafMa7q1GfSBu4lIePAqwwGuhbP hMqKQgbVtlgMlQwKhE+474gRaDgaLwuiozRLJfTqxySfvL3fNNrA3kpOmkD5VZWCBTiSuw 6aiufgKUfjwNGBGhwm988f/fSF2/rNOzg6qGlXaDWDipxC9lpd1KenHuW/a7g/tYvs/cQ9 Ja8lgDsh7Ot8Ex6aKwQeAcDSYu5bkItNE+m2Tjb+yxMheMmYR/HvhTv7l8Z0Lg== Received: from ltc.des.no (48.115.65.81.rev.sfr.net [81.65.115.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TQ4H06GZTzfbv; Wed, 31 Jan 2024 14:31:40 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id AE90B8E801; Wed, 31 Jan 2024 15:31:38 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Minsoo Choo Cc: "freebsd-arch@freebsd.org" Subject: Re: Importing Heimdal 7.8.0 In-Reply-To: (Minsoo Choo's message of "Sun, 28 Jan 2024 05:38:03 +0000") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 31 Jan 2024 15:31:38 +0100 Message-ID: <861q9x4lrp.fsf@ltc.des.no> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Minsoo Choo writes: > I'm currently working on importing the latest version of Heimdal, Please don't. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Thu Feb 1 01:19:48 2024 X-Original-To: freebsd-arch@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 4TQLg70g1Kz58hhm; Thu, 1 Feb 2024 01:20:03 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4TQLg63hrsz4R37; Thu, 1 Feb 2024 01:20:02 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 4111JmLD006020; Thu, 1 Feb 2024 03:19:51 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 4111JmLD006020 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 4111JmVY006019; Thu, 1 Feb 2024 03:19:48 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Thu, 1 Feb 2024 03:19:48 +0200 From: Konstantin Belousov To: Alan Somers Cc: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira , freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: aio_read2() and aio_write2() Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_SBL_A autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TQLg63hrsz4R37 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Wed, Jan 31, 2024 at 11:19:21AM -0700, Alan Somers wrote: > On Sun, Jan 14, 2024 at 12:07 PM Vinícius dos Santos Oliveira > wrote: > > > > Em dom., 14 de jan. de 2024 às 15:23, Alan Somers > > escreveu: > > > I think you're using the term "green threading" too broadly. Golang > > > uses green threads, but Rust does not. The difference is that in Rust > > > with async/await, the task-switching boundaries are explicit (the > > > .await syntax). So Rust uses explicit concurrency, not green > > > threading. I can't speak to the other languages you mention. > > > > Still, we might have async IO if the implementation permits. > > > > > You propose an extension that would essentially create asynchronous > > > (and racy) versions of read, write, readv, and writev . But what > > > about copy_file_range and fspacectl? Or for that matter all the > > > dozens of control-path syscalls like open, stat, chmod, and truncate? > > > > They would block the thread, obviously. Look, I've been playing with > > async IO for most of my career. I'm not asking for exoteric APIs. I > > just want a non-blocking version for read(). What's so hard about > > that? From what I understand from FreeBSD source code, I can already > > "unofficially" do that (offset is ignored if the concrete type is not > > a real file). > > Oh, are you not actually concerned about real files? aio_read and > aio_write already have special handling for sockets. > > > > > Very very few OSes actually implement async versions for anything > > beyond the typical read()/write(). Even open() could block. For > > anything beyond read()/write(), you just create a thread and live with > > that. From a userspace perspective, it's expected that filesystem > > operations such as file-move, directory-listing, etc will block the > > thread. It's already expected. However you don't expect that for the > > basic read()/write(). > > > > Again: Linux and Windows already allow that and it works fine on them. > > > > And again: I ask why FreeBSD is special here. I've been answering your > > questions, but you've been avoiding my question every time. Why is > > FreeBSD special here? Linux and Windows work just fine with this > > design. Why suddenly does it become special for FreeBSD? It's the very > > same application. > > The only sense in which FreeBSD is "special" is that we're better at > finding the best solutions, rather than the quickest and hackiest. > That's why we have kqueue instead of epoll, and ifconfig instead of > ifconfig/iwconfig/wpa_supplicant/ip . > > > > > > This flag that you propose is not a panacea that will eliminate all > > > blocking file operations. There will still be a need for things that > > > block. Rust (via the Tokio library) still uses a thread pool for such > > > things. It even uses the thread pool for the equivalent of read() and > > > write() (but not pread and pwrite). > > > > Nothing new here. I use thread pools to perform DNS queries. I allow > > my user to create threads to perform blocking filesystem operations > > (move, directory listing, etc). I know what I'm asking for: a read() > > that won't block. I'm not asking for a competitor to io_uring. I'm > > just asking for a read() that will never block my thread. > > > > > My point is that if you want fully asynchronous file I/O that never > > > blocks you can't achieve that by adding one additional flag to POSIX > > > AIO. > > > > It's just a read() that won't block the thread. Easy. > > > > Do you have concrete points for the design? What does it need to > > change in the design so it becomes acceptable to you? What are the > > criterias? If the implementation fulfills all these points, will it be > > acceptable for you? > > I would like to see a design that: > * Is extensible to most file system and networking syscalls, even if > it doesn't include them right now. At a minimum, it should be able to > include fspacectl, copy_file_range, truncate, and posix_fallocate. > Probably open too. > * Is reviewed by kib and Thomas Munro. > * Has completion notification delivered by kqueue. > * Is race-resistant. I think that the request was much more modest. It is only about having the https://reviews.freebsd.org/D43448 committed. And indeed I do not see a reason to block the review from landing. I added arch@ to get this discussion more visibility. > > > > > > Instead, all operations would > > > either specify the offset (as with pwrite, pread) or operate only at > > > EoF as if O_APPEND were used. > > > > I strongly disagree here. Async APIs should just achieve the same > > semantics one *already* has when it creates threads and performs > > blocking calls. Do *not* create new semantics. The initial patch > > follows this principle. Your proposal does not. > > Shared state between asynchronous tasks is fundamentally racy if > unsynchronized. And if synchronized, it fundamentally imposes a > performance cost. I even recall reading a paper demonstrating that > the need to assign file descriptors sequentially necessarily created > shared state between threads. The authors were able to improve the > performance of open() by assign file descriptors using some kind of > thread-local data structure instead, and that way open() millions of > files per second. That's what a good asynchronous API looks like: > it's resistant to races without requiring extra synchronization. > > > > > > > -- > > Vinícius dos Santos Oliveira > > https://vinipsmaker.github.io/ From nobody Sat Feb 3 15:59:46 2024 X-Original-To: freebsd-arch@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 4TRy5T35Wvz59dDd for ; Sat, 3 Feb 2024 15:59:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRy5S5rpQz4LRd for ; Sat, 3 Feb 2024 15:59:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-55fc7f63639so3512636a12.1 for ; Sat, 03 Feb 2024 07:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706975995; x=1707580795; 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=IDm8kgMJP5K+07fGbCkSfU64OY7vUMi4U6UBLXWrUFM=; b=k+9xfV7F7cTEsY7Nl9tgqr6q6OHsuq1H7SJJJA7zZdhZOe0oOYUKK4qA2Boi1XYS1M G36h9U4PLJX1M3beELIsOMo3BnTB6cBNuKvXAuIvXQA6SZbugPAz5DSP9IV8DZIjQc2i IcpkkrPqhrBNt+FgtpoXI0kfv63AkOmmOocCuJTdqoeAqJOnN/y+XCVHHjSJyhlSOM2h EDFS0ce+bdOWZcaZlGXa8rRcshSuW+rS3EQOl5VVrqG6SWCL6l+xF3pKB2nQxzORxr2X Dvs4NNmkchUhqDzysowB3od/FzY/0AN+tNbwlK0qSKmIKglD6qw1RpDIsAShOt1Fd7Ue qTXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706975995; x=1707580795; 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=IDm8kgMJP5K+07fGbCkSfU64OY7vUMi4U6UBLXWrUFM=; b=ZCKxamWDgLz90ldRJlJdcA7vvaVSaRbCPKck7imdF0PA+5QjvetktU+FX+XFqsTTqc n9V2XQZlS1XrNZzNhecFdpJzRWjRe52qtfm53AepA3OtdZhAxvDEE/0lhjk5mPK5fJ06 7EV7ZHV0mFpMuvXKibodtuu0EYNp6jrWUUgDTpQzdsDECWjHcMMk30SzX83SlUZbeNfe TIxorrAC90hoGnqi7BiaQE8NgDezAWjNoXB9izH3SrDQp/mBZKd5aEebJhk68Uc2YAak q/hZ3JX4yGirdEkE5Uu2d4lOvqaw3hjWvnWgu2OsZzzz/cwLDsY1KtfGOdoQ9ol4hong bVUQ== X-Forwarded-Encrypted: i=0; AJvYcCWn7O9T5DB0UqOqW03tnihhpoe3hnz5EJWz8vvbLJHmSZcy8QYHkNfxy4JyioNNgqnNP4sPUyoFXTcZhrgHfi/zBqPIBRSLnwM= X-Gm-Message-State: AOJu0YxADL5vRG6jZXYxRl7t00xzbxlvxiG4x8CPapfppCxwGQY6i8ET CLkl81u4x/sVRTcZVj/T1JOK/8xzGqZUPoL73j+tmE4x5Lr5e8V1N36qjzOF/femKCaT3o86AgC rqJSi3pevQ6Rw3yTR9N7aJR1fMP6mU4zZWq8WMQ== X-Google-Smtp-Source: AGHT+IFl04e6lv3s+hOL/4dTMeLPuHrWjg7g3yZYN48pCs5jadB9iB05AT9mA8S/ktJxHFTaNl+f2fIHGpJ9oy5f9J8= X-Received: by 2002:aa7:d6cc:0:b0:55f:fb25:47d9 with SMTP id x12-20020aa7d6cc000000b0055ffb2547d9mr1907134edr.8.1706975994657; Sat, 03 Feb 2024 07:59:54 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202402030136.4131aQIM010980@gitrepo.freebsd.org> <70o6oo0s-r8nn-7r92-5s6r-6so586rpo1o1@SerrOFQ.bet> In-Reply-To: <70o6oo0s-r8nn-7r92-5s6r-6so586rpo1o1@SerrOFQ.bet> From: Warner Losh Date: Sat, 3 Feb 2024 08:59:46 -0700 Message-ID: Subject: Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL To: "Bjoern A. Zeeb" Cc: Gleb Smirnoff , =?UTF-8?Q?Mina_Gali=C4=87?= , Warner Losh , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000cd4fa806107c5182" X-Rspamd-Queue-Id: 4TRy5S5rpQz4LRd X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000cd4fa806107c5182 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [[ moved this to arch@ ]] On Sat, Feb 3, 2024 at 6:44=E2=80=AFAM Bjoern A. Zeeb wrot= e: > On Fri, 2 Feb 2024, Gleb Smirnoff wrote: > > To be fair, it totally disagree with this change. > > For different reasons I second that. > VIMAGE definitively does not belong in MINMAL for comfort. > I too had reservations about this change when it was submitted. Allow me to explain my reasoning. Years ago I did a study on the Unix kernel size over time. It was doubling every 3 years or so going back to 1970. I'll skip all the details, but this was an unsustainable trend. So I embarked on the project to reduce GENERIC to its core parts, and load the rest. This idea dated back to when I committed devd to the tree, though it was almost an afterthought with the nomatch events there. I wrote devmatch and decorated all the PNP tables in the tree (with much help) so that we could load all the drivers on demand automatically. As part of this work I created the MINIMAL kernel. A name I now regret, but the theory of the kernel was "everything you need to boot, but everything else will be dynamically loaded". There are (still?) some things in it that could be loaded, like serial drivers, because we can't (couldn't? I haven't rechecked in years) have the console be in a kld, it had to be in the base kernel. ufs was in this list for a while, but it moved to a module and removed from MINIMAL some time ago. Manu even did some good work in the boot loader to parse the linker.hints file so that fdt drivers could be loaded there (we still need PCI and ACPI). But common root filesystem devices were retained. So this kernel has always had the charter of the GENERIC minus everything you could load after mountroot early in boot, with an eye towards pushing more out when the boot loader grew better pci support and could automatically load cam.ko. In time, I'd hoped the default kernel would become MINIMAL and nobody (or almost nobody) would notice. So when this pull request came in, my initial reaction was 'yuck, why do you need it?' I too thought it was too much for MINIMAL. However, VIMAGE falls under the 'can't load it later' exception. And it's not exactly a trivial piece of infrastructure that we can just ignore. It provides useful functionality when paired with jails. It was also in GENERIC. These reasons coupled together let the idea grow on me. It ticked all my boxes: Can it be loaded? no. Is it widely used? yes. Will I need it if I wanted to make MINIMAL the new GENERIC? yes. Based on that, I approved and committed the pull request. It was well within the remit of MINIMAL based on the historic creation and change criteria I've tried to apply to it. Now, I totally get the desire to have a minimal kernel that doesn't have any baggage in it. I totally support that notion. Maybe we need another kernel in the tree to do that. Maybe it should be called MINIMAL since that name makes sense and one of two renamings happen: Either we rename GENERIC to GENERIC-STATIC and MINIMAL to GENERIC, or we rename MINIMAL to MODULAR and have it (eventually) become the new default. Or we need to create a new name that connotes the same things that MINIMAL seems to inspire in people (since the name evokes notions not quite compatible with my original charter for it). I have nothing on good names, though. All the ones I thought of have other issues, though maybe staking out a charter for what's in this config (the absolute smallest that will boot? Or are there a few additional things that are needed). One problem, as noted on irc, is that we need to have slightly better partitioning of the config files, so that we have a MI std.generic and std.minimal that the MD versions of these kernels can pull in and flavor. That's possible, with effort, with config(8). But it isn't super pleasant. I think, as a separate project, we should consider modernizing the config language to properly account for the subtle differences between 'requires' and 'depends-on'. The former concept is 'bring in this dependency when this item is included' (we don't have this) vs the latter 'don't include this item if the dependency is absent (we have this). But that's a whole other discussion that's happened a few times, but never produced any useful results. Having better tools here might be helpful, but it's the new sysinstall in many ways. I also love the idea of having a few more kernels that test unusual combinations. That's also a good goal. But MINIMAL's charter isn't to fulfill that goal. How we balance that with increased 'universe' times is also something that requires some careful thought. We've just recently managed to get the number of 32-bit arm kernels under control by making a generic there and also marking some kernels as not to be built in universe (they are for the convenience of our users, not for CI driven testing). Warner --000000000000cd4fa806107c5182 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

[[ moved this to arch@ ]]
On Sat,= Feb 3, 2024 at 6:44=E2=80=AFAM Bjoern A. Zeeb <bz@freebsd.org> wrote:
On Fri, 2 Feb 2024, Gleb Smirnoff wrote:
> To be fair, it totally disagree with this change.

For different reasons I second that.
VIMAGE definitively does not belong in MINMAL for comfort.
=

I too had reservations about this change when it was su= bmitted. Allow me to explain my reasoning.

Years a= go I did a study on the Unix kernel size over time. It was doubling every 3= years or so going back to 1970. I'll skip all the details, but this wa= s an unsustainable trend.

So I embarked on the pro= ject to reduce GENERIC to its core parts, and load the rest. This idea date= d back to when I committed devd to the tree, though it was almost an aftert= hought with the nomatch events there. I wrote devmatch and decorated all th= e PNP tables in the tree (with much help) so that we could load all the dri= vers on demand automatically. As part of this work I created the MINIMAL ke= rnel. A name I now regret, but the theory of the kernel was "everythin= g you need to boot, but everything else will be dynamically loaded". T= here are (still?) some things in it that could be loaded, like serial drive= rs, because we can't (couldn't? I haven't rechecked in years) h= ave the console be=C2=A0 in a kld, it had to be in the base kernel. ufs was= in this list for a while, but it moved to a module and removed from MINIMA= L some time ago. Manu even did some good work in the boot loader to parse t= he linker.hints file so that fdt drivers could be loaded there (we still ne= ed PCI and ACPI). But common root filesystem devices were retained. So this= kernel has always had the charter of the GENERIC minus everything you coul= d load after mountroot early in boot, with an eye towards pushing more out = when the boot loader grew better pci support and could automatically load c= am.ko. In time, I'd hoped the default kernel would become MINIMAL and n= obody (or almost nobody) would notice.

So when= this pull request came in, my initial reaction was 'yuck, why do you n= eed it?' I too thought it was too much for MINIMAL. However, VIMAGE fal= ls under the 'can't load it later' exception. And it's not = exactly a trivial piece of infrastructure that we can just ignore. It provi= des useful functionality when paired with jails. It was also in GENERIC. Th= ese reasons coupled together let the idea grow on me. It ticked all my boxe= s: Can it be loaded? no. Is it widely used? yes. Will I need it if I wanted= to make MINIMAL the new GENERIC? yes. Based on that, I approved and commit= ted the pull request. It was well within the remit of MINIMAL based on the = historic creation and change criteria I've tried to apply to it.
<= div>
Now, I totally get the desire to have a minimal kernel t= hat doesn't have any baggage in it. I totally support that notion. Mayb= e we need another kernel in the tree to do that. Maybe it should be called = MINIMAL since that name makes sense and one of two renamings happen: Either= we rename GENERIC to GENERIC-STATIC and MINIMAL to GENERIC, or we rename M= INIMAL to MODULAR and have it (eventually) become the new default. Or we ne= ed to create a new name that connotes the same things that MINIMAL seems to= inspire in people (since the name evokes notions not quite compatible with= my original charter for it). I have nothing on good names, though. All the= ones I thought of have other issues, though maybe staking out a charter fo= r what's in this config (the absolute smallest that will boot? Or are t= here a few additional things that are needed).

One problem, as noted on irc, is that we need to have slightly better part= itioning of the config files, so that we have a MI std.generic and std.mini= mal that the MD versions of these kernels can pull in and flavor. That'= s possible, with effort, with config(8). But it isn't super pleasant. I= think, as a separate project, we should consider modernizing the config la= nguage to properly account for the subtle differences between 'requires= ' and 'depends-on'. The former concept is 'bring in this de= pendency when this item is included' (we don't have this) vs the la= tter 'don't include this item if the dependency is absent (we have = this). But that's a whole other discussion that's happened a few ti= mes, but never produced any useful results. Having better tools here might = be helpful, but it's the new sysinstall in many ways.
I also love the idea of having a few more kernels that test unu= sual combinations. That's also a good goal. But MINIMAL's charter i= sn't to fulfill that goal. How we balance that with increased 'univ= erse' times is also something that requires some careful thought. We= 9;ve just recently managed to get the number of 32-bit arm kernels under co= ntrol by making a generic there and also marking some kernels as not to be = built in universe (they are for the convenience of our users, not for CI dr= iven testing).

Warner
--000000000000cd4fa806107c5182-- From nobody Sat Feb 3 17:35:18 2024 X-Original-To: freebsd-arch@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 4TS0Cn1P9wz59mW0 for ; Sat, 3 Feb 2024 17:35:33 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS0Cm0Cxxz4dyZ for ; Sat, 3 Feb 2024 17:35:31 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1d94b222a3aso25736555ad.2 for ; Sat, 03 Feb 2024 09:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1706981730; x=1707586530; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=8LoWfGnikkMdtmqOLEXyw5/SwW8pFdXjL24iXIWjq2E=; b=kAS0K24qqo/fmNTqGgfY/vMigKGUijLvilqw6skXTIMhN47KbNEEoIIe33/ePE9UbE iijZSTSFZ51Ow2ONxvvwQD7qFH8K1+91pA9gmJiZu3pbZOI5hPrK8th8PEEAE/ygmCVI YOok17UFrZNfWddrAypPFsASf+AbPVSau+oBua+BtIXmjaPO4oo3n70EvM6OX2QprNKV Rz4u/5tPKp8G3R9oyw8t7to9tJdLwzp4xGftItIdkZyTqf8IOmFI/Lwj8RTX6Rc2hqWC imTHQD/DuPhq0UqtSPJdGWBNMrbK16u4+/AzcHinptHNV2te75eH/IrziSkUfqSRgvoh mHRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706981730; x=1707586530; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8LoWfGnikkMdtmqOLEXyw5/SwW8pFdXjL24iXIWjq2E=; b=w3dfjDpCyxJO4GFPLfb5bGdPIDkusSxI+A2AEgJZGuZDnnTDp302wPtpQggi/6orwc Q2i1wpcZddS2b4aw/LbQRkbgUGC9Ew3w2eAP9Fol0JbXq5mNyDS1d127zyLaJxuEm3ku o8cd4R6tbNQp8R3Vm4GCe1PBLF7AKaAFfiMpCQ0S8lJMR1WuhrZrJRsSGzbmjaudSryl JjH6lL2rMskwSRlXoxAjHUUYDZHCuk5/3sxve6HQzYACN6jE/qVRZUfnUb9fKPr/8LLS usmgN0tCx+EzF686ruF2odGdX2fhzpxLg97bV3PJ+2qzgI56xb/4CSHefGtqmjReKOuU XLCg== X-Gm-Message-State: AOJu0Yzu8p93dECynBfx+iRE5qF3ak3K//edUR0oPR64cA0XQz4vJrmC UjHLQhmIE7ngB3HYrD16HzVjf4wxCIw3mJe8sG+S+tdX/mg3CpGMmdf1ytK1tznevD6qeceRY5Q = X-Google-Smtp-Source: AGHT+IFuvimh8QO2IULNGzdaORyx4EfGkxd0g/L6XGBKCtwnH9dznrtZnWKsqcqUcbQ2vET88c75ZA== X-Received: by 2002:a17:902:db11:b0:1d7:8541:f914 with SMTP id m17-20020a170902db1100b001d78541f914mr7679102plx.26.1706981730410; Sat, 03 Feb 2024 09:35:30 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVtjwFElQZTt3G4SvjhHciHxjRoaNrpDFhE09I/dBNx0iZlBt9x6zSR5OsOMXTS4XVWNfokFdxgXBaVEL9Nd5tLS6/B2H6UeGwhCtPHCUQzS++DlNWuouGqGJfp2v9y28wktK9IDI4aKLjpsV8SUBJ7EpEIx1b2vh4KvwyDi5UsaMEVjOuTz+Z8dLyl3EOwKx4WeUSWGaXz56HYvnaCmKFOv6Tu90frFTu7DNHGLqNcxSb9lM63PEE5cW/xFuVKSSKW7N39EYCtGNTexrxbwTjagaN+cV1ToqKfb1DmKpwZVQ== Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id kk3-20020a170903070300b001d7492d9890sm3489922plb.146.2024.02.03.09.35.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Feb 2024 09:35:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Bakul Shah List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL Date: Sat, 3 Feb 2024 09:35:18 -0800 Message-Id: <78927545-B1BB-42B5-8EF4-B904E7D180CD@iitbombay.org> References: Cc: "Bjoern A. Zeeb" , Gleb Smirnoff , =?utf-8?Q?Mina_Gali=C4=87?= , Warner Losh , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, freebsd-arch@freebsd.org In-Reply-To: To: Warner Losh X-Mailer: iPad Mail (20H307) X-Rspamd-Queue-Id: 4TS0Cm0Cxxz4dyZ 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] > On Feb 3, 2024, at 8:00 AM, Warner Losh wrote: >=20 > Now, I totally get the desire to have a minimal kernel that doesn't have a= ny baggage in it. I totally support that notion. Maybe we need another kerne= l in the tree to do that. Maybe it should be called MINIMAL since that name m= akes sense and one of two renamings happen: Either we rename GENERIC to GENE= RIC-STATIC and MINIMAL to GENERIC, or we rename MINIMAL to MODULAR and have i= t (eventually) become the new default. Suggestion for a new name: BASE, on which further modules may be added.= From nobody Sat Feb 3 17:45:00 2024 X-Original-To: freebsd-arch@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 4TS0Qj3xZQz59n4H for ; Sat, 3 Feb 2024 17:45:01 +0000 (UTC) (envelope-from pstef@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS0Qj3Kxcz4fyn; Sat, 3 Feb 2024 17:45:01 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706982301; 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=b5vBUtRftSfYTPsa04jFqT4nZW77BdPyNLsf+Vy/a5Q=; b=wnm7hxvoG+AImThRB1XGCitZvoDnoW8GPd/SOTBOmwKEEe+J6AbiyAucrG0tBCiYmKG3KD q+/wx6Y1DaeytG6ys66LJhsaQ9Fvg8SqPi2cylOb5yvDExSMpT+GoSRL1iDTX90iy0qlsQ L7sMKzvPGcg2LJg+vqAHCKs14TTCpLrRYPMJXwtZXolDv61F0QhstIj71qZDp+rWlMrlo3 iugWhmt9RGLc5SGjUaQXC2bPKQjp+3TJpC+2IJCQ7bbR7/rIINwHl2M5B+Dvg3PwtFEkAv D30qmaUaf1WNXG8nvs2HTU6DAgmQFw945MJRx/bBwHncDr85OTHChTbiibkx6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706982301; 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=b5vBUtRftSfYTPsa04jFqT4nZW77BdPyNLsf+Vy/a5Q=; b=F7mTESD13Sq/6RriamsfGUkPeR01jOyO0BZEsRcAgi9pfLPs3CJONpD43M0qq4NnZdO3b/ 8s94uXIsSlyYgzIdlqVqk+hYkMV1/S4+M3j+6fQFEgaaMyeSvbbKVQD69Z2GW74eywq08X xWzreJEYu9C197G605JJiKX8r8W11wXIOyJmuBZnR7NunSeLf8hDvWKkOaODFKRR291ny1 ZZiKwr+aPoWARUQ06TLS8rirTfPP3uUoRxf6J3OKm1pkelLLvUsnPGJXTTfAqr++upFa6m Qhj9FUAkxmNoZgzEodO8t5eFQDZGtDh7Xu1tPjcAfR+N0gqTQBA1UGxmM3/z6w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706982301; a=rsa-sha256; cv=none; b=nR7NdyKW2JkgMBucU0ntjAtaTgJWM/gNttcCfLac9tuRvBNZWrwtt6A687dReQw1mT0uJ1 YsxdQJyrs7DYHWwf/eOCFYl9INQJZ3055ZeO32FCmrWnoTCm+UgXPdqzRf6oGPP5Elkiwr FpM3dnGyUFzvyUpvzRtlTgJAKI0ns3N0uyK0Mra5B/MOrxgOroLey10KB4wMoRgPj3yzi7 bcttsJ55r4YyNTB4rWQkLVj3J9dSfnxHHknjuVGoTuaK3ZFBADvcQj5uex5tcK+YkRfHNh CkJxNwq6IU+CSet652A7VwdbXHqiswHkTBAOl1NFMyIUClrl7nPNi8B3AsK0/Q== Received: by freefall.freebsd.org (Postfix, from userid 1403) id 2B77475B9; Sat, 3 Feb 2024 17:45:01 +0000 (UTC) Date: Sat, 3 Feb 2024 18:45:00 +0100 From: "Piotr P. Stefaniak" To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Cc: Minsoo Choo , "freebsd-arch@freebsd.org" Subject: Re: Importing Heimdal 7.8.0 Message-ID: References: <861q9x4lrp.fsf@ltc.des.no> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <861q9x4lrp.fsf@ltc.des.no> On 2024-01-31 15:31:38, Dag-Erling Smørgrav wrote: >Minsoo Choo writes: >> I'm currently working on importing the latest version of Heimdal, > >Please don't. why Piotr From nobody Sat Feb 3 17:58:49 2024 X-Original-To: freebsd-arch@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 4TS0kj3BMsz585LQ; Sat, 3 Feb 2024 17:58:53 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS0kj2f1Yz4hK2; Sat, 3 Feb 2024 17:58:53 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706983133; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MhHQfEBekOsatIVJQaLOZYMv5dw+CEZVj8oaUXwf37s=; b=PRUoMSxMy8mT8iDFrj51XoGDbaj/B8Y3avG6KCrE0E1PMaqFHz9IVloXJIFLhQR+YysiXG iQDU1XKXwFqiIPK3NkNrMbYcwVsukfT+JAJFyqqDLBIcptBcUrCziWqIfQYIw0QGkfOBTW ieLLnk50zEOsxLlvaJlDhtcughPumC5FbftE3L45s+GFj6Av2SwL7Tk1ltYQOstLd9wN2T 97zLp0jeN1oC37Oq6h3R4d7/U7ttDPOE+xLBsa4RdnkZ7+Y+2VcwFzw4GCleHSVpj/MsPz vInbaPZLi/2EiwdXpNIWsvqbfxSVlWDWdKezY8hgUUAOq11D40MrOvInY8mxBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706983133; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MhHQfEBekOsatIVJQaLOZYMv5dw+CEZVj8oaUXwf37s=; b=MnNSt0EBjcRvq9I4aiz8Rx2xC2ks7DTv48O5sJ+R9SfRIf4XjDtSOIlG8ZUAh2R6iecurF YJFxZN8G2NIT7xWSphPu4zpL17EMaZ5ekIdsy+1SWZXUryYmM21grZZ5wnQ7hGNvvZv7bO VwH5jg0Z9xne9qUyyAeN4EbLsUyWr1sir3UkMd8pM2mkVIBzmAdstrcvd6C11gV81Ay44s +vmEmmI9FaI+peT3dB6kEGENxTt/9Rrh7RbylrXT3zGBKippDdVsgID++QLo38brKV3ACB VtQPEv5AVSOleslxCJ88o/ky50BWDZ4VcQFkn1Y8rS9MVTEj6opKZbKGdAv0kQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706983133; a=rsa-sha256; cv=none; b=l+kVDYIAfnDQ0csEqgrwpu7d1hQEHbBxbJW4g3o90DWpil5BvtZsrd9DKsifKFQCmvrD9C 7OXJRddgxgtNEtxX8pGEFMLLhtTn4q2N/lRbOwzqggiwdXm4lBrF4EgkQstBidW8Mlp+VZ qAUmHrOB2jTwF13HuQYTI9ma473NT0u/h/WT5XcZ7wc8NRmd8d4GvSMlgLtyeGE+oPnz6E 2W04Eh94OFAKHVqtfolhkOJVpNb5AjKHgwA2+6BfRWVacbJAPDBAW+9LVRkinLOI2OLHjh GgU7RwwEyKA8nd1cqm43/tFG5SdpNIbeGVIBecZA/XeKRP+4mIqVRIYlGqlFTA== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TS0kh1Htnz1NQT; Sat, 3 Feb 2024 17:58:52 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Sat, 3 Feb 2024 09:58:49 -0800 From: Gleb Smirnoff To: Warner Losh Cc: "Bjoern A. Zeeb" , Mina =?utf-8?B?R2FsacSH?= , Warner Losh , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, "freebsd-arch@freebsd.org" Subject: Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL Message-ID: References: <202402030136.4131aQIM010980@gitrepo.freebsd.org> <70o6oo0s-r8nn-7r92-5s6r-6so586rpo1o1@SerrOFQ.bet> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Feb 03, 2024 at 08:59:46AM -0700, Warner Losh wrote: W> Now, I totally get the desire to have a minimal kernel that doesn't have W> any baggage in it. I totally support that notion. Maybe we need another W> kernel in the tree to do that. Maybe it should be called MINIMAL since that W> name makes sense and one of two renamings happen: Either we rename GENERIC W> to GENERIC-STATIC and MINIMAL to GENERIC, or we rename MINIMAL to MODULAR W> and have it (eventually) become the new default. Or we need to create a new W> name that connotes the same things that MINIMAL seems to inspire in people W> (since the name evokes notions not quite compatible with my original W> charter for it). I have nothing on good names, though. All the ones I W> thought of have other issues, though maybe staking out a charter for what's W> in this config (the absolute smallest that will boot? Or are there a few W> additional things that are needed). I'd be happy with either plan: 1) GENERIC -> GENERIC-STATIC or STATIC, MINIMAL -> GENERIC, create new MINIMAL 2) MINIMAL -> MODULAR, create new MINIMAL We just need at least one supported working kernel without VIMAGE (and probably other useful stuff, that is not useful to everyone). -- Gleb Smirnoff From nobody Sat Feb 3 18:24:09 2024 X-Original-To: freebsd-arch@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 4TS1J71X9hz58867 for ; Sat, 3 Feb 2024 18:24:23 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS1J66fdcz4ny7; Sat, 3 Feb 2024 18:24:22 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1d7354ba334so27520245ad.1; Sat, 03 Feb 2024 10:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706984660; x=1707589460; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=v8hYUWx+Qw4l90ffpTuU5ZbbwUxSD1mrvVDIKTTtcD4=; b=cMReKr3WVrOXwZKnbDnV1ORDBtKsHRm6YutvzAmpLIhdncJNoHNoJ+H0mlwC3sJyvq hoA7JdfroaoKbod1Y8h0w1iS6Jdacm0FfB9fBlni5r4ARZS2ycwAyqSwBDV3UL7bS/VM TLu5kWG2WssC7u2kFCVE7C9eomJszw9Nj23c6dMhqX1Bnt83PfSPslhpksewfnCo82WJ eugwaS9vP4hL2pR1GbyBAL6J7KGfnYsk4VRAkmV6xB8xhRiAFuZQLnDeOtla2VTbM3RA lpGRbgAFZt99M2LvzbkRuUrTxTw+RD4XwWOm8q7qfMiD8Kcsl3qNz5c9fdHLWFR47pH5 avxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706984660; x=1707589460; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=v8hYUWx+Qw4l90ffpTuU5ZbbwUxSD1mrvVDIKTTtcD4=; b=hxPl7UQEK242d+1BoYrwY2UVNzaS9wX9gidn7oraoRp35226iAi5EXlfMF/MqWtYBo nULTwdBZUTlZYwIA8ehndoqi4R+7XRhhjqHDgWv22Qfqgr20bIEJKSEnaIGXscASu6tS G/x5O+pJs5GMSGrCspJN7H1iKY+qtMXgDwDehy1+f7kdZoR6v3fx1GrnPxcXLe5+Z5lw 7AZkNAQlq60R5Q/A4U+vZlapJ27bBseILZJKANtFidEs6DTQrRiI3wxjJB7mfDedc9LO UZA0naR4xGm/48uCV9rUZOitQMxjgsqPvR6mSJ+GrInXx5wHjziPceJwxeXAaObYYx/e 3/eQ== X-Gm-Message-State: AOJu0YymnMEXb+nvJip5eS7dGjatC2dsl92N4K7rTJknBkbrOvke8cJP Ry/oy6+YGiJwYaIR2d1ov/WYBXbutLM5Y6xpfbe4Nht+Znop1eyIPleFvLXw X-Google-Smtp-Source: AGHT+IEEjqXxnALNWcF7p0paQoFNjAa6phYxZDC2lz3aawpAqbPD3GCeLBzsV8p0ymHL4Q/gR5M/zw== X-Received: by 2002:a17:903:298f:b0:1d6:ff27:7627 with SMTP id lm15-20020a170903298f00b001d6ff277627mr16140266plb.50.1706984660473; Sat, 03 Feb 2024 10:24:20 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVe2XxtuFlLyBgPzhrMkDDSXu2mWFjD1AlB68b/J8vVDYUlmyhxNd9qlGr6Mbg7xQCrV1owi2gg9xzwxhp1XV6tV0iEcL0sj3kedbbwiOuevjsosEbpxVmxiNyG3Ts4sGsR7A== Received: from smtpclient.apple (c-73-109-44-219.hsd1.wa.comcast.net. [73.109.44.219]) by smtp.gmail.com with ESMTPSA id z7-20020a630a47000000b005cfbdf71baasm3966404pgk.47.2024.02.03.10.24.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Feb 2024 10:24:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Enji Cooper List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Importing Heimdal 7.8.0 Date: Sat, 3 Feb 2024 10:24:09 -0800 Message-Id: <7B302C8A-8A56-4840-B8D1-A01A3F9D765C@gmail.com> References: Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Minsoo Choo , freebsd-arch@freebsd.org In-Reply-To: To: "Piotr P. Stefaniak" X-Mailer: iPhone Mail (21C66) X-Rspamd-Queue-Id: 4TS1J66fdcz4ny7 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] > On Feb 3, 2024, at 09:45, Piotr P. Stefaniak wrote: >=20 > =EF=BB=BFOn 2024-01-31 15:31:38, Dag-Erling Sm=C3=B8rgrav wrote: >> Minsoo Choo writes: >>> I'm currently working on importing the latest version of Heimdal, >>=20 >> Please don't. >=20 > why Cy is importing MIT kerberos. MIT is (in many cases) the defacto flavor of k= erberos. Cheers, -Enji= From nobody Sat Feb 3 19:06:57 2024 X-Original-To: freebsd-arch@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 4TS2FL4Zkkz58Ccd; Sat, 3 Feb 2024 19:07:02 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS2FL2ZyBz3wpF; Sat, 3 Feb 2024 19:07:02 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706987222; 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=xXuldtK0vUo7s87bny1EMn0QALh6iGT8dhhSy+LPex8=; b=ynT0fWDrVlVuk31yKUfZuFGsWygtL8n8+yR5N/aiHyhzwCH5MnBlz5Qh5NzEWfv1qSNfQt rYakg1HjZhz1dzTkjL8LV3lu6Jd/JngkdR+tB9DjZUNPvnuo/uscSnQvA3QYBcsNsLgmy9 9hJ/aQiipZ+cM8UgIrd9UtQju4NrQjhTQj579EQMla0lHYyfwD1LG0VLcTcLl8tGH0Dye0 YryrTGz63aDfldIEplm3DcXOJeH2Jb8aP83TDs2TdLgLNT+yxpdpDOOI2OfhqrAJ5bvmKs k78kE45tpGnw2fnQVpMPwj0yLOQhLYQLQ0xoRgjC3cZkpDNh4FbRzYs7sC7NEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706987222; 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=xXuldtK0vUo7s87bny1EMn0QALh6iGT8dhhSy+LPex8=; b=YUfZOsBOw1KH8qqJ9k1iTzBQj8AYQr3zy08F0X3s+CBvwfjX6MeLhYGZ7JsL2+FRz4T9eA rYIoCURm8h+j4hq9rieEohID1LT7+6k3s7ErLDN5kuKDwZG1huqtEOuypxUhE1hZyH309F R5heSW6jKFKOQyp3MWJAZaiVHb4y/uuw9rVLoA60lz09vpQO0DHtUCsA3d9Y+Rxilix8PP Y5yomm56eX8PI05LXRe9zareYvgj/YvtPNeYqzg5jWX0jQTbplhgPocWuJcsztZQwy35tR NR8tys2s1KweMqsLD7R0Xidebf0gr5Q0VeYnCoq4uHmPEPwuWb1BpOCgw/PSeg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706987222; a=rsa-sha256; cv=none; b=pPdS3CJTciUN/Rb/wA9viMxNqKUg8B21L0QP5CvL79WHJUlf+eUubnUiaucF/6ADjyTG8E N8MyoTyioeMSaMFspJTa/eRsnt+x+gKNhdFvPXoFb3Pc0Q4FYSPtJrw+z3f2UEouDuLIGu kE4S+OyXhZKO3V3GGHEYWxtMLjBJ2JV/MUT6to5aXuHLuPqN1wG9qr3L59lGw4vcrkUXoO Mx18j1798Ka23C3EMMk89QHfZ3Lp0haSeM9MviKHxI5QzRTZ2/Pk4N0Eu8QJM0uQfzTY8G P8sEHmXXHvghMq2JL4oY9bDASGyvywLtOlSAoZqgxvIaWarI+zKO94WI5EFCqQ== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TS2FL0rntz1RXF; Sat, 3 Feb 2024 19:07:02 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id CB8FA3A0EF; Sat, 3 Feb 2024 20:06:58 +0100 (CET) From: Kristof Provost To: Gleb Smirnoff Cc: Warner Losh , "Bjoern A. Zeeb" , =?utf-8?q?Mina_Gali=C4=87?= , Warner Losh , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, freebsd-arch@freebsd.org Subject: Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL Date: Sat, 03 Feb 2024 13:06:57 -0600 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: References: <202402030136.4131aQIM010980@gitrepo.freebsd.org> <70o6oo0s-r8nn-7r92-5s6r-6so586rpo1o1@SerrOFQ.bet> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3 Feb 2024, at 11:58, Gleb Smirnoff wrote: > We just need at least one supported working kernel without VIMAGE (and > probably other useful stuff, that is not useful to everyone). > Strong agree on this point. There are enough users out there who do not want VIMAGE (well, at least o= ne, but it=E2=80=99s enough of one to care), so we need to ensure it keep= s building. It=E2=80=99s very easy to forget about the non-VIMAGE case, a= nd if we don=E2=80=99t have any kernel configs without we=E2=80=99re goin= g to keep breaking it and not noticing until you run into it. That was even raised in the GitHub review. Best regards, Kristof From nobody Sat Feb 3 20:02:13 2024 X-Original-To: freebsd-arch@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 4TS3Tm6rHWz58K2X for ; Sat, 3 Feb 2024 20:02:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS3Tl3GkPz454s for ; Sat, 3 Feb 2024 20:02:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-55f0b2c79cdso3888380a12.3 for ; Sat, 03 Feb 2024 12:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706990568; x=1707595368; 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=RsFzUx/8EjB01Ton6l+Ru7UwUTCGVVCdFkAgQYtXhCM=; b=MptXhQ0vmArOUAIKjv2vspdzXwMzf5lddoNKEtzxF0X5NWC1z42XG5P+OKc28Hujok 0poMlENJgHgyx7fVrbkC0bO6XE7oM5D2UVf3irk76jgFP8QDjZX0bRb7yqLY6jpAA5RX 8fF6z0Ca78QzbJQ7fVeiv/7HcWDSwRF/xwsE8aG721P39USJUHh/ry5GW80Wh2wJOSTs N4V4gBOtVH5z15QEvOHl/pAb0O5//eFcWBVp8zOGoUKCRTFEMqxHDNKaZU6YiCNEDlkm z2Q1XLne6+ldqmagURe52aQrEJLWWG3DSq2RRK4Vl6QRI3thQFNUlgwbQCYOeQUNf3v6 UBTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706990568; x=1707595368; 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=RsFzUx/8EjB01Ton6l+Ru7UwUTCGVVCdFkAgQYtXhCM=; b=A5I95YAmbuyRrBUmA8GgbWKxv8SfEud71sRge1gKrGES4rCMGsRtEU1dd5w3ZKJMht aGTp8RjkcY/nJPbJquxrK/HJHiVwnNS+hV+4UuwQo0cPMMICDETHAjQ5F7zIUKsSWwzP 4Fikhu2rA7LDtZxYb0wRMJKH4fENieZtYuj7dp8is0B85R4ijnrlgBB3gRiNJvRYyi7q oT82244FBql0dx+ORzsBB26xXJ74AN2pp9M+oZ3NAWzSahNp9ess5ph9V1eXND2YTaYt 1fqIxOPyyglriPH1LkLnK3Qigq3po+6l4r1wXn4EGa1oQGx+d6HOfPKpv7sEGaeZ+Hcx CjrA== X-Gm-Message-State: AOJu0YyFvUOrgtl/1je+8HIgTDnHIhPeNzs/FcDThBecRk9YDkYSqmx3 zog/exjViCjQeVJrMgDEbcGdfdDKd1H//olRoYfS74sais+MSYpzuttoRbChq4POrLPEtOKkkVL PHRzlv5UHWtFsFB0STYek7Tyt2QZKZtcqvdUkcg== X-Google-Smtp-Source: AGHT+IGSqu3XQTZ/GE4dYS2oyFadPQtcMdclt5+ezu5OlcjtS6z2UpLxvMSaq8FboI1FatEy/xSJq+tlgLBUFGxs/20= X-Received: by 2002:a05:6402:896:b0:55f:f13b:d372 with SMTP id e22-20020a056402089600b0055ff13bd372mr2000153edy.21.1706990568508; Sat, 03 Feb 2024 12:02:48 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202402030136.4131aQIM010980@gitrepo.freebsd.org> <70o6oo0s-r8nn-7r92-5s6r-6so586rpo1o1@SerrOFQ.bet> In-Reply-To: From: Warner Losh Date: Sat, 3 Feb 2024 13:02:13 -0700 Message-ID: Subject: Re: git: ce348fe5cfc3 - main - amd64 & i386: enable VIMAGE in MINIMAL To: Kristof Provost Cc: Gleb Smirnoff , "Bjoern A. Zeeb" , =?UTF-8?Q?Mina_Gali=C4=87?= , Warner Losh , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000078abad06107fb69b" X-Rspamd-Queue-Id: 4TS3Tl3GkPz454s X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000078abad06107fb69b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 3, 2024 at 12:07=E2=80=AFPM Kristof Provost wr= ote: > On 3 Feb 2024, at 11:58, Gleb Smirnoff wrote: > > We just need at least one supported working kernel without VIMAGE (and > > probably other useful stuff, that is not useful to everyone). > > > Strong agree on this point. > > There are enough users out there who do not want VIMAGE (well, at least > one, but it=E2=80=99s enough of one to care), so we need to ensure it kee= ps > building. It=E2=80=99s very easy to forget about the non-VIMAGE case, and= if we > don=E2=80=99t have any kernel configs without we=E2=80=99re going to keep= breaking it and > not noticing until you run into it. > > That was even raised in the GitHub review. > MINIMAL is not a CI image to test things. It's a replacement for GENERIC that loads what one can. Its contents need to reflect that. That's why I did not give the issue weight. However,we likely need at a minimum LINT-NOVIMAGE like we have LINT-NOINET today. That's easy enough to arrange, and I'm happy to do it to cover the CI aspects of things. It kinda shows, though, that we may want to have more kernels with carefully thought out options to account for the different needs. I'll try to write up my thoughts on what they should be. I'm leaning to have an vm vs embedded vs server split as well as a load-it-all vs compile-it-in split, regardless of what they are named. And there's some base for all three and then extensions from there (vm and embedded may be the same, and server may be a superset of those two). So I'll take an action item to come up with a concrete proposal for these things, along with good definitions so people enhancing the system in the future have good guidance on wher to do that. Warner --00000000000078abad06107fb69b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Feb 3, 2024 at 12:07=E2=80=AF= PM Kristof Provost <kp@freebsd.org= > wrote:
On 3= Feb 2024, at 11:58, Gleb Smirnoff wrote:
> We just need at least one supported working kernel without VIMAGE (and=
> probably other useful stuff, that is not useful to everyone).
>
Strong agree on this point.

There are enough users out there who do not want VIMAGE (well, at least one= , but it=E2=80=99s enough of one to care), so we need to ensure it keeps bu= ilding. It=E2=80=99s very easy to forget about the non-VIMAGE case, and if = we don=E2=80=99t have any kernel configs without we=E2=80=99re going to kee= p breaking it and not noticing until you run into it.

That was even raised in the GitHub review.

MINIMAL is not a CI i= mage to test things. It's a replacement for GENERIC that loads what one= can. Its contents need to reflect that. That's why I did not give the = issue weight. However,we likely need at a minimum LINT-NOVIMAGE like we hav= e LINT-NOINET today. That's easy enough to arrange, and I'm happy t= o do it to cover the CI aspects of things.

It kinda shows, though, that we may want to have mo= re kernels with carefully thought out options to account for the different = needs.=C2=A0 I'll try to write up my thoughts on what they should be. I= 'm leaning to have an vm vs embedded vs server split as well as a load-= it-all vs compile-it-in split, regardless of what they are named. And there= 's some base for all three and then extensions from there (vm and embed= ded may be the same, and server may be a superset of those two). So I'l= l take an action item to come up with a concrete proposal for these things,= along with good definitions so people enhancing the system in the future h= ave good guidance on wher to do that.

Warner
--00000000000078abad06107fb69b-- From nobody Sun Feb 4 06:54:58 2024 X-Original-To: freebsd-arch@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 4TSKyP0dP9z5998Q for ; Sun, 4 Feb 2024 06:55:09 +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 4TSKyN3Xdfz55rf; Sun, 4 Feb 2024 06:55:08 +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=1707029701; 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=eg36FzIvrO/81phF0XlFsNt6Qpif9mISyeGGQgBxIHQ=; b=P2uJOdsNkHqSYspbF7bsZPCaTkEHhidfx+Dbbrq6DC7uwhJ63zEteOwVMDVizo5D9OfUay C4TWiNPKlBf5plbe6yTvHw1UcfaInWqDkAcHLEPvZRivRFMzWb/scI56aoxPHT4vckoa7A 6FBKXNywtg7yTQnlUIsiUQRHAxWTNaY= 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 4ad0be87 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 4 Feb 2024 06:55:01 +0000 (UTC) Date: Sun, 4 Feb 2024 07:54:58 +0100 From: Emmanuel Vadot To: Enji Cooper Cc: "Piotr P. Stefaniak" , Dag-Erling =?ISO-8859-1?Q?Sm?= =?ISO-8859-1?Q?=F8rgrav?= , Minsoo Choo , freebsd-arch@freebsd.org Subject: Re: Importing Heimdal 7.8.0 Message-Id: <20240204075458.04884948a03419c3afcd1f4f@bidouilliste.com> In-Reply-To: <7B302C8A-8A56-4840-B8D1-A01A3F9D765C@gmail.com> References: <7B302C8A-8A56-4840-B8D1-A01A3F9D765C@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TSKyN3Xdfz55rf 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] On Sat, 3 Feb 2024 10:24:09 -0800 Enji Cooper wrote: >=20 > > On Feb 3, 2024, at 09:45, Piotr P. Stefaniak wrote: > >=20 > > ?On 2024-01-31 15:31:38, Dag-Erling Sm=F8rgrav wrote: > >> Minsoo Choo writes: > >>> I'm currently working on importing the latest version of Heimdal, > >>=20 > >> Please don't. > >=20 > > why >=20 > Cy is importing MIT kerberos. MIT is (in many cases) the defacto flavor o= f kerberos. > Cheers, > -Enji Is changing kerberos flavor in 2024 really what we want ? People who are using base kdc will likekly migrate to ports version of heimdal as database isn't compatible (unless something has changed in the past 15 years I've used kerberos). I guess that kerberos is still used a bit at some Colleges or old corporation that haven't moved from it but is it relevant for us to still include kerberos in base ? OpenSSH-portable/curl and anything else in ports could be moved to use MIT/Heimdal from ports (based on some options and/or subpackages if that is possible). --=20 Emmanuel Vadot