From nobody Wed Nov 6 11:08:09 2024 X-Original-To: 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 4Xk2WF6cJzz5cRYw for ; Wed, 06 Nov 2024 11:08:25 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (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 4Xk2WD4WqSz4hcT for ; Wed, 6 Nov 2024 11:08:24 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=LtKeHXEf; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::112b) smtp.mailfrom=tomek@cedro.info; dmarc=none Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-6e9ba45d67fso60985927b3.1 for ; Wed, 06 Nov 2024 03:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1730891303; x=1731496103; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=q9ITba+hBRNwVhVSLS3gLLkul3qOxlln0X0encRfW0s=; b=LtKeHXEf+aOOaWa371vqdsl2jF7vxM2tPU5v4AJeHpQTjQpMMGbowUDVMSiNuF52Ra 1Iqboedmhv+wGTbER8M/o0sPX17kjRYyM3sNYiH6RSApnMNEm6mte8Ywvx3fDSl95/eI a5K2w8KQlaJxmqHrj/ZDsMX2zGZmRG4LKFQKHpp04rq6dpzKOUfPXyA7bOq1hxU80VzX +QwaddZIe6Sw7dtnKFRhu0sk8EfZdMM+ifMCAB+HGYT1YzXqFb0Go+sgqiwik3LBEx/a MqPH7erwqv91ZRwPSibuVrQ8uLDn4gNSCAJUVBSPeGYdq7W1M23bSKkPf+2rxnUUwBQL 5mDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730891303; x=1731496103; 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=q9ITba+hBRNwVhVSLS3gLLkul3qOxlln0X0encRfW0s=; b=AjmeYEwJs+/JgWPY+Vt3zC+fNWXI0/Hw2kTOgCbn4+XclKQSc2xXUxz7EiR244B6lS 54yUMSwHlcWbJttGJXoG+sHFvEQKIRgE2DKGOYw/JXnO35ir6PraWFSzccdHAPiPWDl1 JQ51V2b6EZwYBDVZrK4hZil8rS/rEea2XCxwRJ/EGh9hs6VxBoSJxILFJtKnDHfjqKPe Qg92Q4K779nFGd+8nRa693IaTwNOPBJgsoChYxl1Ezw8edEBDnsvDnOpK+r1HidyP38y 4BdiReMrELdUAKtin5+rByFLQWndmD/EEC7Beu0vkLtsIfWAFKCYXACHg/TysgfVfeB0 q55Q== X-Gm-Message-State: AOJu0YxnIVCQ15udmSn21pLX+UUSxGK8jfhSV4ugL3M947c0HHy81z2f 21qrVAJL99Y1FODwFw9/G8X7HerThRFJXnu3MUeyRY21ZDKRVCR1ZELgbk7nVj6HCqtOUTBUCf8 = X-Google-Smtp-Source: AGHT+IHcpqgcVsBko8D+M5mYkN9MpbHDL7hRHOCI7RyI2CjZCzR0d4nrDXnWgGfirvbSNYDmnMu/2Q== X-Received: by 2002:a05:690c:9c10:b0:6ea:4e1f:2b40 with SMTP id 00721157ae682-6ea4e1f3d77mr246874207b3.9.1730891303584; Wed, 06 Nov 2024 03:08:23 -0800 (PST) Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com. [209.85.128.174]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6ea55ac979asm26818027b3.29.2024.11.06.03.08.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2024 03:08:22 -0800 (PST) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-6e3c3da5bcdso60158817b3.2 for ; Wed, 06 Nov 2024 03:08:21 -0800 (PST) X-Received: by 2002:a05:690c:102:b0:6e5:e163:e001 with SMTP id 00721157ae682-6ea3b87e250mr265865317b3.8.1730891300979; Wed, 06 Nov 2024 03:08:20 -0800 (PST) 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: <202410210954.49L9s9sD076618@critter.freebsd.dk> <203ADA8C-A4ED-4849-B89D-6D18664D67D0@webweaving.org> <202410221118.49MBIRSj009090@critter.freebsd.dk> <202410221847.49MIlXEs014246@critter.freebsd.dk> <202410221907.49MJ7BZl014476@critter.freebsd.dk> In-Reply-To: From: Tomek CEDRO Date: Wed, 6 Nov 2024 12:08:09 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: pyserial.tools.list_port improvement for FreeBSD To: Poul-Henning Kamp Cc: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[cedro.info]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112b:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[cedro.info:+] X-Rspamd-Queue-Id: 4Xk2WD4WqSz4hcT X-Spamd-Bar: --- Back to the topic hot :-) There is this esptool for flashing ESP32 chips over UART. `--port-filter` option was just added that can handle NAME and SERIAL parameters of the USB dongles. New feature is released in 4.9.dev1 for testing.. but it does not work on FreeBSD due current (3.5) pyserial misses those parameters. Here is the feature request for esptool: https://github.com/espressif/esptool/issues/1027 This is the output of pyserial-ports --verbose on Linux: (venv) =E2=9E=9C esptool_test_freebsd pyserial-ports --verbose /dev/ttyUSB0 desc: CP2102N USB to UART Bridge Controller hwid: USB VID:PID=3D10C4:EA60 SER=3D7c98d1065267ee11bcc4c8ab93cd958c LOCATION=3D3-6.1.7 /dev/ttyUSB1 desc: CP2102N USB to UART Bridge Controller hwid: USB VID:PID=3D10C4:EA60 SER=3D14fefc9fe665ee119c09926293cd958c LOCATION=3D3-6.1.5 This aligns well with Your patch PHK as tested before :-) (venv3.9embedded) python3 list_ports.py -v /dev/cuaU0 desc: ugen0.7 hwid: USB VID:PID=3D0483:374B SER=3D"0667FF504955857567182143" LOCATION= =3Dugen0.7 /dev/cuaU1 desc: ugen0.8 hwid: USB VID:PID=3D303A:1001 SER=3D"60:55:F9:CC:E2:B8" LOCATION=3Dugen= 0.8 /dev/cuaU2 desc: ugen0.9 hwid: USB VID:PID=3D10C4:EA60 SER=3D"1a2626680675eb11955981afb7be2ba5" LOCATION=3Dugen0.9 /dev/cuau0 desc: cuau0 hwid: cuau0 4 ports found Are those details propagated somewhere into pyserial core so other places can use them too (i.e. for use with esptool)? Did you consider replacing desc with name when possible? When do you plan to PR the upstream? :-) Thanks :-) Tomek --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Wed Nov 6 11:30:17 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Xk30m33yvz5cSVr; Wed, 06 Nov 2024 11:30:32 +0000 (UTC) (envelope-from elo.sh124@gmail.com) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xk30l5MlPz4m1Q; Wed, 6 Nov 2024 11:30:31 +0000 (UTC) (envelope-from elo.sh124@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jU6sK+GA; spf=pass (mx1.freebsd.org: domain of elo.sh124@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=elo.sh124@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a9eb68e0bd1so221437366b.3; Wed, 06 Nov 2024 03:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730892630; x=1731497430; darn=freebsd.org; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=PhF40Dg7IBMxlmDbVS61xeW5upW01c2Vk7PSdKAtMNE=; b=jU6sK+GAo7+YPRJfchX/VAINdWLP0zKzOP5HuBk6BPz4JudDfGgucOoSS/2v6jOsxa ZswxP4GmONCC2+o4HDLINX1PF1tMxzSsAetUSkKxQz+wNKBodt26A4bZ6TVdqTxzlXJ5 6k5Ukw8H19fQNZyJE4FamPHkNaAPU0B9pWGuEbvZGwku10yycEaze9uFNPXj4f9omHC8 kvG6oUhQNG3Ok3+5dTEyEbi6pYCdddO3znRgHtcC/iwB/65oMJ7OkeDJRDlNuzoS3dL7 hd6ZTQMGmhaaFL2um1VWU6xZedxnA27y3Z6N7aLBTLghOmUQAmiSKqOJTDzafnIY68Ki m7JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730892630; x=1731497430; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PhF40Dg7IBMxlmDbVS61xeW5upW01c2Vk7PSdKAtMNE=; b=k5zB4rGwN2nxK2FEfCEXkjVDj6rZZWUySMOx9XKUhmD7TFgWeUd2/84y1SIJXeP0+r 4OXQnLaHDKXLH5J1dqrMws3bpfhGCFubKWuZgLPJnmKnU9rb/I1Y0qY7hPEaOdu9CVWe UclSnYnj9mAhVl2echVEX4JTDIUTG3EqqDkR6hJnz6Er8atRGLKnCpKZP+uvbmrCVwuS xORNs+K4Kq708u5N+rTH88Y6JfNRJTX2CPd10mzoNGrqWuvHEQrbyTRCKyEOGSunjWle mL9iowkgnbEARiuh8LPz7ldnUH4AcsjGUdGGJnnd8qhJodwT7TQgL2zW7MrdT2q+b1HJ oZ4g== X-Gm-Message-State: AOJu0YyawCEOJWugqhKW7Eb7JhEPm1cmMP3SVOGMmIr3+JbRA0ZcgykP aKZZHVf5r/8Iu1D35UYSwELMWzo0RIaHuZ04BXKBnQqUH/mEOs48ZQxjrfBy X-Google-Smtp-Source: AGHT+IFFyVb3PQdJhe0KyxdPiv6fKaCI2NeASnft7h+IkwjGkavIIMzldd10Ma94AGMVfs6+fyxRbA== X-Received: by 2002:a17:906:c146:b0:a99:d6cf:a1df with SMTP id a640c23a62f3a-a9e655b958amr2028771566b.46.1730892630087; Wed, 06 Nov 2024 03:30:30 -0800 (PST) Received: from smtpclient.apple (wifinat-228.polito.it. [130.192.232.228]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9eb1817e32sm264547566b.197.2024.11.06.03.30.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2024 03:30:29 -0800 (PST) From: Leonardo Pio Francesco Gallina Content-Type: text/plain; charset=utf-8 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 \(3818.100.11.1.3\)) Subject: Seeking Guidance for FreeBSD Projects Message-Id: Date: Wed, 6 Nov 2024 12:30:17 +0100 Cc: freebsd-hackers@freebsd.org To: freebsd-embedded@freebsd.org X-Mailer: Apple Mail (2.3818.100.11.1.3) X-Spamd-Result: default: False [-3.21 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.72)[-0.716]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-embedded@freebsd.org,freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from] X-Rspamd-Queue-Id: 4Xk30l5MlPz4m1Q X-Spamd-Bar: --- Hi, I=E2=80=99m Leonardo Pio Francesco Gallina, a computer engineering = student at Politecnico di Torino, currently pursuing a master=E2=80=99s = in Embedded Systems. I plan to participate in Google Summer of Code with = FreeBSD to gain real-world project experience and make helpful = contributions to the project. At the moment, I=E2=80=99m familiar with C, MIPS, and ARM, and I=E2=80=99m= taking courses in Computer Architecture and Operating Systems for = Embedded Systems. I was thinking of starting by reading the FreeBSD = Handbook and writing some basic device drivers to gain practical = experience with FreeBSD=E2=80=99s codebase. I=E2=80=99d appreciate any guidance on beginner-friendly projects or = areas within FreeBSD that could help me get ready for a GSoC = application. Thanks in advance, Leonardo= From nobody Wed Nov 6 12:40:05 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 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: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird 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-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 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: 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.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-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 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: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird 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 19:13:56 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XkFHk37W8z1GsDq for ; Wed, 06 Nov 2024 19:14:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 4XkFHj6yGWz4qvH for ; Wed, 6 Nov 2024 19:14:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-71e70c32cd7so69172b3a.1 for ; Wed, 06 Nov 2024 11:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1730920448; x=1731525248; 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=0XeIsOR7XRv+VQcfyMPu8fiytSLRX4SDzRDxiwEKbVA=; b=rgXDq06lkVm3SFIMgvxerRkV+WUMtQwSN4rYRm/Aa7YeXqPRKWXI4mQKVyk67Sn/is sMwb9qHSrjNOXCujwY3d2E3xfsWsjQ2vnt//hhiQfBTdt9HqYUUkiC/gzmawm2EewkS4 AKtjvb7IfSRBz2fVRRkLVCTSroCmXQiPhuIVlDNTJ9utjN/kwR+JFg+AyEb7YTqY8kMy W7bRUF3APDt8braC+M3DUeP4RvSTazGLMg+Q6b7Qh1rTgaGX7L7ecw7PdpTESpV7E1xr 3N83h4YZNHk47ode37VlXMbGJq8zNOQJf8HfZZ3u5e+LMjJ4jtbUYx1fXru/Jr7DG7vf Kr0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730920448; x=1731525248; 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=0XeIsOR7XRv+VQcfyMPu8fiytSLRX4SDzRDxiwEKbVA=; b=pMXTZZuRnhK7xnntaG69fJl4EUk0Dt0X1X5b9iDiLfU++Ic5G8yb69dkE87wa5YeXM HsTCjwgo3Cn1cT8H6mNEF8fCwqagpd1IjeruJwj93xMuOeitjBPXRJnYYixt/ig/sQ3N AHawSL8oT/gnC245ltRL8aNOD9b+kEcjK1RmeKO7LXbZ5PB3V0Jrw6xirHItciKHcqYa a3emC58y0qZ2M4siIBzHI6omFmECjyzfxpT6pGkNhzfNilFchkL8iCWZBMHCnXsB8ZNw pBSJafibfCEqQS3BL5dFXi7idslx9s3VEPTaQRpCDwX2FbfwxF+7ZaJuGiW9C9O/AZCj /ULw== X-Forwarded-Encrypted: i=1; AJvYcCUm/dW/ikBcnZJvChj6XkArlGCD0JfPwlezH7+MBVc/dOjEfX5JClr4Onl34wrgJmwywaK3f6tELKnASyILtMU=@freebsd.org X-Gm-Message-State: AOJu0YyM9dtghVNsFfqaOOFfnGJDJiQ1ab2eX+c8+dXpx6ebT7qmOeg0 g6R5Pvr9oTQZl3IOS05zijYQjjEvyYuXSwk97K1Y3AywGg5bZOdnXlmMnfOP6d1lnz7udYgFZxE todFf0jt4PEkNaoDR6H0An8pdUrbPL4Vse6EziV2xFcSV+lBu X-Google-Smtp-Source: AGHT+IHjpIN7ou2saGQeD71leIKg/s0T7kFKanct29jW76yNXNphKsn1gbjsoPnMbMBhrOkwqAbsTNnZ04LDa6e3Mi0= X-Received: by 2002:a05:6a00:a13:b0:71e:768b:700a with SMTP id d2e1a72fcca58-720630921b6mr59456362b3a.23.1730920447926; Wed, 06 Nov 2024 11:14:07 -0800 (PST) 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: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> In-Reply-To: <9fc6fc72-4c2c-4b09-bdb5-122a49b45295@FreeBSD.org> From: Warner Losh Date: Wed, 6 Nov 2024 12:13:56 -0700 Message-ID: Subject: Re: RFC: Add required_klds metadata to Kyua To: Igor Ostapenko Cc: "freebsd-testing@freebsd.org" , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000006efd590626435211" 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: 4XkFHj6yGWz4qvH X-Spamd-Bar: ---- --0000000000006efd590626435211 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2024, 10:12=E2=80=AFAM Igor Ostapenko wr= ote: > Hi FreeBSD developers, > > During Kyua's execenv=3Djail feature implementation there were discussion= s 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=3D"testbinary1", required_klds=3D"pf pflog"} > > - Get it listed per test case: > > > kyua list -v testbinary1 | grep required_klds > required_klds =3D 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 metadat= a > 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 suc= h > 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 singl= e > kldload for all missing modules, but that's another story which is covere= d > 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 th= e > main Kyua repo in the world today > > c) required_kmods -- a little improvement of the previous option to ma= ke > 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 > Love this. Would go with a FreeBSD name, though, because no two oses have the same module names. Don't care a huge amount. Would also like an option to never load kld so qemu testing can be a lot faster... Warner > 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 curren= t > dir, and later we can think of "-k" option like "kyua test" command ha= s. > > > 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 singl= e > 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=3D"klds pkgs" test > > # with configuration: > > echo 'rr =3D "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 > > --0000000000006efd590626435211 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 6, 2024, 10:12=E2=80=AFAM Igor Ostapenko &= lt;igoro@freebsd.org> wrote:
Hi FreeBSD developers,

