From nobody Wed Nov 6 12:40:05 2024 X-Original-To: freebsd-testing@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 4Xk4YJ2TCmz5cXP2; Wed, 06 Nov 2024 12:40:20 +0000 (UTC) (envelope-from igoro@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xk4YJ1zWtz3yBc; Wed, 6 Nov 2024 12:40:20 +0000 (UTC) (envelope-from igoro@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730896820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=JVgpunnUAFOhR3L5crOtX9YiHjFlZBdEoXrUaAffN2A=; b=ryuLvecjSIrahogBKrOWn8NKb9Y8AURMotpgKgvmPl1ALvVu3zuqba8CsMW7hEVDD+x6Sb HQRIigig9vJ+OKqGR7KEMQFfG13YEN7hKA1k1A0Purdo6gCiVPAMZxyv2etzXk8KxaJFiT GjtNC4vZqUNI8jA4L5TJWBY3K1t07mclJHUN6jJrbfcv5QnBftWhLOTajldBs4GYfybXb7 YNL5oeI6M1TAYNdv6adTHsrDy9fNVoPo3aHaL7k270LvXtqf3SvhbgZRowkDTuYVNfwRhL ZqC0Zj0914yZJFvyDmatr4seUQVp89MJjARqOIs1GaSxGxaij3W5BGONWe/Kvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730896820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=JVgpunnUAFOhR3L5crOtX9YiHjFlZBdEoXrUaAffN2A=; b=D/KMW18HbkRV9BMLgqB9uk6BlnoDsmCR0aoxNDJJadR19BZ+pKMtU5e0wUCFHCB5E8qsaP obYaaKIBVveLknqlSNN7B+Tm5KbPGa3MJ+Ghucbq2FL/PJSs0vKbVaBO02Up/tBtyKK5L8 QG49D093RgTEV7kwz9dfZeONYKBO2fDvW0LgX+0ldTfFQyUK0QPh0LkItWsgsRxhRggtbC /bcaKfQGdtDhqhV/pvGfsSgPed3DJ9QbXLTAZBRRfm4p8L1DycpekEsL/28dNTJkGKOFZc 53z7TAT2haefx1I6wRNZo7wC6oCb84bJxLmVEsiJKM2RoiQbrzWhWDqpgmT2Bg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730896820; a=rsa-sha256; cv=none; b=rN3Rjxm8LaWnmFaevTT510Jr7IbbNLwFp1RbUVmpW2K53a5fdmpt0OHz01NpFDuwGyxbfy zNsZ0qacBRtDJenGjzk3UwjZ0OZd7HOcqoDU8d7T1fmr3AYLPdPAmbfRISe6dw+YumHcPS 0hU1zICIFyFLrF1M+mNkOALw5aJMlPDI5lKA+9PotZ2YuhZsDuJKptMi0SH0PJzLBfIP7C UkUb/OFnLKc0dvykAQuq5D3oGJ3g1tw1/PieCJIUSnLUE/Or79+sVCV0moE+OVX/d987DO 9VLdfpdbRnSj0gyqh/NAsP+iknMi7ndWWDy5aT99qy0QZDuu3UZaIMjvpD8ZSg== Received: from [192.168.0.8] (unknown [78.83.216.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: igoro/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Xk4YH4vqtzcLH; Wed, 6 Nov 2024 12:40:19 +0000 (UTC) (envelope-from igoro@FreeBSD.org) Message-ID: <9e175f3c-4be0-437d-abf6-7f9d820154e7@FreeBSD.org> Date: Wed, 6 Nov 2024 14:40:05 +0200 List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Igor Ostapenko Subject: Heads-up: Removal of devel/kyua port To: freebsd-testing@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Kyua has been part of base since 13.0, today it means all supported versions. The tests in /usr/tests usually have parity with Kyua in base, i.e. even if we consider older unsupported systems then new features from the latest port offer limited benefits. Anyway, these cases are not supported. So, in order to avoid double work and user confusion, the devel/kyua port is being considered for removal. The motivation of this notification is to collect comments and suggestions in case if the removal is not a good idea for some reasons. Best regards, igoro From nobody Wed Nov 6 13:01:06 2024 X-Original-To: freebsd-testing@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 4Xk51X6bmBz5cYmB; Wed, 06 Nov 2024 13:01:20 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xk51X5hQxz42yy; Wed, 6 Nov 2024 13:01:20 +0000 (UTC) (envelope-from bofh@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730898080; 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=/CryTdzZZkq6zYFA3PUsgX+SYWqhu049h7vBRK79aek=; b=mRT4zlJhcW6Ai3bzv5krUkE3FH7JbYRZgkNyvg9ySINz8dLpa0+eFDibdpIBbzoO9BX5JU s9L9gNRD3hDN22KBLhkJLwhz9wOzDIQbwqeSBgZ1ftz/DEA82sPLoEowIvi5D8FFrD4C7t dwtG+ZT/P35CWZ5Z+XTIl8j2X+U1JaYes7yCA9m40eksrrEOsdASUHQZe3/yn/9R+ji5IE Jy9NxRoQdqueQ09VGahYB05O6Fuma8vfZjxwHokifW6cxAnfvSW3eMHxOUnjIHsroQ6E/U lzVaLf5ST0P7n2eDmzEc+R+ax3Nm2ejv5Q0J4S2iPHZIBqO0cbuxtUdy5yUUqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730898080; 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=/CryTdzZZkq6zYFA3PUsgX+SYWqhu049h7vBRK79aek=; b=gGP7e6nzx5lOk5Hja6ZRSY+t0bQffMlppyuWy0AvJnnUh6WI8KS91Q42OYSGWLUMCaNKFv 8Dp3LGqO67yWZMIes2SrXBwa99ARe8BcYn0WDpM5JpHjYg4vbn1cAxwffySBWUKkijuRcw 8QRgmIrz/omqQiEqCPq01WJmWIPaxCzIURgNB2DBMwOGo7AQ0U6SylN65yhylj0rjtsmEg OVRswhjIZmzam4KW58wDD+X9sl3mdKpNEiOm3JMfoaQYEo7hwZmbKTS9LhQTsKq7jea9+4 8h1l2ElGDGjhfNe6an0BV/Ldw8hcSpVP9b6CiIHnbzf52YLeLwZm95UeRyGfeA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730898080; a=rsa-sha256; cv=none; b=es35pVtre1WL43wBmG2f09hrcJC075wHVfll8kaEE8HXQUtuw+QheGGWYBcujFLXp/RluG zcpRcN7tX2ngKj7OO72bQo4ijoS4rbJRUGfWWrOLXq/7pagyw42bp5V+hQzBbBkQmlfCmV 2ae7ZagbBCOmSpzafzYzP8Vi2/JpeTM3eQwPyC8s7IMfp2LrcmuL3xefWVuBuA2IH9N28D tq/GKmrQiSKYz9fUAAt+SR5e4dADZnFTvM3HI++2xe9B7ID+kXLicGnN6vzkhFYUm2moD5 wziu1eaebIsxjz/sAC8SsKLYK2cNa5diDn8kVlndLChjtkkIfmR+DGXg8sAufw== Received: from mx.bofh.network (mx.bofh.network [5.9.249.227]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bofh/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Xk51X1G04zcVF; Wed, 6 Nov 2024 13:01:20 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtpclient.apple ( [217.117.226.147]) by mx.bofh.network (OpenSMTPD) with ESMTPSA id fdde1e67 (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO); Wed, 6 Nov 2024 13:01:17 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_E3693147-A099-4B22-9A5C-195CF8066CC2"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\)) Subject: Re: Heads-up: Removal of devel/kyua port From: Moin Rahman In-Reply-To: <9e175f3c-4be0-437d-abf6-7f9d820154e7@FreeBSD.org> Date: Wed, 6 Nov 2024 14:01:06 +0100 Cc: freebsd-testing@freebsd.org, freebsd-hackers , freebsd-ports@freebsd.org Message-Id: References: <9e175f3c-4be0-437d-abf6-7f9d820154e7@FreeBSD.org> To: Igor Ostapenko X-Mailer: Apple Mail (2.3731.700.6.1.9) --Apple-Mail=_E3693147-A099-4B22-9A5C-195CF8066CC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 6, 2024, at 13:40, Igor Ostapenko wrote: >=20 > Hi, >=20 > Kyua has been part of base since 13.0, today it means all supported = versions. >=20 > The tests in /usr/tests usually have parity with Kyua in base, i.e. = even if we consider older unsupported systems then new features from the = latest port offer limited benefits. Anyway, these cases are not = supported. >=20 > So, in order to avoid double work and user confusion, the devel/kyua = port is being considered for removal. >=20 > The motivation of this notification is to collect comments and = suggestions in case if the removal is not a good idea for some reasons. >=20 >=20 > Best regards, > igoro >=20 Hi, I am not exactly sure if the one in 13/stable is the updated one as I merged the latest code into the head and 14/stable. That's why I planned to kill it sometimes during the EOL of 13. But correct me if I am wrong. Kind regards, Moin --Apple-Mail=_E3693147-A099-4B22-9A5C-195CF8066CC2 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----- iQKTBAEBCgB9FiEETfdREoUGjQZKBS+fvbm1phfAvJEFAmcraJJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRE Rjc1MTEyODUwNjhEMDY0QTA1MkY5RkJEQjlCNUE2MTdDMEJDOTEACgkQvbm1phfA vJF/8A//RngBec+VxYj1FNRVL/ktXVE3nukpujD6n+irTkl2diOSyoOZHsy8+8if raRiQLYYsGRfmnbuOdPRATJZNBDe7y0Q7Lizohu3dPrwgRPBm40cPck/wArHFtQy 08cORpAY+VcT1nuzjHAokiwTG3bHh5uy6ISH9pN8u/hHGUyR68adM9Yp5A9ZRLES lq/Bgs+q3uYq2GZYk/d3MFT5GxGXajtbsMGftY841wdDgfTrfC3l5iXQ8Xd+bt3Y oChG1ul4Ep8rG3h2n0ZX4bapQMCX2KekEM4pSZxhgBl4v1Pp5bFf3tmxcDir1e/7 lwnFO7FabXOZ/EQQQr1NzFtGd1fSiFKPU3U47/6MSf8yJLavSi/UgUfeCiE9Grzp YtppRHoLSquL1wlYbm3rovi4hz9JlUkWbmm2JNiZ9HU7q3ftSerBgs17ugM6cJzV jMAZr9dFEQz+jOABJCyoaG/k4JVSW50oA4009tckombgX85RR0vQBiF8J99y75PB yrmNEBtRu6SOHjNMB1MstkawgMl+TxZfx8JtS/DiaJssjOb1/YD3cAtF4VkYx88A 2Cc2K2SoOGTdkZ4XQQZCV6cgUw03cYLpaSfRJmdkMMXL5nagjkhI73uhb94ce43s z1iNjQEIuhEFWjSl6euLj9Hah5BZDMh4cDc/sXtRoFWwd0J9piw= =Laqn -----END PGP SIGNATURE----- --Apple-Mail=_E3693147-A099-4B22-9A5C-195CF8066CC2-- From nobody Wed Nov 6 18:12:10 2024 X-Original-To: freebsd-testing@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 4XkCwG6Bwgz1GnqC; Wed, 06 Nov 2024 18:12:14 +0000 (UTC) (envelope-from igoro@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkCwG44Plz4lPK; Wed, 6 Nov 2024 18:12:14 +0000 (UTC) (envelope-from igoro@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730916734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=yg9tOEi6bDxZIMhIj2tO1klUqZJHoiyUMV91qAE+uek=; b=FZK4QOBOIv6lgYcwjbvsFv5WjyAVPM5v6cz9YdYs1YdSr3I82LYXUirzitelkSIlnk5TE/ DzAzJg4Jfmv4kvA/W1LG6voAH2a5zrTX9Vd+4xUBfZ77mpEa4W2/skeN72B/WDn7+AOeTM lQVUoFJhp0Sz7Scm52ER0nnicCUQp5GY603aQPG3IwFOmbefkpSMpm44Dv9LESqHRYpeyR O7Bbbl/VDWl/rmyB+8JHXpThPa/8YnePG3AHbFp10rNukViseqvWPI33mND0aleoC+ppSl Zn+x1KuZMjaY8HQ4HMpEwM6ZaUPEqgsyy870mrBFiUIdUMjUMXIC7wkjBFZFmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730916734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=yg9tOEi6bDxZIMhIj2tO1klUqZJHoiyUMV91qAE+uek=; b=w4awXEUpbWAk0oRMDGXRwL1CvK9N2mkm9iOt3xGT2uc3QNQgGV5m4jDX7uLKeYjCbAZv8D T6F64AuN0QYkYM6Zk8gMIe9ys5UY0UoEZZy7p96XZfF02G9Q9Y4EQ4aC8LDNHUfDw6GAVe UYL4zeCI2Fw0BqEpGhbD8e+Bw7COgbV6sIiGmkjXqaFxCF1FJHKv2cPbnnetIQ99xBumxT FgHBnC4jFRNMK8kYBR8xtqUeP75Q4AaMIkx82A/aXDcsYTdjHi347naGiAgkpImDtjKGYF zzbY9Engggb7NH6sxuf7xgAOSFiRqG1KYL86PEvLwicw3HJGCkUyXilP7v4qag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730916734; a=rsa-sha256; cv=none; b=JPyZrdJXaoOPBoYMjgjV6aGcyHiTHlD/RN5PtnVIYae9sPcaL7JAw+gEIGFCZILsJYXsnV ZprYuglRyNnidqQYUs+vPzTpLjwLb2zvD1WissLyfQ5YPkBO0OI7dfzdbR1mKXqsAh7coo qLN+81ZJqjV2Bt9mU02XliEZX/Q69S8FjVjDA/vN5Vky9CfRDSa2ebbc8iTZBIjub7bHTv aNnF2HKNfD2j013E8sKwiE34F3G153zYbqHqoWxKFnoHdD7JVnTZlvfdy5caHbXI4RTQpA BPTaHx2kSU00yEBMYaC8OjY0/okbvMf0IajvmuMzPI3iLTsIUcVpB89nskmiQQ== Received: from [192.168.0.8] (unknown [78.83.216.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: igoro/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkCwF4NnWzyyj; Wed, 6 Nov 2024 18:12:13 +0000 (UTC) (envelope-from igoro@FreeBSD.org) Message-ID: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> Date: Wed, 6 Nov 2024 20:12:10 +0200 List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Igor Ostapenko To: freebsd-testing@freebsd.org, freebsd-hackers@freebsd.org Subject: RFC: Add required_klds metadata to Kyua Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi FreeBSD developers, During Kyua's execenv=jail feature implementation there were discussions to get some help from Kyua side with kernel modules required by specific tests. The thing got "required_klds" codename. The problem to solve here is a well-known one: typically we invoke "kyua test" and get a lot of "Skipped" due to many kernel module requirements. And the pain is to know which ones need loading, especially if we target a sub-tree of /usr/tests. Also, the FreeBSD CI needs periodic sync if a new test is added with new module requirements. And other related issues. I would like to share the existing ideas and vision before the implementation itself. I propose to split it onto several subsequent projects to ease reasoning, review, etc. Project A: declaration & skipping --------------------------------- Add a new metadata property to Kyua which is used by a test to define its requirements on specific kernel modules expected being loaded. The following interface is expected: - Define it on ATF level, e.g. for atf-sh: atf_set require.klds pf pflog - Define it on Kyuafile level: test_program{name="testbinary1", required_klds="pf pflog"} - Get it listed per test case: > kyua list -v testbinary1 | grep required_klds required_klds = pf pflog if_epair Having it declared we could simplify tests and avoid manual checks for modules with the respective "skip test" lib calls. Thus, this new metadata would work the same way as the existing required_programs and required_files ones -- if some of the required modules are not loaded Kyua will skip such test with a respective message including names of the missing modules. An extra benefit is that we do not need to iterate it like: 1) kyua test, 2) kldload a-missing-module, 3) repeat. Such iteration is usually needed due to our tests typically do kldstat sequentially with "skip fast" logic. Skipping reason information still is not aggregated to make it easy to run a single kldload for all missing modules, but that's another story which is covered by the following Project B. Q1: I have doubts regarding the name of this new metadata. There are several other options in my mind, it would be appreciated to hear opinions regarding this: a) required_klds -- the original idea based on the vibe that FreeBSD Kyua fork is mainly for FreeBSD b) required_mods -- to keep it OS agnostic while Kyua still is treated as an OS agnostic tool, and freebsd/kyua GitHub repo actually is the main Kyua repo in the world today c) required_kmods -- a little improvement of the previous option to make sure it talks about "kernel modules" and leave space for other meanings in the future, just in case d) required_klds | required_kmods -- to have some official aliases supported, but it's expected to bring confusion instead e) your variant Project B: automatic kldload ---------------------------- Having Project A implemented and the existing tests augmented with the respective metadata we could ask Kyua to automatically load the required kernel modules. From the implementation perspective, Kyua is expected to have a generic concept of a requirement resolver. A resolver may read all metadata and decide on its actions. If we decide on "klds" name in Project A then the very first resolver implemented would look for required_klds metadata, if it's present, then the mentioned kernel modules will be loaded. Such resolver could be named "klds", and we can think of future additions like "pkgs" resolver and so on. Currently, I see it as a new kyua command to make it separate from the testing process itself. The interface could be as follows: - List all available requirement resolvers (name and short description): > kyua rr list - Run all resolvers or only specified ones. It would deal with the current dir, and later we can think of "-k" option like "kyua test" command has. > kyua rr run [resolver1-name resolver2-name ...] - It's proposed to be a sub-set of commands in case if in the future we want additions, e.g. dry-run or verify command without actual resolving. Having this interface the FreeBSD CI could have a separate step to run "kyua rr run" before the existing step which runs "kyua test". But from development perspective it may quickly end up with a need to have a single command for both. The following interface addition could be there: - Run all or specified requirement resolvers before the actual testing: > kyua test --rr ["resolver1-name resolver2-name ..."] Another option is to use the existing Kyua mechanisms and add it as a configuration variable, i.e. it can be configured once in the local kyua.conf not to specify it with every test command invocation: # without configuration: > kyua -v rr="klds pkgs" test # with configuration: > echo 'rr = "klds pkgs"' >> /etc/kyua/kyua.conf > kyua test # now it does resolving first Q2: Project B has the same set of questions about naming and style. For example, "rr" name for kyua.conf feels non-obvious and probably it could be named like "requirement_resolvers" to keep it self-explainable. What do you think? Any idea, comment, or suggestion are welcome. Best regards, igoro From nobody Wed Nov 6 20:13:39 2024 X-Original-To: freebsd-testing@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 4XkGcb711rz1GwgX; Wed, 06 Nov 2024 20:13:51 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkGcb4nClz3xw9; Wed, 6 Nov 2024 20:13:51 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730924031; 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=qpHcKTFtaypvTFON8uJkl25LXjvemteJD+pM3e+foH4=; b=u2RyTrppAZYxkRUyv6Z4roFeWfrLJqv16Gi7NqRfMxb4va0r5CjTeVwDhhAi5sephACmns S+PtqPF9Z5uuAuj9eTcijNV3o7aO8tEGhSBUsCUQ+UMWuRsfWlAaiLfZd2UyEnCjULbMA7 VPQWxGSnGoJymmvNnv/YfwKBPdsukL3tMULjWKdAqe72wygerFujZBQtjKt2dnISHRQUvg ioSZvMGwk6nEpLsbbMPzW7Fopm8bZSunzb6SOCEUen8XbL3OUqZg9kAiHM2U00OGkKhYeH LZawjxxm6VybQo8OVO9EXVX1Kb6rO00ZWX5v9t1hMOBsJjy1amtlY8jMyHnbJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730924031; 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=qpHcKTFtaypvTFON8uJkl25LXjvemteJD+pM3e+foH4=; b=BJvn/n22TbgXP7LcR5us995/Kmq/FyA7rpgGlr/Xxsu1U8fZxPyzTR97IlCZX3qu0hdadU L3Vs3XMA6EwZQxr48Z/7kYIMT2lMDCfntAInqn/IrJARIAoQP9zyTj30FBCTgdwvhRBZst SmTxU1TP5PTp2rAhk9yefiY9rTraL/ISkl55yPcLRNqMDZitEr2nqwqa+pKcdWdr5ipUBx 7lR8WvHK8/AR2CdRZVgXB8CO7CaBsSIlm6TuMDieRtoKljjf/wVTbbfa6futYix/uo/GKL G5P3jsvVFfG8iKuZ4JXKcgEW97p8FgJddePliGQh8JqP2I7CerDNHauKJACEKw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730924031; a=rsa-sha256; cv=none; b=b2ODGZO4EcmR+VjvFkU9p4W/h7rjh7yIoEsWU8aLT5LecLp0SZEfoeFV4rOO22GvygxBXQ ONospw8ezzNtk7BDpvzEu8uBCtr7vzOjthWwtXye8PSVrHGXbkzVVt/brTKvyqg+6/JG8M hyM4vM3X1khRBi3BVlB4YWYtSqDWB6TtfsqI1GGrjCrUu64kmII310ZXjg4dXGOUbyh7UM frLk/Sf2W9UF2CwnqrF/GWtpXmdCsEFioWgMhOc32j+R2FspzX4Vt/4Ul8K6mhi6OWCi1A 59liURhjY4DbYJ/L/8U7FkosyDc9aOgULxqVmDaaR09IF9VFet/N6Y3FiAstig== Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkGcb4GRVz121J; Wed, 6 Nov 2024 20:13:51 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-7b152a23e9aso14857285a.0; Wed, 06 Nov 2024 12:13:51 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUZU/S6zX6jKZ5AZvqrOP3Y3lVZneZUhJrRzQe+eg06phdZKdUC1pb4pQnXVXwKkLZMYGhZ9d7lPD5hBu4HN40=@freebsd.org X-Gm-Message-State: AOJu0Yyl406sP32y5aJn0FqnyzHXX+RPZZ8woJmJRdXxLG7M8uzp/XsJ BlirXWcFDo4ZprmSCRbArnh6bPOfGSd605OkWvQ1oROIzYTPO4oBAPwauReC5tTONhUW4EvMQ2k U3+Pv9XFNublBOJrVTvxTH6fD9xk= X-Google-Smtp-Source: AGHT+IGOZ1Jh835ckCMc4Fhn2hJYaDryyX/ntdHeVIK9f5eCmzXgPBhiF+ZDHqK4d3SSTOjHJ3mOCOkiG2FpJE1fpus= X-Received: by 2002:a05:6214:4b11:b0:6cb:eaba:ed5a with SMTP id 6a1803df08f44-6d1856fb306mr481676526d6.29.1730924031211; Wed, 06 Nov 2024 12:13:51 -0800 (PST) List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 References: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> In-Reply-To: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Wed, 6 Nov 2024 21:13:39 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Add required_klds metadata to Kyua To: Igor Ostapenko Cc: freebsd-testing@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000038e8f0626442893" --000000000000038e8f0626442893 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2024 at 7:12=E2=80=AFPM Igor Ostapenko w= rote: > > > The problem to solve here is a well-known one: typically we invoke "kyua > test" and get a lot of "Skipped" due to many kernel module requirements. > And > the pain is to know which ones need loading, especially if we target a > sub-tree of /usr/tests. Also, the FreeBSD CI needs periodic sync if a new > test is added with new module requirements. And other related issues. > > > Hello Igor, Thanks again for working on this topic And there are even more challenging cases: what about tests that assess the behavior of different modules and need to unload them as well? For example, sys/netipsec/tunnel/* or sys/opencrypto/, which involve loading and unloading modules between tests." Regards, Olivier --000000000000038e8f0626442893 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Nov 6, 2024 at 7:= 12=E2=80=AFPM Igor Ostapenko <igoro= @freebsd.org> wrote:


The problem to solve here is a well-known one: typically we invoke "ky= ua
test" and get a lot of "Skipped" due to many kernel module r= equirements. And
the pain is to know which ones need loading, especially if we target a
sub-tree of /usr/tests. Also, the FreeBSD CI needs periodic sync if a new test is added with new module requirements. And other related issues.


Hello Igor,

Thanks again for working on this to= pic
And there are even more challenging cases: what about tests that ass= ess the behavior of different modules and need to unload them as well?
F= or example, sys/netipsec/tunnel/* or sys/opencrypto/, which involve loading= and unloading modules between tests."

Regards,
Olivier
--000000000000038e8f0626442893-- From nobody Wed Nov 6 20:27:05 2024 X-Original-To: freebsd-testing@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 4XkGvw6LtQz5bnW1; Wed, 06 Nov 2024 20:27:08 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkGvw51F4z42TY; Wed, 6 Nov 2024 20:27:08 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730924828; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U7kGfwXdGcXhyr5ABaJ65mkh2vAUg8G1YqyVz47zDlk=; b=Nh7q6WOdvohUXulSbOh/G7SF//QzzBd5fjPDospvJnWtUZ8jpGG6XmCYadSdQThgARvi24 wd0TnLP4V90mxyFQkWf+dbhqKG1XvUGwygun5vZK1Jg0+PeI5jZxXb4gGn9TUX2xhB8kal KpCYkpa4iheCQoG+BYdgDoLqxbTQ/ZXFbVHRJS17RRysdPjx+cS1jsHKTo+1/ThSgYUaat BhJWNu/lxFvcn62MZppT0tEDsT3UzaGaPbKgk57+qsAJWj6WAZeZRe/cjLVJyjlopRUtpF YihE4GtbDLM+99fxWO7N/UJ1/57rXqfbVX/kKOR7rt6LK6Vq7tmCErrYXanWPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730924828; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U7kGfwXdGcXhyr5ABaJ65mkh2vAUg8G1YqyVz47zDlk=; b=dWfB7vsEHZtkC0SDa5aWdbWWoRzzBHh/cThcfiTtUJjQoSGQTpiWrSpm2Ywm2J1m/IG1bE qzBERAI8IZGRDCUxAcQZUZp2l/XR6dfA4tLiMyHCOHGSaw5z6v5e19TeNn5RH1T3Jxm/xA ec3C9rysbG2BSybmN+jZna+ibvgfcYDzQADTrt8EDr/Wu++2wSPBHmLJIPINg+0BnuEmGp 8K9S2pAvSkzM4JyyJyLKVHwmygEqHLCIPuVo4S4svHniTVe8fIUyuC5b8TqzkOO88ubafO 98aCq8J4xLjVztYwE2g4Q4NEvfbyZLmw0MIUT2XtPa2LObnxSgEYtF32DYVFbA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730924828; a=rsa-sha256; cv=none; b=CdRELeQ2R0u7BiuCHO6YQfOExzUn8Eu+JxFHbilJMxWd+6cbWBDKi1pL6SHDRRBmrlkaNf ajXoL6k9PlfqC/DdwVethCJUD/yLFfmn5qNzEsNYoLrwJTo0S2mjKjYpou6XqAYzlTRm/x 7fHOfRbXOWUQwA8aRxl138w6+tLgLmIx5jakEIr43LCdq7GMVejqA8ZZOfRhSAviBbzb35 A3FhWI00eWZVreiuTKWSE3jKRs8yxknGfREespcnfDkPv6q13wvp+wIA+Ud6VseQ5bRXgD UDRE+2SoVhj/OD9+uj09SfBK88BsVuClSNNm4fQvQYquIkluSG8gtTOzcx3K3g== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkGvw37ssz11nq; Wed, 6 Nov 2024 20:27:08 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id D98BA37923; Wed, 06 Nov 2024 21:27:05 +0100 (CET) From: Kristof Provost To: =?utf-8?q?Olivier_Cochard-Labb=C3=A9?= Cc: Igor Ostapenko , freebsd-testing@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: RFC: Add required_klds metadata to Kyua Date: Wed, 06 Nov 2024 21:27:05 +0100 X-Mailer: MailMate (1.14r5937) Message-ID: <9975A26D-6AB4-433F-B4B2-515F956BF366@FreeBSD.org> In-Reply-To: References: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_C07615AC-1A59-4556-90E2-ECBD1E2270CC_=" Content-Transfer-Encoding: 8bit --=_MailMate_C07615AC-1A59-4556-90E2-ECBD1E2270CC_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6 Nov 2024, at 21:13, Olivier Cochard-Labbé wrote: > On Wed, Nov 6, 2024 at 7:12 PM Igor Ostapenko > wrote: > >> >> >> The problem to solve here is a well-known one: typically we invoke >> "kyua >> test" and get a lot of "Skipped" due to many kernel module >> requirements. >> And >> the pain is to know which ones need loading, especially if we target >> a >> sub-tree of /usr/tests. Also, the FreeBSD CI needs periodic sync if a >> new >> test is added with new module requirements. And other related issues. >> >> >> Hello Igor, > > Thanks again for working on this topic > And there are even more challenging cases: what about tests that > assess the > behavior of different modules and need to unload them as well? > For example, sys/netipsec/tunnel/* or sys/opencrypto/, which involve > loading and unloading modules between tests." > That’s a good point. I ran into that a few days ago when I looked at using the new execenv=jail option to parallelise the netipsec tests, and discovered that that wasn’t straightforward. I wonder if an `forbidden_klds` or something is the answer there. At first to skip a test if the forbidden module is present, later on perhaps to enforce unloading of the module so the test can run. That may not be straightforward through, because module state is global, and if we only support loading required modules that’s easy (gather the list and load, or load when starting a test that requires a new module), but if we support unloading them it’ll affect test scheduling. (i.e. we can’t load modules while a `forbidden_klds` test is running, and can’t unload while a `require_klds` test is running). That said, perhaps we don’t need to worry about that just yet. It’s a minority of tests that forbid modules, so those can just keep doing what they’re doing already (i.e. run exclusively, do the checks in the test script itself). It shouldn’t stop us from making the majority of tests better. Best regards, Kristof --=_MailMate_C07615AC-1A59-4556-90E2-ECBD1E2270CC_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 6 Nov 2024, at 21:13, Olivier Cochard-Labb=C3=A9 wrote= :

On Wed, Nov 6, 2024 at 7:12=E2=80=AF= PM Igor Ostapenko <igoro@freebsd.org> wrote:

The problem to solve here is a well-known one: typically we invoke "k= yua
test" and get a lot of "Skipped" due to many kernel module requirements.
And
the pain is to know which ones need loading, especially if we target a
sub-tree of /usr/tests. Also, the FreeBSD CI needs periodic sync if a new=
test is added with new module requirements. And other related issues.

=

Hello Igor,

Thanks again for working on this topic
And there are even more challenging cases: what about tests that assess t= he
behavior of different modules and need to unload them as well?
For example, sys/netipsec/tunnel/* or sys/opencrypto/, which involve
loading and unloading modules between tests."


That=E2=80=99s a good point. I ran into that a few days a= go when I looked at using the new execenv=3Djail option to parallelise th= e netipsec tests, and discovered that that wasn=E2=80=99t straightforward= =2E

I wonder if an forbidden_klds or something is the answer ther= e. At first to skip a test if the forbidden module is present, later on p= erhaps to enforce unloading of the module so the test can run.

That may not be straightforward through, because module s= tate is global, and if we only support loading required modules that=E2=80= =99s easy (gather the list and load, or load when starting a test that re= quires a new module), but if we support unloading them it=E2=80=99ll affe= ct test scheduling. (i.e. we can=E2=80=99t load modules while a forbidden_klds test is running, and can=E2=80=99t unload while a require_klds test is runn= ing).

That said, perhaps we don=E2=80=99t need to worry about t= hat just yet. It=E2=80=99s a minority of tests that forbid modules, so th= ose can just keep doing what they=E2=80=99re doing already (i.e. run excl= usively, do the checks in the test script itself). It shouldn=E2=80=99t s= top us from making the majority of tests better.

Best regards,
Kristof

--=_MailMate_C07615AC-1A59-4556-90E2-ECBD1E2270CC_=-- From nobody Wed Nov 6 21:12:34 2024 X-Original-To: freebsd-testing@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 4XkHwZ1S5kz5brWr; Wed, 06 Nov 2024 21:12:46 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkHwZ0nfsz46T7; Wed, 6 Nov 2024 21:12:46 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730927566; 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=8vgfZxWovyFu3DTrGEeSz0s4WldmqaR6cDmh6Wfc/gs=; b=E76VpsalwIG6sMW5j9c9PdsnrDFPRlYRztS4/KKBB8Qc5VmwYeZiFGMxrjB6CzJYAtwOpx SkUcy3iisu+gu95c0sJVOTEIkyfunCPJR5BGimDJkLitvPsS4cRBXvmAQ/5ncFliUhNotT PXGcPBNneSepwsLw5e0KW4fQu9DfhYEFplWCtxQtBU9jEXk7OR1epMPvxUuRawnl8qlmHc dRwOCRti2KRkes6xrnKVNnIUkMmADvQAahOYMKAMEleOFA9LrJLE++jV+26ayluMXUHhIn kkSfr6p9NaHMIPoZdDa/N8TBDrloo87iaJagM//vt2x5TBMgaCG5WK2mTPgbuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730927566; 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=8vgfZxWovyFu3DTrGEeSz0s4WldmqaR6cDmh6Wfc/gs=; b=JceC0YXrG0NpXP1Cs8hpbN8d6Tf/poLzYfHMG6gcKmUV7A9r8QlByXyCq/kJRG7M1A/u// v0sw41qdtG0LEWZZpRs9Y/SAESXXjdrGRmFSinhj1V0ffyaQx2rLpzjuXgGjst4Nze+bGN 7uw4UXFjN3D686hllMXRRN10zk3wzHeaO08v7NrV6nH7iACOUzXl5gilOYVVXH2aidBljI C7Ng0vf53gByM1PBqgjZkxnHhu7ZvGSGInqAh9wC9E0GNosltaSsoVUjNe4hcAYqhRdFdb g9smnX2uyRp0GhKkkv3qXqB06qgvlS7P9ms0VR1IwfG8Ma0Zd82VzoPibICr6g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730927566; a=rsa-sha256; cv=none; b=cs6iIkGV5RJxw9KRznnJV/ki1unkhLnrzz+kvfuB3rn8ZByWtMFLBSWQQ0tL7zWZCSkqLn 2tzjxa4Hauj+mKtcrZ6MQWneOTzHkQyAE5l1CTJ1sJk8Ltcx62lF3Va6qWj2dojTz0USMm TUbuv3ygxqtSryxWPmygQWoQPmmAJ/oe9aGc8poC3ze2zTyFBgCqm9vngyi63soyKbZtm7 vBGbaujXOg53IeDqIh9xKQLV50XlB1YXUx0ndQAoOWrscIzPFjS3tjl+UiorXWjhLmkxsd SAhxDsLN/3rBEl4pSXj6pQezEr/N+OBxCR+mMUXGiwCMlmSt6xA1QzygJp9xUA== Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkHwZ0Pvvz12g2; Wed, 6 Nov 2024 21:12:46 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-6cbcc2bd800so3075646d6.0; Wed, 06 Nov 2024 13:12:46 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUiMMoEqspoy7XdzmBlL/eNIYcFyapMvllqIqB73eKgPytKfHFrM8djwSDLCeI4JKOKiR3T64hujclKyzQ6S5N4@freebsd.org, AJvYcCXNLl/P1k4W4arikYNxYCItWUrCKwNwUTNvGE3qDMinKM93+CUUORasX8P82vlqwAoR2RKrIPqGdtmZtAlkr8I=@freebsd.org X-Gm-Message-State: AOJu0YwWxtolIvDi5e8p12ceWbDCXul/dnptzJEaWmVwfxrvLWU1GJU+ 5zjvHbgOKz8WGOzhJi4iqE2MnhNYQtdU0Vvd5WuD6CRstIzY+pTiqjlpKb/22W2DZBcLLTUUjC+ 178qd1Ujg1f8U3Vx+T2lzkMnXKiQ= X-Google-Smtp-Source: AGHT+IEIFwy5hV3q6OMmYS+btyL55sXUIhmB80HCVWofAU7WnodJ6SPohPX64CLnI/Ic5wQPrJ0O13xn4reVLID5GYI= X-Received: by 2002:a05:6214:5293:b0:6cd:fd5d:88f6 with SMTP id 6a1803df08f44-6d393e3a554mr11868256d6.7.1730927565393; Wed, 06 Nov 2024 13:12:45 -0800 (PST) List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 References: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> <9975A26D-6AB4-433F-B4B2-515F956BF366@FreeBSD.org> In-Reply-To: <9975A26D-6AB4-433F-B4B2-515F956BF366@FreeBSD.org> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Wed, 6 Nov 2024 22:12:34 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Add required_klds metadata to Kyua To: Kristof Provost Cc: Igor Ostapenko , freebsd-testing@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000aae642062644fa4a" --000000000000aae642062644fa4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2024 at 9:27=E2=80=AFPM Kristof Provost wro= te: > That said, perhaps we don=E2=80=99t need to worry about that just yet. It= =E2=80=99s a > minority of tests that forbid modules, so those can just keep doing what > they=E2=80=99re doing already (i.e. run exclusively, do the checks in the= test > script itself). It shouldn=E2=80=99t stop us from making the majority of = tests > better. > Yes, I totally agree. The benefits of running parallel jailed tests far outweigh the very few tests that won't support module unloading. Regards. --000000000000aae642062644fa4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Nov 6, 2024 at 9:= 27=E2=80=AFPM Kristof Provost <kp@free= bsd.org> wrote:

That said, perhaps we don=E2=80=99t need to worry about tha= t just yet. It=E2=80=99s a minority of tests that forbid modules, so those = can just keep doing what they=E2=80=99re doing already (i.e. run exclusivel= y, do the checks in the test script itself). It shouldn=E2=80=99t stop us f= rom making the majority of tests better.

=

Yes, I totally agree. The benefits of running para= llel jailed tests far outweigh the very few tests that won't support mo= dule unloading.
Regards.
--000000000000aae642062644fa4a-- From nobody Wed Nov 6 23:58:51 2024 X-Original-To: freebsd-testing@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 4XkMcF42bXz5c1gR; Wed, 06 Nov 2024 23:58:53 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkMcF3VHGz4Qs0; Wed, 6 Nov 2024 23:58:53 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730937533; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+ycPrWJGFEuIFcMun2lArQ/PpLxthpAKgcd/ZkcZuG8=; b=s4a06j9BXcc/hYj5g7YwdLcWN2yufGQvDLSbd9mtMJ0KzPb1s9wcIytt/xYjXvrQVHSsZF APrxoPGk32OKq9t+WWblCX6k1rqvbKbcIa2eQdcgLWCuoFfmj/kbFZbf65tuWyltcN5EiX Jp829AQJjOtAi6ejnpPZw2qVYFpm8hpWCHkOpYuDPT9/rL7jR8PpL8KmhNJjyW5TRdS4Fm TRuSVbKaFmG1e2byKzhwpmVNeA6IRAQw6wFcKHX6S0elIpgTtdANd4QW9VNZlpZh5SIqOW myI5j0lSbV748akIg120Rodv0BsJlZR4Lx+YcPG2r4ppcFnvFqkogaGmpBW7wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730937533; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+ycPrWJGFEuIFcMun2lArQ/PpLxthpAKgcd/ZkcZuG8=; b=U8pMZP+Vq8SQTldOBzQVjRpZs0/LU1JuEwiIYl8ZzCGsTgErSY3Sy1AeA65Ib1V7MEGoHi y0X4ehdHPZpyXcvj/s/NoRZqT8LUrI4VWtwhkf43XdLB6LlkNVwNfgZPNzwSmmF1pVo69F U8dkyPvaaXjnfbDMAoVxcCVm49YDwh1U5ARP1AoUJNDYazysZysk+xzSOwU6xr6lpSDp5F oeN2aDEyRHue06o5BLFRm6xelI6hu4aLCVs+KtErEnv6ODT8WhVX5Wn8Yh60sietGEwygh ESXqASm5Z1AbUbCbYs/JjNXVMFHxy5458TiZarqaKtE7nALVExcBfHbutXRTgA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730937533; a=rsa-sha256; cv=none; b=Bq2T87ViP127q3VyArWedwjR08sib26qb23R10A/U2vpU6SWKo1LDvdtybVj3AKqZh/f3I DIxtaAnsRicWbojDLWhiEP0zTU9tFq+y8fJQRqWKF5XPNwhhsDnwB1aLrN754/Y4Z3zspA r/aTOEBiaUgOLvOPGgmPbE9nxZSKhW/GA4BeM8gLkNqSQckoOR6eWr6OZKXnNzcA1NsB36 KoNwhOLEwIFa60fHhH+qFPCyWFf/UZKyZHXf+61Mdq3hNma4eBA5VcUY7GKxTzjsjlTNRL bM+mPC6kRpMHMiweC1w0bk4NjhuYggcj31Z8zF+yxV2EFTTHXYXPb6OApwNs3w== Received: from ltc.des.dev (unknown [IPv6:2a01:e0a:c54:bed0:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkMcF2Q0mz13Jg; Wed, 6 Nov 2024 23:58:53 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id BE20C8ED4; Thu, 07 Nov 2024 00:58:51 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Igor Ostapenko Cc: freebsd-testing@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: RFC: Add required_klds metadata to Kyua In-Reply-To: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> (Igor Ostapenko's message of "Wed, 6 Nov 2024 20:12:10 +0200") References: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 07 Nov 2024 00:58:51 +0100 Message-ID: <86bjyrud6s.fsf@ltc.des.dev> List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Igor Ostapenko writes: > During Kyua's execenv=3Djail feature implementation there were discussion= s to > get some help from Kyua side with kernel modules required by specific tes= ts. > The thing got "required_klds" codename. https://reviews.freebsd.org/D47470 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Thu Nov 7 11:44:11 2024 X-Original-To: freebsd-testing@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 4XkgG66815z5ckXX; Thu, 07 Nov 2024 11:44:14 +0000 (UTC) (envelope-from igoro@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkgG642mvz4VvQ; Thu, 7 Nov 2024 11:44:14 +0000 (UTC) (envelope-from igoro@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730979854; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z7K3vsA8othGIgBUtCt/kOtRFYLpA0bxR2mHRiK8W0M=; b=ofe5C9hMO6EyoQ3K78lykDU3zK2jfvmcROT/C/PKx8RqiKT607VlJtzYmtKfZ9LAYt8/Br k0kfFGNKWjq8ERQ2sd2NdpFYUMJr3wNrGK+vCfa+CKS23fr1ZM00aL2ovL+acS1L6G4FvU VuDfEvFGKwLbyuOS7NAcdtZLDhJ0TrQXZ/7ctD53wOiv+7DTdLabj1UC5+Q5Rh2RKXjh+L XXFeUrK/jes3fAlnWK4zHYFbppA+3vZzV1W/2jia4vEYSFeUYIX6iaT/TUr7NAEKtq+Kka WLKsVRTEwo1lhTL24RVZP8U0cZHMne+VtKv5k6nfUzRNJcVqUT6FrsGdPRCgTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730979854; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z7K3vsA8othGIgBUtCt/kOtRFYLpA0bxR2mHRiK8W0M=; b=dFV3KBaWyflhOs6xkoP02Ps9hqTAZ042WoayUW2viWa1eNBy3xv21Jtoj50wpMEyEQKTcB AWONspXjS93eNfMSpPYmvaNeOg+GoPvM6B/59nzRYWVLe7jpwLn6zY1GkpaObMVXDOar0f IsogUmVU3vcktlVaU6V7GDZOUndz2fYWwB5ep2y0RKSyVcU9fnowXwqxZawX59EhBC/DEC bxsxf8WncaZ0bk1RMTZdLzz1JlA3crv4izD3fnr9XXjOKdIpA8w83QyYxPPhi9XmyYmCUY J2PkBLR9dPbBOHuXv/HWw7v+wprgKb95GPH8PDOGVvr7X1yMJHxa5ONo7mvOqg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730979854; a=rsa-sha256; cv=none; b=B14VY+Dh4LmlNlbFp5Q/9S5ao2oW6OlnUylS7ppqYID7Cw815aIKJhddALWqtBQwWZHapP 5TVJCYjULGoQWCACh4m+X7iraCFXwCZd/TcLTbbMx9CjTTcKRGVKxgKPjrUahVn22PpQ3n zceE0n8ecJCrg17F6cMzkuGHnaSpYXdpD2+kZ5Bu2RQEA9GMf2xPx407jw3fhOKZ7qTvw3 v058nYYABERYHNx2B7t78WtKsDNMfzsJ2Kxg6zbpySTJO1XQvj52EuBL+5oq4gy8YntZjU cMkAG9N274x9dHWvCZ5qmIaGRhY4OVxYXBCegwuB03cJuehTOEuBgyPxlW8dqg== Received: from [192.168.0.8] (unknown [78.83.216.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: igoro/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkgG55zjNz1J65; Thu, 7 Nov 2024 11:44:13 +0000 (UTC) (envelope-from igoro@FreeBSD.org) Message-ID: Date: Thu, 7 Nov 2024 13:44:11 +0200 List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Heads-up: Removal of devel/kyua port To: Moin Rahman Cc: freebsd-testing@freebsd.org, freebsd-hackers , freebsd-ports@freebsd.org References: <9e175f3c-4be0-437d-abf6-7f9d820154e7@FreeBSD.org> Content-Language: en-US From: Igor Ostapenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Moin Rahman wrote on 11/6/24 3:01 PM: > > >> On Nov 6, 2024, at 13:40, Igor Ostapenko wrote: >> >> Hi, >> >> Kyua has been part of base since 13.0, today it means all supported versions. >> >> The tests in /usr/tests usually have parity with Kyua in base, i.e. even if we consider older unsupported systems then new features from the latest port offer limited benefits. Anyway, these cases are not supported. >> >> So, in order to avoid double work and user confusion, the devel/kyua port is being considered for removal. >> >> The motivation of this notification is to collect comments and suggestions in case if the removal is not a good idea for some reasons. >> >> >> Best regards, >> igoro >> > > Hi, > > I am not exactly sure if the one in 13/stable is the updated > one as I merged the latest code into the head and 14/stable. > That's why I planned to kill it sometimes during the EOL of > 13. > > But correct me if I am wrong. I have not checked the stable/13, but I know that the recent MFC of Kyua changes in head was targeting stable/14 only, i.e. 13 was not considered intentionally. And I think stable/13 must be fine having its old set of tests which must be executable by the version of Kyua in its base. That's great to hear that similar reasoning has been applied before and it's already targeted for removal. The only thing I suggest to do is adding DEPRECATED with a message that the base version must be used instead. We've recently faced a fail case when users run the latest test suite with the older Kyua from ports, that leads to unexpected errors developers should not spend time on. The deprecation notice is not going to save us, but it's at least something. Please, check this proposal: https://reviews.freebsd.org/D47473 > > Kind regards, > Moin From nobody Thu Nov 7 11:55:37 2024 X-Original-To: freebsd-testing@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 4XkgWW0Bbdz5cln2; Thu, 07 Nov 2024 11:55:51 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkgWV6n9fz4Yv3; Thu, 7 Nov 2024 11:55:50 +0000 (UTC) (envelope-from bofh@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730980551; 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=ghYgAS05ZOO3pGNMSBLm4/5E1Dg0ljy2Sb7quycjP3A=; b=PnOEhM7Fj7Mop4iFeFvcvIy4OwcETZrU1t0g4z9m9IIUEbr8hWSjDZ1P3Uv4P58U4wkJxD ti8Hx6n8UjM8xUiQr7wOMNJA4/H2k2z0n6EZA/a37yJhbApy77o6WSWrkYWVIY2KTqXMk4 HUtucwlHbOg4iE1Q2WOv1z2cBNx5ty0uCp+9wQpTLm+UCk//D2PW/gY0z8xMqG8oUyfr8/ 7hMbZIVJ4LCYexClrLI5c9LLZa0KwxD1Nvh8RyCNf+BnuL6mSUv2LEddrRyRrKi8jTh2Cz IGJdn4zKGKDmnQER4HplVuag1RTThIKoaBmRE0dlMuWhpyr9U9oAkR4eHBdf8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730980550; 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=ghYgAS05ZOO3pGNMSBLm4/5E1Dg0ljy2Sb7quycjP3A=; b=dJwVQMtzcmjQGfi8IsW6nlspuAGNEzRpY43OMvBQgaLZsKw58Mf55fUvrqxwrBq3+zWT8+ xrsYixpm6TW9Lh4UptPKy/0DWokTW2Nbx5GnGF+3/HOFKVYMJIdowKImBi8EhIU2lpeRiX TtcGo48141SCHYSZzL791S5pjcFm31Ia2jOm7aCKVYV2oG6lXNSfTDqSWrEzNDahexNtP0 758/7bTEmDa3PqZm6Dq+Nc2cPuYetphYsI3X4KdBprRRlcZ6fSLfaIftRFCrj2r/lgPIbW ICuMcCyMzlv6mjQaHpy0Hlzhk9Jz7yXwLhvE+296f0SCVYgN3C+duI2QnrZQnA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730980551; a=rsa-sha256; cv=none; b=a+lCeSTLUtekAL4avLnQNSvKuL/YdnLKAFJPAV09oJanWCmJtTEJbvm+V3iTQQ/FcSDxKl giRpBrxe1d/h1s8FqOxts0AgjdolK1+fMxxZhNH9605Dw7D/q+m2H357EEZC16IqKBKqYY t3F/m7i5pmt13d6vAJVaWU47s0TPrE1FIgq5E5z429kMSi1ijXX5KNJADXFZO7IsjvHlEW SikQo9TyuEEK4D6XLn4Mt3yOV2uhNatm4zvlfu0NkI3VBY/XTIXFITiwdphEg99GakGt43 GQe6578b009YRS4IwUZtmiSapWA9mcazxRw5HT9bxR+STSUUoCRotyoYTcey9Q== Received: from mx.bofh.network (mx.bofh.network [5.9.249.227]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bofh/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkgWV24k2z1L1F; Thu, 7 Nov 2024 11:55:50 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtpclient.apple ( [217.117.226.147]) by mx.bofh.network (OpenSMTPD) with ESMTPSA id 9615b6e2 (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO); Thu, 7 Nov 2024 11:55:48 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_CF03EB3B-30BD-46A8-9999-142F93A6F579"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\)) Subject: Re: Heads-up: Removal of devel/kyua port From: Moin Rahman In-Reply-To: Date: Thu, 7 Nov 2024 12:55:37 +0100 Cc: freebsd-testing@freebsd.org, freebsd-hackers , freebsd-ports@freebsd.org Message-Id: References: <9e175f3c-4be0-437d-abf6-7f9d820154e7@FreeBSD.org> To: Igor Ostapenko X-Mailer: Apple Mail (2.3731.700.6.1.9) --Apple-Mail=_CF03EB3B-30BD-46A8-9999-142F93A6F579 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 7, 2024, at 12:44, Igor Ostapenko wrote: >=20 > Moin Rahman wrote on 11/6/24 3:01 PM: >>> On Nov 6, 2024, at 13:40, Igor Ostapenko wrote: >>> Hi, >>> Kyua has been part of base since 13.0, today it means all supported = versions. >>> The tests in /usr/tests usually have parity with Kyua in base, i.e. = even if we consider older unsupported systems then new features from the = latest port offer limited benefits. Anyway, these cases are not = supported. >>> So, in order to avoid double work and user confusion, the devel/kyua = port is being considered for removal. >>> The motivation of this notification is to collect comments and = suggestions in case if the removal is not a good idea for some reasons. >>> Best regards, >>> igoro >> Hi, >> I am not exactly sure if the one in 13/stable is the updated >> one as I merged the latest code into the head and 14/stable. >> That's why I planned to kill it sometimes during the EOL of >> 13. >> But correct me if I am wrong. >=20 > I have not checked the stable/13, but I know that the recent MFC of = Kyua changes in head was targeting stable/14 only, i.e. 13 was not = considered intentionally. And I think stable/13 must be fine having its = old set of tests which must be executable by the version of Kyua in its = base. >=20 > That's great to hear that similar reasoning has been applied before = and it's already targeted for removal. The only thing I suggest to do is = adding DEPRECATED with a message that the base version must be used = instead. We've recently faced a fail case when users run the latest test = suite with the older Kyua from ports, that leads to unexpected errors = developers should not spend time on. The deprecation notice is not going = to save us, but it's at least something. >=20 > Please, check this proposal: https://reviews.freebsd.org/D47473 Based on what you have mentioned above I believe your DEPRECATED message is too soft. :/ And I think we should handle it in a different way and mark it to IGNORE for 14 or later also. Kind regards, Moin --Apple-Mail=_CF03EB3B-30BD-46A8-9999-142F93A6F579 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----- iQKTBAEBCgB9FiEETfdREoUGjQZKBS+fvbm1phfAvJEFAmcsqrpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRE Rjc1MTEyODUwNjhEMDY0QTA1MkY5RkJEQjlCNUE2MTdDMEJDOTEACgkQvbm1phfA vJHtpQ//QV0Nw1IkVyVMItfcDSoKK2kxONRdHaAfwNXdVT30crEsqerD10KFBMAb boWJNAuFBzrHr8oJW5uYxET/GFg+Sk7mPtCBKBl9aQgUUKJEkrY2qAqrMRVLLD76 0ssGHKs0qB6wzFx+h04TYMxbeEP97J4RYRdOvf+Ggb71uGYv60Esnhx710jmdtOv iqg/WQIjaDNMixukXA/sMTE7fAN6Ce8nGb/YxSJq6ed7mYYu1C0dgZpgH9ZwwuBs 2pjYoiC5orXKJg1HGI9Znfj/t7BtEAgbw7asHNQPli6xybAY6NyTMdD2V4RgsVFt VWwpvOaURfDwFmGeCP9mYEaSjdA5aX/MkTyxBtNq8OM455m9+9x9U4dGL+PE9GpY hwIn+mFgb8y6PG7EYp6KpcD5UZc6TCzt53i5uKT5R9XrBYQ4xdjynyNYRF7yLiL1 lyz3x9aJn0GLeCtALoS8GMomJ4GFaX6h2D3kvEjPD4a8Gm562+uKIycDPuByB3ml LIfrH/MB4/pdvDsVFEzqfx7etVCMY0teLvBM9Aga2fwE1Bvi1IsxNOfShvczXUm4 NParqBU8j7Y8kXmdy/cIY2q//+fHdXA92U+gNg3NkEhLoeWz4in2WzLno70k8WDT Gc0iAIN5riSgnKZsIPzfbD+mxiGVOtBZ0807QekyrDxijwDHvYE= =JjTp -----END PGP SIGNATURE----- --Apple-Mail=_CF03EB3B-30BD-46A8-9999-142F93A6F579-- From nobody Thu Nov 7 15:16:06 2024 X-Original-To: freebsd-testing@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 4Xklys6QVXz5c03b; Thu, 07 Nov 2024 15:16:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xklys4XKxz3wq8; Thu, 7 Nov 2024 15:16:21 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5c9362c26d8so3848433a12.1; Thu, 07 Nov 2024 07:16:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730992579; x=1731597379; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=srf+epAWm1ok6G5Wr2NN54Jeqt3/TpjUZADdF77PSTk=; b=p4/Mp4tOBMvdnrmv4/JC0z/TISzZzSa7Du+FxzaAcHL1NRPIQ5je/BokqLb+xz0nhs uNxsRT4V51ceXHnpuh9mtXjXaQdiYK+M3CAz4P4XKn+lzPRYI7IEnYFhM0ue9NPw+FL0 yHBSh2rfjD9yPMBH6+bNF5IusTA/pn5aIm8NErxkPrsi5NPubrv7Rkkiae52tn9iRqnl 1uZs1nbRsfAaRjLFIotxRd1mwvkjgVQTOtsryzSgUF8nqfxO08KWm/FWo/2p7k8BvY3E cWW2LCVD4RIqJznVof9Eazv0FlM02cHOwb0C72uG61TkrDEab8KbkM4D/+21p2F6E3fq 5HgA== X-Forwarded-Encrypted: i=1; AJvYcCUib1YbZZIdIV7zrNflnkZnWkn8IAJWS3+AsqFI7ChEktUN+W0i/ajNGAqxeh69DOqP/wyoLnM=@freebsd.org, AJvYcCVx0T0gLSCdKB141M9bK9rDHQYS3YKwaQOOLuKcxvUW6h+/z5CEo6fHZ6MY31byFU4j90IG4lOvOaHTwgXQMwFl@freebsd.org, AJvYcCW6CybSKJKX5jNxdpHd8OQ2xchX2ovQkEjcA4A8QgLlfMV+8bj7+snWGbgKbpW+NyjzRyqu8ahOW88u/63a/s8=@freebsd.org X-Gm-Message-State: AOJu0YwID8siPIuuu3I3Svhi+9+gGO+jv43ImCNSgqf+MFaydKXDhJuu OHBUwrliKWiyDlsLoam/GKGy0lom2uKjgXDI79l4hRSOG4f8g8ShzM54cAbZ3Vh8bYS9jT5R2dt M2BMnHLEwIXJC5+iCNEYPoO8UisEn48n4 X-Google-Smtp-Source: AGHT+IFcPUST7VXkyOeDryku6YD4QkGpaB7YCWgPSnyu70xYvCth0a+CsoAtaPA8bZQb7yG23yz2dxXIKmdS9bCWqfQ= X-Received: by 2002:a05:6402:2746:b0:5c5:c2a7:d535 with SMTP id 4fb4d7f45d1cf-5cf08c2e598mr428629a12.16.1730992579073; Thu, 07 Nov 2024 07:16:19 -0800 (PST) List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 References: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> <9975A26D-6AB4-433F-B4B2-515F956BF366@FreeBSD.org> In-Reply-To: <9975A26D-6AB4-433F-B4B2-515F956BF366@FreeBSD.org> From: Alan Somers Date: Thu, 7 Nov 2024 08:16:06 -0700 Message-ID: Subject: Re: RFC: Add required_klds metadata to Kyua To: Kristof Provost Cc: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= , Igor Ostapenko , freebsd-testing@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Xklys4XKxz3wq8 X-Spamd-Bar: ---- On Wed, Nov 6, 2024 at 1:27=E2=80=AFPM Kristof Provost wro= te: > > On 6 Nov 2024, at 21:13, Olivier Cochard-Labb=C3=A9 wrote: > > On Wed, Nov 6, 2024 at 7:12=E2=80=AFPM Igor Ostapenko = wrote: > > The problem to solve here is a well-known one: typically we invoke "kyua > test" and get a lot of "Skipped" due to many kernel module requirements. > And > the pain is to know which ones need loading, especially if we target a > sub-tree of /usr/tests. Also, the FreeBSD CI needs periodic sync if a new > test is added with new module requirements. And other related issues. > > Hello Igor, > > Thanks again for working on this topic > And there are even more challenging cases: what about tests that assess t= he > behavior of different modules and need to unload them as well? > For example, sys/netipsec/tunnel/* or sys/opencrypto/, which involve > loading and unloading modules between tests." > > > That=E2=80=99s a good point. I ran into that a few days ago when I looked= at using the new execenv=3Djail option to parallelise the netipsec tests, = and discovered that that wasn=E2=80=99t straightforward. > > I wonder if an forbidden_klds or something is the answer there. At first = to skip a test if the forbidden module is present, later on perhaps to enfo= rce unloading of the module so the test can run. > > That may not be straightforward through, because module state is global, = and if we only support loading required modules that=E2=80=99s easy (gather= the list and load, or load when starting a test that requires a new module= ), but if we support unloading them it=E2=80=99ll affect test scheduling. (= i.e. we can=E2=80=99t load modules while a forbidden_klds test is running, = and can=E2=80=99t unload while a require_klds test is running). > > That said, perhaps we don=E2=80=99t need to worry about that just yet. It= =E2=80=99s a minority of tests that forbid modules, so those can just keep = doing what they=E2=80=99re doing already (i.e. run exclusively, do the chec= ks in the test script itself). It shouldn=E2=80=99t stop us from making the= majority of tests better. > > Best regards, > Kristof I too like the idea of Project A with required_klds or required_kmods. But how would you handle situations where a user customizes their kernel config to build some feature that's usually a module directly into the kernel? I would think that would break any test using required_klds. But project B is going to be a lot harder. "forbidden_klds", as suggested by kp, might be the way to go. In addition to the abovementioned suites, the fusefs tests are incompatible with the mac_bsdextended kld. I suggest focusing on Project A for now. That would be great even by itself. -Alan From nobody Thu Nov 7 15:43:49 2024 X-Original-To: freebsd-testing@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 4XkmZc349Xz5c1cG; Thu, 07 Nov 2024 15:43:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkmZc2ZLfz45F1; Thu, 7 Nov 2024 15:43:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730994232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AL8TUioIRP6V8bClOiAG+bdrwp4lu/9pJGqlEYfRsnw=; b=iUTc9TJflxPnNVgzphnxpsaltodr2pW2G+xzjaNz3jPKjvd80mtJH+PrsQtb99Ioc2rKa/ oix84WZzXr9xCYhy3je0ZPEWcMz/9v0m6076aI4iKwH535TV4SKyC1A8a5vihLHVqdF7vO FX2p8YIH8KbO7zqK9dsx8SgyOSaR5+dM1AzvYjEVUCOlsqTxjzMHrGOBe2le/wm/rkaw9B rxwqpVNsp/h5sI4m3Iz5z8Vj4ATB7s6GmPHdywmnBFyUzVtKXGfV6A0Cl8ehU3DwWvxvyD eXv5Yl8HJUfCTCh2HZvzGkQrdABk2M1muo29yg1o3pUT4R9kdwF0/KlqinNFQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730994232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AL8TUioIRP6V8bClOiAG+bdrwp4lu/9pJGqlEYfRsnw=; b=qfrY227t55EJ7MuNahlUZHgLor9y01Cb6uhn+3hF6b2qk6q+v3nN3WdCRKXm5nu6V44TVV TQACBeIPPmqQl8RlAyFhYdWauLxyCDxn7IML0JZp3yrhSQ6rRnXwSQaoR0aP1xP9/q05VT bIfgzZf8kcFb3BqAEhCy8Gf0+GO1J3u362yVBcJWf2Va3moIqhclW/mLKgrwoNW9GpV5r7 4ciJ6krljeZ70uP+f7c9BXg5ZomUpzCdiyjO9au41kH32bKMHCPegUWx1+HKHZJfdQdMIc gZFJznbkpaLJCyxzxPQxIp+7nPUEtbTR1VqUxYAwcAl7QZnfUkNtxG6ll1KTWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730994232; a=rsa-sha256; cv=none; b=d77uMAo7jkkI6lsreIDtbVg9GjWm/FHJLK1uzd4q6Hd3XQsYR+pbq17jEadpeQUykv3Zva 3NvhToaLFygF+qKLbFl1rBwaz8X4l+OMYIw9ujf1XJx4+n8HrOMrKUDzU4Iz4xe9A/cPB+ diImCR55lsCFqIN7T0ULBpQ8fYH/nnxxcq4SLi/jyKiZyrUBwmyjcyKWVXYilobqJFefBr 78be4K/zSAK5KUOCs3XDU+SFzqF8KVuNKA4xOW0o0AVChRXsIGuuxqQ9h9n5VOQN/5M0Jl c4g+iBqS8kgnFRjrL3WC+Akoh+WVLz+tmA5M+dbsmsUv0IisTY5KlTGvN199ug== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkmZc0jGnz1QlM; Thu, 7 Nov 2024 15:43:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id D148B42E78; Thu, 07 Nov 2024 16:43:49 +0100 (CET) From: Kristof Provost To: Alan Somers Cc: =?utf-8?q?Olivier_Cochard-Labb=C3=A9?= , Igor Ostapenko , freebsd-testing@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: RFC: Add required_klds metadata to Kyua Date: Thu, 07 Nov 2024 16:43:49 +0100 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: References: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> <9975A26D-6AB4-433F-B4B2-515F956BF366@FreeBSD.org> List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E1688D6D-F804-4D3F-B9BC-1BE59FE56D88_=" Content-Transfer-Encoding: 8bit --=_MailMate_E1688D6D-F804-4D3F-B9BC-1BE59FE56D88_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7 Nov 2024, at 16:16, Alan Somers wrote: > I too like the idea of Project A with required_klds or required_kmods. > But how would you handle situations where a user customizes their > kernel config to build some feature that's usually a module directly > into the kernel? I would think that would break any test using > required_klds. > That’s actually fine if we use `kldstat -m` or modfind(). It’ll still find a “module” even when it’s built into the kernel. For example, pfsense builds pf into the kernel: [24.11-BETA][root@pfSense.jupiter.sigsegv.be]/root: kldstat Id Refs Address Size Name 1 19 0xffff000000000000 28e4d90 kernel 2 1 0xffff0000028e5000 46e278 zfs.ko 3 1 0xffff000002d54000 3e258 opensolaris.ko 4 1 0xffff0000b1c00000 27000 safexcel.ko 5 1 0xffff0000b1c27000 26000 cryptodev.ko [24.11-BETA][root@pfSense.jupiter.sigsegv.be]/root: kldstat -m pf Id Refs Name 440 1 pf Or when it actually is a module: freebsd_current_zfs# kldstat Id Refs Address Size Name 1 48 0xffffffff80200000 1f75b10 kernel 2 1 0xffffffff82176000 6320 filemon.ko 3 1 0xffffffff8217d000 78fdf8 zfs.ko 4 1 0xffffffff83010000 2a68 mac_ntpd.ko 5 3 0xffffffff83013000 5adc0 pf.ko 6 1 0xffffffff8306e000 9688 pfsync.ko 7 1 0xffffffff83078000 2260 pflog.ko 8 1 0xffffffff8307b000 128a0 dummynet.ko 9 1 0xffffffff8308e000 9890 carp.ko 10 1 0xffffffff83098000 18148 ipsec.ko 11 1 0xffffffff830b1000 7bf98 sctp.ko 12 1 0xffffffff8312d000 2568 ipdivert.ko 13 1 0xffffffff83130000 88d8 if_bridge.ko 14 1 0xffffffff83139000 5120 bridgestp.ko 15 1 0xffffffff8313f000 52a4 if_epair.ko freebsd_current_zfs# kldstat -m pf Id Refs Name 506 1 pf freebsd_current_zfs# kldunload pfsync freebsd_current_zfs# kldunload pflog freebsd_current_zfs# kldunload pf freebsd_current_zfs# kldstat -m pf kldstat: can't find module pf: No such file or directory — Kristof --=_MailMate_E1688D6D-F804-4D3F-B9BC-1BE59FE56D88_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 7 Nov 2024, at 16:16, Alan Somers wrote:

I too like the idea of Project A wi= th required_klds or required_kmods.
But how would you handle situations where a user customizes their
kernel config to build some feature that's usually a module directly
into the kernel? I would think that would break any test using
required_klds.


That=E2=80=99s actually fine if we use kldstat -m or modfind(= ). It=E2=80=99ll still find a =E2=80=9Cmodule=E2=80=9D even when it=E2=80= =99s built into the kernel.

For example, pfsense builds pf into the kernel:

[2=
4.11-BETA][root@pfSense.jupiter.sigsegv.be]/root: kldstat
Id Refs Address                Size Name
 1   19 0xffff000000000000  28e4d90 kernel
 2    1 0xffff0000028e5000   46e278 zfs.ko
 3    1 0xffff000002d54000    3e258 opensolaris.ko
 4    1 0xffff0000b1c00000    27000 safexcel.ko
 5    1 0xffff0000b1c27000    26000 cryptodev.ko
[24.11-BETA][root@pfSense.jupiter.sigsegv.be]/root: kldstat -m pf
Id  Refs Name
440    1 pf

Or when it actually is a module:

fr=
eebsd_current_zfs# kldstat
Id Refs Address                Size Name
 1   48 0xffffffff80200000  1f75b10 kernel
 2    1 0xffffffff82176000     6320 filemon.ko
 3    1 0xffffffff8217d000   78fdf8 zfs.ko
 4    1 0xffffffff83010000     2a68 mac_ntpd.ko
 5    3 0xffffffff83013000    5adc0 pf.ko
 6    1 0xffffffff8306e000     9688 pfsync.ko
 7    1 0xffffffff83078000     2260 pflog.ko
 8    1 0xffffffff8307b000    128a0 dummynet.ko
 9    1 0xffffffff8308e000     9890 carp.ko
10    1 0xffffffff83098000    18148 ipsec.ko
11    1 0xffffffff830b1000    7bf98 sctp.ko
12    1 0xffffffff8312d000     2568 ipdivert.ko
13    1 0xffffffff83130000     88d8 if_bridge.ko
14    1 0xffffffff83139000     5120 bridgestp.ko
15    1 0xffffffff8313f000     52a4 if_epair.ko
freebsd_current_zfs# kldstat -m pf
Id  Refs Name
506    1 pf
freebsd_current_zfs# kldunload pfsync                                    =
                                                                         =
                                                                      	fr=
eebsd_current_zfs# kldunload pflog
freebsd_current_zfs# kldunload pf
freebsd_current_zfs# kldstat -m pf
kldstat: can't find module pf: No such file or directory

=E2=80=94
Kristof

--=_MailMate_E1688D6D-F804-4D3F-B9BC-1BE59FE56D88_=-- From nobody Fri Nov 8 12:38:17 2024 X-Original-To: freebsd-testing@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 4XlJQB1dn1z5cgpW; Fri, 08 Nov 2024 12:38:26 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XlJQB0VhWz4MdX; Fri, 8 Nov 2024 12:38:26 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731069506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8TeE0Pj7T6vu2vQhVMdW9DLkkPT62tOjBOzY83spD2Y=; b=mgRlNLW2E2n8dweC1ZIuWQ7DuHK8zJKVjpFkunW6ewaGtJojsAnFnmkCIK8i5rzvq1s0xa +DNo0UBpbjhGCbh1zSfbGREyXRu6h72rL/mfB8KC3BwgkUft+DUapB2ttlvs1b9ztWoaQK BC/IClKdMpvMHM37nJlqsrUdOdqmEuKfAMtICZAX7ebkwfFqGHJCvKRFhlC+7bDcyapfKg 6ZEVusDEei0VRgnkI+xhjEp4eQTEYDnwdgChxZx8ccpEzDE5Mmg3IkFuOtI6+EvX3SRGYL MVAphv5PdlXVqt/S9Gpr/NETCoqY07KDc41sQ/pGOfwvvC4tpaUFeMFzb8aq1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731069506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8TeE0Pj7T6vu2vQhVMdW9DLkkPT62tOjBOzY83spD2Y=; b=vC/rht3sfGuoY0H51sASJsKioW48Oz3GInp2yBfAt0H88ZD3fQHT4jlKcG7kqY/x0yPBLa g09TgdoPqwovFWYklaBMxNSg/fiiHN9VkTXXMouK+ildSVQ8H8qUF6b+r41qDZgc0kFzWT GPAtH76b/9PCSgsPmXhVUZnkmvvM8VYj8ZJZF2jRxI7jM9AQdS5C3vqO6wRf4etX5vK+L8 WtXv/pY2EHr33StIBNFR5lX0DsEY0A5HPF7S1Yj0Ml9Mvet1HIdCfH7aPZ3kH/qISl63C6 MqTFEz9H/0FjjRA1ESQzyKcZFTjhRQPPuV0XEr853bM7PC/2VvmQPqXa03yBVA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731069506; a=rsa-sha256; cv=none; b=v1yQ8ZizzhuUtFn0J1Y2qZsg6uV0B87meQcw0kKm9HKv0y/C/YjFP1X85Iu88CJeKGsX+p xpzQipL01sk+q5z57q+fvDDJEtIBZBvjkMSrZCq7Pie1/jBFEvRt/aXn5szRct8q0DttFE WyvXEX5rrU0nBZUs0dKXKQs97qLOiu4U4Xp48Lvw4av/0QmO723HjM/CXJtPVtPi9EuNlI uPmTngkAGKJ3oLU0ZrT7B7B3Ww6tDMqIA9NAv1bmVQ3LLamPIrSl4+/1lkm0VnaCP9sQQn 5PWkK4M9vNylt5FgZlzTxNci5WTuDAZ90Ye7SiWEArWuz4vj2eUfQKQ7Oolc7g== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XlJQ96QJyzbJg; Fri, 8 Nov 2024 12:38:25 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 2102E44850; Fri, 08 Nov 2024 13:38:23 +0100 (CET) From: Kristof Provost To: Moin Rahman Cc: Igor Ostapenko , freebsd-testing@freebsd.org, freebsd-hackers , freebsd-ports@freebsd.org Subject: Re: Heads-up: Removal of devel/kyua port Date: Fri, 08 Nov 2024 13:38:17 +0100 X-Mailer: MailMate (1.14r5937) Message-ID: <55C8D0DB-D749-46F9-B006-95613B701D24@FreeBSD.org> In-Reply-To: References: <9e175f3c-4be0-437d-abf6-7f9d820154e7@FreeBSD.org> List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 7 Nov 2024, at 12:55, Moin Rahman wrote: >> On Nov 7, 2024, at 12:44, Igor Ostapenko wrote: >> Please, check this proposal: https://reviews.freebsd.org/D47473 > Based on what you have mentioned above I believe your DEPRECATED > message is too soft. :/ > > And I think we should handle it in a different way and mark it to > IGNORE for 14 or later also. > That seems reasonable to me. We can IGNORE it on anything other than 13.x= and when the 13 branch EOLs we can remove the port entirely. Best regards, Kristof