From nobody Fri Mar 17 18:08:06 2023 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 4PdXDZ2kxpz3yfWv for ; Fri, 17 Mar 2023 18:08:14 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 4PdXDY13x4z3FlP; Fri, 17 Mar 2023 18:08:13 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net; dmarc=none Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 8D9F93C0199; Fri, 17 Mar 2023 18:08:06 +0000 (UTC) Date: Fri, 17 Mar 2023 18:08:06 +0000 From: Brooks Davis To: Justin Hibbits Cc: freebsd-arch@freebsd.org Subject: Re: Blocks runtime in the kernel Message-ID: References: <20230316100611.4892008c@gonegalt.net> 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 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20230316100611.4892008c@gonegalt.net> X-Spamd-Result: default: False [-1.80 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; FREEFALL_USER(0.00)[brooks]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PdXDY13x4z3FlP X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Thu, Mar 16, 2023 at 10:06:11AM -0400, Justin Hibbits wrote: > Most probably know I've been working on the IfAPI conversion of all > network drivers in order to hide the contents of `struct ifnet`. I'm > pretty much done with the development, and it's all in review. > However, there's one bit that I've thought is very clunky since I added > it, the if_foreach() iterator function, which iterates over all > interfaces in the current VNET, and calls a callback to operate on each > interface. I've noticed that oftentimes I end up with a 2 line > callback, which just calls if_foreach_addr_type(), so I end up with > just trivial callback functions, which seems like a waste. >=20 > All that backstory to say, would it be beneficial to anyone else to > add a (very basic) blocks runtime to the kernel for doing things like > this? The rough change to the IfAPI becomes: >=20 > int if_foreach_b(int (^)(if_t)); >=20 > __block int foo =3D 0; >=20 > if_foreach_b(^(if_t ifp) { > if (if_getlinkstate(ifp) =3D=3D LINK_STATE_UP) > foo++; > }); >=20 > The same could be done for other *_foreach KPIs as well, if this proves > out. I think I could have something working in the next several days. >=20 > The only technical snag I see with this would be other compilers. I'm > not sure if GCC still supports blocks, it did at one point. I think two things make this a non-starter. First, GCC doesn't support this feature and I don't think we want to lose that for the reasons Warner outlines elsewhere. Second, it seems moderately likely that C2Y will include lambdas in some form which fills the same niche. This will further reduce the likelihood of blocks support being widespread (already extremely unlikely). At this point I think we just need to live with the clunky syntax. :( -- Brooks From nobody Mon Mar 27 16:16:01 2023 X-Original-To: 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 4PldGT60qwz41k94 for ; Mon, 27 Mar 2023 16:16:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PldGT3zQdz4J70 for ; Mon, 27 Mar 2023 16:16:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679933761; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TIJn8c6wEkEB2n0zqGloglVG4dh7s4YiGAeT/82AzZs=; b=pOq/jwjfY2zttG7/rOXDx1I+PEowYOWHtvDaqLMuNoGmKoQ/1DYsmeDZaZiTf/K2goalTP 8Yc73eHppkuU8rCpU1fTCUc9dVz9HBj63TaNa3eaOCYzXSy/sGwjRqnN3WAA1QLYOh+cbU aYoexOhtTw+ZP7SSjg7tDxzWav2gUQaM8xYL3q01fg1mtcnweFKWrUlCAxClGSSFKNp6hS 7cr5Y34CzIHqyEvhl7bybM9/pWdLTqQUDFZ1T7gNa78PoQFFZGu4nV5QD5R7quw57pEFjg gF4qOXn/MrqmxJawjisSLtRUZF9IJK8j3cgadJAxyUbX/qHaW9aoA1g8vBRjyQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1679933761; a=rsa-sha256; cv=none; b=X3kfYsgeGYre8iM3yJ0dSC4xUnWausYViYejBiLjERpQdeJtT9QT7L/K+4f+vruCUE4wzK kcZo0Wvzdbs1BM6s0ad836ezmE6HP/rXxuWCDBsJkskb0C7LYsmmM+Z1cQS0ZD7pU9pW+L pmA9/DB4w/XPZ1pieEhY4PFqbcLq7SGI4wATn90meqQyZ/KXhx/AQWIAHz/Z2ejGaHddOm 0f6Zi928an+3ChFQmgrDQ7DijElK413hBNxBe9OOjn2/65iM5EfqZcC5GJH92mUnME0D/s UAB6sZmERMW2JI7HB/siad+4+g/GnQfjSvjsB+mOQUSLQnnkSSho+4t4oE7/DA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PldGT34KSzSxs for ; Mon, 27 Mar 2023 16:16:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 32RGG1Qs013722 for ; Mon, 27 Mar 2023 16:16:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 32RGG1hw013721 for arch@FreeBSD.org; Mon, 27 Mar 2023 16:16:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: arch@FreeBSD.org Subject: [Bug 270481] intro(9) needs an update/rewrite Date: Mon, 27 Mar 2023 16:16:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Documentation X-Bugzilla-Component: Manual Pages X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mhorne@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: mhorne@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc blocked Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270481 Bug ID: 270481 Summary: intro(9) needs an update/rewrite Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Manual Pages Assignee: mhorne@freebsd.org Reporter: mhorne@freebsd.org CC: arch@FreeBSD.org, doc@FreeBSD.org Blocks: 248562 The intro(9) man page is outdated, with a last modified date of 1995(!). The page contains a few general programming recommendations and a link to style= (9). Beyond this it fails to provide any real introduction to this section of documentation. While imperfect, section 9 is the most comprehensive set of documentation f= or the FreeBSD kernel source code that exists. This man page has the potential= to be a useful landing page for navigating and discovering this resource. A complete rewrite of this page is in order, with the following goals/principles: - Provide more detailed high-level introduction to this documentation set; describe purpose, authors & audience, and expectations regarding coverage, level-of-detail, and accuracy - Include cross-references to as many section 9 pages as reasonable. This improves their discoverability - Group links by subsystem/domain. NetBSD's intro(9) page is a good exampl= e of this [1] I have begun this rewrite, so this PR is self-assigned and mainly for track= ing purposes. Feedback on what should be usefully included in the new page is welcome. [1] https://man.freebsd.org/cgi/man.cgi?query=3Dintro&apropos=3D0&sektion=3D9&m= anpath=3DNetBSD+9.3&arch=3Ddefault&format=3Dhtml Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248562 [Bug 248562] [meta] intro man pages: review, revamp, update --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Mon Mar 27 17:17:33 2023 X-Original-To: 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 4PlfdT6jpBz41nZ1 for ; Mon, 27 Mar 2023 17:17:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PlfdT4tsgz4QGS for ; Mon, 27 Mar 2023 17:17:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679937453; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gLiaopn/Sx0XDymwtVXHCzQTyEsv2MY1rvJZp+Rpzx0=; b=trsTl8eWUBU35KKvHMcUGJMearVWFIGibgC8ZjDxBt142TB68C5Oc4frvpmxerr1pRdX2J x2weafiEcEjc/xG3QVpoINjLkre1jXPsYPQUUGZ7QXXNCLZRh2rpzzLTYMUf1IRK3IdoqV rzKYXqtjqt8XbeReIqI29PFfd2BVXp6rqYj3ulqmwO8rVM0zLvjFh6W0842Rlta7MCv3Wo PheG51Lhy0Wmg5VuvcAiIzWYTZLYQ5KacKAI1mFOWfVR9oWQ3O2on//qNvh2sBMA0Y1g/K 7uHdByThmTJCAtWQdMbbFZcM310kDUO8IA1FewWaqcTJHC/dKDPqXcATOnke4Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1679937453; a=rsa-sha256; cv=none; b=MsJ1XuB6s5TQ/NoH0zokJRGRxGCkHC1KziAjLEQ4RUWrg4IxaoMiX+d+MmDZo7Kpq4ritT OT6oH/Equouk3FDy7eLjRhUDM4vdJt9cMKbhYQxz+Ihhjt9p+zvG06sExyvWARFHjbyIsu Pu+ECwNF7jWwugCRKiLljzYdifAiJLGCjuh9vBi+A33bwHbladFBk/v4tc7Jm270zlrAtP TTtTJEn6qTjMGlRS6wRZN7rlLJXKdSyW9lY2l1grrmWCpgbM2w7nNewK/6KWKzbAMqX503 d+oN1jXfWc2zvDmEgC5rmd+RNAwb2DPb2SwePQay5yhx/aXZQ+VvDgh0wWE2aA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PlfdT3yk3zWJL for ; Mon, 27 Mar 2023 17:17:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 32RHHXj5099516 for ; Mon, 27 Mar 2023 17:17:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 32RHHXox099515 for arch@FreeBSD.org; Mon, 27 Mar 2023 17:17:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: arch@FreeBSD.org Subject: [Bug 270481] intro(9) needs an update/rewrite Date: Mon, 27 Mar 2023 17:17:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Documentation X-Bugzilla-Component: Manual Pages X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hselasky@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: mhorne@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270481 Hans Petter Selasky changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hselasky@FreeBSD.org --- Comment #1 from Hans Petter Selasky --- Perfect! Now I know where to point people when they don't like my code formatting :-) Oooh it's written in intro(9) that I don't have to care about style(9) really .... > - Include cross-references to as many section 9 pages as reasonable. This= improves their discoverability +1 Are you making a differential revision for this? Maybe you could start with the same sections NetBSD use, and then just fill= in new stuff for FreeBSD? --HPS --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Mon Mar 27 19:11:03 2023 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 4Plj8T6kFBz41wsL for ; Mon, 27 Mar 2023 19:11:05 +0000 (UTC) (envelope-from jhb@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 4Plj8T6J8bz3ChZ; Mon, 27 Mar 2023 19:11:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679944265; 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=raC/X5aG8mKAxaSNc52OG8dYyMEw4dwWZGreExS47e0=; b=xLi9EJna9U1YUCMimn9Vd3V/AjI62aqk3rrE9BAyFanQf3fs3/NhH6LOSKBbEWZs6r4MdY /VIGCZV4HxX1r2eqP3lf6cw0qL2hgKkgBDigE0tZ9WOxuvedOzF2e1XHSjn9gC9Qv79ehn Z03ViaokQBzkjvOFCjcxfN++ulL2Jeh5GZttwfbojyj0YCn8Q+ZXHCD5Y7b8ZeC4uRcnUu FvevlWkCYaPVxu2GNCAEQTKri8OkOi/97R8z8f0oovZl0LPcfXgZiOP0Mn82jv5wqUyVgE tctwpfrfI9+6KSp0cYW281Qew112aK6/cSGG8OQ/vYVHeJguYIotmJc0D+bThA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679944265; 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=raC/X5aG8mKAxaSNc52OG8dYyMEw4dwWZGreExS47e0=; b=Ry87vtr5+IhtHkGfn358KnTzbqfL4Mh9WcF/E1Y9Mg37Gh3l/TRo6vXEA3reRmXaTlZlnI k38d3QU2cyReollbbttlV5ugKDua2OBHiNjQ/perRuQwNm34KELxaJ0Fomi1I0rCw3JyHp C1RCCu7q+zymRgQaPDgPu1WrO3fW9xl0XOVL6RKPOq36ZrGwKu+/BG/MgGqhOUmLrN+jNz EathGRpBYzh/Hk6aat+mq4yfPV7tE6rVrdy43FClgt4Wx31fX5HO77euf5je0gHsxNlcbk PseFw8NWBm7Di/iLOf8TqFKmgyCQ+B9rSVFCGSuHpjEZAUydmJUH+5c77wiSYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1679944265; a=rsa-sha256; cv=none; b=nYh0yludz2991naXSZ5DnDo6b4RNCu1b5Vn1dWj5isoHZyag5Qgid69zGmUppTfRM4HZDy YVNDlmdRT9gsxqY3RaWQ8cs5oBgwfGS/4pxwjPDwHaKPQyOWqLqXFvsUtVE8Ktf9ohIN0J 21CGFw1IjS5icRnIUh5sCnv5JkGyq27MCOrSRg54SlbycONXxEV7fSJkCy0ZvQfCv7GQkq FQf1ES3o2/YhhdPCrRbyuAPJeI5aGB4ULjrc/5OCop44uaisZHYtvXg4u0ooIrSvwfjVxL st2Iph3Uio4ltElZC88HCEJWp6s8cFSOuBti2G/AXI/JaifB6JMKAex07HRceg== Received: from [IPV6:2601:648:8680:16b0:c10c:3358:4516:c03f] (unknown [IPv6:2601:648:8680:16b0:c10c:3358:4516:c03f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Plj8T2mBnzJKf; Mon, 27 Mar 2023 19:11:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org> Date: Mon, 27 Mar 2023 12:11:03 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Content-Language: en-US To: Brooks Davis , Justin Hibbits Cc: freebsd-arch@freebsd.org References: <20230316100611.4892008c@gonegalt.net> From: John Baldwin Subject: Re: Blocks runtime in the kernel In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 3/17/23 11:08 AM, Brooks Davis wrote: > On Thu, Mar 16, 2023 at 10:06:11AM -0400, Justin Hibbits wrote: >> Most probably know I've been working on the IfAPI conversion of all >> network drivers in order to hide the contents of `struct ifnet`. I'm >> pretty much done with the development, and it's all in review. >> However, there's one bit that I've thought is very clunky since I added >> it, the if_foreach() iterator function, which iterates over all >> interfaces in the current VNET, and calls a callback to operate on each >> interface. I've noticed that oftentimes I end up with a 2 line >> callback, which just calls if_foreach_addr_type(), so I end up with >> just trivial callback functions, which seems like a waste. >> >> All that backstory to say, would it be beneficial to anyone else to >> add a (very basic) blocks runtime to the kernel for doing things like >> this? The rough change to the IfAPI becomes: >> >> int if_foreach_b(int (^)(if_t)); >> >> __block int foo = 0; >> >> if_foreach_b(^(if_t ifp) { >> if (if_getlinkstate(ifp) == LINK_STATE_UP) >> foo++; >> }); >> >> The same could be done for other *_foreach KPIs as well, if this proves >> out. I think I could have something working in the next several days. >> >> The only technical snag I see with this would be other compilers. I'm >> not sure if GCC still supports blocks, it did at one point. > > I think two things make this a non-starter. First, GCC doesn't support > this feature and I don't think we want to lose that for the reasons > Warner outlines elsewhere. Second, it seems moderately likely that C2Y > will include lambdas in some form which fills the same niche. This > will further reduce the likelihood of blocks support being widespread > (already extremely unlikely). At this point I think we just need to > live with the clunky syntax. :( Alternatively one could use C++. I think that would be an easier sell than Blocks TBH. It's not hard to write the little bits you would need to let you use a ranged-for for this (which I find more readable than the lambda approach anyway). If you don't need to perform cleanup actions when terminating an iteration you could also provide helper functions that let you implement a IF_FOREACH() wrapper macro that would function similar to TAILQ_FOREACH(). You would just need 'if_first()' and 'if_next()' helpers. -- John Baldwin From nobody Mon Mar 27 22:14:42 2023 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 4PlnDc4vM2z428wn for ; Mon, 27 Mar 2023 22:14:56 +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 4PlnDc1dHnz3v1r; Mon, 27 Mar 2023 22:14:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 32RMEh9k077047 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 28 Mar 2023 01:14:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 32RMEh9k077047 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 32RMEgIg077045; Tue, 28 Mar 2023 01:14:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Mar 2023 01:14:42 +0300 From: Konstantin Belousov To: John Baldwin Cc: Brooks Davis , Justin Hibbits , freebsd-arch@freebsd.org Subject: Re: Blocks runtime in the kernel Message-ID: References: <20230316100611.4892008c@gonegalt.net> <0f19b708-c167-b05e-1b0d-e4c1029a50c4@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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org> 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.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4PlnDc1dHnz3v1r X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Mar 27, 2023 at 12:11:03PM -0700, John Baldwin wrote: > On 3/17/23 11:08 AM, Brooks Davis wrote: > > On Thu, Mar 16, 2023 at 10:06:11AM -0400, Justin Hibbits wrote: > > > Most probably know I've been working on the IfAPI conversion of all > > > network drivers in order to hide the contents of `struct ifnet`. I'm > > > pretty much done with the development, and it's all in review. > > > However, there's one bit that I've thought is very clunky since I added > > > it, the if_foreach() iterator function, which iterates over all > > > interfaces in the current VNET, and calls a callback to operate on each > > > interface. I've noticed that oftentimes I end up with a 2 line > > > callback, which just calls if_foreach_addr_type(), so I end up with > > > just trivial callback functions, which seems like a waste. > > > > > > All that backstory to say, would it be beneficial to anyone else to > > > add a (very basic) blocks runtime to the kernel for doing things like > > > this? The rough change to the IfAPI becomes: > > > > > > int if_foreach_b(int (^)(if_t)); > > > > > > __block int foo = 0; > > > > > > if_foreach_b(^(if_t ifp) { > > > if (if_getlinkstate(ifp) == LINK_STATE_UP) > > > foo++; > > > }); > > > > > > The same could be done for other *_foreach KPIs as well, if this proves > > > out. I think I could have something working in the next several days. > > > > > > The only technical snag I see with this would be other compilers. I'm > > > not sure if GCC still supports blocks, it did at one point. > > > > I think two things make this a non-starter. First, GCC doesn't support > > this feature and I don't think we want to lose that for the reasons > > Warner outlines elsewhere. Second, it seems moderately likely that C2Y > > will include lambdas in some form which fills the same niche. This > > will further reduce the likelihood of blocks support being widespread > > (already extremely unlikely). At this point I think we just need to > > live with the clunky syntax. :( > > Alternatively one could use C++. I think that would be an easier sell > than Blocks TBH. It's not hard to write the little bits you would need > to let you use a ranged-for for this (which I find more readable than the > lambda approach anyway). > > If you don't need to perform cleanup actions when terminating an iteration > you could also provide helper functions that let you implement a > IF_FOREACH() wrapper macro that would function similar to TAILQ_FOREACH(). > You would just need 'if_first()' and 'if_next()' helpers. You might also take a look at the design of MNT_VNODE_FOREACH(). From nobody Tue Mar 28 19:43:56 2023 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 4PmKqy4Qhpz42LNy for ; Tue, 28 Mar 2023 19:43:58 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PmKqy3fM8z48ld; Tue, 28 Mar 2023 19:43:58 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680032638; 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=AWFuku7kdBglXCSGateTCXNZvFtqz0005yLDXyvW74M=; b=yFMhhDEhx6GQV5hro8j5tk2/BHOHWCrdFIMNX3EkV6d02z/II97Kbo/5JKmSxeSfbFsJWv w2RQACaMImNUnFfBuYulBvoVt5moWpWGf/uDf2saib1Lu9vuHe9GBDY3PYtjGYw1hM6bfP 9ZaBotwQ5nCv6ErUf/0H9170NEqs4JUZgtka+8JV4aOFgfvZyQODSPRzU+b8peTgVvYA9P HDFT+aBFeP9MOxbqBTUQKFDUchw+Au3hFZ4QMQm0282LF+c9zRvnvOaFpMAeOnYF9SnB0w KziRx/e0W7hp/mRAlPivt33MaoF/dkvxMb4jF8DoCeywpAhOY4yzlHCiIYeQdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680032638; 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=AWFuku7kdBglXCSGateTCXNZvFtqz0005yLDXyvW74M=; b=UeaCXuEMjLK3hGxyy06whwLKrCnkFKoGGiYkp3rZdCQq6AwbF5SvpEhmOdWKnKTHFvZdQC SRVYiFYRKSRKETLMnfnw4kVP60mKsXpdvQpDuOQowOHX21NJqumPLHMZnLxlDrNdTNQrCo DVXZppaMlOoX2Dh0SYXOKvwR9/0eqxzX38O3awXhfUm6GbNObjMIxHCVDFNX++oQLHsxP9 4uGw5RW13ccVXtq+Hz3I/ss3oGUwjCRzrqemF4CvjlfkBww7PlYe3qtUHzw2qIFKwLvLa2 RawIuFC+CKvfn9SFCDjYc9kp+4ebPg7Er2PR/mI8AxrAiLBJ0RutCDwvp48UQg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680032638; a=rsa-sha256; cv=none; b=VilH9GESbblKL64ftDrZpLmCD2UaC9l7M79UBt4s7RHDRukCr2SH3Hy8jjJ0IQ6EzndLrD Dr62cx8EAFQPbDyEyVt0dRPQVv5583Tgr3dtdBXETAEs/BPU4eTUbWEc+FOebZgHkZak3y pvewO4qHl4sX81tC5PdBw04CHajo96o9CF9rY/MOjLZRBXNj8w0xWLIWBfaC4227TsAeOZ A0OCLHpMjIxTIfdCmZUkbrnmMECs1e1C2a1XRPXh71SUm7As66LrA9ItwRPXF3zdA2J1Uv 1R27Tg5jHbuPFyJn9JNCqQ9I5lCIqpqHmgXyrv6JXyigbxKBnWNNxogljq6w8A== Received: from gonegalt.net (ip-163-182-7-56.dynamic.fuse.net [163.182.7.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhibbits) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PmKqy1FXTzkn6; Tue, 28 Mar 2023 19:43:58 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Tue, 28 Mar 2023 15:43:56 -0400 From: Justin Hibbits To: Konstantin Belousov Cc: John Baldwin , Brooks Davis , freebsd-arch@freebsd.org Subject: Re: Blocks runtime in the kernel Message-ID: <20230328154356.7130e4e0@gonegalt.net> In-Reply-To: References: <20230316100611.4892008c@gonegalt.net> <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; powerpc64le-unknown-linux-gnu) 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-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On Tue, 28 Mar 2023 01:14:42 +0300 Konstantin Belousov wrote: > On Mon, Mar 27, 2023 at 12:11:03PM -0700, John Baldwin wrote: > > On 3/17/23 11:08 AM, Brooks Davis wrote: > > > On Thu, Mar 16, 2023 at 10:06:11AM -0400, Justin Hibbits wrote: > > > > Most probably know I've been working on the IfAPI conversion of > > > > all network drivers in order to hide the contents of `struct > > > > ifnet`. I'm pretty much done with the development, and it's > > > > all in review. However, there's one bit that I've thought is > > > > very clunky since I added it, the if_foreach() iterator > > > > function, which iterates over all interfaces in the current > > > > VNET, and calls a callback to operate on each interface. I've > > > > noticed that oftentimes I end up with a 2 line callback, which > > > > just calls if_foreach_addr_type(), so I end up with just > > > > trivial callback functions, which seems like a waste. > > > > > > > > All that backstory to say, would it be beneficial to anyone > > > > else to add a (very basic) blocks runtime to the kernel for > > > > doing things like this? The rough change to the IfAPI becomes: > > > > > > > > int if_foreach_b(int (^)(if_t)); > > > > > > > > __block int foo = 0; > > > > > > > > if_foreach_b(^(if_t ifp) { > > > > if (if_getlinkstate(ifp) == LINK_STATE_UP) > > > > foo++; > > > > }); > > > > > > > > The same could be done for other *_foreach KPIs as well, if > > > > this proves out. I think I could have something working in the > > > > next several days. > > > > > > > > The only technical snag I see with this would be other > > > > compilers. I'm not sure if GCC still supports blocks, it did > > > > at one point. > > > > > > I think two things make this a non-starter. First, GCC doesn't > > > support this feature and I don't think we want to lose that for > > > the reasons Warner outlines elsewhere. Second, it seems > > > moderately likely that C2Y will include lambdas in some form > > > which fills the same niche. This will further reduce the > > > likelihood of blocks support being widespread (already extremely > > > unlikely). At this point I think we just need to live with the > > > clunky syntax. :( > > > > Alternatively one could use C++. I think that would be an easier > > sell than Blocks TBH. It's not hard to write the little bits you > > would need to let you use a ranged-for for this (which I find more > > readable than the lambda approach anyway). > > > > If you don't need to perform cleanup actions when terminating an > > iteration you could also provide helper functions that let you > > implement a IF_FOREACH() wrapper macro that would function similar > > to TAILQ_FOREACH(). You would just need 'if_first()' and > > 'if_next()' helpers. > > You might also take a look at the design of MNT_VNODE_FOREACH(). Thanks for all the feedback. I ended up going roughly jhb@'s route, but including an (optional) cleanup function, in case the netstack needs to do some cleanup afterwards. This went in e2427c6917. I'm not sure if cleanup is necessary, but in the case a stack might allocate memory for the iterator, it's there (goal being to allow unmodified drivers to work with different stacks). On a side note, a friend of mine would love to see C++ in the kernel, but that's a discussion for another day. - Justin From nobody Tue Mar 28 19:01:20 2023 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 4PmLCs0QwGz42Mfg for ; Tue, 28 Mar 2023 20:01:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4PmLCr6TX0z4Cgs; Tue, 28 Mar 2023 20:01:12 +0000 (UTC) (envelope-from hps@selasky.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.36.2.154] (unknown [46.212.121.255]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 75D6F2609C7; Tue, 28 Mar 2023 22:01:11 +0200 (CEST) Message-ID: Date: Tue, 28 Mar 2023 21:01:20 +0200 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: Blocks runtime in the kernel Content-Language: en-US To: Justin Hibbits , Konstantin Belousov Cc: John Baldwin , Brooks Davis , freebsd-arch@freebsd.org References: <20230316100611.4892008c@gonegalt.net> <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org> <20230328154356.7130e4e0@gonegalt.net> From: Hans Petter Selasky In-Reply-To: <20230328154356.7130e4e0@gonegalt.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4PmLCr6TX0z4Cgs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 3/28/23 21:43, Justin Hibbits wrote: > On a side note, a friend of mine would love to see C++ in the kernel, > but that's a discussion for another day. Hi, I've never used blocks before, but it kind of gets me thinking about C++ templates. Can't you just use static inline functions, and the compiler will insert and optimise the code for you? Or make some macros to generate foreach functions doing various simple things? Personally, it took many years before I grasped all of C++ . I'm worried that blocks is one of those features that look nice, but have strange corners and require more from code analysis. For example if you do static code analysis and use blocks, will the static code analysis tool be completely lost? What about services like coverty? Do they find bugs hidden when using blocks? --HPS From nobody Wed Mar 29 18:17:21 2023 X-Original-To: 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 4Pmvsb62Z9z42tCR for ; Wed, 29 Mar 2023 18:17:23 +0000 (UTC) (envelope-from jhb@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 4Pmvsb5Wr4z3K71 for ; Wed, 29 Mar 2023 18:17:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680113843; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=AeU18zaz5jKVvf1tLZpmz9iklghhY9yvQpGteTSucuI=; b=NutE2nuDHBhGBtq/uUzp5uPgXs12w+m/cv68Sz9qS0iz3v7v8b2zruhtjDy+J5RvG0Ir58 0S6tPDEDyyNB3qRKWbpmhrNQ16cEiQUJTCR9D2xxOR0zKxGBgedM3ahzeqEPLlJ5mor3QI uRzWJeZwgaSxnibyfs1c+wFispgilcgvpTU7nUGracM771QLfDOqjIQasgoQW+vlom3tZk pSdhHvpyIvMaT58z++QKTbrVpYEqJjMLIIkDXMHrPME701DeLNoYOanWPYTwgufZW6pJwh 9gTdcsDRjgJxFcINsOKLFJF/kDXqdqET8Jhko+D/set1Y5Dvw5lKg3Je4e5qiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680113843; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=AeU18zaz5jKVvf1tLZpmz9iklghhY9yvQpGteTSucuI=; b=jyWKd9Tj5meznRH/iQspDMEAmpDCeN9g4JZd8jK5KluaV/9tqPScv2uroGE7YgocTOrMpl 86UsGUL8yaPj86FopUSHNLkj6LPfoxvhXKFM6PZU3MkpD0Ccaw4JWIw3mwtWQTDxX4f4sO pqAhbUsvzBSezU42YF6TefBDud1Fn9/7sI5H4hj1nOvV6egu3LkxMidj6e+mDdm33ycmMn Pf+RoRSKtsuYdtZwpN/h/GJiCXxgoGG35FTLHy6YHNVnQSIh0s4hu0iGB5k+CoUlFIdJBm ajVUEqACg9Y+KS0/9D+AMSjfl0KEsajuftWo/upBVm1LADzYlQzd+DgitOxBFw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680113843; a=rsa-sha256; cv=none; b=sDVYIj8xFr0uFdFskudDzEcubKQ1duAxz6hf/Y+UVacqjawcZTBi4lYGLH5oavS2ohy/Kd TTFKt70jwBug8SaTKyt3pCeE2HUb49SmcaWLFoXmDPuBu4g5Xf6xeHCYaiHOV5af1N22po TqScVmGWQLAdvLNCDiws2aaS+zNPMP9vSYfQBfYwuLqCLH/LsulHzqM0v+Yfsw3gws3qUE c9q7U0Z5JRYdfMH7Qm0iut+VL1JiypNYyAAJmE2ARhfZnejaz+LnoIl8eApAN9vyokSBrd mNC5YJ/72jjQiWTgaTxtFCXPSSuOhqdnsrU2QcpqC4htz524IJZsD8d767H3lQ== Received: from [IPV6:2601:648:8680:16b0:857f:81f3:e6ff:643e] (unknown [IPv6:2601:648:8680:16b0:857f:81f3:e6ff:643e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Pmvsb3690z1BmX for ; Wed, 29 Mar 2023 18:17:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <629bf85d-4d48-17f5-cb26-dfd29f7e6ff7@FreeBSD.org> Date: Wed, 29 Mar 2023 11:17:21 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Content-Language: en-US From: John Baldwin To: arch@FreeBSD.org Subject: Deprecate/remove riscv64sf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N Is anyone using riscv64sf? All of the existing RISC-V boards include hard-float support as well as QEMU. The FPGA cores we use at Cambridge also all support hard-float. My understanding is that glibc doesn't bother supporting soft-float on RV64. If no one is using it (and has no plans to use it), then I propose we drop it in 14.0 and save one more buildworld from make tinderbox. -- John Baldwin From nobody Thu Mar 30 01:39:43 2023 X-Original-To: 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 4Pn5x85j9tz42Cnc for ; Thu, 30 Mar 2023 01:51:08 +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 4Pn5x85HZ8z4Q77 for ; Thu, 30 Mar 2023 01:51:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x533.google.com with SMTP id r11so70665891edd.5 for ; Wed, 29 Mar 2023 18:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; t=1680141067; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gxd6KFeOfvdZLCN6vMFFjj6rGX1gXzX8418rXe/rx8Q=; b=aewad/jnj6T5Oh0wz5WU9a/+NOu/hZEGX1w49WjhjgJ7hI75BNSSW03UUYN9NTGpra ELvZYeaEMFdJQzN6XO2xKT3VoOCodfuBZVopV6EqOQtZAv1Y0sst81p6fW04eWCb1ZOf LQfUv3p97ukGKEwlZeK4ggVNZYRi0IKJIW9lni776/CesnEN3A8j/8sbzRciOEPt+mUP zEqcArXnoPWJlN/2HzyE4A+9vod6CUZtTnaUb8AOQeRu9iV8zivxfIt5va4pap7DayX3 snc32Vn27k+6V85D20BOnQOU+C203AUasqsuhCgLEO8id0vvu4y99SBHjQsEEhFrsOnw QlSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680141067; 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=gxd6KFeOfvdZLCN6vMFFjj6rGX1gXzX8418rXe/rx8Q=; b=sjayvkO4Rd3tQyy91blSFGNxGucoXROSnpI682CfHWg/HE1WzN6TuQvP13Dw9xgpda D7HcyepoqUmvzoL6YLPQYyEoiCr1PZQJkx6CyOlOLBBhO+SzF14bIAiYIfCm1SErdrUm cgCOQT6JgOlQBHvX1SMEYjdsQnaSu1tV2VH90AYTj09gotTREe9qIq/bunnU0JONlSur XSLkmn4EbOmLHlAu1LiRRZk8Qhjcd+xn1L0xnQLdmLgHtZc3h+aO60rG6Vzowj/exoSS 8edJQtNKHdY/SSS7nYwTqRDkdlZZ1kzHHLVaMYS5qZAleaUNczX1t42d9+9aDeuA+NY5 b4qw== X-Gm-Message-State: AAQBX9dsvXeOGPTa0rzhstpIoxJn81SWutuHzFAdvfEw7FPJHAC6TIq/ wi9G2XW8usuAWuGmvpRrRcEEdcEiFy2BNj/tRc0AYA== X-Google-Smtp-Source: AKy350b2rlusEQduXvR5QiStpXT2VK6o6j7RjQAH0+wgg0o7howao3Ol3ylXMp0VfRXW1VBf3M7vuqX+yYM/G8UUEIY= X-Received: by 2002:a17:907:d687:b0:93d:a14f:c9b4 with SMTP id wf7-20020a170907d68700b0093da14fc9b4mr10842951ejc.2.1680141067376; Wed, 29 Mar 2023 18:51:07 -0700 (PDT) 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: <629bf85d-4d48-17f5-cb26-dfd29f7e6ff7@FreeBSD.org> In-Reply-To: <629bf85d-4d48-17f5-cb26-dfd29f7e6ff7@FreeBSD.org> From: Warner Losh Date: Wed, 29 Mar 2023 19:39:43 -0600 Message-ID: Subject: Re: Deprecate/remove riscv64sf To: John Baldwin Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000007e6c9c05f81453ed" X-Rspamd-Queue-Id: 4Pn5x85HZ8z4Q77 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000007e6c9c05f81453ed Content-Type: text/plain; charset="UTF-8" On Wed, Mar 29, 2023, 12:17 PM John Baldwin wrote: > Is anyone using riscv64sf? All of the existing RISC-V boards include > hard-float > support as well as QEMU. The FPGA cores we use at Cambridge also all > support > hard-float. My understanding is that glibc doesn't bother supporting > soft-float > on RV64. If no one is using it (and has no plans to use it), then I > propose > we drop it in 14.0 and save one more buildworld from make tinderbox. > I agree. Iirc it was added just in case since some 32bit cores had no fp. Warner > --0000000000007e6c9c05f81453ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 29, 2023, 12:17 PM John Baldwin <jhb@freebsd.org> wrote:
Is anyone using riscv64sf?=C2=A0 All of the existi= ng RISC-V boards include hard-float
support as well as QEMU.=C2=A0 The FPGA cores we use at Cambridge also all = support
hard-float.=C2=A0 My understanding is that glibc doesn't bother support= ing soft-float
on RV64.=C2=A0 If no one is using it (and has no plans to use it), then I p= ropose
we drop it in 14.0 and save one more buildworld from make tinderbox.

I agree= . Iirc it was added just in case since some 32bit cores had no fp.

Warner=C2=A0
--0000000000007e6c9c05f81453ed-- From nobody Fri Mar 31 18:57:02 2023 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 4Pp8fT4Hpmz437Hb for ; Fri, 31 Mar 2023 18:57:05 +0000 (UTC) (envelope-from mhorne@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 4Pp8fT2P9Gz3Ffk for ; Fri, 31 Mar 2023 18:57:05 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680289025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qg7/NiSWO+OuRXGis/E/zOitjtWkGxFlQJfOjETnWYo=; b=xVRnVdDEE7jqNolUdQXbJQw4hG433kLKVB/djKd+nt/kXZf4GpyuoiyKMyQ29oADjLS/DY jHKFE2RLzpxw/fb/7Xm6+UgKznrqp7C6ppwaB8nADkz1qjG4/JAn2SHE8/msAwiRPLgc5Z EjHnVXysYwkFb+xlp6rh+mdPDE9t561ay/lQogtV5ppT62nO4N6ym1Eiw6ypMq/pkloyhs E6Lnh++l7+EZEZAy3Wgq7B/h/lkdnHYfxvi2IrigiqA/9vNfbowKjNfTQosdYIziUPHaLC J6Cl+CEAdt2vPNLiV9sHKJp4z5YtOJAPjPbC5R3Qq+surS1FSc1y0FoGcuWgug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680289025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qg7/NiSWO+OuRXGis/E/zOitjtWkGxFlQJfOjETnWYo=; b=rKb/j90sctW3GTfiR9JotAtjAoi6mDcur+6Re3Sgc2yvLKNejGLpkFB4coPyI/2MCgpZvB vF4Cl5B50/sJw2deF4OBuK1ah2mP+E5CnNEESMSQ9PN4IjneSH/ifLzwINPKSTcstxzV7K g3GsbJMQgYQxsITyVddH33DojAo1KJUx7jEXqWPSBmCGCvH0GDr0A7S4gsEeiMbHMLsyAV R46VMe/WeUWevdBAz9UVvOgv8MLttbl/aXMHW138ruBfcWS1RsTDTKG1SWPja+K9E8hLom ZWn/+x3mk+NSPbEXzqlBsYhmrWEzE0fXxzAUzMADA0SBtIYsD5t3+DjPxkU4Bw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680289025; a=rsa-sha256; cv=none; b=yd0yyxJwKtMj1q3jmlu14Yd+EYtIJJ3SXv7LSb0Sg/hrFrIhjkTSzU+pM1Zx3/Cix7h96Y cixe3x5P+o4cHWCal/b5DssVCGCz06OOh+8VBjktDSJl4gFls2+0nbsw4TZavo/2iOnH5o WGPX9no9GiNb8w6GzQ54sPPa55fnxYeGt2QRDB6+GQO6uW07+xTreNhMHdjAzLuAW8HBQU jXfUndkY3/Bq5cdYTIQgOgHDtL82Vdpt5vTwhHSZcL+qtNHN0WYQ9mPu6kDTyM9FZCx4jl 2ixtJGN2BdbWOnfqDVrOURHT3vVMzV6PuaC4VVnzLQTfVC5zbLlP9j07AUExPw== Received: from [192.168.1.151] (host-173-212-76-127.public.eastlink.ca [173.212.76.127]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Pp8fT0dKQz19jG for ; Fri, 31 Mar 2023 18:57:05 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: Date: Fri, 31 Mar 2023 15:57:02 -0300 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: Deprecate/remove riscv64sf Content-Language: en-CA To: freebsd-arch@freebsd.org References: <629bf85d-4d48-17f5-cb26-dfd29f7e6ff7@FreeBSD.org> From: Mitchell Horne In-Reply-To: <629bf85d-4d48-17f5-cb26-dfd29f7e6ff7@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 3/29/23 15:17, John Baldwin wrote: > Is anyone using riscv64sf?  All of the existing RISC-V boards include > hard-float > support as well as QEMU.  The FPGA cores we use at Cambridge also all > support > hard-float.  My understanding is that glibc doesn't bother supporting > soft-float > on RV64.  If no one is using it (and has no plans to use it), then I > propose > we drop it in 14.0 and save one more buildworld from make tinderbox. > Seems great to me. Personally I have not done anything to build, test, or otherwise verify the functionality of the riscv64sf variant in years. Also I do not recall any questions or interest in it from users or devs alike. Cheers, Mitchell From nobody Fri Mar 31 20:11:14 2023 X-Original-To: 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 4PpBNS45YQz43C9p for ; Fri, 31 Mar 2023 20:15:04 +0000 (UTC) (envelope-from br@bsdpad.com) Received: from mail.bsdpad.com (mail.bsdpad.com [116.202.106.248]) (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 4PpBNR6Y6Xz3R75 for ; Fri, 31 Mar 2023 20:15:03 +0000 (UTC) (envelope-from br@bsdpad.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdpad.com header.s=20201212 header.b=sjYzGRbG; spf=pass (mx1.freebsd.org: domain of br@bsdpad.com designates 116.202.106.248 as permitted sender) smtp.mailfrom=br@bsdpad.com; dmarc=pass (policy=none) header.from=bsdpad.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bsdpad.com; s=20201212; h=Subject:To:From; bh=XjjXMMNUZ9DurBxIslBV6n/aYI1EZTMiPXnAoPnsqjQ=; b=sjYzGRbGGSm7ffiz7fuQkjfSOa 5VTMTnY2ztikUdA7X5GS/Jm1+JccHfVDOBHgfs7HuDMsFNGdw7TwIfqmT6ipf3VdrNw0b4O9gtRmM 3uGAgFJAu9Kg70mUmqpgmZyfPTy4w6HxUDuqXVrTwfCeO/T7Ji2lfsakD13eGEKZquX2wj2SSZPeh HqXQ8+HazSRk2+5c8bTGeLWvEESFx3VF6bT4a4Kbzg8ZKI8J2gmGLj5f5JSee4r9G25Vt+FIR0t5I 7luR3GS03W+oqcJvS7NdPQw7zDD6q6+v0qozPlQNahnW+ukS3lIkbitMQYvogmW2Mr0XW8Jbsd/+E /n5f5eLg==; Received: from localhost ([127.0.0.1] helo=bsdpad.com) by mail.bsdpad.com with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1piL8j-0008ob-FP; Fri, 31 Mar 2023 21:14:25 +0100 Received: by bsdpad.com (nbSMTP-1.00) for uid 1001 br@bsdpad.com; Fri, 31 Mar 2023 21:14:25 +0100 (BST) Resent-From: Ruslan Bukin Resent-Date: Fri, 31 Mar 2023 21:14:25 +0100 Resent-Message-ID: Resent-To: arch@freebsd.org Date: Fri, 31 Mar 2023 21:11:14 +0100 From: Ruslan Bukin To: John Baldwin Cc: arch@freebsd.org Subject: Re: Deprecate/remove riscv64sf Message-ID: References: <629bf85d-4d48-17f5-cb26-dfd29f7e6ff7@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: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <629bf85d-4d48-17f5-cb26-dfd29f7e6ff7@FreeBSD.org> X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[bsdpad.com,none]; R_DKIM_ALLOW(-0.20)[bsdpad.com:s=20201212]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[arch@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FORWARDED(0.00)[uid]; FREEFALL_USER(0.00)[br]; DKIM_TRACE(0.00)[bsdpad.com:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PpBNR6Y6Xz3R75 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Wed, Mar 29, 2023 at 11:17:21AM -0700, John Baldwin wrote: > Is anyone using riscv64sf? All of the existing RISC-V boards include hard-float > support as well as QEMU. The FPGA cores we use at Cambridge also all support > hard-float. My understanding is that glibc doesn't bother supporting soft-float > on RV64. If no one is using it (and has no plans to use it), then I propose > we drop it in 14.0 and save one more buildworld from make tinderbox. > The idea behind this was to support extensibility of architecture (which is one of the key features of RISC-V). So if F,D,Q extension is not implemented, then riscv64sf could be used. It could be that those times some simulators/emulators did not support these extensions, so riscv64sf created (I could not remember). It could be some of new (synthesized) hardware or new emulators won't have support for this straight away. So in research&development perspective it could be useful, in real life probably not for 64 bit. Ruslan From nobody Fri Mar 31 22:28:01 2023 X-Original-To: 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 4PpFKv1HJmz43LJP for ; Fri, 31 Mar 2023 22:28:03 +0000 (UTC) (envelope-from jhb@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 4PpFKv0fPrz3rvL; Fri, 31 Mar 2023 22:28:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680301683; 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=h4NjrtA2O2g2ZC3gHx/m5kYM0xVJ3S6VNJmw0R9lsr8=; b=tHrYTHkcmjbOEdxHMaUImNVTV+GBpTiSuOaIU/tXObSeOYW32SgcpHFto2jaiVAQgtPP4J IDMsRjasYFbYpDHK8aq5zmxbuPN91uuckUHBUwpbSWNXnbNdU2vOtDD2elzEjeif6yaI9D E5vMQl0/Ol+8UZ3X/NCcP0V8pSabUefI2W+3b+gb6d4c12ttqoOJiZ/X7mxBVH1fnSvAdZ fDMu+ZuE9f3gEJkoc/e1Zi8fb5/DyivEhFohM2qXGPmPfbJJuSdnf1MYprzmaKJyxRS/nL 0PYRODg3/G3KOZ2d8mjKS/O3brI8lOCFe5Ih5qQahjBrJOWgRMvOEM4/A9xfGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680301683; 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=h4NjrtA2O2g2ZC3gHx/m5kYM0xVJ3S6VNJmw0R9lsr8=; b=pKiWZ978eWyY/6m9l78JdTjJeOXnFwetLT8bMTrS5ia7/ZhglTpzdlPc8sN2zkzJypXfXY H+poJVTEe9UkHym9Syrho2WBBPATd9nFL8U7v65hOKgEXjxQzOq8EiD/uNUS7V3Hs7HsTC XZhRl295HCFdbSMZEqsjn3Kls8xOkSehJNoAWwxYoMZQN+Qy9m6x9ulOhHXQFCK+noO9xV 5ZHMvegsHjMYFhjmBtXSMMo96udEwcH8fFIwxgulHXyoRAIROVVEqroeVV3BX+HAXLs9/R xCzBX0RO8htK+OMzFODJ8XCN042BY3JBe9w5kuQB/fm7K8ahLwQX2Xk0AGFaFg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680301683; a=rsa-sha256; cv=none; b=rdlQxH0qUMz/rM03Il41oPOT8+3wA6d57poKo0YgpYF0fX/Ov0MydDU6QT8qziaBUIg5Ie FOVMQkr8RWyBFSspy19xyNKZ0k8XyxN1rfQ67Tt6JOBwVfy44pqah8glxcR63pm5N02QLR 9ESu1f9jNEnaUyN7tVQgQboanDPrgWHSqHicMNZA5qb9ze6T4uZuLiOfyPh7TseqnK53bp 0DZcskwu7e91sJDoc4N+VgZsjTB2HkpT26XrYy7Hatpry0tFnCye6WUpjOn/JiIEWISW6p eyIN0KrM+HwJ4uiL6i4qUIPKKs7eq6BucByAaVDneonM4HotRTpyA8xqbDBXTw== Received: from [IPV6:2601:648:8680:16b0:1094:688c:52c:68a7] (unknown [IPv6:2601:648:8680:16b0:1094:688c:52c:68a7]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PpFKt4zRzzFc8; Fri, 31 Mar 2023 22:28:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <0146d3b2-2dd2-0968-4e54-d5afc01c0854@FreeBSD.org> Date: Fri, 31 Mar 2023 15:28:01 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: Deprecate/remove riscv64sf Content-Language: en-US To: Ruslan Bukin Cc: arch@freebsd.org References: <629bf85d-4d48-17f5-cb26-dfd29f7e6ff7@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 3/31/23 1:11 PM, Ruslan Bukin wrote: > On Wed, Mar 29, 2023 at 11:17:21AM -0700, John Baldwin wrote: >> Is anyone using riscv64sf? All of the existing RISC-V boards include hard-float >> support as well as QEMU. The FPGA cores we use at Cambridge also all support >> hard-float. My understanding is that glibc doesn't bother supporting soft-float >> on RV64. If no one is using it (and has no plans to use it), then I propose >> we drop it in 14.0 and save one more buildworld from make tinderbox. >> > > The idea behind this was to support extensibility of architecture (which is one of the key features of RISC-V). So if F,D,Q extension is not implemented, then riscv64sf could be used. It could be that those times some simulators/emulators did not support these extensions, so riscv64sf created (I could not remember). > It could be some of new (synthesized) hardware or new emulators won't have support for this straight away. So in research&development perspective it could be useful, in real life probably not for 64 bit. I think when riscv64sf was added we were less certain about how prevalent floating point support would be for RISC-V. For example, at Cambridge our MIPS cores did not always include floating point hardware. However, I think in practice FP is always available for 64-bit RISC-V cores. Even open source cores for 64-bit RISC-V include FP support. It's true that cores targetted at more embedded use cases might not include FP, but I don't think FreeBSD is targeted at those cores (nor really Linux for that matter). -- John Baldwin