During Kyua's execenv=3Djail feature implementation there were discussi= ons 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 "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.

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 followin= g
interface is expected:

- Define it on ATF level, e.g. for atf-sh:

=C2=A0 =C2=A0 =C2=A0atf_set require.klds pf pflog

- Define it on Kyuafile level:

=C2=A0 =C2=A0 =C2=A0test_program{name=3D"testbinary1", required_k= lds=3D"pf pflog"}

- Get it listed per test case:

=C2=A0 =C2=A0 =C2=A0> kyua list -v testbinary1 | grep required_klds
=C2=A0 =C2=A0 =C2=A0required_klds =3D 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_file= s
ones -- if some of the required modules are not loaded Kyua will skip such<= br> 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 t= o
our tests typically do kldstat sequentially with "skip fast" logi= c. Skipping
reason information still is not aggregated to make it easy to run a single<= br> kldload for all missing modules, but that's another story which is cove= red
by the following Project B.

Q1: I have doubts regarding the name of this new metadata. There are severa= l
other options in my mind, it would be appreciated to hear opinions regardin= g
this:
=C2=A0 =C2=A0a) required_klds -- the original idea based on the vibe that F= reeBSD Kyua
=C2=A0 =C2=A0 =C2=A0 fork is mainly for FreeBSD

=C2=A0 =C2=A0b) required_mods -- to keep it OS agnostic while Kyua still is= treated
=C2=A0 =C2=A0 =C2=A0 as an OS agnostic tool, and freebsd/kyua GitHub repo a= ctually is the
=C2=A0 =C2=A0 =C2=A0 main Kyua repo in the world today

=C2=A0 =C2=A0c) required_kmods -- a little improvement of the previous opti= on to make
=C2=A0 =C2=A0 =C2=A0 sure it talks about "kernel modules" and lea= ve space for other meanings
=C2=A0 =C2=A0 =C2=A0 in the future, just in case

=C2=A0 =C2=A0d) required_klds | required_kmods -- to have some official ali= ases
=C2=A0 =C2=A0 =C2=A0 supported, but it's expected to bring confusion in= stead

=C2=A0 =C2=A0e) your variant
=
Love this. Would go with a FreeBSD name, though= , because no two oses have the same module names. Don't care a huge amo= unt.

Would also like an = option to never load kld so qemu testing can be a lot faster...

Warner

<= /div>


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.

=C2=A0From the implementation perspective, Kyua is expected to have a gener= ic
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 t= hen 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 additi= ons 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):
=C2=A0 =C2=A0 =C2=A0> kyua rr list

- Run all resolvers or only specified ones. It would deal with the current<= br> =C2=A0 =C2=A0dir, and later we can think of "-k" option like &quo= t;kyua test" command has.

=C2=A0 =C2=A0 =C2=A0> 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
=C2=A0 =C2=A0additions, e.g. dry-run or verify command without actual resol= ving.

Having this interface the FreeBSD CI could have a separate step to run &quo= t;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<= br> command for both. The following interface addition could be there:

- Run all or specified requirement resolvers before the actual testing:

=C2=A0 =C2=A0 =C2=A0> kyua test --rr ["resolver1-name resolver2-nam= e ..."]

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:

=C2=A0 =C2=A0 =C2=A0# without configuration:
=C2=A0 =C2=A0 =C2=A0> kyua -v rr=3D"klds pkgs" test

=C2=A0 =C2=A0 =C2=A0# with configuration:
=C2=A0 =C2=A0 =C2=A0> echo 'rr =3D "klds pkgs"' >&g= t; /etc/kyua/kyua.conf
=C2=A0 =C2=A0 =C2=A0> kyua test=C2=A0 # 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 i= t 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

