From nobody Fri Sep 22 22:55:31 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rsnfs4BD0z4tZ3c; Fri, 22 Sep 2023 22:55:33 +0000 (UTC) (envelope-from gjb@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 4Rsnfs3hQfz3cC5; Fri, 22 Sep 2023 22:55:33 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695423333; 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; bh=0Owh38q+UrlItL22tijA+QNAcoSoxq1t8DjvtSCYrrU=; b=Cftn3q15A9+ieSkMPMC6wqCV7geDgtN+5ss/ukSfvvFJPf84lWdj+VW98xocN+P1CxFO3d oRBD/q4HvKOpJ5vsnATU2r5UlNiGlokdZ8fiR5soUPdUt1peaBKc38a6eL1KzIt+VaPCyd miktr96sZKr2Ctd3a7Afst9BZ3FSmjEAPaawBPsEUznEy35sxQfRUFnVymHwk7n9V+gm6C 6CWeTYdzv+u/qhqHgvvPLzQpQA23157G48aY/BeCy8eBG0eiZpsGbMu6CqIgXSXOpTNR9p uDIJa4gmaEcWOOGyGD2ApD/uaVK+MShgCmTj2pFsQeysr89t9y+DZ5/mHhLBfQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1695423333; a=rsa-sha256; cv=none; b=tsaCpFBT47wrr8ltmA+34FnfTHERcb85VlB027V5TwIepDXb+hkn3fAtEMbVfyB4s2oB1q kznw7cHjEVm4jX1Z26iBqmwKm6spab7zplXOHYSxu8Nq3Xmuafr/yMcF5SYJOZyefjv8/w 7s5p7zgB+K23+ymMuldWWH76FbIdAhUI79dl8Y1RUBs9wPKhHyDzJK5lOzDAFF3NfpFmcy nwc95ECBeArgAW/tS/Og+ZKscVswPtkUUBKvwN5ayqFUD91M6GUJxNGy85EbLYGsLvzMdQ vef26M8DuGtlMcu6MJQmB+BUQTgEjLmicL+Gmwt3o6rdiB/MrmubVuPSU7vscg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695423333; 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; bh=0Owh38q+UrlItL22tijA+QNAcoSoxq1t8DjvtSCYrrU=; b=TEb2rTHdasJRFHC2rnh2GitaS2CC/6xVoS4Pt+caX4HrImJq1EY3p/o5i9akzoA6O/ZBzz vUaa5iNs6SXz/U+iL7/DgJJvyuFY2fyjn+4FpT8DTqNYEEI4tBCmwvY/wqX3kz77Gngu1Q Ou3KocjDfUkjxGln8Mn5rEzLReRNUZ48z2nNLo1Tg4aiegeuxAb2wXZ8z7I9lGVi/mB0oV nr1XM+tqI4SGEMvdlKCwvUMzjaLHwUSLsjn5wsH9rOanEC7zeB/KZqLjTpVHohjox3CDdo vAOEe84hYqGLlq8VPuhQ1RRvN3ldycIeokVGFYb1nSyf/CETFtUh+LUCWMeOSw== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id F3F8C84FA; Fri, 22 Sep 2023 22:55:32 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 22 Sep 2023 22:55:31 +0000 From: Glen Barber To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Cc: FreeBSD Release Engineering Team Subject: Update on 14.0-RELEASE Message-ID: <20230922225531.GT1219@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A/2QVx3Okwt4+LIK" Content-Disposition: inline --A/2QVx3Okwt4+LIK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline We will likely need at minimum a fourth BETA build for the 14.0-RELEASE cycle. As was just announced, BETA3 is now available. There are some known outstanding issues: 1) freebsd-update(8) has previously failed to upgrade from 13.x and earlier due to a file name that had been replaced with a directory of the same name. A patch for this is under testing. 2) FreeBSD arm64/aarch64 EC2 AMIs have been failing to build properly, presumably due to lang/rust build failures leading to the ec2-scripts package from being prevented to be available. The last 15.0-CURRENT snapshots seem to have this resolved, so hopefully it is also resolved for what will eventually be the 'release_0' package set for 14.0-RELEASE, but that is still over a week away. 3) There are no "official" FreeBSD base packages available. I have been occupied with external factors preventing me from having cycles available to look into this without interruption, but I think I am going to err on the side of caution and have a manual package set run available via https://download.freebsd.org/ somewhere within the version, architecture, and machine type namespace. 4) Vagrant images fail to upload due to an incorrect target following the addition of ZFS images. This is another issue where I have personally been blocked/blocking progress. 5) The 'ftp-stage' target does not currently account for ZFS virtual machine images. I again have this in my queue. I do not know if I necessarily care too much about this for 14.0-RELEASE, since all virtual machine images are within the 'Latest/' directory namespace for all builds, but I am intent on fixing it. 6) The ZFS-root EC2 AMIs panic a few seconds after booting, apparently due to memory corruption in ZFS. Note regarding (3) above: this is not yet done, but the datasets in which the builds were done are preserved. I hope to have at least a few hours this weekend to try to get binary packages for the FreeBSD base system in place, wherever that ends up being. Glen On behalf of: re --A/2QVx3Okwt4+LIK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmUOG2MACgkQAxRYpUeP 4pOPCw/+K8Lod6s+bzgmP08Ata8Ag1VNqpVMhiiMQfhBplChUT3kahJuA9Pbucxq 7w6CEemCJOYm2xeQ7RsesnAl3qvrxOVT9P4/z6zBw737/DMyMy0VgAwNNua9Rn4m iFJrqfohMjPyoiq76N6MM6fN8LzXE8GWo/qAmY/2Z5IA4h78NdUAvT4TieqQl8bB X8exhMMlE0C+C0cA5CXC35urNYsZFDIvrdSF3ps5NORard41md0p+EL8lL/Tsd9N FgtPjeX4fhpuoMaNtXPLSPz2DnMfnzkvvmgC+pQrBJS4CoA7gQ3ibT6x11Ams+gC /qBBwP69i252J7EEHfrpSKOfK9iedMW9x54Ay7MlLUc6n03z8d1dSfptNuTKUBuw RsfCbpCO9HxkyXJGJWQc8Z7dmFhy5l1qYL7djA8B7APQag2kH+BwY+x9lE/Rsk2W Wf9OAFTifMsJKLrYd//HRgRwr9Ldf0zywXIuCqFo8NVwNI7WmcL9rx7avfJ4gqB0 y5GGhK5UaVANe6D4FXqvFa7270T0CL+J51jI7HnY9FmJ3MevhvjRhptr7pcmMpty Lw1HYAcYhTuBEcOWmE00t6syONLfDzlqgbJbIKbOWjm2aBE+GmBcoOW2WckQ7kHr yEpsE5hdrtjSAjWw7EV+5LHwbxpu7Adf16ubodTDCHPPIw4X67U= =967b -----END PGP SIGNATURE----- --A/2QVx3Okwt4+LIK-- From nobody Sun Sep 24 00:00:37 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RtR3V0f66z4vRys; Sun, 24 Sep 2023 00:00:38 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RtR3T4wPPz4Ggw; Sun, 24 Sep 2023 00:00:37 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695513637; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=uxm8M3vDBP5+TYcFpoGJwp4tMFUO7XjSZkedYQJCFpg=; b=kx1vpSsp6Dc9g9ItLQiKX1v+Tjr1HdwqVUNhqLWmXHwDwquLXwIXoy6wfWgU6Y2oGMT8+Z hz6A/3mvT4xx7A8DPFW9eeHXyOEv5byQ4FJu8nGe46eeTNYb9OzLUU0Qz3B66RLfOkynEC FUZ7SvSoaLtvFnq5g95Y+7SiBo92YGiUIzGe/0kmwyywRN/+h3rTOovHDkVLwUEwB2n4xZ zayhuBNC5GvLEdDHaRMj+uz6v2S73xrRbmO/HyYtU+sOnN75zV6+K1VACgrIfVX1jPiJkM LY7Z420rVdjzrct76LX7Mx+c9OPss9gRf4zPt9omet4KpKGF0clishC7BGhFRA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1695513637; a=rsa-sha256; cv=none; b=WlY5CGcdEqupA6KgY8WhpB+y8e/BaptEt4W3Aq8FgPTQ6GoM5Hpu8KfpqgqATQhYeqQFS6 Xm8PY5ZY5kvUJuLjh8rWKxrauAOof98Bmv8xi8w5E7/w68gC6ut1gmZCQ3w66keJSV5RPV 0gdrJZn4xlmApvx0B4/ul7CUHC2gRJWpEivb6Ka6EH2AmKL9vhYOQU80qmaMzLf9YHP8m+ FAI2iyodfkVXDb3540dLfnwG4NkJAzu3+1yeePVa5ZE/26Z6bzgpl5YYar80z0/j8bwjND tMzNJ24E5lApMqzYRUSHEticM9VG4DidpBIzYMDFHoBHqYHPalIUsjM3HabbMg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695513637; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=uxm8M3vDBP5+TYcFpoGJwp4tMFUO7XjSZkedYQJCFpg=; b=yTPTJqOXjPeUQl9bDiT5755eztummCmJvQIVRw7UXhCx4tgTStURcIntydanX8U5OgY2Tb CP8fK/Y34Ussg3QPQR4XnfYH6mzQKrzpQ5gqkfyQF7cDA73XkB27Uv5f9dJSzArxTKlut8 uDJrEIhFi21SjD9RC5RgpX2Ar0uxD/pghVHAvApBA4sKzf6Y/XE3KwX+lyoPYCMhISmOdG 2JoR8Ce3u0ZNfrWrJ/pQJpT+eBdzmAzdWSsvYnPETiDjCbQCe8W/q+0hSpOgJBG8NfyaHq g/q9ZoJV3NijRX3ogn8PUNFM/HEH2Y7kHylFtqaRWLVZQ5NBgWmOX8Loxy/Qsw== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 90221D97B; Sun, 24 Sep 2023 00:00:37 +0000 (UTC) To: freebsd-status-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2023Q3 status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20230924000037.90221D97B@freefall.freebsd.org> Date: Sun, 24 Sep 2023 00:00:37 +0000 (UTC) From: Lorenzo Salvadore List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is September, 30th 2023 for work done since the last round of quarterly reports: July 2023 - September 2023. I would like to remind you that reports are published on a quarterly basis and are usually collected during the last month of each quarter, You are also welcome to submit them even earlier if you want, and the earlier you submit them, the more time we have for reviewing. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The following methods are available to submit your reports: * submit a review on Phabricator and add the group "status" to the reviewers list. You should put your reports in the directory doc/website/content/en/status/report-2023-07-2023-09/ (create it if it is missing); * submit a pull request at . You should put your reports in the directory doc/website/content/en/status/report-2023-07-2023-09/ (create it if it is missing); * send an email to status-submissions@FreeBSD.org including your report. An AsciiDoc template is available at . We look forward to seeing your 2023Q3 reports! Thanks, Lorenzo Salvadore (on behalf of status@) From nobody Sun Sep 24 17:41:30 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rtv9h5tn9z4vGQw for ; Sun, 24 Sep 2023 18:07:36 +0000 (UTC) (envelope-from csgordon@fastmail.com) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (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 4Rtv9h0fmmz3c4n for ; Sun, 24 Sep 2023 18:07:36 +0000 (UTC) (envelope-from csgordon@fastmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fastmail.com header.s=fm2 header.b=b5Dp8Pqm; dkim=pass header.d=messagingengine.com header.s=i60c149f6.fm2 header.b=RBm+LdF1; spf=pass (mx1.freebsd.org: domain of csgordon@fastmail.com designates 66.111.4.224 as permitted sender) smtp.mailfrom=csgordon@fastmail.com; dmarc=pass (policy=none) header.from=fastmail.com Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 961AD58196C for ; Sun, 24 Sep 2023 14:07:35 -0400 (EDT) Received: from imap53 ([10.202.2.103]) by compute5.internal (MEProxy); Sun, 24 Sep 2023 14:07:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t=1695578855; x=1695579455; bh=Y23BzQuLBU1JsuwNZhrGwv2h2 04zoL0QNsdGmw0QhKw=; b=b5Dp8PqmFnuPba5t0DBeoTvLieU3rav73NC8aRoLf mo23+QBnb9Esckhf8tRq8FkELRnIbCgs06k2XBqsXZEXTQn14usEEoB7K8r817e1 6OlQgTPd2tJzc81Jm+9oHhSEhkPxqmq9LKUQq1f+pO7FMXNEyNXW8TH0FyZIhTxa a1k1BBEKldQnpD7PqHLezlBB8vTWMtXrusojCSiVFV6YAMm3lkz9mqUhljC6m5BK /xx76ipSfei77P89FcAfod/lVKHC6C01cNn1jlwbctFDhXZFR4jrnV/hpUXozS7g HibnO/kGffShcnf/lg5Vn2uVuU3bSIoMtv6yOgPjCEDUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=i60c149f6.fm2; t=1695578855; x=1695579455; bh=Y23BzQuLBU1JsuwNZhrGwv2h204zoL0Q NsdGmw0QhKw=; b=RBm+LdF14J+k20P82wEFeiEmA8xe2WIu+EiqYvUeixVbEZg/ iNLuSpB6FDlCYi+oEiWRwzsYcgp8uBc66iqXVP8SzaEVhFXDu+PGDj+yCBFf4nS2 E4WpIqGO0KSuuRE6/TPnnz2VN7+jEqb5Fh+TEL2n39y33MWp5FHFYHuLHn13HIL6 IOPTLQJFdf/DhqSiQn6RaR6omHL65jbv48NkONgF9zR6HdrfKTcCixlKDDTdwV1Q 6K4o5Sd3ESwMnsUv8DgyV5FErcwHDmBLKXLdJOJX+dVhPKBS/ibOiKaQ768a5OYF iC4ULMC8zVlaQbB5ueLgxcU4Kipomd85YsINaQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudelvddguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreertdenucfhrhhomhepfdevohhlihhnucfurdcuifhorhguohhnfdcuoegtshhgohhr ughonhesfhgrshhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeevkeevleefgf ekueeuveekkeffgefgieffteekhfeutdelheefudeluedugfegteenucffohhmrghinhep fhhrvggvsghsugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegtshhgohhrughonhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: i60c149f6:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 338E2364005C; Sun, 24 Sep 2023 14:07:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-761-gece9e40c48-fm-20230913.001-gece9e40c List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-Id: <1ee70bdf-828c-462d-bf1c-28d10cd7e903@app.fastmail.com> Date: Sun, 24 Sep 2023 13:41:30 -0400 From: "Colin S. Gordon" To: freebsd-hackers@FreeBSD.org Subject: Finding git commit corresponding to 13.2-RELEASE-p3 Content-Type: multipart/alternative; boundary=bac917373e9c40f4972f9708e55be000 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.09 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[fastmail.com,none]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.224:c]; R_DKIM_ALLOW(-0.20)[fastmail.com:s=fm2,messagingengine.com:s=i60c149f6.fm2]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.224:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[fastmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[fastmail.com:+,messagingengine.com:+]; FREEMAIL_ENVFROM(0.00)[fastmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.111.4.224:from] X-Rspamd-Queue-Id: 4Rtv9h0fmmz3c4n --bac917373e9c40f4972f9708e55be000 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm trying to debug sleep on my laptop, but have run into trouble reprod= ucing the problem with a locally-built kernel, which I suspect is an iss= ue of me not getting the right version of the source for what's currentl= y running.=20 Can anyone point me in the right direction for what commit 13.2-RELEASE-= p3 was built from? I neglected to install the source component during my= initial install, so cloned manually. I've tried a few different commits= , including initially HEAD on 13-STABLE, and more recently a build of 86= 6e5c6b3ce7 from stable/13 (based on https://www.freebsd.org/security/adv= isories/FreeBSD-EN-23:09.freebsd-update.asc). However the builds I've ma= naged to produce introduce an additional failure that masks the original= problem. On 13.2-RELEASE-p3, my machine goes to sleep, and partly wakes= up before hitting https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D2= 11705#c3 on a laptop whose only storage is eMMC, in particular with the = screen coming back up enough for me to see the failure from sdhci. On al= l the kernels I've built locally, the screen never comes back up, so I w= ouldn't be able to see if changes I made had any effect. (There's no act= ual serial port on this machine to debug with another machine.) So I now want to find the commit corresponding to exactly the kernel shi= pped with (amd64) 13.2-RELEASE-p3, so I can =E2=80=A2 Verify that I can actually reproduce the exact problem on a l= ocally-built (so, modifiable kernel). Otherwise there's something wrong = with my build process, I guess. (The kernels I'm building boot and run, = but have different behavior when I try to resume from sleep compared to = 13.2-RELEASE-p3.) =E2=80=A2 Debug bug 211705, and =E2=80=A2 Binary search changes to see what commits might have altered = the resume behavior on my machine (which=20 I'm happy to dig into the problems themselves, but I really need to find= which git commit to build from, and I'm having trouble finding this inf= ormation. I'm sorry if it's posted in some place I haven't managed to f= ind, but I'd appreciate any pointers (both to this specific piece of inf= ormation, and how to find it in the future for other scenarios). Thanks in advance, Colin --bac917373e9c40f4972f9708e55be000 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi,

I'm trying to debug sleep on my laptop, but have run i= nto trouble reproducing the problem with a locally-built kernel, which I= suspect is an issue of me not getting the right version of the source f= or what's currently running.

Can anyone po= int me in the right direction for what commit 13.2-RELEASE-p3 was built = from? I neglected to install the source component during my initial inst= all, so cloned manually. I've tried a few different commits, including i= nitially HEAD on 13-STABLE, and more recently a build of 866e5c6b3ce7 fr= om stable/13 (based on https://www.freebsd.org/secur= ity/advisories/FreeBSD-EN-23:09.freebsd-update.asc). However the bui= lds I've managed to produce introduce an additional failure that masks t= he original problem. On 13.2-RELEASE-p3, my machine goes to sleep, and p= artly wakes up before hitting https://bugs.freebsd.org/bugzilla/show_b= ug.cgi?id=3D211705#c3 on a laptop whose only storage is eMMC, in par= ticular with the screen coming back up enough for me to see the failure = from sdhci. On all the kernels I've built locally, the screen never come= s back up, so I wouldn't be able to see if changes I made had any effect= . (There's no actual serial port on this machine to debug with another m= achine.)

So I now want to find the commit c= orresponding to exactly the kernel shipped with (amd64) 13.2-RELEASE-p3,= so I can
  • Verify that I can actually reproduce the exac= t problem on a locally-built (so, modifiable kernel). Otherwise there's = something wrong with my build process, I guess. (The kernels I'm buildin= g boot and run, but have different behavior when I try to resume from sl= eep compared to 13.2-RELEASE-p3.)
  • Debug bug 211705, and
    <= /li>
  • Binary search changes to see what commits might have altered the= resume behavior on my machine (which
I'm happy to di= g into the problems themselves, but I really need to find which git comm= it to build from, and I'm having trouble finding this information. = I'm sorry if it's posted in some place I haven't managed to find, but I= 'd appreciate any pointers (both to this specific piece of information, = and how to find it in the future for other scenarios).
Thanks in advance,
Colin
--bac917373e9c40f4972f9708e55be000-- From nobody Sun Sep 24 18:59:25 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RtwKl4sydz4vKNJ for ; Sun, 24 Sep 2023 18:59:39 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RtwKl0Rblz4FWK for ; Sun, 24 Sep 2023 18:59:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-80-101.area1b.commufa.jp [123.1.80.101]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 38OIxQYM092740; Mon, 25 Sep 2023 03:59:27 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 25 Sep 2023 03:59:25 +0900 From: Tomoaki AOKI To: "Colin S. Gordon" Cc: freebsd-hackers@FreeBSD.org Subject: Re: Finding git commit corresponding to 13.2-RELEASE-p3 Message-Id: <20230925035925.23d0af28ceebb744705aa804@dec.sakura.ne.jp> In-Reply-To: <1ee70bdf-828c-462d-bf1c-28d10cd7e903@app.fastmail.com> References: <1ee70bdf-828c-462d-bf1c-28d10cd7e903@app.fastmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4RtwKl0Rblz4FWK On Sun, 24 Sep 2023 13:41:30 -0400 "Colin S. Gordon" wrote: > Hi, > > I'm trying to debug sleep on my laptop, but have run into trouble reproducing the problem with a locally-built kernel, which I suspect is an issue of me not getting the right version of the source for what's currently running. > > Can anyone point me in the right direction for what commit 13.2-RELEASE-p3 was built from? I neglected to install the source component during my initial install, so cloned manually. I've tried a few different commits, including initially HEAD on 13-STABLE, and more recently a build of 866e5c6b3ce7 from stable/13 (based on https://www.freebsd.org/security/advisories/FreeBSD-EN-23:09.freebsd-update.asc). However the builds I've managed to produce introduce an additional failure that masks the original problem. On 13.2-RELEASE-p3, my machine goes to sleep, and partly wakes up before hitting https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211705#c3 on a laptop whose only storage is eMMC, in particular with the screen coming back up enough for me to see the failure from sdhci. On all the kernels I've built locally, the screen never comes back up, so I wouldn't be able to see if changes I made had any effect. (There's no actual serial port on this machine to debug with another machine.) > > So I now want to find the commit corresponding to exactly the kernel shipped with (amd64) 13.2-RELEASE-p3, so I can > • Verify that I can actually reproduce the exact problem on a locally-built (so, modifiable kernel). Otherwise there's something wrong with my build process, I guess. (The kernels I'm building boot and run, but have different behavior when I try to resume from sleep compared to 13.2-RELEASE-p3.) > • Debug bug 211705, and > • Binary search changes to see what commits might have altered the resume behavior on my machine (which > I'm happy to dig into the problems themselves, but I really need to find which git commit to build from, and I'm having trouble finding this information. I'm sorry if it's posted in some place I haven't managed to find, but I'd appreciate any pointers (both to this specific piece of information, and how to find it in the future for other scenarios). > > Thanks in advance, > Colin IIUC, each -p* build is done at the point when update for "BRANCH=" line in /usr/src/sys/conf/newvers.sh is done. So you should track the commits to /usr/src/sys/conf/newvers.sh on cgit [1]. For 13.2-p*, track releng/13.2 branch [2]. You can find commits 525ecfdad597980ea4cd59238e24c8530dbcd31d for vanilla 13.2-RELEASE 08b87f63a046bd966bd0ed548211ae98ff50e638 for -p1 4341433a673fde3e1c1554b9daa15d4db71f6edb for -p2 and a1c915cc75c1b3c66e16bb52579e2abdf122eccb for -p3 individually. Next, to be sure enough, go to [3], select releng/13.2 with the drop down menu at the top-right of the page and push "switch" button at the right of it, switch "log msg" to "range" and enter the wanted commit hash and press "search" button. You can find all commits to the branch until the commit is done. [1] https://cgit.freebsd.org/ [2] https://cgit.freebsd.org/src/log/sys/conf/newvers.sh?h=releng/13.2 [3] https://cgit.freebsd.org/src/ -- Tomoaki AOKI From nobody Sun Sep 24 19:16:36 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rtwjf0DNsz4vLZY for ; Sun, 24 Sep 2023 19:16:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rtwjc5cMCz4HXl for ; Sun, 24 Sep 2023 19:16:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fAffs0K6; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1695583011; bh=FfV56FtaVUFeqFCoz/u3zUHF5FBJoMF8YCRMc5oxR0w=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=fAffs0K6CGRFSkWlPQCEz8gVVyLWjJtvVIT42DAVQo0RAuu2jzvwtlnbu2peJashs9mD5o3KhOe60ZdGzWiT1auFZjFbx7gNC+joZz254we9KDevg1gNybgSUD8N4VmGPPIdw7qBzhZ79Vx+RPcTE6Et95dEtNx2MSBKlIAA+UF7n7iFz8Xmst9C0Iodxs+u+NCyYlPDLDWYuo8D71kehRjK9oXIu06AIioptKERfEL59FCcc4pnswicRB5Sn1SRVJCTBOz7CSUyJVBOvuHxp6aa9FHJaLPoWYKm74YW3DVPm7L9TFF01u70PATx6CxFmI+o4XUHfYbj1bbzqX2fLQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1695583011; bh=nryxExJDZDfelPuBszrQ3aEKQnOOlOp5mySX3BWRQlR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Atb+LUcJLBg//CGUB06Z4tIGQ7JOiUAnkqvkaf0zXtknqwjC7+Kd/VU77m5AtHoMn6NQIniiW2nq56j108Y6LJDRclpY94ljrTg8AKn84C95+7aEziCy4E8mf5i4Awm5WMBYT5p3APAsfYuaR2/4MBGW/zSmeUCapuALYbizM+UCgizfLrtmYx1jSR9KH0idvcd7BsENL9ce5MvTDaVKr/nbMliTPyammgXp5RQU+SCjt/bdBPqglpJQ/reYlWUek3DYQGi+1zamOMf4lKzscWn9QaxtvD5an4ckgHPoDKL4kcAZ7R+1L/YtnN40DPDIbnmD3d3+NfRkJNjQJnLx1Q== X-YMail-OSG: 5mGK9wMVM1n_B14Bkyffz4fd7EEOuzLHYPkgeoat24pPBAHamZaDir7HdxVEVzB XEBng7bQrI4QprfCuRTmwT5at8WbY8wLmkvlw0OA89W631DVfIDA7Bem8dCXwNVHzxiOi2oZ5ADh D9xm9_0AA99YJZOcPyBOWu_PM8q9jJ8DHR3cOTCnotOaIB4K7Cvktq55dXwkwZIxznA_dN3wMCxf ThGtzuSqQLGCuF2HW2b3BsKq41adPfzmhLLmPbo3K2VLTR0M3Kz2wsQLaZi26Jo6CUPAAjEKZ0J6 209s3HtIMVBhwDtCA7xPPF9iHrcJH9QuEyZFY2TgI2hTPEE3yUOYyFyQkU_h6aIV_gboSDEU.vfx TwcuhAjchuC.4EjmmHz4MWJ_5WT1R5dLxgHgVGvFLiGH0z5ISYOuQA94tTwWD0BFr6XudmhZPy9M tMujo.Gxswk8gxObn7z53gcSj_.LAmPXAIlm7xandidM.w.tuxtsawtl4EnG4XIh_LGPhioQ_LBH zhLaGn7NyMV5Q7jRBT76XwUMNixa6bofNI7uFX.T39IY26cD.GzD_gEydG5srjNgKTiLil1gUQMy XdsaeVHzdMgjKkkrPDly4RjVHlfHj6sw1FLAn7ff3EQea9QTF0RTqFNmrHdT7YnUUtJYiAJDQiZz 896rBZxHqX_G3cRk6IJB0CQDyTt40kYVpTnb6248BypGKjs8Doh3J2NWwzap5rxdPQEScXEELhxs kLwEp0vhmyDm3MOkAXTVTrVWkMjLEs1L9ySfzZwsJIIWUGCoAZJWswKzEnF8prLdNqCz6UhEwmok LZGh4bkrzy4QFLu_SCwX1vw.4r8UU8o6ykheA0Yk2HYL.4DnxFSTe6i29MFg7Ns8or8Bi3e0M3j. LCe7BCUOo_L5OiGUc5pa45RmsycU3ajLWlbeQSrcUZZ2itAhGHcKMuXbZiXx76.yMbF6YFDMdnxG LwtS4XVKk_eU_KVWmRShB.dn9w7qgA6FI4QuHrvKPcYaAn3SN30feXLV.wdzuvn7.Cw21rUsxivw 62mbfK1M.f1D93VwZioe6KCb.i4PUGOCmhItW.vgGGklnwh2YmMZ0lOydi8yCbXp.M5u92gY7JLr 9cf6neqb6ajIbnLf7qUZqVemAwk5ynrs1wI5Rms6g0f5kfIE8pQZWYduaHd5LfsVzVP8Wl6VIlDi lENa7yX9re8zWB0rA6fFCQ0DBNYuh5297_wbin_MrBakHE22FRl_O3iMJgq6.AfPuBaqzMO2Rd_G fEgMAZUBy910y6TX7Qx8ZULzKTbz9.xx0DELyR367SVBmCMdhmre11l8FFIX_YhQ2I8tcpjQBFmu h0V4wV48BuenFy.IvZ23qWN3H3UWQZr7.Gyzmo5FVX8c1A8O9.P9qNpgNJmSFsTqnWmuUI5Pe98b CuM9lAAMseJeV21L7_vbEN0D5P1OMA0iZuR46SnSGwJc6eegn.hmgy6nlT2rkhfXoZ_Pk2YV60PC BVBaM82MWERa_lpy8EUNc4da7ozTCrGmqgWVIVyDL_rQOr6Ya4Go.nd8jhxClOSed9rTjlrmdRQM QUd6qESh1rtm5zDZuYKD3HJyDiYR7qpynnhWlU9Nf6BxcGNTA2We8shuMxOxHDkINa3bt2_4um6w jnT5ClQ7rLy3OcJlyGBC_1ujNh6_QV_djVKEIdKpePDIOuKNc9x4plF61b0qoAYfUcRtBWwr0aZQ _XX07U8yP7XnUV46S8bnfHHcxHeS5fWR49Z44hY_6TTNq6ftBN1f3o9CoHSerBVbEHB6XPwQBOl6 zgVhi1vA0VqkCtDsfUCwMw7TB2fNifYG.O_J.lYosvqziPaeFVEl0nb_lRimkvL3m97gxlm3No53 quVKgDfvjkDJRoXQdiPIE6zAh8QrCt3.mAK2iAWozk7ipVuIIFB4MuwXCYNal1LGiPcgZR_tZXUj z28V20L9aDOWS2Q7Ht7q5exhRsSH7ZQ7PSuAo3FV2Q.5QPRu1jK.lMJ6coQIJX4rLjztDzZs_Bp. 9F5UZXQt0HYbsuaKc06mYrEPt7kg5UGxjs.xgQ.b34flmQaLSdGSkBdzCeMsaIt35DoRodA9jKKM a2Z2Ifko_7DnN4QO_LTCNEtSTUAq.CFu2YPo429dwNinHQyuPy7UANSpUeP28vUXvuOhduLNvw4e nBxczM55xf0e_cKaxuak5UJlNKRbw6QJMhYQfX6HiIEVKgiQPwlNxAS1yvZZ5PxE6ZtOajIDdq2i iyANZwRThbwNQqUevSolf8C2RZQ3UYna7i_GkbJb9ZwrSiL2qCBkWR3tS3Y3x_rXFCSz3GhXnrA- - X-Sonic-MF: X-Sonic-ID: 966cd3a9-6216-44b8-900a-41e56254a75c Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 24 Sep 2023 19:16:51 +0000 Received: by hermes--production-ne1-6cbd549489-k2llt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ffafe6e3ac392f03a4611aad38a78631; Sun, 24 Sep 2023 19:16:47 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Finding git commit corresponding to 13.2-RELEASE-p3 Message-Id: <722B12CE-1809-4117-89FD-76D1F811DE71@yahoo.com> Date: Sun, 24 Sep 2023 12:16:36 -0700 To: csgordon@fastmail.com, FreeBSD Hackers X-Mailer: Apple Mail (2.3731.700.6) References: <722B12CE-1809-4117-89FD-76D1F811DE71.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.28 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.78)[-0.779]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[fastmail.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Rtwjc5cMCz4HXl Colin S. Gordon wrote on Date: Sun, 24 Sep 2023 17:41:30 UTC : > I'm trying to debug sleep on my laptop, but have run into trouble = reproducing the problem with a locally-built kernel, which I suspect is = an issue of me not getting the right version of the source for what's = currently running.=20 >=20 > Can anyone point me in the right direction for what commit = 13.2-RELEASE-p3 was built from? See: https://cgit.freebsd.org/src/log/?h=3Dreleng/13.2 and its commits with "bump version" or the like in the description. In this case, currently the most recent commit is for -p3 : = https://cgit.freebsd.org/src/commit/?h=3Dreleng/13.2&id=3Da1c915cc75c1b3c6= 6e16bb52579e2abdf122eccb It includes the change (leading whitespace might not be preserved): diff --git a/sys/conf/newvers.sh b/sys/conf/newvers.sh index 85d2cb24a37c..31ce004e1417 100644 --- a/sys/conf/newvers.sh +++ b/sys/conf/newvers.sh @@ -54,7 +54,7 @@ =20 TYPE=3D"FreeBSD" REVISION=3D"13.2" -BRANCH=3D"RELEASE-p2" +BRANCH=3D"RELEASE-p3" if [ -n "${BRANCH_OVERRIDE}" ]; then BRANCH=3D${BRANCH_OVERRIDE} fi Looking at the releng/13.2 branch at around where the sys/conf/newvers.sh changed normally lets you find the commit used to build the 13.2-RELEASE-p? of interest, typically at the commit of the sys/conf/newvers.sh change itself, but possibly at something just after on that same branch if a last minute handling of an issue came up and was adjusted for. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Sep 25 13:50:05 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RvPQ73Ssdz4rMRP for ; Mon, 25 Sep 2023 13:50:07 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.inria.fr", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RvPQ64ZdZz4PW1 for ; Mon, 25 Sep 2023 13:50:06 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=inria.fr header.s=dc header.b="q/wghIKE"; spf=pass (mx1.freebsd.org: domain of Paul.Zimmermann@inria.fr designates 192.134.164.104 as permitted sender) smtp.mailfrom=Paul.Zimmermann@inria.fr; dmarc=pass (policy=none) header.from=inria.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:message-id:from:to:subject; bh=HDNosylXZBtpUXX16UAuamajfzKkkC13ZlYgAJUGS5k=; b=q/wghIKEBUuCj6fgfaZB8/mm3lhRNfKzDaytAEK0Lq4Vwc3b5yB62b26 iAWZu9UXRahfLHnYEJ+Dct5KvHdyOYsW0pgRZW+v6TzMoSMdaU+xeUqEY ea/I76WbfY3+D11kIh+bFitw53FZI+Z0lwsi2GboyRLjR6BcLj858CKkB 8=; Received-SPF: SoftFail (mail3-relais-sop.national.inria.fr: domain of Paul.Zimmermann@inria.fr is inclined to not designate 152.81.9.227 as permitted sender) identity=mailfrom; client-ip=152.81.9.227; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="Paul.Zimmermann@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail3-relais-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@coriandre) identity=helo; client-ip=152.81.9.227; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="postmaster@coriandre"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="6.03,175,1694728800"; d="scan'208";a="66888172" Received: from coriandre.loria.fr (HELO coriandre) ([152.81.9.227]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2023 15:50:05 +0200 Date: Mon, 25 Sep 2023 15:50:05 +0200 Message-Id: From: Paul Zimmermann To: freebsd-hackers@freebsd.org Subject: Accuracy of Mathematical Functions X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[inria.fr:dkim]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[inria.fr,none]; R_SPF_ALLOW(-0.20)[+ip4:192.134.164.0/24:c]; R_DKIM_ALLOW(-0.20)[inria.fr:s=dc]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[192.134.164.104:from]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[inria.fr:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:2200, ipnet:192.134.164.0/24, country:FR] X-Rspamd-Queue-Id: 4RvPQ64ZdZz4PW1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Hi, I hope this is not off-topic for this list (Technical discussions relating to FreeBSD). We have updated our comparison: https://members.loria.fr/PZimmermann/papers/accuracy.pdf This new update includes for the first time the FreeBSD math library, whose accuracy is quite good, except: * single precision: the Bessel functions, lgammaf, cospif, sinpif, tanpif, powf * double precision: the Bessel functions, lgammaf, tgammaf, cospi, sinpi, tanpi, pow * double-extended precision: erfcl, lgammal, tgammal, cospil, sinpil, tanpil, powl Some issues have already been fixed in the development version by Steve Kargl (we used FreeBSD 13.2). Best regards, Paul From nobody Mon Sep 25 18:20:25 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RvWQP1FsQz4ttCx for ; Mon, 25 Sep 2023 18:20:45 +0000 (UTC) (envelope-from dim@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 4RvWQP0dwPz3J46; Mon, 25 Sep 2023 18:20:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695666045; 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=gjIsEQ5J+A25eUjbgtypvExcRt5RlUpdUUCrB96Dapo=; b=Zs2iSD+awEWiIxcdCfNimj5YXFFNEk+xEmI/sLTRz8YmdL29iOLrd2AE8IewAITsgEfuuy T7tS5wzC0FLfrAPjlaPgpN+gDvtSxcbPVlNPzEj7TllRvk2g1mUs61aYnvKo8gWmRW/dO8 bq0xeyGW3+pejdlH+6wXxf9e8UZWgx1mrmQHTpAsLWugyNRfzkOLLRpEiVfEbUsy5KLjtM MQikG4mKr6+Wd0oQKSZaeJjKNKCX5jlMfEdCJgqcMiYEiGp0GGsz/FFKonRN3Cx9BUScPw qOCkNqHzHv2T5gZWylXVFexlLEdVa3RaTaQ2vcBsp4TpgJ8B4k+sM7V/EVZvOw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1695666045; a=rsa-sha256; cv=none; b=k+ePR1vJOAFUD2T3Zkuyol5BlGkrzYWuHmXGg/+f8ZbwsvETna5ib3Nsiqa1NwfyOxzMr9 bE7uzGoQ0NhPogn8zvbHJ3QF5lHA05+U5Pweh6G9zBcsZxg52Oy0/BIMIa9aKsgVwIqlIQ yjq474GXc2UnnYrW6x1fd/1xmM3MVzpYjzJJJrG90U8VLLT4PIih2Eywr7XJvn9wXmTVVN I6+IL0mxhDzRsGWnlQlK3/1rZhFEKOvcT1NqG1ToHtptU1EWT0jwfqa8Od3VMCrIqaANZ+ 9ZPeF+W3g8oXN0ZzQrIZFye2+LgdDgeIneQa7IxF71MLVtlG7GcE/399x5WX4w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695666045; 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=gjIsEQ5J+A25eUjbgtypvExcRt5RlUpdUUCrB96Dapo=; b=rHnF/p5FEN49Sqa/a+94sIDX1yr4qlf1YDnFG2f2j2SicWUtVwXp6VyCRg/e5mHvsEA01Z 7GvbQuwhCY/ntUlUsSHplt/0C/wt7VZdbdhgecnD04MYFtrfcgfNbNsdJBH06bTTMIfw2O KVN6tnIZEEVa6wBLAKgrMPJuOl+aaAqVQ3QsqP4PJCaRWRN6aXwih5w+hfJoUeKC77NAHE DBFGUYFkMEwQKKgxmpVkSzSYn8ZUF1ujk3vPldetqmcrklx7GBn2uIcxfrvkLyFrycOVr2 wcUEZTT6uPdQj2E5WPqjWXiOtu1aoNXXzLvI6rzejISpDz6w5uk0zbsUOl9nTQ== 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 4RvWQN5zH0z1Ksw; Mon, 25 Sep 2023 18:20:43 +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 AE7422ADAA; Mon, 25 Sep 2023 20:20:42 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_24E27A91-7539-491E-A37D-966F2689EC15"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Accuracy of Mathematical Functions From: Dimitry Andric In-Reply-To: Date: Mon, 25 Sep 2023 20:20:25 +0200 Cc: freebsd-hackers@freebsd.org Message-Id: References: To: Paul Zimmermann X-Mailer: Apple Mail (2.3731.700.6) --Apple-Mail=_24E27A91-7539-491E-A37D-966F2689EC15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25 Sep 2023, at 15:50, Paul Zimmermann = wrote: >=20 > I hope this is not off-topic for this list (Technical discussions = relating > to FreeBSD). The freebsd-numerics@ list might have been a better match, but it receives very low traffic, and the audience on this list will be larger. > We have updated our comparison: >=20 > https://members.loria.fr/PZimmermann/papers/accuracy.pdf >=20 > This new update includes for the first time the FreeBSD math library, > whose accuracy is quite good, except: >=20 > * single precision: the Bessel functions, lgammaf, cospif, sinpif, = tanpif, powf > * double precision: the Bessel functions, lgammaf, tgammaf, cospi, = sinpi, > tanpi, pow > * double-extended precision: erfcl, lgammal, tgammal, cospil, sinpil, = tanpil, > powl >=20 > Some issues have already been fixed in the development version by = Steve > Kargl (we used FreeBSD 13.2). Very interesting paper! Of course we are always interested in improvements for libm, and Steve semi-regularly posts patches in our bug tracker. (Steve's no longer a committer, but usually these get committed by others quickly enough.) At the moment FreeBSD 14.0 is in beta phase, and there have been a number of updates to libm, so it would be interesting to see if it makes the ulp situation a bit better. -Dimitry --Apple-Mail=_24E27A91-7539-491E-A37D-966F2689EC15 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZRHPaQAKCRCwXqMKLiCW o2TMAJ9/Q+8EvzDIV+ICI9t0Mis+s43PwQCgvTM2PSETRbFIrvjwkpm7dtrCDyM= =JAfZ -----END PGP SIGNATURE----- --Apple-Mail=_24E27A91-7539-491E-A37D-966F2689EC15-- From nobody Mon Sep 25 18:42:51 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RvWw3665rz4tvCk for ; Mon, 25 Sep 2023 18:42:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RvWw33QvNz3N7c; Mon, 25 Sep 2023 18:42:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 38PIgqrW014821; Mon, 25 Sep 2023 11:42:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 38PIgpVq014820; Mon, 25 Sep 2023 11:42:51 -0700 (PDT) (envelope-from sgk) Date: Mon, 25 Sep 2023 11:42:51 -0700 From: Steve Kargl To: Dimitry Andric Cc: Paul Zimmermann , freebsd-hackers@freebsd.org Subject: Re: Accuracy of Mathematical Functions Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Queue-Id: 4RvWw33QvNz3N7c On Mon, Sep 25, 2023 at 08:20:25PM +0200, Dimitry Andric wrote: > On 25 Sep 2023, at 15:50, Paul Zimmermann wrote: > > > > I hope this is not off-topic for this list (Technical discussions relating > > to FreeBSD). > > The freebsd-numerics@ list might have been a better match, but it > receives very low traffic, and the audience on this list will be larger. I suggested Paul post here as numerics@ has had 32 post since 2021 and many of those are due to someone assigning a bug report to numerics. > > We have updated our comparison: > > > > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > > > This new update includes for the first time the FreeBSD math library, > > whose accuracy is quite good, except: > > > > * single precision: the Bessel functions, lgammaf, cospif, sinpif, tanpif, powf > > * double precision: the Bessel functions, lgammaf, tgammaf, cospi, sinpi, >> tanpi, pow lgammaf and tgammaf are single precision, but it is certainly possible that there are issues. I'll take a look when I have time. >> * double-extended precision: erfcl, lgammal, tgammal, cospil, sinpil, tanpil, >> powl >> >> Some issues have already been fixed in the development version by Steve >> Kargl (we used FreeBSD 13.2). > > Very interesting paper! Of course we are always interested in > improvements for libm, and Steve semi-regularly posts patches in our bug > tracker. (Steve's no longer a committer, but usually these get committed > by others quickly enough.) The issues with half-cycle trig function (i.e., cospi and friends) should be fixed with git 2d3b0a687 on the main branch. It looks like kib merged the patch into stable/13 with git 6fe5d4d8. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272742 -- Steve From nobody Tue Sep 26 13:26:16 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rw0rg6rKhz4v8MT for ; Tue, 26 Sep 2023 13:26:43 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rw0rg4vpbz3cyQ for ; Tue, 26 Sep 2023 13:26:43 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1695734797; 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=VIBPyaaK4b574VkkgKXAejdyqo2qO6fEpkI6NeWw/Bs=; b=X4YO1J2CUFh3bvoqrL/e2vcSJAFL8XCvwpjxmFq4PfeLxmjoT5mIWH4shrmvxCdpge9DPb ZLp1t8QAmOzmuIhfhkc3XJl7WUh/O8dYXKtrPnOYxB8MMbZuCTbu5NoM1mQjIgVXu2x5M0 I/vHDRLUYlCAlJHAFSzoBcL5XnH6Dc1CXq+k0l+IdlpS+JfetoAUN5P3EU/iWdsuwJAh5d khDdYR3oI23uj00otDhP59KQrT6H9+sZ6hrz0VBKa82/8/NEdAY611d0IjREIesgYKoQgZ UBkoP6AWsAfbUssTTlkqjTRTHN7n2RTE29Oh7mmBSxIe8Cyg8kX1w3m/VL95TA== Date: Tue, 26 Sep 2023 15:26:16 +0200 From: Alexander Leidinger To: Paul Zimmermann Cc: freebsd-hackers@freebsd.org Subject: Re: Accuracy of Mathematical Functions In-Reply-To: References: Message-ID: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> X-Sender: Alexander@Leidinger.net Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_a8b8abe34315fc265a9d56e1c6522fc8"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Queue-Id: 4Rw0rg4vpbz3cyQ This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_a8b8abe34315fc265a9d56e1c6522fc8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2023-09-25 15:50, schrieb Paul Zimmermann: > We have updated our comparison: > > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > This new update includes for the first time the FreeBSD math library, > whose accuracy is quite good, except: I wonder how those functions/libs you tested compare in terms of speed... It would allow to provide a hint to the question "Which lib is the fastest and fulfills the needs in terms of accuracy for the intended use-case?" I agree that the best way to do this requires to run all libs on the same hardware and OS, which is not feasible in your approach. What may be feasible is to compare the relative performance of those subsets, which you run on the same hardware. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_a8b8abe34315fc265a9d56e1c6522fc8 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmUS3AkACgkQEg2wmwP4 2IaGDg/9E2ttFzkbLuyCaNkRgnrZ01cillVwxETzcwrPTEeIvGFAWMcoEVJH6Qe7 duL5PhYZ+wsrgZK4YLRGfLRx4yPNqOptK4gIUHzwouFDzSbscU2U+I/2XoTScAH5 bknYWG9Nm47BuJnZyJyUKrvAjQv2t7NMJaQn8tGV9rMS75teIr7fXzSDZSyjudxc f1gROEysKAFMPLlm2mcTDOcjeJL2eJsnnPyZAi2AmoRFAw6b8tH1FGaH8TdCTQJ/ oq1UtpgPI6qtm50eDa722/VGuV6YioWu7Bxg9c+M8Im8oe5D61LhOF3yDgPrkHn9 ltQS9XSZeFd4zL0mbWhNq/uL6TvvKmxLUvRSw9IouF9QfTKFmr7frqUYK7pKrpOO lDMlpkhWJ295bnnEmf5BJbe9DdMb5akltDHIl67vj1St5FtFdzyi6uWDfHgggNyM hZB6yYUTfZQvhbIC8EwGs2nhYVX5Xb0dMhhgWVTsG9L0A9LmweUt6sLJznp0GTJG cOylAteFUxZt0zH0AzT8yTfP9S6Tv1e34oF9JJUGRfrGKsC0fK07rvv5tfGaY7GT b179k6mL3eqJUmdytNEBUcq9UU1soEos1q5LnNpPalOKDPFO2ABcxO/RSZKw0uKN SdtxdSqD0HlVi4t/02dg2JHMlqUPVv7ix5TA4xcwF4Xzj859dX0= =rFZL -----END PGP SIGNATURE----- --=_a8b8abe34315fc265a9d56e1c6522fc8-- From nobody Tue Sep 26 13:43:39 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rw1DH2LMhz4v9mN for ; Tue, 26 Sep 2023 13:43:43 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.inria.fr", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rw1DG1bC1z4FJl for ; Tue, 26 Sep 2023 13:43:42 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=inria.fr header.s=dc header.b=pMX5X5O6; spf=pass (mx1.freebsd.org: domain of Paul.Zimmermann@inria.fr designates 192.134.164.83 as permitted sender) smtp.mailfrom=Paul.Zimmermann@inria.fr; dmarc=pass (policy=none) header.from=inria.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:message-id:from:to:cc:in-reply-to:subject: references; bh=GXBWxkOqBjwMAZ51ODPmbOdbIuYdSvDdSNTEPzwn3Ow=; b=pMX5X5O6z8ynDaSTQ02o/jsUI59aHndHKTYAn3J8zGQ5nrJRyoLM+4Vi R9Ab6TMAT2xRrX3DyunCraQSTTWGhnMtV4pxLTzJmDpfxv8JIPHxCcmnq W1g1Tn4A8fzWcyQLrmOwpocqzGLMk9K+1nwE8jskYX0wySreBSg6Yk0D+ k=; Received-SPF: SoftFail (mail2-relais-roc.national.inria.fr: domain of Paul.Zimmermann@inria.fr is inclined to not designate 152.81.9.227 as permitted sender) identity=mailfrom; client-ip=152.81.9.227; receiver=mail2-relais-roc.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="Paul.Zimmermann@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail2-relais-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@coriandre) identity=helo; client-ip=152.81.9.227; receiver=mail2-relais-roc.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="postmaster@coriandre"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="6.03,178,1694728800"; d="scan'208";a="128008019" Received: from coriandre.loria.fr (HELO coriandre) ([152.81.9.227]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2023 15:43:39 +0200 Date: Tue, 26 Sep 2023 15:43:39 +0200 Message-Id: From: Paul Zimmermann To: Alexander Leidinger Cc: freebsd-hackers@freebsd.org In-Reply-To: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> (message from Alexander Leidinger on Tue, 26 Sep 2023 15:26:16 +0200) Subject: Re: Accuracy of Mathematical Functions References: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.69 / 15.00]; DWL_DNSWL_LOW(-1.00)[inria.fr:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[inria.fr,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[192.134.164.83:from]; R_SPF_ALLOW(-0.20)[+ip4:192.134.164.0/24]; R_DKIM_ALLOW(-0.20)[inria.fr:s=dc]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[inria.fr:+]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2200, ipnet:192.134.164.0/24, country:FR] X-Rspamd-Queue-Id: 4Rw1DG1bC1z4FJl List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear Alexander, since you ask, you will find some graphs in the last slides of my talk about the correctly-rounded power function (x^y) at Arith23: https://members.loria.fr/PZimmermann/talks/pow-arith23.pdf Once CORE-MATH provides all binary64 functions, we plan to redo these graphs with all existing libraries, including freebsd of course. Best regards, Paul > Date: Tue, 26 Sep 2023 15:26:16 +0200 > From: Alexander Leidinger > Cc: freebsd-hackers@freebsd.org > Organization: No organization, this is a private message. > > > [1:text/plain Hide] > > Am 2023-09-25 15:50, schrieb Paul Zimmermann: > > > We have updated our comparison: > > > > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > > > This new update includes for the first time the FreeBSD math library, > > whose accuracy is quite good, except: > > I wonder how those functions/libs you tested compare in terms of > speed... > It would allow to provide a hint to the question > "Which lib is the fastest and fulfills the needs in terms of accuracy > for the intended use-case?" > > I agree that the best way to do this requires to run all libs on the > same hardware and OS, which is not feasible in your approach. What may > be feasible is to compare the relative performance of those subsets, > which you run on the same hardware. > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > > [2:application/pgp-signature Show Save:signature.asc (833B)] > From nobody Tue Sep 26 14:18:00 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rw20051kcz4vCnP for ; Tue, 26 Sep 2023 14:18:08 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.inria.fr", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rw1zz6xlRz4LBg; Tue, 26 Sep 2023 14:18:07 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=inria.fr header.s=dc header.b=vxG5ydoX; spf=pass (mx1.freebsd.org: domain of Paul.Zimmermann@inria.fr designates 192.134.164.83 as permitted sender) smtp.mailfrom=Paul.Zimmermann@inria.fr; dmarc=pass (policy=none) header.from=inria.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:message-id:from:to:cc:in-reply-to:subject: references; bh=tYD0nVF0YYMQfhLnE5r7BJ/R5ZwpezN9/LiR2KzIaO4=; b=vxG5ydoX1TPNN4nGjiK8O8MCO6Vl2OteP8YKHN6xbbVzOc8rs8Tf9Jnd xQ7VBzpD6YHqLhMv6Kz8VxHCdrzXgryZrGgPYsEggJMV3favjfDSmc4lL XK2+PGXLvFOw/qq6lzzr2aWyyqMliDQOHbY9g0Q2esYeyaNHucwrD8mvi o=; Received-SPF: SoftFail (mail2-relais-roc.national.inria.fr: domain of Paul.Zimmermann@inria.fr is inclined to not designate 152.81.9.227 as permitted sender) identity=mailfrom; client-ip=152.81.9.227; receiver=mail2-relais-roc.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="Paul.Zimmermann@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail2-relais-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@coriandre) identity=helo; client-ip=152.81.9.227; receiver=mail2-relais-roc.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="postmaster@coriandre"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="6.03,178,1694728800"; d="scan'208";a="128017210" Received: from coriandre.loria.fr (HELO coriandre) ([152.81.9.227]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2023 16:18:00 +0200 Date: Tue, 26 Sep 2023 16:18:00 +0200 Message-Id: From: Paul Zimmermann To: sgk@troutmask.apl.washington.edu Cc: dim@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: (message from Steve Kargl on Mon, 25 Sep 2023 11:42:51 -0700) Subject: Re: Accuracy of Mathematical Functions References: X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.68 / 15.00]; DWL_DNSWL_LOW(-1.00)[inria.fr:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.983]; DMARC_POLICY_ALLOW(-0.50)[inria.fr,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_DKIM_ALLOW(-0.20)[inria.fr:s=dc]; RCVD_IN_DNSWL_MED(-0.20)[192.134.164.83:from]; R_SPF_ALLOW(-0.20)[+ip4:192.134.164.0/24]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[inria.fr:+]; RCPT_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:2200, ipnet:192.134.164.0/24, country:FR] X-Rspamd-Queue-Id: 4Rw1zz6xlRz4LBg List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org > > > * double precision: the Bessel functions, lgammaf, tgammaf, cospi, sinpi, > >> tanpi, pow > > lgammaf and tgammaf are single precision, but it is certainly possible > that there are issues. I'll take a look when I have time. sorry, one should read: * double precision: the Bessel functions, lgamma, tgamma, cospi, sinpi, tanpi, pow Paul From nobody Tue Sep 26 18:08:04 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rw75S0yzxz4vT8l for ; Tue, 26 Sep 2023 18:08:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rw75R5Rwyz3HQG for ; Tue, 26 Sep 2023 18:08:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 38QI85tP022099; Tue, 26 Sep 2023 11:08:05 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 38QI84cQ022098; Tue, 26 Sep 2023 11:08:04 -0700 (PDT) (envelope-from sgk) Date: Tue, 26 Sep 2023 11:08:04 -0700 From: Steve Kargl To: Alexander Leidinger Cc: Paul Zimmermann , freebsd-hackers@freebsd.org Subject: Re: Accuracy of Mathematical Functions Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Queue-Id: 4Rw75R5Rwyz3HQG On Tue, Sep 26, 2023 at 03:26:16PM +0200, Alexander Leidinger wrote: > Am 2023-09-25 15:50, schrieb Paul Zimmermann: > > > We have updated our comparison: > > > > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > > > This new update includes for the first time the FreeBSD math library, > > whose accuracy is quite good, except: > > I wonder how those functions/libs you tested compare in terms of speed... > It would allow to provide a hint to the question > "Which lib is the fastest and fulfills the needs in terms of accuracy for > the intended use-case?" > > I agree that the best way to do this requires to run all libs on the same > hardware and OS, which is not feasible in your approach. What may be > feasible is to compare the relative performance of those subsets, which you > run on the same hardware. > Speed vs accuracy is always a trade-off. Consider % ./tlibm j0 -f -x 0x1p-9 -X 2 -s 1 -N 4 Interval tested for j0f: [0.00195312,2] 4000000 calls, 0.040901 secs, 0.01023 usecs/call % ./tlibm j0 -f -x 0x1p-9 -X 2 -s 1 -N 4 Interval tested for j0f: [0.00195312,2] 4000000 calls, 0.092471 secs, 0.02312 usecs/call The former timing is for FreeBSD libm on an AMD FX-8350 using only -O2 optimization. The latter is a patched libm, which uses -O2 -funroll-loops -march=bdver2, and is twice as slow! The difference lies in accuracy. The former gives % ./tlibm j0 -f -x 0x1p-9 -X 2 -PD -N 4 Interval tested for j0f: [0.00195312,2] ulp <= 0.5: 85.04% 3401545 | 85.039% 3401545 0.5 < ulp < 0.6: 5.376% 215028 | 90.414% 3616573 0.6 < ulp < 0.7: 3.107% 124266 | 93.521% 3740839 0.7 < ulp < 0.8: 2.432% 97284 | 95.953% 3838123 0.8 < ulp < 0.9: 1.740% 69612 | 97.693% 3907735 0.9 < ulp < 1.0: 0.941% 37646 | 98.635% 3945381 1.0 < ulp < 1.5: 1.108% 44312 | 99.742% 3989693 1.5 < ulp < 2.0: 0.195% 7791 | 99.937% 3997484 2.0 < ulp < 3.0: 0.062% 2491 | 99.999% 3999975 3.0 < ulp < 0.0: 0.001% 25 | 100.000% 4000000 Max ulp: 3.259556 at 1.9667229652404785e+00 while the latter has % ./tlibm j0 -f -x 0x1p-9 -X 2 -PD -N 4 Interval tested for j0f: [0.00195312,2] ulp <= 0.5: 86.76% 3470362 | 86.759% 3470362 0.5 < ulp < 0.6: 5.531% 221257 | 92.290% 3691619 0.6 < ulp < 0.7: 2.761% 110437 | 95.051% 3802056 0.7 < ulp < 0.8: 1.705% 68195 | 96.756% 3870251 0.8 < ulp < 0.9: 1.228% 49134 | 97.985% 3919385 0.9 < ulp < 1.0: 0.841% 33628 | 98.825% 3953013 1.0 < ulp < 1.5: 1.087% 43475 | 99.912% 3996488 1.5 < ulp < 2.0: 0.087% 3473 | 99.999% 3999961 2.0 < ulp < 3.0: 0.001% 39 | 100.000% 4000000 Max ulp: 2.157274 at 1.9673234224319458e+00 The latter is more accurate, but its underlying algorithm uses summation-and-carry of the ascending series. This algorithm is sensitive to compiler options, so I haven't pushed it FreeBSD (, yet). -- Steve From nobody Wed Sep 27 08:32:18 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RwVH21mNKz4v8LF for ; Wed, 27 Sep 2023 08:32:46 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RwVH15zl4z3M2F for ; Wed, 27 Sep 2023 08:32:45 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1695803557; 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=pbuL+LMvrPmqPDAP4xDth+/NPTHmVRjwV6Vi6QdQMRY=; b=T+cLGP1S9ViPDoaShHoMDwVnxiOWoYLTe7z45CdK9IpmuU341lrRKVH7tdJx6dHednLSrQ 8X7GnF62GC+xu3BiMfpy1w0J9qJKGERyQfAhydhBqVM6Wx5dCMvzfV78Elut1sxyD3V6bb wayO3t/3F7ir2SMd/wdMlx+zlSbWUU+ivdPq0I2F+0RwCxG9S4Mns7NHf+kLOR6hJ5tuxS qmDNs0SgWeIyXELVGhxUFsWBqIRQSySvJxU5I+qF+wi1FP/w/jySyymUiAevyEfuSFYJCI qkGMv/p44PPoWFHpBAA5hueJLeSJuXuXdWSxI1MYqxkaqBEkZkTGTotYTYVoGQ== Date: Wed, 27 Sep 2023 10:32:18 +0200 From: Alexander Leidinger To: sgk@troutmask.apl.washington.edu Cc: Paul Zimmermann , freebsd-hackers@freebsd.org Subject: Re: Accuracy of Mathematical Functions In-Reply-To: References: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> Message-ID: <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> X-Sender: Alexander@Leidinger.net Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_115d35aedc6ac8327e40df12a22c806f"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Queue-Id: 4RwVH15zl4z3M2F This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_115d35aedc6ac8327e40df12a22c806f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2023-09-26 20:08, schrieb Steve Kargl: > On Tue, Sep 26, 2023 at 03:26:16PM +0200, Alexander Leidinger wrote: >> Am 2023-09-25 15:50, schrieb Paul Zimmermann: >> >> > We have updated our comparison: >> > >> > https://members.loria.fr/PZimmermann/papers/accuracy.pdf >> > >> > This new update includes for the first time the FreeBSD math library, >> > whose accuracy is quite good, except: >> >> I wonder how those functions/libs you tested compare in terms of >> speed... >> It would allow to provide a hint to the question >> "Which lib is the fastest and fulfills the needs in terms of >> accuracy for >> the intended use-case?" >> >> I agree that the best way to do this requires to run all libs on the >> same >> hardware and OS, which is not feasible in your approach. What may be >> feasible is to compare the relative performance of those subsets, >> which you >> run on the same hardware. >> > > Speed vs accuracy is always a trade-off. Consider Yes. [examples] > The latter is more accurate, but its underlying algorithm > uses summation-and-carry of the ascending series. This > algorithm is sensitive to compiler options, so I haven't > pushed it FreeBSD (, yet). A thought just crossed my mind... should we consider to provide two ABI compatible math libs, one fast (and "acceptable accurate"... whatever this means), and one accurate (and this one being the default to link against)? Users then could use libmap.conf(5) to use the one according to their needs. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_115d35aedc6ac8327e40df12a22c806f Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmUT6KIACgkQEg2wmwP4 2IZAdg//dfmGI7OY601xsx4Z0NU1s6XPDp1PlarmgdTxHuIhBVlfcGTwnXM75tBp SBj43NMniMaODfg5ZjOlVXflwYGH/4AraerRHkTniXIC6ebziAl39LxKI1iQ9PCk 7ppUxno4fy+dcOYYS25qLZtRheLOvGvAz6jr2ncxtfw/qYsr6AVcv2uV7xulzX6h OqGqGAlAOHmbFYLkFen7gPptcPvIe67NMvbkNRZigK3WaVz7N1jEi6wwhZ0HiDG9 ++vvkn3EOWgzEFduD5yAWwOMzg6wBU8fBcocsNz2zLwmRU869Bu4vZTkcXsEb0Ld oOm5wgGbQvt5K01aBob6/662BILO2cNPUobxnd+YekqcTCthnVZ3Jl7Xow74bJo5 cc4JMu/9qz19MmkVgoeHXsTC8cdufDL6WRg5IVHPbLeKX92VzYXFWrpj0TmjOhTI ASWPTbH1F+OXGrhT1ESIgYdGhDRCH+7qhnbkwNq/U6Ypd+WAhUQWYRrvmlsGTIrE Y3svItO6n/7I11xV05QmwE8+yPYBomx8ksBMK2OPHegG7sbd323dtNU8FTsekRmz 6c0cwZhGn0PVvmuUdcMZFJ2DfX8q6C0f6dvCYE3uNBd8/6wYZLzqxdEQpprpL7eW S9jV+n6fI9l48giJgbqX12BhIGN25eYxVTWgw7TPiWAVODTuHtY= =vIcM -----END PGP SIGNATURE----- --=_115d35aedc6ac8327e40df12a22c806f-- From nobody Wed Sep 27 08:57:01 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RwVqC2YQwz4v9gb for ; Wed, 27 Sep 2023 08:57:11 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.inria.fr", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RwVqB0VmPz3RJT for ; Wed, 27 Sep 2023 08:57:09 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=inria.fr header.s=dc header.b=VlTKmfyM; spf=pass (mx1.freebsd.org: domain of Paul.Zimmermann@inria.fr designates 192.134.164.104 as permitted sender) smtp.mailfrom=Paul.Zimmermann@inria.fr; dmarc=pass (policy=none) header.from=inria.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:message-id:from:to:cc:in-reply-to:subject: references; bh=IEpjmkjjLLXFZ5ss0GfYuEd4y828fLckzDdW5eBaLLs=; b=VlTKmfyMQYhDlERGXJVOBtx++6M0ypnTqqvdHrGnm8lQFKACI6AmDT42 7DTAwLuBuI1LeRP9Zeb4Q0DdXNeTniGlZgpJji/NgAx/FQkj0d/NwRM8y 1Y5oVCwJKYmqX5MvDF8hw5I2HF6elN1mNXd50XNRUqg2PJ0Q6WBk9/urw g=; Received-SPF: SoftFail (mail3-relais-sop.national.inria.fr: domain of Paul.Zimmermann@inria.fr is inclined to not designate 152.81.9.227 as permitted sender) identity=mailfrom; client-ip=152.81.9.227; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="Paul.Zimmermann@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail3-relais-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@coriandre) identity=helo; client-ip=152.81.9.227; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="postmaster@coriandre"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="6.03,179,1694728800"; d="scan'208";a="67075713" Received: from coriandre.loria.fr (HELO coriandre) ([152.81.9.227]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2023 10:57:02 +0200 Date: Wed, 27 Sep 2023 10:57:01 +0200 Message-Id: From: Paul Zimmermann To: Alexander Leidinger Cc: sgk@troutmask.apl.washington.edu, freebsd-hackers@freebsd.org In-Reply-To: <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> (message from Alexander Leidinger on Wed, 27 Sep 2023 10:32:18 +0200) Subject: Re: Accuracy of Mathematical Functions References: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[inria.fr:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[inria.fr,none]; R_DKIM_ALLOW(-0.20)[inria.fr:s=dc]; R_SPF_ALLOW(-0.20)[+ip4:192.134.164.0/24]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[192.134.164.104:from]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[inria.fr:+]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:2200, ipnet:192.134.164.0/24, country:FR] X-Rspamd-Queue-Id: 4RwVqB0VmPz3RJT List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Hi Alexander, > A thought just crossed my mind... should we consider to provide two ABI > compatible math libs, one fast (and "acceptable accurate"... whatever > this means), and one accurate (and this one being the default to link > against)? Users then could use libmap.conf(5) to use the one according > to their needs. this is not the same idea, but the new C standard allows to have two functions exp and cr_exp: See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf, page 454, item 4: Function names that begin with cr_ are potentially reserved identifiers and may be added to the header. The cr_ prefix is intended to indicate a correctly rounded version of the function. Having both under the same name, and having a runtime dispatcher that chooses either the fast version or the correctly rounded version, is a nice idea! Paul From nobody Wed Sep 27 14:11:44 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RwdpR27srz4vWWr for ; Wed, 27 Sep 2023 14:11:59 +0000 (UTC) (envelope-from john@sanren.ac.za) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 4RwdpQ3f6Tz4fD2 for ; Wed, 27 Sep 2023 14:11:58 +0000 (UTC) (envelope-from john@sanren.ac.za) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sanren-ac-za.20230601.gappssmtp.com header.s=20230601 header.b=MEU+PdZO; spf=pass (mx1.freebsd.org: domain of john@sanren.ac.za designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=john@sanren.ac.za; dmarc=none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2773af0c5dbso5454617a91.1 for ; Wed, 27 Sep 2023 07:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sanren-ac-za.20230601.gappssmtp.com; s=20230601; t=1695823915; x=1696428715; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IgMmIyfOOD4ZY2NY+oVtmiR6zy4ZBIOjE9GLrrn1F5w=; b=MEU+PdZOG9SC6HuJN/XX3Kv410yEfmlkXW8/dAvzgudH78AYDseBosEPIGFSdoxdnG LNRiIdIbP/VhWaeggJxUSSGPxteASaTP07b+IGxPt8TTqustU8MaI/lwj/iah3LmLV4X BDRSIN1NCYZSocpUj/OO6w4vFOGMOMd2m1hRjjxPx4tjTjh64ZFxtAKMA/IPbMoxjIJM mkNDZyAnhWR056HHjRNPBgmXBE9QqXBkb/vFldM9cfKIRAmC1g1dCp6pUuf0ivUf9W/6 JZBkiDgdBYYHE0RO7advMSCpNtYSwnFS0pqYUcQJK+yeJTniW7YwgZJ+Rg0yAoYCXzcG 5HXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695823915; x=1696428715; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IgMmIyfOOD4ZY2NY+oVtmiR6zy4ZBIOjE9GLrrn1F5w=; b=CDhTPe7QqHxR/5jWuz4h0RyHuhjnDbsJkjsa2IDBCw8plcVoQUVzzxQlxRFM24gCGf +42wWYjheW0eKGjuNmVesIixVmfJ/SqKOT095PAoxptFUXeQiynADlrbO+z54sehujAm ZCWYE+rlSV05rymuxw7tZDwoY9lETKzKTSARhriUftW3T+3j9VaOfVI1zcb7lkCOFQms cL2ViJ1O0WwPyqnOoHhqH92DkIlpGz/X77JHhWMRvnm8SH3RepgWdvUErG71hdNZdVNj LGo753h5VFsVLezxSvPysx4bbM9Xheqw4LdhauJfyTajXKqhdI0KWWUsxLsRm+GbrKeT 3UMw== X-Gm-Message-State: AOJu0YysDxAx//j7d4d9EQGUDRjoePxo8N6wFvS91YHvHi88d04InSCc 7DY39bk9ZJi+LcZa6RNrVGilb5qBSlTfqsTimIi51ZAGmi2m3fCBLYk= X-Google-Smtp-Source: AGHT+IGHjF2rMco0sHhS2vfQooa/BB914tCg01TcxqOhWAUKQCbfIbko+NJxM77lRRYgsRLVKAlpgCk574r+V3PIDoc= X-Received: by 2002:a17:90a:4f48:b0:268:93d:b936 with SMTP id w8-20020a17090a4f4800b00268093db936mr1605868pjl.18.1695823915308; Wed, 27 Sep 2023 07:11:55 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: John Hay Date: Wed, 27 Sep 2023 16:11:44 +0200 Message-ID: Subject: make msi interrupts available to child devices in a pci card driver To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000012f29f060657c634" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[sanren-ac-za.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1030:from]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[sanren-ac-za.20230601.gappssmtp.com:+]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[sanren.ac.za]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4RwdpQ3f6Tz4fD2 --00000000000012f29f060657c634 Content-Type: text/plain; charset="UTF-8" Hi, I would like to know how to make msi interrupts available to child devices in a pci card driver? I'm writing a driver for the OCP TimeCard. Apart from the timers, it also has 16650 UARTs and IIC devices. All of them are memory mapped in a single BAR. It also has 32 MSI interrupts, with each "function/device" connected to a specific MSI interrupt. I would like to add a child device for each of these "functions" and let each of them have their own interrupt, but I'm struggling to figure out the correct way to make the interrupts available to the child device. The memory mapping, using rman and creating subregions for the different devices is working and I can get a UART device connected in polled mode. The basic process in the card's attach() is much like what the puc(4) driver does (leaving error checking etc. out): bar->b_rid = PCIR_BAR(0); bar->b_type = SYS_RES_MEMORY; bar->b_res = bus_alloc_resource_any(sc->sc_dev, bar->b_type, &bar->b_rid, RF_ACTIVE); sc->sc_iomem.rm_type = RMAN_ARRAY; error = rman_init(&sc->sc_iomem); error = rman_manage_region(&sc->sc_iomem, start, end); for (idx = 0; idx < nports; idx++) { port->p_rres = rman_reserve_resource(&sc->sc_iomem, start, end, size, 0, NULL); bsh = rman_get_bushandle(bar->b_res); bst = rman_get_bustag(bar->b_res); port->p_rres = bus_space_subregion(bst, bsh, ofs, size, &bsh); rman_set_bushandle(port->p_rres, bsh); rman_set_bustag(port->p_rres, bst); port->p_dev = device_add_child(dev, NULL, -1); error = device_probe_and_attach(port->p_dev); I can also allocate MSI interrupts for the driver itself as a test, with no problem: sc->sc_msi =32; pci_alloc_msi(dev, &sc->sc_msi); printf("msi irqs %d\n", sc->sc_msi); for (idx = 0; idx < sc->sc_msi; idx++) { iport->pp_irid = idx + 1; iport->pp_ires = bus_alloc_resource_any(dev, SYS_RES_IRQ, &iport->pp_irid, RF_ACTIVE); bus_setup_intr(dev, iport->pp_ires, INTR_TYPE_TTY | INTR_MPSAFE, timecard_intr, NULL, iport, &iport->p_ihandle); error = pci_enable_busmaster(dev); But I have not been able to find a way, similar to the memory to make it available to a child device, that works. It might be because the child is not a direct child of the pci driver. One hackish way that I could get to work was if I used my dev instead of the child's inside the timecard_bus_alloc_resource() and timecard_bus_setup_intr() methods, something like this: static struct resource * timecard_bus_release_resource(device_t dev, device_t child, int type, int rid, struct resource *res) { if (type == SYS_RES_IRQ) return BUS_RELEASE_RESOURCE(device_get_parent(dev), dev, type, rid, res); } static int timecard_bus_setup_intr(device_t dev, device_t child, struct resource *res, int flags, driver_filter_t *filt, void (*ihand)(void *), void *arg, void **cookiep) { return bus_setup_intr(dev, res, flags, filt, ihand, arg, cookiep); } That works, but does not feel quite right and then the interrupt is not "owned" by the child, but by the timecard driver: # vmstat -ia | grep timecard irq41: timecard0 10408538 175 Regards John --00000000000012f29f060657c634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I would like to know how= to make msi interrupts available to child devices in a pci card driver?

I'm writing a driver for the OCP TimeCard. Apart= from the timers, it also has 16650 UARTs and IIC devices. All of them are = memory mapped in a single BAR. It also has 32 MSI interrupts, with each &qu= ot;function/device" connected to a specific MSI interrupt.
<= br>
I would like to add a child device for each of these "fu= nctions" and let each of them have their own interrupt, but I'm st= ruggling to figure out the correct way to make the interrupts available to = the child device.

The memory mapping, using r= man and creating subregions for the different devices is working and I can = get a UART device connected in polled mode. The basic process in the card&#= 39;s attach() is much like what the puc(4) driver does (leaving error check= ing etc. out):

<snip>
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 bar->b_rid =3D PCIR_BAR(0);
=C2=A0 =C2=A0 =C2=A0= =C2=A0 bar->b_type =3D SYS_RES_MEMORY;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b= ar->b_res =3D bus_alloc_resource_any(sc->sc_dev, bar->b_type, &= ;bar->b_rid, RF_ACTIVE);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 sc->sc_iomem.rm_type =3D RMAN_ARRAY;
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 error =3D rman_init(&sc->sc_iomem);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 error =3D rman_manage_region(= &sc->sc_iomem, start, end);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 for (idx =3D 0; idx < nports; idx++) {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 port->p_rre= s =3D rman_reserve_resource(&sc->sc_iomem, start, end, size, 0, NULL= );
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bsh =3D rman_get_bushandle(bar->b_res);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 bst =3D rman_get_bustag(bar->b_res);
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 port->p_rres =3D bus_space_subregion(bst, bsh, ofs, size= , &bsh);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rman_set_bushandle(port->p_rres,= bsh);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rman_set_bustag(port->p_rres, bst);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 port->p_dev =3D device_add_child(dev, NULL, -1)= ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 error =3D device_probe_and_attach(p= ort->p_dev);
</snip>

I can also= allocate MSI interrupts for the driver itself as a test, with no problem:<= /div>

<snip>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= sc->sc_msi =3D32;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = pci_alloc_msi(dev, &sc->sc_msi);
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 printf("msi irqs %d\n", sc->sc_msi);
<= div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (idx =3D 0; idx < sc-= >sc_msi; idx++) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 iport->pp_irid =3D idx + 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 iport->pp_ires =3D bus_alloc_resource_any(d= ev, SYS_RES_IRQ, &iport->pp_irid, RF_ACTIVE);
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bus_setup_intr(dev, iport->= ;pp_ires, INTR_TYPE_TTY | INTR_MPSAFE, timecard_intr, NULL, iport, &ipo= rt->p_ihandle);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 error =3D pci_enab= le_busmaster(dev);
</snip>

But I h= ave not been able to find a way, similar to the memory to make it available= to a child device, that works. It might be because the child is not a dire= ct child of the pci driver.

One hackish way that I= could get to work was if I used my dev instead of the child's inside t= he timecard_bus_alloc_resource() and timecard_bus_setup_intr() methods, som= ething like this:

<snip>
static st= ruct resource *
timecard_bus_release_resource(device_t dev, devic= e_t child, int type, int rid, struct resource *res)
{
i= f (type =3D=3D SYS_RES_IRQ)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 return BUS_RELEASE_RESOURCE(device_get_parent(dev), dev, type, ri= d, res);
}
static int
timecard_bus_setup_intr= (device_t dev, device_t child, struct resource *res,
=C2=A0 =C2= =A0 int flags, driver_filter_t *filt, void (*ihand)(void *), void *arg, voi= d **cookiep)
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return bus_setup= _intr(dev, res, flags, filt, ihand, arg, cookiep);
}
&l= t;/snip>

That works, but does not feel quite ri= ght and then the interrupt is not "owned" by the child, but by th= e timecard driver:
<snip>
# vmstat -ia | grep= timecard
irq41: timecard0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A010408538 =C2=A0 =C2=A0 =C2=A0 =C2=A0175
</snip>

Regards

John
--00000000000012f29f060657c634-- From nobody Wed Sep 27 18:59:25 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RwmBG50MZz4tqpt for ; Wed, 27 Sep 2023 18:59:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RwmBG29Jhz3g1x for ; Wed, 27 Sep 2023 18:59:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 38RIxPG1039185; Wed, 27 Sep 2023 11:59:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 38RIxPVe039184; Wed, 27 Sep 2023 11:59:25 -0700 (PDT) (envelope-from sgk) Date: Wed, 27 Sep 2023 11:59:25 -0700 From: Steve Kargl To: Alexander Leidinger Cc: Paul Zimmermann , freebsd-hackers@freebsd.org Subject: Re: Accuracy of Mathematical Functions Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Queue-Id: 4RwmBG29Jhz3g1x On Wed, Sep 27, 2023 at 10:32:18AM +0200, Alexander Leidinger wrote: > Am 2023-09-26 20:08, schrieb Steve Kargl: > > On Tue, Sep 26, 2023 at 03:26:16PM +0200, Alexander Leidinger wrote: > > > Am 2023-09-25 15:50, schrieb Paul Zimmermann: > > > > > > > We have updated our comparison: > > > > > > > > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > > > > > > > This new update includes for the first time the FreeBSD math library, > > > > whose accuracy is quite good, except: > > > > > > I wonder how those functions/libs you tested compare in terms of > > > speed... > > > It would allow to provide a hint to the question > > > "Which lib is the fastest and fulfills the needs in terms of > > > accuracy for > > > the intended use-case?" > > > > > > I agree that the best way to do this requires to run all libs on the > > > same > > > hardware and OS, which is not feasible in your approach. What may be > > > feasible is to compare the relative performance of those subsets, > > > which you > > > run on the same hardware. > > > > > > > Speed vs accuracy is always a trade-off. Consider > > Yes. > > [examples] > > The latter is more accurate, but its underlying algorithm > > uses summation-and-carry of the ascending series. This > > algorithm is sensitive to compiler options, so I haven't > > pushed it FreeBSD (, yet). > > A thought just crossed my mind... should we consider to provide two ABI > compatible math libs, one fast (and "acceptable accurate"... whatever this > means), and one accurate (and this one being the default to link against)? > Users then could use libmap.conf(5) to use the one according to their needs. This is certainly possible, but implementing it across all supported architecture might be problematic. For float and double, FreeBSD may be able to leverage CoreMath that Paul and his colleagues at Inria are developing (https://core-math.gitlabpages.inria.fr/). I have not tried to build and test it on FreeBSD, yet. Unfortunately, compiler options like -ffast-math and -Ofast tend to lead users down a potentially hazardous path. Everyone wants their codes to run "fast". They just don't know that "fast" might also mean wrong. -- Steve From nobody Thu Sep 28 12:09:27 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RxC2x3mtbz4vvnC for ; Thu, 28 Sep 2023 12:09:45 +0000 (UTC) (envelope-from c@bow.st) Received: from comms.drone (in.bow.st [71.19.146.166]) (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 4RxC2s6B6Xz3GTK; Thu, 28 Sep 2023 12:09:41 +0000 (UTC) (envelope-from c@bow.st) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of c@bow.st designates 71.19.146.166 as permitted sender) smtp.mailfrom=c@bow.st; dmarc=none Received: from homebase (unknown [IPv6:fe80::84f2:9338:4538:7581]) by comms.drone (Postfix) with ESMTPSA id E3729FDEF; Thu, 28 Sep 2023 12:09:30 +0000 (UTC) From: "Mathew\, Cherry G.*" To:"Mathew\, Cherry G.*" Cc: freebsd-hackers@freebsd.org, Alexander Leidinger , adridg@freebsd.org Subject: Search space complexity -> Re: ARC model specified in spinroot/promela References: <85jzt96qjz.fsf@bow.st> <9c424a574cdd39fc879c9ed9192556c0@Leidinger.net> <858r9o6ee0.fsf@bow.st> <85pm304dzi.fsf@bow.st> <85a5u22oxx.fsf@bow.st> <85y1hjecna.fsf@bow.st> <85o7icapb8.fsf@bow.st> <854jjw3jjy.fsf@bow.st> Date: Thu, 28 Sep 2023 12:09:27 +0000 In-Reply-To: <854jjw3jjy.fsf@bow.st> (Cherry G. Mathew's message of "Thu, 14 Sep 2023 14:40:01 +0000") Message-ID: <85ttrev6rs.fsf_-_@bow.st> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: - X-Spamd-Result: default: False [-1.54 / 15.00]; HFILTER_HELO_IP_A(1.00)[comms.drone]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; NEURAL_HAM_SHORT(-0.66)[-0.655]; HFILTER_HELO_NORES_A_OR_MX(0.30)[comms.drone]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCPT_COUNT_THREE(0.00)[4]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:47066, ipnet:71.19.146.0/24, country:US]; TO_DN_SOME(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bow.st]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4RxC2s6B6Xz3GTK Hi Again, This email is a very long rabbit-hole into formal verification itself - If you don't really care about this - just about QA and CI integration, then you can skip this mail entirely - I will send an update on that in a few days. If you would like to help out with the verification run, then please try the attached patch on a reasonably powerful machine (previous reports on list seem to have made progress with about 64GB of RAM etc.), and please send me the output offlist. TIA! As usual, with $PATH suitably set for spin and/or modex, the commands are: # For hand written model verification $ make clean spin-gen spin-run spin-trace # For modex extracted model verification $ make clean modex-gen spin-run spin-trace If you care about the details and some minimal theory of how spin can be best made to explore statespace, and how it is different from hand-written test cases, then please read on, and also try the updated patch below. contd. - inline below.... please read on... >>>>> Mathew, Cherry G * writes: [...] > A few things remain WIP. Obviously, this is a "toy" model - it has > stack based "memory" management, and a directory buffer size of > 64. So that needs to be hammered on a bit more. Further, I'm keen > to now dip my toes into re-entrancy. If you noticed in the earlier > patches, there were model routines for > "mutex_enter()/mutex_exit()". I'll re-look these and play around a > little bit with concurrent entry of ARC() (ARC() is now strictly > entered sequentially in a loop - see arc.drv). Once things settle > down, I will look at making an actual block disk driver with an > ARC(9) managed cache using this code. I will work on this next. But see below for FV details. > Another area of further work would be the *.inv files, where the > invariant specifications are made. I bring your attention to the last expression in arc/arc.inv Here, there is a block marked as follows: #if 1 /* Disable for easy demo. Enable to search harder */ This is a knob you can turn off, to have a quick understanding of the description below. When I refer to the spin "trace", I am referring to what the console barfs out when you run the above commands with the #if negated (ie; s/#if 1/#if 0/) > I also noticed that the arc input trace makes the extracted and > hand-coded models exlclude slightly different looking codepaths. I > need to review these to understand how/what is different. Finally, > need to update the input trace itself to exercise all possible > codepaths in both. This problem went away on its own, because the current state space exploration code works all code paths (confirmed on both handcoded model and modex extracted model). Right, so let's start with what we're trying to do, and how spin (and modern Finite Automaton based verification) differs from predicate logic based testing (eg: assert()s ) we currently rely on in our codebases. I'm obviously not an FV expert, so please refer to all the very excellent documentation out there - in particular, this spin Tutorial helped me quite a bit [1]. If my description below is inconsistent or has errors, please feel free to point them out, on list. Chapter 1: Specification vs. Code Given a "program" - in this case our promela model in arc/arc.pml, spin views each statement as a potentially reachable "state" in a None Deterministic Finite Automaton (NDFA). The first line will be the "Start" state, and the end of the file is usually considered the "End" state (unless one modifies that using "end:" labels - see spin manual for details). We will call a single example of the { "Start" -> "Execute subset of given statements" -> "End" }, a "Run". Why "Non Deterministic" ? Because there are more than one possible branches a next statement can take, to land on the next state, during a "Run". Which branch (formally called "Edge", "Arrow" or "transition", depending on which book you read) you take, can depend on the current state of select variables one can specify. Spin provides the if/fi and do/od constructs to facilitate this. Aside: Note that a single run is deterministic and can thus be viewed as a constituent subset DFA of the equivalent DFA to the specified NDFA. (Recall that any NDFA can be "broken out" into an equivalent DFA). This is where things start to get interesting. When we normally program in C, for eg:, the programming language semantics do not force us to consider all possible execution paths and possibilities. As programmers, we thus usually mentally model only the functional case at hand (eg: Add two numbers, add()) and relegate the alternative cases (eg: the legal range of values that can be provided to the add() function) to a "later" problem to be investigated during "testing". For eg: if I were to write the following C code block: state0: /* Start */ { state1: int i = 0; state2: if (i == 0) { state3: printf("Expr true\n"); } state4: /* End */ } ,we know the exact deterministic path of states the program will go through during a single run, ie; state0->state1->state2->state3->state4 As programmers, we normally don't need to worry about the case where (i != 0) because we normally think of programs functionally, and in the context of a *single run*. "All other cases is for testers to worry about", would be the typical lazy programmer perspective. However, spin's modelling language, promela, has constructs to specify the program (model) with every possible state transition based on the state of specified variables in mind. In fact, spin forces you to explicitly "hide" variables you don't want to contribute to the set of Runs to be explored. For eg: in the above scenario, the following fragment would seemingly be the equivalent promela model: state0: /* Start */ { state1: int i = 0; if state2: :: (i == 0) -> state3: printf("Expr true\n"); fi state4: } At first glance, this may look equivalent to the previous C code snippet above, but spin views this snippet as a Non Deterministic Finite Automaton (NDFA) which is to be decomposed into all possible constituent Run DFAs which make up its equivalent DFA. Remember that a single Run consists of a single sequence of precisely deterministic states - ie; a Deterministic Finite Automaton (DFA). In contrast, we view the C code as an NDFA that's left to the executing computer to explore the Run state progression (DFA) *one* possible Run at a time. To illustrate this, let's assume that in state1:, i = 1 in both snippets above. In the case of C code, because the program state sequence is the job of the executing computer during Run time, we know the state transition precisely - ie; state0->state1->state2->state4 and don't care about other possibilities eg: "What about state3 ?" Spin however views this very differently. It views the state1->state2->... transition as *ONE CASE* among all the several possible Run sequences regardless of the currently considered value of i (remember, we assume i = 1 in this scenario). Since 'i' is declared as type int, this is the set of possible values (INT_MIN < i < INT_MAX). The specific edge traversed next in the NDFA is determined in this case, by the precise current value of i which is expected to be enumerated case by case based on the if/fi construct. Thus when it arrives at state2, spin will need to know what to do next (ie; which edge to traverse to for the next statement) based on the current value of 'i' in all possible cases of 'i'. if these cases are not specified as forward edges, spin views this as an underspecification error and "block"s the Run (as there is no transition edge corresponding to the current value of 'i' to chose). Thus to fix this, we will need to provide the "in all other cases" edge compressed into a keyword, called "else" as follows: state0: /* Start */ { state1: int i = 0; if state2: :: (i == 0) -> state3: printf("Expr true\n"); state3.5a: /* In all other cases, including i == 1 */ :: else -> state3.5b: skip; fi state4: } For spin experts, please forgive my oversimplified explanation, which is really about the "executability" of "state2: :: (i == 0 ... " vs. "state3.5: :: else ..." where "else" evaluates to "true"/executable, in the specific situation that no other alternative in the if/fi block is executable. A keen observer will now note that, if the current value of the variable 'i' were non determinable, one would still be able to specify in promela, what we intend for our program to do. In other words, if we were able to do something like 'state1: i = rand() % i' (not available in spin for very good reasons out of the scope of this discussion) - then even in that case, the specification above would be able to process the program behaviour in *ALL POSSIBLE* "Run" paths between state0->...state4 , whereas the C program can be satisfied by the scenario of a *SINGLE* Run path, at random. To do the functionally equivalent mechanism of what spin does in this case, we would have to write C code to exhaustively loop the entire code block from state1: through all possible values of the variable 'i' between INT_MIN and INT_MAX. Recalling from undergrad computer science discourse, one can view the promela model "program" in the context of spin attempting to decompose the specification into all possible deterministic "Run"s - ie; technically, the attempt is to decompose the specification program which is a NDFA, into all possible "Run"s, each run being a constitutent subset of the equivalent DFA. This is the fundamental context in which we need to view spin's promela specifications, when we wish to verify our specified model. Chapter 2: Specifying Properties of models "So you've got an iterator for the statespace of all variables in a given program, so what ? I can write that in a couple of C while(){} loops!" one might argue. This is where spin sits apart from regular programming. Let's assume that one were to write a large set of exhaustive tests, taking into account the entire state space of all variables in the code. The core part of these tests would be what's called "Propositional Logic". For eg: if you wanted to exhaustively test an add() function add(int a, int b); , one could potentially write a loop as follows: ... test_add() { int a, b; for (a = INT_MIN;a <= INT_MAX;a++) { for (b = INT_MIN;b <= INT_MAX;b++) { assert(add(a, b) == (a + b)); } } } Here, the core propositional logic is the '==' operator. We exhaustively "walk the timeline" (ie; every single Run sequence) of a, b, but are only able to ask the question "is proposition 'P' true *NOW* ? (Here proposition 'P' would be 'add(a,b) == (a + b)'). There is no mechanism in propositional logic to ask questions about the behaviour of state over a period of time (ie; a sequence of state during a Run) wrt the current state, ie; if we are interested to make generalised (technically called "regular") statements about the behaviour of an automaton over a period of time, we need to use a different set of logical tools called "Linear Temporal Logic" (LTL). LTL provides us with a superset of the usual propositional Logic operators to take into account the "timeline" or more precisely, the exact path taken by a given "Run" DFA. So for eg: you could make LTL statements such as: "always add(a, b) == (a + b)" or "eventually (a == b)" The view is that of standing "outside" the for() loops above, and making logical assertions about the state evolutions happening within the loops, for all possible combination of values (states) of a, b and add(). This is what we attempt to do in the file arc/arc.inv - in this case, the Logical assertions listed out in the ltl{} section are about the the properties of the ARC buffers over time. If you bring your attention to the last assertion guarded by a #ifdef DISCOVER_STATEPATH/#endif pair, and modify the #if 1 to a #if 0, you can quickly see how spin operates on the assertion that "always ! (lengthof(T1) == C && lengthof(B2) == C)" As one might apply De-Morgan's laws to propositional logic, LTL has its own set of transformations, with which one can rewrite the above as: "it is never true that the lengths of buffers T1 and B2 is equal to C" or more intuitive, "T1 and B2 are never simultaneously full". ( always !P <==> never P ) When we make this assertion, spin tries to disprove this by exhaustively searching the space of all states and state transitions, in order to identify a case where the assertion is false. If it is able to find this case, then the entire state transition trail is printed out on the console, along with the final state at which the assertion was falsified. This is what happens when you run '$ make clean spin-gen spin-run spin-trace' If spin is unable to find a counter example to disprove the ltl{} claims we have made, then we must conclude that the claims are true - this idea is formally called "Model Checking" [2] and borrows from rich theoretical work that is way beyond my current scope of knowledge. Conclusion: In conclusion, I believe that spin is an excellent tool to apply these rich theoretical ideas to a software methodology (that I've been calling D3) in order to keep the BSD codebases high quality, easily maintainable, and auto-documenting (via LTL claims). Application: If you look at arc/arc.inv you will find a '#if PROBLEM_INVARIANT' clause that I lifted from the original ARC paper (Section III, A.3) - it's a fairly strong invariant spec, which I was surprised to find fails on the current model. There are several potential reasons why this is happening: 1) The assertion is logically untrue, and the authors got this wrong. This is unlikely, as the ARC has been around for long enough, and applied hard enough, that an error would very likely have been discovered by now. But if not, then spin has found a serious inconsistency in the paper! 2) My implementation is incorrect: This is more likely the case, as I am new to specification in promela, and there are several likely points of error. It would be interesting to see how / what can be done to pinpoint where the bug is. I invite the community to attempt to find this logical bug. Finally, if you notice the "DISCOVER_STATEPATH" assertion, if you run it long enough (my computing resources are insufficient to do this in a meaningful time), the counter example provided should give a sequence of inputs that can be used as a static input sequence, to validate the model without -D EXPLORE_STATESPACE. What this would do is to bring in very basic checking of a small subset of the model statespace, which can be integrated into the testing/CI build infrastructure for continuous coverage at low computational cost. Final Note: If you look at the fundamental source of search space complexity, it will become apparent that the system is attempting to find a sequence of inputs that can satisfy the invariants specified. See: arc/arc.drv:init() This search space is very large, as it involves the Kleen Closure set of all words that the model NDFA would match on - which is theoretically infinite - but since we attempt to find the first counter example using the Model checking algorithm, we only look within a finite matching language (my understanding - I may be wrong, since my theoretical understanding of this stuff is very shaky). What will become clear if I get help running this model on a larger, powerful machine, is how big the searchspace is (assuming the program is unable to find a counter example to disprove the last clause in the ltl{}). In other words, please try the patch below, and let me know! Many Thanks, [1] https://spinroot.com/spin/Doc/Spin_tutorial_2004.pdf [2] https://dl.acm.org/doi/10.1145/1592761.1592781 -- ~cherry diff -urN arc-null/arc.c arc/arc.c --- arc-null/arc.c 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc.c 2023-09-14 13:59:20.607107308 +0000 @@ -0,0 +1,173 @@ +/* C Implementation of the Adaptive Replacement Cache algorithm. Written by cherry */ + +/* + * We implement the following algorithm from page 10, Figure 4. + * https://www.usenix.org/legacy/events/fast03/tech/full_papers/megiddo/megiddo.pdf + * + * + * ARC(c) + * + * INPUT: The request stream x1,x2,....,xt,.... + * INITIALIZATION: Set p = 0 and set the LRU lists T1, B1, T2, and B2 to empty. + * + * For every t>=1 and any xt, one and only one of the following four cases must occur. + * Case I: xt is in T1 or T2. A cache hit has occurred in ARC(c) and DBL(2c). + * Move xt to MRU position in T2. + * + * Case II: xt is in B1. A cache miss (resp. hit) has occurred in ARC(c) (resp. DBL(2c)). + * ADAPTATION: Update p = min { p + d1,c } + * where d1 = { 1 if |B1| >= |B2|, |B2|/|B1| otherwise + * + * REPLACE(xt, p). Move xt from B1 to the MRU position in T2 (also fetch xt to the cache). + * + * Case III: xt is in B2. A cache miss (resp. hit) has occurred in ARC(c) (resp. DBL(2c)). + * ADAPTATION: Update p = max { p - d2,0 } + * where d2 = { 1 if |B2| >= |B1|, |B1|/|B2| otherwise + * + * REPLACE(xt, p). Move xt from B2 to the MRU position in T2 (also fetch xt to the cache). + * + * Case IV: xt is not in T1 U B1 U T2 U B2. A cache miss has occurred in ARC(c) and DBL(2c). + * Case A: L1 = T1 U B1 has exactly c pages. + * If (|T1| < c) + * Delete LRU page in B1. REPLACE(xt,p). + * else + * Here B1 is empty. Delete LRU page in T1 (also remove it from the cache). + * endif + * Case B: L1 = T1 U B1 has less than c pages. + * If (|T1| + |T2| + |B1| + |B2| >= c) + * Delete LRU page in B2, if (|T1| + |T2| + |B1| + |B2| = 2c). + * REPLACE(xt, p). + * endif + * + * Finally, fetch xt to the cache and move it to MRU position in T1. + * + * Subroutine REPLACE(xt,p) + * If ( (|T1| is not empty) and ((|T1| exceeds the target p) or (xt is in B2 and |T1| = p)) ) + * Delete the LRU page in T1 (also remove it from the cache), and move it to MRU position in B1. + * else + * Delete the LRU page in T2 (also remove it from the cache), and move it to MRU position in B2. + * endif + */ + +#include "arc_queue/arc.h" + +static void arc_list_init(struct arc_list *_arc_list) +{ + TAILQ_INIT(&_arc_list->qhead); + _arc_list->qcount = 0; + + int i; + for(i = 0; i < ARCLEN; i++) { + init_arc_item(&_arc_list->item_list[i], IID_INVAL, false); + }; +} + +int p, d1, d2; +struct arc_list _B1, *B1 = &_B1, _B2, *B2 = &_B2, _T1, *T1 = &_T1, _T2, *T2 = &_T2; + +void arc_init(void) +{ + p = d1 = d2 = 0; + + arc_list_init(B1); + arc_list_init(B2); + arc_list_init(T1); + arc_list_init(T2); +} + +struct arc_item _LRUitem, *LRUitem = &_LRUitem; + +static void +REPLACE(struct arc_item *x_t, int p) +{ + + + init_arc_item(LRUitem, IID_INVAL, false); + + if ((lengthof(T1) != 0) && + ((lengthof(T1) > p) || + (memberof(B2, x_t) && (lengthof(T1) == p)))) { + readLRU(T1, LRUitem); + delLRU(T1); + cacheremove(LRUitem); + addMRU(B1, LRUitem); + } else { + readLRU(T2, LRUitem); + delLRU(T2); + cacheremove(LRUitem); + addMRU(B2, LRUitem); + } +} + +void +ARC(struct arc_item *x_t) +{ + if (memberof(T1, x_t)) { /* Case I */ + delitem(T1, x_t); + addMRU(T2, x_t); + } + + if (memberof(T2, x_t)) { /* Case I */ + delitem(T2, x_t); + addMRU(T2, x_t); + } + + if (memberof(B1, x_t)) { /* Case II */ + d1 = ((lengthof(B1) >= lengthof(B2)) ? 1 : (lengthof(B2)/lengthof(B1))); + p = min((p + d1), C); + + REPLACE(x_t, p); + + delitem(B1, x_t); + addMRU(T2, x_t); + cachefetch(x_t); + } + + if (memberof(B2, x_t)) { /* Case III */ + d2 = ((lengthof(B2) >= lengthof(B1)) ? 1 : (lengthof(B1)/lengthof(B2))); + p = max((p - d2), 0); + + REPLACE(x_t, p); + + delitem(B2, x_t); + addMRU(T2, x_t); + cachefetch(x_t); + } + + if (!(memberof(T1, x_t) || + memberof(B1, x_t) || + memberof(T2, x_t) || + memberof(B2, x_t))) { /* Case IV */ + + if ((lengthof(T1) + lengthof(B1)) == C) { /* Case A */ + if (lengthof(T1) < C) { + delLRU(B1); + REPLACE(x_t, p); + } else { + assert(lengthof(B1) == 0); + readLRU(T1, LRUitem); + delLRU(T1); + cacheremove(LRUitem); + } + } + + if ((lengthof(T1) + lengthof(B1)) < C) { + if ((lengthof(T1) + + lengthof(T2) + + lengthof(B1) + + lengthof(B2)) >= C) { + if ((lengthof(T1) + + lengthof(T2) + + lengthof(B1) + + lengthof(B2)) == (2 * C)) { + + delLRU(B2); + } + + REPLACE(x_t, p); + } + } + cachefetch(x_t); + addMRU(T1, x_t); + } +} diff -urN arc-null/arc.drv arc/arc.drv --- arc-null/arc.drv 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc.drv 2023-09-28 07:08:06.528728685 +0000 @@ -0,0 +1,148 @@ +/* + * Spin process model statespace driver for the + * Adaptive Replacement Cache algorithm. + * Written by "Mathew, Cherry G." + */ + +/* + * Note: What we're attempting in this driver file, is to generate an + * input trace that would exercise all code-paths of the model specified + * in arc.pml + * + * Feeding a static trace to the algorithm in array _x[N_ITEMS] is an + * acceptable alternative. See -D DISCOVER_STATEPATH below. + */ + +int _x_iid = 0; /* Input trace variable. A temporal record of this + * variable can serve as the input trace. + */ + +/* + * Explore as much of the program statespace as possible, in order to + * try to disprove LTL claims. (See: arc.inv for ltl{} section) + */ + +#ifdef EXPLORE_STATESPACE + +#define DISCOVER_STATEPATH + /* + * Note: disabling this will force spin to + * explore the *entire* state space. This + * may or may not be bounded, and I'm not + * sure if the question of a finite + * boundary is a decidable problem. + */ + + +/* Look for a good input trace ie; a specific linear sequence that + * _x_iid took (see below), which triggered disproving an invariant + * crafted for the purpose of exercising literally every single + * conditional path in the model. (See arc.inv) + * + * In spin parlance, this invariant is called a "never claim". We make + * this claim as specific as possible, in order to force spin to + * search as much of the statespace as possible to disprove it. What + * ensues in the process is twofold: + * + * 1) A program trace is discovered, where the never claim is + * disproved. + * 2) In searching the statespace, a large number of other program + * trace spaces are trialled, which effectively acts as verification + * over the other invariants specified in LTL. (See: arc.inv) + * + * If we save the sequence of generated input values of _x_iid which + * led to disproving the never claim, and the claim itself were crafted + * prudently, then we can use this trace as a "static input" to + * ensure that the rest of the invariants hold, and this takes a + * fraction of the time it takes compared to the discovery + * effort for full verification. This can be thought of as closer to + * "unit testing" of the model, and can be used for a basic + * sanity-check in regular code builds, once the model, and its code + * implementation have matured enough. + * + * Note that this does not invalidate the need for actual unit testing + * of final code. + */ + +#define X_MIN 0 +#define X_MAX (4 * C - 1) /* Four buffer lengths - start at 0 */ + +#define N_ITEMS (X_MAX + 1) /* Number of distinct cache items to test with */ + +#define REPEAT_MAX (X_MAX - X_MIN) /* How many times a repeat loop may go on for */ +hidden int _repeat = 0; + +hidden arc_item _x[N_ITEMS]; /* Input state is irrelevant from a verification PoV */ + +init { + _x_iid = (X_MAX - X_MIN) / 2; /* Start halfway */ + + do + :: + init_arc_item(_x[_x_iid], _x_iid, false); + ARC(_x[_x_iid]); + if + :: (_x_iid > X_MIN) -> _x_iid--; + :: (_x_iid < X_MAX) -> _x_iid++; + :: (_repeat < REPEAT_MAX) -> _repeat++; + :: else break; + fi + od + +} + +#else + +/* + * Not so prudent trace generator - this served as the first iteration + * while putting the basic model and invariants in place. + * + * Eventually, a static trace obtained from the statespace exploration + * described above can be used to drive the ARC() promela model, more + * like how a testing harness would be driven. This could be then in + * the default sanity-check path in CI build runs. This trace could + * also be used as input for testing the C-code implementation (See: + * arc_drv.c etc. + */ + +#define N_ITEMS (N * C) /* Number of distinct cache items to test with */ +#define ITEM_REPS (C / 4) /* Max repeat item requests */ +#define N_ITERATIONS 3 + +hidden arc_item _x[N_ITEMS]; /* Input state is irrelevant from a verification PoV */ +hidden int _item_rep = 0; +hidden int _iterations = 0; + +/* Drive the procs */ +init { + + atomic { + do + :: + _iterations < N_ITERATIONS -> + + _x_iid = 0; + do + :: _x_iid < N_ITEMS -> + init_arc_item(_x[_x_iid], _x_iid, false); + _item_rep = 0; + do + :: _item_rep < (_x_iid % ITEM_REPS) -> + ARC(_x[_x_iid]); + _item_rep++; + :: _item_rep >= (_x_iid % ITEM_REPS) -> + break; + od + _x_iid++; + :: _x_iid >= N_ITEMS -> + break; + od + _iterations++; + :: + _iterations >= N_ITERATIONS -> + break; + od + } + +} +#endif \ No newline at end of file diff -urN arc-null/arc_drv.c arc/arc_drv.c --- arc-null/arc_drv.c 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_drv.c 2023-09-14 14:01:04.826170703 +0000 @@ -0,0 +1,35 @@ +/* See arc.drv for design details */ + +#include "arc_queue/arc.h" + +#define N_ITEMS (2 * C) /* Number of distinct cache items to test with */ +#define ITEM_REPS (C / 4) /* Max repeat item requests */ +#define N_ITERATIONS 3 + +static struct arc_item _x[N_ITEMS]; /* Input state is irrelevant from a verification PoV */ +static int _x_iid = 0; +static int _item_rep = 0; +static int _iterations = 0; + +/* Drive ARC() with a preset input trace */ + +void +main(void) +{ + arc_init(); /* Init module state */ + + while (_iterations < N_ITERATIONS) { + _x_iid = 0; + while (_x_iid < N_ITEMS) { + init_arc_item(&_x[_x_iid], _x_iid, false); + _item_rep = 0; + while(_item_rep < (_x_iid % ITEM_REPS) ) { + ARC(&_x[_x_iid]); + _item_rep++; + } + _x_iid++; + } + _iterations++; + } +} + diff -urN arc-null/arc.inv arc/arc.inv --- arc-null/arc.inv 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc.inv 2023-09-28 07:09:08.515935227 +0000 @@ -0,0 +1,65 @@ +/* $NetBSD$ */ + +/* These are Linear Temporal Logic invariants (and constraints) + * applied over the statespace created by the promela + * specification. Correctness is implied by Logical consistency. + */ +ltl +{ + /* c.f Section I. B, on page 3 of paper */ + always ((lengthof(T1) + + lengthof(B1) + + lengthof(T2) + + lengthof(B2)) <= (2 * C)) + + /* Reading together Section III. A., on page 7, and + * Section III. B., on pages 7,8 + */ + && always ((lengthof(T1) + lengthof(B1)) <= C) + && always ((lengthof(T2) + lengthof(B2)) <= (2 * C)) + + /* Section III. B, Remark III.1 */ + && always ((lengthof(T1) + lengthof(T2)) <= C) + + /* TODO: III B, A.1 */ + + /* III B, A.2 */ + && always (((lengthof(T1) + + lengthof(B1) + + lengthof(T2) + + lengthof(B2)) < C) + implies ((lengthof(B1) == 0) && + lengthof(B2) == 0)) +#if PROBLEM_INVARIANT + /* III B, A.3 */ + && always (((lengthof(T1) + + lengthof(B1) + + lengthof(T2) + + lengthof(B2)) >= C) + implies ((lengthof(T1) + + lengthof(T2)) == C)) +#endif + /* TODO: III B, A.4 */ + + /* TODO: III B, A.5 */ + + /* IV A. */ + && always (p <= C) + +#ifdef DISCOVER_STATEPATH /* See arc.drv */ + /* + * Force spin to generate a "good" input trace (See: arc.drv) + * The handwavy reasoning here is that an absolutely full ARC + * would have had to exercise all codepaths to get there. + */ + && always !(true /* Syntactic glue */ + && lengthof(T1) == C +#if 1 /* Disable for easy demo. Enable to search harder */ + && lengthof(B1) == C + && lengthof(T2) == C +#endif + && lengthof(B2) == C + ) + +#endif +} \ No newline at end of file diff -urN arc-null/arc.pml arc/arc.pml --- arc-null/arc.pml 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc.pml 2023-09-28 06:47:31.494741428 +0000 @@ -0,0 +1,212 @@ +/* Spin process model for Adaptive Replacement Cache algorithm. Written by cherry */ + +/* + * We implement the following algorithm from page 10, Figure 4. + * https://www.usenix.org/legacy/events/fast03/tech/full_papers/megiddo/megiddo.pdf + * + * + * ARC(c) + * + * INPUT: The request stream x1,x2,....,xt,.... + * INITIALIZATION: Set p = 0 and set the LRU lists T1, B1, T2, and B2 to empty. + * + * For every t>=1 and any xt, one and only one of the following four cases must occur. + * Case I: xt is in T1 or T2. A cache hit has occurred in ARC(c) and DBL(2c). + * Move xt to MRU position in T2. + * + * Case II: xt is in B1. A cache miss (resp. hit) has occurred in ARC(c) (resp. DBL(2c)). + * ADAPTATION: Update p = min { p + d1,c } + * where d1 = { 1 if |B1| >= |B2|, |B2|/|B1| otherwise + * + * REPLACE(xt, p). Move xt from B1 to the MRU position in T2 (also fetch xt to the cache). + * + * Case III: xt is in B2. A cache miss (resp. hit) has occurred in ARC(c) (resp. DBL(2c)). + * ADAPTATION: Update p = max { p - d2,0 } + * where d2 = { 1 if |B2| >= |B1|, |B1|/|B2| otherwise + * + * REPLACE(xt, p). Move xt from B2 to the MRU position in T2 (also fetch xt to the cache). + * + * Case IV: xt is not in T1 U B1 U T2 U B2. A cache miss has occurred in ARC(c) and DBL(2c). + * Case A: L1 = T1 U B1 has exactly c pages. + * If (|T1| < c) + * Delete LRU page in B1. REPLACE(xt,p). + * else + * Here B1 is empty. Delete LRU page in T1 (also remove it from the cache). + * endif + * Case B: L1 = T1 U B1 has less than c pages. + * If (|T1| + |T2| + |B1| + |B2| >= c) + * Delete LRU page in B2, if (|T1| + |T2| + |B1| + |B2| = 2c). + * REPLACE(xt, p). + * endif + * + * Finally, fetch xt to the cache and move it to MRU position in T1. + * + * Subroutine REPLACE(xt,p) + * If ( (|T1| is not empty) and ((|T1| exceeds the target p) or (xt is in B2 and |T1| = p)) ) + * Delete the LRU page in T1 (also remove it from the cache), and move it to MRU position in B1. + * else + * Delete the LRU page in T2 (also remove it from the cache), and move it to MRU position in B2. + * endif + */ + +/* Temp variable to hold LRU item */ +arc_item LRUitem; + +/* Adaptation "delta" variables */ +hidden int d1, d2; +int p = 0; + +/* Declare arc lists - "shadow/ghost cache directories" */ +arc_list T1, T2, B1, B2; + +inline REPLACE(/* arc_item */ x_t, /* int */ p) +{ + /* + * Since LRUitem is declared in scope p_ARC, we expect it to be only accessible from there and REPLACE() + * as REPLACE() is only expected to be called from p_ARC. + * XXX: May need to revisit due to Modex related limitations. + */ + init_arc_item(LRUitem, IID_INVAL, false); + + if + :: + (lengthof(T1) != 0) && + ((lengthof(T1) > p) || (memberof(B2, x_t) && (lengthof(T1) == p))) + -> + { + readLRU(T1, LRUitem); + delLRU(T1); + cacheremove(LRUitem); + addMRU(B1, LRUitem); + } + + :: + else + -> + { + readLRU(T2, LRUitem); + delLRU(T2); + cacheremove(LRUitem); + addMRU(B2, LRUitem); + } + fi +} + +inline ARC(/* arc_item */ x_t) +{ + if + :: /* Case I */ + memberof(T1, x_t) + -> + { + delitem(T1, x_t); + addMRU(T2, x_t); + } + :: /* Case I */ + memberof(T2, x_t) + -> + { + delitem(T2, x_t); + addMRU(T2, x_t); + } + :: /* Case II */ + memberof(B1, x_t) + -> + d1 = ((lengthof(B1) >= lengthof(B2)) -> 1 : (lengthof(B2)/lengthof(B1))); + p = min((p + d1), C); + + REPLACE(x_t, p); + { + delitem(B1, x_t); + addMRU(T2, x_t); + cachefetch(x_t); + } + :: /* Case III */ + memberof(B2, x_t) + -> + d2 = ((lengthof(B2) >= lengthof(B1)) -> 1 : (lengthof(B1)/lengthof(B2))); + p = max(p - d2, 0); + + REPLACE(x_t, p); + { + delitem(B2, x_t); + addMRU(T2, x_t); + cachefetch(x_t); + } + :: /* Case IV */ + !(memberof(T1, x_t) || + memberof(B1, x_t) || + memberof(T2, x_t) || + memberof(B2, x_t)) + -> + if + :: /* Case A */ + ((lengthof(T1) + lengthof(B1)) == C) + -> + if + :: + (lengthof(T1) < C) + -> + delLRU(B1); + REPLACE(x_t, p); + :: + else + -> + assert(lengthof(B1) == 0); + { + readLRU(T1, LRUitem); + delLRU(T1); + cacheremove(LRUitem); + } + fi + :: /* Case B */ + ((lengthof(T1) + lengthof(B1)) < C) + -> + if + :: + ((lengthof(T1) + + lengthof(T2) + + lengthof(B1) + + lengthof(B2)) >= C) + -> + if + :: + ((lengthof(T1) + + lengthof(T2) + + lengthof(B1) + + lengthof(B2)) == (2 * C)) + -> + delLRU(B2); + :: + else + -> + skip; + fi + REPLACE(x_t, p); + :: + else + -> + skip; + fi + :: + else + -> + skip; + fi + cachefetch(x_t); + addMRU(T1, x_t); + fi + +} + +#if 0 /* Resolve this after modex extract foo */ +proctype p_arc(arc_item x_t) +{ + /* Serialise entry */ + mutex_enter(sc_lock); + + ARC(x_t); + + mutex_exit(sc_lock); +} +#endif diff -urN arc-null/arc.prx arc/arc.prx --- arc-null/arc.prx 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc.prx 2023-09-14 07:06:38.900036315 +0000 @@ -0,0 +1,80 @@ +// Spin model extractor harness written by cherry +// +%F arc.c +%X -n REPLACE +%X -n ARC +%H +// Disable effects of all included files and try to implement a subset of the APIs they provide. +#define _ARC_H_ +%% +//%C // c_code {} +//%% +//%D // c_cdecl {} +//%% +%L +// We use spin primitives and data objects. +// See %P Below +NonState hidden _LRUitem +NonState hidden LRUitem +NonState hidden _B2 +NonState hidden B2 +NonState hidden _B1 +NonState hidden B1 +NonState hidden _T2 +NonState hidden T2 +NonState hidden _T1 +NonState hidden T1 +NonState hidden x_t + + + +assert(... keep +REPLACE(... keep +init_arc_item(... keep +lengthof(... keep +memberof(... keep +addMRU(... keep +readLRU(... keep +delLRU(... keep +delitem(... keep +cacheremove(... keep +cachefetch(... keep + + +Substitute c_expr { ((lengthof(T1)!=0)&&((lengthof(T1)>now.p)||(memberof(B2,x_t)&&(lengthof(T1)==now.p)))) } (lengthof(T1) != 0) && ((lengthof(T1) > p) || (memberof(B2, x_t) && (lengthof(T1) == p))) +Substitute c_code { now.d1=((lengthof(B1)>=lengthof(B2)) ? Int 1\n : (lengthof(B2)/lengthof(B1))); } d1 = ((lengthof(B1) >= lengthof(B2)) -> 1 : (lengthof(B2)/lengthof(B1))) +Substitute c_code { now.p=min((now.p+now.d1),C); } p = min((p + d1), C) + +Substitute c_code { now.d2=((lengthof(B2)>=lengthof(B1)) ? Int 1\n : (lengthof(B1)/lengthof(B2))); } d2 = ((lengthof(B2) >= lengthof(B1)) -> 1 : (lengthof(B1)/lengthof(B2))); +Substitute c_code { now.p=max((now.p-now.d2),0); } p = max(p - d2, 0); +Substitute c_expr { (!(((memberof(T1,x_t)||memberof(B1,x_t))||memberof(T2,x_t))||memberof(B2,x_t))) } !(memberof(T1, x_t) || memberof(B1, x_t) || memberof(T2, x_t) || memberof(B2, x_t)) +Substitute c_expr { ((lengthof(T1)+lengthof(B1))==C) } ((lengthof(T1) + lengthof(B1)) == C) +Substitute c_expr { (lengthof(T1)=C) } ((lengthof(T1) + lengthof(T2) + lengthof(B1) + lengthof(B2)) >= C) +Substitute c_expr { ((((lengthof(T1)+lengthof(T2))+lengthof(B1))+lengthof(B2))==(2*C)) } ((lengthof(T1) + lengthof(T2) + lengthof(B1) + lengthof(B2)) == (2 * C)) +%% + +%P + +/* Temp variable to hold LRU item */ +hidden arc_item LRUitem; + +arc_list B1, B2, T1, T2; + +#define p_REPLACE(_arg1, _arg2) REPLACE(_arg1, _arg2) /* Demo arbitrary Cfunc->PMLproc transformation */ +inline p_REPLACE(/* arc_item */ x_t, /* int */ p) +{ + +#include "_modex_REPLACE.pml" + +} + +#define p_ARC(_arg1) ARC(_arg1) +inline p_ARC(/* arc_item */ x_t) +{ + +#include "_modex_ARC.pml" + +} +%% \ No newline at end of file diff -urN arc-null/arc_queue/arc.h arc/arc_queue/arc.h --- arc-null/arc_queue/arc.h 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc.h 2023-09-26 15:04:45.316426496 +0000 @@ -0,0 +1,170 @@ +/* + * The objective of the header here is to provide a set of macros that + * reflect the interfaces designed in arc.pmh + */ + +#ifndef _ARC_H_ +#define _ARC_H_ + +#ifdef MODEX +/* Glue for model extraction run */ +#else +/* Defaults to POSIX */ +#include +#include +#include +#endif + +#include "queue.h" /* We use the NetBSD version as it has no + * dependencies (except for -DNULL) . */ + +#define C 64 + +#define ARCLEN (2 * C) /* c.f ghost cache directory length constraints in arc.inv */ + +#define IID_INVAL -1 + +struct arc_item { + TAILQ_ENTRY(arc_item) qlink; + int iid; /* Unique identifier for item */ + bool cached; +}; + +struct arc_list { + TAILQ_HEAD(arc_qhead, arc_item) qhead; + int qcount; + struct arc_item item_list[ARCLEN]; /* We use static memory for demo purposes */ +}; + +inline static struct arc_item * allocmember(struct arc_list *); +inline static void freemember(struct arc_item *); +inline static struct arc_item * findmember(struct arc_list *, struct arc_item *); + +#define init_arc_item(/* &struct arc_item [] */ _arc_item_addr, \ + /* int */_iid, /*bool*/_cached) do { \ + struct arc_item *_arc_item = _arc_item_addr; \ + assert(_arc_item != NULL); \ + _arc_item->iid = _iid; \ + _arc_item->cached = _cached; \ + } while (/*CONSTCOND*/0) + +#define lengthof(/* struct arc_list* */_arc_list) (_arc_list->qcount) +#define memberof(/* struct arc_list* */_arc_list, \ + /* struct arc_item* */_arc_item) \ + ((findmember(_arc_list, \ + _arc_item) != TAILQ_END(&_arc_list->qhead)) ? \ + true : false) + +/* + * We follow spin's channel rx/tx semantics here: "send" means + * duplicate onto queue ("_arc_list.item_list!_arc_item.iid"), and + * recieve means "duplicate" from queue but leave the data source on + * queue ("_arc_list.item_list?<_arc_item.iid>"). + * + * It is an error to addMRU() on a full queue. Likewise, it is an + * error to readLRU() on an empty queue. The verifier is expected to + * have covered any case where these happen. We use assert()s to + * indicate the error. + * + * Note: We use spin's channel mechanism in our design, only because + * it's the easiest. We could have chosen another + * mechanism/implementation, if the semantics were specified + * differently due to, for eg: convention, architectural or efficiency + * reasons. + */ +#define addMRU(/* struct arc_list* */_arc_list, \ + /* struct arc_item* */_arc_item) do { \ + assert(_arc_list->qcount < ARCLEN); \ + struct arc_item *aitmp; aitmp = allocmember(_arc_list); \ + assert(aitmp != NULL); \ + *aitmp = *_arc_item; \ + TAILQ_INSERT_TAIL(&_arc_list->qhead, aitmp, qlink); \ + _arc_list->qcount++; \ + } while (/*CONSTCOND*/0) + +#define readLRU(/* struct arc_list* */_arc_list, \ + /* struct arc_item* */_arc_item) do { \ + assert(!TAILQ_EMPTY(&_arc_list->qhead)); \ + assert(_arc_item != NULL); \ + *_arc_item = *(struct arc_item *)TAILQ_FIRST(&_arc_list->qhead);\ + } while (/*CONSTCOND*/0) + +#define delLRU(/* struct arc_list* */_arc_list) \ + if (!TAILQ_EMPTY(&_arc_list->qhead)) { \ + struct arc_item *aitmp; aitmp = TAILQ_FIRST(&_arc_list->qhead); \ + TAILQ_REMOVE(&_arc_list->qhead, aitmp, qlink); \ + freemember(aitmp); \ + _arc_list->qcount--; assert(_arc_list->qcount >= 0); \ + } else assert(false) + +#define delitem(/* struct arc_list* */_arc_list, \ + /* struct arc_item* */_arc_item) do { \ + struct arc_item *aitmp; \ + aitmp = findmember(_arc_list, _arc_item); \ + if (aitmp != TAILQ_END(&_arc_list->qhead)) { \ + TAILQ_REMOVE(&_arc_list->qhead, aitmp, qlink); \ + freemember(aitmp); \ + _arc_list->qcount--; assert(_arc_list->qcount >= 0); \ + } \ + } while (/*CONSTCOND*/0) + +#define cachefetch(/* struct arc_item* */_arc_item) do { \ + _arc_item->cached = true; /* XXX:TODO */ \ + } while (/*CONSTCOND*/0) + +#define cacheremove(/* struct arc_item* */_arc_item) do { \ + _arc_item->cached = false; /* XXX:TODO */ \ + } while (/*CONSTCOND*/0) + +#define min(a, b) ((a < b) ? a : b) +#define max(a, b) ((a > b) ? a : b) + +/* These routines deal with our home-rolled mem management for the + * ghost cache directory memory embedded within statically defined + * struct arc_list buffers. + * Note that any pointers emerging from these should be treated as + * "opaque"/cookies - ie; they should not be assumed by other routines + * to have any specific properties (such as being part of any specific + * array etc.) They are solely for the consumption of these + * routines. Their contents however may be freely copied/written to. + */ +inline static struct arc_item * +allocmember(struct arc_list *_arc_list) +{ + /* Search for the first unallocated item in given list */ + struct arc_item *aitmp = NULL; + int i; + for (i = 0; i < ARCLEN; i++) { + if (_arc_list->item_list[i].iid == IID_INVAL) { + assert(_arc_list->item_list[i].cached == false); + aitmp = &_arc_list->item_list[i]; + } + } + return aitmp; +} + +inline static void +freemember(struct arc_item *aip) +{ + assert(aip != NULL); + init_arc_item(aip, IID_INVAL, false); +} + +static inline struct arc_item * +findmember(struct arc_list *_arc_list, struct arc_item *aikey) +{ + assert(_arc_list != NULL && aikey != NULL); + assert(aikey->iid != IID_INVAL); + struct arc_item *aitmp; + TAILQ_FOREACH(aitmp, &_arc_list->qhead, qlink) { + if (aitmp->iid == aikey->iid) { + return aitmp; + } + } + return aitmp; /* returns TAILQ_END() on non-membership */ +} + +void ARC(struct arc_item * /* x_t */); +void arc_init(void); + +#endif /* _ARC_H_ */ diff -urN arc-null/arc_queue/arc.pmh arc/arc_queue/arc.pmh --- arc-null/arc_queue/arc.pmh 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc.pmh 2023-09-28 05:13:29.106914626 +0000 @@ -0,0 +1,48 @@ +/* Spin process model for Adaptive Replacement Cache algorithm. Written by cherry */ + +#ifndef _ARC_INC +#define _ARC_INC + +#define EXPLORE_STATESPACE /* XXX: -D via Makefile ? */ + +#ifdef EXPLORE_STATESPACE +#define C 5 /* Cache size - use judiciously - adds to statespace */ +#else +#define C 64 /* Static input run - we can use default size */ +#endif + +#define ARCLEN C + +#define IID_INVAL -1 + +typedef arc_item { + int iid; /* Unique identifier for item */ + bool cached; +}; + +/* Note that we use the arc_item.iid as the member lookup handle to reduce state space */ +typedef arc_list { + chan item_list = [ ARCLEN ] of { int }; /* A list of page items */ +}; + + +#define init_arc_item(_arc_item, _iid, _cached) \ + { \ + _arc_item.iid = _iid; \ + _arc_item.cached = _cached; \ + } + +#define lengthof(_arc_list) len(_arc_list.item_list) +#define memberof(_arc_list, _arc_item) _arc_list.item_list??[eval(_arc_item.iid)] +#define addMRU(_arc_list, _arc_item) _arc_list.item_list!_arc_item.iid +#define readLRU(_arc_list, _arc_item) _arc_list.item_list?<_arc_item.iid> +#define delLRU(_arc_list) _arc_list.item_list?_ +#define delitem(_arc_list, _arc_item) if :: lengthof(_arc_list) > 0; _arc_list.item_list??eval(_arc_item.iid) :: else; skip; fi + +#define cachefetch(_arc_item) _arc_item.cached = true +#define cacheremove(_arc_item) _arc_item.cached = false + +#define min(a, b) ((a < b) -> a : b) +#define max(a, b) ((a > b) -> a : b) + +#endif /* _ARC_INC_ */ \ No newline at end of file diff -urN arc-null/arc_queue/arc_queue.c arc/arc_queue/arc_queue.c --- arc-null/arc_queue/arc_queue.c 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc_queue.c 2023-09-11 11:38:49.468321594 +0000 @@ -0,0 +1,26 @@ +/* Mostly to pull in macros into functions, so that modex can parse them */ + +#include "arc.h" + +void arc_addMRU(struct arc_list *Q, + struct arc_item *I) +{ + addMRU(Q, I); +} + +void arc_readLRU(struct arc_list *Q, + struct arc_item *I) +{ + readLRU(Q, I); +} + +void arc_delLRU(struct arc_list *Q) +{ + delLRU(Q); +} + +void arc_delitem(struct arc_list *Q, + struct arc_item *I) +{ + delitem(Q, I); +} diff -urN arc-null/arc_queue/arc_queue.drv arc/arc_queue/arc_queue.drv --- arc-null/arc_queue/arc_queue.drv 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc_queue.drv 2023-09-14 14:09:51.189956593 +0000 @@ -0,0 +1,43 @@ +/* Drive the procs */ + +arc_item _x; + +init { + + atomic { /* Load up Q */ + I.iid = 0; + do + :: I.iid < ARCLEN -> + p_arc_addMRU( /* Q, I */ ); + I.iid++; + :: I.iid >= ARCLEN -> + break; + od + } + + _x.iid = ARCLEN; + + atomic { /* Read and remove from head */ + do + :: _x.iid > (ARCLEN/2) -> + _x.iid--; + p_arc_readLRU( /* Q, I */ ); + assert(I.iid == (ARCLEN - (_x.iid + 1))); + p_arc_delLRU( /* Q */); + :: _x.iid <= (ARCLEN/2) -> + break; + od + } + + atomic { /* Remove from tail */ + do + :: _x.iid >= 0 -> /* delitem() semantics allow attempt on empty list */ + _x.iid--; + I.iid = _x.iid + ARCLEN/2; + p_arc_delitem( /* Q, I */); + :: _x.iid < 0 -> + break; + od + } + +} diff -urN arc-null/arc_queue/arc_queue_drv.c arc/arc_queue/arc_queue_drv.c --- arc-null/arc_queue/arc_queue_drv.c 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc_queue_drv.c 2023-09-13 10:04:05.819212718 +0000 @@ -0,0 +1,52 @@ +#include "arc.h" +#include "arc_queue.h" + +#include + +static void arc_list_init(struct arc_list *_arc_list) +{ + TAILQ_INIT(&_arc_list->qhead); + _arc_list->qcount = 0; + + int i; + for(i = 0; i < ARCLEN; i++) { + init_arc_item(&_arc_list->item_list[i], IID_INVAL, false); + }; +} + +void main(void) +{ + struct arc_list Q; + struct arc_item I, _x; + + arc_list_init(&Q); + + I.iid = 0; + + do { + printf("addMRU(): I.iid == %d\n", I.iid); + arc_addMRU(&Q, &I); + I.iid++; + } while(I.iid < ARCLEN); + + _x.iid = ARCLEN; + + do { + _x.iid--; + arc_readLRU(&Q, &I); + printf("readLRU(): I.iid == %d, _x.iid == %d\n", I.iid, _x.iid); + assert(I.iid == (ARCLEN - (_x.iid + 1))); + arc_delLRU(&Q); + } while(_x.iid > (ARCLEN/2)); + + + do { /* Remove from tail */ + _x.iid--; + I.iid = _x.iid + ARCLEN/2; + arc_delitem( &Q, &I); + printf("delitem(): I.iid == %d, _x.iid == %d\n", I.iid, _x.iid); + } while(_x.iid >= 0); /* delitem() semantics allow attempt on empty list */ + +} + + diff -urN arc-null/arc_queue/arc_queue.h arc/arc_queue/arc_queue.h --- arc-null/arc_queue/arc_queue.h 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc_queue.h 2023-09-11 09:23:01.999474035 +0000 @@ -0,0 +1,16 @@ +#ifndef _ARC_QUEUE_H_ +#define _ARC_QUEUE_H_ + +void arc_lengthof(struct arc_list *); + +void arc_memberof(struct arc_list *, struct arc_item *); + +void arc_addMRU(struct arc_list *, struct arc_item *); + +void arc_readLRU(struct arc_list *, struct arc_item *); + +void arc_delLRU(struct arc_list *); + +void arc_delitem(struct arc_list *, struct arc_item *); + +#endif /* _ARC_QUEUE_H_ */ diff -urN arc-null/arc_queue/arc_queue.inv arc/arc_queue/arc_queue.inv --- arc-null/arc_queue/arc_queue.inv 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc_queue.inv 2023-09-14 08:51:59.057339095 +0000 @@ -0,0 +1,17 @@ +/* These are Linear Temporal Logic invariants (and constraints) + * applied over the statespace created by the promela + * specification. Correctness is implied by Logical consistency. + */ +ltl +{ + /* Liveness - all threads, except control must finally exit */ + eventually always (_nr_pr == 1) && + + eventually (len(Q.item_list) == ARCLEN) && /* We fill up Q first */ + + eventually always (len(Q.item_list) == 0) && /* We drain the Q in the end */ + + true + + +} \ No newline at end of file diff -urN arc-null/arc_queue/arc_queue.pmh arc/arc_queue/arc_queue.pmh --- arc-null/arc_queue/arc_queue.pmh 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc_queue.pmh 2023-09-13 08:02:28.647475795 +0000 @@ -0,0 +1,23 @@ +#define C 64 + +#define ARCLEN (2 * C) + +#define IID_INVAL -1 + +typedef arc_item { + int iid; +} + +/* Note that we use the arc_item.iid as the member lookup handle to reduce state space */ +typedef arc_list { + chan item_list = [ ARCLEN ] of { int }; /* A list of page items */ +}; + +#define TAILQ_INSERT_TAIL(_qh, _var, _ent) _qh ! _var.iid +#define TAILQ_EMPTY(_qh) (len(_qh) == 0) +#define TAILQ_REMOVE(_qh, _var, _ent) _qh ?? eval(_var.iid) +#define TAILQ_FIRST(_qh, _var) _qh ? <_var.iid> +#define TAILQ_END(_qh) IID_INVAL +#define allocmember(_arc_list, _aitmp) skip; _aitmp.iid = IID_INVAL +#define freemember(_arc_item) _arc_item.iid = IID_INVAL +#define findmember(_arc_list, _arc_item) (TAILQ_EMPTY(_arc_list.item_list) -> TAILQ_END(_arc_list.item_list) : (_arc_list.item_list ?? [eval(_arc_item.iid)] -> _arc_item.iid : IID_INVAL)) diff -urN arc-null/arc_queue/arc_queue.pml arc/arc_queue/arc_queue.pml --- arc-null/arc_queue/arc_queue.pml 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc_queue.pml 2023-09-14 07:01:26.549121004 +0000 @@ -0,0 +1,29 @@ +/* This model fronts the "equivalance" model which is exported. + * The idea here is to drive it identically in such a way that + * invariants hold from both the extracted, as well as the + * hand-crafted model. + */ + +int qcount; +arc_item I; +arc_list Q; + +inline p_arc_delitem() +{ + delitem(Q, I); +} + +inline p_arc_delLRU() +{ + delLRU(Q); +} + +inline p_arc_readLRU() +{ + readLRU(Q, I); +} + +inline p_arc_addMRU() +{ + addMRU(Q, I); +} \ No newline at end of file diff -urN arc-null/arc_queue/arc_queue.prx arc/arc_queue/arc_queue.prx --- arc-null/arc_queue/arc_queue.prx 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/arc_queue.prx 2023-09-13 07:51:32.144705226 +0000 @@ -0,0 +1,51 @@ +// Spin model extractor harness written by cherry +// +%F arc_queue.c +%X -i arc_addMRU +%X -i arc_readLRU +%X -i arc_delLRU +%X -i arc_delitem +%H +// arc.h glue +#define bool int +#define false 0 +#define _SYS_QUEUE_H_ /* Don't expand queue.h macros, as we model them */ + +%% +//%C // c_code {} +//%% +//%D // c_cdecl {} +//%% +%L +// We use spin primitives and data objects. +// See %P Below +NonState hidden Q +NonState hidden I +NonState hidden aitmp + + +Substitute c_code [Q] { Q->qcount--; } qcount-- +Substitute c_code [Q] { Q->qcount++; } qcount++ +Substitute c_code [(Q->qcount>=0)] { ; } assert(qcount >= 0) +Substitute c_code { aitmp=findmember(Q,I); } aitmp.iid=findmember(Q, I) +Substitute c_expr { (aitmp!=TAILQ_END((&(Q->qhead)))) } (aitmp.iid != TAILQ_END(Q.item_list)) +Substitute c_code [Q] { TAILQ_REMOVE((&(Q->qhead)),aitmp,qlink); } TAILQ_REMOVE(Q.item_list, aitmp, _) +Substitute c_code { freemember(aitmp); } freemember(aitmp) +Substitute c_expr { (!TAILQ_EMPTY((&(Q->qhead)))) } (!TAILQ_EMPTY(Q.item_list)) +Substitute c_code [(!TAILQ_EMPTY((&(Q->qhead))))] { ; } assert((!TAILQ_EMPTY(Q.item_list))) +Substitute c_code [(I!=NULL)] { ; } assert(I.iid != IID_INVAL) +Substitute c_code [Q && (struct arc_item *)TAILQ_FIRST((&(Q->qhead))) && I] { (*I)=(*((struct arc_item *)TAILQ_FIRST((&(Q->qhead))))); } TAILQ_FIRST(Q.item_list, I) +Substitute c_code [(Q->qcount<(2*64))] { ; } assert(qcount < ARCLEN) +Substitute c_code [(aitmp!=NULL)] { ; } assert(aitmp.iid == IID_INVAL) +Substitute c_code [I && aitmp] { (*aitmp)=(*I); } aitmp.iid = I.iid +Substitute c_code [Q] { TAILQ_INSERT_TAIL((&(Q->qhead)),aitmp,qlink); } TAILQ_INSERT_TAIL(Q.item_list, aitmp, _); aitmp.iid = IID_INVAL +Substitute c_code { aitmp=allocmember(Q); } allocmember(Q.item_list, aitmp) +Substitute c_code [Q] { aitmp=TAILQ_FIRST((&(Q->qhead))); } TAILQ_FIRST(Q.item_list, aitmp) +%% + +%P +int qcount; +hidden arc_item aitmp; +arc_item I; +arc_list Q; +%% \ No newline at end of file diff -urN arc-null/arc_queue/Makefile arc/arc_queue/Makefile --- arc-null/arc_queue/Makefile 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/Makefile 2023-09-14 14:07:27.103171180 +0000 @@ -0,0 +1,62 @@ +# Equivalence verification +# We attempt to verify that the arc queue implementation in C is consistent with its model. +# Note that the simplified model is in arc_queue/arc.pmh and the C +# implementation equivalent model is in arc_queue/arc_queue.pmh +# +# Thus, spin-gen: uses arc.pmh as the model interface, whereas +# modex-gen: uses arc_queue.pmh + +spin-gen: arc_queue.pml arc_queue.drv arc_queue.inv + cp arc_queue.pml model #mimic modex + cat arc.pmh model > spinmodel.pml;cat arc_queue.drv >> spinmodel.pml;cat arc_queue.inv >> spinmodel.pml; + spin -am spinmodel.pml + +spin-build: #Could be spin-gen or modex-gen + cc -DVECTORSZ=65536 -o pan pan.c + +all: spin-gen spin-build prog + +# Verification related targets. +spin-run: spin-build + ./pan -a #Generate arc.pml.trail on error + +# You run the trace only if the spin run above failed and created a trail +spin-trace: spinmodel.pml.trail + spin -t spinmodel.pml -p -g # -p (statements) -g (globals) -l (locals) -s (send) -r (recv) + ./pan -r spinmodel.pml.trail -g + +# Build the implementation +prog: arc_queue.c arc.h + cc -g -o arc_queue arc_queue_drv.c arc_queue.c + +# Modex Extracts from C code to 'model' - see arc_queue.prx +modex-gen: arc_queue.prx arc_queue.c + modex -v -w arc_queue.prx + cat arc_queue.pmh model > spinmodel.pml;cat arc_queue.drv >> spinmodel.pml;cat arc_queue.inv >> spinmodel.pml; + spin -a spinmodel.pml #Sanity check + +# Housekeeping +modex-gen-clean: + rm -f spinmodel.pml # Our consolidated model file + rm -f _spin_nvr.tmp # Never claim file + rm -f model # modex generated intermediate "model" file + rm -f pan.* # Spin generated source files + rm -f _modex* # modex generated script files + rm -f *.I *.M + +prog-clean: + rm -f arc_queue +spin-run-clean: + rm -f spinmodel.pml.trail + +spin-build-clean: + rm -f pan + +spin-gen-clean: + rm -f spinmodel.pml # Our consolidated model file + rm -f _spin_nvr.tmp # Never claim file + rm -f model # Intermediate "model" file + rm -f pan.* # Spin generated source files + +clean: modex-gen-clean spin-gen-clean spin-build-clean spin-run-clean prog-clean + rm -f *~ diff -urN arc-null/arc_queue/queue.h arc/arc_queue/queue.h --- arc-null/arc_queue/queue.h 1970-01-01 00:00:00.000000000 +0000 +++ arc/arc_queue/queue.h 2023-09-11 04:48:17.669520444 +0000 @@ -0,0 +1,655 @@ +/* $NetBSD: queue.h,v 1.76 2021/01/16 23:51:51 chs Exp $ */ + +/* + * Copyright (c) 1991, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)queue.h 8.5 (Berkeley) 8/20/94 + */ + +#ifndef _SYS_QUEUE_H_ +#define _SYS_QUEUE_H_ + +/* + * This file defines five types of data structures: singly-linked lists, + * lists, simple queues, tail queues, and circular queues. + * + * A singly-linked list is headed by a single forward pointer. The + * elements are singly linked for minimum space and pointer manipulation + * overhead at the expense of O(n) removal for arbitrary elements. New + * elements can be added to the list after an existing element or at the + * head of the list. Elements being removed from the head of the list + * should use the explicit macro for this purpose for optimum + * efficiency. A singly-linked list may only be traversed in the forward + * direction. Singly-linked lists are ideal for applications with large + * datasets and few or no removals or for implementing a LIFO queue. + * + * A list is headed by a single forward pointer (or an array of forward + * pointers for a hash table header). The elements are doubly linked + * so that an arbitrary element can be removed without a need to + * traverse the list. New elements can be added to the list before + * or after an existing element or at the head of the list. A list + * may only be traversed in the forward direction. + * + * A simple queue is headed by a pair of pointers, one the head of the + * list and the other to the tail of the list. The elements are singly + * linked to save space, so elements can only be removed from the + * head of the list. New elements can be added to the list after + * an existing element, at the head of the list, or at the end of the + * list. A simple queue may only be traversed in the forward direction. + * + * A tail queue is headed by a pair of pointers, one to the head of the + * list and the other to the tail of the list. The elements are doubly + * linked so that an arbitrary element can be removed without a need to + * traverse the list. New elements can be added to the list before or + * after an existing element, at the head of the list, or at the end of + * the list. A tail queue may be traversed in either direction. + * + * For details on the use of these macros, see the queue(3) manual page. + */ + +/* + * Include the definition of NULL only on NetBSD because sys/null.h + * is not available elsewhere. This conditional makes the header + * portable and it can simply be dropped verbatim into any system. + * The caveat is that on other systems some other header + * must provide NULL before the macros can be used. + */ +#ifdef __NetBSD__ +#include +#endif + +#if defined(_KERNEL) && defined(DIAGNOSTIC) +#define QUEUEDEBUG 1 +#endif + +#if defined(QUEUEDEBUG) +# if defined(_KERNEL) +# define QUEUEDEBUG_ABORT(...) panic(__VA_ARGS__) +# else +# include +# define QUEUEDEBUG_ABORT(...) err(1, __VA_ARGS__) +# endif +#endif + +/* + * Singly-linked List definitions. + */ +#define SLIST_HEAD(name, type) \ +struct name { \ + struct type *slh_first; /* first element */ \ +} + +#define SLIST_HEAD_INITIALIZER(head) \ + { NULL } + +#define SLIST_ENTRY(type) \ +struct { \ + struct type *sle_next; /* next element */ \ +} + +/* + * Singly-linked List access methods. + */ +#define SLIST_FIRST(head) ((head)->slh_first) +#define SLIST_END(head) NULL +#define SLIST_EMPTY(head) ((head)->slh_first == NULL) +#define SLIST_NEXT(elm, field) ((elm)->field.sle_next) + +#define SLIST_FOREACH(var, head, field) \ + for((var) = (head)->slh_first; \ + (var) != SLIST_END(head); \ + (var) = (var)->field.sle_next) + +#define SLIST_FOREACH_SAFE(var, head, field, tvar) \ + for ((var) = SLIST_FIRST((head)); \ + (var) != SLIST_END(head) && \ + ((tvar) = SLIST_NEXT((var), field), 1); \ + (var) = (tvar)) + +/* + * Singly-linked List functions. + */ +#define SLIST_INIT(head) do { \ + (head)->slh_first = SLIST_END(head); \ +} while (/*CONSTCOND*/0) + +#define SLIST_INSERT_AFTER(slistelm, elm, field) do { \ + (elm)->field.sle_next = (slistelm)->field.sle_next; \ + (slistelm)->field.sle_next = (elm); \ +} while (/*CONSTCOND*/0) + +#define SLIST_INSERT_HEAD(head, elm, field) do { \ + (elm)->field.sle_next = (head)->slh_first; \ + (head)->slh_first = (elm); \ +} while (/*CONSTCOND*/0) + +#define SLIST_REMOVE_AFTER(slistelm, field) do { \ + (slistelm)->field.sle_next = \ + SLIST_NEXT(SLIST_NEXT((slistelm), field), field); \ +} while (/*CONSTCOND*/0) + +#define SLIST_REMOVE_HEAD(head, field) do { \ + (head)->slh_first = (head)->slh_first->field.sle_next; \ +} while (/*CONSTCOND*/0) + +#define SLIST_REMOVE(head, elm, type, field) do { \ + if ((head)->slh_first == (elm)) { \ + SLIST_REMOVE_HEAD((head), field); \ + } \ + else { \ + struct type *curelm = (head)->slh_first; \ + while(curelm->field.sle_next != (elm)) \ + curelm = curelm->field.sle_next; \ + curelm->field.sle_next = \ + curelm->field.sle_next->field.sle_next; \ + } \ +} while (/*CONSTCOND*/0) + + +/* + * List definitions. + */ +#define LIST_HEAD(name, type) \ +struct name { \ + struct type *lh_first; /* first element */ \ +} + +#define LIST_HEAD_INITIALIZER(head) \ + { NULL } + +#define LIST_ENTRY(type) \ +struct { \ + struct type *le_next; /* next element */ \ + struct type **le_prev; /* address of previous next element */ \ +} + +/* + * List access methods. + */ +#define LIST_FIRST(head) ((head)->lh_first) +#define LIST_END(head) NULL +#define LIST_EMPTY(head) ((head)->lh_first == LIST_END(head)) +#define LIST_NEXT(elm, field) ((elm)->field.le_next) + +#define LIST_FOREACH(var, head, field) \ + for ((var) = ((head)->lh_first); \ + (var) != LIST_END(head); \ + (var) = ((var)->field.le_next)) + +#define LIST_FOREACH_SAFE(var, head, field, tvar) \ + for ((var) = LIST_FIRST((head)); \ + (var) != LIST_END(head) && \ + ((tvar) = LIST_NEXT((var), field), 1); \ + (var) = (tvar)) + +#define LIST_MOVE(head1, head2, field) do { \ + LIST_INIT((head2)); \ + if (!LIST_EMPTY((head1))) { \ + (head2)->lh_first = (head1)->lh_first; \ + (head2)->lh_first->field.le_prev = &(head2)->lh_first; \ + LIST_INIT((head1)); \ + } \ +} while (/*CONSTCOND*/0) + +/* + * List functions. + */ +#if defined(QUEUEDEBUG) +#define QUEUEDEBUG_LIST_INSERT_HEAD(head, elm, field) \ + if ((head)->lh_first && \ + (head)->lh_first->field.le_prev != &(head)->lh_first) \ + QUEUEDEBUG_ABORT("LIST_INSERT_HEAD %p %s:%d", (head), \ + __FILE__, __LINE__); +#define QUEUEDEBUG_LIST_OP(elm, field) \ + if ((elm)->field.le_next && \ + (elm)->field.le_next->field.le_prev != \ + &(elm)->field.le_next) \ + QUEUEDEBUG_ABORT("LIST_* forw %p %s:%d", (elm), \ + __FILE__, __LINE__); \ + if (*(elm)->field.le_prev != (elm)) \ + QUEUEDEBUG_ABORT("LIST_* back %p %s:%d", (elm), \ + __FILE__, __LINE__); +#define QUEUEDEBUG_LIST_POSTREMOVE(elm, field) \ + (elm)->field.le_next = (void *)1L; \ + (elm)->field.le_prev = (void *)1L; +#else +#define QUEUEDEBUG_LIST_INSERT_HEAD(head, elm, field) +#define QUEUEDEBUG_LIST_OP(elm, field) +#define QUEUEDEBUG_LIST_POSTREMOVE(elm, field) +#endif + +#define LIST_INIT(head) do { \ + (head)->lh_first = LIST_END(head); \ +} while (/*CONSTCOND*/0) + +#define LIST_INSERT_AFTER(listelm, elm, field) do { \ + QUEUEDEBUG_LIST_OP((listelm), field) \ + if (((elm)->field.le_next = (listelm)->field.le_next) != \ + LIST_END(head)) \ + (listelm)->field.le_next->field.le_prev = \ + &(elm)->field.le_next; \ + (listelm)->field.le_next = (elm); \ + (elm)->field.le_prev = &(listelm)->field.le_next; \ +} while (/*CONSTCOND*/0) + +#define LIST_INSERT_BEFORE(listelm, elm, field) do { \ + QUEUEDEBUG_LIST_OP((listelm), field) \ + (elm)->field.le_prev = (listelm)->field.le_prev; \ + (elm)->field.le_next = (listelm); \ + *(listelm)->field.le_prev = (elm); \ + (listelm)->field.le_prev = &(elm)->field.le_next; \ +} while (/*CONSTCOND*/0) + +#define LIST_INSERT_HEAD(head, elm, field) do { \ + QUEUEDEBUG_LIST_INSERT_HEAD((head), (elm), field) \ + if (((elm)->field.le_next = (head)->lh_first) != LIST_END(head))\ + (head)->lh_first->field.le_prev = &(elm)->field.le_next;\ + (head)->lh_first = (elm); \ + (elm)->field.le_prev = &(head)->lh_first; \ +} while (/*CONSTCOND*/0) + +#define LIST_REMOVE(elm, field) do { \ + QUEUEDEBUG_LIST_OP((elm), field) \ + if ((elm)->field.le_next != NULL) \ + (elm)->field.le_next->field.le_prev = \ + (elm)->field.le_prev; \ + *(elm)->field.le_prev = (elm)->field.le_next; \ + QUEUEDEBUG_LIST_POSTREMOVE((elm), field) \ +} while (/*CONSTCOND*/0) + +#define LIST_REPLACE(elm, elm2, field) do { \ + if (((elm2)->field.le_next = (elm)->field.le_next) != NULL) \ + (elm2)->field.le_next->field.le_prev = \ + &(elm2)->field.le_next; \ + (elm2)->field.le_prev = (elm)->field.le_prev; \ + *(elm2)->field.le_prev = (elm2); \ + QUEUEDEBUG_LIST_POSTREMOVE((elm), field) \ +} while (/*CONSTCOND*/0) + +/* + * Simple queue definitions. + */ +#define SIMPLEQ_HEAD(name, type) \ +struct name { \ + struct type *sqh_first; /* first element */ \ + struct type **sqh_last; /* addr of last next element */ \ +} + +#define SIMPLEQ_HEAD_INITIALIZER(head) \ + { NULL, &(head).sqh_first } + +#define SIMPLEQ_ENTRY(type) \ +struct { \ + struct type *sqe_next; /* next element */ \ +} + +/* + * Simple queue access methods. + */ +#define SIMPLEQ_FIRST(head) ((head)->sqh_first) +#define SIMPLEQ_END(head) NULL +#define SIMPLEQ_EMPTY(head) ((head)->sqh_first == SIMPLEQ_END(head)) +#define SIMPLEQ_NEXT(elm, field) ((elm)->field.sqe_next) + +#define SIMPLEQ_FOREACH(var, head, field) \ + for ((var) = ((head)->sqh_first); \ + (var) != SIMPLEQ_END(head); \ + (var) = ((var)->field.sqe_next)) + +#define SIMPLEQ_FOREACH_SAFE(var, head, field, next) \ + for ((var) = ((head)->sqh_first); \ + (var) != SIMPLEQ_END(head) && \ + ((next = ((var)->field.sqe_next)), 1); \ + (var) = (next)) + +/* + * Simple queue functions. + */ +#define SIMPLEQ_INIT(head) do { \ + (head)->sqh_first = NULL; \ + (head)->sqh_last = &(head)->sqh_first; \ +} while (/*CONSTCOND*/0) + +#define SIMPLEQ_INSERT_HEAD(head, elm, field) do { \ + if (((elm)->field.sqe_next = (head)->sqh_first) == NULL) \ + (head)->sqh_last = &(elm)->field.sqe_next; \ + (head)->sqh_first = (elm); \ +} while (/*CONSTCOND*/0) + +#define SIMPLEQ_INSERT_TAIL(head, elm, field) do { \ + (elm)->field.sqe_next = NULL; \ + *(head)->sqh_last = (elm); \ + (head)->sqh_last = &(elm)->field.sqe_next; \ +} while (/*CONSTCOND*/0) + +#define SIMPLEQ_INSERT_AFTER(head, listelm, elm, field) do { \ + if (((elm)->field.sqe_next = (listelm)->field.sqe_next) == NULL)\ + (head)->sqh_last = &(elm)->field.sqe_next; \ + (listelm)->field.sqe_next = (elm); \ +} while (/*CONSTCOND*/0) + +#define SIMPLEQ_REMOVE_HEAD(head, field) do { \ + if (((head)->sqh_first = (head)->sqh_first->field.sqe_next) == NULL) \ + (head)->sqh_last = &(head)->sqh_first; \ +} while (/*CONSTCOND*/0) + +#define SIMPLEQ_REMOVE_AFTER(head, elm, field) do { \ + if (((elm)->field.sqe_next = (elm)->field.sqe_next->field.sqe_next) \ + == NULL) \ + (head)->sqh_last = &(elm)->field.sqe_next; \ +} while (/*CONSTCOND*/0) + +#define SIMPLEQ_REMOVE(head, elm, type, field) do { \ + if ((head)->sqh_first == (elm)) { \ + SIMPLEQ_REMOVE_HEAD((head), field); \ + } else { \ + struct type *curelm = (head)->sqh_first; \ + while (curelm->field.sqe_next != (elm)) \ + curelm = curelm->field.sqe_next; \ + if ((curelm->field.sqe_next = \ + curelm->field.sqe_next->field.sqe_next) == NULL) \ + (head)->sqh_last = &(curelm)->field.sqe_next; \ + } \ +} while (/*CONSTCOND*/0) + +#define SIMPLEQ_CONCAT(head1, head2) do { \ + if (!SIMPLEQ_EMPTY((head2))) { \ + *(head1)->sqh_last = (head2)->sqh_first; \ + (head1)->sqh_last = (head2)->sqh_last; \ + SIMPLEQ_INIT((head2)); \ + } \ +} while (/*CONSTCOND*/0) + +#define SIMPLEQ_LAST(head, type, field) \ + (SIMPLEQ_EMPTY((head)) ? \ + NULL : \ + ((struct type *)(void *) \ + ((char *)((head)->sqh_last) - offsetof(struct type, field)))) + +/* + * Tail queue definitions. + */ +#define _TAILQ_HEAD(name, type, qual) \ +struct name { \ + qual type *tqh_first; /* first element */ \ + qual type *qual *tqh_last; /* addr of last next element */ \ +} +#define TAILQ_HEAD(name, type) _TAILQ_HEAD(name, struct type,) + +#define TAILQ_HEAD_INITIALIZER(head) \ + { TAILQ_END(head), &(head).tqh_first } + +#define _TAILQ_ENTRY(type, qual) \ +struct { \ + qual type *tqe_next; /* next element */ \ + qual type *qual *tqe_prev; /* address of previous next element */\ +} +#define TAILQ_ENTRY(type) _TAILQ_ENTRY(struct type,) + +/* + * Tail queue access methods. + */ +#define TAILQ_FIRST(head) ((head)->tqh_first) +#define TAILQ_END(head) (NULL) +#define TAILQ_NEXT(elm, field) ((elm)->field.tqe_next) +#define TAILQ_LAST(head, headname) \ + (*(((struct headname *)(void *)((head)->tqh_last))->tqh_last)) +#define TAILQ_PREV(elm, headname, field) \ + (*(((struct headname *)(void *)((elm)->field.tqe_prev))->tqh_last)) +#define TAILQ_EMPTY(head) (TAILQ_FIRST(head) == TAILQ_END(head)) + + +#define TAILQ_FOREACH(var, head, field) \ + for ((var) = ((head)->tqh_first); \ + (var) != TAILQ_END(head); \ + (var) = ((var)->field.tqe_next)) + +#define TAILQ_FOREACH_SAFE(var, head, field, next) \ + for ((var) = ((head)->tqh_first); \ + (var) != TAILQ_END(head) && \ + ((next) = TAILQ_NEXT(var, field), 1); (var) = (next)) + +#define TAILQ_FOREACH_REVERSE(var, head, headname, field) \ + for ((var) = TAILQ_LAST((head), headname); \ + (var) != TAILQ_END(head); \ + (var) = TAILQ_PREV((var), headname, field)) + +#define TAILQ_FOREACH_REVERSE_SAFE(var, head, headname, field, prev) \ + for ((var) = TAILQ_LAST((head), headname); \ + (var) != TAILQ_END(head) && \ + ((prev) = TAILQ_PREV((var), headname, field), 1); (var) = (prev)) + +/* + * Tail queue functions. + */ +#if defined(QUEUEDEBUG) +#define QUEUEDEBUG_TAILQ_INSERT_HEAD(head, elm, field) \ + if ((head)->tqh_first && \ + (head)->tqh_first->field.tqe_prev != &(head)->tqh_first) \ + QUEUEDEBUG_ABORT("TAILQ_INSERT_HEAD %p %s:%d", (head), \ + __FILE__, __LINE__); +#define QUEUEDEBUG_TAILQ_INSERT_TAIL(head, elm, field) \ + if (*(head)->tqh_last != NULL) \ + QUEUEDEBUG_ABORT("TAILQ_INSERT_TAIL %p %s:%d", (head), \ + __FILE__, __LINE__); +#define QUEUEDEBUG_TAILQ_OP(elm, field) \ + if ((elm)->field.tqe_next && \ + (elm)->field.tqe_next->field.tqe_prev != \ + &(elm)->field.tqe_next) \ + QUEUEDEBUG_ABORT("TAILQ_* forw %p %s:%d", (elm), \ + __FILE__, __LINE__); \ + if (*(elm)->field.tqe_prev != (elm)) \ + QUEUEDEBUG_ABORT("TAILQ_* back %p %s:%d", (elm), \ + __FILE__, __LINE__); +#define QUEUEDEBUG_TAILQ_PREREMOVE(head, elm, field) \ + if ((elm)->field.tqe_next == NULL && \ + (head)->tqh_last != &(elm)->field.tqe_next) \ + QUEUEDEBUG_ABORT("TAILQ_PREREMOVE head %p elm %p %s:%d",\ + (head), (elm), __FILE__, __LINE__); +#define QUEUEDEBUG_TAILQ_POSTREMOVE(elm, field) \ + (elm)->field.tqe_next = (void *)1L; \ + (elm)->field.tqe_prev = (void *)1L; +#else +#define QUEUEDEBUG_TAILQ_INSERT_HEAD(head, elm, field) +#define QUEUEDEBUG_TAILQ_INSERT_TAIL(head, elm, field) +#define QUEUEDEBUG_TAILQ_OP(elm, field) +#define QUEUEDEBUG_TAILQ_PREREMOVE(head, elm, field) +#define QUEUEDEBUG_TAILQ_POSTREMOVE(elm, field) +#endif + +#define TAILQ_INIT(head) do { \ + (head)->tqh_first = TAILQ_END(head); \ + (head)->tqh_last = &(head)->tqh_first; \ +} while (/*CONSTCOND*/0) + +#define TAILQ_INSERT_HEAD(head, elm, field) do { \ + QUEUEDEBUG_TAILQ_INSERT_HEAD((head), (elm), field) \ + if (((elm)->field.tqe_next = (head)->tqh_first) != TAILQ_END(head))\ + (head)->tqh_first->field.tqe_prev = \ + &(elm)->field.tqe_next; \ + else \ + (head)->tqh_last = &(elm)->field.tqe_next; \ + (head)->tqh_first = (elm); \ + (elm)->field.tqe_prev = &(head)->tqh_first; \ +} while (/*CONSTCOND*/0) + +#define TAILQ_INSERT_TAIL(head, elm, field) do { \ + QUEUEDEBUG_TAILQ_INSERT_TAIL((head), (elm), field) \ + (elm)->field.tqe_next = TAILQ_END(head); \ + (elm)->field.tqe_prev = (head)->tqh_last; \ + *(head)->tqh_last = (elm); \ + (head)->tqh_last = &(elm)->field.tqe_next; \ +} while (/*CONSTCOND*/0) + +#define TAILQ_INSERT_AFTER(head, listelm, elm, field) do { \ + QUEUEDEBUG_TAILQ_OP((listelm), field) \ + if (((elm)->field.tqe_next = (listelm)->field.tqe_next) != \ + TAILQ_END(head)) \ + (elm)->field.tqe_next->field.tqe_prev = \ + &(elm)->field.tqe_next; \ + else \ + (head)->tqh_last = &(elm)->field.tqe_next; \ + (listelm)->field.tqe_next = (elm); \ + (elm)->field.tqe_prev = &(listelm)->field.tqe_next; \ +} while (/*CONSTCOND*/0) + +#define TAILQ_INSERT_BEFORE(listelm, elm, field) do { \ + QUEUEDEBUG_TAILQ_OP((listelm), field) \ + (elm)->field.tqe_prev = (listelm)->field.tqe_prev; \ + (elm)->field.tqe_next = (listelm); \ + *(listelm)->field.tqe_prev = (elm); \ + (listelm)->field.tqe_prev = &(elm)->field.tqe_next; \ +} while (/*CONSTCOND*/0) + +#define TAILQ_REMOVE(head, elm, field) do { \ + QUEUEDEBUG_TAILQ_PREREMOVE((head), (elm), field) \ + QUEUEDEBUG_TAILQ_OP((elm), field) \ + if (((elm)->field.tqe_next) != TAILQ_END(head)) \ + (elm)->field.tqe_next->field.tqe_prev = \ + (elm)->field.tqe_prev; \ + else \ + (head)->tqh_last = (elm)->field.tqe_prev; \ + *(elm)->field.tqe_prev = (elm)->field.tqe_next; \ + QUEUEDEBUG_TAILQ_POSTREMOVE((elm), field); \ +} while (/*CONSTCOND*/0) + +#define TAILQ_REPLACE(head, elm, elm2, field) do { \ + if (((elm2)->field.tqe_next = (elm)->field.tqe_next) != \ + TAILQ_END(head)) \ + (elm2)->field.tqe_next->field.tqe_prev = \ + &(elm2)->field.tqe_next; \ + else \ + (head)->tqh_last = &(elm2)->field.tqe_next; \ + (elm2)->field.tqe_prev = (elm)->field.tqe_prev; \ + *(elm2)->field.tqe_prev = (elm2); \ + QUEUEDEBUG_TAILQ_POSTREMOVE((elm), field); \ +} while (/*CONSTCOND*/0) + +#define TAILQ_CONCAT(head1, head2, field) do { \ + if (!TAILQ_EMPTY(head2)) { \ + *(head1)->tqh_last = (head2)->tqh_first; \ + (head2)->tqh_first->field.tqe_prev = (head1)->tqh_last; \ + (head1)->tqh_last = (head2)->tqh_last; \ + TAILQ_INIT((head2)); \ + } \ +} while (/*CONSTCOND*/0) + +/* + * Singly-linked Tail queue declarations. + */ +#define STAILQ_HEAD(name, type) \ +struct name { \ + struct type *stqh_first; /* first element */ \ + struct type **stqh_last; /* addr of last next element */ \ +} + +#define STAILQ_HEAD_INITIALIZER(head) \ + { NULL, &(head).stqh_first } + +#define STAILQ_ENTRY(type) \ +struct { \ + struct type *stqe_next; /* next element */ \ +} + +/* + * Singly-linked Tail queue access methods. + */ +#define STAILQ_FIRST(head) ((head)->stqh_first) +#define STAILQ_END(head) NULL +#define STAILQ_NEXT(elm, field) ((elm)->field.stqe_next) +#define STAILQ_EMPTY(head) (STAILQ_FIRST(head) == STAILQ_END(head)) + +/* + * Singly-linked Tail queue functions. + */ +#define STAILQ_INIT(head) do { \ + (head)->stqh_first = NULL; \ + (head)->stqh_last = &(head)->stqh_first; \ +} while (/*CONSTCOND*/0) + +#define STAILQ_INSERT_HEAD(head, elm, field) do { \ + if (((elm)->field.stqe_next = (head)->stqh_first) == NULL) \ + (head)->stqh_last = &(elm)->field.stqe_next; \ + (head)->stqh_first = (elm); \ +} while (/*CONSTCOND*/0) + +#define STAILQ_INSERT_TAIL(head, elm, field) do { \ + (elm)->field.stqe_next = NULL; \ + *(head)->stqh_last = (elm); \ + (head)->stqh_last = &(elm)->field.stqe_next; \ +} while (/*CONSTCOND*/0) + +#define STAILQ_INSERT_AFTER(head, listelm, elm, field) do { \ + if (((elm)->field.stqe_next = (listelm)->field.stqe_next) == NULL)\ + (head)->stqh_last = &(elm)->field.stqe_next; \ + (listelm)->field.stqe_next = (elm); \ +} while (/*CONSTCOND*/0) + +#define STAILQ_REMOVE_HEAD(head, field) do { \ + if (((head)->stqh_first = (head)->stqh_first->field.stqe_next) == NULL) \ + (head)->stqh_last = &(head)->stqh_first; \ +} while (/*CONSTCOND*/0) + +#define STAILQ_REMOVE(head, elm, type, field) do { \ + if ((head)->stqh_first == (elm)) { \ + STAILQ_REMOVE_HEAD((head), field); \ + } else { \ + struct type *curelm = (head)->stqh_first; \ + while (curelm->field.stqe_next != (elm)) \ + curelm = curelm->field.stqe_next; \ + if ((curelm->field.stqe_next = \ + curelm->field.stqe_next->field.stqe_next) == NULL) \ + (head)->stqh_last = &(curelm)->field.stqe_next; \ + } \ +} while (/*CONSTCOND*/0) + +#define STAILQ_FOREACH(var, head, field) \ + for ((var) = ((head)->stqh_first); \ + (var); \ + (var) = ((var)->field.stqe_next)) + +#define STAILQ_FOREACH_SAFE(var, head, field, tvar) \ + for ((var) = STAILQ_FIRST((head)); \ + (var) && ((tvar) = STAILQ_NEXT((var), field), 1); \ + (var) = (tvar)) + +#define STAILQ_CONCAT(head1, head2) do { \ + if (!STAILQ_EMPTY((head2))) { \ + *(head1)->stqh_last = (head2)->stqh_first; \ + (head1)->stqh_last = (head2)->stqh_last; \ + STAILQ_INIT((head2)); \ + } \ +} while (/*CONSTCOND*/0) + +#define STAILQ_LAST(head, type, field) \ + (STAILQ_EMPTY((head)) ? \ + NULL : \ + ((struct type *)(void *) \ + ((char *)((head)->stqh_last) - offsetof(struct type, field)))) + +#endif /* !_SYS_QUEUE_H_ */ diff -urN arc-null/Makefile arc/Makefile --- arc-null/Makefile 1970-01-01 00:00:00.000000000 +0000 +++ arc/Makefile 2023-09-23 07:06:54.452622678 +0000 @@ -0,0 +1,92 @@ +# This set of spinroot related files were written by cherry +# in the Gregorian Calendar year AD.2023, in the month +# of February that year. +# +# We have two specification files and a properties file (".inv") +# +# The properties file contains "constraint" sections +# such as ltl or never claims (either or, not both). +# The specification is divided into two files: +# the file with suffix '.drv' is a "driver" which +# instantiates processes that will ultimately "drive" the +# models under test. +# The file with the suffix '.pml' contains the process +# model code, which, is intended to be the formal specification +# for the code we are interested in writing in C. +# +# We process these files in slightly different ways during +# the dev cycle, but broadly speaking, the idea is to create +# a file called 'spinmodel.pml' which contains the final +# model file that is fed to spin. +# +# Note that when we use the model extractor tool "modex" to +# extract the 'specification' from C code written to implement +# the model defined above. We use a 'harness' file (see file with +# suffix '.prx' below. +# +# Once the harness has been run, spinmodel.pml should be +# synthesised and processed as usual. +# +# The broad idea is that software dev starts by writing the spec +# first, validating the model, and then implementing the model in +# C, after which we come back to extract the model from the C file +# and cross check our implementation using spin. +# +# If things go well, the constraints specified in the '.inv' file +# should hold exactly for both the handwritten model, and the +# extracted one. + +spin-gen: arc.pml arc.drv arc.inv + cp arc.pml model #mimic modex + cat arc_queue/arc.pmh model > spinmodel.pml;cat arc.drv >> spinmodel.pml;cat arc.inv >> spinmodel.pml; + spin -am spinmodel.pml + +spin-build: #Could be spin-gen or modex-gen + cc -DVECTORSZ=65536 -o pan pan.c + +all: spin-gen spin-build prog + +# Verification related targets. +spin-run: spin-build + ./pan -a #Generate arc.pml.trail on error + +# You run the trace only if the spin run above failed and created a trail +spin-trace: spinmodel.pml.trail + spin -t spinmodel.pml -p -g -l # -p (statements) -g (globals) -l (locals) -s (send) -r (recv) + ./pan -r spinmodel.pml.trail -g + +# Build the implementation +prog: arc.c arc_queue/arc.h + cc -g -o arc arc_drv.c arc.c + +# Modex Extracts from C code to 'model' - see arc.prx +modex-gen: arc.prx arc.c + modex -v -w arc.prx + cat arc_queue/arc.pmh model > spinmodel.pml;cat arc.drv >> spinmodel.pml;cat arc.inv >> spinmodel.pml; + spin -a spinmodel.pml #Sanity check + +# Housekeeping +modex-gen-clean: + rm -f spinmodel.pml # Our consolidated model file + rm -f _spin_nvr.tmp # Never claim file + rm -f model # modex generated intermediate "model" file + rm -f pan.* # Spin generated source files + rm -f _modex* # modex generated script files + rm -f *.I *.M + +prog-clean: + rm -f arc +spin-run-clean: + rm -f spinmodel.pml.trail + +spin-build-clean: + rm -f pan + +spin-gen-clean: + rm -f spinmodel.pml # Our consolidated model file + rm -f _spin_nvr.tmp # Never claim file + rm -f model # Intermediate "model" file + rm -f pan.* # Spin generated source files + +clean: modex-gen-clean spin-gen-clean spin-build-clean spin-run-clean prog-clean + rm -f *~ From nobody Fri Sep 29 13:21:39 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RxrbW6QYkz4ttrp for ; Fri, 29 Sep 2023 13:21:43 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 4RxrbV4J60z3YVN for ; Fri, 29 Sep 2023 13:21:42 +0000 (UTC) (envelope-from bacon4000@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=HWCONvzM; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::729 as permitted sender) smtp.mailfrom=bacon4000@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-7741109bdeeso904609685a.2 for ; Fri, 29 Sep 2023 06:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695993701; x=1696598501; darn=freebsd.org; h=content-transfer-encoding:content-language:to:subject:from :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=CM578O7BEtjSrYj1twmSV0KsYtvFUnrOhvsOdqbQLvE=; b=HWCONvzMfIuTpacy+FqQHHAZdAma8b0tHDJ+GwFm63BkOSRFTULh/hosXIrSPEAjdu g44SHXRDhYhbPGawgwmMi+Ks4crlMQIhCIKyqp3mgrP2fe/cBiogkQ40FNP0hy+ZVIHl WiSHCilHuKCppltSJIepx0aF9WLXPq/teedo18eFIEi47OxnIFJa76F+DpR7PGhkoUp0 cjoFyHjpflE48mkKUAIdTGbRq3U0QkSixyziq3nhvdh9YGnJCiVKHyZkn1otQSr7M8bL 55sa9M//od3RaatdYg2x+tcHq7f2AgqocYCZatn8wfbM4aOV8PCnMC0beLUAa2QJakBF V4Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695993701; x=1696598501; h=content-transfer-encoding:content-language:to:subject:from :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=CM578O7BEtjSrYj1twmSV0KsYtvFUnrOhvsOdqbQLvE=; b=tMMil2mHUHPnse8eAnv/vEqVfaxUOJQxD2bXb0SFXNHN3qxYVam59Iy1kNWXOIRoAW gJyOZliku/W/JaRqCajrwGU4KOlgAA1+q5qhZ1Bc2NcSphfMEALAvSisHkxpezI/5I8Q D2stlYLr14SFmMPjSr+ntyQ+YqNz3AyhqxLBVqD8OYtIq+dO+wOtFezGa0wQYBHtNfCd ss0PgnCwsJMJhbiqV+7qNvbPoDirnOkw0jLjyDtP+0gMa+BhDUOp4OwHjNbmqgiOHh/c Zw/SW4MM8VTbUG8CphsNz6U8JInmmV9u+Bhej1Umnre5Z/URhy8spMjUqEDx3uCE+M/R 5BWg== X-Gm-Message-State: AOJu0Yzz+iqAjSIkiYzMKxnVHY2Y24lA8aE842egcrPDPxKa6RfguV1p 0AXIphS62efHJe6gljb7Jg2aDTRdQT8= X-Google-Smtp-Source: AGHT+IEL+R7DT+i1HYOWx7Nngvx4qUjcdb3rpuwh6uxLRrETinB7YQhxoJ3o7Ubrpl9J7cdCkbuWZw== X-Received: by 2002:a05:620a:1992:b0:774:124d:6876 with SMTP id bm18-20020a05620a199200b00774124d6876mr4335090qkb.18.1695993701489; Fri, 29 Sep 2023 06:21:41 -0700 (PDT) Received: from [192.168.0.3] (cpe-184-58-230-200.wi.res.rr.com. [184.58.230.200]) by smtp.gmail.com with ESMTPSA id 21-20020a05620a079500b007756736aee0sm2902514qka.115.2023.09.29.06.21.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Sep 2023 06:21:41 -0700 (PDT) Message-ID: Date: Fri, 29 Sep 2023 08:21:39 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 From: Jason Bacon Subject: Single-user actions on reboot To: freebsd-hackers@freebsd.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::729:from]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4RxrbV4J60z3YVN I'm wondering if there's a canonical way to schedule a command to run automatically during the next boot cycle, but before going multiuser. This would be useful, for example, to run certain tunefs commands on /, which can only be done in single-user mode, on remotely managed systems. Running things after going multiuser is easy, of course, but not sufficient for tunefs commands that cannot be performed on a filesystem mounted rw. Thanks... -- Life is a game. Play hard. Play fair. Have fun. From nobody Fri Sep 29 13:49:17 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RxsCn6Tjxz4twbc for ; Fri, 29 Sep 2023 13:49:41 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [IPv6:2a01:4f8:1c1c:11e5::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 4RxsCn2D9Qz3cMl for ; Fri, 29 Sep 2023 13:49:41 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; none Received: from mail (mail [IPv6:fd5c:5351:d272::3]) by mail.madpilot.net (Postfix) with ESMTP id 4RxsCc32DKz6f2G; Fri, 29 Sep 2023 15:49:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1695995364; x= 1697809765; bh=B7Qtw6om+Pod+AmcsRm2aTiYJBoZ5pHW6WJvaEU3/k8=; b=t SpXeAnSZtj57ljPL2OIGA0tjjeSjnUKvLY40c2mFWwjPFv4O6YpfErk+wCXtFrLj 79CyAUcDIerNti6PeWpWn1tfOpu84uO9Cy5SqMsKlSJP/0tq9pk/R8l2TL77nlcq S+ZNtsT1u36BJ77WlZbseEJCd8PrB5oQPrT6HafLiz82zsvBp8ROzfapmkqHyZkc wvEmNxfMnjKjnJcAb6IVsM2rJq8NM6jAVN8uJwkk7d+LimcaWjGpsSWaGhtehhE/ Ake71V4nFLFbgjVGFQrXCee2G4sir0D7GrQmxLqNmCCTu/83TDsJP3lOAqEdGFrI FFT053rojaCvQLJsQ2UCA== Received: from mail.madpilot.net ([IPv6:fd5c:5351:d272::3]) by mail (mail.madpilot.net [IPv6:fd5c:5351:d272::3]) (amavisd-new, port 10026) with ESMTP id UpXy6_Fkl-Oj; Fri, 29 Sep 2023 15:49:24 +0200 (CEST) Message-ID: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> Date: Fri, 29 Sep 2023 15:49:17 +0200 Subject: Re: Single-user actions on reboot To: Jason Bacon , freebsd-hackers@freebsd.org References: Content-Language: en-US From: Guido Falsi Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeAQTAQIAIgUCT4b6XQIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGuaGDlbL0pOWigf/YVTVf3+ZRnzeGP7CjGV1 Wrrxzjc8h8W64NZasV0XLHGFjl5MYwtm9jJ9gbL8Ubtqstey7lYpjOk2fG6YDhY5eptWCpR6 1QqYrioukhCfKbodSk6PnIZcx719nJVK2P7ihdFEN78TavpBwqIf9hGEcKkMpbRFQv1mYvXD hKVwQGY+8bkH/a/pAWmIyD4qMfKCMurH5DexxEt5SYWu5BB5hd/DWyZ0wuZ+F79KMPzLBPJW 5cpdLNbrvenSqFZGJEGhtTp7GFJJr6lTy8VLBArxmFHiY5jGyR45eZEGDcz86FfGgvPnnpi7 aNCc/ROdF7fnZYPh8uZGGjQbd4EYK4xMzc7BTQRTEHtBARAAoWGsNx6g90r8gcNKaiPpJBiK y8ztV2FyV5LsT0OgQBW3vIxt/odtsxVNNjpyS/BNZCyzLAsFc1WrGBzhYsmPN9SGB5/5YTvk zf5YViU5VAsZlj/MRWCZrWtpic4c0A7N4csOYReNtk/q8YB4PIFsZ9A+kTuoZhnu5t5PdfBA 74+SVwKu84+PZk9wDEY1LbFVT8vM42oKsmoswlIhwJ2xuJI/gbk+cMUe0yiRpNjo4Svw4RB8 4B6uFwdRr/PtS7xi2Zqoof5AaQT9YSBpGpKJOe/Qk5MP4PF6Fqq+go89n77Y2kJkwcHaLoD/ GJ+ZDASIiMRe1y54FHOQ1RCTGGpnJLXdKuGhwv3J21pU8HNlq0ASNQMMQmYAwtUWzjmp/KEy I1qkcmjafcxb8TmiaoK8SQN1Zf96fc/sIrZN6Z5oOCEyyCQ0prH/PTA2jlRkKQ487PTGk2JS KU5VuS57Nlk2DrnvjWp57aV9eFAhpnrrJPuGmFz83/Pc8gC0t7N7i7VVHYRcC5naxYB2UoI1 OUkyxpT/HvQFXXVZ3/KmdXMzrx191AggCPWIwUAP+VcaURSYpeDk6/ZVAOVOe1ChqcJisCD7 wK20/OOvJ2AtkWreGu1CZ9zSx7nK/VYdLr34GxQ4bT1G+9rBQNnFSNbX2TJ431Mdo1GCjDeR K4CtSnrNKYkAEQEAAcLAXwQYAQgACQUCUxB7QQIbDAAKCRAa5oYOVsvSkw3nCADhsKRf+rAR ULTpOh5HoLam62ZJZAyCkNqqu/rke5uj5AaaDY/h7BNhBDiDqhhZLTeofGpVVaErPsWN+tX5 0fypsIt9KAhy90GFrtrIZlWuyK4wsoZvDfp9yaRk+lIM58dw/Rcfxn670JaPTFSRPECVn/uL qBhJSkbYlY212YT9fxVUTJe6wIvDLQrQEjrQD/h1FMhfcLhAqsndltRd6DPvTKeMd/6VAxn0 hkoBKhEy5LkWjM9CHppu+bBkQ91/kj2uJQSXO8euonwHHS3c+6N2i2H7I0emcHGu07wuRB2t Dnw/RLBxohffdPZT2kbxuG7lhVHzwVDw5DRwSw8GkOdy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Queue-Id: 4RxsCn2D9Qz3cMl List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 29/09/23 15:21, Jason Bacon wrote: > > I'm wondering if there's a canonical way to schedule a command to run > automatically during the next boot cycle, but before going multiuser. > > This would be useful, for example, to run certain tunefs commands on /, > which can only be done in single-user mode, on remotely managed systems. > > Running things after going multiuser is easy, of course, but not > sufficient for tunefs commands that cannot be performed on a filesystem > mounted rw. > > Thanks... > AFAIK there is no ready made tool in base (or ports) for that. But ezjail uses this trick with rc scripts (removing itself): https://erdgeist.org/gitweb/ezjail/tree/examples/example/etc/rc.d/ezjail.flavour.example This is effective but requires the disk mounted r/w which maybe is not enough for you. Problem is, without any writable media mounted, how can any script register it has already ran? One idea that comes to mind is adding some hook to the main rc script, before mounting disk r/w, and a second script that removes existing hooks once disks are r/w. -- Guido Falsi From nobody Fri Sep 29 14:34:10 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RxtCG45YZz4v0WW for ; Fri, 29 Sep 2023 14:34:18 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4RxtCG1PZkz4CYr for ; Fri, 29 Sep 2023 14:34:17 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-hackers@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 38TEYAUe088286; Fri, 29 Sep 2023 15:34:10 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 38TEYARc088285; Fri, 29 Sep 2023 15:34:10 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202309291434.38TEYARc088285@donotpassgo.dyslexicfish.net> Date: Fri, 29 Sep 2023 15:34:10 +0100 Organization: Dyslexic Fish To: mad@madpilot.net, freebsd-hackers@FreeBSD.org, bacon4000@gmail.com Subject: Re: Single-user actions on reboot References: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> In-Reply-To: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Fri, 29 Sep 2023 15:34:10 +0100 (BST) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US] X-Rspamd-Queue-Id: 4RxtCG1PZkz4CYr Guido Falsi wrote: > This is effective but requires the disk mounted r/w which maybe is not > enough for you. > > Problem is, without any writable media mounted, how can any script > register it has already ran? To get around that (and I know it's not the same thing, but it does the job for me), I have a script that checks for a marker file in /etc and if it exists, only runs if the file timestamp is newer than the current time. I then have various helper scripts to set the date on that file to (e.g.) 15 minutes in the future. This shuld really be made more generic (having the commands to be run within the so called flag file), but as it stands, I just use this as an added file to /etc/rc.d/ This particular example is based on /etc/rc.d/fsck but is added (don't replace it!), and just forces a full fsck on all filesystems on boot. It's not clean, and really should be merged into /etc/rc.d/fsck , to avoid the double-fsck for one thing, but it was a quick and dirty hack that does the job. I have a script "force-fsck" that simply does this: #!/bin/sh /usr/bin/touch -t "$(/bin/date -v +15M '+%Y%m%d%H%M.%S')" /etc/.force-fsck-expire which i run prior to doing the reboot. The drop-in script, /etc/rc.d/fsck_force_full is here if anyone is interested: https://www.dyslexicfish.com/jamie/freebsd/etc_rc.d_fsck__force__full Though the meat of it is this: | flagfile="/etc/.force-fsck-expire" | | # We have to make sure we only use commands here that exist on the root partition, | # as "/usr" and other partitions won't be mounted at this point. Also, we can't use | # a marker file that gets removed as the mount at this stage is read-only! | | if [ -f "$flagfile" ] && # If the flagfile exists, | expire_time_1="$(/bin/ls -lD '%s' "$flagfile")" && # read it's "mtime", in seconds since epoch | [ "$expire_time_1" ] && # If we get a result, | expire_time_2="${expire_time_1% $flagfile}" && # strip the filename off the end of the string. | [ "x$expire_time_2" != "x$expire_time_1" ] && # If this operation is successful, | expire_time_1="${expire_time_2##* }" && # strip the rest of the cruft from beginning of the string. | [ "x$expire_time_2" != "x$expire_time_1" ] && # If this operation is successful, | [ "${expire_time_1%%*[!0-9]*}" ] && # and if the result is a valid integer, | [ "$expire_time_1" -gt "$(/bin/date +%s)" ] # and if the result is older than the current date, then..... | then | ........ | fi Jason, the script could easily be modified by replacing the fsck command with whatever you want to run.. Cheers, Jamie From nobody Fri Sep 29 16:12:00 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RxwNH0FGzz4v6BD for ; Fri, 29 Sep 2023 16:12:15 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RxwNG44P6z4Nmr for ; Fri, 29 Sep 2023 16:12:14 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 38TGC1NN074025; Fri, 29 Sep 2023 09:12:07 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Fri, 29 Sep 2023 09:12:00 -0700 From: Chris To: Guido Falsi Cc: Jason Bacon , freebsd-hackers@freebsd.org Subject: Re: Single-user actions on reboot In-Reply-To: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> References: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4RxwNG44P6z4Nmr On 2023-09-29 06:49, Guido Falsi wrote: > On 29/09/23 15:21, Jason Bacon wrote: >> >> I'm wondering if there's a canonical way to schedule a command to run >> automatically during the next boot cycle, but before going multiuser. >> >> This would be useful, for example, to run certain tunefs commands on /, >> which can only be done in single-user mode, on remotely managed systems. >> >> Running things after going multiuser is easy, of course, but not sufficient >> for tunefs commands that cannot be performed on a filesystem mounted rw. >> >> Thanks... >> > > AFAIK there is no ready made tool in base (or ports) for that. > > But ezjail uses this trick with rc scripts (removing itself): > > https://erdgeist.org/gitweb/ezjail/tree/examples/example/etc/rc.d/ezjail.flavour.example > > This is effective but requires the disk mounted r/w which maybe is not > enough for you. > > Problem is, without any writable media mounted, how can any script register > it has > already ran? > > One idea that comes to mind is adding some hook to the main rc script, > before > mounting disk r/w, and a second script that removes existing hooks once > disks are > r/w. Indeed. Maybe at the same point the system tastes the disk(s) to see if they've been dismounted properly and then running fsck(8) if not. Using the same method to perform your task(s)? --Chris From nobody Fri Sep 29 16:56:53 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RxxN36Mlkz4v8mQ for ; Fri, 29 Sep 2023 16:57:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 4RxxN33wmcz4YRH for ; Fri, 29 Sep 2023 16:57:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-9b1ebc80d0aso1616485266b.0 for ; Fri, 29 Sep 2023 09:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1696006625; x=1696611425; 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=hC3GDWerFUjciRrEfdX170r37i2w4zEUdUxtbnHfSXc=; b=v/VgSZRHJs64V4RRLH3Av0sF0HwGLiY7tfIWcG6HSSRhgG3OmCOAOQf0ZsOJhBAN9F +H5pg0ImDl55bkST04Lf8DFZIYgBC+7FXOYB84vPBIu22tkZh2+O/YD2+aHDhTjWfIsG tVLztfeAHxIXlRsvmA+0eY78VQJ4Hu35smX0cJAatYGKG2HPrCsxA7zuR0BZahT1+jKq LgHqxOOGoLrzl7P5Fd1tI27yRwxo9rC3Iqv3wQzKP9G/KcDw8X7HXKl5+grQSJUZCL4j QnytQ/oXc+mr9COenwBmSeuxoqGgkkl1nlQXuWmVyZbEwazB7Xzl6TVTbunm+QTjpf04 fGdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696006625; x=1696611425; 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=hC3GDWerFUjciRrEfdX170r37i2w4zEUdUxtbnHfSXc=; b=lpMfKz8lhMNlQUOxwh7te2ScwPBrIUiMf39NX1BR0wW4gaImKLhNX1Zot1Wtms/lT6 1zDa7HDB+RS8ge5GohWHQWurow2jesuzXljyqptmSgfGQEQH/dra8SfOkG+h7XDw25BN ne/whaRFURta4RXPbzoqrrzHYr3b8V/poJ91XfCPUxmIcHP+IGNauUhaCwksYBJulMWc 4WWFcPTShE8HeDZilnlX6Sg04w5dOYIu4PcDCIXZ8T8hvd1WYF/Uoh/TFE+SFzpFdTOw ebaq9lLE8+0O1ZZ64V2WBm2z+5Vqsnb1Og8zzT1i+jvswBxZRSHMCKwg3kAUGLW3o0vf xIUg== X-Gm-Message-State: AOJu0Yw597n3tRKiiijCW3k4yIDlK5a5KL1yJMr0Ki7z27TO5PT2kWid ViRzw/9BOpZRDzF/FuGmNV79f9C+bTkRJ8if2I/Img== X-Google-Smtp-Source: AGHT+IFQNFfUrhflO2/5gyjdox8b5Sr9sI4tdU6mYG3GWg8PzHxNtpW/KyEFq5dv+NER1rwvHVhn7QbJTrV7O+nawuM= X-Received: by 2002:a17:907:7859:b0:9ad:78b7:29ea with SMTP id lb25-20020a170907785900b009ad78b729eamr4302846ejc.44.1696006625037; Fri, 29 Sep 2023 09:57:05 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> In-Reply-To: From: Warner Losh Date: Fri, 29 Sep 2023 10:56:53 -0600 Message-ID: Subject: Re: Single-user actions on reboot To: Chris Cc: Guido Falsi , Jason Bacon , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000006c24970606825050" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4RxxN33wmcz4YRH --0000000000006c24970606825050 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 29, 2023, 10:12 AM Chris wrote: > On 2023-09-29 06:49, Guido Falsi wrote: > > On 29/09/23 15:21, Jason Bacon wrote: > >> > >> I'm wondering if there's a canonical way to schedule a command to run > >> automatically during the next boot cycle, but before going multiuser. > >> > >> This would be useful, for example, to run certain tunefs commands on /, > >> which can only be done in single-user mode, on remotely managed systems. > >> > >> Running things after going multiuser is easy, of course, but not > sufficient > >> for tunefs commands that cannot be performed on a filesystem mounted rw. > >> > >> Thanks... > >> > > > > AFAIK there is no ready made tool in base (or ports) for that. > > > > But ezjail uses this trick with rc scripts (removing itself): > > > > > https://erdgeist.org/gitweb/ezjail/tree/examples/example/etc/rc.d/ezjail.flavour.example > > > > This is effective but requires the disk mounted r/w which maybe is not > > enough for you. > > > > Problem is, without any writable media mounted, how can any script > register > > it has > > already ran? > > > > One idea that comes to mind is adding some hook to the main rc script, > > before > > mounting disk r/w, and a second script that removes existing hooks once > > disks are > > r/w. > Indeed. Maybe at the same point the system tastes the disk(s) to see if > they've been dismounted > properly and then running fsck(8) if not. Using the same method to perform > your task(s)? > At work we just have a custom rc script to do that for all our content disks (only os disks are in fstab). As for writable media... you could set a uefi variable... or create a small MD partition (call it /once) that an rc script in a later phase could use to mop up and then free. The latter is easier, but in many environments the former is more durable and reliable if there's an early crash that happens before mopup and you can really only run something once... Warner > --0000000000006c24970606825050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 29, 2023, 10:12 AM Chris <bsd-lists@bsdforge.com> wrote:
On 2023-09-29 06:49, Guido Falsi wrote:
> On 29/09/23 15:21, Jason Bacon wrote:
>>
>> I'm wondering if there's a canonical way to schedule a com= mand to run
>> automatically during the next boot cycle, but before going multius= er.
>>
>> This would be useful, for example, to run certain tunefs commands = on /,
>> which can only be done in single-user mode, on remotely managed sy= stems.
>>
>> Running things after going multiuser is easy, of course, but not s= ufficient
>> for tunefs commands that cannot be performed on a filesystem mount= ed rw.
>>
>> Thanks...
>>
>
> AFAIK there is no ready made tool in base (or ports) for that.
>
> But ezjail uses this trick with rc scripts (removing itself):
>
> https://erdgeist.org/gitweb/ezjail/tree/examples/example/etc/rc.d/ezjai= l.flavour.example
>
> This is effective but requires the disk mounted r/w which maybe is not=
> enough for you.
>
> Problem is, without any writable media mounted, how can any script reg= ister
> it has
> already ran?
>
> One idea that comes to mind is adding some hook to the main rc script,=
> before
> mounting disk r/w, and a second script that removes existing hooks onc= e
> disks are
> r/w.
Indeed. Maybe at the same point the system tastes the disk(s) to see if they've been dismounted
properly and then running fsck(8) if not. Using the same method to perform =
your task(s)?

At work we just have a custom rc script to do that for all our= content disks (only os disks are in fstab).

As for writable media... you could set a uefi variable= ... or create a small MD partition (call it /once) that an rc script in a l= ater phase could use to mop up and then free. The latter is easier, but in = many environments the former is more durable and reliable if there's an= early crash that happens before mopup and you can really only run somethin= g once...

Warner
<= /blockquote>
--0000000000006c24970606825050-- From nobody Fri Sep 29 21:32:46 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ry3VG4GZyz4vgt1 for ; Fri, 29 Sep 2023 21:32:54 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 4Ry3VG2dgBz3V95 for ; Fri, 29 Sep 2023 21:32:54 +0000 (UTC) (envelope-from bacon4000@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-41811e7ac3dso60635611cf.2 for ; Fri, 29 Sep 2023 14:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696023168; x=1696627968; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Re76ZhQIaiotSDqbNwQSq71ctD3Oe3JjJcoXqInn3C4=; b=ZSi0aBJEW7rOlSoP5spFxx5sGfUSkcfVZHJFaCCd7EVqYXFh0EoWleVQ+jfbaFujc6 jX0Dckok1FMdQlR/uhJTx3cJq0kcq79ASqT1CUBxBOZtHMVQwd/Uv2iYIQT4EE2MOGrA gjHfoeRhEgTgaGG8f8BbNEm25rLkTjENiaQOBp5BRtJA4RaI+R7q6lMLs/HOy2QaoQcA +CM6lSiIeB3R4dNB5qXmA7tp7AqtOuXWet7gYZLYN8kqN2NUm+n5p2Tga3ffb/E+p+qz 2CkvwpqFRdHKZTz9Ruoczd+pxIndhqOBufBn1LckZedX66A2PplYPHJceE2GgYFc3SNh iFSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696023168; x=1696627968; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Re76ZhQIaiotSDqbNwQSq71ctD3Oe3JjJcoXqInn3C4=; b=tqAVbIZDvlWH0N7Nrx+AhhJLYPoXABU3wNaeaN5lGsVqVRIQ1pWyt5J6gudqNTebCB QCoA2LKDQReo/45n0iZY093+Jr41GBu2YJueJHoPrBSVdyfnnkZQUrhYXnbHOwvY0aFV utaHYppWLUr4lmGtaQOe68IF2elMJ36wgAKO+leW9BbsRfNO2kAlOkMOgTpbasrnRY8v sBgFDZiXaZ/Lc8788lR0sYuS61fZ07Vrk18OCH2JjTwyL/HCuka2vPQtTyBE8Gok8W2e foXaRhA2DWlqi40Za30OQkZUW1d0ai0X06dd4mwd7qVIwDWSajOA0fvXVo1NzQxS9zJY jxmw== X-Gm-Message-State: AOJu0YwCsr62Ih9tZS9Tz3T85lXWHX9djwamGw7SNf2ah/KGOpfAZt9s 6HLxMLQpYYt+3/c1NUUe4BH+nwXx7vY= X-Google-Smtp-Source: AGHT+IHJyGB20mjGBQnrIPK6l/R+Tbp9RuC14T34exyMEt2A/wFZnx6WvOK4o7kaXOfP6T9ve3mNCQ== X-Received: by 2002:a05:622a:40a:b0:40f:1c71:d4f7 with SMTP id n10-20020a05622a040a00b0040f1c71d4f7mr5548522qtx.40.1696023168369; Fri, 29 Sep 2023 14:32:48 -0700 (PDT) Received: from ?IPV6:2603:6000:a401:3a00:6e88:14ff:fea7:590c? (2603-6000-a401-3a00-6e88-14ff-fea7-590c.res6.spectrum.com. [2603:6000:a401:3a00:6e88:14ff:fea7:590c]) by smtp.gmail.com with ESMTPSA id iv2-20020a05622a6f0200b004109086e54bsm4763360qtb.38.2023.09.29.14.32.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Sep 2023 14:32:48 -0700 (PDT) Message-ID: <22a305ca-bd0a-af58-31d1-31875ed28629@gmail.com> Date: Fri, 29 Sep 2023 16:32:46 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Single-user actions on reboot To: Warner Losh , Chris Cc: Guido Falsi , FreeBSD Hackers References: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> Content-Language: en-US From: Jason Bacon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Ry3VG2dgBz3V95 On 9/29/23 11:56, Warner Losh wrote: > > > On Fri, Sep 29, 2023, 10:12 AM Chris > wrote: > > On 2023-09-29 06:49, Guido Falsi wrote: > > On 29/09/23 15:21, Jason Bacon wrote: > >> > >> I'm wondering if there's a canonical way to schedule a command > to run > >> automatically during the next boot cycle, but before going > multiuser. > >> > >> This would be useful, for example, to run certain tunefs > commands on /, > >> which can only be done in single-user mode, on remotely managed > systems. > >> > >> Running things after going multiuser is easy, of course, but not > sufficient > >> for tunefs commands that cannot be performed on a filesystem > mounted rw. > >> > >> Thanks... > >> > > > > AFAIK there is no ready made tool in base (or ports) for that. > > > > But ezjail uses this trick with rc scripts (removing itself): > > > > > https://erdgeist.org/gitweb/ezjail/tree/examples/example/etc/rc.d/ezjail.flavour.example > > > > This is effective but requires the disk mounted r/w which maybe > is not > > enough for you. > > > > Problem is, without any writable media mounted, how can any > script register > > it has > > already ran? > > > > One idea that comes to mind is adding some hook to the main rc > script, > > before > > mounting disk r/w, and a second script that removes existing > hooks once > > disks are > > r/w. > Indeed. Maybe at the same point the system tastes the disk(s) to see if > they've been dismounted > properly and then running fsck(8) if not. Using the same method to > perform > your task(s)? > > > At work we just have a custom rc script to do that for all our content > disks (only os disks are in fstab). > > As for writable media... you could set a uefi variable... or create a > small MD partition (call it /once) that an rc script in a later phase > could use to mop up and then free. The latter is easier, but in many > environments the former is more durable and reliable if there's an early > crash that happens before mopup and you can really only run something > once... > > Warner > Thanks for the brainstorming, guys. This is about what I expected to hear. What I had done to automate completion of base upgrades after the required reboot is add the following to /etc/rc.local: # Would be nice if this were added to the default rc.local rc_dir=/etc/rc.local.d for script in $rc_dir/*; do /bin/sh $script done Then drop a very simple self-removing script into /etc/rc.local.d/freebsd-update-install.sh: #!/bin/sh -e /usr/sbin/freebsd-update install /usr/sbin/pkg upgrade -y rm -f $rc_dir/freebsd-update-install.sh I just realized I could do the same thing by creating a new rc script such as /etc/rc.d/local.single, modeled on /etc/rc.d/local, but running earlier and using a different script and directory, e.g. /etc/rc.local.single and /etc/rc.local.single.d/. Cheers, J -- Life is a game. Play hard. Play fair. Have fun. From nobody Sat Sep 30 14:48:51 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RyVTf2ZF7z4w9bd for ; Sat, 30 Sep 2023 14:48:54 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 4RyVTd3Pscz4KjX for ; Sat, 30 Sep 2023 14:48:53 +0000 (UTC) (envelope-from bacon4000@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="b/efl3xk"; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::72b as permitted sender) smtp.mailfrom=bacon4000@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-x72b.google.com with SMTP id af79cd13be357-77574c5979fso351533985a.3 for ; Sat, 30 Sep 2023 07:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696085332; x=1696690132; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=2d7V9hsmKBxVpgUPUI0GiSDtfDGkeGqb0zpAVX/Ppfw=; b=b/efl3xkwCTSU1veLcuNEDBcOWaoG5STEkw1DiBXPWtNo42QnVO2TT8x7fiFMBtG2P rS4b8f+HltxoCh7RYiXlR8zfUx490bd9CsxOD4quUN47gnpwvi7koWdzAIhNtZ3g4+L1 G8JvRB4qncEKvKisPEkMwEPeRqjKFmXTrUzGDkpKkOJSizmfF6GhNVH7NsNdWBfZJ1jW u9N1HxNFVtDMB6GYqe+dBGorTMyDApuw6qdmzajCeAk0ckMxrRCuLb+Vqmlhmd7uhmM8 +4iBGWtI3ozI1tG3p0jOZ/1n4lLK1kcLRte0pZE8lE1BHhffupr+Jyf9fxp+ANJgLOG1 Mrhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696085332; x=1696690132; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2d7V9hsmKBxVpgUPUI0GiSDtfDGkeGqb0zpAVX/Ppfw=; b=YWOsi7OwxISTS/sT3+9MijdDdDgP0vqa/oOLkYclKC8a0j3tJrsgKaa1HEApqi0ygH PM796Vcqqut63gAU4yd0fZqn6UVYyQlDul//4NA9VYkClCrBORPmvXykFiI9rTWygrgS C91HiGHSeSzJm5TZ+Ks7ugRrYXBndo4+UyWxtjx8LtUisDfqSFM5paTGcNwGtb4QAkgm NkYr6MuOZgrFHBzqBOiClyBOrEmVYgrW3te1JMeeL/2VqsC/k6JW3I8LNZ1m/L3aurRa luyrB4fmj3zoLho1R+KW0ufVDrKjxhF2z5VEo1Sy+XAHsK2hG3wa0p3srsX9pKMB2qPF ULdQ== X-Gm-Message-State: AOJu0YxuMeFD1M3QHKFBJ4y5XJ035ZbAufQibqLwDFYNm3gSnfshnB3J tUbE3t2wV6EoDt8XLTb2wQHdM5bx+qw= X-Google-Smtp-Source: AGHT+IGuJXn++Fkswl5YWdkt395+tnYhj5bYAf192eGzcNipoczo4fKDDIU4IJXDGcAmn9iMIrCzTA== X-Received: by 2002:a05:620a:290a:b0:774:3147:4274 with SMTP id m10-20020a05620a290a00b0077431474274mr9512839qkp.14.1696085332343; Sat, 30 Sep 2023 07:48:52 -0700 (PDT) Received: from [192.168.0.3] (cpe-184-58-230-200.wi.res.rr.com. [184.58.230.200]) by smtp.gmail.com with ESMTPSA id v15-20020ae9e30f000000b0077263636a95sm3125810qkf.93.2023.09.30.07.48.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Sep 2023 07:48:51 -0700 (PDT) Message-ID: <5b57713d-59d5-4fb6-3cbe-a714386f7309@gmail.com> Date: Sat, 30 Sep 2023 09:48:51 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Single-user actions on reboot To: Guido Falsi , freebsd-hackers@freebsd.org References: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> Content-Language: en-US From: Jason Bacon In-Reply-To: <67d9160e-c1fc-4e60-93fb-8c18afc2ac41@madpilot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.52 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_SHORT(0.48)[0.478]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72b:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4RyVTd3Pscz4KjX On 9/29/23 08:49, Guido Falsi wrote: > On 29/09/23 15:21, Jason Bacon wrote: >> >> I'm wondering if there's a canonical way to schedule a command to run >> automatically during the next boot cycle, but before going multiuser. >> >> This would be useful, for example, to run certain tunefs commands on >> /, which can only be done in single-user mode, on remotely managed >> systems. >> >> Running things after going multiuser is easy, of course, but not >> sufficient for tunefs commands that cannot be performed on a >> filesystem mounted rw. >> >> Thanks... >> > > AFAIK there is no ready made tool in base (or ports) for that. > > But ezjail uses this trick with rc scripts (removing itself): > > https://erdgeist.org/gitweb/ezjail/tree/examples/example/etc/rc.d/ezjail.flavour.example > > This is effective but requires the disk mounted r/w which maybe is not > enough for you. > > Problem is, without any writable media mounted, how can any script > register it has already ran? > > One idea that comes to mind is adding some hook to the main rc script, > before mounting disk r/w, and a second script that removes existing > hooks once disks are r/w. > Thanks for the brainstorming, gents. This helped narrow my direction, and I implemented what I need by creating a /etc/rc.d/local_early based on the standard /etc/rc.d/local: https://github.com/outpaddling/auto-admin/blob/master/Data/local_early https://github.com/outpaddling/auto-admin/blob/master/Data/rc.local_early The only real difference is when it runs. As an example of how to use it, to toggle the soft-updates journal using tunefs, I generate a script like the following and drop it in /etc/rc.local_early.d. It runs on the next reboot and removes itself. for fs in /dev/ada0s1a /dev/da0p1; do tunefs -j disable $fs mount -u -o rw / rm -f /etc/rc.local_early.d/auto-su+j-toggle.sh done reboot This is now integrated into auto-su+j-toggle (WIP version), part of sysutils/auto-admin. -- Life is a game. Play hard. Play fair. Have fun.