--0000000000006efd590626435211-- From nobody Wed Nov 6 20:13:39 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 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: 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: <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-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 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: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_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-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 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: 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: <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-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 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: 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: 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 05:04:41 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XkVP86tcTz5cMcL for ; Thu, 07 Nov 2024 05:04:44 +0000 (UTC) (envelope-from kevans@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 4XkVP85xzLz53rR for ; Thu, 7 Nov 2024 05:04:44 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730955884; 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=GP8A2+j71HP9dItLdtA6ba7iDiRfUyLokPu4QJUFnf4=; b=pPaz+xoVeUBTSjd2kX3+6tcaIrvuYQGyRSkt0AGt0yrk75OHDgYigzFyBR3SYFQ8p3F1Jr /D3nUOveKGGPNYkz23Qq4btp+k98lfT6IIuf/hBIXBFK1waG4RiBFYueDxJA6/ErHOzHXN TMJdwjUgkMXCtm6HkVTBORp14onwFa3Z7CJqZVz74Lz/oaWvJMX8UXzWtXGd9fRO5jMppb EGvpTFoQS0B0ZNTlHji/lxKmqCCxlaXm1xLy2WKaZkwTpVKyUxCOA3zMvsyryVC60xL5Wk LDzbN7IpnoGpUOGBF9uZLhqKRYhO+FCPE8fWRleJ8TEsmyTmDFvM9JY27ig2Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730955884; 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=GP8A2+j71HP9dItLdtA6ba7iDiRfUyLokPu4QJUFnf4=; b=p/fF+nSIKaxjr324y+nNqQxx1V7trumoGzN6Y92lJEvn9KeBFftTJ9DRHu7cXTskIZnNoT iL8hFNNMTt4LaDd2YDyc/xOaLGBVHJ7Mob3e+snlcXHag82T5WZMBPnaAdgS8sB87y7Evf 6zzQZ4BHOqi/kJWsIs8P1WWiKPnSA8eUiPcKT/0dJ3J0fTSaMh78VvrMkP+e70DMbk6oBF oyBqnRrqKC0IWBASoclSNlHXrv4lLvaJIoyYnCCGr9Iphum9Dep+aRO4p1yw/PztxQQmYz 8xS1cboQvpN52Ro/DJiJeU2ZHTR/8TbwmFqZPPdJgxuq7ZiyYEUN2hlKNYAMsg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730955884; a=rsa-sha256; cv=none; b=rrcyx3jPNqBer7res9ir7AxDhHG4BzzFEFFeC9nn/Rv7CDtFRvaOU6X4tpCc55Rx0AUlZM iSuQNLAsE420TgVwhD0x022Nb+LqCmOvkmezuOmP75o5sKXr/C08FX4VIgxMxKU1dHQcis orrZg31uaIbYcjpkoJttugfut0+bJKGOTl9fzrfXonIodunjKdQvnjv+ieKjyC5YFw0cRe 65EHywFQxFWKNIdCyMP5z5fe9IWA8TqBOdllQrrdXAhyiKn4QaCw78d06iYyYQnZIuVb2I fhxfhy8dwZDSB23pgOgSVdN4K4fs2jF23F0RaLQYyRmpr3VOekz0IImr3AEbQA== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkVP83g1nz1CdN for ; Thu, 7 Nov 2024 05:04:44 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <6356e02c-5e57-4f5f-97b7-7c1252a06d0d@FreeBSD.org> Date: Wed, 6 Nov 2024 23:04:41 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "freebsd-hackers@FreeBSD.org" From: Kyle Evans Subject: Korean Character Widths Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Anyone here up to snuff on their Korean and willing to review some character width adjustments in our localedata? https://reviews.freebsd.org/D47472 adds a number of zero-width exceptions for characters that are reportedly expected to be treated as combining characters (Hangul Jamo medial vowels and final consonants in the U+1160 - U+11FF range. A sanity check on this would be quite welcome; they had referred me to a wcwidth implementation by Markus Kuhn as a point of reference: https://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c Thanks, Kyle Evans From nobody Thu Nov 7 11:44:11 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 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: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: 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-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 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: 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.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-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 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: 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: <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:34:30 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XkmMp6Q5nz5c13p; Thu, 07 Nov 2024 15:34:30 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkmMp64ZFz41v8; Thu, 7 Nov 2024 15:34:30 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730993670; 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; bh=W41+ABVanZQDmGPHTklXSUH1KDiO99Zjs0mv+16I6js=; b=FWRM3OpK4XR3pHi9jE9ZYE6blEPD0hHgRWQZjtX+ubGaU0jLOD07VnE2E/tiKtCsv0ucJq 8gTJlHQBhC2wqCZgcZvAFYJESg5fNl29uI1TzI3gmXKMHyD3SlJjAA37kb9v77Bjs5h1i8 Y3LCUZNjTHqCcw50jhD4BXBe1zs2ALtCAdt7gDBGW0M5wr91IZ9CqmQigH142zjCrpX7cO XTZxy2DLnl3UTfwaySXetS//emM5cKs4NTip+fiQ/HW3xRyxAZQ88gyxZ2hyQFL4Atd+68 9O9ewoqJkU2lMVRcXQz9PqxglWDIJdDPV7gT62Oan1EXi0ZTpSsPN1SwDhKWOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730993670; 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; bh=W41+ABVanZQDmGPHTklXSUH1KDiO99Zjs0mv+16I6js=; b=SV5g6ZfPORctNvJE7HD+8r5JQ/n9pWkwkk+QvooNLnVLa+UUwmQOXCYo4WJ3X//pXd7H57 0cDRHFlO3P7ys0MTFIltDyOdqys/ifAXzQyJyHRarIfi16s8R0n42BaiUYLCOC+FJnKwlA +TAxZKtbLaR+FOh2t74o4RCwqk4WC4IUdefIEwdavgGNNQjSoKPMVGbKXIdHMtLime8fbJ 0N7YwIGtNx8pitt0vyzq7kGuTZDte6mgtTR+lV48/OnC9nxyAQzy82iuD0skrDkUQMLuB8 OyH9cCiQl/2gOTYgYsgHpA5wMr2wUGch/DFTPuPHXdPJB3ciLGLVEBD8E9f23g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730993670; a=rsa-sha256; cv=none; b=Wvgbu56wk1kQio9/NBDbeKF8xvJgcntCCN/0H8monCfVOJm1aeBM6evCKUpK7npGhnF6xw Tzkq4opPW6Gbj8kbyfP91p50aPd1wmiMdFUBMcDmGT+xpO/+/0SMjXD9UqVM6b1Pqt/lDj veV0j6T+Srs0jsHwx/hKqUwByjnVy38EmBawoHNqpJPEgDvnN7ZpUteISGffDYBqBsyN1r NfTVWInwrBIJwOiIJsJLKuc9HZZCxMWhVLwnIOyP+J2Op4qz4JRAFggPaTfNzBnNAtHOii qwPDyL1WvGPc65Z0EPVcIyYgAIdmejH/wpcIHzPgmL/4t+C6M1ALaoF+L97GkQ== Received: by freefall.freebsd.org (Postfix, from userid 1472) id C529C77AE; Thu, 07 Nov 2024 15:34:30 +0000 (UTC) Date: Thu, 7 Nov 2024 15:34:30 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - Third Quarter 2024 Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline; filename="report.txt" Content-Transfer-Encoding: 8bit FreeBSD Status Report Third Quarter 2024 Here is the third 2024 status report, with 32 entries. Unfortunately we are late this quarter, just like last quarter. As our readers know, many FreeBSD contributors are volunteers, so it is natural that less important deadlines like the status reports ones are not always met. Indeed, if you are not a FreeBSD contributor yet, please consider joining us: you could help lighten someone’s burden while learning new skills, working side by side with developers all over the world. Have a nice read. Lorenzo Salvadore, on behalf of the Status Team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2024-07-2024-09/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Continuous Integration □ Ports Collection □ Bugmeister Team □ FreeBSD Samba Team • Projects □ Audio Stack Improvements □ A bhyve management GUI written in Freepascal/Lazarus □ Changes to dhclient to speed up the FreeBSD boot process □ Capsicum and Bhyve Code Audit □ Endpoint-Independent NAT □ Kyua Jail Support □ Linux Source Compatibility Wiki page • Userland □ Service jails — Automatic jailing of rc.d services □ Userspace UFS Driver (fuse-ufs) • Kernel □ FreeBSD V4L2 & kernel USB Video Class driver □ mac_do(4), setcred(2), mdo(1) □ Scheduling Priorities: 256-queue Runqueues Sub-Project □ Wireless Update □ VirtIO Sockets and AF_VSOCK support • Architectures □ Pinephone Pro Support □ SIMD enhancements for aarch64 • Cloud □ FreeBSD on Microsoft HyperV and Azure □ FreeBSD on EC2 □ OpenStack on FreeBSD • Documentation □ Documentation Engineering Team □ FreeBSD Wiki □ The FreeBSD Russian Documentation Project • Ports □ GCC on FreeBSD □ Freepascal and Lazarus on FreeBSD aarch64 • Third Party Projects □ Containers and FreeBSD: Pot, Potluck and Potman ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Core welcomes René Ladan (rene@) as their new secretary. Liaisons Core selected new liaisons for the various teams among themselves: • bugmeister: glebius • ci: olivier • clusteradm: mat • doceng: lwhsu • foundation: hrs • portmgr: tcberner • re: dch • secteam: allanjude • srcmgr: glebius DevSummit 202409 • The Core Team was almost fully present at EuroBSDCon 2024 in Dublin. The following people were present: allanjude, dch, glebius, hrs, lwhsu, mat, olivier, rene • Slides are available at https://wiki.freebsd.org/DevSummit/202409 • Core met with the FreeBSD Foundation to have their periodic meeting and take the change to do it in face-to-face. Topics included improving alignment and communications between the two groups and the community. New support timeline for FreeBSD releases • Core approves the proposal by re@ to reduce the support timeline for FreeBSD releases from five to four years, after which the release is supported on a best-effort basis. This proposal is also backed by portmgr and secteam. srcmgr • Core helped in forming a new srcmgr team. Their charter is not fully set in stone yet, it can be adjusted if needed in 6-12 months from now. • Nominations for new src commit bits should from now on be sent to srcmgr@ instead of core@ • A lurker program is suggested to keep an influx of new members. • Core announced srcmgr during DevSummit 202409 and sent a follow-up to developers@ on September 29. Commit bits • Core welcomes Igor Ostapenko (igoro) as a new src committer. • Core extended the text that the grim reaper script sends to include ways on how to get commit bits of developers re-activated. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://freebsdfoundation.org/ Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://freebsdfoundation.org/journal/ Foundation Events URL: https://freebsdfoundation.org/our-work/events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and worldwide community, and helping to advance the state of FreeBSD. We do this in both technical and non-technical ways. We are 100% supported by donations from individuals and corporations and those investments help us fund the: • Software development projects to implement features and functionality in FreeBSD • Sponsor and organize conferences and developer summits to provide collaborative opportunities and promote FreeBSD • Purchase and support of hardware to improve and maintain FreeBSD infrastructure • Resources to improve security, quality assurance, and continuous integration efforts • Materials and staff needed to promote, educate, and advocate for FreeBSD • Collaboration between commercial vendors and FreeBSD developers • Representation of the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity Even though the summer months tend to be slower, we accomplished a lot of work and you will see that in our Q3 report! Some highlights include raising over $135,000 from individual donors, and kicking off two major projects. First, thanks to a large investment from the Sovereign Tech Fund, we will be doing even more to improve our infrastructure. Second, thanks to a large investment by Quantum Leap Research and the Foundation, we will be working to accelerate a FreeBSD on Modern Laptops project. We also continued work on the Alpha-Omega funded project, hired a userland software developer, and opened a job position for a solutions specialist. As you will see below, spreading the word about FreeBSD through advocacy and community is still an important part of our mission. Over the summer, we sponsored EuroBSDCon, and the upcoming FreeBSD and OpenZFS Summits, and provided travel grants to around eight FreeBSD contributors to attend EuroBSDCon. Our advocacy team was busy producing content that promotes the benefits and strengths of FreeBSD, why companies are using FreeBSD, and why you should use FreeBSD if you care about security. We also promoted work within the Project and Foundation on social media. During EuroBSDCon, Foundation and Core Team members met to discuss Core’s questions as they navigate what they want to accomplish during their term. We identified 2 key areas to work on in the near term: 1. Financial reporting transparency - Break out operating system improvements spending in our quarterly reports. We are working with our accountant so that starting in 2025, we can report how much we are spending on certain projects and key areas, like laptop, enterprise, security…​ In the meantime, we will add notes to our financial reports that document which projects are included in the OS Improvement expense category. We are aware that we have not posted financials this year. Our accounting team is introducing us to improved reporting, while integrating our books into a new accounting system. 2. The projects we are funding are not mentioned on the Project’s website. We document these on our website, because we want to show our donors where their financial contributions are being spent. We recognize that we need to also add documentation about these projects on FreeBSD.org, so we will investigate how to better connect our software development work with the Project. We are funding a lot of software development work to advance, improve, and keep FreeBSD secure. We received funding for some of this work, but most of it is being funded by your donations and our investments. Our purpose is to focus on the long-term sustainability of FreeBSD. To do this, we need more companies stepping in to help fund our efforts. Our investments will only carry on this work for a year or two at most. If your company relies on FreeBSD, please consider giving a financial contribution so we can ensure it stays the secure, reliable, and innovative platform you depend on. Not sure how to go about asking? Please reach out. We can help you navigate the process. Please go here to make a donation: https://freebsdfoundation.org/donate/. To find out more about our Partnership Program, go here: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/. OS Improvements During the third quarter of 2024, 263 src, 37 ports, and 11 doc tree commits identified The FreeBSD Foundation as a sponsor. Several members of the FreeBSD Foundation’s development team attended the FreeBSD Developer Summit in Dublin, Ireland prior to EuroBSDCon 2024. You can watch a video of the Hello From the Foundation talk to open the Summit, when: • Deb Goodkin introduced the FreeBSD Foundation • Joe Mingrone introduced members of the development team and said a few words about FreeBSD’s 2024 Google Summer Code campaign • Ed Maste described some of the current or recently completed Foundation development projects. Alice Sowerby, who recently began supporting the Foundation in Technical Program Management role, gave a talk to introduce the CHAOSS (Community Health Analytics for Open Source Software) project and how to start collecting and working with community health metrics. The Foundation, along with new funding and investment partners, is currently supporting four major projects. • The first, partially funded by Alpha-Omega, is to improve FreeBSD security. As part of this effort, the Foundation enlisted Synacktiv to run a code audit on two significant subsystems: bhyve and Capsicum. For details, refer to the dedicated Capsicum and Bhyve Code Audit report entry. • The second project, jointly funded by AMD and the Foundation, is to develop an AMD IOMMU driver for FreeBSD. The impetus for the project was to better support large core AMD systems. However, the driver will be useful in different scenarios when interrupt remapping is required. The work is nearing completion, and developer Konstantin Belousov is testing the driver on some of AMD’s large-core-count systems before committing. • The third project, backed by an investment from the Sovereign Tech Fund, is to improve FreeBSD through five key sub-projects: □ Zero Trust Builds: Enhance tooling and processes □ CI/CD Automation: Streamline software delivery and operations □ Reduce Technical Debt: Implement tools and processes to keep technical debt low □ Security Controls: Modernize and extend security artifacts, including the FreeBSD Ports and Package Collection, to assist with regulatory compliance □ SBOM Improvements: Enhance and implement new tooling and processes for FreeBSD SBOM To reduce technical debt, we have partnered with Bitergia to analyze and assess our open Bugzilla bugs. By implementing improved issue management processes and establishing open-source tooling for the long term, our goal is to achieve and sustain a manageable bug backlog. The remaining four sub-projects will begin in 2025. • The fourth project, which will be funded by both the Foundation and Quantum Leap Research, is to improve FreeBSD laptop usability. We have begun (or will soon start) supporting developers working in the following areas: □ Enhanced wireless chipset support: Expanding chipset compatibility to ensure reliable wireless connectivity and support for newer wireless standards. □ Power management: Implementing modern power-saving states (such as s2idle and s0ix) to improve battery life and energy efficiency. □ Graphics enhancements: Improving support for Intel and AMD graphics by integrating the latest DRM drivers. □ Audio improvements: Enhancing audio routing, headphone switching, and digital microphone (DMIC) functionality for a more user-friendly multimedia experience. □ Laptop-specific hardware features: Addressing specialty buttons, touchpad gestures, and other unique hardware components found in modern laptops. FreeBSD completed our 20th consecutive year participating in Google Summer of Code. The 11 projects for this summer are now complete; nine passed. The Foundation has been providing project management support for the FreeBSD Open Container Initiative (OCI) Working Group, with Alice Sowerby hosting the bi-weekly meeting, and running the recent Podman on FreeBSD testing project. The OCI develops open industry standards for cloud native container formats and runtimes, ensuring platform consistency. The FreeBSD OCI Working Group is defining these standards for FreeBSD, with implementations using jails and potentially lightweight VMs with bhyve. Refer to the Foundation’s OCI Container Support Project page for details. In other Foundation news: • Isaac Freund joined the Foundation’s development team as a Userland Developer. As the lead developer of the River Wayland Compositor and a member of the Core Zig Team, we are excited about the experience Isaac will be bringing to FreeBSD. • Alfonso Sabato Siciliano is working on a Vision Accessibility Subsystem for blind, low-vision, and color blind users. New features will include a Braille refreshable display framework, a communication channel for the virtual terminal console, a speech synthesizer, high-contrast TUI utilities, and an accessibility book to document assistive technologies available on FreeBSD. • Tom Jones, completed his work with RGNets to port the Vector Packet Processor (VPP), a layer 2-4 multi-platform network stack in userspace, to FreeBSD. You can read about Tom’s next project to support full-cone NAT for FreeBSD firewalls in his Endpoint-Independent NAT report entry. • Christos Margiolis continued to improve FreeBSD’s audio stack and provide audio developers with useful tools and frameworks to facilitate sound development on FreeBSD. Refer to the Audio Stack Improvements entry for the latest news. • Olivier Certner has two entries in this report. You can read about his latest work in the Scheduling Priorities: 256-queue Runqueues Sub-Project and mac_do(4), setcred(2), mdo(1) report entries. • Bjoern Zeeb continued to improve wireless networking on FreeBSD. You can read the latest news in Bjoern’s Wireless Update entry. • Philip Paeps continued work on a contract to modernize the FreeBSD cluster. • Chih-Hsin Chang has continued work to port OpenStack components so that the cloud computing platform can be run on FreeBSD hosts. Refer to the OpenStack on FreeBSD entry for the latest information. • Other members of the Foundation’s technology team contributed to FreeBSD development efforts. For example: □ Mitchell Horne committed work for RISC-V, including adding support for the Supervisor-mode: Page-Based Memory Types (Svpbmt) extension □ Ed Maste removed the deprecated mergemaster tool in favor of etcupdate (8) for updating files not managed by install world □ Joe Mingrone updated our base libpcap and tcpdump(1) □ Li-Wen Hsu kept our Jenkins port tracking the latest upstream versions with a number of port updates. Continuous Integration and Workflow Improvement As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure. Advocacy During the third quarter of 2024, we continued growing our efforts to drive awareness, advocate for the project, highlight users, and bring educational content to the FreeBSD community. Below are some of those efforts. • Presented at the EuroBSDcon 2024 FreeBSD Developer Summit. Slides and the Live stream are now available. • Attended and exhibited at EuroBSDCon 2024. The Foundation was again a Silver Sponsor. • Finalized our Bronze Sponsorship of the OpenZFS User and Developer Summit • Began planning the Fall 2024 FreeBSD Summit taking place November 7-8, 2024 in San Jose, CA. The program is now available and registration is open. • Updated the community on the new release schedule: Navigating FreeBSD’s New Quarterly and Biennial Release Schedule • Announced: New CIS® FreeBSD 14 Benchmark: Secure Your Systems with Expert-Guided Best Practices • Shared more information about the Sovereign Tech Fund’s investment in the Foundation: Sovereign Tech Fund to Invest €686,400 in FreeBSD Infrastructure Modernization • Announced the joint investment by Quantum Leap Research and FreeBSD Foundation to Improve Laptop Support and Usability and more on why we are making this investment. • Published additional blogs including: □ FreeBSD Ports and Packages: What you need to know □ Why You Should Use FreeBSD □ Enhancing Memory Safety in Programming: Insights from the FreeBSD Vendor Summit □ FreeBSD as a Platform for Your Future Technology □ Celebrating FreeBSD: Insights from Deb Goodkin • Participated in the following contributed articles, interviews and podcasts: □ Get to Know: Deb Goodkin, Executive Director, FreeBSD Foundation □ All Things Open Blog: Unlocking the Potential of FreeBSD □ Why Open Source Can Be the Perfect Place for New Developers – and How to Get Started, with Deb Goodkin from the FreeBSD Foundation □ Steady in a shifting Open Source world: FreeBSD’s enduring stability □ Apple’s Open Source Roots: The BSD Heritage Behind macOS and iOS • Published the July 2024, August 2024, and September 2024 FreeBSD Foundation Updates. • Released the May/June 2024 and July/August 2024 issues of the FreeBSD Journal with HTML versions of the articles. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 13.4-RELEASE announcement URL: https://www.freebsd.org/releases/13.4R/announce/ FreeBSD 14.2-RELEASE schedule URL: https://www.freebsd.org/releases/14.2R/schedule/ FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The Team managed 13.4-RELEASE, leading to the final RELEASE build and announcement in September. Planning has started for the upcoming 14.2-RELEASE cycle. The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI Tinderbox view URL: https://tinderbox.freebsd.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI 3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&email1=testing%40FreeBSD.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet In the fourth quarter of 2024, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD. Important completed tasks: • Update main and stable/14 build environment to 14.1-RELEASE Work in progress tasks: • Improving the src/tests/ci work to support running test suites • Merging Pre-commit CI with CIRRUS-CI • Designing and implementing pre-commit CI building and testing and pull/ merge-request based system (to support the workflow working group) • Proof of concept system is in progress. • Designing and implementing use of CI cluster to build release artifacts as release engineering does, starting with snapshot builds • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Redesigning the hardware test lab and adding more hardware for testing Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Tobias C. Berner Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. According to INDEX, there are currently 36,504 ports in the Ports Collection. There are currently ~3,379 open ports PRs. The last quarter saw 11,594 commits by 154 committers on the main branch and 832 commits by 78 committers on the 2024Q3 branch. Compared to last quarter, this means a slight increase in the number of commits on the main branch (from 10,525) and about half of the backports to the quarterly branch (compared to 1,771). The number of ports also increased (up from 32,471). The most active committers to main were: • 5133 sunpoet@FreeBSD.org • 1262 yuri@FreeBSD.org • 375 jbeich@FreeBSD.org • 357 vvd@FreeBSD.org • 331 bofh@FreeBSD.org • 192 uzsolt@FreeBSD.org • 185 eduardo@FreeBSD.org • 172 diizzy@FreeBSD.org • 148 mfechner@FreeBSD.org • 131 arrowd@FreeBSD.org A lot has happened in the ports tree in the last three quarter, an excerpt of the major software upgrades are: • Default version of PostgreSQL switched to 16 • chromium updated from 126.0.6478.126 to 129.0.6668.100 • firefox updated from 127.0.2 to 131.0-rc1 • firefox-esr updated from 115.9.1 to 128.3.0-rc1 • rust updated from 1.79.0 to 1.81.0 • sdl2 updated from 2.30.3 to 2.30.7 • wlroots updated from 0.17.4 to 0.18.1 • wine-devel updated from 9.4 to 9.16 • qt5 updated from 5.15.14 to 5.15.15 • qt6 updated from 6.7.2 to 6.7.3 • plasma6 updated from 6.1.1 to 6.1.2 During the last quarter, pkgmgr@ ran 24 exp-runs to test various ports upgrades, updates to default versions of ports, and base system changes. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Bugmeister Team Links: FreeBSD Bugzilla URL: https://wiki.freebsd.org/Bugzilla Contact: Bugmeister Charts and graphs Ed Maste from the FreeBSD Foundation has expressed an interest in seeing useful charts and graphs added to Bugzilla. The few that we have now are not very informative. Many of the interesting Bugzilla queries for them have been documented, but the information there is really dense. If you are interested in working on this task, contact Ed directly. Bugzilla version upgrade Recently, upstream Bugzilla has released 5.0.4.1, which is a minor bugfix release. Preliminary work suggests that the update will be unobtrusive. Work is continuing. PR statistics PRs continue to come in and get triaged. Over the longer term, we are nearly at steady-state. The number of PRs over the past quarter (and year) has fluctuated. Vladimir Druzenko pointed out that the number dropped by around 200 during 2023Q4. (We have not done the data analysis to find out why that was.) However, slowly, the number has come back to where it was a year ago. But we do seem to be closing incoming PRs more quickly these days. For reference: https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html&days=365 The overall number of PRs remains at slightly over 11,600. We do have a lot of technical debt. Bugmeister is also working towards restarting the Bugathons. Acknowledgements Bugmeister would like to thank a number of people who have assisted with bugbusting, including new triagers Alexander Vereeken, Alexander Ziaee, and Frederick Lee. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Samba Team Links: FreeBSD Samba Team Wiki URL: https://wiki.freebsd.org/Samba Samba Homepage URL: https://www.samba.org/ Contact: FreeBSD Samba Team Samba provides secure, stable and fast file and print services for all clients using the SMB/CIFS protocol. It is an important component to seamlessly integrate FreeBSD/Linux/Unix Servers and Desktops into Active Directory environments. It can function both as a domain controller or as a regular domain member. The new FreeBSD Samba Team was created to better coordinate maintenance efforts of the Samba ports and its dependencies, in particular: • databases/ldb22 • databases/ldb25 • databases/ldb28 • databases/tdb • devel/talloc • devel/tevent • net/samba416 • net/samba419 Notable changes in the last quarter include: • Creation of the FreeBSD Samba Team by Timur Bakeyev, Xavier Beaudouin, Yasuhiro Kimura, Mateusz Piotrowski, and Mikaël Urankar. • Added SAMBA_LDB_PORT to Mk/Uses/samba.mk (sponsored by Klara, Inc.) • Switching net/samba419 to use external dependencies by default instead of vendoring (sponsored by Klara, Inc.) • Updating net/samba419 to 4.19.8 Currently, the FreeBSD Samba team is coordinating efforts in the following areas: • Switching the default version of Samba from 4.16 to 4.19 (Bugzilla PR# 280769). • Current blockers are: • Broken fruit:posix_rename = yes (Bugzilla PR#281360) • Broken replication in Samba 4.19.8_1 (Bugzilla PR#281672) • Adding Samba 4.20 to the ports tree (Bugzilla PR#280533) • Adding Samba 4.21 to the ports tree (Bugzilla PR#281262) Testing and community contributions are welcome, please reach out on Bugzilla or via the team email. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Audio Stack Improvements Contact: Christos Margiolis The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, since it has been left largely unmaintained, and, although high in quality, there is still room for improvement — from lack of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to touch on all those areas, and as such, is more of a general improvement project, than an implementation of a specific feature. Important work since last report: • Several sound(4) fixes. • Wrote mixer(8) and sound(4) tests. • mixer(8): Implement hot-swapping • audio(8): Initial revision • sound: Implement dummy driver • Improved and added sound examples. • mididump(1): Initial revision • virtual_oss patches. • Gave a talk at the 09/2024 DevSummit in Dublin, Ireland. Future work includes: • More bug fixes and improvements. • Finalize and commit of audio(8) and mididump(1). • Implement a generic MIDI layer, similar to pcm/, and improve/modernize the MIDI codebase in general. • Implement a bluetooth device management utility. • More virtual_oss patches and improvements. • Attempt to implement an snd_hda(4) pin-patching mechanism. • Investigate SOF/DMIC support. You can also follow the development process in freebsd-multimedia@, where I post regular reports. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A bhyve management GUI written in Freepascal/Lazarus Links: Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/ Contact: José Alonso Cárdenas Márquez Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It needs a bunch of tools mostly installed by the base system and some installed from ports/packages. The main goal is to be a desktop application focus on desktop user to easily and quickly setup and run virtual machines on FreeBSD hosts. It should be used for virtual machines testing purpose (not for production). For a tool for production virtual machines management, take a look at sysutils/ vm-bhyve, sysutils/bmd, or sysutils/cbsd. Bhyvemgr supports aarch64 on 15-CURRENT only, and amd64 from FreeBSD 13.x to 15-CURRENT. It can be compiled from sysutils/bhyvemgr as a port, or installed as packages with gtk2, qt5, or qt6 interface support. People interested in helping the project are welcome. Version at the end of 2024Q3: 1.1.0 TODO • Test on real aarch64 hardware • Add uart device support • Add missing global setting entries (bios, board, chassis, system) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Changes to dhclient to speed up the FreeBSD boot process Links: Speeding up the FreeBSD boot process URL: https://wiki.freebsd.org/SummerOfCode2024Projects/SpeedingUpTheFreeBSDBootProcess dhclient Pull Request URL: https://github.com/freebsd/freebsd-src/pull/1368 Contact: Isaac Cilia Attard As part of my Google Summer of Code 2024 project, involving speeding up the FreeBSD boot process, I have worked on decreasing the time it takes for ARP resolution within dhclient to happen. This involved reducing the default ARP resolution timeout from 2000 ms to 250 ms, and adding an option to disable it altogether. The latter is useful within cloud environments, where a node is certain to have an IP address allotted to it. As a consequence of this, connecting to a DHCP network is now faster, including the boot process during which this happens. The speedup experienced is about 2 seconds. This causes FreeBSD systems to boot significantly faster than before. Sponsor: Google LLC (GSoC 2024) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Capsicum and Bhyve Code Audit Contact: Ed Maste Contact: Pierre Pronchery < pierre@freebsdfoundation.org> With the support of the Alpha-Omega project, the FreeBSD Foundation undertook code audits of two important subsystems — the bhyve hypervisor, and the Capsicum sandboxing framework. In addition to uncovering vulnerabilities in these systems to correct, the audits look to identify classes of vulnerabilities and/or suboptimal coding practices that we can look to address across the project. The Foundation interviewed several firms, and selected Synacktiv to perform the audit. A number of issues with critical and high severity were identified, which have been fixed as documented in security advisories: • FreeBSD-SA-24:09.libnv • FreeBSD-SA-24:10.bhyve • FreeBSD-SA-24:11.ctl • FreeBSD-SA-24:12.bhyve • FreeBSD-SA-24:14.umtx • FreeBSD-SA-24:15.bhyve • FreeBSD-SA-24:16.libnv Fixes are in progress for a number of lower-severity issues. The code audit report will be shared in the near future, after issues above a severity threshold have been addressed. The FreeBSD Foundation will also publish a report including commentary on the impact of the Synacktiv code audit report, classes of vulnerabilities identified, and lessons learned. More information is available in the Alpha-Omega repository. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Endpoint-Independent NAT Contact: Tom Jones This project aims to add support for Endpoint-Independent Mappings for UDP to the pf and ipfw firewalls. End Point Independent NAT enables applications behind a NAT speaking to multiple remote hosts to receive the same mappings. This allows an application without any NAT traversal mechanisms to work around NAT issues to perform peer discovery. From the remote hosts perspective the NAT is transparent and it is as-if there is no NAT at all. This form of NAT has been given several names over the last few decades and might be known as 'full-cone' NAT. Patches to pf landed in early September based on work by Damjan Jovanovic and Naman Sood with updates to work on pf in main. The patches add a new 'endpoint-independent' suffix to UDP pf nat rules. ipfw support for endpoint-independent is going to be made available via libalias, allowing any system which uses libalias for address translation to benefit from the change. There is an in-progress review D46689 to add support to libalias. The in-progress change and the committed pf change could both benefit from testing in more and diverse environments. Sponsor: The FreeBSD Foundation Sponsor: Tailscale ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kyua Jail Support Contact: Igor Ostapenko The FreeBSD test suite is executed by the kyua(1) utility. Kyua supports parallel execution of tests with kyua -v parallelism= test, however many network tests leverage jail(8) features like VNET(9) and have conflicts with jail naming and network configuration. As a result they are marked with the is_exclusive=true metadata property to prevent them from running at the same time and interfering with each other. It creates a dilemma when a project aims to increase test coverage, but the accumulation of exclusive tests proportionally increases the time required to run them. This, in turn, affects the development process from multiple angles. Kyua has recently got a change in 15-CURRENT to support a new concept called "execution environment". By default, tests run in the so-called "host" execution environment, where they are executed as before. A test can opt-in to use a brand new execution environment, the "jail" one. In this case, kyua creates a jail before running the test, and then executes the test within the jail. That opens up the opportunity to run more tests in parallel due to the extra isolation provided by the jail concept itself, and specifically by the VNET. It depends on hardware and configuration, but there are reports that having the same environment netpfil/pf tests can be run around 4 times faster — a few minutes instead of half an hour. The following Makefile change is a quick demo of how netpfil/pf tests were switched to run in parallel with jail execution environment: -# Tests reuse jail names and so cannot run in parallel. -TEST_METADATA+= is_exclusive=true +# Allow tests to run in parallel in their own jails +TEST_METADATA+= execenv="jail" +TEST_METADATA+= execenv_jail_params="vnet allow.raw_sockets" More details: • The key commit with detailed description: 257e70f1d5ee61037c8c59b116538d3b6b1427a2 • The man pages covering the "execenv" feature: kyuafile(5), kyua.conf(5) This change also brings new sysctl read-only variables, which expose more details about current jail, and may be generally useful: • security.jail.children.max: Maximum number of child jails • security.jail.children.cur: Current number of child jails A hint: the sysctl -n security.jail.children.cur run from prison0 provides the number of all jails in the system. Further improvements to Kyua, such as requirements definition and automatic resolution, are currently in the design phase. Potentially new metadata properties like required_klds and required_pkgs provide a clue to these topics. Please contact Igor to discuss ideas and use cases that can help shape these upcoming Kyua enhancements. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Linux Source Compatibility Wiki page Links: Linux Source Compatibility URL: https://wiki.freebsd.org/LinuxSourceCompatibility Contact: Edward Tomasz Napierala There is now a wiki page to track source compatibility differences between FreeBSD and Linux — and it needs your input! FreeBSD and Linux are already largely compatible at the source code level due to both being Unix systems and following the same standards. There are however certain system calls specific to Linux; there are also differences in header files, constants and so on. Implementing them in FreeBSD would make porting software easier. Not all of the items there are fixable. Some differences cannot be eliminated due to naming clashes, disagreements on how the system is supposed to work, or because it would make autoconf pick up a less functional compatibility API instead of the native one. In such cases we should document it and advise what API to use instead. The wiki page aims to provide an overview and help track progress. That is where your help is needed. I need people who actually port software to FreeBSD to add missing APIs, based on their experiences. This also includes non-syscall items, like missing headers and unsupported constants. Preferably also mention the name of the software that could use them. • Add missing items • Add prospective API consumers Sponsor: Innovate UK ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. Service jails — Automatic jailing of rc.d services Links: rc-article part for Service Jails URL: https://docs.freebsd.org/en/articles/rc-scripting/#rcng-service-jails service jail patches for ports in our bugtracker URL: https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=service+jail+aware Contact: Alexander Leidinger Service jails extend the rc(8) system to allow automatic jailing of rc.d services. A service jail inherits the filesystem of the parent host or jail, but uses all other limits of the jail (process visibility, restricted network access, filesystem mounting permissions, sysvipc, …​) by default. Additional configuration allows inheritance of the IPs of the parent, sysvipc, memory page locking, and use of the bhyve virtual machine monitor (vmm(4)). Since the last report several ports have been modified to come with a service jail config. Out of about 1460 start scripts in the ports collection, about 80 start scripts are changed. Prominent examples out of those are postgresql, DNS servers, FTP servers, PHP, dovecot, postfix, rspamd, amavisd-new and clamav. Some more changes are waiting for a treatment by the corresponding port maintainers. Any help in changing more start scripts (most of the time just one line to add) is welcome. If you want to help, you can check the bugtracker link above for changes which are already under review. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userspace UFS Driver (fuse-ufs) Links fuse-ufs GitHub URL: https://github.com/realchonk/fuse-ufs Contact: Benjamin Stürz During this year’s Summer of Code, I wrote a userspace UFS driver using FUSE and Rust. The project was meant to ease the process of mounting FreeBSD UFS filesystems on other operating systems. Up to this point, only read-only filesystem access has been implemented. But as a bonus, fuse-ufs has the ability to mount filesystems with endianness different from the host’s endianness. I am currently working on splitting the project into a binary and library part, to make it easier to integrate it into other operating systems. As part of this refactoring, an additional FUSE2 backend will be implemented, to be able to run it on OpenBSD. Currently there is testing infrastructure for Linux and FreeBSD with OpenBSD coming in the future. Although there is no CI for MacOS, a friend of mine tested it with MacFUSE and it works. Once the big refactor is done, I will start concentrating on implementing write support. Thanks to being bribed by Robert Clausecker, I will also add soft-updates and mounting Sun’s UFS in the future. The driver can be installed using cargo install fuse-ufs, or (if on Arch Linux) using your favorite AUR helper. Thanks to Robert Clausecker a port for FreeBSD exists in sysutils/fusefs-ufs. A big thanks to Alan Somers and Kirk McKusick for mentoring me and thanks to Robert Clausecker for the FreeBSD port and suggesting this GSoC project to me in the first place. Another thanks to Davids Paskevics for writing a fuzzer for me. Sponsor: Google Summer of Code 2024 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. FreeBSD V4L2 & kernel USB Video Class driver Links: Public development repository URL: https://github.com/AlvinChen1028/freebsd-src/tree/feature-uvc Upstreaming preparation repository URL: https://github.com/lwhsu/freebsd-src/pull/2 Contact: Alvin Chen Contact: Li-Wen Hsu This work is to create FreeBSD UVC (USB Video Class) kernel driver and follow v4l2 APIs, so that most of the Linux camera applications can be easily ported to FreeBSD. The code is still cleaning up and will be submitted to official review after completing. Current Status: 1. The key functions of the UVC driver are enabled. 2. The key v4l2 IOCTLs are implemented. 3. Support most of USB cameras (up to 4K resolution): Jabra, Logitech, etc. 4. Some applications validated: VLC, Cheese, pwcview. Future Work: 1. A couple of v4l2 IOCTLs need be implemented: make all cases in v4l2-compliance test suite be passed. 2. Some UVC APIs need be implemented: uvc control mapping callbacks, etc. 3. UVC lock issue related to USB. 4. PCI based AI camera supporting. 5. Code refactoring if needed. Sponsor: Dell Technologies for the development Sponsor: The FreeBSD Foundation for assistance of upstreaming ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ mac_do(4), setcred(2), mdo(1) Contact: Olivier Certner Contact: Baptiste Daroussin This project aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging our MAC framework. Traditional programs for credentials change have to execute preliminary operations as root (if not as the effective UID, at a minimum as the saved UID). Some of these programs (e.g., sudo(8)) have lots of lines of codes and comprise features (e.g., loadable security modules) that can be dangerous from a security standpoint. Thus, they have a non-negligible attack surface and are difficult to prove correct. Additionally, in most scenarios, the extra features they bring are not necessary. More generally, the threat model for the mac_do(4) kernel module part is that of compromised userland programs, be they credentials changers or credentials providers ones. This stance implies that calls to the kernel’s credentials-changing API must be monitored by the kernel without upcalls to userland. In practice, mac_do(4) must be configured beforehand by the administrator to indicate which transitions of credentials are valid (through a sysctl(8) knob, security.mac.do.rules). Currently, the companion userland program, mdo(1), is the only one that can be authorized to proceed by mac_do(4) (for now, based on the executable path). This tiny program simply establishes the new credentials via calls to setuid(2) , and optionally initgroups(3) (calling setgroups(2)) and setgid(2) (if -i was not passed). The resulting set of groups is either that of the target UID based on the password database, or that before the change in UID (when using -i). The second alternative can be a security hazard in some cases (as the effective GID is not changed either), whereas the first contradicts the threat model above. The current mac_do(4) rules specification indeed only allows to express simple UID transitions towards explicit UIDs from other explicit UIDs or GIDs, without taking into account groups. Consequently, the kernel module currently cannot check the content of setgroups(2) and setgid(2) system calls' parameters, relying completely on mdo(1) passing the right information. A new version of mac_do(4) has been in the works for approximately a month. Besides fixing concurrency, per-jail settings and MAC policies composition problems, it features a revamp of the rules specification in order to make it possible to finely control which groups are allowed in the resulting credentials. Notably, primary and secondary groups can now be specified independently, and for the latter, GIDs can be tagged as allowed, mandatory or forbidden. A special alias, ., can be used to indicate the current process' UIDs or GIDs depending on the context. These new features imply that the mac_do(4) module is able to apply credentials change at once, since the allowed final credentials depend on the initial ones through the configured rules. The traditional userland interface (e.g., setuid (2), setuid(2), setgroups(2), etc.) is at odds with this requirement as it necessitates multiple calls to reach the desired final credentials, making the process pass by several successive states that themselves may not be allowed by mac_do(4)'s rules. We overcome this limitation by introducing a new system call, setcred(2), which allows to request arbitrary transitions of credentials at once. Beside its usefulness in conjunction with mac_do(4), it has the benefit of simplifying coding of credentials change in userland. Since it is also extensible, it may have the potential to be adopted later by other systems. Pre-requisite changes are currently under review (see in particular revisions D46886 to D46889 and D46896 to D46923). The bulk of changes in mac_do(4)/mdo(1) proper will soon be pushed under review as well. An older version of the full series can be seen on GitHub. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Scheduling Priorities: 256-queue Runqueues Sub-Project Contact: Olivier Certner The goal of the 256-queue runqueues sub-project is to fix FreeBSD’s POSIX compliance in that different priority levels in the SCHED_FIFO or SCHED_RR scheduling classes must lead to immediate preemption by threads having higher priority. It is part of the bigger scheduling priorities revamp project aiming at rationalizing FreeBSD scheduling interfaces, including having consistent rtprio(2) and POSIX interface behaviors (where it makes sense), enhancing POSIX compliance, removing duplicate code and fixing existing bugs, and enhancing the non-standard parts both for better control and security. Expected benefits are increased usage of FreeBSD as a soft real-time platform, e.g., for video and audio processing in casual desktop uses to professional settings. Readers interested in this topic are invited to consult AsiaBSDCon 2024’s paper and EuroBSDCon 2024’s slides for a wider view, and to contact me for questions, feedbacks or discussions. Currently, priority levels specified either through the prio field of struct rtprio (rtprio(2) interface) or the sched_priority one of struct sched_param, for real-time scheduling classes (RTP_PRIO_FIFO and RTP_PRIO_REALTIME for the former, SCHED_FIFO and SCHED_RR for the latter) as well as idle-time ones (RTP_PRIO_IDLE), are conflated as follows: Each priority level that has the same quotient when divided by 4 is internally treated the same. In particular, threads being in the same such equivalence class but having higher priority will not preempt other threads in the same class, violating POSIX expectations for SCHED_FIFO and SCHED_RR. To remedy this situation, we have chosen an impacting internal change on the number of queues per runqueue, and defer to the above-mentioned EuroBSDCon 2024’s slides for more details. The switch to 256-queue runqueues having non-trivial impacts on the ULE scheduler, we have been analyzing it and tuning the scheduler to preserve its previous behavior with respect to anti-starvation and the effect of nice values. With the goal to perform further testing, we have revived Jeff Roberson’s initial ULE’s test tool, called late (currently available on GitHub ). All the modifications made as part of this sub-project are currently under review, starting with Phabricator’s review D45387 (click on the "Stack" tab to see the full series of reviews). In the course of this project, we have noticed that the effect of nice values is especially weak, and consequently have produced experimental patches to make their effect stronger. However, it is not clear at this point whether we can increase their effect satisfactorily enough in the current ULE setting. We have also started another scheduler project about adapting ULE to hybrid architectures, which might also trigger more drastic scheduler changes. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wireless Update Links: Categorised Wireless Problem Reports URL: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=0 Contact: Bjoern A. Zeeb Contact: The FreeBSD wireless mailing list The ongoing wireless efforts are trying to bring more support for recent chipsets as well as newer standards. With iwlwifi(4) and rtw88(4) being supported we received patches and initial reports for rtw89 and ath10k working for some people. Additionally ath11k, ath12k and various chipsets supported by mt76 are waiting for someone to find the time to finish compat code, test and debug. Work is ongoing to update drivers to Linux v6.11 using the now bootstrapped vendor branches, which should help maintenance a lot in the future. One particular focus for this update is also to find ways to minimize incompatibilities between wireless compat code versions in order to support multiple Linux versions as needed. After the native kern_malloc changes got committed, LinuxKPI is seeing ongoing work for memory allocation to play better by the rules set out in Linux which should help with DMA problems seen. There is further work pending to add missing bus_dmamap_sync() calls. There is work to support rtw88(4) SDIO devices (being tested on an r2s-plus) and ongoing work to stabilize updated USB support which should start landing once the driver updates have finished. Lastly there are more updates in the queue to finish 11n support for LinuxKPI 802.11 compat code as well as improving native net80211 code. If you have questions or feedback please use the freebsd-wireless mailing list. That way everyone will see, be able to join in, and the answers will be publicly archived. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ VirtIO Sockets and AF_VSOCK support Links: Source code URL: https://github.com/daniloegea/freebsd-src/tree/virtio_vsocks Contact: Danilo Egea Gondolfo The VirtIO Socket device is used to enable communication between guests and host without networking. The AF_VSOCK protocol family enables it to be used through the sockets API. For the past many months I have been working on a guest driver for the VirtIO Socket device and an implementation of the AF_VSOCK protocol family. Originally, I wanted to get the lxd-agent daemon working on FreeBSD but the communication with the LXD host daemon is done through VSOCKs. LXD is a nice container and virtual machine manager based on Linux/KVM and my end goal is to make FreeBSD a LXD first-class citizen. At the moment I have it working well enough to enable the lxd-agent to work. I adapted the golang.org/x/sys library and the lxd-agent to support AF_VSOCK on FreeBSD. Features such as command execution, interactive consoles and file transfer are working. On Linux, AF_VSOCK can be used with VirtIO, HyperV and VMware sockets as transports. I am trying to design my implementation so it will also be possible to use it with different transports in the future. After getting the current work in a good shape, ideas for future work include integration of AF_VSOCK and HyperV Sockets (which is already supported on FreeBSD through AF_HYPERV), VIRTIO_VSOCK_F_SEQPACKET, VirtIO Socket device for bhyve and the host side of the driver. I will continue to slowly work on this on my limited free time and hopefully have something more concrete for the next time. There is still a lot of work to be done until it become ready for code review. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Pinephone Pro Support Links: Repository on Codeberg URL: https://codeberg.org/Honeyguide/freebsd-pinephonepro Contact: Toby Kurien A new project trying to make FreeBSD usable on the Pinephone Pro has been started during August. The current FreeBSD RELEASE images already boot on a Pinephone Pro, but no screen output or other devices are supported. The aim is to step by step support additional components so that the device one day might be usable as a highly mobile FreeBSD device. Over the last few weeks, the groundwork has been implemented like getting used to the device, cross-compiling and booting a 15.0-CURRENT custom kernel as well as toggling the LEDs (red/green/blue in the front). Also, the LCD backlight can be turned on already and the USB-C hub is enabled even though it is not yet functional due to missing power management support. The next step is to write a driver for the RK818 power management chip. Without it, most of the hardware will not power on like the USB-C port above. This will be done by trying to modify the existing RK808 driver. RK818 support should then make it possible to access a lot more of the devices, e.g. allowing to enable the screen, USB peripherals or WiFi. Additional feedback and testers are welcome. Sponsor: Honeyguide Group ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SIMD enhancements for aarch64 Links: EuroBSDCon 2024 presentation URL: https://www.youtube.com/live/OzX38cWdivc?si=VsMrEmT_IdKpjv7W&t=22070 Slides from presentation (PDF) URL: http://fuz.su/~fuz/talks/eurobsdcon-str-talk.pdf Google Summer of Code (GSoC) project description URL: https://summerofcode.withgoogle.com/programs/2024/projects/TKRS35FA simd(7) URL: https://man.freebsd.org/cgi/man.cgi?query=simd&sektion=7&manpath=FreeBSD+15.0-CURRENT Contact: Getz Mikalsen The porting effort of the SIMD enhanced libc string functions from amd64 to aarch64 has been successfully completed. There are now optimized implementations for 16 libc string functions in addition to those with implementations already available as part of the ARM optimized subroutines library. There is also a presentation regarding the general method for these methods from EuroBSDCon 2024 available on YouTube with a short description in the end of how the porting has been done with regards to the aarch64 architecture. These enhancements significantly improve performance of string functions for all FreeBSD systems on the aarch64 platform. The code is currently undergoing acceptance testing in the form of an exp-run building all the ports, once without and once with the patch set applied to see if it has caused any new failures. Sponsor: Google LLC (GSoC 2024) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Souradeep Chakrabarti Contact: Colin Su Contact: Li-Wen Hsu In this quarter, we have published the 13.4-RELEASE on Azure Marketplace. Souradeep Chakrabarti from Microsoft has added a feature to use hypercalls for TLB shootdown on Hyper-V and Azure. Micro-benchmark shows 30-40% performance improvement on TLB shootdown. This has been presented at the DevSummit 202409 Wei Hu root-caused an issue on missing CDROM device when booting FreeBSD on the latest Azure v6 VM SKU. V6 type only offers NVMe disks to guest OS. He also continues bug fixing for FreeBSD MANA NIC device. Work in progress tasks: • Automating the image publishing process and merging to src/release/. (Li-Wen Hsu) • Colin Su is testing adding FreeBSD support in Azure Pipelines □ https://github.com/microsoft/azure-pipelines-agent/pull/3266 □ Building and publishing snapshot builds to Azure community gallery. Open tasks: • Update FreeBSD-related doc at Microsoft Learn • Update sysutils/azure-agent to the latest version • Upstream local modifications of Azure agent • Port Linux Virtual Machine Extensions for Azure Sponsor: Microsoft for people in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD on EC2 Contact: Colin Percival FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances. In the past quarter, a new "small" flavour of EC2 AMI has been added, without debug symbols, tests, 32-bit compatibility libraries, or the LLVM debugger, and without the Amazon SSM Agent pre-installed or the AWS CLI installed by default at first boot. Build performance tests are now being performed weekly using the snapshot AMIs built by the release engineering team. These tests revealed several performance regressions which have now been fixed; in particular a bug fix to the use of the EFI RNG in the boot loader produced a dramatic speedup on Graviton instances. Sponsor: Amazon Sponsor: https://www.patreon.com/cperciva ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OpenStack on FreeBSD Links: OpenStack URL: https://www.openstack.org/ OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd Contact: Chih-Hsin Chang Contact: Li-Wen Hsu The OpenStack on FreeBSD project aims to bring OpenStack cloud infrastructure to the FreeBSD operating system, using FreeBSD’s special features while keeping it compatible with OpenStack. In the third quarter of 2024, we continued working on several important tasks. Our work on porting OpenStack Ironic is still ongoing, with tests now running on arm64 servers. In this setup, the service node is amd64, and the provisioning node is arm64. This helps us explore more options for running mixed environments in OpenStack on FreeBSD. In August, we gave a presentation at COSCUP 2024 to share the project’s progress and our experiences. This helped us get more attention and interest from people in the community. We also updated some of the OpenStack components, like Keystone, Glance, and Placement, from FreeBSD 14.0-STABLE to FreeBSD 15.0-CURRENT. This update helps us keep up with the latest changes in FreeBSD, making the project run better. Another notable item was testing the bhyve serial console over TCP patch and using it in the OpenStack workflow. This brings us closer to stopping the use of the custom socat-manager solution and moving to a built-in serial console solution. Although we are still planning to turn the OpenStack manual installation process into FreeBSD ports, there has not been much progress yet. We hope to work more on this in the next few months. Existing work can be found in the openstack repository. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. Documentation Engineering Team Link: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ Link: FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/ Link: Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. Benedict Reuschling steps down from doceng@. doceng@ would like to thank bcr@ for his service. Document changes • Handbook: Document the automatic creation of XDG directories starting with FreeBSD 14.1. The VNET config example script has been fixed. • Architecture Handbook: remove K&R prototypes in MAC chapter. • Website: Some improvements regarding the top banner and layout, visually rearrange buttons and more. • Documentation repository: fix of all malformed tables warnings. Removal of deprecated attributes to conform to new gohugo releases. FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblate Link: FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/ Q3 2024 Status • 17 team languages • 214 registered users 1 new translator joined Weblate: • matthew (id) Languages • Chinese (Simplified) (zh-cn) (progress: 7%) • Chinese (Traditional) (zh-tw) (progress: 3%) • Dutch (nl) (progress: 1%) • French (fr) (progress: 1%) • German (de) (progress: 1%) • Greek (el) (progress: 1%) • Indonesian (id) (progress: 1%) • Italian (it) (progress: 5%) • Korean (ko) (progress: 32%) • Norwegian (nb-no) (progress: 1%) • Persian (fa-ir) (progress: 3%) • Polish (progress: 2%) • Portuguese (progress: 0%) • Portuguese (pt-br) (progress: 24%) • Spanish (es) (progress: 36%) • Turkish (tr) (progress: 2%) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. Packages maintained by DocEng During this quarter the following work was done in packages maintained by doceng@: • textproc/docproj: Bump gohugo dependency to 0.133.1 • www/gohugo: update to 0.134.3 Open issues There are 2 Open PRs in bugzilla assigned to doceng@: • 276923 www/gohugo link error under poudriere • 267274 Please remove the zh-CN Handbook of the current FreeBSD website During this quarter doceng@ closed 3 PRs: • 266107 FreeBSD Handbook and other books: PDF: broken links – crossref • 279815 status reports: ERR_TOO_MANY_REDIRECTS • 281396 handbook: ERROR: : line 149: dropping cells from incomplete row detected ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Wiki Links: FreeBSD wiki front page URL: https://wiki.freebsd.org/FrontPage Contact: Mark Linimon Contact: Wiki admin < wiki-admin@freebsd.org> The FreeBSD wiki is a repository of information that does not fit well in the official project documentation because it is too specific, too disparate, or too transient. Current projects: Mark Linimon has started attacking various stale pages. The focus has been on pages that we show to new, interested, users. (Recent Foundation newsletters refer to some of these pages directly.) Unfortunately, many of these pages have become stale, to the point where they were actually not good recommendations. The pages that have received the most work are: • IdeasPage (referenced in Foundation documentation) • JuniorJobs (referenced in Foundation documentation) • SummerOfCodeIdeas • various pages under CategoryProject • various pages under CategoryTodo • MentorMatch In addition to removing obviously stale entries, all entries have now been datestamped with the time that they were added to the various pages. wiki-admin@ would like to request that we carry forward this tradition into the future. As well, wiki-admin@ has been sending email to ask committers/contributors to the above pages "should we keep this entry?" This task will continue until the pages have been cleaned up. (NB: the fact that content in the wiki was stale was mentioned by numerous respondents in the FreeBSD Foundation 2024 Community Survey Report.) Previous plans that have stalled Plans are still underway to familiarize our audience on Discord with the wiki (there are too many "silos" in our FreeBSD community). The team has simply not had enough cycles to do this. However, contact Setesh on the FreeBSD Discord for more information. Preliminary work was being done on updating the wiki software itself. Earlier, we were looking at switching implementations because MoinMoin development seemed to have stalled, leaving us with an unwanted hanging python2 dependency. However, MoinMoin now claims that they are nearing a 2.0 release. We have not yet tried an install of their latest beta version to test compatibility. Testers welcome. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The FreeBSD Russian Documentation Project Links: FAQ URL: https://docs.freebsd.org/ru/books/faq/ Handbook URL: https://docs.freebsd.org/ru/books/handbook/ Web URL: https://www.freebsd.org/ru/ Contact: Andrei Zakhvatov The FreeBSD Russian Documentation Project’s current goal is to provide up-to-date Russian translations of the most important parts of FreeBSD documentation (FAQ, Handbook, Web). It is important to support Russian speakers with high-quality official technical materials and increase acceptance of the operating system around the globe. We hope that this activity will receive some support from the Russian-speaking FreeBSD community and lead to more translated materials. There is some progress in document translation: • FAQ: PR #277008 and PR #282062 • Handbook: Chapter 1. Introduction: PR #276334 • Handbook: Chapter 2. Installing FreeBSD: PR #280610 • Handbook: Chapter 3. FreeBSD Basics: PR #282059 Check the official translation guide if you are willing to help. We always appreciate your help with translation of the following materials: • Handbook chapters and sections • Articles • Web pages ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org/ GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ GCC 13 release series URL: https://gcc.gnu.org/gcc-13/ GCC 14 release series URL: https://gcc.gnu.org/gcc-14/ Contact: Lorenzo Salvadore This quarter the main news is about the new GCC releases: • lang/gcc11 has been updated to 11.5.0, which is the last GCC 11 planned released; • lang/gcc12 has been updated to 12.4.0; • lang/gcc13 has been updated to 13.3.0; • lang/gcc14 has been updated to 14.2.0. The exp-run to update GCC default version from 13 to 14 has started. As usual, thanks to everyone involved. If you maintain any of the affected ports or want to give a hand preparing and testing some patches, please consider trying adding -fpermissive to CFLAGS in affected ports: GCC 14 has transformed some warnings into errors, which is the cause of many of the failed builds. The -fpermissive flag switches those errors back to warnings. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Freepascal and Lazarus on FreeBSD aarch64 Links: Freepascal Project URL: https://www.freepascal.org/ Lazarus IDE URL: https://www.lazarus-ide.org/ Contact: José Alonso Cárdenas Márquez Free Pascal is a mature, versatile, open source Pascal compiler. It can target many operating systems and processor architectures: Intel x86 (16 and 32 bit), AMD64/x86-64, PowerPC, PowerPC64, SPARC, SPARC64, ARM, AArch64, MIPS, Motorola 68k, AVR, and the JVM. Additionally, support for RISC-V (32/64), Xtensa, and Z80 architectures, and for the LLVM compiler infrastructure is available in the development version. Also, the Free Pascal team maintains a transpiler for pascal to Javascript called pas2js. Lazarus is a Delphi compatible cross-platform IDE for Rapid Application Development. It has a variety of components ready for use and a graphical form designer to easily create complex graphical user interfaces. Three years ago, Mikaël Urankar began porting the Free Pascal compiler to FreeBSD aarch64 and it was merged into Free Pascal source code (main branch). Some months ago, I added lang/fpc-devel (3.3.1) and editors /lazarus-devel (3.99) to the ports tree only for i386 and amd64 because aarch64 was not ready yet. The binaries generated on aarch64 did not run because of ELF issues. Finally, some days ago the issues were resolved and support for FreeBSD aarch64 was completed. lang/fpc-devel and editors/lazarus-devel were updated to 3.3.1.20240913 and 3.99.20240913 with support for aarch64 respectively. It brings to FreeBSD users a new language and platform working on FreeBSD aarch64 for console, graphic, or any kind of apps development. TODO • Update fpc/lazarus based ports (such as sysutils/bhyvemgr and archivers/ peazip) to support FreeBSD/aarch64 • Push FreeBSD RISC-V support ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on GitHub URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Bretton Vine (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. Potluck aims to be to FreeBSD and Pot (and potentially one day also Podman) what Dockerhub is to Linux and Docker: a repository of container descriptions and complete container images for usage with Pot and in many cases Nomad. During this quarter, there were two bugfixes to Pot that will be released soon. Potluck images saw some updates again. All images have been rebuilt again to include the latest fixes and quarterly packages. Additionally, some images like Loki or Vault have also received additional updates and bugfixes. Also, we have done some research regarding potential future support of OCI, Buildah and Podman images in Potluck. Two blog posts, one describing a basic Buildah and Podman setup and one describing how to orchestrate Podman containers with Nomad and Consul have been published. As always, feedback and patches are welcome. Sponsors: Nikulipe UAB, Honeyguide Group From nobody Thu Nov 7 15:43:49 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 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: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_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 Thu Nov 7 19:40:59 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XksrS2xzYz5cTJM for ; Thu, 07 Nov 2024 19:41:12 +0000 (UTC) (envelope-from freebsd@ny-central.org) Received: from mail2.ny-central.com (mail2.ny-central.com [173.212.246.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4XksrR6BMwz4hyp for ; Thu, 7 Nov 2024 19:41:11 +0000 (UTC) (envelope-from freebsd@ny-central.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ny-central.org header.s=202405 header.b=S9MLxAU0; spf=pass (mx1.freebsd.org: domain of freebsd@ny-central.org designates 173.212.246.2 as permitted sender) smtp.mailfrom=freebsd@ny-central.org; dmarc=pass (policy=none) header.from=ny-central.org X-Virus-Scanned: amavisd-new at ny-central.com DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.ny-central.com C84091AF1B2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ny-central.org; s=202405; t=1731008470; bh=LY/gfFY5BBVF0vv17Zz5KmMbCums1LYsRG/TJhknVHE=; h=Date:From:To:Subject:In-Reply-To:References; z=Date:=20Thu,=207=20Nov=202024=2020:40:59=20+0100=20(CET)|From:=20 Chris=20Moerz=20|To:=20freebsd-hackers@fre ebsd.org|Subject:=20Re:=20Seeking=20Guidance=20for=20FreeBSD=20Pro jects|In-Reply-To:=20|References:=20 ; b=S9MLxAU0erwxDNwr0fREVLLL4O9jkQkb4xJhJTfsC1s3GMBYYU5pK+1vz2GLV1B1w 1yF07wtHzta9ee04LBUKY4J3lCDAy6Buh25svUTMcCUuRWQS+WJ+W1/+gcrHg3qw8e aObfwdJW5ihaKdvCkzbOp4+7GS5a4EaLd104sdLtyrIuZNYSGZRFv8QVONt9iafmAG JSCrhra4wH7PZ/xvorAYtI2vWSx278xzygICbXuoZVMAR2sXj2OCpq16hRxc4/8CMV 9OB7ZDcM3kE31zUNs1NBSuC5nXiQn7TIWccZkC6b2RHe3NLxzL9DGllDhqAE4+E8fT kaP4ZlieZxIop72GNs9+LFFQhITJllt31gat5Abg1724ljlkeuDMcdb93nV4l8Ysyz 4x5Ms4+J8l1mvYmVU6iJc5kmuzpZcfhUympXZhOTovLityXKQoZVBTMM9GyjXRQLJB bS/mv7ufU1Unuz1lK9qo6ksqF03uFq+q2a6UDQLvCyPpNmQeC1KXsGvEZZiLMtpisI aA+wkflgj6ioMqsSI5FsktMjvE7TC0haFMisD4HS0BXpUXAjz8FGW6WKlZnBgq/X3w NPIh1sLqQqAnlhRASqmjagj31FufBOHt5VcKkBNhDRRO1Wjq5kanlOfgEiSQd6qqLh v59kXO33qzjPzBW8WiFXfTgc= Received: from tenforward.ny-central.local (unknown [192.168.11.104]) by mail2.ny-central.com (Postfix) with ESMTPSA id C84091AF1B2 for ; Thu, 07 Nov 2024 20:41:00 +0100 (CET) Date: Thu, 7 Nov 2024 20:40:59 +0100 (CET) From: Chris Moerz To: freebsd-hackers@freebsd.org Subject: Re: Seeking Guidance for FreeBSD Projects In-Reply-To: Message-ID: <2f2d88d9-f0dc-b71a-294c-736ccce11940@ny-central.org> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3328038562-2077882235-1731008460=:10241" X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mail2.ny-central.com X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[ny-central.org,none]; R_DKIM_ALLOW(-0.20)[ny-central.org:s=202405]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:51167, ipnet:173.212.240.0/21, country:DE]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[ny-central.org:+] X-Rspamd-Queue-Id: 4XksrR6BMwz4hyp X-Spamd-Bar: -- This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3328038562-2077882235-1731008460=:10241 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Hi Leonardo, not sure whether you already received a reply, so I figure I'll attempt to help connect some dots. There's a wiki page that lists a handful of people who are helpful contacts for various topics and areas of development, who you could reach out - obviously, this would apply primarily if, down the road, you identify a particular topic area you realize you're very much interested in. See https://wiki.freebsd.org/MentorMatch There is an article on Contributing to FreeBSD on the docs site, which helps with getting an overview of the various development parts of FreeBSD: https://docs.freebsd.org/en/articles/contributing/ There are various projects listed on the wiki, which could potentially be a good starting point: https://wiki.freebsd.org/CategoryProject However, since this may be too much choice, maybe you want to focus on the "junior jobs" first: https://wiki.freebsd.org/JuniorJobs Hope this helps. I'll ask around for further pointers in the meantime. Let me know if there's any further or other questions. Thanks chris On Wed, 6 Nov 2024, Leonardo Pio Francesco Gallina wrote: > Hi, > > I’m Leonardo Pio Francesco Gallina, a computer engineering student at Politecnico di Torino, currently pursuing a master’s in Embedded Systems. I plan to participate in Google Summer of Code with FreeBSD to gain real-world project experience and make helpful contributions to the project. > > At the moment, I’m familiar with C, MIPS, and ARM, and I’m taking courses in Computer Architecture and Operating Systems for Embedded Systems. I was thinking of starting by reading the FreeBSD Handbook and writing some basic device drivers to gain practical experience with FreeBSD’s codebase. > > I’d appreciate any guidance on beginner-friendly projects or areas within FreeBSD that could help me get ready for a GSoC application. > > Thanks in advance, > Leonardo > --3328038562-2077882235-1731008460=:10241-- From nobody Thu Nov 7 20:02:57 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XktKb75kwz5cWLs; Thu, 07 Nov 2024 20:02:59 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XktKb6Y7tz4nSt; Thu, 7 Nov 2024 20:02:59 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731009779; 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=1FkLkEDhZ+hkwCoxvXPWh2uVIx5rXvUx3dAFTwDK/Hk=; b=kL9LxP9ET2qvI9Uh4eNMxpXAKLKMSahfmto+dBL3BY852UhRwKo9vKfhJ7tEJ2ftwtxULl /pFHUq0ihEuwlMjHjbwqMxgxrFU8mztNwAaWI3YW0SH+M7F0BULXY5Bre05nFkR4ObOkhv l0CpBgI4pjC39nKa7u++CsA9i7hnImVSNEB7kQrip2F4FcWnV8Ksa8YVbw/hgN3WD/XS9u vdvRvsnRzgbEkI7mK1HgJmPSVIXzKdm3+0171QyVbV+hl3cLk/rvTS9IB1YIeWhSOkRTCX 9eSQbfSTd4kF6pToZulI2Cw+IJKgryWVUH+9vrYU69kvlrXA7VDoptTc3mKZaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731009779; 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=1FkLkEDhZ+hkwCoxvXPWh2uVIx5rXvUx3dAFTwDK/Hk=; b=W1ik4L137narmoxc/GkGB+z8wn5V6uNCeeh/lkoJ1RnOwNExp9Xy+shUOAGKh86wXKg7kT Fp3yHPfuortj8lRadgKAFAUOiWk1695dVclfbGt2D/bURPGGsjVV2xSdq24bTnLEbhe4IE KeblI1FOHV5NRFICSAZjsfz/ZRggFKfbj8yCeJJbZxxL/A0OxCDwG4h4HsI6hGrQrTJQmL f7m5R8sMmrdJFZOkwU5fkV/pMyI4gKjZnVZWR52Q9nsXRnJf8L4fuugn7TYKzoSnA9dH92 ZgouyTy9ThKYch/Fr9tq/kRQHbqdJd/XmyNfqLCf/EY8uTV4uz/7FlmK7230Aw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731009779; a=rsa-sha256; cv=none; b=SUCfm633d1s5WuhPKGMacH6iVw0rESZi1w4y/Stj1tEm+r4di+87GqX35kg/7fZKlbaCix 07O5mGojUoT01rnOq6I9fLiCciOj+n25ZN5cg7Fy9ipvd5ybdaRkghUpistGIVRCByOM2a Jw2J2FvOPyoBUP5T0mx98/nZGMw/g9kR+Sw6S6psbJJ+q9AcCiDTAtFthCcxwSqYf4yLc/ xSRapkBnPpko306LsGgLwq8iIszoWLFz5OyvKnWZ/L97et35mOcMKzWtgxxIHZdCGbjIVC FNmPJLd+Qn/tG5Xr7vkw1X8Nj1+LdlyIZbjeN+Tx6NOgyHy7BCn1V+YEwE3LRQ== Received: from ralga.knownspace (unknown [IPv6:2600:2b00:a720:d301:9f03:382a:d672:81f0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhibbits) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XktKb4qSrzGfY; Thu, 7 Nov 2024 20:02:59 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Thu, 7 Nov 2024 15:02:57 -0500 From: Justin Hibbits To: , Subject: Watchdog rework Message-ID: <20241107150257.022d1f92@ralga.knownspace> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; powerpc64le-unknown-linux-gnu) 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 Hi everyone, I've spent some time reworking the watchdog framework, changing it to use sbintime_t instead of power-of-2-nanoseconds. I've thus far tested it only with a software watchdog, but put it up for review to get some feedback on the approach as a whole. The changes are backwards compatible, so drivers don't need to be converted immediately, but can instead be converted over time as needed. The change was brought because at Juniper we have some watchdog timers that don't fit nicely in the power-of-2 nanosecond format, but instead use a simple countdown timer. Moving to sbintime_t (which may even be slightly overkill) gives more freedom with setting the watchdog period. The review is at https://reviews.freebsd.org/D47312 and I would love to get some feedback on it. - Justin From nobody Thu Nov 7 20:33:46 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Xkv1W38ngz5cYrp for ; Thu, 07 Nov 2024 20:34:07 +0000 (UTC) (envelope-from freebsd@ny-central.org) Received: from mail2.ny-central.com (mail2.ny-central.com [173.212.246.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4Xkv1V2lP4z4v6P for ; Thu, 7 Nov 2024 20:34:06 +0000 (UTC) (envelope-from freebsd@ny-central.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ny-central.org header.s=202405 header.b=SxV+JiW0; spf=pass (mx1.freebsd.org: domain of freebsd@ny-central.org designates 173.212.246.2 as permitted sender) smtp.mailfrom=freebsd@ny-central.org; dmarc=pass (policy=none) header.from=ny-central.org X-Virus-Scanned: amavisd-new at ny-central.com DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.ny-central.com 445291AF183 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ny-central.org; s=202405; t=1731011645; bh=H2GJPCbtYQgH2+Ahw8szDICJNweTsm0tQcCexlByW6U=; h=Date:From:To:Subject:In-Reply-To:References; z=Date:=20Thu,=207=20Nov=202024=2021:33:46=20+0100=20(CET)|From:=20 Chris=20Moerz=20|To:=20freebsd-hackers@fre ebsd.org|Subject:=20Re:=20Seeking=20Guidance=20for=20FreeBSD=20Pro jects|In-Reply-To:=20<2f2d88d9-f0dc-b71a-294c-736ccce11940@ny-cent ral.org>|References:=20=20<2f2d88d9-f0dc-b71a-294c-736ccce11940@ny-central.org>; b=SxV+JiW0lVIDEOXh674n3AhL9x0hEUx37m3P06+6YI8htGfRW7AffTky6EPBDtBdK VEE3Ad98Zhi2VXONKQJNzQ3P4/zm998YJmvniGF6ymsfkMj9QSWwDlzX4eITpq7ujJ GHsRX0XShW3csvMM25VvO2rkgXYnBePjqvp3gDbilMOpkwMwyjZlNsrwXBIxLbosaI AvMvsLEMZlagK8XV881EqKasUY3tKfD+dFy7Yai8h2pBmH1h4H31+Bf5orU3WGeheU YeDhjRTYQFoDH6SqD787VdFvbjqDDhHFQhLtC4eydA4pdb0E6fUQU+rj54Se3J24kS d+0g3g20/Vx/JZAax9oJFpIIA9GDIOOXijXDNv5U8f25BUUfWQn110BMrZNb6lgBz+ PvxqhmWJiCPewtsXbhzhlYxJ7BE7gr0bIt+wOAfALoiIfROxBTIfD7wrS7WMhghZnB 18M2DwBeDRtQaIN2OOM47lyidxDQ6kkywTSq29UBwWYjxoo6kdSU8ebgRKIgHiJ6KD lIYsUsQvY+X5xvhr/MS7aLbhWzwjbGWBXrNKDTZSMIeA9Bm46b5W3/5Q/YpXxzy48J Ab+4a3Zx0v0rlEKUIrEU42OS8WzWuJ+5BpQtoanu706ul/W9L9W4FzS3QzzH6gKbyZ W4in/6xVrb6sago/xgZirIPQ= Received: from tenforward.ny-central.local (unknown [192.168.11.104]) by mail2.ny-central.com (Postfix) with ESMTPSA id 445291AF183 for ; Thu, 07 Nov 2024 21:33:55 +0100 (CET) Date: Thu, 7 Nov 2024 21:33:46 +0100 (CET) From: Chris Moerz To: freebsd-hackers@freebsd.org Subject: Re: Seeking Guidance for FreeBSD Projects In-Reply-To: <2f2d88d9-f0dc-b71a-294c-736ccce11940@ny-central.org> Message-ID: References: <2f2d88d9-f0dc-b71a-294c-736ccce11940@ny-central.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/mixed; boundary="3328038562-1995239470-1731011635=:20890" X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mail2.ny-central.com X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ny-central.org,none]; R_DKIM_ALLOW(-0.20)[ny-central.org:s=202405]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:51167, ipnet:173.212.240.0/21, country:DE]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[ny-central.org:+] X-Rspamd-Queue-Id: 4Xkv1V2lP4z4v6P X-Spamd-Bar: -- This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3328038562-1995239470-1731011635=:20890 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Hi Leonardo, I stumbled across this reading the quarterly report. That one is probably the best link to really get you started towards Google Summer of Code: https://wiki.freebsd.org/SummerOfCodeIdeas chris On Thu, 7 Nov 2024, Chris Moerz wrote: > Hi Leonardo, > > not sure whether you already received a reply, so I figure I'll attempt to > help connect some dots. > > There's a wiki page that lists a handful of people who are helpful > contacts for various topics and areas of development, who you could reach > out - obviously, this would apply primarily if, down the road, you > identify a particular topic area you realize you're very much interested > in. > > See https://wiki.freebsd.org/MentorMatch > > There is an article on Contributing to FreeBSD on the docs site, which > helps with getting an overview of the various development parts of > FreeBSD: https://docs.freebsd.org/en/articles/contributing/ > > There are various projects listed on the wiki, which could potentially be > a good starting point: https://wiki.freebsd.org/CategoryProject > > However, since this may be too much choice, maybe you want to focus on the > "junior jobs" first: https://wiki.freebsd.org/JuniorJobs > > Hope this helps. I'll ask around for further pointers in the meantime. > Let me know if there's any further or other questions. > > Thanks > chris > > On Wed, 6 Nov 2024, Leonardo Pio Francesco Gallina wrote: > > > Hi, > > > > I’m Leonardo Pio Francesco Gallina, a computer engineering student at Politecnico di Torino, currently pursuing a master’s in Embedded Systems. I plan to participate in Google Summer of Code with FreeBSD to gain real-world project experience and make helpful contributions to the project. > > > > At the moment, I’m familiar with C, MIPS, and ARM, and I’m taking courses in Computer Architecture and Operating Systems for Embedded Systems. I was thinking of starting by reading the FreeBSD Handbook and writing some basic device drivers to gain practical experience with FreeBSD’s codebase. > > > > I’d appreciate any guidance on beginner-friendly projects or areas within FreeBSD that could help me get ready for a GSoC application. > > > > Thanks in advance, > > Leonardo > > --3328038562-1995239470-1731011635=:20890-- From nobody Fri Nov 8 12:38:17 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 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: 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 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