From nobody Mon Nov 22 19:16:45 2021 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7CF5318980FD for ; Mon, 22 Nov 2021 19:16:45 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HycT937TTz4RnT for ; Mon, 22 Nov 2021 19:16:45 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637608605; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=UibQjc/2UCHUSi+maBtrVAunbJkWRyk6hTJMJqrFwkU=; b=wtwTubVvEichnL9UecQ9idjToyIzTFLpbxgvJYnQiDAHtJxP7VwwrYz2I/qgiEJtrxbjEY 2recnT3DKloQFEzLwq3w+p0r2I2TISpH9MjuCVIZzA2KyzETV24B0rE2aPlADZGEO3DyNS xS+nG8SYW65w79VvwJVtb7cIupVgRVil8NC/8R+ebw5KtMmMtC0tGgdtrGfeQItzXS5CWV 7QXIuAzYr3LJwETdodoTwXLpJHS9pFKknXK4U4+uUokBeRh1KllGLQwgMtCENKWqS38Qt+ Q7RfoBuRHaSf1sDAbYC5XNHKJAcT4Pbx85xpeHLN309f89SgGBK1p6/e2PN7gA== Received: by freefall.freebsd.org (Postfix, from userid 1403) id 51E251F6DF; Mon, 22 Nov 2021 19:16:45 +0000 (UTC) Date: Mon, 22 Nov 2021 19:16:45 +0000 From: "Piotr P. Stefaniak" To: freebsd-arch@freebsd.org Subject: Introducing base64(1) Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637608605; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=UibQjc/2UCHUSi+maBtrVAunbJkWRyk6hTJMJqrFwkU=; b=AaWLIMC4zsp1CmAx0+l8vfx85jQkaptAZbi0pdsC4R4IzKvVJlrj9zd0YMZEJik2NwRqwP rljNdLt0VIDcDOIg07CxJFgyHv3I65pybcmFHqjJJ0Qkq8CZcX7s9MQYKhm7razTeZEtft 9I31aMKqTuw3fUBEhUi3VqzBrIdncLKP9ZQlFvcMlPeGOVpah4g4AyuKv7HikAkbtKRqWq WkvWJMHrELVbnHsHBfteMuhx5tuG2eB8Gn/f0ErfSNZSAvWTj/Hes1BhZCuz0LmNNfkRI7 MTJMGiowN2TIfsEDyg+MBaW3mUflLtrIk3vmC73bpbRCO17nHfMSfqucj0n/PA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637608605; a=rsa-sha256; cv=none; b=XFXeXq13Ta8FGqr79W04SMSL1BxEYTh2jc+iWsDqPJi5gVa91GX9wfwLoE/mMoQCgftW2z /8959ZS6+wYLA75Y5sihPeH2FLztvLrUyIKgo5cqWiMxGJTxwjV2et4x139te81uBGJ4KQ 9oUIDeHsaHGkoguPZRVkDvfzqh3fuqZyc5dpJfhjtTU6j+7AM4hb9iPypTz9LyvbTERB5O qIR7KdkIe/SobbkmEaxOroTRT4wMpm+E3dvfdSZYtQBM8F7K61LzmcVz1jvatQvKjC0Bsq FronWgyoapAVqukKHrfTgm8MHJ84905nM+ZDodeJK9LvGmACtqJrnLT79H2ICw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello archers, I've prepared a short series of changes: https://reviews.freebsd.org/D32943 "Conflate uudecode and uuencode" https://reviews.freebsd.org/D32944 "b64encode: implement -w to wrap lines" https://reviews.freebsd.org/D32945 "Implement base64(1)" First, I modularize uuencode and uudecode by wrapping them in bin2text2bin.c ("binary to text to binary"). The program will be installed as bin2text2bin, uuencode, uudecode, b64encode, and b64decode and will be responsible for running the coders according to their historical behavior. Additionally, bin2text2bin will be able to take a parameter designating the coder and accept all its options in this form: bin2text2bin [options] and the behavior should be the same as if [options] was invoked. This has the advantage that adding coders won't require installing them as binaries. I think quoted-printable or yEnc would be nice, but currently I have no plans to implement those. Second, I implement an option to b64encode that sets the column after which lines wrap. Plus, I accidentally optimize the function that produces the encoded output. Third, I use the existing b64encode and b64decode implementation and the newly implemented option to call it as base64, respecting the syntax of that program's invocation. Corrections, bug reports and other thoughts welcome. Piotr From nobody Fri Dec 10 21:40:19 2021 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C1BE018D69CF; Fri, 10 Dec 2021 21:40:32 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9kpm2WHZz4qbr; Fri, 10 Dec 2021 21:40:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 31A7D2787C; Fri, 10 Dec 2021 21:40:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f170.google.com with SMTP id t34so9718468qtc.7; Fri, 10 Dec 2021 13:40:32 -0800 (PST) X-Gm-Message-State: AOAM532AOsakstNQF6iAEWA0LJUEwQHtiOo8cn0EWsp+VdKIgWbfbEZ3 oUmXWoxXuTYX9a3G5tYz7cjcrGx81/dXBlwvG9I= X-Google-Smtp-Source: ABdhPJy8zvPV9WwF1yp+H6c7BRh3PrDY0DjyWpLTbWDYYYNqo9IlZNVf4QoSPXy+niE80AJoIx52bnYWsIBnfQCIJ2A= X-Received: by 2002:ac8:58ca:: with SMTP id u10mr29657394qta.44.1639172431649; Fri, 10 Dec 2021 13:40:31 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Kyle Evans Date: Fri, 10 Dec 2021 15:40:19 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: configng To: freebsd-arch@freebsd.org, FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000839de905d2d19259" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639172432; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=lmfbxcQqkI8m0v4FpItYbn2gjjSqm1Zc+RfMjjYf5P4=; b=NAe+8yVDfelQg9uBNvsOXjmw3GQse7Edlm2QlEV8yJgkouW46r7ytZ0LHByP13OJXVx5iH i9Qfn+Okppp2/yEFC0Au/UORRsVnjjSw5yNlQcw4NBAmctYGkb5jAaJ8h6vN5E8+1EMT5S +YWK4lLLo/en6WnaAHwfZTwT4170rJqfyg79BWCv4IP8kaXBk7ponnqpftyAoL2xnBxvuV 9XVWfpOk+F9SdOqjcZDS2wxTc5tZfvJHLxTOJ3g31WlsAFd5Q8J00VDtaloIMh9GzR+031 k+6r4rZ8FwKmdPktG8g0YB46RgLNMz2I8jJ4eSLMUYG44HCA6cZzg+ABurtVpQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639172432; a=rsa-sha256; cv=none; b=qRfzkea6VsaBCnrabEFDHazAtK5gmEyoe2e+uRJdQE0/8ds8ucqWN949W0pD8U7RkyD4Wp b/6f32pQDwUnP+qy5ayV8TQ3ghK0Y4x/4BArlUTRYOzxcTu2YNdYYfaD1bEzPCNDpDUHHt tLx7PSxrp4iSDkEcUiYetTme9i7dCUs+mo5galRym1Yb/O2hJzB/iB1sQcSh0AbxvJBjXp nXqjRTCkIzk/oOAaZkai131firyPUTWSMzFr/MQYq+IjvJ2Fs7y17ZRp9EtP/7ulVSY10G Ra7kKxJFkUS2IW9FIYqKEWDItWqzYNEqSuqahk2LXnBhES5MKLyTTSB70JSeYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: Y --000000000000839de905d2d19259 Content-Type: text/plain; charset="UTF-8" Hi, FYI- we're forming a group to look at what the next generation of config(8) should look like, with the goal of addressing some long-standing issues with the existing kernel configuration system. If you're interested in participating in the ongoing design discussion, please shoot an e-mail to kevans@FreeBSD.org or imp@FreeBSD.org. The current high-level requirement outline can be found here: https://hackmd.io/w1Tf8mmVQVuZok7-LNEhgw The current expectation is that configng will use an entirely different configuration language, rather than extending what we currently have, and come with some tooling to aide migration. This will be discussed more in-depth in later stages; for now, we want to focus on what we want to get out of the next generation. Thanks, Kyle Evans --000000000000839de905d2d19259-- From nobody Fri Dec 10 22:39:37 2021 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 87AA218E243A; Fri, 10 Dec 2021 22:40:15 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9m7g3CWmz3Gs8; Fri, 10 Dec 2021 22:40:15 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wm1-x331.google.com with SMTP id 77-20020a1c0450000000b0033123de3425so10126621wme.0; Fri, 10 Dec 2021 14:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4EILn3eJFqusQL6CnbT2GOklNsW1NwwTKUSrNYVyxqo=; b=HyiKSLiHMPqS5/jmc0LLi72wYXMDN27paek9grVO0auNpjQdjY+x/Wa7uH3AsR67Fc DSnIuKLCkUpiEWB0tvpDUNZZjOOQRj+tIYTIBiKCS2IqJAMlhNEypVyIbtOoIlmj6hnx mjqoES7FD1m224gccnjhRXYtOXnRnRAThSGRNIXKQQkhr51zqEa6dLz40CAgDMnHkejq IGud3ccE00fKaebqo/MFUdPWO0/hiU6/9hWNCSwn8JR1EUOeW6G5kkKrzBgXoXjSAKbi ohtj2i1HtnrC7UsZDUfqrjDtNo0FLhXtGmOsG+XaanFVcZkTQzujWblR7dI4m/DY2uSW lCSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4EILn3eJFqusQL6CnbT2GOklNsW1NwwTKUSrNYVyxqo=; b=L09DvGNt3B5DikLuGfev8JAF5bQWgU3Mv5C/PU2+3HVzcFpeV4pPBa+sqkM+Rb5n1m 5wSuNb5TgswIF7WtHJ29T0rlqZFSOPkUhiwTz7NTFLpBs2SXir6W8SD8gt9f8xk3lAdb 7nQVj62pbPsP3BMC/gt4r6f+2ENSpufYVqYPazWzvpVIOp0wAQDiYcsEGkTpddE0qicG Vdpp4ONYgVNW3ZuNaXE9kypy8OmG2fM6W7lAhAXj6YuRTru8yYmQ+kKUew4LEWKRPxF2 ER+kuCIySNDVWEGfdRXpOofzGbKez4BdcDSNcqk4n5Cxhp9GiQYu9iURfL8sRoqYcMgq ykpw== X-Gm-Message-State: AOAM530aXgEMsqvUZYnZWi18V4CT9rZBn48RpKU0uaOWolQ1edv6VIJ1 HKxB/z+5qW66KfgeILWX6gsLecIk3Sg0HC91Hb6t1YD/Vnk= X-Google-Smtp-Source: ABdhPJxNDpt13xhxHCtxAaMl3nCtMaFjxkh/oM/3fMvsal9N52sTel8aZ5EzIUecSKBANHx6xenPNgCZVWcCGX9BcRk= X-Received: by 2002:a05:600c:4f55:: with SMTP id m21mr20602202wmq.68.1639176013983; Fri, 10 Dec 2021 14:40:13 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Sat, 11 Dec 2021 01:39:37 +0300 Message-ID: Subject: Re: configng To: Kyle Evans Cc: FreeBSD Arch , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000009b29505d2d2685d" X-Rspamd-Queue-Id: 4J9m7g3CWmz3Gs8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --00000000000009b29505d2d2685d Content-Type: text/plain; charset="UTF-8" On Sat, Dec 11, 2021 at 12:41 AM Kyle Evans wrote: > Hi, > > FYI- we're forming a group to look at what the next generation of config(8) > should look like, with the goal of addressing some long-standing issues > with the existing kernel configuration system. > > If you're interested in participating in the ongoing design discussion, > please shoot an e-mail to kevans@FreeBSD.org or imp@FreeBSD.org. The > current high-level requirement outline can be found here: > https://hackmd.io/w1Tf8mmVQVuZok7-LNEhgw > > The current expectation is that configng will use an entirely different > configuration language, rather than extending what we currently have, and > come with some tooling to aide migration. This will be discussed more > in-depth in later stages; for now, we want to focus on what we want to get > out of the next generation. > > Thanks, > > Kyle Evans > My suggestion may be to use an "expert system" with its "rule" structure . Over time , by adding rules only , you may improve its ability to make decisions for a proper configuration . In that way you will be able to use an expert system to manage your rule base . You may study as a beginning point the CLIPS among many other systems : https://en.wikipedia.org/wiki/CLIPS CLIPS You may design all of expert system as a single XML file or other included XML file names as elements of main XML file ( let's say ) entries . You may need to cooperate with a person being "expert" on "expert systems" . With my best wishes for all , Mehmet Erol Sanliturk --00000000000009b29505d2d2685d-- From nobody Tue Dec 14 22:27:29 2021 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 422C018F537E for ; Tue, 14 Dec 2021 22:27:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDCgJ37WZz4cH1 for ; Tue, 14 Dec 2021 22:27:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x930.google.com with SMTP id n9so18532952uaq.10 for ; Tue, 14 Dec 2021 14:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=PxzPaY/Ogt1rPKPAANV8Wd2TFWVbdj6E5Ss9Pp8cQNg=; b=gVPzyWvCJGv/iie84NMToUwfIFaOuy65cK9QZm/bNDJjswja2T6k66l9YalbR6rIta hsZQpPgw/TVkHuMrOmKt7HQ2FLD0wqfkSLw7hQjNih98pzhDs6q5agqXSnCA+oZGzWyE zcooXdAcPbqcMfzqSoGCERGPhTvwArwzvUH2KL1KRtcBJu/rrw1MHBJi9J1ZvG4bm+77 VjK+hGb+SgbWZdbHq+6SPHHhZC8ZFVQLG+h37Q13ukIo1jeOwa8/EtIJlrWPMagpTdyu JzZugUYi1deAvz3pZyjeMqwcF38w/huShJy5BJY8rLMWsF7j7goyh27YNpCHSSlE/wKE uVBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PxzPaY/Ogt1rPKPAANV8Wd2TFWVbdj6E5Ss9Pp8cQNg=; b=45w89OwDvuXKqUtm/mJF9XUl+4QUOyQ8pBrBofruxBVihY0Qj2BBVosB9HbuoIumfO EzMDbk2bG1EXinIBadKTAeI+poRiB8UvyAq1ic5W8RBtsG9wn9bn2ZOswd2rUos/SbZW 27a3XpEtDS5iaiDrLjvalB6DeKgRz0iPuOi9dW/rvzZTyyflmdCNwTlVG9Af2Kc8lLL0 alnR2IbSqXRcQ7AMYBRt57uKpOvTSmje1aK3vvzGQy/nRDO7V3LW7USepQSSl0tcUQVJ Q7262IyjzKPj1ls+ixP9ixCPLu9gMADcpzNUjLN0fkweEy1ezy7hYh7288TfFsYeDmft CEkA== X-Gm-Message-State: AOAM532mmdTbfAbqCcihD+2pBG+lgSRu46lqdAJ9/0csL8I2Nmv8eulJ jbVo0LquI0+RYMdIb3Kkp6NBXqq4cSYHgnP0p+Q0CRynXZbf9iMQ X-Google-Smtp-Source: ABdhPJyugFotoz/ZWAjqY7Os/lqvodzDdseHqL8xq7ly0LNTAYP5KPApGsksbiCiYGQk2FO2dZabxJQDypwrvxSvxs8= X-Received: by 2002:a9f:2383:: with SMTP id 3mr8321347uao.77.1639520859567; Tue, 14 Dec 2021 14:27:39 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Tue, 14 Dec 2021 15:27:29 -0700 Message-ID: Subject: TinyBSD to be removed To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000006fc96705d322b2f3" X-Rspamd-Queue-Id: 4JDCgJ37WZz4cH1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=gVPzyWvC; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::930) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::930:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: Y --0000000000006fc96705d322b2f3 Content-Type: text/plain; charset="UTF-8" TinyBSD hasn't been updated in about a decade. The last commits in the google code site were in 2011. The kernel configs are full of removed devices and don't have the required changes from the past 10ish years. I plan on removing it. Please comment on https://reviews.freebsd.org/D33450 . Comments? Warner --0000000000006fc96705d322b2f3-- From nobody Fri Dec 31 21:21:19 2021 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 84586192351B for ; Fri, 31 Dec 2021 21:21:37 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQdPD5tY8z4YJD for ; Fri, 31 Dec 2021 21:21:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f51.google.com with SMTP id i5-20020a05683033e500b0057a369ac614so36698188otu.10 for ; Fri, 31 Dec 2021 13:21:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6DrH5Njm/zsdRrvo56bcqr/IbA/Jh8RQhy6imeXPDjY=; b=uIkJfHxmmQ+MbPMtUruDc1wHLazyPQiGWZUH8zTyic2oPqs9O+S0raiRtp9PnpX5dl +zJnOW4CXOOI+phll+fz5HUh6EapIL51N41z886D3XTThwb0GBgvjaT55ZG+XJpgFxA3 UpXCBLJAgc1iFyXXs8Yrtu2Y+lqp0YemAW9LnaCKuUOE1vStfjvrTkC8gvu1mVrf4JeH n+SJkTWfHan336a29nu8JR7dKLwTywuf5Mw7fO4Bqld68DYo2PHHqdtgUb89wBrpld/g Yoy5MZv3uULIo8QMxbxvWY/cHYxNMYOwlZst3GSRqMT8cxPpGeLQzV8aEF6uULG3jb7Y SoeQ== X-Gm-Message-State: AOAM533AtIbYeBXo07fqKwIGvR8pHWxrcAz2teCjOFXkObw2Z5KzYTi/ yYBbEllPtB2QYF31uudSIyr1ku+xw1JCrQEkWowp7E9humg= X-Google-Smtp-Source: ABdhPJxkOFZbr2fQQiqvAVFGdQMlTmMFKZyY0OWdM6YhQKw2nRrm8crztUxPYQNJtidI0UVdk4U1uPHFd0ubI+ZALQQ= X-Received: by 2002:a9d:554f:: with SMTP id h15mr26908152oti.111.1640985690158; Fri, 31 Dec 2021 13:21:30 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Fri, 31 Dec 2021 14:21:19 -0700 Message-ID: Subject: LGPL code in /usr/tests? To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JQdPD5tY8z4YJD X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.51 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; TO_DOM_EQ_FROM_DOM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.51:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; DMARC_NA(0.00)[freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.51:from]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-ThisMailContainsUnwantedMimeParts: N I recently ran into a bug in fusefs that can only be triggered when NFS exports a FUSE file system. That makes it very difficult to write an automated test. My options are basically: * Add an fhgetdirentries(2) syscall that is like getdirentries, but takes a fhandle_t* argument instead of a file descriptor. * Actually start nfsd during the test, and export the temporary FUSE filesystem. The first option sounds like way too much non-test code to change. Plus, I may need to add thread() and fhwrite() syscalls too, for other NFS-related test cases. The second option would also be a lot of work, but at least the work would all be confined to the test code. However, what would I do once I've exported the file system? Mounting it with the NFS client would add several more layers to the stack under test. I'm not even sure that it's safe to self-mount an exported file system. Another option would be to communicate directly with nfsd from the test code. That's possible, but writing NFS RPCs by hand is very cumbersome, and it would obscure the test logic. A better option is to use libnfs. The API is just what I would need. However, it's licensed under the LGPL 2.1. I know that we as a project decided to import no new GPLish code into contrib/. But this code would never be used outside of /usr/tests, so it wouldn't even affect many production builds. Would that be acceptable? The workarounds are ugly: * Create a new port for all libnfs-dependent tests. This would be hard to maintain, because the content of the tests must be so dependent on the base version of the OS. * Write the tests in Python using libnfs-python. The tests could still be compiled as part of the base system, they just wouldn't work unless libnfs-python is installed from ports. But this is awkward because the tests are currently C++. So I would have to embed a Python interpreter into the C++ code. It would really obfuscate the test logic. * Store the tests in the base system, but detached from the build. Then create a port that builds them by mounting SRC_BASE, much like devel/py-libzfs does. It would then install them in /usr/local/tests. This is probably the least-bad option if I can't import libnfs into contrib/. What do you think? Is it acceptable to import libnfs intro contrib/? It's LGPL, except for a few headers that are BSD and some examples that are GPLv3. But we needn't use the examples, or even import them. https://github.com/sahlberg/libnfs From nobody Mon Jan 3 06:30:36 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 94F511921142 for ; Mon, 3 Jan 2022 06:30:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JS5Tz6NmXz3sd7 for ; Mon, 3 Jan 2022 06:30:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x935.google.com with SMTP id i5so41171207uaq.10 for ; Sun, 02 Jan 2022 22:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gmrkXRFygtZqJA+mQNZ3esGkfvIn+bFHqrTe+Ku2LL0=; b=wwIHzTXx7LhJFUuDBtyoXcDATMvXpb+C4N2KboSHDeGaske7KGGhZlz5xV1+Oqo1pW wFdihDWfXDlFnNKvB9kT2rtyv7VoNyw0iZ4PwpqjwilBUtVJJAjKo6ujOCatfU0JQLNC Q9aCbKP2bBKoSVg22y2BJLuM9HD7ap9MUgbzFpghjKlsWrbu/bjsxrQEnJSuyRK+/qzb g5K2uVZ2SHSXp4r0+txM0zOMRIh4V3pZPLhxmKtivS74wA9PJ7zxzb927KbmpNZZO11q h6tbW6+B+7t2tsrQF3DSpDq+WGgtPvH9TgfGpjnSHo0E72ErsXW6eu1r10GTJkZ9ewzB K0NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gmrkXRFygtZqJA+mQNZ3esGkfvIn+bFHqrTe+Ku2LL0=; b=hBCb2XGE1ZNkYcEmtCC252gHZ6bGyI0gps+2s/2KNuEcLoYNUwVpPxDcSqakVtUGPk imVsPlvhqyhNo2k7RKGvz1RH6oLtXFJD+Ez0VjF88wYEnZHfkMSmHS+RsmkIZeA2Efdi hI/AQ3yrTnATz0rZmOXoqSUY3/XLUQQnEsEs5aRwhkU+MM+dYELHQy9ISwgMK9fNqOGF 8NW2ANhzM8g9/4ZTWIivJTnYKfNMAqhYJbC5vKXGgwQUWoibZQbuitLLzknJx+JWY3HZ erm3SeUZFKXs3zjhNBm7GWzPVQcV7xFXyLKTS3JJHnRSik63GeGOubv1Fi6iETm50KTh u0lQ== X-Gm-Message-State: AOAM532MvO4UmDsL5BeBVPFQQeDt6SuEkiw4iqens8bIyZPUE2xPuN2+ cnuUWKe1iRCWVrOtjIoOK8X6S89cJBhUSvu0IP6M/z2ly8Q= X-Google-Smtp-Source: ABdhPJwxqe+cCT6CusuvLwRczfO0luysJkLTW2yYSYIbmNOa+BB3NPU2PwHdJ/4pFwyDEcXjNyzKoZasEBne2+0uP/g= X-Received: by 2002:a05:6102:da:: with SMTP id u26mr13293062vsp.42.1641191447322; Sun, 02 Jan 2022 22:30:47 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 2 Jan 2022 23:30:36 -0700 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Alan Somers Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000039f6c105d4a7a9ce" X-Rspamd-Queue-Id: 4JS5Tz6NmXz3sd7 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=wwIHzTXx; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::935) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [1.36 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.85)[-0.846]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.21)[0.207]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::935:from]; NEURAL_SPAM_LONG(0.99)[0.995]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000039f6c105d4a7a9ce Content-Type: text/plain; charset="UTF-8" Top posting my reactions (sorry) I think 'in base as a private library, used only in the tests protected by MK_LGPL' is fine. This would keep it in base, keep the testing happening, and allow those who want to omit it. This would also not run afoul of any companies that still have downloading GPL'd software is a fireable offense, since all such policies I heard about years ago were specifically the GPL, not the LGPL). This is of course a trade off between getting something useful from the LGPL software (better testing) and our desires not to have any in the tree at all, if possible. Adding a knob would let it be shut off easily with all the tests disabled that depend on it. This is also in keeping with our historical practices of having software with undesirable licenses as long as it gets us something. I think this is better than the ports options because it will get more use and exposure this way and is more likely to remain working (though with our current CI setup adding it as a dependency for that CI would be easy and give us decent coverage). Warner On Fri, Dec 31, 2021 at 2:22 PM Alan Somers wrote: > I recently ran into a bug in fusefs that can only be triggered when > NFS exports a FUSE file system. That makes it very difficult to write > an automated test. My options are basically: > > * Add an fhgetdirentries(2) syscall that is like getdirentries, but > takes a fhandle_t* argument instead of a file descriptor. > * Actually start nfsd during the test, and export the temporary FUSE > filesystem. > > The first option sounds like way too much non-test code to change. > Plus, I may need to add thread() and fhwrite() syscalls too, for other > NFS-related test cases. The second option would also be a lot of > work, but at least the work would all be confined to the test code. > However, what would I do once I've exported the file system? Mounting > it with the NFS client would add several more layers to the stack > under test. I'm not even sure that it's safe to self-mount an > exported file system. Another option would be to communicate directly > with nfsd from the test code. That's possible, but writing NFS RPCs > by hand is very cumbersome, and it would obscure the test logic. A > better option is to use libnfs. The API is just what I would need. > However, it's licensed under the LGPL 2.1. I know that we as a > project decided to import no new GPLish code into contrib/. But this > code would never be used outside of /usr/tests, so it wouldn't even > affect many production builds. Would that be acceptable? The > workarounds are ugly: > > * Create a new port for all libnfs-dependent tests. This would be > hard to maintain, because the content of the tests must be so > dependent on the base version of the OS. > * Write the tests in Python using libnfs-python. The tests could > still be compiled as part of the base system, they just wouldn't work > unless libnfs-python is installed from ports. But this is awkward > because the tests are currently C++. So I would have to embed a > Python interpreter into the C++ code. It would really obfuscate the > test logic. > * Store the tests in the base system, but detached from the build. > Then create a port that builds them by mounting SRC_BASE, much like > devel/py-libzfs does. It would then install them in /usr/local/tests. > This is probably the least-bad option if I can't import libnfs into > contrib/. > > What do you think? Is it acceptable to import libnfs intro contrib/? > It's LGPL, except for a few headers that are BSD and some examples > that are GPLv3. But we needn't use the examples, or even import them. > > https://github.com/sahlberg/libnfs > > --00000000000039f6c105d4a7a9ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Top posting my reactions (sorry)

=
I think=C2=A0'in base as a private library, used only in the tests= protected by MK_LGPL' is fine.

This would kee= p it in base, keep the testing happening, and allow those who want
to omit it. This would also not run afoul of any companies that still hav= e downloading
GPL'd software is a fireable offense, since all= such policies I heard about years ago
were specifically the GPL,= not the LGPL). This is of course a trade off between
getting som= ething useful from the LGPL software (better testing) and our desires
=
not to have any in the tree at all, if possible. Adding a knob would l= et it be shut
off easily with all the tests disabled that depend = on it. This is also in keeping with
our historical practices of h= aving software with undesirable=C2=A0licenses as long as it
gets = us something.

I think this is better than the port= s options because it will get more use and exposure
this way and = is more likely to remain working (though with our current CI setup
adding it as a dependency for that CI would be easy and give us decent co= verage).

Warner

On Fri, Dec 31, 2021 at 2:22 PM Ala= n Somers <asomers@freebsd.org= > wrote:
I re= cently ran into a bug in fusefs that can only be triggered when
NFS exports a FUSE file system.=C2=A0 That makes it very difficult to write=
an automated test.=C2=A0 My options are basically:

* Add an fhgetdirentries(2) syscall that is like getdirentries, but
takes a fhandle_t* argument instead of a file descriptor.
* Actually start nfsd during the test, and export the temporary FUSE filesy= stem.

The first option sounds like way too much non-test code to change.
Plus, I may need to add thread() and fhwrite() syscalls too, for other
NFS-related test cases.=C2=A0 The second option would also be a lot of
work, but at least the work would all be confined to the test code.
However, what would I do once I've exported the file system?=C2=A0 Moun= ting
it with the NFS client would add several more layers to the stack
under test.=C2=A0 I'm not even sure that it's safe to self-mount an=
exported file system.=C2=A0 Another option would be to communicate directly=
with nfsd from the test code.=C2=A0 That's possible, but writing NFS RP= Cs
by hand is very cumbersome, and it would obscure the test logic.=C2=A0 A better option is to use libnfs.=C2=A0 The API is just what I would need. However, it's licensed under the LGPL 2.1.=C2=A0 I know that we as a project decided to import no new GPLish code into contrib/.=C2=A0 But this<= br> code would never be used outside of /usr/tests, so it wouldn't even
affect many production builds.=C2=A0 Would that be acceptable?=C2=A0 The workarounds are ugly:

* Create a new port for all libnfs-dependent tests.=C2=A0 This would be
hard to maintain, because the content of the tests must be so
dependent on the base version of the OS.
* Write the tests in Python using libnfs-python.=C2=A0 The tests could
still be compiled as part of the base system, they just wouldn't work unless libnfs-python is installed from ports.=C2=A0 But this is awkward
because the tests are currently C++.=C2=A0 So I would have to embed a
Python interpreter into the C++ code.=C2=A0 It would really obfuscate the test logic.
* Store the tests in the base system, but detached from the build.
Then create a port that builds them by mounting SRC_BASE, much like
devel/py-libzfs does.=C2=A0 It would then install them in /usr/local/tests.=
This is probably the least-bad option if I can't import libnfs into
contrib/.

What do you think?=C2=A0 Is it acceptable to import libnfs intro contrib/?<= br> It's LGPL, except for a few headers that are BSD and some examples
that are GPLv3.=C2=A0 But we needn't use the examples, or even import t= hem.

https://github.com/sahlberg/libnfs

--00000000000039f6c105d4a7a9ce-- From nobody Mon Jan 3 07:37:13 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 40F31192C620 for ; Mon, 3 Jan 2022 07:37:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JS6zV0MLPz4T09; Mon, 3 Jan 2022 07:37:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wm1-x334.google.com with SMTP id n10-20020a7bc5ca000000b00345c520d38eso17922586wmk.1; Sun, 02 Jan 2022 23:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tRT+Z1E4vD6PjbyOdutkFa8Ibg3UEMaJ9r3IJojqqzs=; b=egJKE95Gmay2Ed2LPsoAfXCNGmcQ6d/BgVHfcEMVZLkxJOxZBvx16UXb2G73PeDP32 sirL56bZtVxInH5GgHrJzhcVf3vKO+8Xjsz3idUrsJiToTiLknTODIdFaSV/JkXUy9wG EhcaeBIYmlnOGZUYOqR2z7QdMDzQQbiAP29AbLP3PWhtmBR0e7edDOpq+BTgdMT+XVWJ 7OcmLY6+lxbn+aO11H7JTHNWX8uUGWQrs04TfrTthn+cwHHHDzK2Lqv1ZLAVivR3kDo7 L8LHlZrueB0fLfHbe+p5jqTna+9aE51tHsujD4o+TW9PPiyqIfN7r4ussIAi7wM20NDn B9Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tRT+Z1E4vD6PjbyOdutkFa8Ibg3UEMaJ9r3IJojqqzs=; b=Kgnr6Ro6f7RIFL35jCta/6VmvPczW5GIJb6+BqwCRq4dM2wDVKg8eM6Y8HcmiogYfS wTCS95jMMJegmt5ijCB1aetz8aTL/hq0dhIAKo1Meh9A/YR1effvMoxyMcJuQSr5kDDG /liB3NkMOSNUF3aYaY+wg+cgqN0zN7G2I40Xe52iISo8H/+uoPNIZW6GOqAGxf6xI5tg ky9yrVl7I9+M3xiuh5zekIbtoZBtVhJWP0GyKqdxNMf2EJ0DAmStogkoPHeEbJNrnWsl VrnqwuFM87m+iBOXvVaEqvqNSGIeEvRyatmrjLkN5NbIsFmaA4HLwMZP6Qg3tt+frvf6 t4uA== X-Gm-Message-State: AOAM533cpZ7L50swJM7nvlg7TQtCISpBmrJMy0A0XXJEvPK2rXlM1OPy LBeMU1gT6eGWi9Ui846UISe4v0xjFOWUE5uSBsucxVTb62rs0w== X-Google-Smtp-Source: ABdhPJwtXmasIOVZd0ceQoR8y9sSZrOv7Wrq1JcR1kyiHsY0eemqwN1tX3lRzJ8uQz1Uo56envDHWtx+G2cAvv9KCdA= X-Received: by 2002:a05:600c:3c9b:: with SMTP id bg27mr37610829wmb.163.1641195469843; Sun, 02 Jan 2022 23:37:49 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Mon, 3 Jan 2022 10:37:13 +0300 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Warner Losh Cc: Alan Somers , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000fcb10105d4a898a6" X-Rspamd-Queue-Id: 4JS6zV0MLPz4T09 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --000000000000fcb10105d4a898a6 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 9:31 AM Warner Losh wrote: > Top posting my reactions (sorry) > > I think 'in base as a private library, used only in the tests protected by > MK_LGPL' is fine. > > This would keep it in base, keep the testing happening, and allow those > who want > to omit it. This would also not run afoul of any companies that still have > downloading > GPL'd software is a fireable offense, since all such policies I heard > about years ago > were specifically the GPL, not the LGPL). This is of course a trade off > between > getting something useful from the LGPL software (better testing) and our > desires > not to have any in the tree at all, if possible. Adding a knob would let > it be shut > off easily with all the tests disabled that depend on it. This is also in > keeping with > our historical practices of having software with undesirable licenses as > long as it > gets us something. > > I think this is better than the ports options because it will get more use > and exposure > this way and is more likely to remain working (though with our current CI > setup > adding it as a dependency for that CI would be easy and give us decent > coverage). > > Warner > > https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License GNU Lesser General Public License https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft Strong and weak copyleft "GNU Lesser General Public License" is a WEAK copyleft license ( it may be considered "benign" : it does not invade the user software , affects only the modifications to the LGPL licensed software ) , in spite of this , "GNU General Public License" is a STRONG copyleft license ( it may be considered "malignant" : it invades the user software as a whole ) . Using a ( LGPL licensed software ) for testing another software is not directly involved in the tested software . To eliminate possible doubts , if I were the decision maker about how to use it , I would make it a port , and fetch it during testing as a dynamically loaded library ( manage it port with respect to its license ) . Mehmet Erol Sanliturk > On Fri, Dec 31, 2021 at 2:22 PM Alan Somers wrote: > >> I recently ran into a bug in fusefs that can only be triggered when >> NFS exports a FUSE file system. That makes it very difficult to write >> an automated test. My options are basically: >> >> * Add an fhgetdirentries(2) syscall that is like getdirentries, but >> takes a fhandle_t* argument instead of a file descriptor. >> * Actually start nfsd during the test, and export the temporary FUSE >> filesystem. >> >> The first option sounds like way too much non-test code to change. >> Plus, I may need to add thread() and fhwrite() syscalls too, for other >> NFS-related test cases. The second option would also be a lot of >> work, but at least the work would all be confined to the test code. >> However, what would I do once I've exported the file system? Mounting >> it with the NFS client would add several more layers to the stack >> under test. I'm not even sure that it's safe to self-mount an >> exported file system. Another option would be to communicate directly >> with nfsd from the test code. That's possible, but writing NFS RPCs >> by hand is very cumbersome, and it would obscure the test logic. A >> better option is to use libnfs. The API is just what I would need. >> However, it's licensed under the LGPL 2.1. I know that we as a >> project decided to import no new GPLish code into contrib/. But this >> code would never be used outside of /usr/tests, so it wouldn't even >> affect many production builds. Would that be acceptable? The >> workarounds are ugly: >> >> * Create a new port for all libnfs-dependent tests. This would be >> hard to maintain, because the content of the tests must be so >> dependent on the base version of the OS. >> * Write the tests in Python using libnfs-python. The tests could >> still be compiled as part of the base system, they just wouldn't work >> unless libnfs-python is installed from ports. But this is awkward >> because the tests are currently C++. So I would have to embed a >> Python interpreter into the C++ code. It would really obfuscate the >> test logic. >> * Store the tests in the base system, but detached from the build. >> Then create a port that builds them by mounting SRC_BASE, much like >> devel/py-libzfs does. It would then install them in /usr/local/tests. >> This is probably the least-bad option if I can't import libnfs into >> contrib/. >> >> What do you think? Is it acceptable to import libnfs intro contrib/? >> It's LGPL, except for a few headers that are BSD and some examples >> that are GPLv3. But we needn't use the examples, or even import them. >> >> https://github.com/sahlberg/libnfs >> >> --000000000000fcb10105d4a898a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 3, 2022 = at 9:31 AM Warner Losh <imp@bsdimp.com= > wrote:
=
Top posting my reactions (sorry)

=
I think=C2=A0'in base as a private library, used only in the tests= protected by MK_LGPL' is fine.

This would kee= p it in base, keep the testing happening, and allow those who want
to omit it. This would also not run afoul of any companies that still hav= e downloading
GPL'd software is a fireable offense, since all= such policies I heard about years ago
were specifically the GPL,= not the LGPL). This is of course a trade off between
getting som= ething useful from the LGPL software (better testing) and our desires
=
not to have any in the tree at all, if possible. Adding a knob would l= et it be shut
off easily with all the tests disabled that depend = on it. This is also in keeping with
our historical practices of h= aving software with undesirable=C2=A0licenses as long as it
gets = us something.

I think this is better than the port= s options because it will get more use and exposure
this way and = is more likely to remain working (though with our current CI setup
adding it as a dependency for that CI would be easy and give us decent co= verage).

Warner

<= br>


GNU Lesser General Public L= icense

Strong and weak copyleft
<= div>

"GNU Lesser Genera= l Public License" is a=C2=A0 WEAK copyleft license ( it may= be considered "benign" : it does not invade the user software , = affects only the modifications to the LGPL licensed software ) ,

in spite of this ,<= br>

"GNU = General Public License" is a STRONG copyleft license ( it may be consi= dered "malignant" : it invades the user software as a whole ) .


Using a ( LGPL = licensed software ) for testing another software is not directly involved i= n the tested software .

To elimin= ate possible doubts , if I were the decision maker about how to use it , I = would make it a port , and fetch it during testing as a dynamically loaded = library ( manage it port with respect to its license ) .

Mehmet=C2=A0 Erol Sanliturk



=C2=A0
=
On Fri, Dec 31, 20= 21 at 2:22 PM Alan Somers <asomers@freebsd.org> wrote:
I recently ran into a bug in fusefs that c= an only be triggered when
NFS exports a FUSE file system.=C2=A0 That makes it very difficult to write=
an automated test.=C2=A0 My options are basically:

* Add an fhgetdirentries(2) syscall that is like getdirentries, but
takes a fhandle_t* argument instead of a file descriptor.
* Actually start nfsd during the test, and export the temporary FUSE filesy= stem.

The first option sounds like way too much non-test code to change.
Plus, I may need to add thread() and fhwrite() syscalls too, for other
NFS-related test cases.=C2=A0 The second option would also be a lot of
work, but at least the work would all be confined to the test code.
However, what would I do once I've exported the file system?=C2=A0 Moun= ting
it with the NFS client would add several more layers to the stack
under test.=C2=A0 I'm not even sure that it's safe to self-mount an=
exported file system.=C2=A0 Another option would be to communicate directly=
with nfsd from the test code.=C2=A0 That's possible, but writing NFS RP= Cs
by hand is very cumbersome, and it would obscure the test logic.=C2=A0 A better option is to use libnfs.=C2=A0 The API is just what I would need. However, it's licensed under the LGPL 2.1.=C2=A0 I know that we as a project decided to import no new GPLish code into contrib/.=C2=A0 But this<= br> code would never be used outside of /usr/tests, so it wouldn't even
affect many production builds.=C2=A0 Would that be acceptable?=C2=A0 The workarounds are ugly:

* Create a new port for all libnfs-dependent tests.=C2=A0 This would be
hard to maintain, because the content of the tests must be so
dependent on the base version of the OS.
* Write the tests in Python using libnfs-python.=C2=A0 The tests could
still be compiled as part of the base system, they just wouldn't work unless libnfs-python is installed from ports.=C2=A0 But this is awkward
because the tests are currently C++.=C2=A0 So I would have to embed a
Python interpreter into the C++ code.=C2=A0 It would really obfuscate the test logic.
* Store the tests in the base system, but detached from the build.
Then create a port that builds them by mounting SRC_BASE, much like
devel/py-libzfs does.=C2=A0 It would then install them in /usr/local/tests.=
This is probably the least-bad option if I can't import libnfs into
contrib/.

What do you think?=C2=A0 Is it acceptable to import libnfs intro contrib/?<= br> It's LGPL, except for a few headers that are BSD and some examples
that are GPLv3.=C2=A0 But we needn't use the examples, or even import t= hem.

https://github.com/sahlberg/libnfs

--000000000000fcb10105d4a898a6-- From nobody Mon Jan 3 14:47:42 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6FA3F1933F3F for ; Mon, 3 Jan 2022 14:48:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSJWj2g9Bz3pC9 for ; Mon, 3 Jan 2022 14:48:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f169.google.com with SMTP id w80so16827633oie.9 for ; Mon, 03 Jan 2022 06:48:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k+OxMAnRRM/2K+ajJAatU7ptb76GJHe0O0AjOs7SCos=; b=HlDySeXEEo6T+2fDuWgg7E/1T6P30qtSlXO7jgnzTjevfGUhM74i4uG7wjfGbCgzv2 U9ob0SspoUpdy7XkGx9J0OL3e5ho5wnRe0fst/NJydQX6Uux2suDaNztgXsLKx9sAwuh qA55XhvP4jTGr2tjiI+0mvJe6Q9liQvWCKeaGm/mFTfjbHsGdm/ZSAU6aNinN4qOJ3hS eSLIwTr85JNk6hpM/VaUnQO+ovssqPdtkiFdvALN+Ow/YzwhOz4U9qf0aXuRNm+N4WiR fVaip9zVkXQPMKlKifQa5KiY4GMtyJFZ41FA5REavOg3nwW6yz5QjWpnOXiLvHWaQEoX Jn3Q== X-Gm-Message-State: AOAM530seGulItH9SN4Jm9JgflFnAuuK0r/icKb86KX/5i2ubDvil7MC z/B0hMo4j7HSvYPMsLoLeNoNnZ9V4LkD2YMG8NA= X-Google-Smtp-Source: ABdhPJw5ppq4hFqc9y2fpKDkotjopYZ+tmYLOGNIitifZkbALNxvsA5DyLrvDvgrqOFgkLD7SfCJ2CaTpdT3ieZxbXU= X-Received: by 2002:aca:1001:: with SMTP id 1mr35418685oiq.55.1641221273913; Mon, 03 Jan 2022 06:47:53 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Mon, 3 Jan 2022 07:47:42 -0700 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Mehmet Erol Sanliturk Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JSJWj2g9Bz3pC9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk wrote: > > > > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh wrote: >> >> Top posting my reactions (sorry) >> >> I think 'in base as a private library, used only in the tests protected by MK_LGPL' is fine. >> >> This would keep it in base, keep the testing happening, and allow those who want >> to omit it. This would also not run afoul of any companies that still have downloading >> GPL'd software is a fireable offense, since all such policies I heard about years ago >> were specifically the GPL, not the LGPL). This is of course a trade off between >> getting something useful from the LGPL software (better testing) and our desires >> not to have any in the tree at all, if possible. Adding a knob would let it be shut >> off easily with all the tests disabled that depend on it. This is also in keeping with >> our historical practices of having software with undesirable licenses as long as it >> gets us something. >> >> I think this is better than the ports options because it will get more use and exposure >> this way and is more likely to remain working (though with our current CI setup >> adding it as a dependency for that CI would be easy and give us decent coverage). >> >> Warner >> > > > > https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License > GNU Lesser General Public License > > https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft > Strong and weak copyleft > > > "GNU Lesser General Public License" is a WEAK copyleft license ( it may be considered "benign" : it does not invade the user software , affects only the modifications to the LGPL licensed software ) , > > in spite of this , > > "GNU General Public License" is a STRONG copyleft license ( it may be considered "malignant" : it invades the user software as a whole ) . > > > Using a ( LGPL licensed software ) for testing another software is not directly involved in the tested software . > > To eliminate possible doubts , if I were the decision maker about how to use it , I would make it a port , and fetch it during testing as a dynamically loaded library ( manage it port with respect to its license ) . > > > Mehmet Erol Sanliturk The problem is that the library, not just the headers, needs to be present at compile time. Or do you know a good workaround? > > > > >> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers wrote: >>> >>> I recently ran into a bug in fusefs that can only be triggered when >>> NFS exports a FUSE file system. That makes it very difficult to write >>> an automated test. My options are basically: >>> >>> * Add an fhgetdirentries(2) syscall that is like getdirentries, but >>> takes a fhandle_t* argument instead of a file descriptor. >>> * Actually start nfsd during the test, and export the temporary FUSE filesystem. >>> >>> The first option sounds like way too much non-test code to change. >>> Plus, I may need to add thread() and fhwrite() syscalls too, for other >>> NFS-related test cases. The second option would also be a lot of >>> work, but at least the work would all be confined to the test code. >>> However, what would I do once I've exported the file system? Mounting >>> it with the NFS client would add several more layers to the stack >>> under test. I'm not even sure that it's safe to self-mount an >>> exported file system. Another option would be to communicate directly >>> with nfsd from the test code. That's possible, but writing NFS RPCs >>> by hand is very cumbersome, and it would obscure the test logic. A >>> better option is to use libnfs. The API is just what I would need. >>> However, it's licensed under the LGPL 2.1. I know that we as a >>> project decided to import no new GPLish code into contrib/. But this >>> code would never be used outside of /usr/tests, so it wouldn't even >>> affect many production builds. Would that be acceptable? The >>> workarounds are ugly: >>> >>> * Create a new port for all libnfs-dependent tests. This would be >>> hard to maintain, because the content of the tests must be so >>> dependent on the base version of the OS. >>> * Write the tests in Python using libnfs-python. The tests could >>> still be compiled as part of the base system, they just wouldn't work >>> unless libnfs-python is installed from ports. But this is awkward >>> because the tests are currently C++. So I would have to embed a >>> Python interpreter into the C++ code. It would really obfuscate the >>> test logic. >>> * Store the tests in the base system, but detached from the build. >>> Then create a port that builds them by mounting SRC_BASE, much like >>> devel/py-libzfs does. It would then install them in /usr/local/tests. >>> This is probably the least-bad option if I can't import libnfs into >>> contrib/. >>> >>> What do you think? Is it acceptable to import libnfs intro contrib/? >>> It's LGPL, except for a few headers that are BSD and some examples >>> that are GPLv3. But we needn't use the examples, or even import them. >>> >>> https://github.com/sahlberg/libnfs >>> From nobody Mon Jan 3 16:31:33 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1B54B192CBD9 for ; Mon, 3 Jan 2022 16:32:17 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450: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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSLr072Xrz4dhL; Mon, 3 Jan 2022 16:32:16 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id e5so70905262wrc.5; Mon, 03 Jan 2022 08:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BQNp3/2TXyENqM2dC4UESQSRS9aXm2h5uOgqb5CaV2I=; b=BWsKSYJKM53QUo7E4dHFbtwkOpRWS/GV7egtKH30WgdfKzkbgCxl4d68xlcU2F9JEA qgmQ/5H2afupUOGVSCYU41dsUNAILyhgmTuapivdHmR0FlL8ZG0SKBYmEDrJRJnPBLS3 BYKXdUqKrii3zc9fGXTXuiqhZjOra06ML83CsXwduqGfcG/xfCRspbq61pCBNzMctGmf aRUyp7tupJNBw8wI50bP4XkBWbJ3tGyzYvs9W77qWz98EcXy8zyIRee9rguo1Lwxwjpr MmNlT3yAXkMCSTmEjtaMwwuwSPhJH7FkHxH++CPXhzfOyPZ8HyViKYiYmVzOv6WhOoDp e/xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BQNp3/2TXyENqM2dC4UESQSRS9aXm2h5uOgqb5CaV2I=; b=jMK1o6lCmMVXGucawf9HTYJzdfdBU8bRnH+yWqGUqIXKVHrQiJSymN1wH7Vz4NS7bQ T1JF+n1KdZc47XVjbORqrSesc3gLOdDL6HVW0KHU81NcAaR9OhXwZrHdgjLAqe3bUJt5 X4fZtsO0eUfjlpJgnhtyOOOGGnCR8u/cz5xkgtiGdiLq7WL1A8rqytLEosDzx5n/ux3m CKFVCh5lWGNoLQGke3jOuZVAq1ZWrB8d35crpo6joyOioZYVPsMf+gxF1F91RbYer1FV m10/RF7W1Jq6aTao6RTBUMWKmVoFQ/pgjtZC354uUQlseeaQ24K1yYim34veyAc3nXdz A2Og== X-Gm-Message-State: AOAM5324sy7Oxsklqm73wy7CjocXUAl1EBq6zbD+WeIsYaqtojc2OgVp LYWFWz8WmH50dmYTEPA5ryvlX4fMviBlJhI5q2TP7gQaYnSkZw== X-Google-Smtp-Source: ABdhPJyA0Sw9s5CgS5IWjfDyOCni9Pi6IbG+OaVk4W1TDxQ2A3l2+WT26DYgiu3VgSqpApHL/VtQeGloMCIReNpZmv4= X-Received: by 2002:a5d:44ce:: with SMTP id z14mr38817478wrr.383.1641227530161; Mon, 03 Jan 2022 08:32:10 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Mon, 3 Jan 2022 19:31:33 +0300 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Alan Somers Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000ee500205d4b00f39" X-Rspamd-Queue-Id: 4JSLr072Xrz4dhL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --000000000000ee500205d4b00f39 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 5:47 PM Alan Somers wrote: > On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk > wrote: > > > > > > > > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh wrote: > >> > >> Top posting my reactions (sorry) > >> > >> I think 'in base as a private library, used only in the tests protected > by MK_LGPL' is fine. > >> > >> This would keep it in base, keep the testing happening, and allow those > who want > >> to omit it. This would also not run afoul of any companies that still > have downloading > >> GPL'd software is a fireable offense, since all such policies I heard > about years ago > >> were specifically the GPL, not the LGPL). This is of course a trade off > between > >> getting something useful from the LGPL software (better testing) and > our desires > >> not to have any in the tree at all, if possible. Adding a knob would > let it be shut > >> off easily with all the tests disabled that depend on it. This is also > in keeping with > >> our historical practices of having software with undesirable licenses > as long as it > >> gets us something. > >> > >> I think this is better than the ports options because it will get more > use and exposure > >> this way and is more likely to remain working (though with our current > CI setup > >> adding it as a dependency for that CI would be easy and give us decent > coverage). > >> > >> Warner > >> > > > > > > > > https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License > > GNU Lesser General Public License > > > > https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft > > Strong and weak copyleft > > > > > > "GNU Lesser General Public License" is a WEAK copyleft license ( it may > be considered "benign" : it does not invade the user software , affects > only the modifications to the LGPL licensed software ) , > > > > in spite of this , > > > > "GNU General Public License" is a STRONG copyleft license ( it may be > considered "malignant" : it invades the user software as a whole ) . > > > > > > Using a ( LGPL licensed software ) for testing another software is not > directly involved in the tested software . > > > > To eliminate possible doubts , if I were the decision maker about how to > use it , I would make it a port , and fetch it during testing as a > dynamically loaded library ( manage it port with respect to its license ) . > > > > > > Mehmet Erol Sanliturk > > > The problem is that the library, not just the headers, needs to be > present at compile time. Or do you know a good workaround? > You can fetch the LGPL licensed sources during compile time from outside of the FreeBSD base known to the testing program . The user(s) of FreeBSD can also use a similar facility . For example : I am developing mainly two programs : (1) Mathematical Analysis computations (2) A Multi-media information management system These programs are using parts taken from legally personally usable sources which can not be used for a ( free or commercial ) distribution . During program development , it is possible to use them , because they are in there just as a filler for not-implemented-yet parts . To prevent unacceptable inclusion of such sources into my own productions , I am using global directories outside of the program directories : /KBMS/Parts_to_ be_Removed/... ( Part specific directories ) /MAS/Parts_to_ be_Removed/... ( Part specific directories ) It is explicitly known that these directories and their contents can not be used . There is no danger of including them erroneously . You can define such directories . During compilation you may fetch LGPL licensed parts from these directories ( even though they may be on the Internet ) . After compilation of the programs ( and if they are executed ) you may discard them . By supplying a script to manage such issues , users of the FreeBSD may also use the associated external directories created in their systems and used during their works . The main problem for the LGPL licensed sources is the modifications performed in them . If there are such parts they should be open sourced , not the sources of the user sources . The closed source programs will not be affected from such modifications . Some closed source program developers may not want to handle legal implications of these modified or not modified LGPL licensed parts even when they are distributed because any failure of distribution of especially modified sources may cause significant trouble for them . To eliminate such distribution related concerns , the best action may be to store these sources into a publicly accessible repository , modify these sources in that repository and use them from this repository . In this case , modifications in the main repository and excluding of these from FreeBSD distributions will not affect FreeBSD users other than fetching them when they are needed , which is legally acceptable and harmless . Generation of a package or port from this repository may be necessary or not , I will not be able to say anything because I do not know . The port or package generator persons would know such points . My opinion is that the above model may not require either a port or a package separately because everything necessary will be in the repository . Mehmet Erol Sanliturk > > > > > > > > > > >> > >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers > wrote: > >>> > >>> I recently ran into a bug in fusefs that can only be triggered when > >>> NFS exports a FUSE file system. That makes it very difficult to write > >>> an automated test. My options are basically: > >>> > >>> * Add an fhgetdirentries(2) syscall that is like getdirentries, but > >>> takes a fhandle_t* argument instead of a file descriptor. > >>> * Actually start nfsd during the test, and export the temporary FUSE > filesystem. > >>> > >>> The first option sounds like way too much non-test code to change. > >>> Plus, I may need to add thread() and fhwrite() syscalls too, for other > >>> NFS-related test cases. The second option would also be a lot of > >>> work, but at least the work would all be confined to the test code. > >>> However, what would I do once I've exported the file system? Mounting > >>> it with the NFS client would add several more layers to the stack > >>> under test. I'm not even sure that it's safe to self-mount an > >>> exported file system. Another option would be to communicate directly > >>> with nfsd from the test code. That's possible, but writing NFS RPCs > >>> by hand is very cumbersome, and it would obscure the test logic. A > >>> better option is to use libnfs. The API is just what I would need. > >>> However, it's licensed under the LGPL 2.1. I know that we as a > >>> project decided to import no new GPLish code into contrib/. But this > >>> code would never be used outside of /usr/tests, so it wouldn't even > >>> affect many production builds. Would that be acceptable? The > >>> workarounds are ugly: > >>> > >>> * Create a new port for all libnfs-dependent tests. This would be > >>> hard to maintain, because the content of the tests must be so > >>> dependent on the base version of the OS. > >>> * Write the tests in Python using libnfs-python. The tests could > >>> still be compiled as part of the base system, they just wouldn't work > >>> unless libnfs-python is installed from ports. But this is awkward > >>> because the tests are currently C++. So I would have to embed a > >>> Python interpreter into the C++ code. It would really obfuscate the > >>> test logic. > >>> * Store the tests in the base system, but detached from the build. > >>> Then create a port that builds them by mounting SRC_BASE, much like > >>> devel/py-libzfs does. It would then install them in /usr/local/tests. > >>> This is probably the least-bad option if I can't import libnfs into > >>> contrib/. > >>> > >>> What do you think? Is it acceptable to import libnfs intro contrib/? > >>> It's LGPL, except for a few headers that are BSD and some examples > >>> that are GPLv3. But we needn't use the examples, or even import them. > >>> > >>> https://github.com/sahlberg/libnfs > >>> > --000000000000ee500205d4b00f39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 3, 2022 = at 5:47 PM Alan Somers <asomers@f= reebsd.org> wrote:
On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk
<m.e.sanlit= urk@gmail.com> wrote:
>
>
>
> On Mon, Jan 3, 2022 at 9:31 AM Warner Losh <imp@bsdimp.com> wrote:
>>
>> Top posting my reactions (sorry)
>>
>> I think 'in base as a private library, used only in the tests = protected by MK_LGPL' is fine.
>>
>> This would keep it in base, keep the testing happening, and allow = those who want
>> to omit it. This would also not run afoul of any companies that st= ill have downloading
>> GPL'd software is a fireable offense, since all such policies = I heard about years ago
>> were specifically the GPL, not the LGPL). This is of course a trad= e off between
>> getting something useful from the LGPL software (better testing) a= nd our desires
>> not to have any in the tree at all, if possible. Adding a knob wou= ld let it be shut
>> off easily with all the tests disabled that depend on it. This is = also in keeping with
>> our historical practices of having software with undesirable licen= ses as long as it
>> gets us something.
>>
>> I think this is better than the ports options because it will get = more use and exposure
>> this way and is more likely to remain working (though with our cur= rent CI setup
>> adding it as a dependency for that CI would be easy and give us de= cent coverage).
>>
>> Warner
>>
>
>
>
> https://en.wikipedia.org/wiki/GN= U_Lesser_General_Public_License
> GNU Lesser General Public License
>
> https://en.wikipedia.org/wiki/Co= pyleft#Strong_and_weak_copyleft
> Strong and weak copyleft
>
>
> "GNU Lesser General Public License" is a=C2=A0 WEAK copyleft= license ( it may be considered "benign" : it does not invade the= user software , affects only the modifications to the LGPL licensed softwa= re ) ,
>
> in spite of this ,
>
> "GNU General Public License" is a STRONG copyleft license ( = it may be considered "malignant" : it invades the user software a= s a whole ) .
>
>
> Using a ( LGPL licensed software ) for testing another software is not= directly involved in the tested software .
>
> To eliminate possible doubts , if I were the decision maker about how = to use it , I would make it a port , and fetch it during testing as a dynam= ically loaded library ( manage it port with respect to its license ) .
>
>
> Mehmet=C2=A0 Erol Sanliturk





=C2=A0
The problem is that the library, not just the headers, needs to be
present at compile time.=C2=A0 Or do you know a good workaround?



You can f= etch the LGPL licensed sources during compile time from outside of the Free= BSD
base known to the testing program . The user(s) of=C2=A0= FreeBSD can also use a similar facility .

For example :

I am developing mainly = two programs :

(1) Mathematical Analysis= computations
(2) A Multi-media information management = system

These programs are using parts ta= ken from legally personally usable sources=C2=A0 which
= can not be used for a ( free or commercial ) distribution . During program = development ,
it is possible to use them , because they= are in there just as a filler for=C2=A0 not-implemented-yet parts .

To prevent unacceptable inclusion of such = sources into my own productions , I am
using global director= ies=C2=A0 outside of the program directories :

/KBMS/Parts_to_ be_Removed/... ( Part specific directories )
/MAS/Parts_to_ be_Removed/... ( Part specific directories )

It is explicitly known that these directori= es and their contents can not be used .
There is no danger o= f including them erroneously .


You can define such directories . During compilation you may fet= ch LGPL licensed
parts from these directories ( even th= ough they may be on the Internet ) . After compilation of
= the programs ( and if they are executed ) you may discard them . By supplyi= ng a script to manage such issues , users of the FreeBSD may also use the a= ssociated external directories created in their systems and used during the= ir works .


The = main problem for the LGPL licensed sources is the modifications performed <= br>
in them . If there are such parts they should be open so= urced , not the sources of the
user sources . The closed sou= rce programs will not be affected from such modifications .
=
Some closed source program developers may not want to h= andle legal implications of
these modified or not modified L= GPL licensed parts even when they are distributed=C2=A0 because any failure= of distribution of especially modified sources may cause significant troub= le for them . To eliminate such distribution related concerns , the best ac= tion may be to store
these sources into a publicly acce= ssible repository , modify these sources in that repository and use them=C2= =A0 from this repository . In this case , modifications in the main reposit= ory and excluding of these from FreeBSD distributions will not affect FreeB= SD users other than fetching them when they are needed , which is legally a= cceptable and harmless .

Generation of a= package or port from this repository=C2=A0 may be necessary or not ,
<= /div>
I will not be able to say anything because I do not know . T= he port or package
generator persons would know such po= ints . My opinion is that the above model
may not requi= re either a port or a package separately because=C2=A0 everything necessary=
will be in the repository .



Mehmet Erol Sanliturk<= br>



= =C2=A0

>
>
>
>
>>
>> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers <asomers@freebsd.org> wrote: >>>
>>> I recently ran into a bug in fusefs that can only be triggered= when
>>> NFS exports a FUSE file system.=C2=A0 That makes it very diffi= cult to write
>>> an automated test.=C2=A0 My options are basically:
>>>
>>> * Add an fhgetdirentries(2) syscall that is like getdirentries= , but
>>> takes a fhandle_t* argument instead of a file descriptor.
>>> * Actually start nfsd during the test, and export the temporar= y FUSE filesystem.
>>>
>>> The first option sounds like way too much non-test code to cha= nge.
>>> Plus, I may need to add thread() and fhwrite() syscalls too, f= or other
>>> NFS-related test cases.=C2=A0 The second option would also be = a lot of
>>> work, but at least the work would all be confined to the test = code.
>>> However, what would I do once I've exported the file syste= m?=C2=A0 Mounting
>>> it with the NFS client would add several more layers to the st= ack
>>> under test.=C2=A0 I'm not even sure that it's safe to = self-mount an
>>> exported file system.=C2=A0 Another option would be to communi= cate directly
>>> with nfsd from the test code.=C2=A0 That's possible, but w= riting NFS RPCs
>>> by hand is very cumbersome, and it would obscure the test logi= c.=C2=A0 A
>>> better option is to use libnfs.=C2=A0 The API is just what I w= ould need.
>>> However, it's licensed under the LGPL 2.1.=C2=A0 I know th= at we as a
>>> project decided to import no new GPLish code into contrib/.=C2= =A0 But this
>>> code would never be used outside of /usr/tests, so it wouldn&#= 39;t even
>>> affect many production builds.=C2=A0 Would that be acceptable?= =C2=A0 The
>>> workarounds are ugly:
>>>
>>> * Create a new port for all libnfs-dependent tests.=C2=A0 This= would be
>>> hard to maintain, because the content of the tests must be so<= br> >>> dependent on the base version of the OS.
>>> * Write the tests in Python using libnfs-python.=C2=A0 The tes= ts could
>>> still be compiled as part of the base system, they just wouldn= 't work
>>> unless libnfs-python is installed from ports.=C2=A0 But this i= s awkward
>>> because the tests are currently C++.=C2=A0 So I would have to = embed a
>>> Python interpreter into the C++ code.=C2=A0 It would really ob= fuscate the
>>> test logic.
>>> * Store the tests in the base system, but detached from the bu= ild.
>>> Then create a port that builds them by mounting SRC_BASE, much= like
>>> devel/py-libzfs does.=C2=A0 It would then install them in /usr= /local/tests.
>>> This is probably the least-bad option if I can't import li= bnfs into
>>> contrib/.
>>>
>>> What do you think?=C2=A0 Is it acceptable to import libnfs int= ro contrib/?
>>> It's LGPL, except for a few headers that are BSD and some = examples
>>> that are GPLv3.=C2=A0 But we needn't use the examples, or = even import them.
>>>
>>> https://github.com/sahlberg/libnfs
>>>
--000000000000ee500205d4b00f39-- From nobody Mon Jan 3 16:56:49 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EE8B419321A3 for ; Mon, 3 Jan 2022 16:57:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSMNg6F3wz4j3P for ; Mon, 3 Jan 2022 16:57:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f47.google.com with SMTP id w19-20020a056830061300b0058f1dd48932so43764550oti.11 for ; Mon, 03 Jan 2022 08:57:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OLTkNO3h6bZQbupevbaL4l4yKokfB74b2E6JIjXyoS4=; b=j+jzP43TXFiIFpnBWs7t78w9vnjLHWGl8S+d2oCLnBvJAM1tY2VWOqltrSq0aHH+gh JHSNcFrGdxiCdtGLXmiZ/zeE+/jdXz3ByKqlHvlxQWp2RAUjs3pqYA9p+i/yvoeIQVCz wtqCy2IJkZ1YNmMTgMvzW6ZxdJtjba2sNBeVjnTTOJDwqZ2HR7SfQBDogK14DufwunkE URvKhpJjFL1rD9yj7EmP/SSShNxpaodVu6CQNC4aBVjG1TOJVrRMCn86JILoN0jxd9wO vsjVd5iYHnBTJGVUkTsVW5JK0Ew1/AxiTMky1AkyfkkrtfE5foJ9nOyMF9Lvc+TARjUW uMBg== X-Gm-Message-State: AOAM531NPzhwTV8gqmzxWaJz+iiZZETdNmw6qRiPJ0zAxLHRDjcHsDhZ e+NKOf56lbFVb2aby1u5EATm56IfopFRBmBoI36KZnP2 X-Google-Smtp-Source: ABdhPJxX8Q7haapwWPQ0iQ4VI+PCDMI0znKB2D//Z/u4Hd6ORH98BttpC+MZvdo3L67x0yaSj3IruQShK7fg9fWHsbQ= X-Received: by 2002:a9d:554f:: with SMTP id h15mr34388717oti.111.1641229020914; Mon, 03 Jan 2022 08:57:00 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Mon, 3 Jan 2022 09:56:49 -0700 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Mehmet Erol Sanliturk Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JSMNg6F3wz4j3P X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk wrote: > > > > On Mon, Jan 3, 2022 at 5:47 PM Alan Somers wrote: >> >> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk >> wrote: >> > >> > >> > >> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh wrote: >> >> >> >> Top posting my reactions (sorry) >> >> >> >> I think 'in base as a private library, used only in the tests protect= ed by MK_LGPL' is fine. >> >> >> >> This would keep it in base, keep the testing happening, and allow tho= se who want >> >> to omit it. This would also not run afoul of any companies that still= have downloading >> >> GPL'd software is a fireable offense, since all such policies I heard= about years ago >> >> were specifically the GPL, not the LGPL). This is of course a trade o= ff between >> >> getting something useful from the LGPL software (better testing) and = our desires >> >> not to have any in the tree at all, if possible. Adding a knob would = let it be shut >> >> off easily with all the tests disabled that depend on it. This is als= o in keeping with >> >> our historical practices of having software with undesirable licenses= as long as it >> >> gets us something. >> >> >> >> I think this is better than the ports options because it will get mor= e use and exposure >> >> this way and is more likely to remain working (though with our curren= t CI setup >> >> adding it as a dependency for that CI would be easy and give us decen= t coverage). >> >> >> >> Warner >> >> >> > >> > >> > >> > https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License >> > GNU Lesser General Public License >> > >> > https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft >> > Strong and weak copyleft >> > >> > >> > "GNU Lesser General Public License" is a WEAK copyleft license ( it m= ay be considered "benign" : it does not invade the user software , affects = only the modifications to the LGPL licensed software ) , >> > >> > in spite of this , >> > >> > "GNU General Public License" is a STRONG copyleft license ( it may be = considered "malignant" : it invades the user software as a whole ) . >> > >> > >> > Using a ( LGPL licensed software ) for testing another software is not= directly involved in the tested software . >> > >> > To eliminate possible doubts , if I were the decision maker about how = to use it , I would make it a port , and fetch it during testing as a dynam= ically loaded library ( manage it port with respect to its license ) . >> > >> > >> > Mehmet Erol Sanliturk >> > > > > > >> >> The problem is that the library, not just the headers, needs to be >> present at compile time. Or do you know a good workaround? > > > > > You can fetch the LGPL licensed sources during compile time from outside = of the FreeBSD > base known to the testing program . The user(s) of FreeBSD can also use = a similar facility . > > For example : > > I am developing mainly two programs : > > (1) Mathematical Analysis computations > (2) A Multi-media information management system > > These programs are using parts taken from legally personally usable sourc= es which > can not be used for a ( free or commercial ) distribution . During progra= m development , > it is possible to use them , because they are in there just as a filler f= or not-implemented-yet parts . > > To prevent unacceptable inclusion of such sources into my own productions= , I am > using global directories outside of the program directories : > > /KBMS/Parts_to_ be_Removed/... ( Part specific directories ) > /MAS/Parts_to_ be_Removed/... ( Part specific directories ) > > It is explicitly known that these directories and their contents can not = be used . > There is no danger of including them erroneously . > > > You can define such directories . During compilation you may fetch LGPL l= icensed > parts from these directories ( even though they may be on the Internet ) = . After compilation of > the programs ( and if they are executed ) you may discard them . By suppl= ying a script to manage such issues , users of the FreeBSD may also use the= associated external directories created in their systems and used during t= heir works . > > > The main problem for the LGPL licensed sources is the modifications perfo= rmed > in them . If there are such parts they should be open sourced , not the s= ources of the > user sources . The closed source programs will not be affected from such = modifications . > > Some closed source program developers may not want to handle legal implic= ations of > these modified or not modified LGPL licensed parts even when they are dis= tributed because any failure of distribution of especially modified source= s may cause significant trouble for them . To eliminate such distribution r= elated concerns , the best action may be to store > these sources into a publicly accessible repository , modify these source= s in that repository and use them from this repository . In this case , mo= difications in the main repository and excluding of these from FreeBSD dist= ributions will not affect FreeBSD users other than fetching them when they = are needed , which is legally acceptable and harmless . > > Generation of a package or port from this repository may be necessary or= not , > I will not be able to say anything because I do not know . The port or pa= ckage > generator persons would know such points . My opinion is that the above m= odel > may not require either a port or a package separately because everything= necessary > will be in the repository . > > > > Mehmet Erol Sanliturk So you suggest that "make buildworld" downloads the libnfs sources? That would be a big change from the current setup, where all sources are assumed to be present when make starts. I expect that it might break tools like "make release" and nanobsd, too. Of course, we could always put these tests into tools/regression instead of tests/. That would be easy. But then they wouldn't get run in CI. And I think that CI is essential for any new tests. > > > > >> >> >> > >> > >> > >> > >> >> >> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers wro= te: >> >>> >> >>> I recently ran into a bug in fusefs that can only be triggered when >> >>> NFS exports a FUSE file system. That makes it very difficult to wri= te >> >>> an automated test. My options are basically: >> >>> >> >>> * Add an fhgetdirentries(2) syscall that is like getdirentries, but >> >>> takes a fhandle_t* argument instead of a file descriptor. >> >>> * Actually start nfsd during the test, and export the temporary FUSE= filesystem. >> >>> >> >>> The first option sounds like way too much non-test code to change. >> >>> Plus, I may need to add thread() and fhwrite() syscalls too, for oth= er >> >>> NFS-related test cases. The second option would also be a lot of >> >>> work, but at least the work would all be confined to the test code. >> >>> However, what would I do once I've exported the file system? Mounti= ng >> >>> it with the NFS client would add several more layers to the stack >> >>> under test. I'm not even sure that it's safe to self-mount an >> >>> exported file system. Another option would be to communicate direct= ly >> >>> with nfsd from the test code. That's possible, but writing NFS RPCs >> >>> by hand is very cumbersome, and it would obscure the test logic. A >> >>> better option is to use libnfs. The API is just what I would need. >> >>> However, it's licensed under the LGPL 2.1. I know that we as a >> >>> project decided to import no new GPLish code into contrib/. But thi= s >> >>> code would never be used outside of /usr/tests, so it wouldn't even >> >>> affect many production builds. Would that be acceptable? The >> >>> workarounds are ugly: >> >>> >> >>> * Create a new port for all libnfs-dependent tests. This would be >> >>> hard to maintain, because the content of the tests must be so >> >>> dependent on the base version of the OS. >> >>> * Write the tests in Python using libnfs-python. The tests could >> >>> still be compiled as part of the base system, they just wouldn't wor= k >> >>> unless libnfs-python is installed from ports. But this is awkward >> >>> because the tests are currently C++. So I would have to embed a >> >>> Python interpreter into the C++ code. It would really obfuscate the >> >>> test logic. >> >>> * Store the tests in the base system, but detached from the build. >> >>> Then create a port that builds them by mounting SRC_BASE, much like >> >>> devel/py-libzfs does. It would then install them in /usr/local/test= s. >> >>> This is probably the least-bad option if I can't import libnfs into >> >>> contrib/. >> >>> >> >>> What do you think? Is it acceptable to import libnfs intro contrib/= ? >> >>> It's LGPL, except for a few headers that are BSD and some examples >> >>> that are GPLv3. But we needn't use the examples, or even import the= m. >> >>> >> >>> https://github.com/sahlberg/libnfs >> >>> From nobody Mon Jan 3 17:32:22 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DC2A11939943 for ; Mon, 3 Jan 2022 17:33:00 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSNB45Q0Sz4pM6; Mon, 3 Jan 2022 17:33:00 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id s1so71310016wrg.1; Mon, 03 Jan 2022 09:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j5fl/73F2nZvRFrMTHlS3G6K17DA4DJVN3Q7WDU5n7g=; b=Lhbvzf/Qf+hGiEkFar+cmQnoyWEcZ47Zht0Vm+R3o+YHm30GLteaX6sFFz9tV/XGY5 /AQbSKWLja50hwLT3GRr9s0p/0RlP/AULbMU0CIb4/utEIpUsfk9gskZeAlfIo0Zy21o cMa2mOnjYhgdBTapCDNLDglvbegVCnK6CaFP2rZYIFA6tCN5vpq6+8eMQibVqKUIKfHS YHFa1JDAvuumo/vI2Odq1kTIDwQ/fiL7nSs/gfslyFOJadELaOoFwXwZBHLauohBqM7G XJ9iysWzkjKQCCUajkY75RtsKJOGTiGdpoLgP6tlZiqBoatRrGRBtSbJpv4iHinT0lWt ViHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j5fl/73F2nZvRFrMTHlS3G6K17DA4DJVN3Q7WDU5n7g=; b=mjLdIxEdPmwMxdt0v7Tky6xGjV8TBIFDDWtZ8tob7B5FJ3wlmNKwb5/ILS6YlLf4xs kFQI4+hDObehGYVMAHOCQEsayzEWfvCCAcbhq5HfpLsYo/7JDCL5yg9t0IytJnXC4IP8 9W/iwhpvogpx20EryVbWsYrVezg49ukfObddAXqZTCj4GUcylycTXFvOaW9kSFaGE8Tt xGhVcH3zoa4AARG7VEHFSPPMt9dq17cuPMpYoy9Q1kEf6hrxWgoMY1BXfY748DGUs7E9 1q13Sk402Se1HU7JqAMJp824rPHIEGDFL2ytjjNKYNaNswFhBk/l226d33OMtubCfcGK DcYQ== X-Gm-Message-State: AOAM530fLzeocYdMXD8fkehXAydvoQQyAR1/u3Bndgn8WX2hN576ZZHS WTdIOXT6dWwfgSB346+wO03EIrerHFv8ng/E3vczmDgfV4A9zQ== X-Google-Smtp-Source: ABdhPJwQp+ZKBE15BNIfAlYINqESRGRp4nUfKfZ8prXnDK7iuWPVMEcRSifASpD2ZBFQAoie60CwRMzsXEcB7XBoaCc= X-Received: by 2002:adf:e0c8:: with SMTP id m8mr17758596wri.609.1641231179250; Mon, 03 Jan 2022 09:32:59 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Mon, 3 Jan 2022 20:32:22 +0300 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Alan Somers Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000006eff9605d4b0e9d0" X-Rspamd-Queue-Id: 4JSNB45Q0Sz4pM6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000006eff9605d4b0e9d0 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 7:57 PM Alan Somers wrote: > On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk > wrote: > > > > > > > > On Mon, Jan 3, 2022 at 5:47 PM Alan Somers wrote: > >> > >> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk > >> wrote: > >> > > >> > > >> > > >> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh wrote: > >> >> > >> >> Top posting my reactions (sorry) > >> >> > >> >> I think 'in base as a private library, used only in the tests > protected by MK_LGPL' is fine. > >> >> > >> >> This would keep it in base, keep the testing happening, and allow > those who want > >> >> to omit it. This would also not run afoul of any companies that > still have downloading > >> >> GPL'd software is a fireable offense, since all such policies I > heard about years ago > >> >> were specifically the GPL, not the LGPL). This is of course a trade > off between > >> >> getting something useful from the LGPL software (better testing) and > our desires > >> >> not to have any in the tree at all, if possible. Adding a knob would > let it be shut > >> >> off easily with all the tests disabled that depend on it. This is > also in keeping with > >> >> our historical practices of having software with undesirable > licenses as long as it > >> >> gets us something. > >> >> > >> >> I think this is better than the ports options because it will get > more use and exposure > >> >> this way and is more likely to remain working (though with our > current CI setup > >> >> adding it as a dependency for that CI would be easy and give us > decent coverage). > >> >> > >> >> Warner > >> >> > >> > > >> > > >> > > >> > https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License > >> > GNU Lesser General Public License > >> > > >> > https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft > >> > Strong and weak copyleft > >> > > >> > > >> > "GNU Lesser General Public License" is a WEAK copyleft license ( it > may be considered "benign" : it does not invade the user software , affects > only the modifications to the LGPL licensed software ) , > >> > > >> > in spite of this , > >> > > >> > "GNU General Public License" is a STRONG copyleft license ( it may be > considered "malignant" : it invades the user software as a whole ) . > >> > > >> > > >> > Using a ( LGPL licensed software ) for testing another software is > not directly involved in the tested software . > >> > > >> > To eliminate possible doubts , if I were the decision maker about how > to use it , I would make it a port , and fetch it during testing as a > dynamically loaded library ( manage it port with respect to its license ) . > >> > > >> > > >> > Mehmet Erol Sanliturk > >> > > > > > > > > > > > >> > >> The problem is that the library, not just the headers, needs to be > >> present at compile time. Or do you know a good workaround? > > > > > > > > > > You can fetch the LGPL licensed sources during compile time from outside > of the FreeBSD > > base known to the testing program . The user(s) of FreeBSD can also use > a similar facility . > > > > For example : > > > > I am developing mainly two programs : > > > > (1) Mathematical Analysis computations > > (2) A Multi-media information management system > > > > These programs are using parts taken from legally personally usable > sources which > > can not be used for a ( free or commercial ) distribution . During > program development , > > it is possible to use them , because they are in there just as a filler > for not-implemented-yet parts . > > > > To prevent unacceptable inclusion of such sources into my own > productions , I am > > using global directories outside of the program directories : > > > > /KBMS/Parts_to_ be_Removed/... ( Part specific directories ) > > /MAS/Parts_to_ be_Removed/... ( Part specific directories ) > > > > It is explicitly known that these directories and their contents can not > be used . > > There is no danger of including them erroneously . > > > > > > You can define such directories . During compilation you may fetch LGPL > licensed > > parts from these directories ( even though they may be on the Internet ) > . After compilation of > > the programs ( and if they are executed ) you may discard them . By > supplying a script to manage such issues , users of the FreeBSD may also > use the associated external directories created in their systems and used > during their works . > > > > > > The main problem for the LGPL licensed sources is the modifications > performed > > in them . If there are such parts they should be open sourced , not the > sources of the > > user sources . The closed source programs will not be affected from such > modifications . > > > > Some closed source program developers may not want to handle legal > implications of > > these modified or not modified LGPL licensed parts even when they are > distributed because any failure of distribution of especially modified > sources may cause significant trouble for them . To eliminate such > distribution related concerns , the best action may be to store > > these sources into a publicly accessible repository , modify these > sources in that repository and use them from this repository . In this > case , modifications in the main repository and excluding of these from > FreeBSD distributions will not affect FreeBSD users other than fetching > them when they are needed , which is legally acceptable and harmless . > > > > Generation of a package or port from this repository may be necessary > or not , > > I will not be able to say anything because I do not know . The port or > package > > generator persons would know such points . My opinion is that the above > model > > may not require either a port or a package separately because > everything necessary > > will be in the repository . > > > > > > > > Mehmet Erol Sanliturk > > > So you suggest that "make buildworld" downloads the libnfs sources? > That would be a big change from the current setup, where all sources > are assumed to be present when make starts. I expect that it might > break tools like "make release" and nanobsd, too. Of course, we could > always put these tests into tools/regression instead of tests/. That > would be easy. But then they wouldn't get run in CI. And I think > that CI is essential for any new tests. > > It is very likely that there will not be many ( or high frequency ) modifications in the repository of required LGPL licensed parts . Fetching and storing them into a directory outside of the source tree and keeping them in there will not be a violation of its license . If a modification is applied into their main repository , then again the action will be "fetch and store them , and keep them in there" . In this case , "make { buildworld | release }" or other processing steps will require only specification of the global directory of LGPL licensed sources ( outside of the FreeBSD base ) . These will not be included into FreeBSD base when it is distributed but only will be used during testing or other tasks where they are applied . Any user of the FreeBSD , will do a similar action in their "make { buildworld | release }" or other processing works . Since it is possible to keep the LGPL licensed sources ( by fetching modifications from its repository ) indefinitely , my opinion is that continuous use of these sources are legally possible and harmless . ( I am not a lawyer and my views do not constitute legal advice . ) If a user does not want to keep these LGPL licensed parts , she/he may discard the global directory contents when she/he completes her/his job , and again she/he may fetch and use them . Such an action will be decided by the user with respect to her/his needs and/or conventions . With respect to LGPL license such an action is not necessary if the above defined publically accessible repository is used . Mehmet Erol Sanliturk > > > > > > > > > >> > >> > >> > > >> > > >> > > >> > > >> >> > >> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers > wrote: > >> >>> > >> >>> I recently ran into a bug in fusefs that can only be triggered when > >> >>> NFS exports a FUSE file system. That makes it very difficult to > write > >> >>> an automated test. My options are basically: > >> >>> > >> >>> * Add an fhgetdirentries(2) syscall that is like getdirentries, but > >> >>> takes a fhandle_t* argument instead of a file descriptor. > >> >>> * Actually start nfsd during the test, and export the temporary > FUSE filesystem. > >> >>> > >> >>> The first option sounds like way too much non-test code to change. > >> >>> Plus, I may need to add thread() and fhwrite() syscalls too, for > other > >> >>> NFS-related test cases. The second option would also be a lot of > >> >>> work, but at least the work would all be confined to the test code. > >> >>> However, what would I do once I've exported the file system? > Mounting > >> >>> it with the NFS client would add several more layers to the stack > >> >>> under test. I'm not even sure that it's safe to self-mount an > >> >>> exported file system. Another option would be to communicate > directly > >> >>> with nfsd from the test code. That's possible, but writing NFS RPCs > >> >>> by hand is very cumbersome, and it would obscure the test logic. A > >> >>> better option is to use libnfs. The API is just what I would need. > >> >>> However, it's licensed under the LGPL 2.1. I know that we as a > >> >>> project decided to import no new GPLish code into contrib/. But > this > >> >>> code would never be used outside of /usr/tests, so it wouldn't even > >> >>> affect many production builds. Would that be acceptable? The > >> >>> workarounds are ugly: > >> >>> > >> >>> * Create a new port for all libnfs-dependent tests. This would be > >> >>> hard to maintain, because the content of the tests must be so > >> >>> dependent on the base version of the OS. > >> >>> * Write the tests in Python using libnfs-python. The tests could > >> >>> still be compiled as part of the base system, they just wouldn't > work > >> >>> unless libnfs-python is installed from ports. But this is awkward > >> >>> because the tests are currently C++. So I would have to embed a > >> >>> Python interpreter into the C++ code. It would really obfuscate the > >> >>> test logic. > >> >>> * Store the tests in the base system, but detached from the build. > >> >>> Then create a port that builds them by mounting SRC_BASE, much like > >> >>> devel/py-libzfs does. It would then install them in > /usr/local/tests. > >> >>> This is probably the least-bad option if I can't import libnfs into > >> >>> contrib/. > >> >>> > >> >>> What do you think? Is it acceptable to import libnfs intro > contrib/? > >> >>> It's LGPL, except for a few headers that are BSD and some examples > >> >>> that are GPLv3. But we needn't use the examples, or even import > them. > >> >>> > >> >>> https://github.com/sahlberg/libnfs > >> >>> > --0000000000006eff9605d4b0e9d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 3, 2022 = at 7:57 PM Alan Somers <asomers@f= reebsd.org> wrote:
On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk
<m.e.sanlit= urk@gmail.com> wrote:
>
>
>
> On Mon, Jan 3, 2022 at 5:47 PM Alan Somers <asomers@freebsd.org> wrote:
>>
>> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk
>> <m= .e.sanliturk@gmail.com> wrote:
>> >
>> >
>> >
>> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh <imp@bsdimp.com> wrote:
>> >>
>> >> Top posting my reactions (sorry)
>> >>
>> >> I think 'in base as a private library, used only in t= he tests protected by MK_LGPL' is fine.
>> >>
>> >> This would keep it in base, keep the testing happening, a= nd allow those who want
>> >> to omit it. This would also not run afoul of any companie= s that still have downloading
>> >> GPL'd software is a fireable offense, since all such = policies I heard about years ago
>> >> were specifically the GPL, not the LGPL). This is of cour= se a trade off between
>> >> getting something useful from the LGPL software (better t= esting) and our desires
>> >> not to have any in the tree at all, if possible. Adding a= knob would let it be shut
>> >> off easily with all the tests disabled that depend on it.= This is also in keeping with
>> >> our historical practices of having software with undesira= ble licenses as long as it
>> >> gets us something.
>> >>
>> >> I think this is better than the ports options because it = will get more use and exposure
>> >> this way and is more likely to remain working (though wit= h our current CI setup
>> >> adding it as a dependency for that CI would be easy and g= ive us decent coverage).
>> >>
>> >> Warner
>> >>
>> >
>> >
>> >
>> > https://en.wikipedia.or= g/wiki/GNU_Lesser_General_Public_License
>> > GNU Lesser General Public License
>> >
>> > https://en.wikipedia.or= g/wiki/Copyleft#Strong_and_weak_copyleft
>> > Strong and weak copyleft
>> >
>> >
>> > "GNU Lesser General Public License" is a=C2=A0 WEAK= copyleft license ( it may be considered "benign" : it does not i= nvade the user software , affects only the modifications to the LGPL licens= ed software ) ,
>> >
>> > in spite of this ,
>> >
>> > "GNU General Public License" is a STRONG copyleft l= icense ( it may be considered "malignant" : it invades the user s= oftware as a whole ) .
>> >
>> >
>> > Using a ( LGPL licensed software ) for testing another softwa= re is not directly involved in the tested software .
>> >
>> > To eliminate possible doubts , if I were the decision maker a= bout how to use it , I would make it a port , and fetch it during testing a= s a dynamically loaded library ( manage it port with respect to its license= ) .
>> >
>> >
>> > Mehmet=C2=A0 Erol Sanliturk
>>
>
>
>
>
>
>>
>> The problem is that the library, not just the headers, needs to be=
>> present at compile time.=C2=A0 Or do you know a good workaround? >
>
>
>
> You can fetch the LGPL licensed sources during compile time from outsi= de of the FreeBSD
> base known to the testing program . The user(s) of=C2=A0 FreeBSD can a= lso use a similar facility .
>
> For example :
>
> I am developing mainly two programs :
>
> (1) Mathematical Analysis computations
> (2) A Multi-media information management system
>
> These programs are using parts taken from legally personally usable so= urces=C2=A0 which
> can not be used for a ( free or commercial ) distribution . During pro= gram development ,
> it is possible to use them , because they are in there just as a fille= r for=C2=A0 not-implemented-yet parts .
>
> To prevent unacceptable inclusion of such sources into my own producti= ons , I am
> using global directories=C2=A0 outside of the program directories : >
> /KBMS/Parts_to_ be_Removed/... ( Part specific directories )
> /MAS/Parts_to_ be_Removed/... ( Part specific directories )
>
> It is explicitly known that these directories and their contents can n= ot be used .
> There is no danger of including them erroneously .
>
>
> You can define such directories . During compilation you may fetch LGP= L licensed
> parts from these directories ( even though they may be on the Internet= ) . After compilation of
> the programs ( and if they are executed ) you may discard them . By su= pplying a script to manage such issues , users of the FreeBSD may also use = the associated external directories created in their systems and used durin= g their works .
>
>
> The main problem for the LGPL licensed sources is the modifications pe= rformed
> in them . If there are such parts they should be open sourced , not th= e sources of the
> user sources . The closed source programs will not be affected from su= ch modifications .
>
> Some closed source program developers may not want to handle legal imp= lications of
> these modified or not modified LGPL licensed parts even when they are = distributed=C2=A0 because any failure of distribution of especially modifie= d sources may cause significant trouble for them . To eliminate such distri= bution related concerns , the best action may be to store
> these sources into a publicly accessible repository , modify these sou= rces in that repository and use them=C2=A0 from this repository . In this c= ase , modifications in the main repository and excluding of these from Free= BSD distributions will not affect FreeBSD users other than fetching them wh= en they are needed , which is legally acceptable and harmless .
>
> Generation of a package or port from this repository=C2=A0 may be nece= ssary or not ,
> I will not be able to say anything because I do not know . The port or= package
> generator persons would know such points . My opinion is that the abov= e model
> may not require either a port or a package separately because=C2=A0 ev= erything necessary
> will be in the repository .
>
>
>
> Mehmet Erol Sanliturk





=C2=A0
So you suggest that "make buildworld" downloads the libnfs source= s?
That would be a big change from the current setup, where all sources
are assumed to be present when make starts.=C2=A0 I expect that it might break tools like "make release" and nanobsd, too.=C2=A0 Of course= , we could
always put these tests into tools/regression instead of tests/.=C2=A0 That<= br> would be easy.=C2=A0 But then they wouldn't get run in CI.=C2=A0 And I = think
that CI is essential for any new tests.





It is very likely that there will not be many ( or high = frequency ) modifications in
the repository of required= LGPL licensed parts .=C2=A0

Fetchi= ng and storing them into a directory outside of the source tree and
keeping them in there will not be a violation of its license .=
If a modification is applied into their=C2=A0 main repo= sitory , then again the action will be
"fetch and = store them , and keep them in there" .
In this case , &= quot;make { buildworld=C2=A0 | release }" or other processing steps wi= ll require only specification of the global directory of LGPL licensed sour= ces ( outside of the FreeBSD base ) .
These will not be= included into FreeBSD base when it is distributed
but = only will be used during testing or other tasks where they are applied .

Any user of the FreeBSD , will do a = similar action in their "make { buildworld=C2=A0 | release }"
or other processing works .


Since it is possible to keep the LGPL licensed sources ( by fet= ching modifications from its repository ) indefinitely , my opinion
is that continuous use of these sources are legally possible and ha= rmless .
( I am not a lawyer and my views do not constitute = legal advice . )



If a user does not want to keep these LGPL licensed parts , she/he ma= y discard the
global directory contents when she/he complete= s her/his job , and again she/he
may fetch and use them= . Such an action will be decided by the user with respect to
her/his needs and/or conventions . With respect to LGPL license such an a= ction is not
necessary if the above defined publically = accessible repository is used .


Mehmet Erol Sanliturk




=C2=A0
>
>
>
>
>>
>>
>> >
>> >
>> >
>> >
>> >>
>> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers <asomers@freebsd.org&g= t; wrote:
>> >>>
>> >>> I recently ran into a bug in fusefs that can only be = triggered when
>> >>> NFS exports a FUSE file system.=C2=A0 That makes it v= ery difficult to write
>> >>> an automated test.=C2=A0 My options are basically: >> >>>
>> >>> * Add an fhgetdirentries(2) syscall that is like getd= irentries, but
>> >>> takes a fhandle_t* argument instead of a file descrip= tor.
>> >>> * Actually start nfsd during the test, and export the= temporary FUSE filesystem.
>> >>>
>> >>> The first option sounds like way too much non-test co= de to change.
>> >>> Plus, I may need to add thread() and fhwrite() syscal= ls too, for other
>> >>> NFS-related test cases.=C2=A0 The second option would= also be a lot of
>> >>> work, but at least the work would all be confined to = the test code.
>> >>> However, what would I do once I've exported the f= ile system?=C2=A0 Mounting
>> >>> it with the NFS client would add several more layers = to the stack
>> >>> under test.=C2=A0 I'm not even sure that it's= safe to self-mount an
>> >>> exported file system.=C2=A0 Another option would be t= o communicate directly
>> >>> with nfsd from the test code.=C2=A0 That's possib= le, but writing NFS RPCs
>> >>> by hand is very cumbersome, and it would obscure the = test logic.=C2=A0 A
>> >>> better option is to use libnfs.=C2=A0 The API is just= what I would need.
>> >>> However, it's licensed under the LGPL 2.1.=C2=A0 = I know that we as a
>> >>> project decided to import no new GPLish code into con= trib/.=C2=A0 But this
>> >>> code would never be used outside of /usr/tests, so it= wouldn't even
>> >>> affect many production builds.=C2=A0 Would that be ac= ceptable?=C2=A0 The
>> >>> workarounds are ugly:
>> >>>
>> >>> * Create a new port for all libnfs-dependent tests.= =C2=A0 This would be
>> >>> hard to maintain, because the content of the tests mu= st be so
>> >>> dependent on the base version of the OS.
>> >>> * Write the tests in Python using libnfs-python.=C2= =A0 The tests could
>> >>> still be compiled as part of the base system, they ju= st wouldn't work
>> >>> unless libnfs-python is installed from ports.=C2=A0 B= ut this is awkward
>> >>> because the tests are currently C++.=C2=A0 So I would= have to embed a
>> >>> Python interpreter into the C++ code.=C2=A0 It would = really obfuscate the
>> >>> test logic.
>> >>> * Store the tests in the base system, but detached fr= om the build.
>> >>> Then create a port that builds them by mounting SRC_B= ASE, much like
>> >>> devel/py-libzfs does.=C2=A0 It would then install the= m in /usr/local/tests.
>> >>> This is probably the least-bad option if I can't = import libnfs into
>> >>> contrib/.
>> >>>
>> >>> What do you think?=C2=A0 Is it acceptable to import l= ibnfs intro contrib/?
>> >>> It's LGPL, except for a few headers that are BSD = and some examples
>> >>> that are GPLv3.=C2=A0 But we needn't use the exam= ples, or even import them.
>> >>>
>> >>> https://github.com/sahlberg/libnfs
>> >>>
--0000000000006eff9605d4b0e9d0-- From nobody Mon Jan 3 18:06:20 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7F6B91919354 for ; Mon, 3 Jan 2022 18:06:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSNwm2LdSz4vpH for ; Mon, 3 Jan 2022 18:06:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92e.google.com with SMTP id c36so33514631uae.13 for ; Mon, 03 Jan 2022 10:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=REljSrcZwq+eC7sp68BTYsqWmCDgVgsYcIprXxcJWnY=; b=mVZamQvGhhaih2Jk6peZhAYJ/R73HxvFGrdkHaV7rbZ5eSSNx1sfL5fHAJrUDvn+jD OFEiMSxskHUhqI98ar6HdcIOFCWPwgbi4+n58dOQJUth9mlGqDbmO9SAoObVbyqkVM+1 Vt/jKhQmwO3Adtb4Ze6yIYrQJ38EYT82F30+TKCuCY5R9jZdkMjxhEMkDfg2twfVQkbk 469rTj6vGOBxS0FAtEbcL4MVZstTgBjdV1WIfn+Oqdhz5rZEoMuvpn4Nkg33x5YWrLfu 8V4HiiPYi2pKTf6pkVr0fpvMA57l4f/zBbmsvpMomn84uFYNTCpgvUyo7J7ilr3H5Gis ZmEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=REljSrcZwq+eC7sp68BTYsqWmCDgVgsYcIprXxcJWnY=; b=m0ndu8pBjbxDcOduNyrGEhV/I5ywRJqNRbQUqaMCVUikJPCo+lhDxi0iSCv1szHSZK IPCLUWOElT5qaMenxPQ88jIH1TwDR35WAnAsz6g3OwaL67OsC7dmjjJ5WMbRKAT/5DhX 5MpLfdHLXnKh21lr9pMaM3g4k+ImS1b+i9+azCQvdqrB/9HqPRHmWdQVmP6QOQ12cfub mO/Af3wIpjnt01vM0fNWvSVtefc933txByL7rnr+OC2/kZZsBrUNk/UozTj2Qe1SQqX3 gpha6PQ8B1HEbJ4JVlJOd3nmkQw/Vdx2GGjzegpNlLHaQAi7BRvFfvFvlr8JtfE6v7sO OuMA== X-Gm-Message-State: AOAM532/t9rHT+EFQe1WSEF8ZGUtzospU08NjkLBH1LTKrwr5GnQXIKC 7tLjBbek2HBccRAdnLjMUtTk19svF56uLij5aXOsiASr5as= X-Google-Smtp-Source: ABdhPJzy6Klui54xGLP30ASUl+VvAQC7hUx9R+MoB0LY1T115lrGdDA7KTLGoN2R9kgIuF+xyhhKKyhPTqSWwlLYMMc= X-Received: by 2002:a9f:2383:: with SMTP id 3mr14329251uao.77.1641233191607; Mon, 03 Jan 2022 10:06:31 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 3 Jan 2022 11:06:20 -0700 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Mehmet Erol Sanliturk Cc: Alan Somers , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000061365205d4b161e8" X-Rspamd-Queue-Id: 4JSNwm2LdSz4vpH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000061365205d4b161e8 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022, 10:32 AM Mehmet Erol Sanliturk wrote: > > > On Mon, Jan 3, 2022 at 7:57 PM Alan Somers wrote: > >> On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk >> wrote: >> > >> > >> > >> > On Mon, Jan 3, 2022 at 5:47 PM Alan Somers wrote: >> >> >> >> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk >> >> wrote: >> >> > >> >> > >> >> > >> >> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh wrote: >> >> >> >> >> >> Top posting my reactions (sorry) >> >> >> >> >> >> I think 'in base as a private library, used only in the tests >> protected by MK_LGPL' is fine. >> >> >> >> >> >> This would keep it in base, keep the testing happening, and allow >> those who want >> >> >> to omit it. This would also not run afoul of any companies that >> still have downloading >> >> >> GPL'd software is a fireable offense, since all such policies I >> heard about years ago >> >> >> were specifically the GPL, not the LGPL). This is of course a trade >> off between >> >> >> getting something useful from the LGPL software (better testing) >> and our desires >> >> >> not to have any in the tree at all, if possible. Adding a knob >> would let it be shut >> >> >> off easily with all the tests disabled that depend on it. This is >> also in keeping with >> >> >> our historical practices of having software with undesirable >> licenses as long as it >> >> >> gets us something. >> >> >> >> >> >> I think this is better than the ports options because it will get >> more use and exposure >> >> >> this way and is more likely to remain working (though with our >> current CI setup >> >> >> adding it as a dependency for that CI would be easy and give us >> decent coverage). >> >> >> >> >> >> Warner >> >> >> >> >> > >> >> > >> >> > >> >> > https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License >> >> > GNU Lesser General Public License >> >> > >> >> > https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft >> >> > Strong and weak copyleft >> >> > >> >> > >> >> > "GNU Lesser General Public License" is a WEAK copyleft license ( it >> may be considered "benign" : it does not invade the user software , affects >> only the modifications to the LGPL licensed software ) , >> >> > >> >> > in spite of this , >> >> > >> >> > "GNU General Public License" is a STRONG copyleft license ( it may >> be considered "malignant" : it invades the user software as a whole ) . >> >> > >> >> > >> >> > Using a ( LGPL licensed software ) for testing another software is >> not directly involved in the tested software . >> >> > >> >> > To eliminate possible doubts , if I were the decision maker about >> how to use it , I would make it a port , and fetch it during testing as a >> dynamically loaded library ( manage it port with respect to its license ) . >> >> > >> >> > >> >> > Mehmet Erol Sanliturk >> >> >> > >> > >> > >> > >> > >> >> >> >> The problem is that the library, not just the headers, needs to be >> >> present at compile time. Or do you know a good workaround? >> > >> > >> > >> > >> > You can fetch the LGPL licensed sources during compile time from >> outside of the FreeBSD >> > base known to the testing program . The user(s) of FreeBSD can also >> use a similar facility . >> > >> > For example : >> > >> > I am developing mainly two programs : >> > >> > (1) Mathematical Analysis computations >> > (2) A Multi-media information management system >> > >> > These programs are using parts taken from legally personally usable >> sources which >> > can not be used for a ( free or commercial ) distribution . During >> program development , >> > it is possible to use them , because they are in there just as a filler >> for not-implemented-yet parts . >> > >> > To prevent unacceptable inclusion of such sources into my own >> productions , I am >> > using global directories outside of the program directories : >> > >> > /KBMS/Parts_to_ be_Removed/... ( Part specific directories ) >> > /MAS/Parts_to_ be_Removed/... ( Part specific directories ) >> > >> > It is explicitly known that these directories and their contents can >> not be used . >> > There is no danger of including them erroneously . >> > >> > >> > You can define such directories . During compilation you may fetch LGPL >> licensed >> > parts from these directories ( even though they may be on the Internet >> ) . After compilation of >> > the programs ( and if they are executed ) you may discard them . By >> supplying a script to manage such issues , users of the FreeBSD may also >> use the associated external directories created in their systems and used >> during their works . >> > >> > >> > The main problem for the LGPL licensed sources is the modifications >> performed >> > in them . If there are such parts they should be open sourced , not the >> sources of the >> > user sources . The closed source programs will not be affected from >> such modifications . >> > >> > Some closed source program developers may not want to handle legal >> implications of >> > these modified or not modified LGPL licensed parts even when they are >> distributed because any failure of distribution of especially modified >> sources may cause significant trouble for them . To eliminate such >> distribution related concerns , the best action may be to store >> > these sources into a publicly accessible repository , modify these >> sources in that repository and use them from this repository . In this >> case , modifications in the main repository and excluding of these from >> FreeBSD distributions will not affect FreeBSD users other than fetching >> them when they are needed , which is legally acceptable and harmless . >> > >> > Generation of a package or port from this repository may be necessary >> or not , >> > I will not be able to say anything because I do not know . The port or >> package >> > generator persons would know such points . My opinion is that the above >> model >> > may not require either a port or a package separately because >> everything necessary >> > will be in the repository . >> > >> > >> > >> > Mehmet Erol Sanliturk >> >> > > > > > >> So you suggest that "make buildworld" downloads the libnfs sources? >> That would be a big change from the current setup, where all sources >> are assumed to be present when make starts. I expect that it might >> break tools like "make release" and nanobsd, too. Of course, we could >> always put these tests into tools/regression instead of tests/. That >> would be easy. But then they wouldn't get run in CI. And I think >> that CI is essential for any new tests. >> >> > > > > It is very likely that there will not be many ( or high frequency ) > modifications in > the repository of required LGPL licensed parts . > > Fetching and storing them into a directory outside of the source tree and > keeping them in there will not be a violation of its license . > If a modification is applied into their main repository , then again the > action will be > "fetch and store them , and keep them in there" . > In this case , "make { buildworld | release }" or other processing steps > will require only specification of the global directory of LGPL licensed > sources ( outside of the FreeBSD base ) . > These will not be included into FreeBSD base when it is distributed > but only will be used during testing or other tasks where they are applied > . > > Any user of the FreeBSD , will do a similar action in their "make { > buildworld | release }" > or other processing works . > > > Since it is possible to keep the LGPL licensed sources ( by fetching > modifications from its repository ) indefinitely , my opinion > is that continuous use of these sources are legally possible and harmless . > ( I am not a lawyer and my views do not constitute legal advice . ) > > > > If a user does not want to keep these LGPL licensed parts , she/he may > discard the > global directory contents when she/he completes her/his job , and again > she/he > may fetch and use them . Such an action will be decided by the user with > respect to > her/his needs and/or conventions . With respect to LGPL license such an > action is not > necessary if the above defined publically accessible repository is used . > All of that is covered by our existing practice of storing LGPL code in src/gnu/lib. We cover it in the handbook already. Since it is publicly available forever, storing it there will have no impact that's any different than libdialog or libreadline has has in the past. Warner > Mehmet Erol Sanliturk > > > > > > > >> > >> > >> > >> > >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers >> wrote: >> >> >>> >> >> >>> I recently ran into a bug in fusefs that can only be triggered when >> >> >>> NFS exports a FUSE file system. That makes it very difficult to >> write >> >> >>> an automated test. My options are basically: >> >> >>> >> >> >>> * Add an fhgetdirentries(2) syscall that is like getdirentries, but >> >> >>> takes a fhandle_t* argument instead of a file descriptor. >> >> >>> * Actually start nfsd during the test, and export the temporary >> FUSE filesystem. >> >> >>> >> >> >>> The first option sounds like way too much non-test code to change. >> >> >>> Plus, I may need to add thread() and fhwrite() syscalls too, for >> other >> >> >>> NFS-related test cases. The second option would also be a lot of >> >> >>> work, but at least the work would all be confined to the test code. >> >> >>> However, what would I do once I've exported the file system? >> Mounting >> >> >>> it with the NFS client would add several more layers to the stack >> >> >>> under test. I'm not even sure that it's safe to self-mount an >> >> >>> exported file system. Another option would be to communicate >> directly >> >> >>> with nfsd from the test code. That's possible, but writing NFS >> RPCs >> >> >>> by hand is very cumbersome, and it would obscure the test logic. A >> >> >>> better option is to use libnfs. The API is just what I would need. >> >> >>> However, it's licensed under the LGPL 2.1. I know that we as a >> >> >>> project decided to import no new GPLish code into contrib/. But >> this >> >> >>> code would never be used outside of /usr/tests, so it wouldn't even >> >> >>> affect many production builds. Would that be acceptable? The >> >> >>> workarounds are ugly: >> >> >>> >> >> >>> * Create a new port for all libnfs-dependent tests. This would be >> >> >>> hard to maintain, because the content of the tests must be so >> >> >>> dependent on the base version of the OS. >> >> >>> * Write the tests in Python using libnfs-python. The tests could >> >> >>> still be compiled as part of the base system, they just wouldn't >> work >> >> >>> unless libnfs-python is installed from ports. But this is awkward >> >> >>> because the tests are currently C++. So I would have to embed a >> >> >>> Python interpreter into the C++ code. It would really obfuscate >> the >> >> >>> test logic. >> >> >>> * Store the tests in the base system, but detached from the build. >> >> >>> Then create a port that builds them by mounting SRC_BASE, much like >> >> >>> devel/py-libzfs does. It would then install them in >> /usr/local/tests. >> >> >>> This is probably the least-bad option if I can't import libnfs into >> >> >>> contrib/. >> >> >>> >> >> >>> What do you think? Is it acceptable to import libnfs intro >> contrib/? >> >> >>> It's LGPL, except for a few headers that are BSD and some examples >> >> >>> that are GPLv3. But we needn't use the examples, or even import >> them. >> >> >>> >> >> >>> https://github.com/sahlberg/libnfs >> >> >>> >> > --00000000000061365205d4b161e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 3, 2022, 10:32 AM Mehmet Erol Sanliturk &l= t;m.e.sanliturk@gmail.com>= ; wrote:


On Mon, Jan 3, 2022 at 7:57 PM Alan Somers &l= t;asomers@freebsd.org> wrote:
On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk<= br> <m.e.sanliturk@gmail.com> wrote:
>
>
>
> On Mon, Jan 3, 2022 at 5:47 PM Alan Somers <asomers@freebsd.org> wrote:
>>
>> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk
>> <m.e.sanliturk@gmail.com> wrote:
>> >
>> >
>> >
>> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh <imp@bsdimp.com= > wrote:
>> >>
>> >> Top posting my reactions (sorry)
>> >>
>> >> I think 'in base as a private library, used only in t= he tests protected by MK_LGPL' is fine.
>> >>
>> >> This would keep it in base, keep the testing happening, a= nd allow those who want
>> >> to omit it. This would also not run afoul of any companie= s that still have downloading
>> >> GPL'd software is a fireable offense, since all such = policies I heard about years ago
>> >> were specifically the GPL, not the LGPL). This is of cour= se a trade off between
>> >> getting something useful from the LGPL software (better t= esting) and our desires
>> >> not to have any in the tree at all, if possible. Adding a= knob would let it be shut
>> >> off easily with all the tests disabled that depend on it.= This is also in keeping with
>> >> our historical practices of having software with undesira= ble licenses as long as it
>> >> gets us something.
>> >>
>> >> I think this is better than the ports options because it = will get more use and exposure
>> >> this way and is more likely to remain working (though wit= h our current CI setup
>> >> adding it as a dependency for that CI would be easy and g= ive us decent coverage).
>> >>
>> >> Warner
>> >>
>> >
>> >
>> >
>> > https://en.w= ikipedia.org/wiki/GNU_Lesser_General_Public_License
>> > GNU Lesser General Public License
>> >
>> > https://en.w= ikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft
>> > Strong and weak copyleft
>> >
>> >
>> > "GNU Lesser General Public License" is a=C2=A0 WEAK= copyleft license ( it may be considered "benign" : it does not i= nvade the user software , affects only the modifications to the LGPL licens= ed software ) ,
>> >
>> > in spite of this ,
>> >
>> > "GNU General Public License" is a STRONG copyleft l= icense ( it may be considered "malignant" : it invades the user s= oftware as a whole ) .
>> >
>> >
>> > Using a ( LGPL licensed software ) for testing another softwa= re is not directly involved in the tested software .
>> >
>> > To eliminate possible doubts , if I were the decision maker a= bout how to use it , I would make it a port , and fetch it during testing a= s a dynamically loaded library ( manage it port with respect to its license= ) .
>> >
>> >
>> > Mehmet=C2=A0 Erol Sanliturk
>>
>
>
>
>
>
>>
>> The problem is that the library, not just the headers, needs to be=
>> present at compile time.=C2=A0 Or do you know a good workaround? >
>
>
>
> You can fetch the LGPL licensed sources during compile time from outsi= de of the FreeBSD
> base known to the testing program . The user(s) of=C2=A0 FreeBSD can a= lso use a similar facility .
>
> For example :
>
> I am developing mainly two programs :
>
> (1) Mathematical Analysis computations
> (2) A Multi-media information management system
>
> These programs are using parts taken from legally personally usable so= urces=C2=A0 which
> can not be used for a ( free or commercial ) distribution . During pro= gram development ,
> it is possible to use them , because they are in there just as a fille= r for=C2=A0 not-implemented-yet parts .
>
> To prevent unacceptable inclusion of such sources into my own producti= ons , I am
> using global directories=C2=A0 outside of the program directories : >
> /KBMS/Parts_to_ be_Removed/... ( Part specific directories )
> /MAS/Parts_to_ be_Removed/... ( Part specific directories )
>
> It is explicitly known that these directories and their contents can n= ot be used .
> There is no danger of including them erroneously .
>
>
> You can define such directories . During compilation you may fetch LGP= L licensed
> parts from these directories ( even though they may be on the Internet= ) . After compilation of
> the programs ( and if they are executed ) you may discard them . By su= pplying a script to manage such issues , users of the FreeBSD may also use = the associated external directories created in their systems and used durin= g their works .
>
>
> The main problem for the LGPL licensed sources is the modifications pe= rformed
> in them . If there are such parts they should be open sourced , not th= e sources of the
> user sources . The closed source programs will not be affected from su= ch modifications .
>
> Some closed source program developers may not want to handle legal imp= lications of
> these modified or not modified LGPL licensed parts even when they are = distributed=C2=A0 because any failure of distribution of especially modifie= d sources may cause significant trouble for them . To eliminate such distri= bution related concerns , the best action may be to store
> these sources into a publicly accessible repository , modify these sou= rces in that repository and use them=C2=A0 from this repository . In this c= ase , modifications in the main repository and excluding of these from Free= BSD distributions will not affect FreeBSD users other than fetching them wh= en they are needed , which is legally acceptable and harmless .
>
> Generation of a package or port from this repository=C2=A0 may be nece= ssary or not ,
> I will not be able to say anything because I do not know . The port or= package
> generator persons would know such points . My opinion is that the abov= e model
> may not require either a port or a package separately because=C2=A0 ev= erything necessary
> will be in the repository .
>
>
>
> Mehmet Erol Sanliturk





=C2=A0
So you suggest that "make buildworld" downloads the libnfs source= s?
That would be a big change from the current setup, where all sources
are assumed to be present when make starts.=C2=A0 I expect that it might break tools like "make release" and nanobsd, too.=C2=A0 Of course= , we could
always put these tests into tools/regression instead of tests/.=C2=A0 That<= br> would be easy.=C2=A0 But then they wouldn't get run in CI.=C2=A0 And I = think
that CI is essential for any new tests.





It is very likely that there will not be many ( or high = frequency ) modifications in
the repository of required= LGPL licensed parts .=C2=A0

Fetchi= ng and storing them into a directory outside of the source tree and
keeping them in there will not be a violation of its license .=
If a modification is applied into their=C2=A0 main repo= sitory , then again the action will be
"fetch and = store them , and keep them in there" .
In this case , &= quot;make { buildworld=C2=A0 | release }" or other processing steps wi= ll require only specification of the global directory of LGPL licensed sour= ces ( outside of the FreeBSD base ) .
These will not be= included into FreeBSD base when it is distributed
but = only will be used during testing or other tasks where they are applied .

Any user of the FreeBSD , will do a = similar action in their "make { buildworld=C2=A0 | release }"
or other processing works .


Since it is possible to keep the LGPL licensed sources ( by fet= ching modifications from its repository ) indefinitely , my opinion
is that continuous use of these sources are legally possible and ha= rmless .
( I am not a lawyer and my views do not constitute = legal advice . )



If a user does not want to keep these LGPL licensed parts , she/he ma= y discard the
global directory contents when she/he complete= s her/his job , and again she/he
may fetch and use them= . Such an action will be decided by the user with respect to
her/his needs and/or conventions . With respect to LGPL license such an a= ction is not
necessary if the above defined publically = accessible repository is used .
<= /div>

All of that is covered b= y our existing practice of storing LGPL code in src/gnu/lib. We cover it in= the handbook already. Since it is publicly available forever, storing it t= here will have no impact that's any different than libdialog or libread= line has has in the past.

Warner


Mehmet Erol Sanliturk





=C2=A0
>
>
>
>
>>
>>
>> >
>> >
>> >
>> >
>> >>
>> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers <asomer= s@freebsd.org> wrote:
>> >>>
>> >>> I recently ran into a bug in fusefs that can only be = triggered when
>> >>> NFS exports a FUSE file system.=C2=A0 That makes it v= ery difficult to write
>> >>> an automated test.=C2=A0 My options are basically: >> >>>
>> >>> * Add an fhgetdirentries(2) syscall that is like getd= irentries, but
>> >>> takes a fhandle_t* argument instead of a file descrip= tor.
>> >>> * Actually start nfsd during the test, and export the= temporary FUSE filesystem.
>> >>>
>> >>> The first option sounds like way too much non-test co= de to change.
>> >>> Plus, I may need to add thread() and fhwrite() syscal= ls too, for other
>> >>> NFS-related test cases.=C2=A0 The second option would= also be a lot of
>> >>> work, but at least the work would all be confined to = the test code.
>> >>> However, what would I do once I've exported the f= ile system?=C2=A0 Mounting
>> >>> it with the NFS client would add several more layers = to the stack
>> >>> under test.=C2=A0 I'm not even sure that it's= safe to self-mount an
>> >>> exported file system.=C2=A0 Another option would be t= o communicate directly
>> >>> with nfsd from the test code.=C2=A0 That's possib= le, but writing NFS RPCs
>> >>> by hand is very cumbersome, and it would obscure the = test logic.=C2=A0 A
>> >>> better option is to use libnfs.=C2=A0 The API is just= what I would need.
>> >>> However, it's licensed under the LGPL 2.1.=C2=A0 = I know that we as a
>> >>> project decided to import no new GPLish code into con= trib/.=C2=A0 But this
>> >>> code would never be used outside of /usr/tests, so it= wouldn't even
>> >>> affect many production builds.=C2=A0 Would that be ac= ceptable?=C2=A0 The
>> >>> workarounds are ugly:
>> >>>
>> >>> * Create a new port for all libnfs-dependent tests.= =C2=A0 This would be
>> >>> hard to maintain, because the content of the tests mu= st be so
>> >>> dependent on the base version of the OS.
>> >>> * Write the tests in Python using libnfs-python.=C2= =A0 The tests could
>> >>> still be compiled as part of the base system, they ju= st wouldn't work
>> >>> unless libnfs-python is installed from ports.=C2=A0 B= ut this is awkward
>> >>> because the tests are currently C++.=C2=A0 So I would= have to embed a
>> >>> Python interpreter into the C++ code.=C2=A0 It would = really obfuscate the
>> >>> test logic.
>> >>> * Store the tests in the base system, but detached fr= om the build.
>> >>> Then create a port that builds them by mounting SRC_B= ASE, much like
>> >>> devel/py-libzfs does.=C2=A0 It would then install the= m in /usr/local/tests.
>> >>> This is probably the least-bad option if I can't = import libnfs into
>> >>> contrib/.
>> >>>
>> >>> What do you think?=C2=A0 Is it acceptable to import l= ibnfs intro contrib/?
>> >>> It's LGPL, except for a few headers that are BSD = and some examples
>> >>> that are GPLv3.=C2=A0 But we needn't use the exam= ples, or even import them.
>> >>>
>> >>> https://github.com/sahlberg/libnf= s
>> >>>
--00000000000061365205d4b161e8-- From nobody Mon Jan 3 18:37:00 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0FC1F1922448 for ; Mon, 3 Jan 2022 18:37:38 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSPcd5DCQz3Jr8; Mon, 3 Jan 2022 18:37:37 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wm1-x334.google.com with SMTP id c66so21886681wma.5; Mon, 03 Jan 2022 10:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fRou0fSX8Q5f8sZTXN3NNqPDtQoSPltdYZ9L4+/jrQ8=; b=DT6sisAWGEnxsIkL9Wc+4+ckZvtlq3QGVhzVegtRSryRyLrv6X1Co4kCVf6Krnimmb EnivZDyJF4Xz9ygAnIKJg8Gi5bFMTS9v7oshE5s/Sx3vXpx8WQ5dkZEEvWgKNXQ6cGZk NdzUnhcQZHK7x4M5OMQSL57QVvanGz6WxlwxmbC9KCX++yM/AYUOlC7dpIJGOweuBa6b gAhyYpZ9qgCeiMSmK9As/5AtWLYx7r13wB7mO0rWWYa5Mt2T1A+96h1kK5Qyi0gFPNqE 1MoVyOBW7wAFJGyucDCDFy0ziCfQZc78fmETEQ5kDIJ+k+1IziQftaZvJ1lC+C3btDz2 /e5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fRou0fSX8Q5f8sZTXN3NNqPDtQoSPltdYZ9L4+/jrQ8=; b=Np2aM0XXnBxYYZr7DleOXrGlXz7priLMSizWax26Bogcy5qJPMjVX8aE/gprvKFrJ5 6eWCgSnLj/H4+tIm8dtp68OqUVsnmEyfPmp3anQqU4g01gdmpxkFSVEDqgTMEo7KXb2E OHFDryBRMQ+AZ3kYWpQoV1OsHC2WUlrq6+r6CP4yCiH5h6bQOTBJbKqW7+cOV5MKvEkP +zPfdS7Hdj9O+cESeiF9EWHeLK11mk7Mb2TNCU//miF/0VFBv086JzJ+AH1oACCUboKy vBquetY1qteOCujZoKzaPZLuWYJMNGlWk1P3kEX59XqTIBTaDnhmQINrw0E8AH1RxGmz hkzA== X-Gm-Message-State: AOAM53005khBmjtty7uJqr8Hpo5htPrOK2KpzCHCtEF17D2S/ozcb3G9 /u6XnOydj/V0Jp35EdHwWFhdEf3BZmwHMszr+uV4c4RZkfk= X-Google-Smtp-Source: ABdhPJzEwdrFh+/Zbc68SROb4gGBHcXGek/zGbCnnoT2hK0mposE3J5Rj7aUBLxDZ7YvHsGqlR7fwWY4zK76V3uGIZ0= X-Received: by 2002:a05:600c:4998:: with SMTP id h24mr39166974wmp.188.1641235056598; Mon, 03 Jan 2022 10:37:36 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Mon, 3 Jan 2022 21:37:00 +0300 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Warner Losh Cc: Alan Somers , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000008aa1ab05d4b1d05a" X-Rspamd-Queue-Id: 4JSPcd5DCQz3Jr8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000008aa1ab05d4b1d05a Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 9:06 PM Warner Losh wrote: > > > On Mon, Jan 3, 2022, 10:32 AM Mehmet Erol Sanliturk < > m.e.sanliturk@gmail.com> wrote: > >> >> >> On Mon, Jan 3, 2022 at 7:57 PM Alan Somers wrote: >> >>> On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk >>> wrote: >>> > >>> > >>> > >>> > On Mon, Jan 3, 2022 at 5:47 PM Alan Somers >>> wrote: >>> >> >>> >> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk >>> >> wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh wrote: >>> >> >> >>> >> >> Top posting my reactions (sorry) >>> >> >> >>> >> >> I think 'in base as a private library, used only in the tests >>> protected by MK_LGPL' is fine. >>> >> >> >>> >> >> This would keep it in base, keep the testing happening, and allow >>> those who want >>> >> >> to omit it. This would also not run afoul of any companies that >>> still have downloading >>> >> >> GPL'd software is a fireable offense, since all such policies I >>> heard about years ago >>> >> >> were specifically the GPL, not the LGPL). This is of course a >>> trade off between >>> >> >> getting something useful from the LGPL software (better testing) >>> and our desires >>> >> >> not to have any in the tree at all, if possible. Adding a knob >>> would let it be shut >>> >> >> off easily with all the tests disabled that depend on it. This is >>> also in keeping with >>> >> >> our historical practices of having software with undesirable >>> licenses as long as it >>> >> >> gets us something. >>> >> >> >>> >> >> I think this is better than the ports options because it will get >>> more use and exposure >>> >> >> this way and is more likely to remain working (though with our >>> current CI setup >>> >> >> adding it as a dependency for that CI would be easy and give us >>> decent coverage). >>> >> >> >>> >> >> Warner >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License >>> >> > GNU Lesser General Public License >>> >> > >>> >> > https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft >>> >> > Strong and weak copyleft >>> >> > >>> >> > >>> >> > "GNU Lesser General Public License" is a WEAK copyleft license ( >>> it may be considered "benign" : it does not invade the user software , >>> affects only the modifications to the LGPL licensed software ) , >>> >> > >>> >> > in spite of this , >>> >> > >>> >> > "GNU General Public License" is a STRONG copyleft license ( it may >>> be considered "malignant" : it invades the user software as a whole ) . >>> >> > >>> >> > >>> >> > Using a ( LGPL licensed software ) for testing another software is >>> not directly involved in the tested software . >>> >> > >>> >> > To eliminate possible doubts , if I were the decision maker about >>> how to use it , I would make it a port , and fetch it during testing as a >>> dynamically loaded library ( manage it port with respect to its license ) . >>> >> > >>> >> > >>> >> > Mehmet Erol Sanliturk >>> >> >>> > >>> > >>> > >>> > >>> > >>> >> >>> >> The problem is that the library, not just the headers, needs to be >>> >> present at compile time. Or do you know a good workaround? >>> > >>> > >>> > >>> > >>> > You can fetch the LGPL licensed sources during compile time from >>> outside of the FreeBSD >>> > base known to the testing program . The user(s) of FreeBSD can also >>> use a similar facility . >>> > >>> > For example : >>> > >>> > I am developing mainly two programs : >>> > >>> > (1) Mathematical Analysis computations >>> > (2) A Multi-media information management system >>> > >>> > These programs are using parts taken from legally personally usable >>> sources which >>> > can not be used for a ( free or commercial ) distribution . During >>> program development , >>> > it is possible to use them , because they are in there just as a >>> filler for not-implemented-yet parts . >>> > >>> > To prevent unacceptable inclusion of such sources into my own >>> productions , I am >>> > using global directories outside of the program directories : >>> > >>> > /KBMS/Parts_to_ be_Removed/... ( Part specific directories ) >>> > /MAS/Parts_to_ be_Removed/... ( Part specific directories ) >>> > >>> > It is explicitly known that these directories and their contents can >>> not be used . >>> > There is no danger of including them erroneously . >>> > >>> > >>> > You can define such directories . During compilation you may fetch >>> LGPL licensed >>> > parts from these directories ( even though they may be on the Internet >>> ) . After compilation of >>> > the programs ( and if they are executed ) you may discard them . By >>> supplying a script to manage such issues , users of the FreeBSD may also >>> use the associated external directories created in their systems and used >>> during their works . >>> > >>> > >>> > The main problem for the LGPL licensed sources is the modifications >>> performed >>> > in them . If there are such parts they should be open sourced , not >>> the sources of the >>> > user sources . The closed source programs will not be affected from >>> such modifications . >>> > >>> > Some closed source program developers may not want to handle legal >>> implications of >>> > these modified or not modified LGPL licensed parts even when they are >>> distributed because any failure of distribution of especially modified >>> sources may cause significant trouble for them . To eliminate such >>> distribution related concerns , the best action may be to store >>> > these sources into a publicly accessible repository , modify these >>> sources in that repository and use them from this repository . In this >>> case , modifications in the main repository and excluding of these from >>> FreeBSD distributions will not affect FreeBSD users other than fetching >>> them when they are needed , which is legally acceptable and harmless . >>> > >>> > Generation of a package or port from this repository may be necessary >>> or not , >>> > I will not be able to say anything because I do not know . The port or >>> package >>> > generator persons would know such points . My opinion is that the >>> above model >>> > may not require either a port or a package separately because >>> everything necessary >>> > will be in the repository . >>> > >>> > >>> > >>> > Mehmet Erol Sanliturk >>> >>> >> >> >> >> >> >>> So you suggest that "make buildworld" downloads the libnfs sources? >>> That would be a big change from the current setup, where all sources >>> are assumed to be present when make starts. I expect that it might >>> break tools like "make release" and nanobsd, too. Of course, we could >>> always put these tests into tools/regression instead of tests/. That >>> would be easy. But then they wouldn't get run in CI. And I think >>> that CI is essential for any new tests. >>> >>> >> >> >> >> It is very likely that there will not be many ( or high frequency ) >> modifications in >> the repository of required LGPL licensed parts . >> >> Fetching and storing them into a directory outside of the source tree and >> keeping them in there will not be a violation of its license . >> If a modification is applied into their main repository , then again the >> action will be >> "fetch and store them , and keep them in there" . >> In this case , "make { buildworld | release }" or other processing steps >> will require only specification of the global directory of LGPL licensed >> sources ( outside of the FreeBSD base ) . >> These will not be included into FreeBSD base when it is distributed >> but only will be used during testing or other tasks where they are >> applied . >> >> Any user of the FreeBSD , will do a similar action in their "make { >> buildworld | release }" >> or other processing works . >> >> >> Since it is possible to keep the LGPL licensed sources ( by fetching >> modifications from its repository ) indefinitely , my opinion >> is that continuous use of these sources are legally possible and harmless >> . >> ( I am not a lawyer and my views do not constitute legal advice . ) >> >> >> >> If a user does not want to keep these LGPL licensed parts , she/he may >> discard the >> global directory contents when she/he completes her/his job , and again >> she/he >> may fetch and use them . Such an action will be decided by the user with >> respect to >> her/his needs and/or conventions . With respect to LGPL license such an >> action is not >> necessary if the above defined publically accessible repository is used . >> > > > All of that is covered by our existing practice of storing LGPL code in > src/gnu/lib. We cover it in the handbook already. Since it is publicly > available forever, storing it there will have no impact that's any > different than libdialog or libreadline has has in the past. > > Warner > > You are right . If src/gnu/lib is included in FreeBSD base AND some users want to exclude these from the FreeBSD base ( or releases ) then a possible action would be my suggestion ( as move it into , for example , /gnu/lib/... and exclude it from the FreeBSD base , by supplying its Internet access link in releases ) among other ( possibly many ) alternatives . > >> Mehmet Erol Sanliturk >> > > >> >> >> >> >> >> >>> > >>> > >>> > >>> > >>> >> >>> >> >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >> >>> >> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers >>> wrote: >>> >> >>> >>> >> >>> I recently ran into a bug in fusefs that can only be triggered >>> when >>> >> >>> NFS exports a FUSE file system. That makes it very difficult to >>> write >>> >> >>> an automated test. My options are basically: >>> >> >>> >>> >> >>> * Add an fhgetdirentries(2) syscall that is like getdirentries, >>> but >>> >> >>> takes a fhandle_t* argument instead of a file descriptor. >>> >> >>> * Actually start nfsd during the test, and export the temporary >>> FUSE filesystem. >>> >> >>> >>> >> >>> The first option sounds like way too much non-test code to change. >>> >> >>> Plus, I may need to add thread() and fhwrite() syscalls too, for >>> other >>> >> >>> NFS-related test cases. The second option would also be a lot of >>> >> >>> work, but at least the work would all be confined to the test >>> code. >>> >> >>> However, what would I do once I've exported the file system? >>> Mounting >>> >> >>> it with the NFS client would add several more layers to the stack >>> >> >>> under test. I'm not even sure that it's safe to self-mount an >>> >> >>> exported file system. Another option would be to communicate >>> directly >>> >> >>> with nfsd from the test code. That's possible, but writing NFS >>> RPCs >>> >> >>> by hand is very cumbersome, and it would obscure the test logic. >>> A >>> >> >>> better option is to use libnfs. The API is just what I would >>> need. >>> >> >>> However, it's licensed under the LGPL 2.1. I know that we as a >>> >> >>> project decided to import no new GPLish code into contrib/. But >>> this >>> >> >>> code would never be used outside of /usr/tests, so it wouldn't >>> even >>> >> >>> affect many production builds. Would that be acceptable? The >>> >> >>> workarounds are ugly: >>> >> >>> >>> >> >>> * Create a new port for all libnfs-dependent tests. This would be >>> >> >>> hard to maintain, because the content of the tests must be so >>> >> >>> dependent on the base version of the OS. >>> >> >>> * Write the tests in Python using libnfs-python. The tests could >>> >> >>> still be compiled as part of the base system, they just wouldn't >>> work >>> >> >>> unless libnfs-python is installed from ports. But this is awkward >>> >> >>> because the tests are currently C++. So I would have to embed a >>> >> >>> Python interpreter into the C++ code. It would really obfuscate >>> the >>> >> >>> test logic. >>> >> >>> * Store the tests in the base system, but detached from the build. >>> >> >>> Then create a port that builds them by mounting SRC_BASE, much >>> like >>> >> >>> devel/py-libzfs does. It would then install them in >>> /usr/local/tests. >>> >> >>> This is probably the least-bad option if I can't import libnfs >>> into >>> >> >>> contrib/. >>> >> >>> >>> >> >>> What do you think? Is it acceptable to import libnfs intro >>> contrib/? >>> >> >>> It's LGPL, except for a few headers that are BSD and some examples >>> >> >>> that are GPLv3. But we needn't use the examples, or even import >>> them. >>> >> >>> >>> >> >>> https://github.com/sahlberg/libnfs >>> >> >>> >>> >> --0000000000008aa1ab05d4b1d05a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 3, 2022 = at 9:06 PM Warner Losh <imp@bsdimp.com= > wrote:
=


On Mon, Jan 3, 2022, 10:32 AM Mehmet Erol Sanliturk &l= t;m.e.sanlitur= k@gmail.com> wrote:


On Mon, Jan 3, 2022 at 7:57 PM Ala= n Somers <asomers@freebsd.org> wrote:
On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol= Sanliturk
<m.e.sanliturk@gmail.com> wrote:
>
>
>
> On Mon, Jan 3, 2022 at 5:47 PM Alan Somers <asomers@freebsd.org> wrote:
>>
>> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk
>> <m.e.sanliturk@gmail.com> wrote:
>> >
>> >
>> >
>> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh <imp@bsdimp.com= > wrote:
>> >>
>> >> Top posting my reactions (sorry)
>> >>
>> >> I think 'in base as a private library, used only in t= he tests protected by MK_LGPL' is fine.
>> >>
>> >> This would keep it in base, keep the testing happening, a= nd allow those who want
>> >> to omit it. This would also not run afoul of any companie= s that still have downloading
>> >> GPL'd software is a fireable offense, since all such = policies I heard about years ago
>> >> were specifically the GPL, not the LGPL). This is of cour= se a trade off between
>> >> getting something useful from the LGPL software (better t= esting) and our desires
>> >> not to have any in the tree at all, if possible. Adding a= knob would let it be shut
>> >> off easily with all the tests disabled that depend on it.= This is also in keeping with
>> >> our historical practices of having software with undesira= ble licenses as long as it
>> >> gets us something.
>> >>
>> >> I think this is better than the ports options because it = will get more use and exposure
>> >> this way and is more likely to remain working (though wit= h our current CI setup
>> >> adding it as a dependency for that CI would be easy and g= ive us decent coverage).
>> >>
>> >> Warner
>> >>
>> >
>> >
>> >
>> > https://en.w= ikipedia.org/wiki/GNU_Lesser_General_Public_License
>> > GNU Lesser General Public License
>> >
>> > https://en.w= ikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft
>> > Strong and weak copyleft
>> >
>> >
>> > "GNU Lesser General Public License" is a=C2=A0 WEAK= copyleft license ( it may be considered "benign" : it does not i= nvade the user software , affects only the modifications to the LGPL licens= ed software ) ,
>> >
>> > in spite of this ,
>> >
>> > "GNU General Public License" is a STRONG copyleft l= icense ( it may be considered "malignant" : it invades the user s= oftware as a whole ) .
>> >
>> >
>> > Using a ( LGPL licensed software ) for testing another softwa= re is not directly involved in the tested software .
>> >
>> > To eliminate possible doubts , if I were the decision maker a= bout how to use it , I would make it a port , and fetch it during testing a= s a dynamically loaded library ( manage it port with respect to its license= ) .
>> >
>> >
>> > Mehmet=C2=A0 Erol Sanliturk
>>
>
>
>
>
>
>>
>> The problem is that the library, not just the headers, needs to be=
>> present at compile time.=C2=A0 Or do you know a good workaround? >
>
>
>
> You can fetch the LGPL licensed sources during compile time from outsi= de of the FreeBSD
> base known to the testing program . The user(s) of=C2=A0 FreeBSD can a= lso use a similar facility .
>
> For example :
>
> I am developing mainly two programs :
>
> (1) Mathematical Analysis computations
> (2) A Multi-media information management system
>
> These programs are using parts taken from legally personally usable so= urces=C2=A0 which
> can not be used for a ( free or commercial ) distribution . During pro= gram development ,
> it is possible to use them , because they are in there just as a fille= r for=C2=A0 not-implemented-yet parts .
>
> To prevent unacceptable inclusion of such sources into my own producti= ons , I am
> using global directories=C2=A0 outside of the program directories : >
> /KBMS/Parts_to_ be_Removed/... ( Part specific directories )
> /MAS/Parts_to_ be_Removed/... ( Part specific directories )
>
> It is explicitly known that these directories and their contents can n= ot be used .
> There is no danger of including them erroneously .
>
>
> You can define such directories . During compilation you may fetch LGP= L licensed
> parts from these directories ( even though they may be on the Internet= ) . After compilation of
> the programs ( and if they are executed ) you may discard them . By su= pplying a script to manage such issues , users of the FreeBSD may also use = the associated external directories created in their systems and used durin= g their works .
>
>
> The main problem for the LGPL licensed sources is the modifications pe= rformed
> in them . If there are such parts they should be open sourced , not th= e sources of the
> user sources . The closed source programs will not be affected from su= ch modifications .
>
> Some closed source program developers may not want to handle legal imp= lications of
> these modified or not modified LGPL licensed parts even when they are = distributed=C2=A0 because any failure of distribution of especially modifie= d sources may cause significant trouble for them . To eliminate such distri= bution related concerns , the best action may be to store
> these sources into a publicly accessible repository , modify these sou= rces in that repository and use them=C2=A0 from this repository . In this c= ase , modifications in the main repository and excluding of these from Free= BSD distributions will not affect FreeBSD users other than fetching them wh= en they are needed , which is legally acceptable and harmless .
>
> Generation of a package or port from this repository=C2=A0 may be nece= ssary or not ,
> I will not be able to say anything because I do not know . The port or= package
> generator persons would know such points . My opinion is that the abov= e model
> may not require either a port or a package separately because=C2=A0 ev= erything necessary
> will be in the repository .
>
>
>
> Mehmet Erol Sanliturk





=C2=A0
So you suggest that "make buildworld" downloads the libnfs source= s?
That would be a big change from the current setup, where all sources
are assumed to be present when make starts.=C2=A0 I expect that it might break tools like "make release" and nanobsd, too.=C2=A0 Of course= , we could
always put these tests into tools/regression instead of tests/.=C2=A0 That<= br> would be easy.=C2=A0 But then they wouldn't get run in CI.=C2=A0 And I = think
that CI is essential for any new tests.





It is v= ery likely that there will not be many ( or high frequency ) modifications = in
t= he repository of required LGPL licensed parts .=C2=A0

Fetching and storing them in= to a directory outside of the source tree and
keeping them in there will not be= a violation of its license .
If a modification is applied into their=C2=A0 main= repository , then again the action will be
"fetch and store them , and ke= ep them in there" .
In this case , "make { buildworld=C2=A0 | release }&qu= ot; or other processing steps will require only specification of the global= directory of LGPL licensed sources ( outside of the FreeBSD base ) .
<= /div>
These wil= l not be included into FreeBSD base when it is distributed
but only will be use= d during testing or other tasks where they are applied .

Any user of the FreeBSD = , will do a similar action in their "make { buildworld=C2=A0 | release= }"
or other processing works .


Since it is possible to = keep the LGPL licensed sources ( by fetching modifications from its reposit= ory ) indefinitely , my opinion
is that continuous use of these sources are legally = possible and harmless .
( I am not a lawyer and my views do not constitute legal adv= ice . )



If a user does not want to = keep these LGPL licensed parts , she/he may discard the
global directory contents wh= en she/he completes her/his job , and again she/he
may fetch and use them . Suc= h an action will be decided by the user with respect to
her/his needs and/or convent= ions . With respect to LGPL license such an action is not
necessary if the abov= e defined publically accessible repository is used .







=C2=A0
All of tha= t is covered by our existing practice of storing LGPL code in src/gnu/lib. = We cover it in the handbook already. Since it is publicly available forever= , storing it there will have no impact that's any different than libdia= log or libreadline has has in the past.

Warner

=



You are right .= =C2=A0

If=C2=A0=C2=A0 src/gnu/lib = =C2=A0 is included in FreeBSD base=C2=A0 AND=C2=A0 some users want to exclu= de these
from the FreeBSD base ( or releases )

then=C2=A0 a possible action would be my suggesti= on
( as move it into , for example ,=C2=A0=C2=A0=C2=A0 = /gnu/lib/...=C2=A0=C2=A0=C2=A0 and exclude it from the FreeBSD base ,
=
by supplying its Internet access link in releases )
among other ( possibly many ) alternatives .

=C2=A0

Mehmet Erol Sanliturk
=C2=A0
=




=C2=A0
>
>
>
>
>>
>>
>> >
>> >
>> >
>> >
>> >>
>> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers <asomer= s@freebsd.org> wrote:
>> >>>
>> >>> I recently ran into a bug in fusefs that can only be = triggered when
>> >>> NFS exports a FUSE file system.=C2=A0 That makes it v= ery difficult to write
>> >>> an automated test.=C2=A0 My options are basically: >> >>>
>> >>> * Add an fhgetdirentries(2) syscall that is like getd= irentries, but
>> >>> takes a fhandle_t* argument instead of a file descrip= tor.
>> >>> * Actually start nfsd during the test, and export the= temporary FUSE filesystem.
>> >>>
>> >>> The first option sounds like way too much non-test co= de to change.
>> >>> Plus, I may need to add thread() and fhwrite() syscal= ls too, for other
>> >>> NFS-related test cases.=C2=A0 The second option would= also be a lot of
>> >>> work, but at least the work would all be confined to = the test code.
>> >>> However, what would I do once I've exported the f= ile system?=C2=A0 Mounting
>> >>> it with the NFS client would add several more layers = to the stack
>> >>> under test.=C2=A0 I'm not even sure that it's= safe to self-mount an
>> >>> exported file system.=C2=A0 Another option would be t= o communicate directly
>> >>> with nfsd from the test code.=C2=A0 That's possib= le, but writing NFS RPCs
>> >>> by hand is very cumbersome, and it would obscure the = test logic.=C2=A0 A
>> >>> better option is to use libnfs.=C2=A0 The API is just= what I would need.
>> >>> However, it's licensed under the LGPL 2.1.=C2=A0 = I know that we as a
>> >>> project decided to import no new GPLish code into con= trib/.=C2=A0 But this
>> >>> code would never be used outside of /usr/tests, so it= wouldn't even
>> >>> affect many production builds.=C2=A0 Would that be ac= ceptable?=C2=A0 The
>> >>> workarounds are ugly:
>> >>>
>> >>> * Create a new port for all libnfs-dependent tests.= =C2=A0 This would be
>> >>> hard to maintain, because the content of the tests mu= st be so
>> >>> dependent on the base version of the OS.
>> >>> * Write the tests in Python using libnfs-python.=C2= =A0 The tests could
>> >>> still be compiled as part of the base system, they ju= st wouldn't work
>> >>> unless libnfs-python is installed from ports.=C2=A0 B= ut this is awkward
>> >>> because the tests are currently C++.=C2=A0 So I would= have to embed a
>> >>> Python interpreter into the C++ code.=C2=A0 It would = really obfuscate the
>> >>> test logic.
>> >>> * Store the tests in the base system, but detached fr= om the build.
>> >>> Then create a port that builds them by mounting SRC_B= ASE, much like
>> >>> devel/py-libzfs does.=C2=A0 It would then install the= m in /usr/local/tests.
>> >>> This is probably the least-bad option if I can't = import libnfs into
>> >>> contrib/.
>> >>>
>> >>> What do you think?=C2=A0 Is it acceptable to import l= ibnfs intro contrib/?
>> >>> It's LGPL, except for a few headers that are BSD = and some examples
>> >>> that are GPLv3.=C2=A0 But we needn't use the exam= ples, or even import them.
>> >>>
>> >>> https://github.com/sahlberg/libnf= s
>> >>>
--0000000000008aa1ab05d4b1d05a-- From nobody Wed Jan 5 23:58:24 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1B3CC19374B7 for ; Wed, 5 Jan 2022 23:58:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTmf41yk2z4SRJ for ; Wed, 5 Jan 2022 23:58:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92a.google.com with SMTP id i5so1359862uaq.10 for ; Wed, 05 Jan 2022 15:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=jzni5fV+/78HVglEZNxDnLL2eYfTEZ+d5APjatKyw+w=; b=fseG0ILzuLKKJPvssfW+8yvd06lKqESEu/eHRilHt8S6ieYvsRmENOBuSAWKWi9zH6 Lju8z3/46McAXYEgu6VQjV7Q2ZC6GDMcqt5TyhClIP5vuVjLPGU/ukK0skYfoIKvkAjn qq4VrJjx6UtvpThNuhbbJgnBZgoct4/mZk+//8AxeAY9uwhDvCLcaueEd8uaCNN4OYSs m66Hq9/LDfEE3DkGAUaaVcHEeyvt5xiE1b0zgI+bkQ0TiDw3aPA9peVz/ZW3E/m1osIk MD/E+MlwZW5Z+QyUr0gsYQUpV802wEmaJKyFoy1h1GZOFeQ2O7Xv45m/MGG/UE1Jk2sX IPzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jzni5fV+/78HVglEZNxDnLL2eYfTEZ+d5APjatKyw+w=; b=Txdh3+TG18JEMpP/n3ZZ1ZcAOF82i/neXkWYLqzxwTwo0deamJ68ng5MFdRg+Uey+S JU7dyFtphhEtMbodp8lZhqJDnBRNHpWZJjqB5bAwvYlEQJ0/baRLPs5B2yPFJWWi/+eC UOLL+hGLyzgy9yHGgoSI+sPirYsd5Gjuf6Im8HbdDNufZUpXpOX/6Gf9/U65QB4cvZdS /XshrRS6+CQ5FQhNpdERmttVhHEGl0xNu+GiZPuNhYvmsWxg45+g+V6TU3AxkkaGfAJ3 4yLoIhJEZRN2D7txf1+9oqmdkOopSqEx8kQyCHerY7jUEG0AUGfSNLVMxbFNX2+JVHko 6IMA== X-Gm-Message-State: AOAM5337npV2W2+bcxIgSDOzQ7fQ7d1eLlHiKEe3mIKnokyfaFNxgj6C OKl0T+XkHC625gP80+2Cl9dqNWRf1ZpzF4TfkKnuu0FDJiQApw== X-Google-Smtp-Source: ABdhPJxFC+Lv1faZPl2isd3MVNE/afTAHF3p+VpnE5k2H+gEZBUnzZGkOJ0EfrnifQFfIhou9EXzaxVhnZDY4mTTxcg= X-Received: by 2002:a05:6102:ed3:: with SMTP id m19mr18865424vst.68.1641427115500; Wed, 05 Jan 2022 15:58:35 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Wed, 5 Jan 2022 16:58:24 -0700 Message-ID: Subject: libsoft retiring To: "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000024faf805d4de882b" X-Rspamd-Queue-Id: 4JTmf41yk2z4SRJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=fseG0ILz; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.901]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92a:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000024faf805d4de882b Content-Type: text/plain; charset="UTF-8" Greetings, I implemented libsoft on arm for the FreeBSD 10 -> FreeBSD 11 transition from using the 'softfp' ABI (where hardware float was used, but registers were passed in integer registers) to the 'hardfp' ABI we've used ever since. libsoft has been turned off since I added it as an option in 2016 6 months before the 11.0 release. Several people used it at the time to transition their 32-bit armv6 FreeBSD 10 (or 11-current) boards to armv7 FreeBSD 11. Since then I know of nobody that's used it. I think that it's time to retire the option entirely. https://reviews.freebsd.org/D33761 has the bits to remove it. Comments? Warner --00000000000024faf805d4de882b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I implemented libsoft on= arm for the FreeBSD 10 -> FreeBSD 11 transition from using the 'sof= tfp' ABI (where hardware float was used, but registers were passed in i= nteger registers) to the 'hardfp' ABI we've used ever since.

libsoft has been turned off since I added it as an o= ption in 2016 6 months before the 11.0 release. Several people used it at t= he time to transition their 32-bit armv6 FreeBSD 10 (or 11-current) boards = to armv7 FreeBSD 11. Since then I know of nobody that's used it.
<= div>
I think that it's time to retire the option=C2=A0ent= irely.=C2=A0https://reviews.= freebsd.org/D33761 has the bits to remove it.

= Comments?

Warner
--00000000000024faf805d4de882b-- From nobody Mon Jan 10 08:55:39 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7CA641936003 for ; Mon, 10 Jan 2022 08:56:38 +0000 (UTC) (envelope-from list@johnericson.me) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXSP15c8gz3MyV for ; Mon, 10 Jan 2022 08:56:37 +0000 (UTC) (envelope-from list@johnericson.me) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D10563201EA6 for ; Mon, 10 Jan 2022 03:56:36 -0500 (EST) Received: from imap44 ([10.202.2.94]) by compute4.internal (MEProxy); Mon, 10 Jan 2022 03:56:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnericson.me; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=CD/isUhBrG7lB5S2SzFkAGdhGKVHbfqRsuJYJ6XW7Tk=; b=OSqcLYVZ oFE9wDYwK7Ezhdlxb/v6Cpq7CWmqyCwVMxJogmD1nZEuyet+Nkf2tD17bQ6FKwN+ BTQvgUUuccaQHKr5QkLVfpU7Z7QrIDD+bdFs7GTwwbs/6fsc21aJ12tY0HZlVTck FATZCXFWbIfEVJ7lDQt8tX1WV4KJN6qOpPrKy/UqFSpopE5G9+gRiT/ohZjuJBo1 yyi6nzgiDSfXvLDnZQNQlvPMp+bisXaEAwaTg4iea8bnii3ZyGLyIw5s8OPROXIH B7sCftr562ADvNKbeM6thPOhjohiPeLytv7vrRwXxI8S0z0CuIt9nrBFwYDoMkLq SBpAyLAFZFjpBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=CD/isUhBrG7lB5S2SzFkAGdhGKVHb fqRsuJYJ6XW7Tk=; b=Z6WjjFjiAOShDUhBtLBMPefakGXsApkdV086/gQ1YDaEM Qi08t+WIAhZAC7oUkkUzpl46Ca9hCgF6/43/pzmMhEdPcigGEQ2OVROxtLRTNaU+ gx8/aYqW2h9qkXtPIYCpQMz0CO8OWLvL0Y9NXhSJX3cdszaTQiPEYPbWRYJxfFu9 Ty02S/SVBvBqIZOeJeQkG7cXybuh2zqKEFOw44iqdzUsxrU7ibTNWwipWdTKeSxZ e11sjZNGp5+EuwdZYg+uSd9bX0Ht6XB69pafW3ea625MPI3cjN6XE1+svh1w+uc0 5utML84xmWx+Fq02ZPmzEaM/ZcvWU7l/AKBNBQMOg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudegledguddvlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdflohhhnhcugfhrihgtshhonhdfuceolhhishhtsehjohhh nhgvrhhitghsohhnrdhmvgeqnecuggftrfgrthhtvghrnhepudeifeekffetffelffehgf ehteffhedvfffhgefgueetveeigeejtdfhkeejtefhnecuffhomhgrihhnpegtrghtvghr nhdrtghomhdpkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheplhhishhtsehjohhhnhgvrhhitghsohhnrdhmvg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1DD2AFA0AA6; Mon, 10 Jan 2022 03:56:36 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4527-g032417b6d6-fm-20220109.002-g032417b6 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Message-Id: Date: Mon, 10 Jan 2022 03:55:39 -0500 From: "John Ericson" To: freebsd-arch@freebsd.org Subject: Leveraging process descriptors for process creation without fork Content-Type: text/plain X-Rspamd-Queue-Id: 4JXSP15c8gz3MyV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=johnericson.me header.s=fm2 header.b=OSqcLYVZ; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=Z6WjjFji; dmarc=none; spf=pass (mx1.freebsd.org: domain of list@johnericson.me designates 64.147.123.20 as permitted sender) smtp.mailfrom=list@johnericson.me X-Spamd-Result: default: False [-4.09 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[johnericson.me:s=fm2,messagingengine.com:s=fm1]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[johnericson.me]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[johnericson.me:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.20:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from] X-ThisMailContainsUnwantedMimeParts: N Hi, I have long been interested in seeing an alternative to fork+exec implemented in a real-world Unix OS. What I have in mind is: 1. Load an executable into a fresh new unscheduled process (we might call this an "embryonic" process) 2. Set file descriptors and other state on that process 3. Submit it to the scheduler I am far from the first person to think of this interface, of course. Since becoming interested in this, I have been referred to this paper[1], which very nicely describes the concept in detail, and also evaluates an all-userspace implementation of it. I must admit I first emailed the Linux mailing list about this.[2] The reception was positive, but the multitude of other features[3] supported in the relevant code makes refactoring it to elegantly implement both the existing and new interfaces a rather large task. I checked, and FreeBSD's fork and exec code is, surprise surprise, a great deal simpler, and therefore a better venue for demonstrating this feature's viability. Also, as I am interested in the feature in the context of efforts like Capsicum and CloudABI, FreeBSD is a natural starting point for cultural and historical reasons. I am under no illusion that, even with FreeBSD's comparative simplicity, I will have time to finish this project in the near future, but I hope it is still OK to discuss the merits of the idea itself. Thanks, John [1]: http://catern.com/rsys21.pdf [2]: https://lore.kernel.org/lkml/f8457e20-c3cc-6e56-96a4-3090d7da0cb6@JohnEricson.me/T/#m6be1994668e6f34837496c86f37f9fe52bfae990 [3]: Especially binfmt_misc, if anyone was curious From nobody Thu Feb 3 05:45:22 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DCAD719A89CA for ; Thu, 3 Feb 2022 05:45:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jq71c4f3mz4lWR for ; Thu, 3 Feb 2022 05:45:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92a.google.com with SMTP id b37so3216953uad.12 for ; Wed, 02 Feb 2022 21:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=DHl+AaN78lKy+y2NEl3D15HFu4lnqiaL+bcPLscsOks=; b=4G9baxTrqLJ+4ggT4gdF81JRObemuQzGkJwPInYeLOIceHCRfI0iQr/eZsxKW9Q3xY vYAjU0bzVUkgR9zWgkKhT1/wGwZNYJXGYPsiAwg5ChoKwah8J/G7JpdTOzYAX6P93jgE qZ9UOzT473zp2kCfM+3DPO5iRPRqsSOeh4NrzFA1wS9QN0kZ0ksv4YbPVdItrSm5QvaU gnttslLsBWHDoUNnxY+AWvGeIfv0XXFSx8opGnpAFHfnjhgMupzy9Y1wYQk3Eq4HFwmN gLIwnSlJo0BGgWvthmeD9ba3MIV8l2NghfNcyDpZYPJVfBUvzrDrikIEf1SkUOy2daIx ytiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DHl+AaN78lKy+y2NEl3D15HFu4lnqiaL+bcPLscsOks=; b=FA6EvAt+Fyg+b1Ii4K8F7qpg1CqlMVq+lMWXuA5rcMfqvhXihCx10iiANNsxDCC8IM 2SvWolQRjc+BEXQC5FlJyrBMYsr7ckllAPltXDS/p1SNJ5jKxjoIJ4NVgnHevU0hPngu JP/pbS5RaIQDxOdZXn4vEqWvJWat0CNG9TLWwlE+CdYlIslMtSiby2Wauc0O/aGCMggS b3MZJ28lYfqFUmngDPkukAfh9s/Zl1S2yzDoGWlYazZfPALU367qYrYRNk+qTfgtIDHo 352WBswEIfYVNrK5BMb9FVBYONgaAaZNU4EandNjjypS1LMC8ree6jlPQdNAEEg69xTQ IVPQ== X-Gm-Message-State: AOAM533ooqdLBz8gruBWz6Tj8AnuWXgMLI6BlIiaz2CS4XXjlOrKeN7v 8SmeYqEAQPXYbCEf8l9LUc/0SVYVkudF1W40j9CoftTkT4nGRQ== X-Google-Smtp-Source: ABdhPJyEKEWgf6WUT9M3+aa/rlQdHHpKlpMH9V8qT7ystggizsArwmyt/f23PlabHMoRRX4gSyfOY7j0NJynWDOAeIM= X-Received: by 2002:a67:33c9:: with SMTP id z192mr13412463vsz.42.1643867133427; Wed, 02 Feb 2022 21:45:33 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Wed, 2 Feb 2022 22:45:22 -0700 Message-ID: Subject: Style(9) tweak To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000008bd6df05d716a459" X-Rspamd-Queue-Id: 4Jq71c4f3mz4lWR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=4G9baxTr; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.98)[-0.984]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92a:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000008bd6df05d716a459 Content-Type: text/plain; charset="UTF-8" Greetings, Please review https://reviews.freebsd.org/D34152. I've strengthened the admonition against $FreeBSD$. After this change, style(9) recommends that you only include $FreeBSD$ in new code you are sure will be merged to stable/12. If you later decide you need to merge code to stable/12, you can always add $FreeBSD$ just before the merge. Also, since stable/11 is no longer supported, I've removed references to it as well. Thanks! Warner --0000000000008bd6df05d716a459 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,


I've strengthened the admonition agains= t $FreeBSD$. After this change, style(9) recommends that you only include $= FreeBSD$ in new code you are sure will be merged to stable/12. If you later= decide you need to merge code to stable/12, you can always add $FreeBSD$ j= ust before the merge. Also, since stable/11 is no longer supported, I'v= e removed references to it as well.

Thanks!
<= div>
Warner
--0000000000008bd6df05d716a459-- From nobody Sun Feb 6 22:15:19 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1F85519B121F for ; Sun, 6 Feb 2022 22:15:31 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsNrM0NdKz3CyJ; Sun, 6 Feb 2022 22:15:31 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644185731; 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=YH06QaQcre4fdDkPb0ZjxJ2iNwHkJa6bC8i4ZNUycMc=; b=myASYqhuW262CLwey6pE91XoIbaBJTMm5GtiXU8/G+5km6vbh/+hPGKUeOVf22G/V50SF7 o2g+cjfoLU8n5HOMrZd6aZErz+3Ulqva8beij2HIEgrr7R/4qqI0CXqy9P1Sq4Pg6BuE9X bL3ImiT5TN5aPPjj+sDHdbAVLB/GTp4aomQy22vqreXsRzzdBq1mWqeByvAF8X55MyM8ey YTE+KGcUwak0CnhbDg5RAHvfcAt+vtQUUOFU8UHdv3rpYQ4SS+l+uQ8mSHeYmLe+Ra2tRd 7YUOucfwZ1ahxMjAj8BXF7wiK4Mp8CaFg+rBW0ZcNfRzlwKOU8LPaFoCsHiSNg== Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id DCD4625297; Sun, 6 Feb 2022 22:15:30 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f169.google.com with SMTP id v5so10539573qto.7; Sun, 06 Feb 2022 14:15:30 -0800 (PST) X-Gm-Message-State: AOAM533D2N2vhUboDVmbMgZ6onRR2IzumJHuVi6nGjDF2V7CJwrYpFUU Nuqv6WbL5IrZMPrQqzQGxlnDXouC21D2m3R83S0= X-Google-Smtp-Source: ABdhPJw/SyvVSPh1lvhlv+KuHZy7bBEMCL0HBmfwxy+GEmE9cU6mPW7nlKb+gsYzzd3RBC6mb32gso8bNxgOH48hncU= X-Received: by 2002:ac8:4b59:: with SMTP id e25mr6055359qts.444.1644185730439; Sun, 06 Feb 2022 14:15:30 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Sun, 6 Feb 2022 16:15:19 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: _FORTIFY_SOURCE Implementation To: Kyle Evans Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644185731; 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=YH06QaQcre4fdDkPb0ZjxJ2iNwHkJa6bC8i4ZNUycMc=; b=hA8BcVx/Klgxemkwrbw3w2yQzcFx71/PLjV2zcDs8TsATbYgxYqB1yqFAkbS1D52CHtUGx a4nOd6tqJCUwYzkLyGDvOAECLj7vXiKg3lycXJnnHdVKfxqYKjbAmCEmDA2kQaZt/BT1CB UNoZnN7x4bS1w6Ebg4xzSwW621L10YZjvQpiZzmYUbELwjjQsCCkpmCPW5cdBA9yx/hzgt sfcjiqphE5hR/k92Wk6nKX+ViInYnaGsJ682bKtTmqJz1hRVbxBV9T7ybnd7eeoC+dEr7X ZNgdH0LWH2ZukjRA6Xd9qzaS53VWBO2txIb4tekG5Hh56nuilAEp9h00Wxh9bw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644185731; a=rsa-sha256; cv=none; b=Qt2HnxvsbycaVifoG/uyc4V+W6aHFFbQKem5NOG/M1wFwnHR2MoAxaKZeApTKvXhGV1wSK IoSocz2GzMsp83VppJYgtvyJvfEjUV091y1riwu3IoKnC1xJQ+0RU80R0q8wR+9sNp4zE8 3NX5NebIlKiA+xrcZyLgSwfpAtmfha/GVRkXsBJrR3Lx/U4VF6CTKCtbmLWK2ENWz3bsZm GEEzmx/kXr6Bv9SEJ4yGNrSq73awmLByfHpUPCNqqw0rmj2m8j3gKAaItaNpLcnlBxufWX bv243vSq+dyVbmykl6LLJntoc0UobQdG5md0eXiPnLbjuL3ZgmeJDhdmUbF6iQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Oct 4, 2021 at 11:01 PM Kyle Evans wrote: > > Hello! > > I've just created three reviews to import and enable the > _FORTIFY_SOURCE implementation from NetBSD. For some light background, > _FORTIFY_SOURCE attempts to detect some classes of buffer overflows. > > - https://reviews.freebsd.org/D32306 - Import _FORTIFY_SOURCE > - https://reviews.freebsd.org/D32307 - Prepare for _FORTIFY_SOURCE > - https://reviews.freebsd.org/D32308 - Enable it > > D32307 is perhaps the most interesting as it hacks around > _FORTIFY_SOURCE redefinitions in libc. Other prerequisite work was > needed to get this to build at all;`main` as of the bc 5.0.2 update > (f774652b0e837b) is required. > > The last review enables it by default at FORTIFY_SOURCE=2, if building > WITH_SSP (the default). It respects a "FORTIFY_SOURCE" make(1) var to > indicate the level, so either user or a makefile can disable it as > needed with FORTIFY_SOURCE=0. > Hi, I'd forgotten about this patch set until some recent -Wfortify-source fixes started going in; I think I'd addressed most of the feedback months ago, and I've just finished addressing some feedback on the manpages introduced. I'd like to maybe try and land this within the next week or so. Thanks, Kyle Evans From nobody Mon Feb 7 16:40:39 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0E84419B6C11; Mon, 7 Feb 2022 16:40:41 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JssMX6qNKz3Hdp; Mon, 7 Feb 2022 16:40:40 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644252041; 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=T/KoK/hQoOv46E6KCjFqedmVwze2aU2XSbb7gzvWPcQ=; b=UW//J2e6EJPVioIyKNM19XdQNYfD7snsV35WAkh5HcqWrIHX0pKJ8x0/eYlEVM+Scs9gfn vkSNb754BbY+3Bnzggo0RMmX0BKzeblbEZUqMFktFE1Ifsp3He6023hqdnk486R7i2VzGq bCYoWzy2xHZFdvCxksq4FJgsj3YjMz8lVEHFkWQFkVty7uDYkZ4i3gjoCuuXJcpR25Y3hl XJ5VZcL73pHSrSp5fvFPYjwwhy2H0D1o0OEJXmkWtEn5ijDhfoEj4RKBg/d0pZjyz4mqsp /HZwOJnPQo3WW4isCqUERyb7ZCKRqyuA8vmXCHh+jGLRLibcHusB+OcpRX4m9g== Received: from [192.168.1.106] (host-173-212-73-28.public.eastlink.ca [173.212.73.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 9956B2E6B4; Mon, 7 Feb 2022 16:40:40 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: Date: Mon, 7 Feb 2022 12:40:39 -0400 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 From: Mitchell Horne Subject: Re: A new boot-time trace framework To: "Bjoern A. Zeeb" Cc: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org References: <5E5F06E4-F0FA-45F9-B121-88C69CA15A25@lists.zabbadoz.net> Content-Language: en-CA In-Reply-To: <5E5F06E4-F0FA-45F9-B121-88C69CA15A25@lists.zabbadoz.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644252041; 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=T/KoK/hQoOv46E6KCjFqedmVwze2aU2XSbb7gzvWPcQ=; b=Ssi+58zxyS8AQjffHROJ7oVn3DKzQ/rJyCDDwsk35TJ87nvWWmUzYUSCzKg9sYMTASxy7g aUcWIcyCutrrJkq0k26NPbdEuKnKluor0LROB8VIGXKOy+hVWWqgmTtVf9GwO8+OgqEyRF HxbbUfO0Ft2mbFqqaBtaRg5L6963gmBjZQaElBwgueHv/EfCKSnvK+rF7LsZpmg6pmK1UI 2DvbAu+V2LJupuwRoVaESBJAzRyrGvdNvl/98uM8cCcyVqARMwSGIZ7Y3smNpRze8UVpjo YyjL90N0F5t6ZZ2Km5PQqxLkarK6uAqDvzPl7IrT+3v2G0Y5xkwBrf8s0X+Abg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644252041; a=rsa-sha256; cv=none; b=iNyTUWjgP1k7ZDRM/3fOrdnsuj6IqWuj/9unyW7HHYipNFiM/DsS6iqHxhZNz7yo+Gks1+ KZ4p5H/M9bdFwVn4QArk9Q/zqAfQzXspjjByHNmlH8OFAYY83HsqctXn3stzMMvz9e1Bcc aSZvjmx2yioDV0AujmCjvNeSpn3VORX9p6k1uSHQq61UMIDoK4RI66jyfxTma3bqL1Hsrm 4qaMmEc01vqY/WRW+EWO0Bnf53LVWkbxl+mFsgGtTZSn5oADyCQCiL1AFGoj9kyd5nAVux ClfTL14QROCIIR3QPIMfEFAqaGFOMdU2MmAdJY/iWbuWyJl0fdVt3IazOP63sQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/10/21 13:39, Bjoern A. Zeeb wrote: > On 10 Nov 2021, at 16:26, Mitchell Horne wrote: > >> Unlike TSLOG, I intend for this work to be compiled in to the kernel >> by default, but disabled behind a tunable (kern.boottrace.enabled). >> The cost of doing so should be minimal, only a couple of syscalls >> added to init(8) at most. > Hi, apologies for my delayed reply here. > I think if you really want to have this on by default (whether that make > sense or not for the majority of people) I’d at least avoid the function > call and reduce it to a branch which is super-easy to do. > Good suggestion, the latest version has this change. > My honest feeling is that another of the at least 3 other tracing > mechanisms existing these days be better extended and improved rather > than another one added;  we were always joking about 3 firewalls but if > we keep going this path we can soon start joking about 9 tracing > mechanisms and that will be a major mess for sysadmins.  I can see from > when this work was coming and back then it might have made sense this > way; but more than a decade has passed.. > Thanks for your input. In general, I agree with you; it is preferable to extend existing mechanisms than add something new with duplicated functionality, and I tend to look for this option first. Conversely, I feel that a one-size-fits all tracing framework is not possible, as what data is captured and how it is presented is highly dependent on the meaning/nature of that data. Put differently, we will always require more than one tracing mechanism for different types of tracing tasks. In reviewing the existing tracing options, I did not find that building this functionality on top of them to be any easier or more desirable. TSLOG covers much of the same area but with a different notion of tracing (i.e. recursive event tracing based around function entry/exit as opposed to one-shot events). The intended consumer of its data is a set of python scripts, so it is presented much differently than the human-readable log of events that boottrace produces. KTR has a KTR_INIT class that appears completely unused and comes close to realizing the same purpose, but would still require the addition of a whole new interface for creating new ktr events from userspace. Rather than bend these existing tools to meet these needs it seems better to me to leave them to do what they are good at, and instead add something new that is purpose-built and equally limited in scope (for which the work is already complete). > /bz On another note, it was misleading of me to call boottrace a 'framework', as this implies a much wider scope than what it achieves. More accurate would be to call it a facility. I intend to move forward and commit this work later this week if there are no lingering comments. Cheers, Mitchell From nobody Mon Feb 14 11:03:47 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C4F6E19B0799; Mon, 14 Feb 2022 11:03:58 +0000 (UTC) (envelope-from akamit91@hotmail.com) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11olkn2041.outbound.protection.outlook.com [40.92.19.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jy1Yn4zdWz4l4W; Mon, 14 Feb 2022 11:03:54 +0000 (UTC) (envelope-from akamit91@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MakKzml3pVjjCu+i3il1+BbSZfvU1XUqVNud1+l9DAHfpHy5BzWpcBk+KEUzPI+wxOukci5j6VgGwNhFX0tlYeKqDmkwUTVBp8DV44FvoQbpc+DzXnCvk111W2UQ+tURigaZa3miqRkdpVxgYq8I0RjS4yt+u+xJSThLA8JtpIRLrTN9cWL5LDmtVP1E7iqiKcxrywxmpgU4rHklGKmwEjazwtHJrzD/zy9iwiVRtplmbl1DycZ/gHJfBZI1AdqRDAWOjUGkKioEg2K3fOWDtavnL8YBO/mitnVuDhDXl20SB/g1REG7bSXNCs2bK1ajEIvqURPUqByUR/WPQeLDqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nCglUqtXDQKn1NhKrLShLPLRpt/o5ztTKiM6oDGurvI=; b=hAzgtImI/SVoo5CvmtNdzo3ClWQ4S8BNKf9NO2XjVlEL88dbeY1PyTrR2ZrsEqjDJVSlnylwYQXeLP2BA4GCAXHeTcL0TF1fsx6yY2lAGeVklo9XRcdQ3hzrAIw68olbBHvxoqXjw1kmMRuCm5DtOFdku/9yLeHEoIo6/O9W950vAaZntCq8swtWackcVmA43fULVYYvloWgGNvzUebS6RoiE/L3aSIISrJ1xfSic1WafDDhz3qxiylmhqn53hqCGOGWeMGdhTIU8U1c4OoDCyDz1TB3JnpTy4d3+PXtPPDeYop7QyHrb4fpD4Lqd91cev5ka9Cu93PrkKFC7H4hYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nCglUqtXDQKn1NhKrLShLPLRpt/o5ztTKiM6oDGurvI=; b=ilOcNMRozmZXuJufjmGrCLsxsGt+UQXJSIGuFWzOFQ1yagge7FZPuuoZ46ATnV0lGpQGOQRyuPLg0NNQif4CgMCqAUQN7ZVLP+r56e0Ey9b+ODUl/z/hQLRGh5iO9zv2HFpGSQR2e4zWz24KYFLVDdEHIwqGbcgwD3D6dSGyQwAtpmA++H6Z9OCmR5X5B2zSi5cB5Px9lrpTyy2yuuWE3nzq1n6M9vtwX2rSRt5V0f7wCcRZT0BI0zl9z12jPS+7FhnZLdZMFnTVv7RvmSB/oNOMVqKzaHMoLWfEVZdNw58DmbaDbblTKwWLjI6fB04i5bv7TPSUGRoaHxmYC4h8Mg== Received: from SJ0PR18MB4932.namprd18.prod.outlook.com (2603:10b6:a03:40f::17) by DM8PR18MB4472.namprd18.prod.outlook.com (2603:10b6:8:29::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.19; Mon, 14 Feb 2022 11:03:47 +0000 Received: from SJ0PR18MB4932.namprd18.prod.outlook.com ([fe80::7c29:2fa5:e2d9:a913]) by SJ0PR18MB4932.namprd18.prod.outlook.com ([fe80::7c29:2fa5:e2d9:a913%4]) with mapi id 15.20.4975.015; Mon, 14 Feb 2022 11:03:47 +0000 From: Amit kumar To: "freebsd-dtrace@FreeBSD.org" , "freebsd-arch@freebsd.org" CC: "markj@FreeBSD.org" Subject: dtrace fails to trace on FreeBSD-14(CURRENT) with ASLR and W^X Thread-Topic: dtrace fails to trace on FreeBSD-14(CURRENT) with ASLR and W^X Thread-Index: AQHYIYwcE2zkkoggs0iIye4ydJzSsA== Date: Mon, 14 Feb 2022 11:03:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 0f29d0e1-d00c-57be-6602-6da277a4689c x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [uJN6ZPyltwb+LPcOGJ8YkQ26POYztG6T] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 900f683a-a6b8-448b-0e7f-08d9efa9ac6f x-ms-traffictypediagnostic: DM8PR18MB4472:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zZgVF8iUHIAdVKT29jJHlh7VPnRYOgkbkc4+UDKYARfWFpJnTBCa6L+7ojjcNCYbxNToJ3ETrCL6XESJwyc+wYu1pFum3vrg6gjYHF2CKm1BwzSgjt/CbjLnqQuU9xh2iKcUdywKp6zsVlwqwtBxZ/vOqUIIFOomceSvZrIvyKhVXsmIlnNHQmZ3hNSd86J2IFlLYTc+HCC7md54HE5N6dRRxEHc/55h9z3Ja743ei9BRvtdlyx3swY7IH8YSkjCv9lnJnpHDRl+3l5zHwzRUplVHuJg4H0fxEiQZQytkMRXUhViw6PF7CgptzRDThlUypvb76ESvMyrUjlGBVVtYOYgB2ODGNOGYmRBBx9PJbXVsW61dscSuqZLmCs9bcVmHhCjtr06dR+vshjnoCmYcX59QucEHVXh5MCHJBygSEhtsCMxSc4SJb+9dIKnMtDhQyGxDpWHyHHELuRG56W5OEMVNnY5RVOKMQLYkJtWQdf6kM7JPh42Bp9NoNtp1y7VaqSePz4jRMKAd2PKrBbh7gWQvfprcLSJHMDBRfMcpyB9d32k1Eccf9kWQgMoy7LDtyWpaIPIUHs7JP2M23YPiw/H2DLajrl5HxZWAcOgWrkSU5iYMCaYeZmAxzb3ATdE x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: neqHftvqh6C10+Y6u9Dy9uXQ5QczXfw9eaOfpjFbQpIGTtZJxxFBmGsy7wUG4FOyUtQIyxR+lnfa//U1eM1u2Eeakssm4E5k2phHLI02mi2m7VxWEVl+pB+90dZ0AJxdENyQZt6ERJ/maoab566XxRo3ksHdl6zfrQnpIAxwwpPqXyZHcDaz8osir3yE+sanDPd3aDEM2gMutbADJ8IyVReysqfpc/VWodgxNipIhGpVMP4wt9HAj1WnUr4PRDWki9cjpoztn3se+VU/6HbBHjEVbwNJKtKtzQ+2DQZOcK4L1JVSoSjEsAedh5gZWvzY51/DEU/kKdSstmwVF3yeM6U7nw+bWvAWHRfZ7i3etqP7AMSmE68z5ur+73TgDXGTOe2IGsVoea3RfF4tz2j2pmr2/8ZXf5ZB7adLhnfgRdXNw5x2u9i8hfy62WMe4BWWUPLS041NIj+EQGrdJEErxagWSd6zSgXr73AIDIUGyrOc3tkAjCIjAti2xJJA1qnaXT3IWYHddkJiAaPciHW3epY8PpudSF7XRY4BrTE9JsDQMFlES6/jA+fQXcNda839FpZTkyeXbXpYyeqkeq2RgLuhGlXD0ZU36oGyM1ZcwbK+YQ7KM0jk1E2rFzT6FdFFChk57OFGZzKtZRkGeI5dUFLOgWVKouaFaBWagqz6UNfiWhvWvIJT/umdfofTF6uSGRUnpBC5Ug1rvurkwwba6mPyIjqcQVMTi1uL5Y2zatUlkjrkPIV/jgg3OAp1CEk9MB8f+NXcMzZqYUqwjXRKgJgwtwLOgjv8vj7nlq82BvEIop0pbKJwLQ8obH2xdPgsC3efuHfOa9rKpyKoGuaIFaYfcv6kPgtIv9GJai2pNEsW73UiQmCiaglKeUVYEETrTRQX95C4rgmmZGiFqnMkmmKJmY+R1Bp6KVpJd1g53N5UNXpyxc9GMc/q+SwYPnOy Content-Type: multipart/alternative; boundary="_000_SJ0PR18MB49326C3D1DF915EB841CC2D8DC339SJ0PR18MB4932namp_" List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-db494.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR18MB4932.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 900f683a-a6b8-448b-0e7f-08d9efa9ac6f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2022 11:03:47.0481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR18MB4472 X-Rspamd-Queue-Id: 4Jy1Yn4zdWz4l4W X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hotmail.com header.s=selector1 header.b=ilOcNMRo; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=hotmail.com; spf=pass (mx1.freebsd.org: domain of akamit91@hotmail.com designates 40.92.19.41 as permitted sender) smtp.mailfrom=akamit91@hotmail.com X-Spamd-Result: default: False [-4.91 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.19.41:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[hotmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[hotmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[40.92.19.41:from]; NEURAL_HAM_SHORT(-0.91)[-0.912]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-dtrace,freebsd-arch]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --_000_SJ0PR18MB49326C3D1DF915EB841CC2D8DC339SJ0PR18MB4932namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Encountered this issue while running https://github.com/freebsd/freebsd-src= /blob/main/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/pid/tst.empt= ystack.d a somewhat simpler method to reproduce configuration file /usr/bin/find /usr/bin/find: ELF 64-bit LSB shared object, x86-64, <.....> kern.elf64.allow_wx: 0 kern.elf64.aslr.pie_enable: 1 kern.elf64.aslr.enable: 1 # dtrace -n pid92817:::entry dtrace: description 'pid92817:::entry' matched 4380 probes [2] + trace trap (core dumped) exec find / > /dev/null 2>&1 # exec find / > /dev/null 2>&1 & [1] 85293 # dtrace -n pid85293:a.out:: dtrace: description 'pid85293:a.out::' matched 6828 probes [1] + trace trap (core dumped) exec find / > /dev/null 2>&1 CPU ID FUNCTION:NAME 1 89149 find_execute:1f8 looking at find core in gdb (gdb) p $_siginfo $1 =3D { si_signo =3D 5, si_errno =3D 0, si_code =3D 3, . . . Can someone help me understand why am I seeing core due to SIGTRAP TRAP_DTR= ACE ? Regards Amit --_000_SJ0PR18MB49326C3D1DF915EB841CC2D8DC339SJ0PR18MB4932namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

a somewhat simpler method to reproduce 

configuration
file /usr/bin/= find
/usr/bin/find: ELF 64-bit LSB sha= red object, x86-64, <.....>

kern.elf64.allow_wx: 0
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1

# dtrace -n pid92817:::entry
dtrace: description 'pid92817:::entry' matched 4380 probes
[2]  + trace trap (core dumped)  exec find / > /dev/null= 2>&1

# exec = find / > /dev/null 2>&1 &
[1] 85293
# dtrace -n pid85293:a.= out::
dtrace: description 'pi= d85293:a.out::' matched 6828 probes
[1] + trace trap (core = dumped) exec find / > /dev/null 2>&1
CPU ID FUNCTION:NAME
1 89149 find_execute:1f= 8

looking at find core in gdb
(gdb) p $_siginfo
$1 =3D {
  si_signo =3D 5,
  si_errno =3D 0,
  si_code =3D 3,
  .
  .
  .

Can someone help me understand why = am I seeing core due to SIGTRAP TRAP_DTRACE ?

Regards
Amit
--_000_SJ0PR18MB49326C3D1DF915EB841CC2D8DC339SJ0PR18MB4932namp_-- From nobody Tue Mar 1 19:04:34 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C292519EC7AD for ; Tue, 1 Mar 2022 19:04:42 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4K7RWY4dw8z4lFJ for ; Tue, 1 Mar 2022 19:04:41 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 221J4YpI032168 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 1 Mar 2022 13:04:34 -0600 (CST) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 221J4Yg8032167; Tue, 1 Mar 2022 13:04:34 -0600 (CST) (envelope-from mike) Message-Id: <202203011904.221J4Yg8032167@mail.karels.net> To: freebsd-arch@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: support for asymmetric CPUs List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32165.1646161474.1@mail.karels.net> Date: Tue, 01 Mar 2022 13:04:34 -0600 X-Rspamd-Queue-Id: 4K7RWY4dw8z4lFJ X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [1.82 / 15.00]; HAS_REPLYTO(0.00)[mike@karels.net]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.994]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_LONG(0.52)[0.523]; DMARC_NA(0.00)[karels.net]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Has anyone been looking at scheduling issues for asymmetric CPUs like those with performance cores and efficiency cores? I've been looking at this a little, with Intel's Alder Lake as an example. E.g. the i7-12700 has 8 performance cores with SMT (hyperthreading) and 4 efficiency cores without SMT. The E-cores are supposedly better for threaded processes. Intel also has a hardware/firmware facility to advise the OS about process behavior to guide placement. I don't know much about this yet, but there is supposedly support pending for Linux. Looking ahead, the Apple M1 also has asymmetric CPUs with P-cores and E-cores. (Does FreeBSD support any ARM chips with asymmetric CPUs yet?) It seems clear that there should be a generalized interface that supports machine-dependent configuration, even if the hooks mostly end up pointing to machine-independent routines in the scheduler in common cases. I'd envision initial support that just looked at CPU usage and adjusted the cpusets for threads that were using the default cpuset. I was also thinking about exposing cpusets of P-cores and E-cores for use by knowledgeable user processes. I'm not sure whether it makes sense to try to generalize beyond one dimension, higher-performance and lower- performance cores, e.g. for vector-heavy processes or other potential asymmetric capabilities. I'm not sure how to generalize more, so that could be a future exercise if there was a reason for it. If anyone has thought about this or has done any work on it, I'd be interested to hear about it. Mike From nobody Tue Mar 1 19:58:19 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A99E519F62EB for ; Tue, 1 Mar 2022 19:58:27 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7Sjb4QbGz4rcs; Tue, 1 Mar 2022 19:58:27 +0000 (UTC) (envelope-from peterj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646164707; 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=jehNAA6osCRHmYk554PvKpGK/pucKNrCgC+go7NidWM=; b=SPd9L4jy4YHof2+PUiiaX4iOIiD2XyFBJ0uVz0xAOQ32SlhU5uuFDMPJ0mpveUUNWX7TOm w/f/8cBB74gem6n8yvjxERlPBWRgIlHiRl+EgJmzMunIWDXJjBj/ErnznwVMq9Oz2nk+I0 0LCspQwTptX62pl/Qh4S9aT58rVNBfBjA/sRAmM7AELwfOA1sbSYlAFH/NLCUq56oGvbPp 5o2dMeqVHbDmNoFb/pR6Y7ZQMM6FIs2a9BmuViK19L6GnrrcYLKIbS5HBVmVi90oW86NaB mt3Yp8K/p4io08SofFFKNDe99ZhjLOUdOySoRoxbzCg1KJw1H76vbUYvEx7Aww== Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 7473EAB94; Tue, 1 Mar 2022 19:58:26 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Wed, 2 Mar 2022 06:58:19 +1100 From: Peter Jeremy To: Mike Karels Cc: freebsd-arch@freebsd.org Subject: Re: support for asymmetric CPUs Message-ID: References: <202203011904.221J4Yg8032167@mail.karels.net> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hE2a7nJK79M1wdjr" Content-Disposition: inline In-Reply-To: <202203011904.221J4Yg8032167@mail.karels.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646164707; 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=jehNAA6osCRHmYk554PvKpGK/pucKNrCgC+go7NidWM=; b=qBZOC2cY/X13QVQdPqaa0QS+zpo4Wluu7S6hKx5cxL5GX1VR8uoQIawY2tLQNSQpuHKCy+ jRM853nszcCpuc7B2mHP8nRfEAL8xrVaphgRwNX8ycQ5wgSSv96aOR04Ca/Z0RIwS0sIqb n1891dy7cFa9XhHjJvhCChNci0csMJRsVbRoxPNKLUVVfm+mxBKOklF/k7qzoAGbWRdsAl K4r1SEMRqQR1p262PNJMW1mvz6S8oXCeCrGSlAz+ps/JGsesE5NK33iSCzt7DWoSGRq/52 0xp1vYVkRMegvjFV9f1JCEmyli9DtGD6kVEQLHkDMfmjW0E59f3ZxI6b6oypOA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646164707; a=rsa-sha256; cv=none; b=olA+39S3ltr8fFBZOtQq/dwUmEwrtx7bvUbg/d8hFubdUv/J/6BGgeYl/yHcJj5EwCXAya RrkU5trd50IdE4xbBtsFvuwMgJqjFSVhQ0nDBlKv6IASVPYKxsTqs3dlJ3kSHBXTheDi4g wRli1KbHFaT18zjoaMQzWkbZxnPqCvXhybTQfZOaebIRbgjekLKYOO5LjjV8Hx1KuZfEhm CGjyr2QLLSGt3CSsf5XTAXjfIjdNhRmW3so9fw7X9hDyfmyym+TeXI8xMmUcbyTlltwu/J LjWpOFlbTR/scXcb4SvqF3Vdk892EntqD/Gxi8YdaKOf3FK6q1zunj6iTAxMXA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --hE2a7nJK79M1wdjr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-Mar-01 13:04:34 -0600, Mike Karels wrote: >E-cores. (Does FreeBSD support any ARM chips with asymmetric CPUs yet?) Only one that I'm aware of: The RK3399 is big.LITTLE (4=D7Cortex-A53 @1.4GHz + 2=D7Cortex-A72 @1.8GHz) used in e.g. https://www.pine64.org/rockpro64/ As far as I can tell, FreeBSD treats it as a flat hex-core CPU. --=20 Peter Jeremy --hE2a7nJK79M1wdjr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmIeetVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzT1Bg//ftK9nh77mFQlm3ZbNA5aI06IuGFdbVoOu8/bPSi1rE9R1M4DQMGOqneB sRFeMOcQ020qJb2vX2a8CFt7EMQvpLRDN2e8k5Wp4JHkhcMu5moGlqkOOiJGUlN8 Ype7Oq3C0xK5y+vjU1qp+hR7u6aoXNG2rQR750d9lWKzLPT9xE+0vhwRZGtagAeD hrHINcaNHMkepmaPIsskRGegotwByOB5NhE/++bPpPuhYyVlskyH6ZaKuxWTEOK6 wUKDfBo63SNkA8HUbPC3JZ5n+pZGjn+BjmKoprOy/rgghoHMtTwTTZ1DXhX1+dMk lgC9/YohFJRXGmSUTaNp1MwnvQgIJc6GCwLELsSiYGG8lDoGtTDxpHn+ZEko1QP/ ipFhBtjmICdaXeH87x5w55qgZ4owvaynrOqF6r4KgNx1xtEIjA2cMTLqNveKWhTb EMRS0SGN9TwQ2IuZj+3KJbJyO6sisWmTeDLBqTz9X3QoiohPLXMI4cYzUZzcXREV ci/yTcQXtiKo4pY1LCHv/jShYRP8B2WLnAIzczkD0HrqeKpXpfT/V/m0l9GgK8oD +XDs9mHnmzjmYn51UdcqAts2rul+Qvk5Iv4PQ1rZOFjfv3K6p+MZC1Od5ukXHD6h Xi2p1lY+LcSHMJnFH7TxsWOvq1BWPZdxqUUb0MVRqOZWvLXUr+A= =O1F3 -----END PGP SIGNATURE----- --hE2a7nJK79M1wdjr-- From nobody Tue Mar 1 21:05:28 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7C67519E5EB3 for ; Tue, 1 Mar 2022 21:05:32 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7VC02kSlz3Kpm; Tue, 1 Mar 2022 21:05:32 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646168732; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qUDj+FudZN6bpZyzN9ErQqC7lJmzoG1s8DKy8eYUyAs=; b=ZoeepQ04cVbFApGeMlX+18OzZ/qqXO1uV2xeHxLqzjLgUv77q531iKhHr/D0ajVAG88p+p PvOeh21WtixRYkzWaWbVMJURFsyyC+cuwQ92lXgl30g8iPaqrN66cFFotB/SVEcmxCs97B NxZ4/VBZ9sFSOsrCtW2jQpJdWlwh5gwGjNW+6DiqtBYSufgQXnfMOCHNJVfS2UtWsRiNJZ qMyIy8VzZbjFXNudFVJzgcgRX1JjQQiKnkmSo8/FYtlex6t3CcJUzA042AsqZq3AGIf4T3 B5IBFXdDZb4nTU/arZamna85fZHzpRdJffwyQshRArxBAdJ47moZpUpiRvxgAw== Received: from [IPV6:2003:cd:5f12:a700:6580:26b2:2ead:28bd] (p200300cd5f12a700658026b22ead28bd.dip0.t-ipconnect.de [IPv6:2003:cd:5f12:a700:6580:26b2:2ead:28bd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C32C3B43F; Tue, 1 Mar 2022 21:05:31 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Tue, 1 Mar 2022 22:05:28 +0100 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: support for asymmetric CPUs Content-Language: en-US To: mike@karels.net, freebsd-arch@freebsd.org References: <202203011904.221J4Yg8032167@mail.karels.net> From: Stefan Esser In-Reply-To: <202203011904.221J4Yg8032167@mail.karels.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------q2Sl1z858D4DbvuK84fsltx9" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646168732; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qUDj+FudZN6bpZyzN9ErQqC7lJmzoG1s8DKy8eYUyAs=; b=b1jkwxfLAOpJD3Iwkpj2e7YAgOD2+T3BP9tRypU134YoJOkhSDz9093fOZMUYzLVNNAKV+ 81KMiJ0TGuom3/b3TW15Cnxi4/CCzUn/DcihrWWW85/sHXV4w3QsDP5mQv85PI4RvbyAgn dzdajBf9q8uUbWcA+/QtyAtdUmfDoyoIfLcKaglqy+vM5zlxbV/w6IBjIq3rscEVtHSBVo OOdXZCWGxgSxmcjsPNbS+4Q8jzKYf1NXYUPWNiVDIrthy6NnARpRUxGZI6JbpmcfvHdVi/ HjyPINuhJ+HTvvpOHvuT3aEZAyXn7zsgFDAWu0L82OMM400ef+mXEvM9lgPdDg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646168732; a=rsa-sha256; cv=none; b=Jw18vqQNJhth0sg+0SGHp2TpRmQO/Ay8JIEYepd4OUD1CW4RwTktbpgmMRUNp6UysGA/HD 5OvFI1RZn0mUv0V99+pvQvnwDFPLks/H67TJhYiyidZmaXzpOQyWHOl7mOQHTHnKnYDqVm ofTLS8aXg36DGFsoc2SesAnh6d5Jz3sUUcsMrhk4r/MT9I72Zw00u3g995QT3unzStPero GxT6JdwTyfJNHlO7YAyg5L8zXeHdlafM/Gq4HOA16ZontrslbPZlpmAO9oK20c2H4/mAPT P202D9AFgwHnm/QJnRL0cvOuRjGOZ7X8TJ8+2WcVgwqohlQt2B1yt8F9Z8Ahwg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------q2Sl1z858D4DbvuK84fsltx9 Content-Type: multipart/mixed; boundary="------------6dFPJITf0ISmoW2oMuw70sR0"; protected-headers="v1" From: Stefan Esser To: mike@karels.net, freebsd-arch@freebsd.org Message-ID: Subject: Re: support for asymmetric CPUs References: <202203011904.221J4Yg8032167@mail.karels.net> In-Reply-To: <202203011904.221J4Yg8032167@mail.karels.net> --------------6dFPJITf0ISmoW2oMuw70sR0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 01.03.22 um 20:04 schrieb Mike Karels: > Has anyone been looking at scheduling issues for asymmetric CPUs like > those with performance cores and efficiency cores? I've been looking > at this a little, with Intel's Alder Lake as an example. E.g. the > i7-12700 has 8 performance cores with SMT (hyperthreading) and 4 > efficiency cores without SMT. The E-cores are supposedly better for > threaded processes. Intel also has a hardware/firmware facility to > advise the OS about process behavior to guide placement. I don't know > much about this yet, but there is supposedly support pending for Linux.= > Looking ahead, the Apple M1 also has asymmetric CPUs with P-cores and > E-cores. (Does FreeBSD support any ARM chips with asymmetric CPUs yet?= ) >=20 > It seems clear that there should be a generalized interface that suppor= ts > machine-dependent configuration, even if the hooks mostly end up pointi= ng > to machine-independent routines in the scheduler in common cases. I'd > envision initial support that just looked at CPU usage and adjusted the= > cpusets for threads that were using the default cpuset. I was also > thinking about exposing cpusets of P-cores and E-cores for use by > knowledgeable user processes. I'm not sure whether it makes sense to > try to generalize beyond one dimension, higher-performance and lower- > performance cores, e.g. for vector-heavy processes or other potential > asymmetric capabilities. I'm not sure how to generalize more, so that > could be a future exercise if there was a reason for it. >=20 > If anyone has thought about this or has done any work on it, I'd be > interested to hear about it. Not identical to big/little scheduling, but IMHO related: If the scheduler is improved to support asymmetric CPUs then I'd think that more intelligent handling of SMP cores should also be considered. If a SMP-capable core executes only one thread, it can be considered to operate at a nominal clock rate (100%). With 2 simultaneous threads there are 2 virtual cores of in the order of 60% clock rate (each). Therefore a single SMP-capable core could be considered to dynamically switch between being 1 P-core or 2 E-cores. I'd think that it is not required to have a high-precision estimate of the relative performance of P-cores vs. E-cores (which also may have individual and dynamically clock multipliers depending on the temperature, load, and other parameters). But the topology (especially with regard to significant cache latencies) and the rough performance level (e.g. 100% vs. 60%) of each core should be reflected in the scheduler logic. Regards, STefan --------------6dFPJITf0ISmoW2oMuw70sR0-- --------------q2Sl1z858D4DbvuK84fsltx9 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmIeipgFAwAAAAAACgkQR+u171r99UQL NAgAo4GdYcRIAIQuyHh53jZY+15Qzp3qXGqnuUjQ6f2Hi34/T1sjqsD/aL6AOp5fnPsWkVvq44cC m1Un4TMCvucvKhg5F5iexRmpPlWPKow+QqTOI++4p50fLcpKE5uOQvP2y9+OGta4muhSMGHvgJgd 82a9ZmzLq16+/js7+3hqzr7VYNkLzhfQUlTd6DVrdcpZ8zvxXdEIqsjYC9LAE3gn+rq94JcFl8Kw G4DQhFFxnfECNVQcst2UkHCubynw222WdxDrqzucV2ZEgS6VkMB1cjl1V9+bmfZTzziAgLMK7cCK ZftdsVaxpZCXtJSx4lX5NGiGAk8ET2XBikAMNfqgzg== =bR89 -----END PGP SIGNATURE----- --------------q2Sl1z858D4DbvuK84fsltx9-- From nobody Wed Mar 2 07:36:38 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9DA5F19F2950 for ; Wed, 2 Mar 2022 07:36:40 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7mCD45gWz3pvW for ; Wed, 2 Mar 2022 07:36:40 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646206600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VuH/mAartVRdpimfnAViLPVubyFhHNtNDD6JHMs//Gs=; b=tw1GNDY7hlgIVJZ2VWJ8Oa/lS6tgyJPq9pTF2omFIuMK7Y8RuT5OzTE4F+PloDRXFMaWju JIu93IZ2zHXf5cNrUnoxkiCJiGGnsDDcDHvJmMRBz9dAhrtIxpgJVfh7oXMQkWLQs+Qx72 9KiLL8cMk8Gd18zRk0FqC9w5kwZxm7Gx/Fzk1iZvVTaRW0+BDbAQKl8r+qMeMctW20I2y7 Zw4ZzGFApCmsIeTEtnaBCppavX/H9eH9RoTX7hEvy28yQ1Nj/pgJ1oGKuHBbQ9yEeVEolV aX2PTUVYVezjC3X4YVv+eVXqpca4fHzoZdTvphFpWioLDuXeRagLVDNfeu+V/w== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 754C5ABF3; Wed, 2 Mar 2022 07:36:40 +0000 (UTC) Date: Wed, 2 Mar 2022 08:36:38 +0100 From: Daniel Ebdrup Jensen To: freebsd-arch@freebsd.org Subject: Re: support for asymmetric CPUs Message-ID: <20220302073638.o7qgisnbbixo6ezh@geroi.local> References: <202203011904.221J4Yg8032167@mail.karels.net> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nmulnnf74c4d7qy5" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646206600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VuH/mAartVRdpimfnAViLPVubyFhHNtNDD6JHMs//Gs=; b=eqXQXhBHTeU7aQcU2Natj3eKILD9vBWFOg2zqXrzoa9RKthWDJ+BUIKcIJlKLt/L85lNhV et7QjTZnyQ7AzCl9O7JmKt6AaswT/AgRvNfxIWs9/im+YleUUykQMmK2faCWL14DChp/TZ JhDVsV3Qj81gt6A9hPZoKfSJjfCUxZvBhgxGQ4mOGhRNdJ9byqZ/CSrDCPqCkImbGf5QUy Rn8dVaQmkdFJpjiCAFFFLPS5L/bGuNoQvUUIast9XlW/IWCehRlkKapdsHsRzWzMpQxR1I GJWrWYLO/LHrHNBLWGpop8TCXfOuASx8GzJxQH8BLSkuQJvP6OUp32wrSqzZQg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646206600; a=rsa-sha256; cv=none; b=YxEPHaFhxnunGmXIKzoM20KAAMDbLymzuAn+y1HVHEcc5otq5V9d0mM5FN1p+gy8bOyBlF sWcD7NW2clU/rt4Bo/8gn0XybP/VOqExkEs4HWsD99kzeqezhAkZi/29AHrZBmJr5vL8kE dRoQqDR6mismFG9KrAm3fnaGQddJHbh9F51UaW31bJwkGiXfYomgsKd/AngOmuurX9jImz lbV81jMW5IpxPZ7Yp1BNu+L3u08hgBsCs48Xkc9KwgFG62+IFfbdgVM8Kq08auYhJCp2Wm MA6Ac4n78JEgQsbMyGJbRqNo8Vkwc1/X4RTfGXoUPWVitOwkGFXMRaa7PgpVRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --nmulnnf74c4d7qy5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Tue, Mar 01, 2022 at 10:05:28PM +0100, Stefan Esser wrote: >Am 01.03.22 um 20:04 schrieb Mike Karels: >> If anyone has thought about this or has done any work on it, I'd be >> interested to hear about it. > >Not identical to big/little scheduling, but IMHO related: > >Regards, STefan Hi folks, I should preface this by saying that I'm no expert in schedulers, but that even I've spotted at least a few issues with Heterogeneous Multi Processing - which so far as I know is the generic name for ARM bigLITTLE, Intel P+E cores, and whatever else AMD, RISC-V, and IBM come up with if the technology matures. The existence of cores which are meant for energy-efficient use implies that the scheduler can keep track of when something is energy-efficient, which in turn means that in an ideal world the programmer would give the compiler some kind of hints, there's some information that lets the scheduler know if something will use less energy if it's run on a faster processor vs taking longer on a slower one, and/or that there's some other magic trick that'll make this sort of thing work without adding potentially thousands of lines of heuristics to our scheduler [1] which won't necessarily make it faster than another scheduler [2] which has almost an order of magnitude more lines but isn't any faster and can be slower in certain use-cases [3]. And all of that doesn't take into account however many person-hours will go into actually programming all of it. All of this, of course, assumes that HMP isn't just a bad idea that's been allowed to fester a bit too long - something that I'm not personally convinced it isn't, and I've seen no good arguments supporting it other than something that amounts to "these folks are saying it will have been a good idea in X number of years". I'd love to hear what scheduler experts have to say on it, though. Yours, Daniel Ebdrup Jensen 1: https://cgit.freebsd.org/src/tree/sys/kern/sched_ule.c 2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/fair.c 3: https://www.usenix.org/conference/atc18/presentation/bouron --nmulnnf74c4d7qy5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmIfHoZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87oTcwgAq532GcXDEMulK87Y9MZElJbHRU1dS/S41vXWdoL5ZT7an24OfyI6hDfv 16EX+QxJ7+4YMLHi3eMD320r10gprZF4GQT6o3lvwWAOhp8/rPcqqZ+rMy1KnjN8 x79pSV4e4PvSPVfpnqfsY8bB1aQzEHkkvRIClNfUnJzYSMrq6pMlVat7cDJKoU/1 KdI/ipnzNvkfzXXXCVjXocUf3hj2MgSkr1XwqcjytVgBOVMnZzs481eJSlZeK1Qa WXDWKrtvP0cTwCuIsfmWbKzMZ/iYv7ge3rmjJWawbtuEQmutmietM2OB8F8Y0zIY 4W4ImYOwpIsUb/QDzG5a73pUcopq2g== =f2Ct -----END PGP SIGNATURE----- --nmulnnf74c4d7qy5-- From nobody Wed Mar 2 11:12:06 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B12AC19EFF26 for ; Wed, 2 Mar 2022 11:12:27 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7s0B6m9vz4kCm; Wed, 2 Mar 2022 11:12:26 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) client-signature ECDSA (P-256)) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id A18AE23C6E; Wed, 2 Mar 2022 12:12:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1646219544; 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=mY/yQZkZUy75coLQ12M+t0NKYHYFRhA4cEjmhG5yFzw=; b=BzwM0Aorjn2qWLQq+BXsVscTNnHmz/GqG8AJEEDDYGhEGEarFErz06N7bvhTfLa0mTTT/Y XhubnbKovngaiLhFGxO7JxazMyW5VPsWxIo/KqjYS3xiym7ZkAOSRGx96/m9qLIyPU55cg 1totDfWaDTTns6CM7dirvOMOz0oTUloCYYYey+Um9zuwivoem5JH+uPsRGSQZDWJk92mi6 Rgi8yDTrIaurid9Aa3p78h1dPOEiq/c/qcxwR08FwRq132+PsxSgMz45yWC6Z5YyWmTBYI t16G9RYdsabVfQRPbK18zdf0UA1QfkezS/JDGLq229IVUeUA+8+4OUU/CUMFUQ== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id A845EA684; Wed, 2 Mar 2022 12:12:06 +0100 (CET) Date: Wed, 02 Mar 2022 12:12:06 +0100 Message-ID: <20220302121206.Horde.NKFkA1iMzx7Q3sIoiU3Gkrw@webmail.leidinger.net> From: Alexander Leidinger To: Daniel Ebdrup Jensen Cc: freebsd-arch@freebsd.org Subject: Re: support for asymmetric CPUs References: <202203011904.221J4Yg8032167@mail.karels.net> <20220302073638.o7qgisnbbixo6ezh@geroi.local> In-Reply-To: <20220302073638.o7qgisnbbixo6ezh@geroi.local> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_CYpbMvSfKQ4eUIKrPlyXljl"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4K7s0B6m9vz4kCm X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=BzwM0Aor; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.09 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-0.99)[-0.985]; MLMMJ_DEST(0.00)[freebsd-arch]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_CYpbMvSfKQ4eUIKrPlyXljl Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Daniel Ebdrup Jensen (from Wed, 2 Mar=20=20 2022=2008:36:38 +0100): > The existence of cores which are meant for energy-efficient use > implies that the scheduler can keep track of when something is > energy-efficient, which in turn means that in an ideal world the > programmer would give the compiler some kind of hints, there's some > information that lets the scheduler know if something will use less > energy if it's run on a faster processor vs taking longer on a > slower one, and/or that there's some other magic trick that'll make > this sort of thing work without adding potentially thousands of > lines of heuristics to our scheduler [1] which won't necessarily > make it faster than another scheduler [2] which has almost an order > of magnitude more lines but isn't any faster and can be slower in > certain use-cases [3]. I had a look at [3]... looks like experiments in terms of migrating=20=20 more=20than one thread at once may be interesting (4 minutes to=20=20 distribute=20512 threads from one core to all 32 cores), no matter if=20=20 mixed=20perf cores are a good idea or not. The first question I have for this case is: is this an artificial case=20= =20 (the=20authors limited all threads to one cpu via cpuset and then opened=20= =20 up=20to all cpus to measure the time to get to a balanced state) which=20= =20 can=20not happen in the wild with a "normal" workload (postfix / apache=20= =20 /=20nginx / mysql / ...) except you play around with cpusets? In case someone with some ULE-knowledge reads this: Do I read our code correctly if I say replacing CPU_CLR(high, &hmask); CPU_COPY(&hmask, &lmask); by CPU_COPY(&hmask, &lmask); CPU_CLR(high, &lmask); in sched_balance_group() would result in migrating more than one=20=20 thread=20away from a given core in an extremely unbalanced case? > 1: https://cgit.freebsd.org/src/tree/sys/kern/sched_ule.c > 2:=20=20 >=20https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /kernel/sched/fair.c > 3: https://www.usenix.org/conference/atc18/presentation/bouron Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_CYpbMvSfKQ4eUIKrPlyXljl Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmIfUQUACgkQEg2wmwP4 2IZC5Q//Wd05meIb/8YE+LwKnwTUlSzszR7KLvLC0iTCfJdCEq3BTbM2ctMwAQTg 1RU7QPUs0lJV2FrwTWW+AG6a71I7eH0BVzv47melrtR5bpD+5JnK7D15Q729Ncj9 pXIY524XrqZ2S1Q2QUvgd9/DmX/drRE1JVC6AXvDSoQc1AKeYMM4RIcgF6Ew932Y NYyUwUj8SEmOshM2hlJzs5uW/XIKz+FTErc0zgkRhb2jR50TfxpxHRSjPwQtkkKJ 41J+9+XLJ+W++cNye/wvV/SMJ8VKqbWJN+bo+DfGAW1Fu0Al0N6/fP6ypb1iAvxZ 9thZRXOnVjk/LAHI1cJnpEumt9m43tQ+ZsHiJw6sN5ZIdhXnIDtGeh2fWW1zYhHe w1uSebNVT7LUS5dMD26Abpw21f/9vZ4lFMrc7Ce+//L3s7ivCC1bWVwRygBhEGbN wnSvfrT1WbW3G7rO7c6Azwmsb1+nzIH/BbVocjBUUgYjsz1pSixGecigKQzkGVQd DU00u6l/dWk2TIhKNGfkZDXI5/6hnzNK+EDMflSJzXmcBmvyjR9AGyl5kMbK/Wt5 vGAp+2uRGdGNQv32ZbEhn5bxXsis3gAMaYGwPlMzEMKqmdvHl2Ed/GaYNR9kXkwa IpPl6IELatFh067MyPIMdl4ZnfK7YZAxIeuCc2Ekyw862JgxG0g= =g1dK -----END PGP SIGNATURE----- --=_CYpbMvSfKQ4eUIKrPlyXljl-- From nobody Fri Mar 4 01:39:02 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C66F419FF43D for ; Fri, 4 Mar 2022 01:39:10 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4K8r9p0lSYz4llN for ; Fri, 4 Mar 2022 01:39:10 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 2241d2L2045465 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 3 Mar 2022 19:39:02 -0600 (CST) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 2241d20M045464; Thu, 3 Mar 2022 19:39:02 -0600 (CST) (envelope-from mike) Message-Id: <202203040139.2241d20M045464@mail.karels.net> To: freebsd-arch@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: support for asymmetric CPUs List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <45462.1646357942.1@mail.karels.net> Date: Thu, 03 Mar 2022 19:39:02 -0600 X-Rspamd-Queue-Id: 4K8r9p0lSYz4llN X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [1.23 / 15.00]; HAS_REPLYTO(0.00)[mike@karels.net]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.952]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.88)[0.880]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[karels.net]; MLMMJ_DEST(0.00)[freebsd-arch]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Replying to several messages, including my own: Although several people mentioned energy efficiency, that is not my immediate goal. At least with the Alder Lake CPUs, I suspect that the difference in energy use between low load on P-cores and E-cores is small. These are not especially energy-efficient chips; the i7-12700K is rated at a base power of 125 W, with a peak of 190 W. Instead, I am more interested in system throughput and sensible placement decisions using fairly simple algorithms. I plan to experiment with starting most processes on E-cores, and promoting to P-cores as soon as they start using much CPU time. This should reserve the P-cores for the processes that most need them, and keep the processes with lower utilization from interrupting them and disturbing caches. In any case, I'm hoping that simple algorithms can beat random placement. Naively, I hope that similar strategies would also lower power consumption for varying workloads with mixed core types, although not as much as algorithms that were more sensitive to efficiency of different types of workload on the different cores. I haven't decided yet whether to consider threaded processes differently; the E-cores are supposedly better for threaded processes. I also don't know if/when I'll experiment with Intel's Hardware Feedback Interface; it will obviously depend on availability of documentation or example code. In theory HFI could yield quicker placement decisions. Any additional input welcomed... Mike From nobody Fri Mar 4 09:03:06 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B88DE19E688A for ; Fri, 4 Mar 2022 09:03:16 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4K922D09Kdz4XBV for ; Fri, 4 Mar 2022 09:03:15 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [192.168.0.252] (gw.br-thn-01.caladan.net.uk [80.71.4.65] (may be forged)) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 224937Kh035981; Fri, 4 Mar 2022 09:03:08 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: support for asymmetric CPUs From: Bob Bishop In-Reply-To: <202203040139.2241d20M045464@mail.karels.net> Date: Fri, 4 Mar 2022 09:03:06 +0000 Cc: "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <310CBE30-6E24-4F17-9E52-76E067E8BF52@gid.co.uk> References: <202203040139.2241d20M045464@mail.karels.net> To: mike@karels.net X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4K922D09Kdz4XBV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk X-Spamd-Result: default: False [-2.70 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gid.co.uk]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > On 4 Mar 2022, at 01:39, Mike Karels wrote: >=20 > Replying to several messages, including my own: >=20 > Although several people mentioned energy efficiency, that is not my > immediate goal. At least with the Alder Lake CPUs, I suspect that the > difference in energy use between low load on P-cores and E-cores is > small. These are not especially energy-efficient chips; the i7-12700K > is rated at a base power of 125 W, with a peak of 190 W. Instead, I = am > more interested in system throughput and sensible placement decisions > using fairly simple algorithms. I plan to experiment with starting > most processes on E-cores, and promoting to P-cores as soon as they > start using much CPU time. This should reserve the P-cores for the > processes that most need them, and keep the processes with lower > utilization from interrupting them and disturbing caches. In any = case, > I'm hoping that simple algorithms can beat random placement. Naively, > I hope that similar strategies would also lower power consumption for > varying workloads with mixed core types, although not as much as > algorithms that were more sensitive to efficiency of different types > of workload on the different cores. I haven't decided yet whether to > consider threaded processes differently; the E-cores are supposedly = better > for threaded processes. >=20 > I also don't know if/when I'll experiment with Intel's Hardware = Feedback > Interface; it will obviously depend on availability of documentation = or > example code. In theory HFI could yield quicker placement decisions. Section 14.6 of this for a starter: = https://www.intel.com/content/dam/develop/public/us/en/documents/253669-sd= m-vol-3b.pdf > Any additional input welcomed... >=20 > Mike >=20 -- Bob Bishop rb@gid.co.uk From nobody Mon Mar 14 16:42:01 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BD6AB1A22C09 for ; Mon, 14 Mar 2022 16:42:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KHMlK04pKz4YD7 for ; Mon, 14 Mar 2022 16:42:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6F010260CAF for ; Mon, 14 Mar 2022 17:42:13 +0100 (CET) Message-ID: Date: Mon, 14 Mar 2022 17:42:01 +0100 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: "freebsd-arch@freebsd.org" From: Hans Petter Selasky Subject: FYI: if_capabilities needs to grow - proposing extension using nvlists Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KHMlK04pKz4YD7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.27 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[selasky.org]; NEURAL_SPAM_MEDIUM(0.02)[0.019]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.990]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, The "ifp->if_capabilities" field is out of bits and needs to grow. The plan is to call this a legacy field and use nvlists to extend this field. Please see here for planned changes to ifconfig and if IOCTLs if you are interested doing review and testing: https://reviews.freebsd.org/D32551 --HPS From nobody Wed Mar 16 13:56:21 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B40441A2F1E0 for ; Wed, 16 Mar 2022 13:56:41 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJWzD3t0Hz3Fcv; Wed, 16 Mar 2022 13:56:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id h63so2355262iof.12; Wed, 16 Mar 2022 06:56:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t8nj0KQo7LfQxIyd2vYrElyCkFcoLv2kg0dvdCY+8hM=; b=ppujAq7H65sPKP2IaaQkLMV3iPaywj8HG34HINoqxtaZ6BqUrvXKvf5PNKh4HlsWeS LiXOx+aCrsr2Dg0wLF523uZxhKoBNcf/m28NgM7T5ZTJINafWuzd72KvVKgHMQv7qJ5i 8y/phojztMadEf93ll1Z9oecQ5/eo8CkaC8pXL/uwyIbihzZcOio6ejuCL6VSxZTArt3 k1SWkF590OaSns12otE/evqPFXEQB+O1Xui5CBjFeMngNASBhUxKwf70eTtuD+xc1000 R0IzLr4d8goXXyeIXWsaOuXWFUwft5oi4LOMjGRitFj4Hxkgr/bOCuh8ZREMq5hl2Gqq NLmA== X-Gm-Message-State: AOAM532jKzHr8zZTaCRzPRexs2Vz5YHhw1Ski3Cr5vZlwm2uXG7h8N3O FY504WuNQ6llcZBOaBhUBPKNMNe083iOBMSFDIorzkc7 X-Google-Smtp-Source: ABdhPJws2fzDYap4kUpiJtH5qTaRPnOqFNA0CmR90Sl/xHvvQ0u4K73gZsCdpWzSXhYP+ry+pqonMbPSce5o2IO0NNc= X-Received: by 2002:a02:a081:0:b0:317:b141:29ca with SMTP id g1-20020a02a081000000b00317b14129camr25039739jah.275.1647438994340; Wed, 16 Mar 2022 06:56:34 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Wed, 16 Mar 2022 09:56:21 -0400 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Warner Losh Cc: Alan Somers , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KJWzD3t0Hz3Fcv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-0.29 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_SPAM_LONG(0.48)[0.476]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.52:from]; NEURAL_HAM_MEDIUM(-0.77)[-0.771]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.52:from]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, 3 Jan 2022 at 13:06, Warner Losh wrote: > > All of that is covered by our existing practice of storing LGPL code in s= rc/gnu/lib. We cover it in the handbook already. Since it is publicly avail= able forever, storing it there will have no impact that's any different tha= n libdialog or libreadline has has in the past. gnu/ isn't the right place - build infrastructure exists in src/gnu/lib, but the GPL/LGPL source itself lives in contrib/diff and contrib/dialog. Those two are the only remaining GPL/LGPL userland components, and both are on the way out. I suspect the right place for the proposed library's build infrastructure is beside the tests that will use it. From nobody Sun Mar 20 16:38:09 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C85BE1A3296D for ; Sun, 20 Mar 2022 16:38:09 +0000 (UTC) (envelope-from alfix86@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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KM3Mh6HJ2z3t2m for ; Sun, 20 Mar 2022 16:38:08 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-ej1-x631.google.com with SMTP id bg10so25714198ejb.4 for ; Sun, 20 Mar 2022 09:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=jKtGPgGVLSKIuZE45Tm+yjLfwRRkl9CYqwPxwpwW7Z0=; b=fyJauafVYTmjhdjk9iyGjvuq6zseZTPTmV71HjW5Qy00THhxCmXNpVM1nfYil/VS/L tSDaIqcf5Epp3aqleu0hUi5HYyRbsOrKD4eZDTW/lRobwa02XlfRMGcXS07czsXGfhxv AlQ5OfAheDVtDQF+gcLyDQE4XaHFl6f2qaGscEYvBpzTe66wHLwA3Lxp5q4GHMphGRZg dtyQ+OqUOUXMRfAwRoj5d7Fki6iSAF6XxzblDxsT8Es7VAqZeBjBojitBZb3wk33+1g6 Oe92NG7bXSKghnIVP1oIQ1zIJt44r9U0f2kV503OGmi/I+lwgo+4hcI2mHGGD1JI+eZ6 E5Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=jKtGPgGVLSKIuZE45Tm+yjLfwRRkl9CYqwPxwpwW7Z0=; b=aHq6a4Fm3QdMjIgiNTaEGPLLjqCIcNSISmju7OseyfHHIxGU5oE1qpOMbMVeChF0K0 zJ+/D/hoVMRmMp1nO+SqDiGRVdLH4y3UDi/zYXRJBw3hiWHo9w8lxDZX58oFbQfBf8gz 6WLGrdBHTI0gpXuVTuXodwpFNpI5UJlSIQp95RGkgVgpHcA/6OmeJ9NYhyxsVjGn/ENH oPyADsGIC20IWTnPD3Fu/1xDt+kKwsBnSitJt7ugiPKQejRh7pu7gGdCHM+AXsq4di/a FIGpXzfO5/xCF07fh0InLNaiySpmO9hTFTDnCAkStMIYNC18xBFzbs14yjFMNVw4SUrL gqlQ== X-Gm-Message-State: AOAM533e/ipExC157gE6hCCM6JaAh4n/ZXRDB+zmedXo5F6Kz+sIOnxU oK20GqshYgC3IblLlYFokQyShZZJiOY= X-Google-Smtp-Source: ABdhPJxJocTNb0uRz7rV2YG1wT8BfM7W8YxdSMq9S19oK3o8ziDsIFGR15rOINER7WCN2iB98W9WnQ== X-Received: by 2002:a17:906:27d1:b0:6df:ccdd:1a8d with SMTP id k17-20020a17090627d100b006dfccdd1a8dmr8638011ejc.751.1647794287710; Sun, 20 Mar 2022 09:38:07 -0700 (PDT) Received: from alfixbsd.homenet.telecomitalia.it (host-95-252-128-186.retail.telecomitalia.it. [95.252.128.186]) by smtp.gmail.com with ESMTPSA id l12-20020a056402028c00b00418f7fc4bd8sm5411213edv.91.2022.03.20.09.38.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Mar 2022 09:38:07 -0700 (PDT) Date: Sun, 20 Mar 2022 17:38:09 +0100 From: "Alfonso S. Siciliano" To: freebsd-arch@freebsd.org Subject: TERMs for bsdinstall Message-Id: <20220320173809.644227669c080c2c48a7ed29@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KM3Mh6HJ2z3t2m X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fyJauafV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alfix86@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=alfix86@gmail.com X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.989]; RECEIVED_SPAMHAUS_PBL(0.00)[95.252.128.186:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from]; MLMMJ_DEST(0.00)[freebsd-arch]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I am ready to start to replace LGPL-dialog with bsddialog in bsdinstall/scripts, so some question and proposal: I noted 'release/rc.local' prompts 4 TERMs for bsdinstall: xterm, vt100, ansi, cons25w: # Serial or other console echo echo "Welcome to FreeBSD!" echo echo "Please choose the appropriate terminal type for your system." echo "Common console types are:" echo " ansi Standard ANSI terminal" echo " vt100 VT100 or compatible terminal" echo " xterm xterm terminal emulator (or compatible)" echo " cons25w cons25w terminal" echo echo -n "Console type [vt100]: " read TERM TERM=${TERM:-vt100} I would replace: ansi vt100 [default] xterm cons25w with: vt100 vt220 [default] xterm cons25w (delete?) Why? Add vt220 and new default, because it has better UI features than vt100 and is similarly old. xterm is ok. Delete ansi, I seem it is not usable also with LGPL-dialog, do somebody really use it? Some test: % env TERM=ansi sade % env TERM=ansi dialog --menu test 0 0 0 n1 d1 n2 d2 Delete cons25w? Reading the logs it seems useful for pc98 now deleted, however it was added for japanese users, I have not this hardware so I could send a call for testing in current@. Please note I want to remove nothing (TERMs, drivers, etc.), it is just an echo-prompt update. Feel free to point me to any useful resource and let me know if you want to be involved in reviews / other discussions. Finally I added an editable wiki page for tracking the replacement process . Regards, Alfonso From nobody Tue Mar 22 21:11:37 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0B8C61A378B3 for ; Tue, 22 Mar 2022 21:11:39 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KNPLK62z8z4nnp for ; Tue, 22 Mar 2022 21:11:37 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 822363C0199; Tue, 22 Mar 2022 21:11:37 +0000 (UTC) Date: Tue, 22 Mar 2022 21:11:37 +0000 From: Brooks Davis To: "Alfonso S. Siciliano" Cc: freebsd-arch@freebsd.org Subject: Re: TERMs for bsdinstall Message-ID: <20220322211137.GC93207@spindle.one-eyed-alien.net> References: <20220320173809.644227669c080c2c48a7ed29@gmail.com> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <20220320173809.644227669c080c2c48a7ed29@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4KNPLK62z8z4nnp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-3.85 / 15.00]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.946]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-ThisMailContainsUnwantedMimeParts: N --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 20, 2022 at 05:38:09PM +0100, Alfonso S. Siciliano wrote: > Hello, >=20 > I am ready to start to replace LGPL-dialog with bsddialog in bsdinstall/s= cripts, > so some question and proposal: >=20 > I noted 'release/rc.local' prompts 4 TERMs for bsdinstall: xterm, vt100, = ansi, > cons25w: >=20 > # Serial or other console > echo > echo "Welcome to FreeBSD!" > echo > echo "Please choose the appropriate terminal type for your system." > echo "Common console types are:" > echo " ansi Standard ANSI terminal" > echo " vt100 VT100 or compatible terminal" > echo " xterm xterm terminal emulator (or compatible)" > echo " cons25w cons25w terminal" > echo > echo -n "Console type [vt100]: " > read TERM > TERM=3D${TERM:-vt100} >=20 >=20 > I would replace: >=20 > ansi > vt100 [default] > xterm > cons25w >=20 > with: >=20 > vt100 > vt220 [default] > xterm > cons25w (delete?) >=20 > Why? >=20 > Add vt220 and new default, because it has better UI features than vt100 a= nd is > similarly old. >=20 > xterm is ok. >=20 > Delete ansi, I seem it is not usable also with LGPL-dialog, do somebody r= eally > use it? Some test: > % env TERM=3Dansi sade > % env TERM=3Dansi dialog --menu test 0 0 0 n1 d1 n2 d2 >=20 > Delete cons25w? Reading the logs it seems useful for pc98 now deleted, ho= wever > it was added for japanese users, I have not this hardware so I could send= a call > for testing in current@. >=20 > Please note I want to remove nothing (TERMs, drivers, etc.), it is just an > echo-prompt update. >=20 >=20 > Feel free to point me to any useful resource and let me know if you want = to be > involved in reviews / other discussions. > Finally I added an editable wiki page for tracking the replacement process > . It's hard to imagine anyone using something that isn't xterm compatible. Does it even make sense to have this prompt? -- Brooks --neYutvxvOLaeuPCA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJiOjuIAAoJEKzQXbSebgfAGOkIAIq2yWj1sgJqsHBAj22cy6R/ wq1S+B9m+VHSKMT62xNlrPIWJkg8/I4PGe6Whm9sIkCZiFM0N/Cl6jAPYJN6xPHF OKOKEdjN78gI378mWcc8S/C1heGMBNqrVG7JqgMgxnEVh1IBJvFhYZNhUY71aCIT Wy5zr50q2XSowuQUdEA5HV+vYQzGVrqy1UvtUrt0MxiKI/YjiJa5k6W7olXWcUZp AQS9khnIPUJMIL7TTivAsu2y6wyWpfCPv1fryt9VFcvcLmxhKQf8DxIGoOJcyTUc HGr5XHosCtzsni35u30g+oBYaudOA9bor7q2T7mn9NCjMmCCMKAmsp5rt8xFhgk= =P3/V -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From nobody Tue Mar 22 21:45:05 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5C48C1A40104 for ; Tue, 22 Mar 2022 21:45:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KNQ4y26Qhz4vSw for ; Tue, 22 Mar 2022 21:45:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647985506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4lmmNfK5nwT+MHlLtKikLFtf8p478f5OTZY2+chzg5s=; b=X2+gGOXZwv3eiuT/0mc/YVnPx80AmuOAwuwUN9OJHvytbG0pgJsKUVshHgKXC01Y5i10pA iIS5sYk/AfzRbWDC+g7Kuyxp91Yn68Kp+6zT9OiSUXq/FQhp27tcm+VC+GvZucx2esgPBU 7W1/aZa7O46Xzz1GKUyKFRmkRdt2iMsRthaw7fyK5kVu0jd7qWeVAYIWxqpOIY8Ogb2KI3 y4eRyeuLxyeBjXvduKmf89yCLDZBbf46azwD7rTob+lFarS6/OntC4G5a32b2zqHXdx3vU uMXMVAGsBEbsUrTGO1q2u0Df6HTYVIysgJV9feGwM30HY38X9VR3swpghqGqxg== Received: from [IPV6:2601:405:4a00:acd:7dec:1764:c390:f448] (unknown [IPv6:2601:405:4a00:acd:7dec:1764:c390:f448]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: nwhitehorn/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 10235B6CC for ; Tue, 22 Mar 2022 21:45:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Message-ID: <6d28c151-3553-3b48-5974-85900ea0e4dd@freebsd.org> Date: Tue, 22 Mar 2022 17:45:05 -0400 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: TERMs for bsdinstall Content-Language: en-US To: freebsd-arch@freebsd.org References: <20220320173809.644227669c080c2c48a7ed29@gmail.com> <20220322211137.GC93207@spindle.one-eyed-alien.net> From: Nathan Whitehorn In-Reply-To: <20220322211137.GC93207@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647985506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4lmmNfK5nwT+MHlLtKikLFtf8p478f5OTZY2+chzg5s=; b=xsPb/8ZwcY//8BGvF96W1F/Ox9MtaGyt0SpjyKOQktDsmPR4XTju1N7U8hU1COLCtrO+5i G3If5IXRJDualynx25+NrFH8sjNk607TEh7RPWSepL3lFmPobe38D6v2lpfqEUTAzoZfWl qnpcxW33QfiYf3MO/JKqxbalq7muLl19H/YlwCmiTJCKw2TZZhNwzKulKnYn+aj5+r4R2g mV6QrLCOR1FPOtYJLmQEj4Tqbi6vdyZogBEWQDqRoYdDD5OMBD1i6FxRrfqC+GYoKhT8dd GLL6ozb0aKVmyaQkoVHKvy7UmVZXNSnQ0A932SDIrToHmTrICOKd3STGOWE9ZA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647985506; a=rsa-sha256; cv=none; b=U4FCZAskSdYLozmSvf4nD3BtLMO0nFjlJZp8YLwLjRJ0Z7WlDj2YJrBJtIcRYAHnxKgYBH SMKTVMNJAquVKp0ZUnlsdU4e8ZJRXNQHGiLqavLkcPsApDNCJHVcRhd+Hru/7WNwHWgnc+ k6w/h8yI9wMb7WWsFSJz9aWBGKG0dAgyW41GrhwW8AhUDGmQGqlwpATVr/Ubnwjt+7PmQ/ oKNhPL2E9mpAnleVnKYgV4tJ4G6V/DOX3IKm885GKjddH7SePp2HGD4wn1TL5Rq2mK5pRV hHXGYJIfw5fsuBQCObBRLjEkDsyDU4RYzykfRMF+Ltr/emtaWubkGCm257tS5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 3/22/22 17:11, Brooks Davis wrote: > On Sun, Mar 20, 2022 at 05:38:09PM +0100, Alfonso S. Siciliano wrote: >> Hello, >> >> I am ready to start to replace LGPL-dialog with bsddialog in bsdinstall/scripts, >> so some question and proposal: >> >> I noted 'release/rc.local' prompts 4 TERMs for bsdinstall: xterm, vt100, ansi, >> cons25w: >> >> # Serial or other console >> echo >> echo "Welcome to FreeBSD!" >> echo >> echo "Please choose the appropriate terminal type for your system." >> echo "Common console types are:" >> echo " ansi Standard ANSI terminal" >> echo " vt100 VT100 or compatible terminal" >> echo " xterm xterm terminal emulator (or compatible)" >> echo " cons25w cons25w terminal" >> echo >> echo -n "Console type [vt100]: " >> read TERM >> TERM=${TERM:-vt100} >> >> >> I would replace: >> >> ansi >> vt100 [default] >> xterm >> cons25w >> >> with: >> >> vt100 >> vt220 [default] >> xterm >> cons25w (delete?) >> >> Why? >> >> Add vt220 and new default, because it has better UI features than vt100 and is >> similarly old. >> >> xterm is ok. >> >> Delete ansi, I seem it is not usable also with LGPL-dialog, do somebody really >> use it? Some test: >> % env TERM=ansi sade >> % env TERM=ansi dialog --menu test 0 0 0 n1 d1 n2 d2 >> >> Delete cons25w? Reading the logs it seems useful for pc98 now deleted, however >> it was added for japanese users, I have not this hardware so I could send a call >> for testing in current@. >> >> Please note I want to remove nothing (TERMs, drivers, etc.), it is just an >> echo-prompt update. >> >> >> Feel free to point me to any useful resource and let me know if you want to be >> involved in reviews / other discussions. >> Finally I added an editable wiki page for tracking the replacement process >> . > It's hard to imagine anyone using something that isn't xterm compatible. > Does it even make sense to have this prompt? > > -- Brooks It's from the pre-newcons misty past. I'd support deleting it. -Nathan From nobody Wed Mar 23 10:00:22 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C38D51A3575F for ; Wed, 23 Mar 2022 10:00:25 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KNkPP4xhzz4vTQ; Wed, 23 Mar 2022 10:00:25 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648029625; 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=hfopVRtRmbRT7DX1vjiSxszg5d/XYDuCH8EfupejUlQ=; b=kqVDHAUUrRoB5+H9GwegNUokZNQO5DDf3ePS5DhtOkZcPOIkXXMZC315EA/vGKYlwGTNcd ZE0G5f8GvZBdoFbcdft2Ly0ruJKye2WPfMR1bsjjLcmIkpbDdXyjiPkaPK14gV6a4UtRAh COoo7caJQxqeQB+e4M/6hC6KMx/fTAcOQgTqLaYyqi29egrNS8pTDmMAjKTSApzvCSNngh HRFJvba498vIglxqEohZWl1IDYan7/HHchxf8cjtZORN6hRLRO4SWpXLPnGBOdGfK/a/Fy AwIj04kZrIFYXpkW97UU9dBWGaM5vuP0oAVCjuUVU0aAPJ6rP7hhXds7f5DFdw== Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 81EA521FD2; Wed, 23 Mar 2022 10:00:25 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 6DACC27C0054; Wed, 23 Mar 2022 06:00:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 23 Mar 2022 06:00:25 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegjedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffoffkjghfgggtsehttdhmtdertddtnecuhfhrohhmpefrhhhilhhi phcurfgrvghpshcuoehphhhilhhiphesfhhrvggvsghsugdrohhrgheqnecuggftrfgrth htvghrnhepjeeluefhjeekteetgffhveeftdeitdehkeeuvdeuveefvdfghfegffffheej tddunecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqdduudeiiedviedvgeekqddvfeehudektddtkedqphhhih hlihhppeepfhhrvggvsghsugdrohhrghesthhrohhusghlvgdrihhs X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Mar 2022 06:00:24 -0400 (EDT) From: Philip Paeps To: Brooks Davis Cc: "Alfonso S. Siciliano" , freebsd-arch@freebsd.org Subject: Re: TERMs for bsdinstall Date: Wed, 23 Mar 2022 18:00:22 +0800 X-Mailer: MailMate (1.14r5880) Message-ID: <06F373BB-33FB-41C6-B7AF-F6A651E3D52B@freebsd.org> In-Reply-To: <20220322211137.GC93207@spindle.one-eyed-alien.net> References: <20220320173809.644227669c080c2c48a7ed29@gmail.com> <20220322211137.GC93207@spindle.one-eyed-alien.net> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648029625; 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=hfopVRtRmbRT7DX1vjiSxszg5d/XYDuCH8EfupejUlQ=; b=CDyfRVF+q6GJsaVr4LpcuQbQqFX6Jw4rTTbLIIX5lbGUFOS6jsfIXEn16AZNm9tdhHl78E sF3MlQJjpaU+v7xPQxgCCUv8CbuZkQcYbzqpROAW1rQ25Ew5djIwxq9AZ1l3Wj9kWPJxjI hssVz1sJBNQBfR2iROq8I5AGVAvDzA2RE+fxl+6akqlzu+QzuE/AWt8bz1GiTt2UzB4WdT 0f66Dr8X9Mk+h0ipp4YKzT6ndcfDJLYfhgrEENnYMHq8ylAZ8avp81cJA3yU9hLEvg2xJH 0Wo8zi9NW3X71dETlfags5AjeJAYaJffy/ML7uOgy2goM5Zxnt1pV7MgwQmceA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648029625; a=rsa-sha256; cv=none; b=dK4Lm690848khKZPPS7Aw2kMx46SmNxA6CINwHUXbC27/4dHV7bXVWueWCju3L4sOUKexo KRDttMm9UMLXO2EvE56m4a0f+25sIQ+OLd1r/95cwj/cCf7oZO7fNy/JxHh/p1Nn/lf6t3 +LhriqInnxwGS4IY/cl+y2QVlKZFoxIsryw9VQt7XFWhAOiPeypOXGKkb5808NC6afh+6s oX7GOErUQvUbQz8Xp9EWPac/2y+5WYOVuEQGn66pl0ycWqO1bGT+PCSH7roXfq/PANQI7j yWrcHr7tkoM81AoBvN5TDuPrA3kTKeYhndu1xItKMi5AKNPsEm+91VnTVjzrBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2022-03-23 05:11:37 (+0800), Brooks Davis wrote: > On Sun, Mar 20, 2022 at 05:38:09PM +0100, Alfonso S. Siciliano wrote: >> I am ready to start to replace LGPL-dialog with bsddialog in >> bsdinstall/scripts, >> so some question and proposal: >> >> I noted 'release/rc.local' prompts 4 TERMs for bsdinstall: xterm, >> vt100, ansi, >> cons25w: >> >> # Serial or other console >> echo >> echo "Welcome to FreeBSD!" >> echo >> echo "Please choose the appropriate terminal type for your system." >> echo "Common console types are:" >> echo " ansi Standard ANSI terminal" >> echo " vt100 VT100 or compatible terminal" >> echo " xterm xterm terminal emulator (or compatible)" >> echo " cons25w cons25w terminal" >> echo >> echo -n "Console type [vt100]: " >> read TERM >> TERM=${TERM:-vt100} >> >> >> I would replace: >> >> ansi >> vt100 [default] >> xterm >> cons25w >> >> with: >> >> vt100 >> vt220 [default] >> xterm >> cons25w (delete?) >> >> Why? >> >> Add vt220 and new default, because it has better UI features than >> vt100 and is >> similarly old. >> >> xterm is ok. >> >> Delete ansi, I seem it is not usable also with LGPL-dialog, do >> somebody really >> use it? Some test: >> % env TERM=ansi sade >> % env TERM=ansi dialog --menu test 0 0 0 n1 d1 n2 d2 >> >> Delete cons25w? Reading the logs it seems useful for pc98 now >> deleted, however >> it was added for japanese users, I have not this hardware so I could >> send a call >> for testing in current@. >> >> Please note I want to remove nothing (TERMs, drivers, etc.), it is >> just an >> echo-prompt update. >> >> >> Feel free to point me to any useful resource and let me know if you >> want to be >> involved in reviews / other discussions. >> Finally I added an editable wiki page for tracking the replacement >> process >> . > > It's hard to imagine anyone using something that isn't xterm > compatible. > Does it even make sense to have this prompt? It might make sense to retain ansi and vt100 for the unfortunate scenario of a serial console wired to a "smart" (stupid) terminal server. I can't remember ever encountering one that mangled xterm but I've seen so much stupid in this space that I'm sure they're out there... I agree that cons25w can go. That was a hack for syscons. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From nobody Sun Mar 27 10:35:21 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BA5111A55E05 for ; Sun, 27 Mar 2022 10:35:21 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRBzs4xtHz3Q2C for ; Sun, 27 Mar 2022 10:35:21 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648377321; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Dgmdv/Gxf2U4S55HXwi09ug3/3PD7KofuHFvJgKTGk=; b=kYlk5zrvmpAko8D0KsZLbr6N61FS4ZUqtvOPrxYkFP5irF+MOfAvTZ/mSbZQDpvSP5qjGt jUaqSDrXClVtRnk6pXpYmKKWM2fPe4EKau2Q/OEhE9MgRrmNxNy7jcmD1VFhG2vAhWwcDI ZHobdVuRUSjJSf6ehAqM1AFooM9hhmBgO04d9dgrJ7jvJjifuFqGS3HJCXo7J+Kb3P3e+P sVJ+nDn7dtv3wItrhHDAZ++e/RzXLiTbDWy7DCGWS/zxcQGKyYeIoXulN2G+QLY+Xy0b89 UJFPOZ9xNTOv3qhz+9lKe7fyZAoH8sSISCHR6RStlw+9ffj6V+ZbW1LQjD1iKA== Received: by freefall.freebsd.org (Postfix, from userid 1403) id 9AF3315E2F; Sun, 27 Mar 2022 10:35:21 +0000 (UTC) Date: Sun, 27 Mar 2022 10:35:21 +0000 From: "Piotr P. Stefaniak" To: freebsd-arch@freebsd.org Subject: Re: Introducing base64(1) Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648377321; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Dgmdv/Gxf2U4S55HXwi09ug3/3PD7KofuHFvJgKTGk=; b=xo3yt+0TJlByEyYrYg3vSR3YvCaW8lB9m+DmPuvjylw4O+8jKKppseCdMmpfouzIgpL8gF bxQerPSAOW6KXfKTLrnFHwmelD39i+GtbQcp+DbFbwnPYwsP2r82KWjTevKp4ivOq36sVu km8CLybKXQj0sKyfoj0AIyDeteIoKQ1pO/T8zENOOpoanlGMC+aMLm0sBdRh9hto5a6uvI MXUPX+u4Z+UBr/NUhRUTbyLKs+1N12SkVDMlRWkohXGxKS73gjrfUV0S0BQyDsaujv+pCi 5ZwQP0xFHaINbiOnNhJ6JtNwj+GJPAXtpaysfy6lckcEGRWmMkvOteN5q13TTg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648377321; a=rsa-sha256; cv=none; b=X3WP1i9E3Nj8mpYlgeJ9cVlAq8AlWaLHWlPPamich7DFuZCOruMSpg80Z+p1wYYup3Gjc6 zfpO8qeFr8htTw3w9CbsLROFdL7O4LK8MfORkeb7UDxDK/lbioHG5JamNy/Dz2DCock9J+ nOxT8RP7OHHkr/W/v1RABpmOnGL73vZup78FHUXoJgYCyyGo6XslLujARUigPKXYbauv8f gMQiH2xlgSnJ8UFUw32KHLzCZCle+RXKzarXym0onDUNvo78eGfwgOKkbDLvMIjZctlPeq j0cLsVdTGyjuvz1fuHUlY7gmQSfVI5LwVa9hW+demae9gHcENbm1sS9AIenJeg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2021-11-22 19:16:45, Piotr P. Stefaniak wrote: >Hello archers, > >I've prepared a short series of changes: >https://reviews.freebsd.org/D32943 "Conflate uudecode and uuencode" >https://reviews.freebsd.org/D32944 "b64encode: implement -w to wrap lines" >https://reviews.freebsd.org/D32945 "Implement base64(1)" I would like to start applying these, one by one and see what kind of issues people will find. Hopefully nothing major. >First, I modularize uuencode and uudecode by wrapping them in >bin2text2bin.c ("binary to text to binary"). The program will be >installed as bin2text2bin, uuencode, uudecode, b64encode, and b64decode >and will be responsible for running the coders according to their >historical behavior. > >Additionally, bin2text2bin will be able to take a parameter designating >the coder and accept all its options in this form: >bin2text2bin [options] >and the behavior should be the same as if > [options] >was invoked. >This has the advantage that adding coders won't require installing them >as binaries. I think quoted-printable or yEnc would be nice, but >currently I have no plans to implement those. This one is the one that I'm most concerned about since the change is pretty invasive structure-wise. It's probably missing some cleanup like make delete-old, but I know nothing about it. >Second, I implement an option to b64encode that sets the column after >which lines wrap. Plus, I accidentally optimize the function that >produces the encoded output. >Third, I use the existing b64encode and b64decode implementation and the >newly implemented option to call it as base64, respecting the syntax of >that program's invocation. I updated the two changes mentioned above yesterday. Now getopt_long() is used only once and then the options are passed to new special-purpose functions. This seems cleaner than using getopt_long() to reconstruct options for another getopt_long() loop. I've done some git-rebasing on the way so that's another thing that might be wrong - but I find that less likely than bugs of other sort. Piotr From nobody Sat Apr 9 03:25:08 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7C6011A906C7; Sat, 9 Apr 2022 03:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kb0qj338lz3Jp3; Sat, 9 Apr 2022 03:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649474721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=Y3yxpgZoxfflKs/ZkOzVqaw9vXhF5AjrPD0Z5Qzv9uQ=; b=Ovcwiiq9eZ28t5XY5l699kni+MoO7tCEi8o+eeA6iOCNpE+wENuVfDZSJ7yZ4+IFVqQq1r QyAhBoHLeDC81tCqFeP80OsLEn0UGBMDaxPUXbhS2wXmymquQRPN+XX+uPnXHp7OgVYZif 6EUxfhte3Zy8kfbhlohl1eXBQERFiy8c1rfDLln7MwmS9rJK4fC3TemhuvWSnIUkdkn3FN vOrhaYda95v6H8jD7q2a757gQCyq2EUdLd3Oimwn1EBX9XK/WJAU9l/K+/D0W4IG6ZibqE r1ys5H6e170iRW7NmUBR6veG8eXQhhFLwnwgSzTzXNJ0WOBVCG1/BihKZRalJA== Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 441CD20B9; Sat, 9 Apr 2022 03:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f46.google.com with SMTP id h14so12836664lfl.2; Fri, 08 Apr 2022 20:25:21 -0700 (PDT) X-Gm-Message-State: AOAM533k+6J/5u5TX/3ozgWzF+n+C4WAsJFJUNIvRtmUmoOdM2aPnOHG TF0BJ3zrVPDt4W80GhdEihkSrc8Esz53dq5hH74= X-Google-Smtp-Source: ABdhPJysOwpyBhHvkLM1vZbPZTl0uCPpZxuEyZwZdngkIYlvl9e6kt7CFeFgytu0IuaYCZeBVxVYUZ0lIKIjoFGrDgU= X-Received: by 2002:a05:6512:22d3:b0:44a:518d:c23b with SMTP id g19-20020a05651222d300b0044a518dc23bmr14598737lfu.21.1649474719782; Fri, 08 Apr 2022 20:25:19 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Kyle Evans Date: Fri, 8 Apr 2022 22:25:08 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: [RFC] patch's default backup behavior To: freebsd-arch@freebsd.org Cc: FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649474721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=Y3yxpgZoxfflKs/ZkOzVqaw9vXhF5AjrPD0Z5Qzv9uQ=; b=cSr6bXBo77hbjorcaszsH/yMub8iNstUTzQuLlRto/fBfzL85CtNUJy1N30CyjKzy3oPwn VlwUJz1Yq2oIE3AyHduiFv2rpXCte/EpHbw4+KIfSPTotkGrNUbdSyAIq1to4WsN2jZEGY fcwAp5jpqzm1+ryI/xuyLy8k5Lrm1OTxLn2GCLHklUVTJctj/+YMSUmJTgPpCe65AAWuAf fgI8QMKJj/ue4b4bcW9cYe9znGn80UQPt9pqXLuD+pR3ewcIzLPklgG69JKN0O2tioReHO 0JCgA2Opan8s1ecFwk3xmIfZRaa636l1rKinnNhLo92mhZfbIYDPEZS5UvoZbw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649474721; a=rsa-sha256; cv=none; b=wDYoECRxRtgayJnJt8jHJrEtQp9kTTVEl27ZUXmAk+9vkPVDeErtdQWiS+0Um3yd4KYVoX bhMClXS5q48IIBCZoRanBdK/SvpiGHdMQ3majeaXx2pfAMRSMBiz1yv4VPW59nC7t2BYSZ EveAQ8WF2Pq+NW/gw+xNbFKBcEwdamHWKpMWin7VFiEiT0o2+dlJDkkwWAEmovcesEKkvA FJWQX15sJuLsO8CBzGueDIK2UUdOZO6lBDSmEK0IX02B4Rl6CMgeDg57jS7tUxWydVYmNx vxlr9NdNdWYkztbaA5sOAod/camErrnBa1AvP6oku8hvhexjvE+U9k4Enny1QA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello! FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, where a backup is created for every file patched. I'd like to test the waters on switching this to the GNU behavior, which feels a whole lot more reasonable. Notably, they'll only create backup files if a mismatch was detected (presumably this means either a hunk needed fuzz or a hunk outright failed). This yields far fewer backup files in the ideal scenario (context entirely matches), while still leaving backup files when it's sensible (base file changed and we might want to regenerate the patch). Thoughts / comments / concerns? Cross-posted this to a couple of different lists to try and hit the largest number of stakeholders in patch(1) behavior. Thanks, Kyle Evans From nobody Sat Apr 9 03:41:44 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7784C1A951EF for ; Sat, 9 Apr 2022 03:41:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kb1Bq4YRRz3Njf for ; Sat, 9 Apr 2022 03:41:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2f.google.com with SMTP id r25so7087493vsa.13 for ; Fri, 08 Apr 2022 20:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HGk+thzFTctV//nQfaFYIijxcu9GDJOv5QxpgEAtTk8=; b=Y/1zsl7WnH1cYIqq5Le4hlwYbLJ/HnRCZRiXjCxQhsugW6fuRH8yutHrOHm6061TlT RUSTKfQOJcemZSBpYNu29PXV6cdhKIX2tCBwCf9fhYFrhzrY9+Z9waAO3grLG9G+AME9 Uiy7L6MdSlwkwjrYTCZF/qUayZiG3wng2+S0TwdjOZ9pxCxEBDXkpJ4tH1/u4xOdDnlh Bh50NkcvXjKUrDIr8jRILaCEHrRe5Wo5muaWyHzOTL1z4IpQA7GbQ7Z4LAf03rO52NWt TwyUBNKpxi8A8JO39nBjcmsUtokDPd/J3rnxpd6WfXZSVfdhwcvVrD8OrDUAEA2XF98I vVug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HGk+thzFTctV//nQfaFYIijxcu9GDJOv5QxpgEAtTk8=; b=uHng+neSvI1GApGL/vAMB1EsiK9z6flprh09eFY3vMxAitQG04BgodOCRRoVo91nF/ mZo0mY5zKKMTXADze6VzYkGAcnT03AInIMhu0wedRE43TF8C5TpfM67DAnrv981h9WDZ IqEfT3BbwZemEg8Q0xt7/d1qW8aosiYzyRpJFepPXkOAwH7dvj4DXZAUcPt0jnoCJ4yY WAxkU4l5hfzC19MvI9fa1xVlt4HuZdwomosCJOxLInO3v26WJOGcd790ucV5sc4OrdGq tXOQ9NVCRxUGvZ6rJa4sKl4uu7HK3Wf6mC6mqpOEWM6Ulv+iWY74X3zozj0THr+Y8CcA IGLQ== X-Gm-Message-State: AOAM531p866e78svDcNZ3op2xJy0dn3UtOqAprdRk3xDjVSU3rlESP8y ugL43mn1HzX30u5JOk2P8O6GcJsX4i7fhIAZZ7J+ozL668gjfw== X-Google-Smtp-Source: ABdhPJxrZpD7rzEzckUUUuQvhRd7l/DqYqMHO2oW1CGrU2u/wBHqoydv0Sul+xsJTCKytwiLzNFXRIgVDk+furDWrLc= X-Received: by 2002:a67:cb81:0:b0:328:da1:312b with SMTP id h1-20020a67cb81000000b003280da1312bmr4497196vsl.6.1649475715041; Fri, 08 Apr 2022 20:41:55 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 8 Apr 2022 21:41:44 -0600 Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Kyle Evans Cc: "freebsd-arch@freebsd.org" , FreeBSD Hackers , ports-list freebsd Content-Type: multipart/alternative; boundary="0000000000000fa54005dc307e7e" X-Rspamd-Queue-Id: 4Kb1Bq4YRRz3Njf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="Y/1zsl7W"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2f:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --0000000000000fa54005dc307e7e Content-Type: text/plain; charset="UTF-8" On Fri, Apr 8, 2022, 9:26 PM Kyle Evans wrote: > Hello! > > FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > where a backup is created for every file patched. > > I'd like to test the waters on switching this to the GNU behavior, > which feels a whole lot more reasonable. Notably, they'll only create > backup files if a mismatch was detected (presumably this means either > a hunk needed fuzz or a hunk outright failed). This yields far fewer > backup files in the ideal scenario (context entirely matches), while > still leaving backup files when it's sensible (base file changed and > we might want to regenerate the patch). > > Thoughts / comments / concerns? Cross-posted this to a couple of > different lists to try and hit the largest number of stakeholders in > patch(1) behavior. > Could one select the old behavior? Or would it just be a change? A new -V value? I like the Idea. Warner Thanks, > > Kyle Evans > > --0000000000000fa54005dc307e7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 8, 2022, 9:26 PM Kyle Evans <kevans@fre= ebsd.org> wrote:
Hello!

FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, where a backup is created for every file patched.

I'd like to test the waters on switching this to the GNU behavior,
which feels a whole lot more reasonable. Notably, they'll only create backup files if a mismatch was detected (presumably this means either
a hunk needed fuzz or a hunk outright failed). This yields far fewer
backup files in the ideal scenario (context entirely matches), while
still leaving backup files when it's sensible (base file changed and we might want to regenerate the patch).

Thoughts / comments / concerns? Cross-posted this to a couple of
different lists to try and hit the largest number of stakeholders in
patch(1) behavior.

=
Could one select the old behavior? Or would it just be a = change? A new -V value?

= I like the Idea.=C2=A0

W= arner=C2=A0

Thanks,

Kyle Evans

--0000000000000fa54005dc307e7e-- From nobody Sat Apr 9 03:44:34 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E8B781A97C07; Sat, 9 Apr 2022 03:44:47 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kb1G74TCzz3Qhn; Sat, 9 Apr 2022 03:44:47 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649475887; 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=HccpfTPByUs1r/d4/HLDOSSDmQwfELQvqYaDT9Iv0h4=; b=DgSaBuMWWBA+ClhqbENhnqJ/1jgLsvMNOscT3U7E+x7k3VG4AyxlU27MvfEXxKe8tv5S3b vgzyNl/rkOk3wHwdK6VzEQmSJkb0TRMjEjSQS+iQefAxHu92xtSQ5lFRojrLSmgEc7xOJc nmBGZyo7jWN2Fc9Tbd7MRXfeGMvTl5ARyIIqS5jwq8KfOnndkzEE49igmO+vpky5nV4W8q DL19+LUgCZGxZ/Q6jX8pVtkj9r2u6T7eK1Dy8DF+1dks1VJjqGUendu2quOB1+fwxnsQHB ewzfCJyN5DuXYD6UyYFT4fSjRC1LH/veXYFmzht6VXtkQR9jxqOnlTbbjnbDDQ== Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 5FAC7271F; Sat, 9 Apr 2022 03:44:47 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f179.google.com with SMTP id b43so13710145ljr.10; Fri, 08 Apr 2022 20:44:47 -0700 (PDT) X-Gm-Message-State: AOAM531lZgrUJQwLnN8nCyOtq+0q/nFccxrzbUojXR7eq1NQ/oF/XETO Vow68q0hLwkwbiimAWzkPL0IZBzJJ0Ygsx9y9Rg= X-Google-Smtp-Source: ABdhPJzyPcKOYpvFh9ArJmbICY95A33Gktc3Upb5Zu5sNLf3KNGuZeUVG4D2ZGafAMjfxUzEIR40mqfAHi9X867/zmU= X-Received: by 2002:a2e:7c16:0:b0:246:377b:f802 with SMTP id x22-20020a2e7c16000000b00246377bf802mr13466303ljc.155.1649475885638; Fri, 08 Apr 2022 20:44:45 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Fri, 8 Apr 2022 22:44:34 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Warner Losh Cc: "freebsd-arch@freebsd.org" , FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649475887; 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=HccpfTPByUs1r/d4/HLDOSSDmQwfELQvqYaDT9Iv0h4=; b=Kg/mpDa9tbUD1YPmM6owe7FdJaCyQXBZ5qtSZxCk2Ud/IjHPS8zTshWqh8dVVrAmruq3x7 ckr1DUTI8AVh0pZC1F/NCqqagpVlK79tmfa++lPFOIZl/V8zSRabr6TspnvSMz96Hq4HCw nZm6egqeOIm3a9ZPMKMyYsSkoE28rMhCh7KH3v//7r1TikB3u9rKDTpRTrFbM2HeoCQXAa 0eE4+VbzRcCao8X6G2Uw+AICiPdM8cyh9l1JZAHeprkc1SXZiWmwGC9c6TMWaAS8eZmd+m wF8L7jytTxd5KsYUI+foW22fvmOwr2zKcSro7AoxyCuiseQSCIyGDrOqVdwq0w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649475887; a=rsa-sha256; cv=none; b=KhwikacqGO/22AH//0hMpXIccETK3XXZvNI385rwHlmME7pSMit0Emx67y8hDt0ZCV1MXg mGhP0+jjO+8HGQ7ZmFUFkueJwH2b7gpG618zY5iBI2pcr3LYDIvTi3WQ2MB2IQXqRUL2JG rN/1LX9DnviP+nEczYGwPU75PxT9CxsUA7ETQzvZNe8a1oODqmK+wZ1e2SAEw/lvKlaguQ GNT6lcR0v5sqczZWRUFI+qZZK7aJK2GQxPbIhZTiTC/rzFobGWs/mxNor6Jr+NrzF1ucVW fV8L34QlkzQaCro0b5uZSBlBulvQXRh5JkjOqhqJdAZxeD+CQKzStsKP36zcSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 8, 2022 at 10:41 PM Warner Losh wrote: > > > > On Fri, Apr 8, 2022, 9:26 PM Kyle Evans wrote: >> >> Hello! >> >> FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, >> where a backup is created for every file patched. >> >> I'd like to test the waters on switching this to the GNU behavior, >> which feels a whole lot more reasonable. Notably, they'll only create >> backup files if a mismatch was detected (presumably this means either >> a hunk needed fuzz or a hunk outright failed). This yields far fewer >> backup files in the ideal scenario (context entirely matches), while >> still leaving backup files when it's sensible (base file changed and >> we might want to regenerate the patch). >> >> Thoughts / comments / concerns? Cross-posted this to a couple of >> different lists to try and hit the largest number of stakeholders in >> patch(1) behavior. > > > Could one select the old behavior? Or would it just be a change? A new -V value? > Yeah, the current behavior is actually represented by the `-b` flag. With the new behavior, we'd specifically implement `--backup-if-mismatch` (a nop from the beginning), `--no-backup-if-mismatch` (turn off backups, equivalent to `-V none` but "lighter" in that it won't override -b/-V) and we'd leave existing flags otherwise alone. > I like the Idea. > > Warner > >> Thanks, >> >> Kyle Evans >> From nobody Sat Apr 9 13:06:33 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 24B5A1A9A9C3; Sat, 9 Apr 2022 13:06:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbFkP14xlz4bL0; Sat, 9 Apr 2022 13:06:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id dAixnHzbogTZYdAnUnLzjm; Sat, 09 Apr 2022 13:06:36 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id dAnSnMspFqyysdAnTnNbrL; Sat, 09 Apr 2022 13:06:36 +0000 X-Authority-Analysis: v=2.4 cv=Y6brDzSN c=1 sm=1 tr=0 ts=625184dc a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=z0gMJWrwH1QA:10 a=7Qk2ozbKAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=whenkf9jZ82PwOJKZ_8A:9 a=CjuIK1q_8ugA:10 a=HNhVPpsFFhwA:10 a=1lyxoWkJIXJV6VJUPhuM:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 51896115A; Sat, 9 Apr 2022 06:06:34 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 446673AD; Sat, 9 Apr 2022 06:06:33 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Kyle Evans cc: Warner Losh , "freebsd-arch@freebsd.org" , FreeBSD Hackers , ports-list freebsd Subject: Re: [RFC] patch's default backup behavior In-reply-to: References: Comments: In-reply-to Kyle Evans message dated "Fri, 08 Apr 2022 22:44:34 -0500." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Apr 2022 06:06:33 -0700 Message-Id: <20220409130633.446673AD@slippy.cwsent.com> X-CMAE-Envelope: MS4xfPlcm9V00LeZBmPaR+826IRgrXaRXST6AAYJ8Q9k5TOYzzcKJaAW7ULXXCvQQz6LnQ0BsgNnFzW3mj8hSrHAm7RywHVElykilB7Ikbn7XBbDn03AwEWh wdPNlu0+nRX3RhSz958tFK1OS80d0QB9ECyR9kY7mlu1ILCWyyeBJXl2hT/Gqnd1cgRYeJy8C22y4rrlQl4RLZf2WAMLnd8uP9EmETlFsKZwU7BZrYcZptFz n2J+T+bVigkhZJZZaOL59+NftFszBr0n7Rt48vt4sblFeZFVpDqJFG/lLnBBSES3bb07ZZRsbV9HTdKcCtGXWIaBTK0wmk9nMN12NalOlvQ= X-Rspamd-Queue-Id: 4KbFkP14xlz4bL0 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [2.11 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.910]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-ports,freebsd-arch]; R_SPF_NA(0.00)[no SPF record] X-ThisMailContainsUnwantedMimeParts: N In message , Kyle Evans writes: > On Fri, Apr 8, 2022 at 10:41 PM Warner Losh wrote: > > > > > > > > On Fri, Apr 8, 2022, 9:26 PM Kyle Evans wrote: > >> > >> Hello! > >> > >> FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > >> where a backup is created for every file patched. > >> > >> I'd like to test the waters on switching this to the GNU behavior, > >> which feels a whole lot more reasonable. Notably, they'll only create > >> backup files if a mismatch was detected (presumably this means either > >> a hunk needed fuzz or a hunk outright failed). This yields far fewer > >> backup files in the ideal scenario (context entirely matches), while > >> still leaving backup files when it's sensible (base file changed and > >> we might want to regenerate the patch). > >> > >> Thoughts / comments / concerns? Cross-posted this to a couple of > >> different lists to try and hit the largest number of stakeholders in > >> patch(1) behavior. > > > > > > Could one select the old behavior? Or would it just be a change? A new -V v > alue? > > > > Yeah, the current behavior is actually represented by the `-b` flag. > With the new behavior, we'd specifically implement > `--backup-if-mismatch` (a nop from the beginning), > `--no-backup-if-mismatch` (turn off backups, equivalent to `-V none` > but "lighter" in that it won't override -b/-V) and we'd leave existing > flags otherwise alone. Looks good to me. > > > I like the Idea. > > > > Warner > > > >> Thanks, > >> > >> Kyle Evans > >> > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From nobody Sun Apr 10 15:21:56 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C58781A802A7; Sun, 10 Apr 2022 15:22:09 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbwhK5BS1z3QT4; Sun, 10 Apr 2022 15:22:09 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649604129; 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=f8pnRzvxMYr7mzzuQKb4VNfO3I5D8B4RHQLdO7cAkpM=; b=R5Sgs0XhsfCx0GvjnwTg1SdbMhmywjLHvkpICEV20ucNf83iVE3z3xBHkfssyA0XzBInZL OvsXwm/3Z4hVBVZ0+Pfbh2gtqqxJS1IPPTaQLHYDa40udZIPv9k5Oo5Bl4EdkR1k4nAhHz PSWC27x4ageQQb2Ua98+6LmmatrV54TRnF/+E8ggDpJ6C+icqb//NnV3MgZr4I7i4MZB4g pljnkX6+fU97GWv8KIkVyARv4GXD33MvgNeXdVV9ztioZtjL37uuuNZIB5e7rMVoyPcaj8 T326cns0wfKZdvyJHPbYjT3dbyTSaWdicaft27M2rUZQk4uv3sDqVTt0OW0KSQ== Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8FE752603F; Sun, 10 Apr 2022 15:22:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f42.google.com with SMTP id bq30so9835971lfb.3; Sun, 10 Apr 2022 08:22:09 -0700 (PDT) X-Gm-Message-State: AOAM533Ft514UNoMPEsNd1csw0SrEcVfnZ8IkSFR9kCTUMh3203nwMzd HYb9saHyUsGpSB6y2FlrxNmdnuO8x1Z08tRQOk8= X-Google-Smtp-Source: ABdhPJw81RkuwjIjEIuoMmfhAKxD0q7To/wBNmepcGP3hCF+WRSVMHLhs8DXScueQpptsVxofzop81HXCAJybeW8Xc0= X-Received: by 2002:a05:6512:39c8:b0:46b:9aed:389f with SMTP id k8-20020a05651239c800b0046b9aed389fmr3816778lfu.194.1649604128153; Sun, 10 Apr 2022 08:22:08 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> In-Reply-To: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> From: Kyle Evans Date: Sun, 10 Apr 2022 10:21:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Matthias Andree Cc: freebsd-arch@freebsd.org, FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649604129; 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=f8pnRzvxMYr7mzzuQKb4VNfO3I5D8B4RHQLdO7cAkpM=; b=Pr68PfcZLqPB1/jcjGpnbodHtWaQqwoyuthlz5gAdq1qZw/gHhVUgZDlLhXmwEHMVI+pOP Mn1VObhmX+cY1KP6iMHEe+0q4sWRDufbsZWu/ceIIpKDq3t2IAuQbNiWXqLzynHrxlJAlG ZIPB5nm3ClncuY7FkKV6FNgJw+HDmY8lSf0QKQ187G6CwWJiu3iOlkP5rHzrI3RSyFR/Ox U97iidGP+QQ0VgK1dQ34MnfxaKXEnRgClPrReVxZCLsqd5QOXMhnoWYIZm40LxSBA1Aon7 EorUTp0CvyjS7OFHv+JLbvtHhtxyr31T+TIdMikbk0BFdP5NfU3vfiRYL39kvQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649604129; a=rsa-sha256; cv=none; b=AWS1qjVBCB1kU6FoW5rQdajzUBmPx83lH3aFdAFFCN4CPv2kWnZ6GpP7NK1VQnQvP3usJZ JMI0TJH5fsgtPep4pQqb0vR5m5FJsovCXGGEOnMT09zG351Vm+ROHHHNLkDxEYbyt+ZAfN tVpAMBIfmpLQJhKAdxBuCIZy7l5o9iWYFs9x7ooyWP4q3vHF8PUxA0Jxuc5Y/MNMybP+oq zqv09W5H72IjWO9AqiB0c44vSp+mHfyRi3xSDVwCOTljjoi/g4VOXlX4LRgtbs26GmkOWX e0YZh8k6n/Wjylil+H4ldsyKQhtlQ4U2TZJiXsoICEu8CQRaap9M/dluIA/CrA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree wrote: > > [resending from hopefully subscribed address that it makes it to some of > the lists] > > Am 09.04.22 um 05:25 schrieb Kyle Evans: > > Hello! > > > > FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > > where a backup is created for every file patched. > > > > I'd like to test the waters on switching this to the GNU behavior, > > which feels a whole lot more reasonable. Notably, they'll only create > > backup files if a mismatch was detected (presumably this means either > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > backup files in the ideal scenario (context entirely matches), while > > still leaving backup files when it's sensible (base file changed and > > we might want to regenerate the patch). > > > > Thoughts / comments / concerns? Cross-posted this to a couple of > > different lists to try and hit the largest number of stakeholders in > > patch(1) behavior. > > > > Thanks, > > > > Kyle Evans > > > > Kyle, > > you would discard the original reference for gendiff or "make makepatch" > in ports, that would make patch - edit - regenerate-patch cycles require > extra efforts, and if that extra effort is only remembering patch's -b > option, but if we do it consistently for FreeBSD 14 and announce it in > due time beforehand, fine. Certainly worthy of release notes. > Arguably, `make patch` should be using the `-b` option even today to be portable across different patch implementations. Yes, we have our own patch with our own behavior that we can rely on, but I'm personally a fan of not tying ourselves and, perhaps more importantly, others (downstreams) into one behavior when we can trivially wire it down. > I personally also dislike and advise against "magic" and if-then > behavior. It makes documentation less concise, it makes tool behavior > more complex to judge, and from people who script a test-based approach, > this bears potential for confusion, astonishment and other effects, > because behavior as to when we get .orig files gets *apparently* > inconsistent, and may send people who have not read the entire manual to > the letter on detours finding out why they sometimes get .orig, or > worse, when developing patches, and interaction with other tools might > surprise people, too. > There are certainly trade-offs -- with the GNU behavior, you can instead quickly use the presence of an .orig file to know that you may need to sanity check the result and tooling can key off the same rather than checking patch(1) output for words like 'fuzz'. fuzz has bitten people before, it will bite people again. I'm not so sure that the scenario you write about will really happen. GNU patch has done this for many years, and I haven't seen such a proliferation of confusion. If anything, I see more confusion in practice from BSD patch's default differing from both the much more common GNU behavior and also from POSIX-specified behavior. > IF we are to change policy, my vote is to ALWAYS leave the .orig files > away and not only write them if we also write .rej files. I explicitly > dislike the GNU behavior, which seems geared for interactive use rather > than scripting. > re: interactive use, I think that's an entirely separate debate, even. :-) My personal opinion is that defaults *should* be geared more for interactive use, and scripts should be (+ able to be) entirely explicit about the behavior they want. This is a general opinion, not just with patch. If you solidify script usage with flags, then we can be a bit more fluid so that tooling can adapt to the ever-changing user landscape. Obviously you can't reliably predict potential for future behavior changes, though there are some obvious candidates like this one where the difference in defaults between us and other implementations are well-known. > I checked POSIX 2018, apparently the backup files (.orig) are only > required if -b is given, so omitting them would seem fine to me, and the > rationale section suggests that for consistency with other utilities, > the default would be to NOT save .orig file, but the -b option can be > used to request them being written (but then consistently on all files > not just those without rejects - also because there is no working patch > -R for ed-style diffs.). I'd actually be OK with that, too, to an extent. Thanks, Kyle Evans From nobody Sun Apr 10 15:48:06 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E03711A87DBE; Sun, 10 Apr 2022 15:48:12 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbxGN03Sdz3lc5; Sun, 10 Apr 2022 15:48:12 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id s28so3668920wrb.5; Sun, 10 Apr 2022 08:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=Yewh/XlVg5+aywoADu3h0ltVxqXZcs72Sk6Dq+0qLOI=; b=njOtJs+CHcZS1s3H+H2NE/OqxQcS/JeD+J+jc95IzkdUUUh5uWZoG2XGwWMY67vLt/ tEkaWcf/90NaQI9zx7LuXZMi0p4Vo2S/FyklDSQjXtcyGZRxkH0URFA6VrpHLoXVn+Pq mF6KRJHpWuPMOlu8fJsjbQnkEXCuzdrVbktuQFFCHfAvDh6qVcwRHygrXT9vkwqCD+Z7 4BJuNgPkeNCq/d5Ck4a13HMqIo83XNwirfqMhYOfStiheYJvP+XcEer15h3614mcGIMY AP+M+K2WeZgT1Lfz89RufNpszS/UrOtOvQWgRzGxmUu1hwYyGlu0VGgkiSkoRsGNfTeh idgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=Yewh/XlVg5+aywoADu3h0ltVxqXZcs72Sk6Dq+0qLOI=; b=cpvdcEMMWxeIC1N1w55R1BSoSdJ1tMJKZN4fKYHtIpqF8gH5JuvxvFE6d6KA3LjBTv 70MwAlBbdVpu1o9A/1yFWXjv/FYSsLD6ZhpzyHTePqG7uNi8THVb66b4AfZVsVHrBSyD 2tO7C4zIbquK7+u1lXMwDQiWjcc7RgsC/UDy6LQr5MiSUziVcL6hfdB8VKymblmIRsiP PuG9WceeTKUPkpLaSrI4yUFFxWpfrPON9U6IAJyfvYxHtZzYK3PMvxSQYagyfrqhKCUi ZJEl26i+qPdKJIyThaCsgtq6nUhDxN6d7MBp6pKu85qR3MEv4GMIsfO0lnMk8JO4dl6M sV3w== X-Gm-Message-State: AOAM533TpEpN4KTraEVMxG1/GnbKqk+cyckOLqJOoY5WYFjUrMpeDH6z X1d2FPCXhrEyyliR9YxuZedR1MZqE5g= X-Google-Smtp-Source: ABdhPJyEyWJ1CzupJagxM2+oVQugaVZamO/oQc2UWJ8Wn2UYXudnrGUAXKCg2WghbyZq0qypmfWcgg== X-Received: by 2002:a5d:6d0f:0:b0:207:990e:8e6 with SMTP id e15-20020a5d6d0f000000b00207990e08e6mr9161410wrq.384.1649605690866; Sun, 10 Apr 2022 08:48:10 -0700 (PDT) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id s17-20020adfdb11000000b001f02d5fea43sm24742088wri.98.2022.04.10.08.48.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Apr 2022 08:48:10 -0700 (PDT) Date: Sun, 10 Apr 2022 17:48:06 +0200 From: Gary Jennejohn To: Kyle Evans Cc: Matthias Andree , freebsd-arch@freebsd.org, FreeBSD Hackers , ports-list freebsd Subject: Re: [RFC] patch's default backup behavior Message-ID: <20220410174806.48e53928@ernst.home> In-Reply-To: References: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KbxGN03Sdz3lc5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=njOtJs+C; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-0.97 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; NEURAL_SPAM_MEDIUM(0.03)[0.028]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; MLMMJ_DEST(0.00)[freebsd-arch,freebsd-hackers,freebsd-ports]; FREEMAIL_CC(0.00)[gmx.de,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 10 Apr 2022 10:21:56 -0500 Kyle Evans wrote: > On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree wrote: [big SNIP] > > I checked POSIX 2018, apparently the backup files (.orig) are only > > required if -b is given, so omitting them would seem fine to me, and the > > rationale section suggests that for consistency with other utilities, > > the default would be to NOT save .orig file, but the -b option can be > > used to request them being written (but then consistently on all files > > not just those without rejects - also because there is no working patch > > -R for ed-style diffs.). > > I'd actually be OK with that, too, to an extent. > Please do not change the behavior of the -b flag! I make patches to /usr/src/ to eliminate things I don't want compiled in when I run buildkernel and buildworld and then move the resulting .orig backups to the original file names to eliminate those changes. -- Gary Jennejohn From nobody Sun Apr 10 15:52:35 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CA3321A89F21; Sun, 10 Apr 2022 15:52:48 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbxMh5Bc7z3nGQ; Sun, 10 Apr 2022 15:52:48 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649605968; 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=99XcnMzcRm5b8LiWj7h6PylRwjeEm10jcbTShBSSV78=; b=NvFfN86i3zSUxKTss7I68APY03TNYUB+E+5UTGFHtfWxnkXbFFApX6lKUCK+vkdAKLG0YI niU1ClkrmtRWtmiihznl6rTbzkHT3QCijKyZYWH8au7RL5iq/4QP7LBX0a4aEEnEqOGIBd fXZjvxMSa/RIb1+P4QwuLEYVQr1xkH1m//4rDdbpWn4soXhscn29hH+pzd46ZA7VS8TJXk P+eyGQhvB4iSirmt+qhRimp3vEtvzPfPsK1RDGbgyivCIu3ypIL8fMd9ZoeZmWGov5r4By ppVAj9oHnjJEi9DghBaWCEWVc65X54DtBPK1hrEfuCLlmEY1Y07f2RBzs/Vewg== Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8A3152628F; Sun, 10 Apr 2022 15:52:48 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f50.google.com with SMTP id x33so16228400lfu.1; Sun, 10 Apr 2022 08:52:48 -0700 (PDT) X-Gm-Message-State: AOAM533CmzueBuePJLlLFPmiZGKG1uis4OQ2muXDmEQX5QEe0TXUVNMx NbQCYL5iQWNSR0GwIxrjfEqQdlhwwfF5Gb8lQYM= X-Google-Smtp-Source: ABdhPJxnziySmo74fixHuIoUnxiXKbemJaTEgnKf+4h++BxcWwOICIWdkEZ95J33eUcUcH9GRVHnuneGUC8nO3Tb8RY= X-Received: by 2002:a05:6512:39c8:b0:46b:9aed:389f with SMTP id k8-20020a05651239c800b0046b9aed389fmr3883046lfu.194.1649605967183; Sun, 10 Apr 2022 08:52:47 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> <20220410174806.48e53928@ernst.home> In-Reply-To: <20220410174806.48e53928@ernst.home> From: Kyle Evans Date: Sun, 10 Apr 2022 10:52:35 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Gary Jennejohn Cc: Matthias Andree , freebsd-arch@freebsd.org, FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649605968; 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=99XcnMzcRm5b8LiWj7h6PylRwjeEm10jcbTShBSSV78=; b=aB2C4p1J5JUnwcVHLEhDld9ReNq1svngemBKTWnTP2nOVhnHAMwYqyM5shwP3gHRyKIrJw 3q5T5PCSMCuk9QqwLL5DbbCWaTpmOCVFGNK1l1+NfCef+soOsfoWpOkk/YId3NVdkedePq ngOgri96YHInKmhqUnbfzRyyI/MuUlZB3iwrKPlgvu9U4E0gns5YOBpKsMAVvkqY4VmsiO cIoD89gFO68kTXYY6c8iLqM3WzR0eei1odJMqjooAr4XlQV6nACWtTvDPZ/cqjfVi2Cyjt FCWkkwXhEw48PWnSbDFzYam5VHAPl0Bejkd5nZKubCOExeunBiYZ3GMbNaHmgA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649605968; a=rsa-sha256; cv=none; b=UwB61pCQZRIt+89dFGlNIlXeEgFKZ6ym4MT0Tn36kuNS8TWQ+R/dKVu/2kbUIZtWYQwXUN Espt3d6AIsdhDyT9IjXCNnjnMTZ6iqKHma1Y90//u/zvKDYhzFrrfjiaq6kTWWrka5eenj ywp0vroilsh3eQK+m3E7Eo2cPjgwaU8ewWFQRCl1lRRHGyPYC7jv3Gha+Q5pXGjTurjRwY UYn3N2JIVk496Huz1cbPebgUeiYxu5BvHEMi809+svVQgG2I0P+24nkjzAMQuZ+QXzHq66 gwEnz9Tk3I1kuZj8hFQIlaLV7SIB9FVOUJSZGdvs9RakSGc5ZzFhRuGwsp6HDw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 10, 2022 at 10:48 AM Gary Jennejohn wrote: > > On Sun, 10 Apr 2022 10:21:56 -0500 > Kyle Evans wrote: > > > On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree wrote: > [big SNIP] > > > I checked POSIX 2018, apparently the backup files (.orig) are only > > > required if -b is given, so omitting them would seem fine to me, and the > > > rationale section suggests that for consistency with other utilities, > > > the default would be to NOT save .orig file, but the -b option can be > > > used to request them being written (but then consistently on all files > > > not just those without rejects - also because there is no working patch > > > -R for ed-style diffs.). > > > > I'd actually be OK with that, too, to an extent. > > > > Please do not change the behavior of the -b flag! I make patches to > /usr/src/ to eliminate things I don't want compiled in when I run > buildkernel and buildworld and then move the resulting .orig backups > to the original file names to eliminate those changes. > No one has proposed changing the behavior of the -b flag (that would be silly), but rather the default behavior (sans -b flag). The -b flag is the proposed solution to maintaining the status quo across such a change if it happens. From nobody Sat Apr 16 18:17:08 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8FF189F733A for ; Sat, 16 Apr 2022 18:17:08 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KghHS3jJRz4qBd for ; Sat, 16 Apr 2022 18:17:08 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650133028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=36tl6RFWY402cZThrWNWapqGuFQKZ5aQPrSwnGqgvGA=; b=a6To3gvf6Ah3rj/lCMbxtK+81eDJjBuxOHsdfsdDdtmuzb5EgK6FZxr2Ef+UhlCobxuVSz jmNvS6xZSD8ytzsiBEiGq8N4Kn6rHSb8VTNK0rLiOe4ylH857ngysxLBAjJaQrZLaVEdRD 4o0Vjk7r8eZPw0H4OiYAZAUGorai51zizJ3RLF6tZmSn30ycgm4hpCpqFGNXnKnHg6F8MW ZcvSySZjwVxc03zBSIaLR9SZ2mXRuZjRrZQcXJZMpEGKm7nwQuV1GTIwKSg+aokGdMxyxo qwLWTY7zlF8/jVy+C92I11pUOQ3HWR/swGuOS8AIoKODnYJY/12QV078Xk8fmg== Received: by freefall.freebsd.org (Postfix, from userid 1403) id 63C661801D; Sat, 16 Apr 2022 18:17:08 +0000 (UTC) Date: Sat, 16 Apr 2022 18:17:08 +0000 From: "Piotr P. Stefaniak" To: freebsd-arch@freebsd.org Subject: Re: Introducing base64(1) Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650133028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=36tl6RFWY402cZThrWNWapqGuFQKZ5aQPrSwnGqgvGA=; b=UPWk+fDI3ebRx+h9rAT9PHD0BSdALuYlh41HzbNteqOFmlIV9eOCXe9kAi/6NsCg1UkJZ2 G+70YnmsYF++0QMFd4ZfAYnhwW8SxkXCAMD1HC3T/W7GEOmFh/iSK+kzrRpSTXNKefgJf5 jzm6+jM4KwXsiS4OL88hEC6boXC9GKvlEjJgmCr7zBGcuv4A3BcLeKiAZzORVMXK1aQM4q v6M0iHe2oJILuoVSs45REWIfDXf1Ss5Q+qQPPYl31LLQ6ACeQFCFJGs9QfHV3N2eFOn6hx YIzksByNhPfduJQxZhb/NaoCcy1UbDbm0H68dUuCgSgE5ERgL50OKqi5YRbwcA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650133028; a=rsa-sha256; cv=none; b=kH1wAeDl7kOJeKKp6YqvmwHEFWW7+HMPp37aDBeLkFJJb0qBp85Y0Rz7NlSq4lFM4hohml 2NRGaYlMQs4MfWF96YR3lFQ4AbcaY3pnyzsS5yUtBxM0XWXMK28nPEzDeGc+aK/PN93iJv KUX8IEeqBy8cgrZChWP57RmKGxzQNk1auxyZD9/KQror3MyvkFaS+5izQtaM4espPk+67i Klga9VsJUuHDUqOtyFJ6+VRHmBIF2NV5ltWLMOThTpj+bf+E93R5ijzsi444n/ZVf7UHAs Lr5Oq9HzvFLaqJPXgXVQNdhvQIXQfujfFwFd5fcUUUh0NGy0hpuFF3nDJIBGEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2021-11-22 19:16:45, Piotr P. Stefaniak wrote: >https://reviews.freebsd.org/D32943 "Conflate uudecode and uuencode" >https://reviews.freebsd.org/D32944 "b64encode: implement -w to wrap lines" >https://reviews.freebsd.org/D32945 "Implement base64(1)" I've updated these. Mainly I renamed bin2text2bin to bintrans. >Additionally, bin2text2bin will be able to take a parameter designating >the coder and accept all its options in this form: >bin2text2bin [options] >and the behavior should be the same as if > [options] >was invoked. >This has the advantage that adding coders won't require installing them >as binaries. I think quoted-printable or yEnc would be nice, but >currently I have no plans to implement those. That's changed now, you can also review this now: https://reviews.freebsd.org/D34933 "Import a quoted-printable bidirectional converter" Corrections, bug reports and other thoughts welcome. Piotr From nobody Wed May 4 21:48:39 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 79EB61AC9979 for ; Wed, 4 May 2022 21:48:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ktr7F32H2z4b8j; Wed, 4 May 2022 21:48:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651700921; 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=hP2sULsZqzOhvacSGzGOeH3lpC/ENGLGSfkDadu897Q=; b=Q3YuD9DY3lh3cT10E5BgmSgH2it9GsRnd739Lsl72x8SyfwZuYlOPgJUCkJxovjpjUlndD qzeQnocrU8tKpuV4oou376bb3gs1ihC75Sa0yVzeO4KSuBd+hgyOo4lfZgcEHNcs5abvEj AavDjBqnE/L/TzQo2YdjvnnMEbn/irCXd1BF5rLrCtvfkKxUXS8paSNLTcfScSmA10fV17 ImuDFHEVG3asGO6cOn4mADv5A86nZN9oGcbCY2W2iAXQkuNmiE43R+MQMosaum2SF8ofZk 5byBkjRPg8ABs2HIdM3JXBZ7TmQDJ2sJSOk357LPS/qA9z4MnZB6hVHuHwdVOg== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id DD6D98344; Wed, 4 May 2022 21:48:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Wed, 4 May 2022 14:48:39 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US From: John Baldwin To: arch@FreeBSD.org Cc: gallatin@FreeBSD.org Subject: Time sharing for interrupt threads Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651700921; 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=hP2sULsZqzOhvacSGzGOeH3lpC/ENGLGSfkDadu897Q=; b=EGkKtL2o80pkLLbGOrTd6KE9hAe80AqW/MBOi/cuCTniLzCvofBfw8Ix+wa8XSJim82LLm 5hrE0vUMXfjKlVDyK1mrQRLyt/ILHH7lR/YkiqQpTokRwk0uuyUijcTshc5Cg21N5N/tZH 3yyUh0aQ9rb2M1UnXBqW5c1EYM/C434k4pjKycBMlVQ7ddU70Wd/9DDbhQq8PflVenkWYh bmRFibgMD12LRCKvalv1cc556G+PGivvDafJAdlSlf2sxkCIjc3jjCdQGveBMfIDdpFJ/1 sVMmxkhMXlnNqWzQ5qM1NpLIIs9yG9/zxo9mMM3Yrkx/n1pBXTYo+z8YBRZHpQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651700921; a=rsa-sha256; cv=none; b=hcoV/JRUvzQnNsGvwwvx06pK91zeXzkgLFQHe4FYghx4Toof29aI34U262cvLm+LYl0nkB KPqcq8N4cxbARsL1U7QwV+BorOSvhuFG6ubSHEtXSlY2QO34lOhOkPJUPtjd8eShEuffuE c0F4QBahsokIwWuG8wUX/+VxXqQ9FwK0WsA8xfEDHqxGv2GXQ3lBVwEuTMtuyI1VfVILtB 3xh0yCDeVzboHTeygEwQgDyFbmuBXtYytHYT7b/z4mQJKwIPL9D5bjTNuBY1sbQctxJCUD zmQfIe8wr1ekyBODR+bWthtfSbUFMZzJ33jucVuvlFjw1tM1KQhG+PW9VJiNvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N My recent changes to the softclock threads (raising their priority) were to address a livelock issue in which a constant stream of packets could starve timeout events. However, in the discussion on the review (https://reviews.freebsd.org/D33693), several other livelock cases were raised. As a result, I've pursued a possible more general solution to livelock among interrupt threads. Previously I have toyed with the notion of extending our existing interrupt API to support cooperative time-sharing among interrupt handlers (where handlers would have to explicitly reschedule themselves before returning). This would be similar to what some drivers have tried to do in the past with scheduling tasks on taskqueues to defer work. However, this approach was a bit clunky (and the implementation was also a bit clunky) as it requires driver changes. It also requires drivers to try to understand how much work is "too much work" and knowing when to yield. Using tasks on taskqueues had similar problems. One of the other issues with the taskqueue approach is that the tasks would try to also yield by rescheduling the task, but this didn't actually work since the taskqueue thread handler would just see the requeued task and run it again right away, so the task always ended up running to completion. iflib attempts to ameliorate the requeue task problem by forcing all iflib devices to use a single pool of per-CPU threads so that the thread can at least round-robin among the tasks for multiple devices. However, this doesn't succeed in time-sharing with other interrupt handlers either for non-iflib NIC drivers or for non-network devices. It also still has the problem of drivers having to guess at when to yield. Instead, an approach I now think might be most workable is to do forced time-sharing via preemption from clock interrupts similar to what is done for userspace time-sharing threads. However, this would be a separate tier of time-sharing that only forces time-sharing among ithreads. I have implemented an initial prototype of this in ULE and Drew has tested it in some specific livelock use cases. The general idea of this approach is that sched_clock() (which runs at stathz) notices that an ithread has used a full time slice without going idle, the ithread's priority is demoted by 4 (to force it into a separate runq) and if there is a runnable thread waiting at the ithread's original priority, a preemption is scheduled when the clock interrupt finishes. The ithread's "base" priority is restored if the ithread goes idle (the priority isn't actually restored until the idle ithread is resumed via sched_wakeup, but it gives the desired behavior of undoing "demotion" once the ithread stops running and goes idle). One other constraint is that ithreads will only demote to PRI_MAX_ITHD but no lower, so ithreads will still always be preferred to non-ithreads. The changes to implement this can be found on the swi_refactor branch here: https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:swi_refactor One thing that Drew found though when testing this initially is that while non-iflib NIC drivers (which run handlers at PI_NET) could preempt each other, an iflib driver (whcih runs its gtaskqueue threads at a hardcoded PI_SOFT) could not, or at least not as well. My suspicion is that it just takes several full slices for a PI_NET ithread to demote down to PI_SOFT where the gtaskqueue iflib thread would actually get a chance to run, and that even with a steady stream of traffic the non-iflib driver occasionally catches up and briefly goes idle which resets the priority back to PI_NET. Drew hacked iflib to use PI_NET as a quick hack and once this was done the iflib driver was able to preempt the non-iflib driver smoothly. From that experience, I suspect that if we do want to pursue this approach, we may need to collapse our notion of ithread priorities a bit. That is, we may want priorities to look something like this: PI_REALTIME (PI_MIN_ITHD + 0) /* Reserved for "unusual" hardware like maybe clocks. */ PI_HARDWARE (PI_MIN_ITHD + 4) /* All "normal" hardware like NET/DISK/etc. */ PI_SOFT (PI_MIN_ITHD + 8) /* Software handlers like netisr and others. */ This way, once a hardware handler uses up a time slice, it ends up yielding to all other hardware handlers and if it uses two slices it can't even starve swis. It's not really clear to me that we need hard lines between different classes of interrupts nowadays especially if we force time-sharing between long-running handlers. It's debatable that NVMe devices (PI_DISK) should always be preempted by NICs (PI_NET) for example. In the review Warner had proposed a separate PI_FLASH perhaps for flash storage that might be above PI_NET, but I think it might be simplest to let a system auto-adjust to interrupt load via a time-sharing system instead. In terms of softclock, I'm not quite sure if it should still run at PI_HARDWARE or PI_SOFT in the above model. I think it probably still wants to run at PI_HARDWARE, but it would probably still work even at PI_SOFT in at least some livelock workloads. If we do decide to move forward with some sort of time-sharing, I do think we can possibly simplify iflib drivers by removing the global taskqueue thread pool and reverting back to just using dedicated ithreads. This would avoid the need for iflib drivers needing to figure out when to yield but instead let the handlers run to completion. One further historical note: the reason we have different priorities for ithreads at all is mostly just an artifact of moving away from spl. In the old interrupt masking implementation in FreeBSD 4.x and before, pending interrupts (both hardware and software) were tracked in a bitmask (in fact, there were only 24 bits for hardware interrupts, so we enforced artificial interrupt sharing by tying multiple hardware interrupts to the same bit) and pending interrupts were handled via an ffs() loop on the bitmask during splx(). When we added ithreads we kept priorities that reflected the relative order of the bits set aside in the pending bitmask. Certainly that is where the SWI_* values come from, and the relative ordering of PI_* interrupts is mostly I think a SWAG based on the the fact that at the time network devices needed lower latency than disk (which was all spinning rust). At least some versions of Solaris (the one my Solaris Internals book describes) don't assign differing priorities to ithreads at all (all ithreads ran at the same priority and I think the version of Solaris in question had per-cpu ithreads that handlers were queued to when an interrupt asserted). I'm less familiar with what other systems do in terms of the relative priority of device interrupts. Given all that, my question is if other folks think that time-sharing of interrupt threads is an idea worth pursuing (vs having ithreads always run to completion)? If so, do folks have feedback on the design or the question of collapsing ithread priorities? -- John Baldwin From nobody Thu May 5 07:11:08 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 78B8E1AB950D for ; Thu, 5 May 2022 07:11:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kv4cM6Tknz3FP8; Thu, 5 May 2022 07:11:12 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [176.74.213.87]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A900826021A; Thu, 5 May 2022 09:11:11 +0200 (CEST) Message-ID: <04f80ff1-2374-8f49-ac13-1c55570cb6c0@selasky.org> Date: Thu, 5 May 2022 09:11:08 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: Time sharing for interrupt threads Content-Language: en-US To: John Baldwin , arch@FreeBSD.org Cc: gallatin@FreeBSD.org References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Kv4cM6Tknz3FP8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.68)[-0.676]; NEURAL_HAM_SHORT(-1.00)[-0.995]; MLMMJ_DEST(0.00)[arch]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/4/22 23:48, John Baldwin wrote: > My recent changes to the softclock threads (raising their priority) were to > address a livelock issue in which a constant stream of packets could starve > timeout events. Sorry for short-cutting the thread, but why can't we have multiple worker threads with different prio's for timers? In USB we have that, once for Giant locked and non-Giant locked callbacks. I mean, all timer interrupts are executed serially and any congested mutex will make all succeeding timer callbacks halt on that CPU core! --HPS From nobody Thu May 5 07:31:11 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 071D91ABCCC4 for ; Thu, 5 May 2022 07:31:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kv53C6bVLz3HC0; Thu, 5 May 2022 07:31:03 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id AB1828928E; Thu, 5 May 2022 07:30:56 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 2457VCbG086648 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 5 May 2022 07:31:12 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 2457VBHH086647; Thu, 5 May 2022 07:31:11 GMT (envelope-from phk) Message-Id: <202205050731.2457VBHH086647@critter.freebsd.dk> To: John Baldwin cc: arch@FreeBSD.org, gallatin@FreeBSD.org Subject: Re: Time sharing for interrupt threads In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86645.1651735871.1@critter.freebsd.dk> Date: Thu, 05 May 2022 07:31:11 +0000 X-Rspamd-Queue-Id: 4Kv53C6bVLz3HC0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-2.97 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.972]; MLMMJ_DEST(0.00)[arch]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- John Baldwin writes: > In the old interrupt masking implementation in FreeBSD 4.x and before, > pending interrupts (both hardware and software) were tracked in a bitmask > [...] > At least some versions of Solaris (the one my Solaris Internals book > describes) don't assign differing priorities to ithreads at all [...] The original priority assignment we inherited in the SPL mechanism was mandated by ideosyncrasies of specific hardware-interfaces on the PDP/11, specifically DMA vs non-DMA transfers. Back then, serial interfaces, both asynchronous and synchronous, had neither FIFO buffers nor DMA, so their interrupts had to be served within one character interval, or they would drop data. A very real issue on a 1 MIPS machine with 50 serial ports. Already back in the 1980'ies, "big-iron" UNIX vendors had mitigated this with "intelligent serial adapters" or all sorts. When we came on the scene with our PC hardware, and it's two or more serial ports at 115200, the problem was back, and even the traditional SPL ordering was barely enough, so we got "fast interrupts" to implent a software FIFO (Thanks @bde!). In OS-theory, interrupt priorites should depend only on the need to serve the hardware "in a timely manner". In real life that may not have anything to do with the hardware, for instance an emergency stop button. The wisdom of prioritizing "NET" over "DISK" or vice versa, will almost by definition depend on the actual application, so my proposal would be to classify drivers into some broard classes, "NET", "DISK", "GPIO", "GRAPHICS" etc, each with a sysctl setting the priority. I would set NET and DISK to the same priority out of the box. For further granularity of tuning we could also have sysctls per driver instance or per interrupt. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Thu May 5 22:34:54 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 816931AB0525 for ; Thu, 5 May 2022 22:34:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KvT683FLvz3s7y; Thu, 5 May 2022 22:34:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651790096; 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=ifFQmnQ7iIR1pRicAZsQKES80us/Y2BvSxJI0WIJnTo=; b=V1XWmzhhu58Gl6kIa3EAwLwSjksht35SxQUwm/pEgmce5Y9ar4z/3IevjcU96iUgp+HPei lmkFKYAOq02IknNBPMubAy6N4XnaIQLmCEsa/3DWO09Z2/3WeKmT/0L4xUru0N1EYmi5Wg mLiLP9ME8y6yoJerZ+LDKF9ez0gLoKkWjXjOmjYdk1IUcj57JbdAPBid6eYdfQBMvk9Ygd 7CEAQm5OqFW8T5aVoKVdZjDLBbW0PGDoj4sXJcKttb4pCywMp115PGyKTc8xwJ9jMRDTol O9Zo5HaPuNhrWUgmw5FDrTBT1ty7ODuA7/8fdjuqQnxRrJiZfzbPzYqyPIVmxA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id E797E25931; Thu, 5 May 2022 22:34:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Thu, 5 May 2022 15:34:54 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: Hans Petter Selasky , arch@FreeBSD.org Cc: gallatin@FreeBSD.org References: <04f80ff1-2374-8f49-ac13-1c55570cb6c0@selasky.org> From: John Baldwin Subject: Re: Time sharing for interrupt threads In-Reply-To: <04f80ff1-2374-8f49-ac13-1c55570cb6c0@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651790096; 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=ifFQmnQ7iIR1pRicAZsQKES80us/Y2BvSxJI0WIJnTo=; b=n4ok+S4NOVX620cQlSCX08kUu3f+MuApjQCjYQ6xePs0UBX6IgWvGO5xM4wb4f7CkeNkNu xn0+S80dayLbqS0eaDrCByvOp+YWCksPNY4pJFqaC0OZNbMi2oDVjGIrdj4bLVoFKeBQ6b bglrx6KAl2IY912PD47qBA0g3XUXPNvYazV3Ko579cgsoz2jFRriQYjEFkFC680hQ9tmUU izE3TGlygLLUVa/48JRogkNxvszdSx8j7WAuEPBDQgwhV9YIieznOttTlyblVjxZ50Svor xL5mXrkf9aad1BImWg2BNTJ1DoXO7txFnbLc0e539gHQMVims7rI13N4FZaCDw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651790096; a=rsa-sha256; cv=none; b=nG0tHSbdRa3VLXvBcHewvTiQRd9NK+RxEzeE4qCjzuLpRz+ojHOlZ7N6IUXzGVpLHWfj12 mDUAZpQODzuha+2p5WjEa0R1NJE5nUcnG2d2r/6JQOjkP1Oh1c1M1XFe4m5G4ltBG6rsjz I7SUMwkmp/W9nSKvbhAq2id2eKo/JoH1Q/KF/9nXz35PoeSClVJEsIfPl71y/PEjFCTnmN YXVb4JA88EFCeEJye8gHmRVQL9FeTIanTM+8A1tbyKwsRVYDPckKNA2P9P9yS/0ydon88P w2w/Djb121mmQeXC7tU4BSpTQCEEZvfG/3KX5DZo9/go4IFmg2jKsrQglRMDWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 5/5/22 12:11 AM, Hans Petter Selasky wrote: > On 5/4/22 23:48, John Baldwin wrote: >> My recent changes to the softclock threads (raising their priority) were to >> address a livelock issue in which a constant stream of packets could starve >> timeout events. > > Sorry for short-cutting the thread, but why can't we have multiple > worker threads with different prio's for timers? In USB we have that, > once for Giant locked and non-Giant locked callbacks. I mean, all timer > interrupts are executed serially and any congested mutex will make all > succeeding timer callbacks halt on that CPU core! We do have per-CPU threads at least. However, this particular problem is orthogonal I think to the notion of if we want to enable time-sharing for ithreads in general. Having multiple workers for callouts raises its own interesting problems such as how you decide how to schedule callouts among multiple threads. I suspect that the number of callouts using Giant are fairly inconsequential at this point so Giant vs non-Giant probably isn't compelling. You could perhaps add some kind of scheduler-activations type thing where you either spawn or wakeup another thread when a callout handler blocks on a lock. That would be a fair bit of work though and not really related to this proposal. -- John Baldwin From nobody Tue May 10 09:26:32 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 20D7D1AE7D16 for ; Tue, 10 May 2022 09:26:47 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from sonicconh5003-vm1.mail.kks.yahoo.co.jp (sonicconh5003-vm1.mail.kks.yahoo.co.jp [114.110.61.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KyCNP5n3kz4dV2 for ; Tue, 10 May 2022 09:26:45 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) X-YMail-OSG: h6dUD1kVM1lNvETr8qvkJHUEttFu9nWuITccPQVrDeUAY3ey2ytAPhZvvt5xaXv iiPpD2GCF3Nph9HsmYsoW3CqxGN3UMvjjiMPTvOCSj8Dd8BNq2JfhrxeUGzUCKKL24w9nlq4coYx vthHaKXFRR9DcIvvPZkdON03n7WCWGwUsIERILlmKy9tyEkTeTY1BbLGF461ruJpncjqjocCsDGZ mTmX_NE5vbCfOqrYFnZ4PXYI1EClhKs6lq.i2qQuHf4hRI2sTmCVEsT4BFHiQSvbEquqXcs8d.CF uh2BjvEeQM.uavH.R6Rc8pZUlmtu3iEYCimh3NwaWMpQpZkwJyJAEG6.FT7fd_jmEM96YSkSvjTk HNACT2ujhNf_3j.dvyKo8p7mzYQgaaq_HDXdZcZQ3t0v.GkW77O9JXtjXuyaA6B1WMcroUnZx.tS qlfQwvfrPbvArN.95o_WfC.2YrYzsV4OE9y5b.zGSDmFcvDh7XWUkE7sQv94TEKTI8noMRWOz4qH kW1oaUTbgKB2PUn9dGehn4r7q2WC8f2IRg19__gOLDX.rKrKrxjQoTbsmcs8BVuE4B4ZJShHsw4W 6hO6.hbD.DEWBSFOb1_KSpKc.jYR5Ytx8dEwb7_XwsB4ZuELfolw947wCTIj_AkU9kfEEXygcfES N6HKcAJ1Lp0IiVZWNXxgyiPLN8iGFM8USBLde2Rjm43zL6Y_K4iU14QOVnFbEZDm5PCCfhkVMJ0P JAJJtkYALnuuJRZNMOpzkJzokM6fnzEsIYbH6TkMDlNwqYCVeLjPJPagZd6du20QHK9VJCcvUIdz vql8JQUMr8PqMmsAeudpSofGSTYJDUQOQO34Ak0Dj_Nz2te7n4QJtj_8ruDlwBj94tP1IllolnvP G5kSOkQdEJBKCYaW3etf7wQE9hTc9R8JU_gFEfsoRNw-- Received: from sonicgw.mail.yahoo.co.jp by sonicconh5003.mail.kks.yahoo.co.jp with HTTP; Tue, 10 May 2022 09:26:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1652174796; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:References; bh=+ok505zfKw7VsUQNEjRC+jxzi2KFPyTBpFfB2Zg/MBU=; b=B5DJOVNSprXymd4IViX60pPxKMC73WSMKSJU7VUAy95B3ynnWzBhV9bqP3jTxqJp 76cUkLa/nuEjtlyzI4iIluriEqcLEh3m81hNWM3VmDPef+58njo2OPpY0Y/Y0380XeL wmlMJ57KjHQ6qlYDAVf4HRWFNMQc+6hSncNhaN5c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:References; b=dareNmnMctGcy878nUM06mQzSncE2VYQmUzW3m6EByxdKROVG8+jmNaJjlLg+Zh3 tuGz7tZD1H+ZS6EfXIyuOFMseUDcQfSIGgIVvefQNvcwNrhSgNev4In5L+J/RNqAFWl L701V3dN4RTCJUi6C/0NRW7WrU4i8W1ZyDsvOrOk=; Date: Tue, 10 May 2022 18:26:32 +0900 (JST) From: =?UTF-8?B?44KEIOOCguOCig==?= Reply-To: Mori Hiroki To: "freebsd-arch@freebsd.org" Message-ID: <1106790730.2035302.1652174792061.JavaMail.yahoo@mail.yahoo.co.jp> Subject: Build error armv5 on 12-STABLE List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1106790730.2035302.1652174792061.JavaMail.yahoo.ref@mail.yahoo.co.jp> X-Rspamd-Queue-Id: 4KyCNP5n3kz4dV2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.co.jp header.s=yj20110701 header.b=B5DJOVNS; dmarc=pass (policy=none) header.from=yahoo.co.jp; spf=pass (mx1.freebsd.org: domain of yamori813@yahoo.co.jp designates 114.110.61.44 as permitted sender) smtp.mailfrom=yamori813@yahoo.co.jp X-Spamd-Result: default: False [-4.00 / 15.00]; HAS_REPLYTO(0.00)[yamori813@yahoo.co.jp]; R_SPF_ALLOW(-0.20)[+ip4:114.110.48.0/20:c]; FREEMAIL_FROM(0.00)[yahoo.co.jp]; REPLYTO_ADDR_EQ_FROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[yahoo.co.jp:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.co.jp,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.co.jp]; ASN(0.00)[asn:24572, ipnet:114.110.48.0/20, country:JP]; DWL_DNSWL_NONE(0.00)[yahoo.co.jp:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.co.jp:s=yj20110701]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[yahoo.co.jp]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[114.110.61.44:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hi. I have build error at kernel build on 12-STABLE. build error at this. sys/contrib/ck/include/gcc/arm/ck_pr_armv4.h also need this file at armv5 build. sys/arm/arm/elf_trampoline.c How to fix this ? Hiroki Mori From nobody Sat May 28 21:59:34 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7B98A1B5EA06 for ; Sat, 28 May 2022 21:59:29 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L9bDc3HfGz3DnR for ; Sat, 28 May 2022 21:59:28 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-ed1-x532.google.com with SMTP id t5so9261475edc.2 for ; Sat, 28 May 2022 14:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:from :subject:to:content-transfer-encoding; bh=FJXyUjMPANhueEjWrpzwOBcEGIjp38L2Ju4ih60rOWg=; b=ITFX6367Ggpq+ey/Qeqx3VJCbABILFNHqKDmoX6Xg17V0msIiETA5U7J6Zd4Xkx8tW eoiiUdEf1Zv02zuwvc3P+QGNg/qE0bjQO5v3t4zxJixd0NNgB3BRkMUOZ+pThL+lbAur v3/IDYw/TrIb4wYNE0NFyFVP0BjROg5DjHs0j6JTdfaObc+hInyQPLUFsEp7LFkVYwW1 30WNLzIWMDmmUpC/eioN6dm3E/EMavoBfJ/tDd4UlpoZ04R/oIO/e8fjqAv9mRN98IB4 BhKIsFMLFxV09FedY0OvQj6I5vp/8SWLgILrTE11lznHqVAj+aRoB9xB1mAGLr7cw29X KhKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:subject:to:content-transfer-encoding; bh=FJXyUjMPANhueEjWrpzwOBcEGIjp38L2Ju4ih60rOWg=; b=amrTP0CzJrabvD7zoWRyAkk/5jlb33hVy0DLPUkqcnGirBrZ+mSMTV6tTbc2ElnpIO Skxuh4HVL1O+bhUoSLFZDe+v/N3aP1RblLiqoXoGBVgu7czNiVU8bHNfemLQJqlTPQ4j PWMqBl0HYYdyC/t5uK9oSlMxFcsiZJQdx3QXP2FMOK+6qckEYc7lDqfK5Kfinkk0PRYI Jbh0qU7Dqg7P6Ghh+WbX0JyvJVZkLBWtMrEv4ErVKMJhtXwGV7Pb6k/xpu1IVeXfQXI3 hvG5G7vQA1F+OQcXq3sOHhN/lbsoxZW/Cp5bJbwOXEfiUYqjDsvndkPWasruV6dXz89i HDTQ== X-Gm-Message-State: AOAM531K+Wg04WZpmA/C0DLgto3FDIuIgSxRN37bNsY2Nn2mCsVX5K2T ryVgpSd3xPhjyMaDfa17d0M/0BNVo3A= X-Google-Smtp-Source: ABdhPJwLiP/91bedJqcWTLVYaVk0kfAqXxG0IxEX7SVxs8Vog/aLWHrwg/FI51X8whBlhOZU8ph9uQ== X-Received: by 2002:a50:ce09:0:b0:42d:2252:bc40 with SMTP id y9-20020a50ce09000000b0042d2252bc40mr8557318edi.294.1653775166410; Sat, 28 May 2022 14:59:26 -0700 (PDT) Received: from [192.168.1.26] ([87.13.145.113]) by smtp.gmail.com with ESMTPSA id 2-20020a508e42000000b0042ad421574esm4000325edx.33.2022.05.28.14.59.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 May 2022 14:59:26 -0700 (PDT) Message-ID: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> Date: Sat, 28 May 2022 23:59:34 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US From: "Alfonso S. Siciliano" Subject: bsdinstall TUI utility To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L9bDc3HfGz3DnR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ITFX6367; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alfix86@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=alfix86@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.98)[-0.985]; RECEIVED_SPAMHAUS_PBL(0.00)[87.13.145.113:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; MLMMJ_DEST(0.00)[freebsd-arch]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, So far I replaced and adapted `dialog` with `bsddialog` in bsdinstall/scripts. Currently, I am addressing the last 4 scripts: auto, bootconfig, keymap, and wlanconfig. These scripts use also the $DIALOG variable and some "if" to handle Xdialog(1). For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, Xdialog(1) is not used in this context (that is `bsdconfig -X`). Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to provide only the support for bsddialog(1) in bsdinstall(8)? I would prefer this solution because I can avoid: to handle some dialog/Xdialog/bsddialog command line difference and to hook some bsdconfig function built on dialog(1) incompatible with bsddialog(1) (for example autosizing, implemented in bsddialog(3) already). Please note these considerations are only for bsdinstall, bsdconfig is unchanged. Best regards, Alfonso From nobody Sat May 28 23:02:51 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E99FC1B39ABD for ; Sat, 28 May 2022 23:02:58 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from shxd.cx (shxd.cx [64.201.244.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L9cds6pZdz3M0n; Sat, 28 May 2022 23:02:57 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from lummox.shxd.cx ([10.0.0.254]:62253 helo=smtpclient.apple) by shxd.cx with esmtpsa (TLS1.2) tls TLS_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nv5SJ-000Alk-Hj; Sat, 28 May 2022 16:02:47 -0700 From: Devin Teske Message-Id: <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_D33AF0BD-A25C-40EC-A4F1-2EC18FDE640D" List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: bsdinstall TUI utility Date: Sat, 28 May 2022 16:02:51 -0700 In-Reply-To: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> Cc: freebsd-arch@freebsd.org, dteske@freebsd.org To: "Alfonso S. Siciliano" References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> X-Mailer: Apple Mail (2.3696.100.31) X-Rspamd-Queue-Id: 4L9cds6pZdz3M0n X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dtf@shxd.cx has no SPF policy when checking 64.201.244.140) smtp.mailfrom=dtf@shxd.cx X-Spamd-Result: default: False [0.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.58)[0.576]; NEURAL_HAM_LONG(-0.77)[-0.771]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.554]; MLMMJ_DEST(0.00)[freebsd-arch]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[dteske@freebsd.org,dtf@shxd.cx]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36734, ipnet:64.201.240.0/20, country:US]; FROM_NEQ_ENVFROM(0.00)[dteske@freebsd.org,dtf@shxd.cx]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_D33AF0BD-A25C-40EC-A4F1-2EC18FDE640D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano = wrote: >=20 > Hello, >=20 >=20 > So far I replaced and adapted `dialog` with `bsddialog` in > bsdinstall/scripts. > >=20 >=20 > Currently, I am addressing the last 4 scripts: auto, bootconfig, = keymap, > and wlanconfig. These scripts use also the $DIALOG variable and some > "if" to handle Xdialog(1). > For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. >=20 Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean = bsddialog? > * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. bsdinstall(8) uses only dialog(1) in the context of $DIALOG ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) > * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, > Xdialog(1) is not used in this context (that is `bsdconfig -X`). >=20 Correct, bsdconfig does use bsdinstall > Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to > provide only the support for bsddialog(1) in bsdinstall(8)? >=20 I object. I and another developer are adding support for zenity = https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfi= g = There is also work to resolve the namespace issues in bsdinstall = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdc= onfig = I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it = exists until those efforts can be completed. ASIDE: bsdinstall doesn=E2=80=99t use Xdialog > I would prefer this solution because I can avoid: to handle some > dialog/Xdialog/bsddialog command line difference and to hook some > bsdconfig function built on dialog(1) incompatible with bsddialog(1) > (for example autosizing, implemented in bsddialog(3) already). >=20 The differences in command line should be handled through conditionals, = but can be the default and opt to handle LGPL-dialog through a = USE_GNU_DIALOG flag bsddialog may support auto-sizing, but so does dialog and Xdialog. However, ... The sizing code in bsdconfig (used indirectly by bsdinstall) was written = because the auto-sizing that does exist and is available in both dialog = and Xdialog (as well as Zenity) does not provide a cohesive experience = when trying to write a program that is in-reality a series of bespoke = dialogs. The sizing code makes sure that regardless of which utility you are = using that the experience is uniform in what is presented to the user. Attempting to rely solely on the auto-sizing available from these = separate utilities (including bsddialog) would change the UI/UX. The problem was solved by: 1. Making the stored text used for dialogs dictate how it will look 2. Painstakingly determining where each utility failed given the text 3. Determining how to make the utility display the text properly For example, stored text will contain newlines instead of attempting to = rely on line wrapping on a box of given size. I would have to evaluate bsddialog=E2=80=99s auto-sizing to determine if = it is trust-worthy given not only all the stored texts, but all the = translations as well (as bsdconfig is i18n compatible). It is actually = less work to just allow bsdconfig to likely treat bsddialog as it is = dialog and let it perform the size calculations for you. If bsddialog is top be a drop-in replacement, I=E2=80=99m more than a = little surprised that it cannot accept the sizes calculated for dialog = being passed to it. >=20 > Please note these considerations are only for bsdinstall, bsdconfig is > unchanged. >=20 What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-turn = relies on dlg_gauge_reallocate(3) from LGPL-dialog? =E2=80=94=20 Devin= --Apple-Mail=_D33AF0BD-A25C-40EC-A4F1-2EC18FDE640D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano <alfix86@gmail.com> = wrote:

Hello,


So far I = replaced and adapted `dialog` with `bsddialog` in
bsdinstall/scripts.
<https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog>

Currently, I am addressing = the last 4 scripts: auto, bootconfig, keymap,
and = wlanconfig. These scripts use also the $DIALOG variable and some
"if" to handle Xdialog(1).
For example 'auto' = uses $DIALOG, $USE_XDIALOG, and `dialog`.


Can = we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean = bsddialog?


* $DIALOG: I = seem bsdinstall(8) uses only dialog(1) as TUI utility.

bsdinstall(8) uses only dialog(1) in the context = of $DIALOG

ASIDE: It also uses = dialog(3) and dpv(3)/dpv(1)


* I seem bsdconfig(8) does not "call" these 4 scripts, so, = probably,
 Xdialog(1) is not used in this context = (that is `bsdconfig -X`).


Correct, bsdconfig does use = bsdinstall


Is there any = objection to delete $DIALOG/LGPL-dialog/Xdialog to
provide = only the support for bsddialog(1) in bsdinstall(8)?


I = object.

I and another developer are = adding support for zenity


There is also work = to resolve the namespace issues in bsdinstall


I am in favor = of keeping $DIALOG/LGPL-dialog/Xdialog support where it exists until = those efforts can be completed.

ASIDE:= bsdinstall doesn=E2=80=99t use Xdialog

I would prefer this solution because I can avoid: to handle = some
dialog/Xdialog/bsddialog command line difference and = to hook some
bsdconfig function built on dialog(1) = incompatible with bsddialog(1)
(for example autosizing, = implemented in bsddialog(3) already).


The = differences in command line should be handled through conditionals, but = can be the default and opt to handle LGPL-dialog through a = USE_GNU_DIALOG flag

bsddialog may = support auto-sizing, but so does dialog and Xdialog.

However, ...

The= sizing code in bsdconfig (used indirectly by bsdinstall) was written = because the auto-sizing that does exist and is available in both dialog = and Xdialog (as well as Zenity) does not provide a cohesive experience = when trying to write a program that is in-reality a series of bespoke = dialogs.

The sizing code makes sure = that regardless of which utility you are using that the experience is = uniform in what is presented to the user.

Attempting to rely solely on the auto-sizing = available from these separate utilities (including bsddialog) would = change the UI/UX.

The problem was = solved by:

1. Making the stored text = used for dialogs dictate how it will look
2. Painstakingly = determining where each utility failed given the text
3. = Determining how to make the utility display the text = properly

For example, stored text = will contain newlines instead of attempting to rely on line wrapping on = a box of given size.

I would have to = evaluate bsddialog=E2=80=99s auto-sizing to determine if it is = trust-worthy given not only all the stored texts, but all the = translations as well (as bsdconfig is i18n compatible). It is actually = less work to just allow bsdconfig to likely treat bsddialog as it is = dialog and let it perform the size calculations for you.

If bsddialog is top be a drop-in replacement, = I=E2=80=99m more than a little surprised that it cannot accept the sizes = calculated for dialog being passed to it.



Please note these = considerations are only for bsdinstall, bsdconfig is
unchanged.


What = of dpv? bsdinstall uses dpv(3) to unpack the dists which in-turn relies = on dlg_gauge_reallocate(3) from = LGPL-dialog?
=E2=80=94 
Devin
<= /html>= --Apple-Mail=_D33AF0BD-A25C-40EC-A4F1-2EC18FDE640D-- From nobody Sat May 28 23:34:11 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C71D51B40787 for ; Sat, 28 May 2022 23:34:20 +0000 (UTC) (envelope-from btv1==14710170ea3==tom@invisible-island.net) Received: from smtp-1a.his.com (smtp-1a.his.com [216.194.196.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L9dL34NRVz3Q4g for ; Sat, 28 May 2022 23:34:19 +0000 (UTC) (envelope-from btv1==14710170ea3==tom@invisible-island.net) Received: from cuda201.his.com (cuda201.his.com [216.194.196.22]) by smtp-1a.his.com (Postfix) with ESMTPS id 9B5861AA for ; Sat, 28 May 2022 19:34:13 -0400 (EDT) X-ASG-Debug-ID: 1653780852-061c4116e066b20001-RYubVt Received: from smtp-nf-202.his.com (smtp-nf-202.his.com [216.194.196.20]) by cuda201.his.com with ESMTP id Jf8aS4BQi8HtA3en; Sat, 28 May 2022 19:34:12 -0400 (EDT) X-Barracuda-Envelope-From: tom@invisible-island.net X-Barracuda-RBL-Trusted-Forwarder: 216.194.196.20 Received: from zproxy101.his.com (zproxy101.his.com [18.218.2.49]) by smtp-nf-202.his.com (Postfix) with ESMTPS id 5A0D56009A; Sat, 28 May 2022 19:34:12 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zproxy101.his.com (Postfix) with ESMTP id 2A3E417AB72; Sat, 28 May 2022 19:34:12 -0400 (EDT) X-Barracuda-RBL-IP: 18.218.2.49 X-Barracuda-Effective-Source-IP: zproxy101.his.com[18.218.2.49] X-Barracuda-Apparent-Source-IP: 18.218.2.49 Received: from zproxy101.his.com ([127.0.0.1]) by localhost (zproxy101.his.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dPGlem6L2bdE; Sat, 28 May 2022 19:34:12 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zproxy101.his.com (Postfix) with ESMTP id 117FF17B170; Sat, 28 May 2022 19:34:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at zproxy101.his.com Received: from zproxy101.his.com ([127.0.0.1]) by localhost (zproxy101.his.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k0suGLjFkeGj; Sat, 28 May 2022 19:34:11 -0400 (EDT) Received: from prl-debianold-64.jexium-island.net (static-71-246-219-82.washdc.fios.verizon.net [71.246.219.82]) by zproxy101.his.com (Postfix) with ESMTPSA id EFC3F17AB72; Sat, 28 May 2022 19:34:11 -0400 (EDT) Received: from tom by prl-debianold-64.jexium-island.net with local (Exim 4.92) (envelope-from ) id 1nv5wh-0005bx-75; Sat, 28 May 2022 19:34:11 -0400 Date: Sat, 28 May 2022 19:34:11 -0400 From: Thomas Dickey To: Devin Teske Cc: "Alfonso S. Siciliano" , freebsd-arch@freebsd.org Subject: Re: bsdinstall TUI utility Message-ID: <20220528233411.GA21521@prl-debianold-64.jexium-island.net> X-ASG-Orig-Subj: Re: bsdinstall TUI utility Reply-To: dickey@his.com References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Barracuda-Connect: smtp-nf-202.his.com[216.194.196.20] X-Barracuda-Start-Time: 1653780852 X-Barracuda-URL: https://spam.his.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at his.com X-Barracuda-Scan-Msg-Size: 4772 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.98329 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Rspamd-Queue-Id: 4L9dL34NRVz3Q4g X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of "btv1==14710170ea3==tom@invisible-island.net" designates 216.194.196.25 as permitted sender) smtp.mailfrom="btv1==14710170ea3==tom@invisible-island.net" X-Spamd-Result: default: False [-1.75 / 15.00]; HAS_REPLYTO(0.00)[dickey@his.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.194.196.0/22]; REPLYTO_ADDR_EQ_FROM(0.00)[]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[dickey@his.com,btv1==14710170ea3==tom@invisible-island.net]; RCVD_IN_DNSWL_LOW(-0.30)[216.194.196.22:received,216.194.196.20:received,216.194.196.25:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:11604, ipnet:216.194.196.0/24, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[dickey@his.com,btv1==14710170ea3==tom@invisible-island.net]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.59)[-0.594]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.26)[0.263]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[his.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.98)[0.982]; RCVD_IN_DNSWL_NONE(0.00)[18.218.2.49:received]; MLMMJ_DEST(0.00)[freebsd-arch]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_COUNT_SEVEN(0.00)[10] X-ThisMailContainsUnwantedMimeParts: N --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 28, 2022 at 04:02:51PM -0700, Devin Teske wrote: >=20 >=20 > > On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano w= rote: > >=20 > > Hello, > >=20 > >=20 > > So far I replaced and adapted `dialog` with `bsddialog` in > > bsdinstall/scripts. > > > >=20 > >=20 > > Currently, I am addressing the last 4 scripts: auto, bootconfig, keymap, > > and wlanconfig. These scripts use also the $DIALOG variable and some > > "if" to handle Xdialog(1). > > For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. > >=20 >=20 > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean bsddialog? fwiw, dialog is LGPL. It is not a GNU project. Given the history of this feature, adding USE_BSDDIALOG would be less disruptive. =20 > > * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. >=20 > bsdinstall(8) uses only dialog(1) in the context of $DIALOG by the way, the manpage doesn't list dialog in its "SEE ALSO". (the existing oblique mention is a start) > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) >=20 >=20 > > * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, > > Xdialog(1) is not used in this context (that is `bsdconfig -X`). > >=20 >=20 > Correct, bsdconfig does use bsdinstall >=20 >=20 > > Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to > > provide only the support for bsddialog(1) in bsdinstall(8)? > >=20 >=20 > I object. :-) =20 > I and another developer are adding support for zenity >=20 > https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconf= ig >=20 > There is also work to resolve the namespace issues in bsdinstall >=20 > https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsd= config >=20 > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it exi= sts > until those efforts can be completed. >=20 > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog iirc, Xdialog is defunct, except perhaps in ports. =20 > > I would prefer this solution because I can avoid: to handle some > > dialog/Xdialog/bsddialog command line difference and to hook some > > bsdconfig function built on dialog(1) incompatible with bsddialog(1) > > (for example autosizing, implemented in bsddialog(3) already). > >=20 >=20 > The differences in command line should be handled through conditionals, b= ut can be the default and opt to handle LGPL-dialog through a USE_GNU_DIALO= G flag >=20 > bsddialog may support auto-sizing, but so does dialog and Xdialog. >=20 > However, ... >=20 > The sizing code in bsdconfig (used indirectly by bsdinstall) was written > because the auto-sizing that does exist and is available in both dialog a= nd > Xdialog (as well as Zenity) does not provide a cohesive experience when > trying to write a program that is in-reality a series of bespoke dialogs. Zenity's a graphical client, and isn't subject to the same limitations that TUI clients encounter. =20 > The sizing code makes sure that regardless of which utility you are using > that the experience is uniform in what is presented to the user. >=20 > Attempting to rely solely on the auto-sizing available from these separate > utilities (including bsddialog) would change the UI/UX. >=20 > The problem was solved by: >=20 > 1. Making the stored text used for dialogs dictate how it will look > 2. Painstakingly determining where each utility failed given the text > 3. Determining how to make the utility display the text properly >=20 > For example, stored text will contain newlines instead of attempting to r= ely > on line wrapping on a box of given size. >=20 > I would have to evaluate bsddialog=E2=80=99s auto-sizing to determine if = it is > trust-worthy given not only all the stored texts, but all the translation= s as > well (as bsdconfig is i18n compatible). It is actually less work to just > allow bsdconfig to likely treat bsddialog as it is dialog and let it perf= orm ^if > the size calculations for you. >=20 > If bsddialog is top be a drop-in replacement, I=E2=80=99m more than a lit= tle > surprised that it cannot accept the sizes calculated for dialog being pas= sed > to it. >=20 >=20 > >=20 > > Please note these considerations are only for bsdinstall, bsdconfig is > > unchanged. > >=20 >=20 > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-turn re= lies > on dlg_gauge_reallocate(3) from LGPL-dialog? > =E2=80=94=20 > Devin --=20 Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGYgtkt2kxADCLA1WzCr0RyFnvgMFAmKSsW8ACgkQzCr0RyFn vgOlQQwAxV2i0q+riGisgYiKwDfNUGwT0tGfnVuc0BerQfcItPhRPc9ODRZeTMUO KTUtcfIzKcOSql/s1HHieNl9oj/zPqDnPme97bc3Zdt0uXmnvOqf7qIJeH/4ZhHV vXt95aJn+ZG5JHRUXzAJRc0EAuhLTsMEKZEuWiYki0Wi+eZ7geO1HTro8de6LXKZ A/xRoD70J8l9NCIPayFCpriI+6bRd/jdhaUDCHdWiKhXkItMMMCRruTrQ+G7oGIF 3SkP66eHiBoa17LdQCwd9lOS2hDFfw1diGzckk5Y0HZyffeWQDLayVLp0f6XupHZ XU60wto3L/7DVBoBlpp5gN+nQeyJNT/rpvnT4bLmet87/87MsilDt4mFDqAoGtZk S9u/PPejKD0q6OZpvxBBu7oxNiWG3SjHZ4IByy+CU4rTUB2/3VI975sl6+vZAL9q koohOSIVv4hbHT59sa4FiioLPIZhUQBIh2SVJSuMkG4UiCQ3r8tpdYOJrpCZCmPQ d4axjTtG =Fv+C -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From nobody Sun May 29 16:01:46 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 306E61B5F08E for ; Sun, 29 May 2022 16:01:48 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LB3FR3YqTz3vpN for ; Sun, 29 May 2022 16:01:47 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-ed1-x52c.google.com with SMTP id er5so10735569edb.12 for ; Sun, 29 May 2022 09:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=z3ehbIrI9gxpSXIIuUj87IK+ZeqECOJKbUN8jbOeRR0=; b=HadPG0K67L+2chUv8nRhJnpsHTNzDFcvqa8qe7NSCw1tR+kpyZx2qdx6CTQF/3hlaS zdPo6fMFG0zZp1/kK3NthGvmSm0CUnDX1jOtN/fj47BeIdDnz+fhVuokpvzG82CXNTHu GAb+7eJKRvKmbryv4ZhlP4XHKuU4r56jNLGcLEaafM37ZKJGZGUHFWBNpB6cKY0+fEPB rqjeqjISErUVU7nuhZMYOGDbPbw/oSSVn9DkTHxhW3CxjOqCQjKHeJiV6okflzVEDF91 C+XkclOnzOj9W9XsHsQrT+RvjiH00MB7CWWf5K2mSUmzIwwl5FrdL5/uGNQeDosRtanJ orGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=z3ehbIrI9gxpSXIIuUj87IK+ZeqECOJKbUN8jbOeRR0=; b=E2VuiLgj/EmDREtxcHrcp2s5qEo1IqICgaKBIRNpbpeAZNgW2YrZvWfdi6K6ukJks3 eYL4BH6p36vZvIH+zPxaIdsfCt5zUfgxqhr0ElYUheb5vW3pC0UAqETFXBVf6XpoGReD cP93NHLVTfvi8ip50B3Xm9bFFgZ8eyVWCIeo7eul11iPDMf+N7OaX5mPkW/x/95C/NTG I3YbgKwlPJ1dgMn2VsjUzrDzESFfgBS/+8dyMaIABGlscRAAcMeJFYuyl3ezWNaIGBc4 78KaPfEISI3x3Y+s/aon9RObmSG/jGCiUL6vA0m+bwjCqXNyQ2Riwk1R57o95Q0dhl9I Z/dA== X-Gm-Message-State: AOAM531GyO3gZ/WBozl5lkKDBZOCcqQ3mclAz4Bu84jHE8aj2/0Sl577 TCRcRF7DrPpGjTfBmJFvmg2pGr0If00= X-Google-Smtp-Source: ABdhPJzUvFewSGbnGwGm1V79+Q/ciYcxPR3Fq3cvOIfFaycTKNJh7Z1IxcAAuHLPppaPp132HUP2qg== X-Received: by 2002:a05:6402:1b1e:b0:42b:cf35:2621 with SMTP id by30-20020a0564021b1e00b0042bcf352621mr21503658edb.352.1653840100365; Sun, 29 May 2022 09:01:40 -0700 (PDT) Received: from [192.168.1.26] ([87.13.145.113]) by smtp.gmail.com with ESMTPSA id w25-20020a50f119000000b0042b0fcfe966sm5069568edl.37.2022.05.29.09.01.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 May 2022 09:01:39 -0700 (PDT) Message-ID: <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> Date: Sun, 29 May 2022 18:01:46 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: bsdinstall TUI utility Content-Language: en-US To: freebsd-arch@freebsd.org References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> From: "Alfonso S. Siciliano" In-Reply-To: <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4LB3FR3YqTz3vpN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=HadPG0K6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alfix86@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=alfix86@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.00)[-0.002]; RECEIVED_SPAMHAUS_PBL(0.00)[87.13.145.113:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; MLMMJ_DEST(0.00)[freebsd-arch]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Obviously, I made some mistake writing in English. Currently, I am working to replace dialog(1) and dialog(3) in BASE with a BSD licensed alternative . I have almost completed the task . luckily somebody helped me, I will thank at the end. The topic of the email is not bsdconfig. It has already a review, it preserves the $DIALOG variable to handle a multitude of front-end: bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on. I would continue the discussion for bsdconfig in phabricator; although I should update it after some recent commit. . The topic of this email is bsdinstall. I have to update the last few scripts to delete LGPL-dialog from BASE. Properly I asked the right way to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts because the others used only and called directly `dialog` without any bsdconfig's help. On 5/29/22 01:02, Devin Teske wrote: > > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano wrote: >> >> Hello, >> >> >> So far I replaced and adapted `dialog` with `bsddialog` in >> bsdinstall/scripts. >> >> >> >> Currently, I am addressing the last 4 scripts: auto, bootconfig, keymap, >> and wlanconfig. These scripts use also the $DIALOG variable and some >> "if" to handle Xdialog(1). >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. >> > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean bsddialog? > OK. > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG Exactly 1. > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) > > >> * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, >> Xdialog(1) is not used in this context (that is `bsdconfig -X`). >> > > Correct, bsdconfig does use bsdinstall > Exactly 2. > >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to >> provide only the support for bsddialog(1) in bsdinstall(8)? >> > > I object. > > I and another developer are adding support for zenity > > https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig > > There is also work to resolve the namespace issues in bsdinstall > > https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdconfig > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it exists until those efforts can be completed. > > ASIDE: bsdinstall doesn’t use Xdialog Exactly 3. Anyway, probably the misunderstanding is at this point. My question is not for bsdconfig but for 4 scripts in bsdinstall. Let' s say: "should bsdinstall/scripts/auto have the code to handle $DIALOG/LGPL-dialog/Xdialog" ``` if [ "$USE_XDIALOG" ]; then yes=ok no=cancel defaultno=default-no extra_args="--wrap --left" format="$passed_msg" else yes=yes no=no defaultno=defaultno extra_args="--cr-wrap" format="$passed_msg" fi ... EXTRA_DISTS=$( eval dialog \ --backtitle \"$OSNAME Installer\" \ ``` Please note, I have not a strong opinion, if you confirm your needs for $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstall I'll add and preserve these features in the 4 scripts. Please let me know, so I can complete the dialog/bsddialog replacement soon. > > >> I would prefer this solution because I can avoid: to handle some >> dialog/Xdialog/bsddialog command line difference and to hook some >> bsdconfig function built on dialog(1) incompatible with bsddialog(1) >> (for example autosizing, implemented in bsddialog(3) already). >> > > The differences in command line should be handled through conditionals, but can be the default and opt to handle LGPL-dialog through a USE_GNU_DIALOG flag > > bsddialog may support auto-sizing, but so does dialog and Xdialog. > > However, ... > > The sizing code in bsdconfig (used indirectly by bsdinstall) was written because the auto-sizing that does exist and is available in both dialog and Xdialog (as well as Zenity) does not provide a cohesive experience when trying to write a program that is in-reality a series of bespoke dialogs. > > The sizing code makes sure that regardless of which utility you are using that the experience is uniform in what is presented to the user. > > Attempting to rely solely on the auto-sizing available from these separate utilities (including bsddialog) would change the UI/UX. > > The problem was solved by: > > 1. Making the stored text used for dialogs dictate how it will look > 2. Painstakingly determining where each utility failed given the text > 3. Determining how to make the utility display the text properly > > For example, stored text will contain newlines instead of attempting to rely on line wrapping on a box of given size. > > I would have to evaluate bsddialog’s auto-sizing to determine if it is trust-worthy given not only all the stored texts, but all the translations as well (as bsdconfig is i18n compatible). It is actually less work to just allow bsdconfig to likely treat bsddialog as it is dialog and let it perform the size calculations for you. > > If bsddialog is top be a drop-in replacement, I’m more than a little surprised that it cannot accept the sizes calculated for dialog being passed to it. > > >> >> Please note these considerations are only for bsdinstall, bsdconfig is >> unchanged. >> > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-turn relies on dlg_gauge_reallocate(3) from LGPL-dialog? I seem these considerations are for bsdconfig so the discussion can continue in phabricator. Of course I made some error in English in the first email. Here the topic is bsdinstall. bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months, all the components (written in C) were adapted or rewritten to use bsddialog(3). Example https://cgit.freebsd.org/src/commit/?id=50e244964e9b06528b84720e09da7bdf8cec6d32 Most bsdinstall scripts "call" just `dialog` using its autosizing (without any bsdconfig's help). So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example https://cgit.freebsd.org/src/commit/?id=4d1ba6febfa7c7808027fd1ef60b3bffadd17853 The important question was asked above. I would want to understand the right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall scripts. I had some problem using the autosizing functions of bsdconfig for bsddialog, probably bacause dialog(3) and bsddialog(3) implement different auto text wrapping algorithms, or the utilities have different command lines. Honestly I am not interested in investigating, I would like to improve bsddialog instead of wasting time on a LGPL software almost ready to leave the BASE. For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" in bsddialog(3) with colors, a callback and bottom info" depending only on BSD licensed code. The complete unicode support is a TODO, although bsddialog provides some feature already https://bugs.freebsd.org/248968 This is probably another misunderstanding. My goal, after some email and chat with others, is to provide a BSD licensed alternative to dialog for the "BASE needs"; similar not equal, otherwise the effort would not be feasible for a single. Indeed, also the command lines are quite different. Example https://cgit.freebsd.org/src/commit/?id=6833ac673d98275ef72a8873372714011c73eb15 So far the replacement process was in phabricator with author(s), maintainer(s) and 2/3 members of the core team. Anyone interested can notify me to be added in future reviews. Alfonso From nobody Sun May 29 17:51:52 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0A0B91B545F5 for ; Sun, 29 May 2022 17:51:53 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LB5hS6k8vz4cf2; Sun, 29 May 2022 17:51:52 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653846712; 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=AUQxJ3CLSI2KNUHiIhiWmGmX/mW7R/OoDXzGoD/wWAA=; b=IrOjosi+n7+7gpSS2AXXflze2XM9F0blNMFhXlCMjxP/yFYcEh1sWdBHAieetqMAcVvgAF wa0fU3x6k6pygk701gHOromw5I/1jYysLAZ0UHmWD8Y5BkwZy8KWYoS9yJrX7E2MNZCNEE HjkHCcIm6WxB8UdUp9+fQb5LMcYdtfD4l6vmNTYO6yT4jA11G/sqcg26ch13XQbbzSDCov 2/ZO99eTojTGwP7zlG/BDf6UExoboNq6eg4hfn4zdoWcMWKhcl2vxbjyjqiYUHR4nIfqbv f+PIHbgx+90TJr0fMvd7hyGwygyhIdNNQ5suahcx/rv+HQUcNVwvjkiDuhFUCw== Received: by freefall.freebsd.org (Postfix, from userid 1403) id CA6358018; Sun, 29 May 2022 17:51:52 +0000 (UTC) Date: Sun, 29 May 2022 17:51:52 +0000 From: "Piotr P. Stefaniak" To: Devin Teske Cc: freebsd-arch@freebsd.org Subject: zenity Message-ID: References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653846712; 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=AUQxJ3CLSI2KNUHiIhiWmGmX/mW7R/OoDXzGoD/wWAA=; b=e9u0xccGCIyqhZSB45VXxWiGpOLPic98oaAmK+dCFNk2GDwqp2AELTN5QzGeK4MtJWCqHv b38kj1uMdn2EGu+5NGag+arC821kKTUrYRpOQD2gxikJbNIdqLQAyRLgj7moph90PEOLvb LJiTFMwt8rsvz9xS5Z08RorvbBtYm+6f86HXhqs9PZk40pthiObBKgeLjtWZK8Vr2LO6D+ P68wbcKMof7xMxys5AOaHTVzXGlt7r+ayyNxRhfIJwyEtBduvP/hRF0lfXGUp5TKYxjWGF OnqQuLaiMjre1hMam4k9Lp5RG1TXUI2KVcDfaVkijewO7zjdaiZTEQMwFVD5Zg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653846712; a=rsa-sha256; cv=none; b=mIogBknUL/r/hcaivy94Ps6Dlalqx3yoEPR54zDdzGoFu69H4KSy19MO+MLz9kwCETYOxq AKqmz0HZiFOZ7ZUdIOa1QuobygFT5LOmoRv3AYeMDzq1YkNzLYyE73VSuL1p/Xx+hkJPS1 vg7/oxWQqI0GlbpSw4GA310Cm632W6z0H7Gggcd8Ay27kM5guLTin1lHgat63F3R947YMD VTN1rer2ixiRFC8A9egb8luYu1FC80y2x2d4/5CnbhdcNFwCxrcn2nXtKL8H/D5gZMzNLr Z2WWjD0mp+te3HlRf3kb8TOEcUNHpIC4aeWrOhzFVqV8y2D3IIPJflhg1JMA3Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2022-05-28 16:02:51, Devin Teske wrote: > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano wrote: >> >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to >> provide only the support for bsddialog(1) in bsdinstall(8)? >> > >I object. > >I and another developer are adding support for zenity > >https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig > >There is also work to resolve the namespace issues in bsdinstall > >https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdconfig > >I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it exists until those efforts can be completed. Does your plan mean that instead of eradicating *GPL-licensed software from base, we will be adding more of it? Piotr From nobody Mon May 30 09:58:15 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 124621B5C453 for ; Mon, 30 May 2022 09:58:17 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBW7Y026Bz4htP; Mon, 30 May 2022 09:58:17 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653904697; 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=sVA0mS1R1lS61SCLbH2S6Z7nudZk7UiKH8NeH7lmy8g=; b=ljuQctJ8avTlW4neVQrTBsqv1HzkKWnuHaG0cuMrc4UzhAzXkT08V5NsbCU400yie1RPHm tekbvJsuBp3GgqF6PmC1Yhi5V50tIww4MipPe2qIUjSYH+1J1H3aPJXgqYcUsVOcAlfoZ5 FAkYYY9GsfeLCHIQhgaMdascEaFua2UOSe3c+rsRbJyJSKyMpw5tduqbN7pHl7MiJUGTFF /NQZvsprDNqxxx+ebkZNcJkaoIeGRpX2kGUP0q0tVISs++dgBKRgGsewAGaqjbiwm5RVVg 7XZq+6EGvQJXRg4nk3LZQHkIhROIDIvzTU6K04d8uC8mOoEBwuWIL95MzuVz6A== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id BCB1BC14E; Mon, 30 May 2022 09:58:16 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 2E6B013EE42; Mon, 30 May 2022 11:58:15 +0200 (CEST) Date: Mon, 30 May 2022 11:58:15 +0200 From: Baptiste Daroussin To: Devin Teske Cc: "Alfonso S. Siciliano" , freebsd-arch@freebsd.org Subject: Re: bsdinstall TUI utility Message-ID: <20220530095815.lznjl6m72yttwadg@aniel.nours.eu> References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653904697; 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=sVA0mS1R1lS61SCLbH2S6Z7nudZk7UiKH8NeH7lmy8g=; b=AvyShqRdWtTXkslqy97FPhPrme3k9xrUBhJHI5FSglSawIagU4lY4Y822hnHQiBXqoZxiV IXiGNmorAqZmioktplWzuH2SJHWOITdP0UjoGtYS8ShpvPeG34vDf71zUYwEN1QT6RqnYs gWqxy86llFmZEQnwUYerlVwRIiKlmgc6XWYNh6Hnhnl8iLl2MCAjcndNXk/+TNkqtD+zWd 8f3V5a5bKiLmbFWAS7guLKcnwGMf8mdhTPs3ENJkd8sk2X62G/20eS7bn2fxMg3eRLqw0Q Mbf99HQWRftLAIsQ/DBvEYhVA++OIOPIF/3j+t6fcdaKz/wQe6AEL4LXiCir7w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653904697; a=rsa-sha256; cv=none; b=UfMHw2u1o86/BtBpaGYzuo5p4o5SY3MJIq6jV0pIfrmRvLw0+trBjMrCqAYnEWaGHTdbmJ ObcnF8xI2e9AKvDNG+FK+9idKl5sn3CptAlnjJ9F72YpdbKRa5EA5gi+F/zApgYw0D3rYy KEULluxRR10y9/FfnPH1sOrJ7m0RKqHHJG1FN2XoiGgvWRFmgw8qa6+yTBf48q6YbtRIrI C04+HKPj9Wz4MpwepKf+keeqRSdj255I1MP47sEzZSowDKHOHpK6L/9SHyfZyjFlyO+6Og XsX9bvyp7KGxA8S9JxzXPSzJUwAbOvB3T53/ZNeYsSQ8U4RSkhGjxLNygZFRTw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sat, May 28, 2022 at 04:02:51PM -0700, Devin Teske wrote: > > > > On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano wrote: > > > > Hello, > > > > > > So far I replaced and adapted `dialog` with `bsddialog` in > > bsdinstall/scripts. > > > > > > > > Currently, I am addressing the last 4 scripts: auto, bootconfig, keymap, > > and wlanconfig. These scripts use also the $DIALOG variable and some > > "if" to handle Xdialog(1). > > For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. > > > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean bsddialog? > > > > * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) > > > > * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, > > Xdialog(1) is not used in this context (that is `bsdconfig -X`). > > > > Correct, bsdconfig does use bsdinstall > > > > Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to > > provide only the support for bsddialog(1) in bsdinstall(8)? > > > > I object. > > I and another developer are adding support for zenity > > https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig > > There is also work to resolve the namespace issues in bsdinstall > > https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdconfig > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it exists until those efforts can be completed. > > ASIDE: bsdinstall doesn’t use Xdialog I don't think we should block the replacement of dialog with bsddialog in base, based on project which have not been touched at all for more than 2 years. (I am not blaming anyone involved in those project, time flies quickly :( ). In particular considering that X-dialog is a long dead project, which will probably get removed from the ports tree soonish, and that dialog(1) and dialog(3) are planned to get removed from base. Don't get me wrong, I do think that there is a value in support multiple dialog like application, but either we have the ongoing project back into active mode and work with Alfonso to ease the integration of bsddialog, or we complete the switch of bsddialog at the price of breaking other dialog utilities support and later on, it will be possible to resume the zenity project (or any other) on top of it. So to summerize, are the people working on the bsdconfig having time to help and/or able to propose a concrete plan on how to integrate easily bsdialog to help Alfonso moving forward? if yes then that is the best situation for all, if no, I think we should pursue with Alfonso's proposal Best regards, Bapt From nobody Mon May 30 15:58:41 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D1AE81B5605A for ; Mon, 30 May 2022 15:58:48 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from shxd.cx (shxd.cx [64.201.244.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBg7X0q9Hz4ctv; Mon, 30 May 2022 15:58:48 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from lummox.shxd.cx ([10.0.0.254]:53415 helo=smtpclient.apple) by shxd.cx with esmtpsa (TLS1.2) tls TLS_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nvhmr-0008YQ-Lz; Mon, 30 May 2022 08:58:33 -0700 Content-Type: text/plain; charset=utf-8 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: bsdinstall TUI utility From: Devin Teske In-Reply-To: <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> Date: Mon, 30 May 2022 08:58:41 -0700 Cc: freebsd-arch@freebsd.org, dteske@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> To: "Alfonso S. Siciliano" X-Mailer: Apple Mail (2.3696.100.31) X-Rspamd-Queue-Id: 4LBg7X0q9Hz4ctv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dtf@shxd.cx has no SPF policy when checking 64.201.244.140) smtp.mailfrom=dtf@shxd.cx X-Spamd-Result: default: False [-1.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.99)[-0.990]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[dteske@freebsd.org,dtf@shxd.cx]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36734, ipnet:64.201.240.0/20, country:US]; FROM_NEQ_ENVFROM(0.00)[dteske@freebsd.org,dtf@shxd.cx]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano = wrote: >=20 > Obviously, I made some mistake writing in English. >=20 No, your English is fine. Perhaps I did not explain myself well. >=20 > Currently, I am working to replace dialog(1) and dialog(3) in BASE = with > a BSD licensed alternative . > I have almost completed the task > . Well understood. I have been observing the work. > luckily somebody helped me, I will thank at the end. >=20 >=20 > The topic of the email is not bsdconfig. Also understood. > It has already a review, Link? > it preserves the $DIALOG variable to handle a multitude of front-end: > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on. Good. > I would continue the discussion for bsdconfig in phabricator; > although I should update it after some recent commit. > . >=20 I have commented that I request time to review. >=20 > The topic of this email is bsdinstall. Correct. > I have to update the last few > scripts to delete LGPL-dialog from BASE. Properly I asked the right = way > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts = because > the others used only and called directly `dialog` without any > bsdconfig's help. >=20 When you look at the bsdinstall code and you see that it calls dialog = without bsdconfig=E2=80=99s help, that is because I have not written the = code yet. When I am done with bsdinstall, it will use bsdconfig=E2=80=99s = API (see =E2=80=9Cbsdconfig api=E2=80=9D) So removing it will only see it added again later. >=20 > On 5/29/22 01:02, Devin Teske wrote: > > > > > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano = wrote: > >> > >> Hello, > >> > >> > >> So far I replaced and adapted `dialog` with `bsddialog` in > >> bsdinstall/scripts. > >> > >> > >> > >> Currently, I am addressing the last 4 scripts: auto, bootconfig, = keymap, > >> and wlanconfig. These scripts use also the $DIALOG variable and = some > >> "if" to handle Xdialog(1). > >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. > >> > > > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean = bsddialog? > > >=20 > OK. >=20 > > > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. > > > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG >=20 >=20 > Exactly 1. >=20 >=20 > > > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) > > > > > >> * I seem bsdconfig(8) does not "call" these 4 scripts, so, = probably, > >> Xdialog(1) is not used in this context (that is `bsdconfig -X`). > >> > > > > Correct, bsdconfig does use bsdinstall > > >=20 >=20 > Exactly 2. >=20 >=20 > > > >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to > >> provide only the support for bsddialog(1) in bsdinstall(8)? > >> > > > > I object. > > > > I and another developer are adding support for zenity > > > > = https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfi= g = > > > > There is also work to resolve the namespace issues in bsdinstall > > > > = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdc= onfig = > > > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where = it exists until those efforts can be completed. > > > > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog >=20 >=20 > Exactly 3. >=20 >=20 > Anyway, probably the misunderstanding is at this point. My question is > not for bsdconfig but for 4 scripts in bsdinstall. No, the confusion is that I have my own roadmap that includes fixing = namespace issues in bsdinstall before then merging bsdinstall with = bsdconfig so that they use a single API. As the code I previously linked to in GitHub demonstrates, I was working = on it in 2020 last, and then the pandemic hit and then I had a child, = and then two root canals, and then some issues due to a data breech, so = it=E2=80=99s been a very busy couple of years, pandemic aside =E2=80=94 = at work we only just returned to the office last week and had been = entirely remote for over 24 months (and to be honest, it is a little = strange to come back into the office and find *everything* exactly as it = was, even to the point that the fridge is freshly stocked with the same = exact foods that were in the fridge the day we closed the office; it=E2=80= =99s Twilight Zone levels of freaky). > Let' s say: "should bsdinstall/scripts/auto have the code to handle > $DIALOG/LGPL-dialog/Xdialog" > ``` > if [ "$USE_XDIALOG" ]; then > yes=3Dok no=3Dcancel defaultno=3Ddefault-no > extra_args=3D"--wrap --left" > format=3D"$passed_msg" > else > yes=3Dyes no=3Dno defaultno=3Ddefaultno > extra_args=3D"--cr-wrap" > format=3D"$passed_msg" > fi >=20 > ... >=20 > EXTRA_DISTS=3D$( eval dialog \ > --backtitle \"$OSNAME Installer\" \ >=20 > ``` >=20 > Please note, I have not a strong opinion, if you confirm your needs = for > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in = bsdinstall > I'll add and preserve these features in the 4 scripts. > Please let me know, so I can complete the dialog/bsddialog replacement > soon. >=20 My answer is YES, the code could continue to handle that for three very = simple reasons: 1. The effort of your roadmap is to *introduce* bsdinstall and = introduction of something new is easier when remnants of the past can be = referenced as we work toward the goal of: 1.a. Reaching parity 1.b. Removing deprecated code 2. Removing old while adding new means if there is ever a discrepancy: 2.a. I have to go to git to see how old code worked 2.b. I have to install old code to run it (opposed to installing old = dialog and setting some environment variables) 3. Making fixes to correct an unintended consequence may introduce = issues: 3.a. When I cannot run the head (as described in 2 above) code with old = dialog 3.b. =E2=80=A6 as I have to run two codeines and merge between the two 3.c. =E2=80=A6 and there will be a time in the future when this should = be expected to break and that should trigger removal, but not before = completing the transitional period on a roadmap to reach parity >=20 > > > > > >> I would prefer this solution because I can avoid: to handle some > >> dialog/Xdialog/bsddialog command line difference and to hook some > >> bsdconfig function built on dialog(1) incompatible with = bsddialog(1) > >> (for example autosizing, implemented in bsddialog(3) already). > >> > > > > The differences in command line should be handled through = conditionals, but can be the default and opt to handle LGPL-dialog = through a USE_GNU_DIALOG flag > > > > bsddialog may support auto-sizing, but so does dialog and Xdialog. > > > > However, ... > > > > The sizing code in bsdconfig (used indirectly by bsdinstall) was = written because the auto-sizing that does exist and is available in both = dialog and Xdialog (as well as Zenity) does not provide a cohesive = experience when trying to write a program that is in-reality a series of = bespoke dialogs. > > > > The sizing code makes sure that regardless of which utility you are = using that the experience is uniform in what is presented to the user. > > > > Attempting to rely solely on the auto-sizing available from these = separate utilities (including bsddialog) would change the UI/UX. > > > > The problem was solved by: > > > > 1. Making the stored text used for dialogs dictate how it will look > > 2. Painstakingly determining where each utility failed given the = text > > 3. Determining how to make the utility display the text properly > > > > For example, stored text will contain newlines instead of attempting = to rely on line wrapping on a box of given size. > > > > I would have to evaluate bsddialog=E2=80=99s auto-sizing to = determine if it is trust-worthy given not only all the stored texts, but = all the translations as well (as bsdconfig is i18n compatible). It is = actually less work to just allow bsdconfig to likely treat bsddialog as = it is dialog and let it perform the size calculations for you. > > > > If bsddialog is top be a drop-in replacement, I=E2=80=99m more than = a little surprised that it cannot accept the sizes calculated for dialog = being passed to it. > > > > > >> > >> Please note these considerations are only for bsdinstall, bsdconfig = is > >> unchanged. > >> > > > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which = in-turn relies on dlg_gauge_reallocate(3) from LGPL-dialog? >=20 >=20 >=20 > I seem these considerations are for bsdconfig so the discussion can > continue in phabricator. Of course I made some error in English in the > first email. No, your English was fine. I perhaps did not explain the we are at = perhaps cross efforts with our distinctly separate roadmaps with their = own goals and timelines. >=20 > Here the topic is bsdinstall. >=20 > bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months, > all the components (written in C) were adapted or rewritten to > use bsddialog(3). Example > = https://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7bdf= 8cec6d32 >=20 I will review and get back with comment. > Most bsdinstall scripts "call" just `dialog` using its autosizing > (without any bsdconfig's help). > So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example > = https://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3bff= add17853 > The important question was asked above. I would want to understand the > right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall > scripts. >=20 Correct. It is part of my roadmap to remove said auto-sizing in = bsdinstall. > I had some problem using the autosizing functions of bsdconfig for > bsddialog, I do not fully understand this. The API examines the text and determines = the proper size to pass. Can bsddialog not accept a size? > probably bacause dialog(3) and bsddialog(3) implement > different auto text wrapping algorithms, or the utilities have = different > command lines. Does bsddialog have support for specifying the size of a widget? > Honestly I am not interested in investigating, That is an unfortunate statement. I am interested in the work being = done, perhaps you could be interested in the work I am doing that I have = been working on for longer than you have been working on bsddialog. > I would > like to improve bsddialog instead of wasting time on a LGPL software > almost ready to leave the BASE. Leaving existing code in place does not waste time on LGPL software = because: 1. Someone like myself will be installing LGPL dialog from ports and = relying on the old code to utilize it: 1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using = environment variables) between LGPL dialog and bsdialog 1.b. so that I can compare the two against each other and fix any = regressions Removing the code to handle LGPL dialog at the same time as removing = LGPL dialog from base kind of makes that hard. As previously explained, = that will force me to perform a series of hacks where I pull down the = old tree with the LGPL handling code and make changes blindly which will = only become more and more difficult as the old code without bsddialog = support and new code (as you propose) without LGPL handling code drift = further and further apart. I don=E2=80=99t understand what is so difficult about separating the = task of =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving = deprecated features=E2=80=9D to accommodate a transitional period is so = difficult =E2=80=94 it makes reaching feature parity (which is in = bsddialog=E2=80=99s interest) very difficult if you try and do both of = those things at the same time. > For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" in > bsddialog(3) with colors, a callback and bottom info" depending only = on > BSD licensed code. Cool! > The complete unicode support is a TODO, although bsddialog provides = some > feature already https://bugs.freebsd.org/248968 >=20 Interesting. Will have a look. > This is probably another misunderstanding. My goal, after some email = and > chat with others, is to provide a BSD licensed alternative to dialog > for the "BASE needs"; similar not equal, otherwise the effort would = not > be feasible for a single. > Indeed, also the command lines are quite different. Example > = https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a887337271401= 1c73eb15 >=20 Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for = transitional period, to come back later and remove old, = obsolete/deprecated code referring to LGPL dialog). > So far the replacement process was in phabricator with author(s), > maintainer(s) and 2/3 members of the core team. Anyone interested can > notify me to be added in future reviews. >=20 I shouldn=E2=80=99t need notification as a principled author/maintainer. Regardless, consider this my notification to be added to add future = reviews. I am available again for review =E2=80=94 though with a child, it may = take some days before I can respond, since I am new to being a parent. =E2=80=94=20 Devin= From nobody Mon May 30 16:18:34 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 71E0B1B5A795 for ; Mon, 30 May 2022 16:18:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBgZh2w3Lz4gL5 for ; Mon, 30 May 2022 16:18:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2e.google.com with SMTP id j11so5126366vka.6 for ; Mon, 30 May 2022 09:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uq7f+R9QbycBozHtTeJsWb8LT4/n4JgU0kCDNGRgH84=; b=i+eJl4XluLg9HvPqpJFANnHS5j+3bEOxL0zLX2xj8oXpFzf6URNeOePCti4oALhEYH 7s4fTlMnl3Zi6IbX0U6NIwvL5Hj8VKXrrpK2lODcSvebtuWRrK5G6XDsR12o7Hu74xbY 0jpmGtK7aL+yEKvZez1GCM9lLzahlHGtKtg+jxO0QM9dszkTwdajGpTZQtV5k74FbLM/ a301VTXZiblHXpOe8haPmg6KG2zWtc+gZwtGNqDnr5xjh6H1bgHoTIzN573waD1XpR/3 +vIGT6WOxpmtqNykgiZLMBkDMxlcZOpVLXd849JjpdkDdm/uyTaM3U+oaSBVb4tMY1vD tIQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uq7f+R9QbycBozHtTeJsWb8LT4/n4JgU0kCDNGRgH84=; b=HoT4RYhAaWfM01IH/HNSrY0qmrIJAfemaLSmK21+icRfyGqZejw3rdoUhDO5JSt38L VGAoM+m3nUUPsO3ppJThJIeT+CLQo9SAF6ZINyMel9a3Aa6lavGkROt0J7GJ+23g1zzF vpcgffWGsB3NXfXHT86D8ULbKK9fNAbP+nSrP9bXomebUCtXnFFvI+/eUz5tHOT2wnm0 zka6Tg54pV+BunP9siueVjMs/GxLbUd0lYTtNm0CDZ3Z0dZHswtKLWKuwTink0rUaqJK MREg5nohLgLRiEfeN12wVDTZmvLoQUcwjnJ+D3KWUsm7g4bB+pmowsKYX08fV4K4XbKe 2V6Q== X-Gm-Message-State: AOAM532Pi4hq/F/nN9Ih+2V2MMN8tInumOOxfLe0xui6OWLSlMbhS5Wc xMzZbOZi2+Is8rX7zmb23uPQZG7XZ5c9eadxLN1Umg== X-Google-Smtp-Source: ABdhPJwnLG1xS2eaX+TNdpSBD6U9NElN9Z3vRoByvxdtfxH+ezAFqvj1futSJXbayPl9g3aD0f7qndYVrhpkIL87k3o= X-Received: by 2002:a05:6122:911:b0:357:a318:272c with SMTP id j17-20020a056122091100b00357a318272cmr15182842vka.36.1653927526102; Mon, 30 May 2022 09:18:46 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> In-Reply-To: From: Warner Losh Date: Mon, 30 May 2022 10:18:34 -0600 Message-ID: Subject: Re: bsdinstall TUI utility To: Devin Teske Cc: "Alfonso S. Siciliano" , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000ad8cb705e03d0203" X-Rspamd-Queue-Id: 4LBgZh2w3Lz4gL5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=i+eJl4Xl; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2e:from]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --000000000000ad8cb705e03d0203 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2022, 9:59 AM Devin Teske wrote: > > > > On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano > wrote: > > > > Obviously, I made some mistake writing in English. > > > > No, your English is fine. Perhaps I did not explain myself well. > > > > > > > Currently, I am working to replace dialog(1) and dialog(3) in BASE with > > a BSD licensed alternative . > > I have almost completed the task > > . > > Well understood. > > I have been observing the work. > > > > luckily somebody helped me, I will thank at the end. > > > > > > The topic of the email is not bsdconfig. > > Also understood. > > > > > > It has already a review, > > Link? > > > > > it preserves the $DIALOG variable to handle a multitude of front-end: > > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on. > > Good. > > > > > I would continue the discussion for bsdconfig in phabricator; > > although I should update it after some recent commit. > > . > > > > I have commented that I request time to review. > > > > > > > The topic of this email is bsdinstall. > > Correct. > > > > > I have to update the last few > > scripts to delete LGPL-dialog from BASE. Properly I asked the right way > > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts because > > the others used only and called directly `dialog` without any > > bsdconfig's help. > > > > When you look at the bsdinstall code and you see that it calls dialog > without bsdconfig=E2=80=99s help, that is because I have not written the = code yet. > When I am done with bsdinstall, it will use bsdconfig=E2=80=99s API (see = =E2=80=9Cbsdconfig > api=E2=80=9D) > > So removing it will only see it added again later. > > > > > > > On 5/29/22 01:02, Devin Teske wrote: > > > > > > > > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano > wrote: > > >> > > >> Hello, > > >> > > >> > > >> So far I replaced and adapted `dialog` with `bsddialog` in > > >> bsdinstall/scripts. > > >> > > >> > > >> > > >> Currently, I am addressing the last 4 scripts: auto, bootconfig, > keymap, > > >> and wlanconfig. These scripts use also the $DIALOG variable and some > > >> "if" to handle Xdialog(1). > > >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. > > >> > > > > > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean > bsddialog? > > > > > > > OK. > > > > > > > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. > > > > > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG > > > > > > Exactly 1. > > > > > > > > > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) > > > > > > > > >> * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, > > >> Xdialog(1) is not used in this context (that is `bsdconfig -X`). > > >> > > > > > > Correct, bsdconfig does use bsdinstall > > > > > > > > > Exactly 2. > > > > > > > > > >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to > > >> provide only the support for bsddialog(1) in bsdinstall(8)? > > >> > > > > > > I object. > > > > > > I and another developer are adding support for zenity > > > > > > > https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconf= ig > < > https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconf= ig > > > > > > > > There is also work to resolve the namespace issues in bsdinstall > > > > > > > https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsd= config > < > https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsd= config > > > > > > > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it > exists until those efforts can be completed. > > > > > > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog > > > > > > Exactly 3. > > > > > > Anyway, probably the misunderstanding is at this point. My question is > > not for bsdconfig but for 4 scripts in bsdinstall. > > No, the confusion is that I have my own roadmap that includes fixing > namespace issues in bsdinstall before then merging bsdinstall with > bsdconfig so that they use a single API. > Any chance we could unify the efforts? As the code I previously linked to in GitHub demonstrates, I was working on > it in 2020 last, and then the pandemic hit and then I had a child, and th= en > two root canals, and then some issues due to a data breech, so it=E2=80= =99s been a > very busy couple of years, pandemic aside =E2=80=94 at work we only just = returned > to the office last week and had been entirely remote for over 24 months > (and to be honest, it is a little strange to come back into the office an= d > find *everything* exactly as it was, even to the point that the fridge is > freshly stocked with the same exact foods that were in the fridge the day > we closed the office; it=E2=80=99s Twilight Zone levels of freaky). > > > > Let' s say: "should bsdinstall/scripts/auto have the code to handle > > $DIALOG/LGPL-dialog/Xdialog" > > ``` > > if [ "$USE_XDIALOG" ]; then > > yes=3Dok no=3Dcancel defaultno=3Ddefault-no > > extra_args=3D"--wrap --left" > > format=3D"$passed_msg" > > else > > yes=3Dyes no=3Dno defaultno=3Ddefaultno > > extra_args=3D"--cr-wrap" > > format=3D"$passed_msg" > > fi > > > > ... > > > > EXTRA_DISTS=3D$( eval dialog \ > > --backtitle \"$OSNAME Installer\" \ > > > > ``` > > > > Please note, I have not a strong opinion, if you confirm your needs for > > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstall > > I'll add and preserve these features in the 4 scripts. > > Please let me know, so I can complete the dialog/bsddialog replacement > > soon. > > > > My answer is YES, the code could continue to handle that for three very > simple reasons: > > 1. The effort of your roadmap is to *introduce* bsdinstall and > introduction of something new is easier when remnants of the past can be > referenced as we work toward the goal of: > > 1.a. Reaching parity > > 1.b. Removing deprecated code > > 2. Removing old while adding new means if there is ever a discrepancy: > > 2.a. I have to go to git to see how old code worked > > 2.b. I have to install old code to run it (opposed to installing old > dialog and setting some environment variables) > > 3. Making fixes to correct an unintended consequence may introduce issues= : > > 3.a. When I cannot run the head (as described in 2 above) code with old > dialog > > 3.b. =E2=80=A6 as I have to run two codeines and merge between the two > > 3.c. =E2=80=A6 and there will be a time in the future when this should be= expected > to break and that should trigger removal, but not before completing the > transitional period on a roadmap to reach parity > > > > > > > > > > > > > >> I would prefer this solution because I can avoid: to handle some > > >> dialog/Xdialog/bsddialog command line difference and to hook some > > >> bsdconfig function built on dialog(1) incompatible with bsddialog(1) > > >> (for example autosizing, implemented in bsddialog(3) already). > > >> > > > > > > The differences in command line should be handled through > conditionals, but can be the default and opt to handle LGPL-dialog throug= h > a USE_GNU_DIALOG flag > > > > > > bsddialog may support auto-sizing, but so does dialog and Xdialog. > > > > > > However, ... > > > > > > The sizing code in bsdconfig (used indirectly by bsdinstall) was > written because the auto-sizing that does exist and is available in both > dialog and Xdialog (as well as Zenity) does not provide a cohesive > experience when trying to write a program that is in-reality a series of > bespoke dialogs. > > > > > > The sizing code makes sure that regardless of which utility you are > using that the experience is uniform in what is presented to the user. > > > > > > Attempting to rely solely on the auto-sizing available from these > separate utilities (including bsddialog) would change the UI/UX. > > > > > > The problem was solved by: > > > > > > 1. Making the stored text used for dialogs dictate how it will look > > > 2. Painstakingly determining where each utility failed given the text > > > 3. Determining how to make the utility display the text properly > > > > > > For example, stored text will contain newlines instead of attempting > to rely on line wrapping on a box of given size. > > > > > > I would have to evaluate bsddialog=E2=80=99s auto-sizing to determine= if it is > trust-worthy given not only all the stored texts, but all the translation= s > as well (as bsdconfig is i18n compatible). It is actually less work to ju= st > allow bsdconfig to likely treat bsddialog as it is dialog and let it > perform the size calculations for you. > > > > > > If bsddialog is top be a drop-in replacement, I=E2=80=99m more than a= little > surprised that it cannot accept the sizes calculated for dialog being > passed to it. > > > > > > > > >> > > >> Please note these considerations are only for bsdinstall, bsdconfig = is > > >> unchanged. > > >> > > > > > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-turn > relies on dlg_gauge_reallocate(3) from LGPL-dialog? > > > > > > > > I seem these considerations are for bsdconfig so the discussion can > > continue in phabricator. Of course I made some error in English in the > > first email. > > No, your English was fine. I perhaps did not explain the we are at perhap= s > cross efforts with our distinctly separate roadmaps with their own goals > and timelines. > > > > > > > Here the topic is bsdinstall. > > > > bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months, > > all the components (written in C) were adapted or rewritten to > > use bsddialog(3). Example > > > https://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7bd= f8cec6d32 > > > > I will review and get back with comment. > > > > Most bsdinstall scripts "call" just `dialog` using its autosizing > > (without any bsdconfig's help). > > So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example > > > https://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3bf= fadd17853 > > The important question was asked above. I would want to understand the > > right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall > > scripts. > > > > Correct. It is part of my roadmap to remove said auto-sizing in bsdinstal= l. > > > > > I had some problem using the autosizing functions of bsdconfig for > > bsddialog, > > I do not fully understand this. The API examines the text and determines > the proper size to pass. Can bsddialog not accept a size? > > > > > > probably bacause dialog(3) and bsddialog(3) implement > > different auto text wrapping algorithms, or the utilities have differen= t > > command lines. > > Does bsddialog have support for specifying the size of a widget? > > > > > > Honestly I am not interested in investigating, > > That is an unfortunate statement. I am interested in the work being done, > perhaps you could be interested in the work I am doing that I have been > working on for longer than you have been working on bsddialog. > > > > > I would > > like to improve bsddialog instead of wasting time on a LGPL software > > almost ready to leave the BASE. > > Leaving existing code in place does not waste time on LGPL software > because: > > 1. Someone like myself will be installing LGPL dialog from ports and > relying on the old code to utilize it: > > 1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using > environment variables) between LGPL dialog and bsdialog > > 1.b. so that I can compare the two against each other and fix any > regressions > > Removing the code to handle LGPL dialog at the same time as removing LGPL > dialog from base kind of makes that hard. As previously explained, that > will force me to perform a series of hacks where I pull down the old tree > with the LGPL handling code and make changes blindly which will only beco= me > more and more difficult as the old code without bsddialog support and new > code (as you propose) without LGPL handling code drift further and furthe= r > apart. > > I don=E2=80=99t understand what is so difficult about separating the task= of > =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving deprecated feature= s=E2=80=9D to accommodate a > transitional period is so difficult =E2=80=94 it makes reaching feature p= arity > (which is in bsddialog=E2=80=99s interest) very difficult if you try and = do both of > those things at the same time. > > > > > For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" in > > bsddialog(3) with colors, a callback and bottom info" depending only on > > BSD licensed code. > > Cool! > > > > > The complete unicode support is a TODO, although bsddialog provides som= e > > feature already https://bugs.freebsd.org/248968 > > > > Interesting. Will have a look. > > > > This is probably another misunderstanding. My goal, after some email an= d > > chat with others, is to provide a BSD licensed alternative to dialog > > for the "BASE needs"; similar not equal, otherwise the effort would not > > be feasible for a single. > > Indeed, also the command lines are quite different. Example > > > https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a88733727140= 11c73eb15 > > > > Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for > transitional period, to come back later and remove old, obsolete/deprecat= ed > code referring to LGPL dialog). > > > > > So far the replacement process was in phabricator with author(s), > > maintainer(s) and 2/3 members of the core team. Anyone interested can > > notify me to be added in future reviews. > > > > I shouldn=E2=80=99t need notification as a principled author/maintainer. > I've found that having a herald rule in phabricator facilitates this. While you are listed in the MAINTAINERs file, it's use has been falling out of fashion in the years since we've adopted phabricator. Also, you've been kinda AWOL for the last couple of years with activity trailing off in the 2018 or 2019 time frame, so it's an understandable, though now corrected, oversight. 3 or 4 years is a long time in 'project time' to be away from the caretaking of things. Regardless, consider this my notification to be added to add future reviews= . > You'll find you are happier if you add the herald rule yourself. It's a bit hidden, but if you go to reviews.freebsd.org and click on the "More Applications" button on the left you'll be able to scroll down to find Herald. It makes it so people don't have to remember, and you'll see everything relevant to the path of the tree that you register. Obviously people should remember, but this will als= o catch new people that are interested in contributing that haven't seen this thread. > I am available again for review =E2=80=94 though with a child, it may tak= e some > days before I can respond, since I am new to being a parent. > Good luck with your child. They are a joy, but can also take up a lot of time. One of the hardest lessons I learned when I had my child was that sometimes you don't have enough time to influence things as much as you'd have done before the child and that things in the project will continue to happen nonetheless. The shared nature of FreeBSD allows for these transitions, and the passing of code from hand to hand sometimes since there are no 'hard locks' anymore. Warner --000000000000ad8cb705e03d0203 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 30, 2022, 9:59 AM Devin T= eske <dteske@fre= ebsd.org> wrote:


> On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano <alfix86@gmail.com= > wrote:
>
> Obviously, I made some mistake writing in English.
>

No, your English is fine. Perhaps I did not explain myself well.



>
> Currently, I am working to replace dialog(1) and dialog(3) in BASE wit= h
> a BSD licensed alternative <https://wiki.freebs= d.org/GPLinBase>.
> I have almost completed the task
> <https://wiki.freebsd.org/Ro= admapFromDialogToBSDDialog>.

Well understood.

I have been observing the work.


> luckily somebody helped me, I will thank at the end.
>
>
> The topic of the email is not bsdconfig.

Also understood.




> It has already a review,

Link?



> it preserves the $DIALOG variable to handle a multitude of front-end:<= br> > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on.
Good.



> I would continue the discussion for bsdconfig in phabricator;
> although I should update it after some recent commit.
> <https://reviews.freebsd.org/D34755>. >

I have commented that I request time to review.



>
> The topic of this email is bsdinstall.

Correct.



> I have to update the last few
> scripts to delete LGPL-dialog from BASE. Properly I asked the right wa= y
> to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts becaus= e
> the others used only and called directly `dialog` without any
> bsdconfig's help.
>

When you look at the bsdinstall code and you see that it calls dialog witho= ut bsdconfig=E2=80=99s help, that is because I have not written the code ye= t. When I am done with bsdinstall, it will use bsdconfig=E2=80=99s API (see= =E2=80=9Cbsdconfig api=E2=80=9D)

So removing it will only see it added again later.



>
> On 5/29/22 01:02, Devin Teske wrote:
> >
> >
> >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano <alfix86@= gmail.com> wrote:
> >>
> >> Hello,
> >>
> >>
> >> So far I replaced and adapted `dialog` with `bsddialog` in > >> bsdinstall/scripts.
> >> <https://wiki.freeb= sd.org/RoadmapFromDialogToBSDDialog>
> >>
> >>
> >> Currently, I am addressing the last 4 scripts: auto, bootconf= ig, keymap,
> >> and wlanconfig. These scripts use also the $DIALOG variable a= nd some
> >> "if" to handle Xdialog(1).
> >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `d= ialog`.
> >>
> >
> > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean bs= ddialog?
> >
>
> OK.
>
> >
> >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI ut= ility.
> >
> > bsdinstall(8) uses only dialog(1) in the context of $DIALOG
>
>
> Exactly 1.
>
>
> >
> > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1)
> >
> >
> >> * I seem bsdconfig(8) does not "call" these 4 scrip= ts, so, probably,
> >>=C2=A0 =C2=A0Xdialog(1) is not used in this context (that is `= bsdconfig -X`).
> >>
> >
> > Correct, bsdconfig does use bsdinstall
> >
>
>
> Exactly 2.
>
>
> >
> >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog = to
> >> provide only the support for bsddialog(1) in bsdinstall(8)? > >>
> >
> > I object.
> >
> > I and another developer are adding support for zenity
> >
> > http= s://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig= <https://g= ithub.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig><= br> > >
> > There is also work to resolve the namespace issues in bsdinstall<= br> > >
> > = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdco= nfig <https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig>
> >
> > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support wher= e it exists until those efforts can be completed.
> >
> > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog
>
>
> Exactly 3.
>
>
> Anyway, probably the misunderstanding is at this point. My question is=
> not for bsdconfig but for 4 scripts in bsdinstall.

No, the confusion is that I have my own roadmap that includes fixing namesp= ace issues in bsdinstall before then merging bsdinstall with bsdconfig so t= hat they use a single API.
Any chance we could unify the efforts?

As the code I previously linked to in GitHub demonstrates, I was working on= it in 2020 last, and then the pandemic hit and then I had a child, and the= n two root canals, and then some issues due to a data breech, so it=E2=80= =99s been a very busy couple of years, pandemic aside =E2=80=94 at work we = only just returned to the office last week and had been entirely remote for= over 24 months (and to be honest, it is a little strange to come back into= the office and find *everything* exactly as it was, even to the point that= the fridge is freshly stocked with the same exact foods that were in the f= ridge the day we closed the office; it=E2=80=99s Twilight Zone levels of fr= eaky).


> Let' s say: "should bsdinstall/scripts/auto have the code to = handle
> $DIALOG/LGPL-dialog/Xdialog"
> ```
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if [ "$USE_XDIALOG" ]; then
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes=3Dok no=3Dca= ncel defaultno=3Ddefault-no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extra_args=3D&qu= ot;--wrap --left"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"$= passed_msg"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0else
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes=3Dyes no=3Dn= o defaultno=3Ddefaultno
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extra_args=3D&qu= ot;--cr-wrap"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"$= passed_msg"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0fi
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0EXTRA_DISTS=3D$( eval dialog \
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= backtitle \"$OSNAME Installer\" \
>
> ```
>
> Please note, I have not a strong opinion, if you confirm your needs fo= r
> $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstal= l
> I'll add and preserve these features in the 4 scripts.
> Please let me know, so I can complete the dialog/bsddialog replacement=
> soon.
>

My answer is YES, the code could continue to handle that for three very sim= ple reasons:

1. The effort of your roadmap is to *introduce* bsdinstall and introduction= of something new is easier when remnants of the past can be referenced as = we work toward the goal of:

1.a. Reaching parity

1.b. Removing deprecated code

2. Removing old while adding new means if there is ever a discrepancy:

2.a. I have to go to git to see how old code worked

2.b. I have to install old code to run it (opposed to installing old dialog= and=C2=A0 setting some environment variables)

3. Making fixes to correct an unintended consequence may introduce issues:<= br>
3.a. When I cannot run the head (as described in 2 above) code with old dia= log

3.b. =E2=80=A6 as I have to run two codeines and merge between the two

3.c. =E2=80=A6 and there will be a time in the future when this should be e= xpected to break and that should trigger removal, but not before completing= the transitional period on a roadmap to reach parity



>
> >
> >
> >> I would prefer this solution because I can avoid: to handle s= ome
> >> dialog/Xdialog/bsddialog command line difference and to hook = some
> >> bsdconfig function built on dialog(1) incompatible with bsddi= alog(1)
> >> (for example autosizing, implemented in bsddialog(3) already)= .
> >>
> >
> > The differences in command line should be handled through conditi= onals, but can be the default and opt to handle LGPL-dialog through a USE_G= NU_DIALOG flag
> >
> > bsddialog may support auto-sizing, but so does dialog and Xdialog= .
> >
> > However, ...
> >
> > The sizing code in bsdconfig (used indirectly by bsdinstall) was = written because the auto-sizing that does exist and is available in both di= alog and Xdialog (as well as Zenity) does not provide a cohesive experience= when trying to write a program that is in-reality a series of bespoke dial= ogs.
> >
> > The sizing code makes sure that regardless of which utility you a= re using that the experience is uniform in what is presented to the user. > >
> > Attempting to rely solely on the auto-sizing available from these= separate utilities (including bsddialog) would change the UI/UX.
> >
> > The problem was solved by:
> >
> > 1. Making the stored text used for dialogs dictate how it will lo= ok
> > 2. Painstakingly determining where each utility failed given the = text
> > 3. Determining how to make the utility display the text properly<= br> > >
> > For example, stored text will contain newlines instead of attempt= ing to rely on line wrapping on a box of given size.
> >
> > I would have to evaluate bsddialog=E2=80=99s auto-sizing to deter= mine if it is trust-worthy given not only all the stored texts, but all the= translations as well (as bsdconfig is i18n compatible). It is actually les= s work to just allow bsdconfig to likely treat bsddialog as it is dialog an= d let it perform the size calculations for you.
> >
> > If bsddialog is top be a drop-in replacement, I=E2=80=99m more th= an a little surprised that it cannot accept the sizes calculated for dialog= being passed to it.
> >
> >
> >>
> >> Please note these considerations are only for bsdinstall, bsd= config is
> >> unchanged.
> >>
> >
> > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-= turn relies on dlg_gauge_reallocate(3) from LGPL-dialog?
>
>
>
> I seem these considerations are for bsdconfig so the discussion can > continue in phabricator. Of course I made some error in English in the=
> first email.

No, your English was fine. I perhaps did not explain the we are at perhaps = cross efforts with our distinctly separate roadmaps with their own goals an= d timelines.



>
> Here the topic is bsdinstall.
>
> bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months,
> all the components (written in C) were adapted or rewritten to
> use bsddialog(3). Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7bdf8ce= c6d32
>

I will review and get back with comment.


> Most bsdinstall scripts "call" just `dialog` using its autos= izing
> (without any bsdconfig's=C2=A0 help).
> So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3bffadd= 17853
> The important question was asked above. I would want to understand the=
> right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall<= br> > scripts.
>

Correct. It is part of my roadmap to remove said auto-sizing in bsdinstall.=



> I had some problem using the autosizing functions of bsdconfig for
> bsddialog,

I do not fully understand this. The API examines the text and determines th= e proper size to pass. Can bsddialog not accept a size?




> probably bacause dialog(3) and bsddialog(3) implement
> different auto text wrapping algorithms, or the utilities have differe= nt
> command lines.

Does bsddialog have support for specifying the size of a widget?




> Honestly I am not interested in investigating,

That is an unfortunate statement. I am interested in the work being done, p= erhaps you could be interested in the work I am doing that I have been work= ing on for longer than you have been working on bsddialog.



> I would
> like to improve bsddialog instead of wasting time on a LGPL software > almost ready to leave the BASE.

Leaving existing code in place does not waste time on LGPL software because= :

1. Someone like myself will be installing LGPL dialog from ports and relyin= g on the old code to utilize it:

1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using env= ironment variables) between LGPL dialog and bsdialog

1.b. so that I can compare the two against each other and fix any regressio= ns

Removing the code to handle LGPL dialog at the same time as removing LGPL d= ialog from base kind of makes that hard. As previously explained, that will= force me to perform a series of hacks where I pull down the old tree with = the LGPL handling code and make changes blindly which will only become more= and more difficult as the old code without bsddialog support and new code = (as you propose) without LGPL handling code drift further and further apart= .

I don=E2=80=99t understand what is so difficult about separating the task o= f =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving deprecated feature= s=E2=80=9D to accommodate a transitional period is so difficult =E2=80=94 i= t makes reaching feature parity (which is in bsddialog=E2=80=99s interest) = very difficult if you try and do both of those things at the same time.



> For dpv(3) in distfetch.c, I implemented an "improved mixedgauge&= quot; in
> bsddialog(3) with colors, a callback and bottom info" depending o= nly on
> BSD licensed code.

Cool!



> The complete unicode support is a TODO, although bsddialog provides so= me
> feature already https://bugs.freebsd.org/248968 >

Interesting. Will have a look.


> This is probably another misunderstanding. My goal, after some email a= nd
> chat with others, is to provide a BSD licensed alternative to dialog > for the "BASE needs"; similar not equal, otherwise the effor= t would not
> be feasible for a single.
> Indeed, also the command lines are quite different. Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a8873372714011c7= 3eb15
>

Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for tr= ansitional period, to come back later and remove old, obsolete/deprecated c= ode referring to LGPL dialog).



> So far the replacement process was in phabricator with author(s),
> maintainer(s) and 2/3 members of the core team. Anyone interested can<= br> > notify me to be added in future reviews.
>

I shouldn=E2=80=99t need notification as a principled author/maintainer.

I've found t= hat having a herald rule in phabricator facilitates this. While
y= ou are listed in the MAINTAINERs file, it's use has been falling out
of fashion in the years since we've adopted phabricator. Also, = you've
been kinda AWOL for the last couple of years with acti= vity trailing off
in the 2018 or 2019 time frame, so it's an = understandable, though now
corrected, oversight. 3 or 4 years is = a long time in 'project time' to be away
from the caretak= ing of things.

Regardless, consider this my notification to be added to add future reviews= .

You'll find you are happier if yo= u add the herald rule yourself. It's a bit hidden,
but if you= go to reviews.freebsd.org and c= lick on the "More Applications" button
on the left you&= #39;ll be able to scroll down to find Herald. It makes it so people
don't have to remember, and you'll see everything relevant to th= e path of the
tree that you register. Obviously people should rem= ember, but this will also
catch new people that are interested in= contributing that haven't seen this thread.
=C2=A0
I am available again for review =E2=80=94 though with a child, it may take = some days before I can respond, since I am new to being a parent.

Good luck with your child. They are a joy, but c= an also take up a lot of time.
One of the hardest lessons=C2=A0I = learned when I had my child was that sometimes
you don't have= enough time to influence things as much as you'd have done
b= efore the child and that things in the project will continue to happen none= theless.
The shared nature of FreeBSD allows for these transition= s, and the passing of
code from hand to hand sometimes since ther= e are no 'hard locks' anymore.

Warner

--000000000000ad8cb705e03d0203-- From nobody Mon May 30 17:40:01 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 265221B67BDE for ; Mon, 30 May 2022 17:40:04 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from shxd.cx (shxd.cx [64.201.244.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBjNM1jBKz4rWF for ; Mon, 30 May 2022 17:40:03 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from lummox.shxd.cx ([10.0.0.254]:59432 helo=smtpclient.apple) by shxd.cx with esmtpsa (TLS1.2) tls TLS_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nvjMw-000PXM-26; Mon, 30 May 2022 10:39:54 -0700 From: Devin Teske Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D3A6E4F5-AB76-4B4E-AF53-9E9500F6B7F5" List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: bsdinstall TUI utility Date: Mon, 30 May 2022 10:40:01 -0700 In-Reply-To: Cc: "Alfonso S. Siciliano" , "freebsd-arch@freebsd.org" To: Warner Losh References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> X-Mailer: Apple Mail (2.3696.100.31) X-Rspamd-Queue-Id: 4LBjNM1jBKz4rWF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dtf@shxd.cx has no SPF policy when checking 64.201.244.140) smtp.mailfrom=dtf@shxd.cx X-Spamd-Result: default: False [-0.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; URI_COUNT_ODD(1.00)[3]; NEURAL_HAM_SHORT(-0.80)[-0.800]; FORGED_SENDER(0.30)[dteske@freebsd.org,dtf@shxd.cx]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36734, ipnet:64.201.240.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[dteske@freebsd.org,dtf@shxd.cx]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_D3A6E4F5-AB76-4B4E-AF53-9E9500F6B7F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 30, 2022, at 9:18 AM, Warner Losh wrote: >=20 >=20 >=20 > On Mon, May 30, 2022, 9:59 AM Devin Teske > wrote: >=20 >=20 > > On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano > wrote: > >=20 > > Obviously, I made some mistake writing in English. > >=20 >=20 > No, your English is fine. Perhaps I did not explain myself well. >=20 >=20 >=20 > >=20 > > Currently, I am working to replace dialog(1) and dialog(3) in BASE = with > > a BSD licensed alternative >. > > I have almost completed the task > > >. >=20 > Well understood. >=20 > I have been observing the work. >=20 >=20 > > luckily somebody helped me, I will thank at the end. > >=20 > >=20 > > The topic of the email is not bsdconfig. >=20 > Also understood. >=20 >=20 >=20 >=20 > > It has already a review, >=20 > Link? >=20 >=20 >=20 > > it preserves the $DIALOG variable to handle a multitude of = front-end: > > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on. >=20 > Good. >=20 >=20 >=20 > > I would continue the discussion for bsdconfig in phabricator; > > although I should update it after some recent commit. > > >. > >=20 >=20 > I have commented that I request time to review. >=20 >=20 >=20 > >=20 > > The topic of this email is bsdinstall. >=20 > Correct. >=20 >=20 >=20 > > I have to update the last few > > scripts to delete LGPL-dialog from BASE. Properly I asked the right = way > > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts = because > > the others used only and called directly `dialog` without any > > bsdconfig's help. > >=20 >=20 > When you look at the bsdinstall code and you see that it calls dialog = without bsdconfig=E2=80=99s help, that is because I have not written the = code yet. When I am done with bsdinstall, it will use bsdconfig=E2=80=99s = API (see =E2=80=9Cbsdconfig api=E2=80=9D) >=20 > So removing it will only see it added again later. >=20 >=20 >=20 > >=20 > > On 5/29/22 01:02, Devin Teske wrote: > > > > > > > > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano = > wrote: > > >> > > >> Hello, > > >> > > >> > > >> So far I replaced and adapted `dialog` with `bsddialog` in > > >> bsdinstall/scripts. > > >> > > > >> > > >> > > >> Currently, I am addressing the last 4 scripts: auto, bootconfig, = keymap, > > >> and wlanconfig. These scripts use also the $DIALOG variable and = some > > >> "if" to handle Xdialog(1). > > >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. > > >> > > > > > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean = bsddialog? > > > > >=20 > > OK. > >=20 > > > > > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI = utility. > > > > > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG > >=20 > >=20 > > Exactly 1. > >=20 > >=20 > > > > > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) > > > > > > > > >> * I seem bsdconfig(8) does not "call" these 4 scripts, so, = probably, > > >> Xdialog(1) is not used in this context (that is `bsdconfig = -X`). > > >> > > > > > > Correct, bsdconfig does use bsdinstall > > > > >=20 > >=20 > > Exactly 2. > >=20 > >=20 > > > > > >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to > > >> provide only the support for bsddialog(1) in bsdinstall(8)? > > >> > > > > > > I object. > > > > > > I and another developer are adding support for zenity > > > > > > = https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfi= g = = > > > > > > > There is also work to resolve the namespace issues in bsdinstall > > > > > > = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdc= onfig = = > > > > > > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where = it exists until those efforts can be completed. > > > > > > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog > >=20 > >=20 > > Exactly 3. > >=20 > >=20 > > Anyway, probably the misunderstanding is at this point. My question = is > > not for bsdconfig but for 4 scripts in bsdinstall. >=20 > No, the confusion is that I have my own roadmap that includes fixing = namespace issues in bsdinstall before then merging bsdinstall with = bsdconfig so that they use a single API. >=20 > Any chance we could unify the efforts? >=20 > As the code I previously linked to in GitHub demonstrates, I was = working on it in 2020 last, and then the pandemic hit and then I had a = child, and then two root canals, and then some issues due to a data = breech, so it=E2=80=99s been a very busy couple of years, pandemic aside = =E2=80=94 at work we only just returned to the office last week and had = been entirely remote for over 24 months (and to be honest, it is a = little strange to come back into the office and find *everything* = exactly as it was, even to the point that the fridge is freshly stocked = with the same exact foods that were in the fridge the day we closed the = office; it=E2=80=99s Twilight Zone levels of freaky). >=20 >=20 > > Let' s say: "should bsdinstall/scripts/auto have the code to handle > > $DIALOG/LGPL-dialog/Xdialog" > > ``` > > if [ "$USE_XDIALOG" ]; then > > yes=3Dok no=3Dcancel defaultno=3Ddefault-no > > extra_args=3D"--wrap --left" > > format=3D"$passed_msg" > > else > > yes=3Dyes no=3Dno defaultno=3Ddefaultno > > extra_args=3D"--cr-wrap" > > format=3D"$passed_msg" > > fi > >=20 > > ... > >=20 > > EXTRA_DISTS=3D$( eval dialog \ > > --backtitle \"$OSNAME Installer\" \ > >=20 > > ``` > >=20 > > Please note, I have not a strong opinion, if you confirm your needs = for > > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in = bsdinstall > > I'll add and preserve these features in the 4 scripts. > > Please let me know, so I can complete the dialog/bsddialog = replacement > > soon. > >=20 >=20 > My answer is YES, the code could continue to handle that for three = very simple reasons: >=20 > 1. The effort of your roadmap is to *introduce* bsdinstall and = introduction of something new is easier when remnants of the past can be = referenced as we work toward the goal of: >=20 > 1.a. Reaching parity >=20 > 1.b. Removing deprecated code >=20 > 2. Removing old while adding new means if there is ever a discrepancy: >=20 > 2.a. I have to go to git to see how old code worked >=20 > 2.b. I have to install old code to run it (opposed to installing old = dialog and setting some environment variables) >=20 > 3. Making fixes to correct an unintended consequence may introduce = issues: >=20 > 3.a. When I cannot run the head (as described in 2 above) code with = old dialog >=20 > 3.b. =E2=80=A6 as I have to run two codeines and merge between the two >=20 > 3.c. =E2=80=A6 and there will be a time in the future when this should = be expected to break and that should trigger removal, but not before = completing the transitional period on a roadmap to reach parity >=20 >=20 >=20 > >=20 > > > > > > > > >> I would prefer this solution because I can avoid: to handle some > > >> dialog/Xdialog/bsddialog command line difference and to hook some > > >> bsdconfig function built on dialog(1) incompatible with = bsddialog(1) > > >> (for example autosizing, implemented in bsddialog(3) already). > > >> > > > > > > The differences in command line should be handled through = conditionals, but can be the default and opt to handle LGPL-dialog = through a USE_GNU_DIALOG flag > > > > > > bsddialog may support auto-sizing, but so does dialog and Xdialog. > > > > > > However, ... > > > > > > The sizing code in bsdconfig (used indirectly by bsdinstall) was = written because the auto-sizing that does exist and is available in both = dialog and Xdialog (as well as Zenity) does not provide a cohesive = experience when trying to write a program that is in-reality a series of = bespoke dialogs. > > > > > > The sizing code makes sure that regardless of which utility you = are using that the experience is uniform in what is presented to the = user. > > > > > > Attempting to rely solely on the auto-sizing available from these = separate utilities (including bsddialog) would change the UI/UX. > > > > > > The problem was solved by: > > > > > > 1. Making the stored text used for dialogs dictate how it will = look > > > 2. Painstakingly determining where each utility failed given the = text > > > 3. Determining how to make the utility display the text properly > > > > > > For example, stored text will contain newlines instead of = attempting to rely on line wrapping on a box of given size. > > > > > > I would have to evaluate bsddialog=E2=80=99s auto-sizing to = determine if it is trust-worthy given not only all the stored texts, but = all the translations as well (as bsdconfig is i18n compatible). It is = actually less work to just allow bsdconfig to likely treat bsddialog as = it is dialog and let it perform the size calculations for you. > > > > > > If bsddialog is top be a drop-in replacement, I=E2=80=99m more = than a little surprised that it cannot accept the sizes calculated for = dialog being passed to it. > > > > > > > > >> > > >> Please note these considerations are only for bsdinstall, = bsdconfig is > > >> unchanged. > > >> > > > > > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which = in-turn relies on dlg_gauge_reallocate(3) from LGPL-dialog? > >=20 > >=20 > >=20 > > I seem these considerations are for bsdconfig so the discussion can > > continue in phabricator. Of course I made some error in English in = the > > first email. >=20 > No, your English was fine. I perhaps did not explain the we are at = perhaps cross efforts with our distinctly separate roadmaps with their = own goals and timelines. >=20 >=20 >=20 > >=20 > > Here the topic is bsdinstall. > >=20 > > bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months, > > all the components (written in C) were adapted or rewritten to > > use bsddialog(3). Example > > = https://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7bdf= 8cec6d32 = > >=20 >=20 > I will review and get back with comment. >=20 >=20 > > Most bsdinstall scripts "call" just `dialog` using its autosizing > > (without any bsdconfig's help). > > So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example > > = https://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3bff= add17853 = > > The important question was asked above. I would want to understand = the > > right way to handle $DIALOG/Xdialog/`dialog` in the last 4 = bsdinstall > > scripts. > >=20 >=20 > Correct. It is part of my roadmap to remove said auto-sizing in = bsdinstall. >=20 >=20 >=20 > > I had some problem using the autosizing functions of bsdconfig for > > bsddialog, >=20 > I do not fully understand this. The API examines the text and = determines the proper size to pass. Can bsddialog not accept a size? >=20 >=20 >=20 >=20 > > probably bacause dialog(3) and bsddialog(3) implement > > different auto text wrapping algorithms, or the utilities have = different > > command lines. >=20 > Does bsddialog have support for specifying the size of a widget? >=20 >=20 >=20 >=20 > > Honestly I am not interested in investigating, >=20 > That is an unfortunate statement. I am interested in the work being = done, perhaps you could be interested in the work I am doing that I have = been working on for longer than you have been working on bsddialog. >=20 >=20 >=20 > > I would > > like to improve bsddialog instead of wasting time on a LGPL software > > almost ready to leave the BASE. >=20 > Leaving existing code in place does not waste time on LGPL software = because: >=20 > 1. Someone like myself will be installing LGPL dialog from ports and = relying on the old code to utilize it: >=20 > 1.a. expressly so I can flip bsdinstall/bsdconfig back and forth = (using environment variables) between LGPL dialog and bsdialog >=20 > 1.b. so that I can compare the two against each other and fix any = regressions >=20 > Removing the code to handle LGPL dialog at the same time as removing = LGPL dialog from base kind of makes that hard. As previously explained, = that will force me to perform a series of hacks where I pull down the = old tree with the LGPL handling code and make changes blindly which will = only become more and more difficult as the old code without bsddialog = support and new code (as you propose) without LGPL handling code drift = further and further apart. >=20 > I don=E2=80=99t understand what is so difficult about separating the = task of =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving = deprecated features=E2=80=9D to accommodate a transitional period is so = difficult =E2=80=94 it makes reaching feature parity (which is in = bsddialog=E2=80=99s interest) very difficult if you try and do both of = those things at the same time. >=20 >=20 >=20 > > For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" in > > bsddialog(3) with colors, a callback and bottom info" depending only = on > > BSD licensed code. >=20 > Cool! >=20 >=20 >=20 > > The complete unicode support is a TODO, although bsddialog provides = some > > feature already https://bugs.freebsd.org/248968 = > >=20 >=20 > Interesting. Will have a look. >=20 >=20 > > This is probably another misunderstanding. My goal, after some email = and > > chat with others, is to provide a BSD licensed alternative to dialog > > for the "BASE needs"; similar not equal, otherwise the effort would = not > > be feasible for a single. > > Indeed, also the command lines are quite different. Example > > = https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a887337271401= 1c73eb15 = > >=20 >=20 > Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place = for transitional period, to come back later and remove old, = obsolete/deprecated code referring to LGPL dialog). >=20 >=20 >=20 > > So far the replacement process was in phabricator with author(s), > > maintainer(s) and 2/3 members of the core team. Anyone interested = can > > notify me to be added in future reviews. > >=20 >=20 > I shouldn=E2=80=99t need notification as a principled = author/maintainer. >=20 > I've found that having a herald rule in phabricator facilitates this. = While > you are listed in the MAINTAINERs file, it's use has been falling out > of fashion in the years since we've adopted phabricator. Also, you've > been kinda AWOL for the last couple of years with activity trailing = off > in the 2018 or 2019 time frame, so it's an understandable, though now > corrected, oversight. 3 or 4 years is a long time in 'project time' to = be away > from the caretaking of things. I was not AWOL. I was (and am) working on my roadmaps. Bsdconfig is over 30,000 lines of code. It wasn=E2=80=99t written in a = day. I have 5 large projects I am working on: 1. Bsdinstall namespace 2. Bsdconfig zenity 3. libfigput 4. Sysconf 5. cmb I am working on them in GitHub instead of an f.o branch because I have = never been shown how. >=20 > Regardless, consider this my notification to be added to add future = reviews. >=20 > You'll find you are happier if you add the herald rule yourself. It's = a bit hidden, > but if you go to reviews.freebsd.org and = click on the "More Applications" button > on the left you'll be able to scroll down to find Herald. It makes it = so people > don't have to remember, and you'll see everything relevant to the path = of the > tree that you register. Obviously people should remember, but this = will also > catch new people that are interested in contributing that haven't seen = this thread. Thanks. Didn=E2=80=99t know MAINTAINERS was on the way out. Will look = into Herald. > =20 > I am available again for review =E2=80=94 though with a child, it may = take some days before I can respond, since I am new to being a parent. >=20 > Good luck with your child. They are a joy, but can also take up a lot = of time. > One of the hardest lessons I learned when I had my child was that = sometimes > you don't have enough time to influence things as much as you'd have = done > before the child and that things in the project will continue to = happen nonetheless. > The shared nature of FreeBSD allows for these transitions, and the = passing of > code from hand to hand sometimes since there are no 'hard locks' = anymore. >=20 Thanks. I have a non-working spouse, so theoretically only part of what you said = applies. =E2=80=94=20 Devin= --Apple-Mail=_D3A6E4F5-AB76-4B4E-AF53-9E9500F6B7F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 30, 2022, at 9:18 AM, Warner Losh <imp@bsdimp.com> = wrote:



On Mon, May 30, 2022, 9:59 AM Devin Teske <dteske@freebsd.org> wrote:


> On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano <alfix86@gmail.com> wrote:
>
> Obviously, I made some mistake writing in English.
>

No, your English is fine. Perhaps I did not explain myself well.



>
> Currently, I am working to replace dialog(1) and dialog(3) in BASE = with
> a BSD licensed alternative <https://wiki.freebsd.org/GPLinBase>.
> I have almost completed the task
> <https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog>.<= br class=3D"">
Well understood.

I have been observing the work.


> luckily somebody helped me, I will thank at the end.
>
>
> The topic of the email is not bsdconfig.

Also understood.




> It has already a review,

Link?



> it preserves the $DIALOG variable to handle a multitude of = front-end:
> bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so = on.

Good.



> I would continue the discussion for bsdconfig in phabricator;
> although I should update it after some recent commit.
> <https://reviews.freebsd.org/D34755>.
>

I have commented that I request time to review.



>
> The topic of this email is bsdinstall.

Correct.



> I have to update the last few
> scripts to delete LGPL-dialog from BASE. Properly I asked the right = way
> to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts = because
> the others used only and called directly `dialog` without any
> bsdconfig's help.
>

When you look at the bsdinstall code and you see that it calls dialog = without bsdconfig=E2=80=99s help, that is because I have not written the = code yet. When I am done with bsdinstall, it will use bsdconfig=E2=80=99s = API (see =E2=80=9Cbsdconfig api=E2=80=9D)

So removing it will only see it added again later.



>
> On 5/29/22 01:02, Devin Teske wrote:
> >
> >
> >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano <alfix86@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >>
> >> So far I replaced and adapted `dialog` with `bsddialog` = in
> >> bsdinstall/scripts.
> >> <https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog> > >>
> >>
> >> Currently, I am addressing the last 4 scripts: auto, = bootconfig, keymap,
> >> and wlanconfig. These scripts use also the $DIALOG = variable and some
> >> "if" to handle Xdialog(1).
> >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and = `dialog`.
> >>
> >
> > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean = bsddialog?
> >
>
> OK.
>
> >
> >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI = utility.
> >
> > bsdinstall(8) uses only dialog(1) in the context of $DIALOG
>
>
> Exactly 1.
>
>
> >
> > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1)
> >
> >
> >> * I seem bsdconfig(8) does not "call" these 4 scripts, so, = probably,
> >>   Xdialog(1) is not used in this context (that = is `bsdconfig -X`).
> >>
> >
> > Correct, bsdconfig does use bsdinstall
> >
>
>
> Exactly 2.
>
>
> >
> >> Is there any objection to delete = $DIALOG/LGPL-dialog/Xdialog to
> >> provide only the support for bsddialog(1) in = bsdinstall(8)?
> >>
> >
> > I object.
> >
> > I and another developer are adding support for zenity
> >
> > https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depe= nd/bsdconfig <https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depe= nd/bsdconfig>
> >
> > There is also work to resolve the namespace issues in = bsdinstall
> >
> > https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/= depend/bsdconfig <https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/= depend/bsdconfig>
> >
> > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support = where it exists until those efforts can be completed.
> >
> > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog
>
>
> Exactly 3.
>
>
> Anyway, probably the misunderstanding is at this point. My question = is
> not for bsdconfig but for 4 scripts in bsdinstall.

No, the confusion is that I have my own roadmap that includes fixing = namespace issues in bsdinstall before then merging bsdinstall with = bsdconfig so that they use a single API.

Any chance we could unify = the efforts?

As the code I previously linked to in GitHub demonstrates, I was working = on it in 2020 last, and then the pandemic hit and then I had a child, = and then two root canals, and then some issues due to a data breech, so = it=E2=80=99s been a very busy couple of years, pandemic aside =E2=80=94 = at work we only just returned to the office last week and had been = entirely remote for over 24 months (and to be honest, it is a little = strange to come back into the office and find *everything* exactly as it = was, even to the point that the fridge is freshly stocked with the same = exact foods that were in the fridge the day we closed the office; it=E2=80= =99s Twilight Zone levels of freaky).


> Let' s say: "should bsdinstall/scripts/auto have the code to = handle
> $DIALOG/LGPL-dialog/Xdialog"
> ```
>       if [ "$USE_XDIALOG" ]; then
>               yes=3Dok = no=3Dcancel defaultno=3Ddefault-no
>              =  extra_args=3D"--wrap --left"
>              =  format=3D"$passed_msg"
>       else
>               yes=3Dyes = no=3Dno defaultno=3Ddefaultno
>              =  extra_args=3D"--cr-wrap"
>              =  format=3D"$passed_msg"
>       fi
>
>       ...
>
>       EXTRA_DISTS=3D$( eval dialog \
>                  =  --backtitle \"$OSNAME Installer\" \
>
> ```
>
> Please note, I have not a strong opinion, if you confirm your needs = for
> $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in = bsdinstall
> I'll add and preserve these features in the 4 scripts.
= > Please let me know, so I can complete the dialog/bsddialog = replacement
> soon.
>

My answer is YES, the code could continue to handle that for three very = simple reasons:

1. The effort of your roadmap is to *introduce* bsdinstall and = introduction of something new is easier when remnants of the past can be = referenced as we work toward the goal of:

1.a. Reaching parity

1.b. Removing deprecated code

2. Removing old while adding new means if there is ever a = discrepancy:

2.a. I have to go to git to see how old code worked

2.b. I have to install old code to run it (opposed to installing old = dialog and  setting some environment variables)

3. Making fixes to correct an unintended consequence may introduce = issues:

3.a. When I cannot run the head (as described in 2 above) code with old = dialog

3.b. =E2=80=A6 as I have to run two codeines and merge between the = two

3.c. =E2=80=A6 and there will be a time in the future when this should = be expected to break and that should trigger removal, but not before = completing the transitional period on a roadmap to reach parity



>
> >
> >
> >> I would prefer this solution because I can avoid: to = handle some
> >> dialog/Xdialog/bsddialog command line difference and to = hook some
> >> bsdconfig function built on dialog(1) incompatible with = bsddialog(1)
> >> (for example autosizing, implemented in bsddialog(3) = already).
> >>
> >
> > The differences in command line should be handled through = conditionals, but can be the default and opt to handle LGPL-dialog = through a USE_GNU_DIALOG flag
> >
> > bsddialog may support auto-sizing, but so does dialog and = Xdialog.
> >
> > However, ...
> >
> > The sizing code in bsdconfig (used indirectly by bsdinstall) = was written because the auto-sizing that does exist and is available in = both dialog and Xdialog (as well as Zenity) does not provide a cohesive = experience when trying to write a program that is in-reality a series of = bespoke dialogs.
> >
> > The sizing code makes sure that regardless of which utility = you are using that the experience is uniform in what is presented to the = user.
> >
> > Attempting to rely solely on the auto-sizing available from = these separate utilities (including bsddialog) would change the = UI/UX.
> >
> > The problem was solved by:
> >
> > 1. Making the stored text used for dialogs dictate how it will = look
> > 2. Painstakingly determining where each utility failed given = the text
> > 3. Determining how to make the utility display the text = properly
> >
> > For example, stored text will contain newlines instead of = attempting to rely on line wrapping on a box of given size.
= > >
> > I would have to evaluate bsddialog=E2=80=99s auto-sizing to = determine if it is trust-worthy given not only all the stored texts, but = all the translations as well (as bsdconfig is i18n compatible). It is = actually less work to just allow bsdconfig to likely treat bsddialog as = it is dialog and let it perform the size calculations for you.
> >
> > If bsddialog is top be a drop-in replacement, I=E2=80=99m more = than a little surprised that it cannot accept the sizes calculated for = dialog being passed to it.
> >
> >
> >>
> >> Please note these considerations are only for bsdinstall, = bsdconfig is
> >> unchanged.
> >>
> >
> > What of dpv? bsdinstall uses dpv(3) to unpack the dists which = in-turn relies on dlg_gauge_reallocate(3) from LGPL-dialog?
= >
>
>
> I seem these considerations are for bsdconfig so the discussion = can
> continue in phabricator. Of course I made some error in English in = the
> first email.

No, your English was fine. I perhaps did not explain the we are at = perhaps cross efforts with our distinctly separate roadmaps with their = own goals and timelines.



>
> Here the topic is bsdinstall.
>
> bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since = months,
> all the components (written in C) were adapted or rewritten to
> use bsddialog(3). Example
> https://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b847= 20e09da7bdf8cec6d32
>

I will review and get back with comment.


> Most bsdinstall scripts "call" just `dialog` using its = autosizing
> (without any bsdconfig's  help).
> So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example
> https://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027f= d1ef60b3bffadd17853
> The important question was asked above. I would want to understand = the
> right way to handle $DIALOG/Xdialog/`dialog` in the last 4 = bsdinstall
> scripts.
>

Correct. It is part of my roadmap to remove said auto-sizing in = bsdinstall.



> I had some problem using the autosizing functions of bsdconfig = for
> bsddialog,

I do not fully understand this. The API examines the text and determines = the proper size to pass. Can bsddialog not accept a size?




> probably bacause dialog(3) and bsddialog(3) implement
> different auto text wrapping algorithms, or the utilities have = different
> command lines.

Does bsddialog have support for specifying the size of a widget?




> Honestly I am not interested in investigating,

That is an unfortunate statement. I am interested in the work being = done, perhaps you could be interested in the work I am doing that I have = been working on for longer than you have been working on bsddialog.



> I would
> like to improve bsddialog instead of wasting time on a LGPL = software
> almost ready to leave the BASE.

Leaving existing code in place does not waste time on LGPL software = because:

1. Someone like myself will be installing LGPL dialog from ports and = relying on the old code to utilize it:

1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using = environment variables) between LGPL dialog and bsdialog

1.b. so that I can compare the two against each other and fix any = regressions

Removing the code to handle LGPL dialog at the same time as removing = LGPL dialog from base kind of makes that hard. As previously explained, = that will force me to perform a series of hacks where I pull down the = old tree with the LGPL handling code and make changes blindly which will = only become more and more difficult as the old code without bsddialog = support and new code (as you propose) without LGPL handling code drift = further and further apart.

I don=E2=80=99t understand what is so difficult about separating the = task of =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving = deprecated features=E2=80=9D to accommodate a transitional period is so = difficult =E2=80=94 it makes reaching feature parity (which is in = bsddialog=E2=80=99s interest) very difficult if you try and do both of = those things at the same time.



> For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" = in
> bsddialog(3) with colors, a callback and bottom info" depending = only on
> BSD licensed code.

Cool!



> The complete unicode support is a TODO, although bsddialog provides = some
> feature already https://bugs.freebsd.org/248968
>

Interesting. Will have a look.


> This is probably another misunderstanding. My goal, after some = email and
> chat with others, is to provide a BSD licensed alternative to = dialog
> for the "BASE needs"; similar not equal, otherwise the effort would = not
> be feasible for a single.
> Indeed, also the command lines are quite different. Example
> https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a8= 873372714011c73eb15
>

Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for = transitional period, to come back later and remove old, = obsolete/deprecated code referring to LGPL dialog).



> So far the replacement process was in phabricator with = author(s),
> maintainer(s) and 2/3 members of the core team. Anyone interested = can
> notify me to be added in future reviews.
>

I shouldn=E2=80=99t need notification as a principled = author/maintainer.

I've found = that having a herald rule in phabricator facilitates this. = While
you are listed in the MAINTAINERs file, it's = use has been falling out
of fashion in the years = since we've adopted phabricator. Also, you've
been = kinda AWOL for the last couple of years with activity trailing = off
in the 2018 or 2019 time frame, so it's an = understandable, though now
corrected, oversight. 3 = or 4 years is a long time in 'project time' to be away
from the caretaking of = things.

I was not AWOL. I was (and am) working on my = roadmaps.

Bsdconfig is over 30,000 = lines of code. It wasn=E2=80=99t written in a day.

I have 5 large projects I am working = on:

1. Bsdinstall = namespace
2. Bsdconfig zenity
3. = libfigput
4. Sysconf
5. cmb

I am working on them in GitHub instead of an f.o = branch because I have never been shown how.




Regardless, consider this my notification to be added to add future = reviews.

You'll find you are happier if you add = the herald rule yourself. It's a bit hidden,
but if = you go to reviews.freebsd.org and click on the "More Applications" = button
on the left you'll be able to scroll down to = find Herald. It makes it so people
don't have to = remember, and you'll see everything relevant to the path of = the
tree that you register. Obviously people should = remember, but this will also
catch new people that = are interested in contributing that haven't seen this = thread.

Thanks. Didn=E2=80=99t know MAINTAINERS was on the = way out. Will look into Herald.



 
I am available again for review =E2=80=94 though with a child, it may = take some days before I can respond, since I am new to being a = parent.

Good luck with your child. They are a = joy, but can also take up a lot of time.
One of the = hardest lessons I learned when I had my child was that = sometimes
you don't have enough time to influence = things as much as you'd have done
before the child = and that things in the project will continue to happen = nonetheless.
The shared nature of FreeBSD allows = for these transitions, and the passing of
code from = hand to hand sometimes since there are no 'hard locks' = anymore.


Thanks.

I have = a non-working spouse, so theoretically only part of what you said = applies.
=E2=80=94 
Devin
= --Apple-Mail=_D3A6E4F5-AB76-4B4E-AF53-9E9500F6B7F5-- From nobody Mon May 30 17:49:49 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AE2D91B41D68 for ; Mon, 30 May 2022 17:49:50 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from shxd.cx (shxd.cx [64.201.244.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBjbf0Bq3z4sgL; Mon, 30 May 2022 17:49:50 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from lummox.shxd.cx ([10.0.0.254]:51125 helo=smtpclient.apple) by shxd.cx with esmtpsa (TLS1.2) tls TLS_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nvjWP-0005oP-KL; Mon, 30 May 2022 10:49:41 -0700 Content-Type: text/plain; charset=utf-8 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: bsdinstall TUI utility From: Devin Teske In-Reply-To: <20220530095815.lznjl6m72yttwadg@aniel.nours.eu> Date: Mon, 30 May 2022 10:49:49 -0700 Cc: "Alfonso S. Siciliano" , freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <052BBC3F-DF35-41E4-9B5A-819A1E9DCEC8@freebsd.org> References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <20220530095815.lznjl6m72yttwadg@aniel.nours.eu> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3696.100.31) X-Rspamd-Queue-Id: 4LBjbf0Bq3z4sgL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dtf@shxd.cx has no SPF policy when checking 64.201.244.140) smtp.mailfrom=dtf@shxd.cx X-Spamd-Result: default: False [-0.87 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.57)[-0.569]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[dteske@freebsd.org,dtf@shxd.cx]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:36734, ipnet:64.201.240.0/20, country:US]; FROM_NEQ_ENVFROM(0.00)[dteske@freebsd.org,dtf@shxd.cx]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N > On May 30, 2022, at 2:58 AM, Baptiste Daroussin = wrote: >=20 > On Sat, May 28, 2022 at 04:02:51PM -0700, Devin Teske wrote: >>=20 >>=20 >>> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano = wrote: >>>=20 >>> Hello, >>>=20 >>>=20 >>> So far I replaced and adapted `dialog` with `bsddialog` in >>> bsdinstall/scripts. >>> >>>=20 >>>=20 >>> Currently, I am addressing the last 4 scripts: auto, bootconfig, = keymap, >>> and wlanconfig. These scripts use also the $DIALOG variable and some >>> "if" to handle Xdialog(1). >>> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. >>>=20 >>=20 >> Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean = bsddialog? >>=20 >>=20 >>> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. >>=20 >> bsdinstall(8) uses only dialog(1) in the context of $DIALOG >>=20 >> ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) >>=20 >>=20 >>> * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, >>> Xdialog(1) is not used in this context (that is `bsdconfig -X`). >>>=20 >>=20 >> Correct, bsdconfig does use bsdinstall >>=20 >>=20 >>> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to >>> provide only the support for bsddialog(1) in bsdinstall(8)? >>>=20 >>=20 >> I object. >>=20 >> I and another developer are adding support for zenity >>=20 >> = https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfi= g = >>=20 >> There is also work to resolve the namespace issues in bsdinstall >>=20 >> = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdc= onfig = >>=20 >> I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it = exists until those efforts can be completed. >>=20 >> ASIDE: bsdinstall doesn=E2=80=99t use Xdialog >=20 > I don't think we should block the replacement of dialog with bsddialog = in base, > based on project which have not been touched at all for more than 2 = years. Nobody is blocking anything, stand down. They haven=E2=80=99t been =E2=80=9Ctouched =E2=80=A6 for more than 2 = years=E2=80=9D because I am working on large changes that cannot be = committed piece-meal. > (I am > not blaming anyone involved in those project, time flies quickly :( ). I don=E2=80=99t know what you mean by this. > In particular considering that X-dialog is a long dead project, which = will > probably get removed from the ports tree soonish, and that dialog(1) = and > dialog(3) are planned to get removed from base. >=20 I=E2=80=99m not sure of the relevance to retaining a transitional period = that prevents undue burden on integration efforts. > Don't get me wrong, I do think that there is a value in support = multiple dialog > like application, but either we have the ongoing project back into = active mode > and work with Alfonso OK > to ease the integration of bsddialog, The easiest path to feature parity is a transitional period where =E2=80=94= regardless of the removal of dialog from base =E2=80=94 dialog-handling = code is retained so that integration is not hampered with a head lacking = support that is ever-drifting away from the last-known-good point. > or we complete the > switch of bsddialog at the price of breaking other dialog utilities = support and > later on, it will be possible to resume the zenity project (or any = other) on top > of it. >=20 > So to summerize, are the people working on the bsdconfig having time = to help Yes. I am not the only maintainer =E2=80=94 I have another developer = that I have been working with for over 2 years on our existing roadmap = in GitHub =E2=80=94 either myself or my unofficial mentee can review = changes to bsdconfig. What the community here seems to be implying is that since there were = few-to-no commits on the tree that the code has become defunct when that = is far from the truth. The reality is that the code has only received = minor changes in the past 3-4 years because: 1. It is stable 2. Like the bsddialog project, we have our silo where are working our = roadmap (albeit not in the main f.o git view) > and/or able to propose a concrete plan on how to integrate easily = bsdialog to help > Alfonso moving forward? if yes then that is the best situation for = all, if no, I > think we should pursue with Alfonso's proposal I recommended a concrete plan in my last e-mail to Alfonso. Retain existing LGPL-handling code regardless of removal of = dialog(1),dialog(3) from base so that I and my colleagues can have an = integration period. As previously explained, removing deprecated code = simply because the tool has been removed from base (when an integrator = like myself or my colleagues that work on bsdconfig can simply = re-install it during the sweetheart integration period) makes it = unnecessarily difficult to remediate regressions. =E2=80=94=20 Kindest regards, Devin= From nobody Mon May 30 20:02:31 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 128591B5DEE4 for ; Mon, 30 May 2022 20:02:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBmY42LW6z3l2w for ; Mon, 30 May 2022 20:02:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id x11so5331844vkn.11 for ; Mon, 30 May 2022 13:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7XHnH6DOlgp6UEft+Wn6zTJgBeMpVYONiaX5m93dHyk=; b=SDObub1jxkdGkCQsQHxUAEwxbSGhrl0aX29cLr4WGGTMemtLNtdXt+S1Q5UuHTJMKR Kdt7kfJLgmmPWdNnqMdgY+fAqO81ujU07C7ek8NRk6RG4PKTqvRjJovWl7jaRsAhIJDu nU31jwv+V0qYSDvjHJIy3jRDF44XgZJbpN0IKDCE6M4uhUdr5y/aFYLm1WFAQ1VoTuzz n9NVFC/GSL0+fWUt8R8J8utdkpK6emmX2KQGW6kqG8fhQ06oP/W9+ZcbYtON26vPQ85u Un4o9tmECNbcXCqAy9LZSNPMmQvLwyHd6LGVeM3F/IbxvGJSjK7JO8VASvNcGu4ZJ6TM RxQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7XHnH6DOlgp6UEft+Wn6zTJgBeMpVYONiaX5m93dHyk=; b=pnAgaxS6O9xMkXcAgT0zUMp4oC5HFVndk5YGRmN5ryll2iAMJZswG81EcvQ3QOA1xR k984E32h0aalwjPq96LYMgMOQEdmPu0z7vqaz2MxkqGDDcFz+Iqv1c4AL46YFdUaQVrB VUtA6HWcLohvu6CBS8st1494AozWTZ7vZg58MXHmYnjbYkv63VrQVLhz1wrhNTsOXdPU VB8dWMTgu1VX9Ix5zc4dNc8+SxSc1LOJzKIKKY3MSp8V1WzpA4YVmxUSzpuxcABZrxNU klElHwWyOziYuvYXBA3Cqe/vtc7ajqzjSI+y1z1IwD7rrhH9h3XPD4YXywgHmiBdREur pYRw== X-Gm-Message-State: AOAM533z1nx04nOqx2pliuXp4nSvundVvAY9MloWRXp/QaOZXHBDDIXu iS2ZqtKjfJAw6ugaEIGqcHXosU0HXsEri8ttCgRXuJLfa2Q= X-Google-Smtp-Source: ABdhPJwHcafRw99v0Tx7vz/2AkLTMNQ75OQC6EFzVf+AkbYaoFfGcks6qvud/Pyv5i1id2tXxmzgWUDhVJ45hdntNp0= X-Received: by 2002:ac5:c34d:0:b0:358:2693:dcae with SMTP id l13-20020ac5c34d000000b003582693dcaemr11586097vkk.16.1653940962486; Mon, 30 May 2022 13:02:42 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> In-Reply-To: From: Warner Losh Date: Mon, 30 May 2022 14:02:31 -0600 Message-ID: Subject: Re: bsdinstall TUI utility To: Devin Teske Cc: "Alfonso S. Siciliano" , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000008c82a105e040231d" X-Rspamd-Queue-Id: 4LBmY42LW6z3l2w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=SDObub1j; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --0000000000008c82a105e040231d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2022 at 11:40 AM Devin Teske wrote: > > > On May 30, 2022, at 9:18 AM, Warner Losh wrote: > > > > On Mon, May 30, 2022, 9:59 AM Devin Teske wrote: > >> >> >> > On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano >> wrote: >> > >> > Obviously, I made some mistake writing in English. >> > >> >> No, your English is fine. Perhaps I did not explain myself well. >> >> >> >> > >> > Currently, I am working to replace dialog(1) and dialog(3) in BASE wit= h >> > a BSD licensed alternative . >> > I have almost completed the task >> > . >> >> Well understood. >> >> I have been observing the work. >> >> >> > luckily somebody helped me, I will thank at the end. >> > >> > >> > The topic of the email is not bsdconfig. >> >> Also understood. >> >> >> >> >> > It has already a review, >> >> Link? >> >> >> >> > it preserves the $DIALOG variable to handle a multitude of front-end: >> > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on. >> >> Good. >> >> >> >> > I would continue the discussion for bsdconfig in phabricator; >> > although I should update it after some recent commit. >> > . >> > >> >> I have commented that I request time to review. >> >> >> >> > >> > The topic of this email is bsdinstall. >> >> Correct. >> >> >> >> > I have to update the last few >> > scripts to delete LGPL-dialog from BASE. Properly I asked the right wa= y >> > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts becaus= e >> > the others used only and called directly `dialog` without any >> > bsdconfig's help. >> > >> >> When you look at the bsdinstall code and you see that it calls dialog >> without bsdconfig=E2=80=99s help, that is because I have not written the= code yet. >> When I am done with bsdinstall, it will use bsdconfig=E2=80=99s API (see= =E2=80=9Cbsdconfig >> api=E2=80=9D) >> >> So removing it will only see it added again later. >> >> >> >> > >> > On 5/29/22 01:02, Devin Teske wrote: >> > > >> > > >> > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano >> wrote: >> > >> >> > >> Hello, >> > >> >> > >> >> > >> So far I replaced and adapted `dialog` with `bsddialog` in >> > >> bsdinstall/scripts. >> > >> >> > >> >> > >> >> > >> Currently, I am addressing the last 4 scripts: auto, bootconfig, >> keymap, >> > >> and wlanconfig. These scripts use also the $DIALOG variable and som= e >> > >> "if" to handle Xdialog(1). >> > >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. >> > >> >> > > >> > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean >> bsddialog? >> > > >> > >> > OK. >> > >> > > >> > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. >> > > >> > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG >> > >> > >> > Exactly 1. >> > >> > >> > > >> > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) >> > > >> > > >> > >> * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably= , >> > >> Xdialog(1) is not used in this context (that is `bsdconfig -X`). >> > >> >> > > >> > > Correct, bsdconfig does use bsdinstall >> > > >> > >> > >> > Exactly 2. >> > >> > >> > > >> > >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to >> > >> provide only the support for bsddialog(1) in bsdinstall(8)? >> > >> >> > > >> > > I object. >> > > >> > > I and another developer are adding support for zenity >> > > >> > > >> https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdcon= fig >> < >> https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdcon= fig >> > >> > > >> > > There is also work to resolve the namespace issues in bsdinstall >> > > >> > > >> https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig >> < >> https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig >> > >> > > >> > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where i= t >> exists until those efforts can be completed. >> > > >> > > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog >> > >> > >> > Exactly 3. >> > >> > >> > Anyway, probably the misunderstanding is at this point. My question is >> > not for bsdconfig but for 4 scripts in bsdinstall. >> >> No, the confusion is that I have my own roadmap that includes fixing >> namespace issues in bsdinstall before then merging bsdinstall with >> bsdconfig so that they use a single API. >> > > Any chance we could unify the efforts? > > As the code I previously linked to in GitHub demonstrates, I was working >> on it in 2020 last, and then the pandemic hit and then I had a child, an= d >> then two root canals, and then some issues due to a data breech, so it= =E2=80=99s >> been a very busy couple of years, pandemic aside =E2=80=94 at work we on= ly just >> returned to the office last week and had been entirely remote for over 2= 4 >> months (and to be honest, it is a little strange to come back into the >> office and find *everything* exactly as it was, even to the point that t= he >> fridge is freshly stocked with the same exact foods that were in the fri= dge >> the day we closed the office; it=E2=80=99s Twilight Zone levels of freak= y). >> >> >> > Let' s say: "should bsdinstall/scripts/auto have the code to handle >> > $DIALOG/LGPL-dialog/Xdialog" >> > ``` >> > if [ "$USE_XDIALOG" ]; then >> > yes=3Dok no=3Dcancel defaultno=3Ddefault-no >> > extra_args=3D"--wrap --left" >> > format=3D"$passed_msg" >> > else >> > yes=3Dyes no=3Dno defaultno=3Ddefaultno >> > extra_args=3D"--cr-wrap" >> > format=3D"$passed_msg" >> > fi >> > >> > ... >> > >> > EXTRA_DISTS=3D$( eval dialog \ >> > --backtitle \"$OSNAME Installer\" \ >> > >> > ``` >> > >> > Please note, I have not a strong opinion, if you confirm your needs fo= r >> > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstal= l >> > I'll add and preserve these features in the 4 scripts. >> > Please let me know, so I can complete the dialog/bsddialog replacement >> > soon. >> > >> >> My answer is YES, the code could continue to handle that for three very >> simple reasons: >> >> 1. The effort of your roadmap is to *introduce* bsdinstall and >> introduction of something new is easier when remnants of the past can be >> referenced as we work toward the goal of: >> >> 1.a. Reaching parity >> >> 1.b. Removing deprecated code >> >> 2. Removing old while adding new means if there is ever a discrepancy: >> >> 2.a. I have to go to git to see how old code worked >> >> 2.b. I have to install old code to run it (opposed to installing old >> dialog and setting some environment variables) >> >> 3. Making fixes to correct an unintended consequence may introduce issue= s: >> >> 3.a. When I cannot run the head (as described in 2 above) code with old >> dialog >> >> 3.b. =E2=80=A6 as I have to run two codeines and merge between the two >> >> 3.c. =E2=80=A6 and there will be a time in the future when this should b= e >> expected to break and that should trigger removal, but not before >> completing the transitional period on a roadmap to reach parity >> >> >> >> > >> > > >> > > >> > >> I would prefer this solution because I can avoid: to handle some >> > >> dialog/Xdialog/bsddialog command line difference and to hook some >> > >> bsdconfig function built on dialog(1) incompatible with bsddialog(1= ) >> > >> (for example autosizing, implemented in bsddialog(3) already). >> > >> >> > > >> > > The differences in command line should be handled through >> conditionals, but can be the default and opt to handle LGPL-dialog throu= gh >> a USE_GNU_DIALOG flag >> > > >> > > bsddialog may support auto-sizing, but so does dialog and Xdialog. >> > > >> > > However, ... >> > > >> > > The sizing code in bsdconfig (used indirectly by bsdinstall) was >> written because the auto-sizing that does exist and is available in both >> dialog and Xdialog (as well as Zenity) does not provide a cohesive >> experience when trying to write a program that is in-reality a series of >> bespoke dialogs. >> > > >> > > The sizing code makes sure that regardless of which utility you are >> using that the experience is uniform in what is presented to the user. >> > > >> > > Attempting to rely solely on the auto-sizing available from these >> separate utilities (including bsddialog) would change the UI/UX. >> > > >> > > The problem was solved by: >> > > >> > > 1. Making the stored text used for dialogs dictate how it will look >> > > 2. Painstakingly determining where each utility failed given the tex= t >> > > 3. Determining how to make the utility display the text properly >> > > >> > > For example, stored text will contain newlines instead of attempting >> to rely on line wrapping on a box of given size. >> > > >> > > I would have to evaluate bsddialog=E2=80=99s auto-sizing to determin= e if it >> is trust-worthy given not only all the stored texts, but all the >> translations as well (as bsdconfig is i18n compatible). It is actually l= ess >> work to just allow bsdconfig to likely treat bsddialog as it is dialog a= nd >> let it perform the size calculations for you. >> > > >> > > If bsddialog is top be a drop-in replacement, I=E2=80=99m more than = a little >> surprised that it cannot accept the sizes calculated for dialog being >> passed to it. >> > > >> > > >> > >> >> > >> Please note these considerations are only for bsdinstall, bsdconfig >> is >> > >> unchanged. >> > >> >> > > >> > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-tur= n >> relies on dlg_gauge_reallocate(3) from LGPL-dialog? >> > >> > >> > >> > I seem these considerations are for bsdconfig so the discussion can >> > continue in phabricator. Of course I made some error in English in the >> > first email. >> >> No, your English was fine. I perhaps did not explain the we are at >> perhaps cross efforts with our distinctly separate roadmaps with their o= wn >> goals and timelines. >> >> >> >> > >> > Here the topic is bsdinstall. >> > >> > bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months, >> > all the components (written in C) were adapted or rewritten to >> > use bsddialog(3). Example >> > >> https://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7b= df8cec6d32 >> > >> >> I will review and get back with comment. >> >> >> > Most bsdinstall scripts "call" just `dialog` using its autosizing >> > (without any bsdconfig's help). >> > So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example >> > >> https://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3b= ffadd17853 >> > The important question was asked above. I would want to understand the >> > right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall >> > scripts. >> > >> >> Correct. It is part of my roadmap to remove said auto-sizing in >> bsdinstall. >> >> >> >> > I had some problem using the autosizing functions of bsdconfig for >> > bsddialog, >> >> I do not fully understand this. The API examines the text and determines >> the proper size to pass. Can bsddialog not accept a size? >> >> >> >> >> > probably bacause dialog(3) and bsddialog(3) implement >> > different auto text wrapping algorithms, or the utilities have differe= nt >> > command lines. >> >> Does bsddialog have support for specifying the size of a widget? >> >> >> >> >> > Honestly I am not interested in investigating, >> >> That is an unfortunate statement. I am interested in the work being done= , >> perhaps you could be interested in the work I am doing that I have been >> working on for longer than you have been working on bsddialog. >> >> >> >> > I would >> > like to improve bsddialog instead of wasting time on a LGPL software >> > almost ready to leave the BASE. >> >> Leaving existing code in place does not waste time on LGPL software >> because: >> >> 1. Someone like myself will be installing LGPL dialog from ports and >> relying on the old code to utilize it: >> >> 1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using >> environment variables) between LGPL dialog and bsdialog >> >> 1.b. so that I can compare the two against each other and fix any >> regressions >> >> Removing the code to handle LGPL dialog at the same time as removing LGP= L >> dialog from base kind of makes that hard. As previously explained, that >> will force me to perform a series of hacks where I pull down the old tre= e >> with the LGPL handling code and make changes blindly which will only bec= ome >> more and more difficult as the old code without bsddialog support and ne= w >> code (as you propose) without LGPL handling code drift further and furth= er >> apart. >> >> I don=E2=80=99t understand what is so difficult about separating the tas= k of >> =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving deprecated featur= es=E2=80=9D to accommodate a >> transitional period is so difficult =E2=80=94 it makes reaching feature = parity >> (which is in bsddialog=E2=80=99s interest) very difficult if you try and= do both of >> those things at the same time. >> >> >> >> > For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" in >> > bsddialog(3) with colors, a callback and bottom info" depending only o= n >> > BSD licensed code. >> >> Cool! >> >> >> >> > The complete unicode support is a TODO, although bsddialog provides so= me >> > feature already https://bugs.freebsd.org/248968 >> > >> >> Interesting. Will have a look. >> >> >> > This is probably another misunderstanding. My goal, after some email a= nd >> > chat with others, is to provide a BSD licensed alternative to dialog >> > for the "BASE needs"; similar not equal, otherwise the effort would no= t >> > be feasible for a single. >> > Indeed, also the command lines are quite different. Example >> > >> https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a8873372714= 011c73eb15 >> > >> >> Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for >> transitional period, to come back later and remove old, obsolete/depreca= ted >> code referring to LGPL dialog). >> >> >> >> > So far the replacement process was in phabricator with author(s), >> > maintainer(s) and 2/3 members of the core team. Anyone interested can >> > notify me to be added in future reviews. >> > >> >> I shouldn=E2=80=99t need notification as a principled author/maintainer. >> > > I've found that having a herald rule in phabricator facilitates this. Whi= le > you are listed in the MAINTAINERs file, it's use has been falling out > of fashion in the years since we've adopted phabricator. Also, you've > been kinda AWOL for the last couple of years with activity trailing off > in the 2018 or 2019 time frame, so it's an understandable, though now > corrected, oversight. 3 or 4 years is a long time in 'project time' to be > away > from the caretaking of things. > > > I was not AWOL. I was (and am) working on my roadmaps. > I meant was that there aren't many commits in the last 3-4 years for bsdinstall that were authored by you, but there were a large number authored by others. It was a way of explaining why people might have thought the entry in MAINTAINERS was stale. It was a poor choice of words, and implied much more than I'd intended. It was a sloppy shortcut in expressing this. I'm sorry. Bsdconfig is over 30,000 lines of code. It wasn=E2=80=99t written in a day. > > I have 5 large projects I am working on: > > 1. Bsdinstall namespace > 2. Bsdconfig zenity > 3. libfigput > 4. Sysconf > 5. cmb > > I am working on them in GitHub instead of an f.o branch because I have > never been shown how. > Great! That's the new model. It's easier for the project to setup, but it makes it harder for people to see progress on. there's not been a lot about these things on the mailing lists, but they all sound interesting. Regardless, consider this my notification to be added to add future reviews= . >> > > You'll find you are happier if you add the herald rule yourself. It's a > bit hidden, > but if you go to reviews.freebsd.org and click on the "More Applications" > button > on the left you'll be able to scroll down to find Herald. It makes it so > people > don't have to remember, and you'll see everything relevant to the path of > the > tree that you register. Obviously people should remember, but this will > also > catch new people that are interested in contributing that haven't seen > this thread. > > > Thanks. Didn=E2=80=99t know MAINTAINERS was on the way out. Will look int= o Herald > Sure thing. It's quite helpful. Warner > > > I am available again for review =E2=80=94 though with a child, it may tak= e some >> days before I can respond, since I am new to being a parent. >> > > Good luck with your child. They are a joy, but can also take up a lot of > time. > One of the hardest lessons I learned when I had my child was that sometim= es > you don't have enough time to influence things as much as you'd have done > before the child and that things in the project will continue to happen > nonetheless. > The shared nature of FreeBSD allows for these transitions, and the passin= g > of > code from hand to hand sometimes since there are no 'hard locks' anymore. > > > Thanks. > > I have a non-working spouse, so theoretically only part of what you said > applies. > --0000000000008c82a105e040231d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 30, 2022 at 11:40 AM Devi= n Teske <dteske@= freebsd.org> wrote:


On May 30, 2022= , at 9:18 AM, Warner Losh <imp@bsdimp.com> wrote:



On Mon, May 30, 2022, 9:59 AM Devin Teske <dteske@freebsd.org> wrote= :


> On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano <alfix86@gmail.com= > wrote:
>
> Obviously, I made some mistake writing in English.
>

No, your English is fine. Perhaps I did not explain myself well.



>
> Currently, I am working to replace dialog(1) and dialog(3) in BASE wit= h
> a BSD licensed alternative <https://wiki.freebs= d.org/GPLinBase>.
> I have almost completed the task
> <https://wiki.freebsd.org/Ro= admapFromDialogToBSDDialog>.

Well understood.

I have been observing the work.


> luckily somebody helped me, I will thank at the end.
>
>
> The topic of the email is not bsdconfig.

Also understood.




> It has already a review,

Link?



> it preserves the $DIALOG variable to handle a multitude of front-end:<= br> > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on.
Good.



> I would continue the discussion for bsdconfig in phabricator;
> although I should update it after some recent commit.
> <https://reviews.freebsd.org/D34755>. >

I have commented that I request time to review.



>
> The topic of this email is bsdinstall.

Correct.



> I have to update the last few
> scripts to delete LGPL-dialog from BASE. Properly I asked the right wa= y
> to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts becaus= e
> the others used only and called directly `dialog` without any
> bsdconfig's help.
>

When you look at the bsdinstall code and you see that it calls dialog witho= ut bsdconfig=E2=80=99s help, that is because I have not written the code ye= t. When I am done with bsdinstall, it will use bsdconfig=E2=80=99s API (see= =E2=80=9Cbsdconfig api=E2=80=9D)

So removing it will only see it added again later.



>
> On 5/29/22 01:02, Devin Teske wrote:
> >
> >
> >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano <alfix86@= gmail.com> wrote:
> >>
> >> Hello,
> >>
> >>
> >> So far I replaced and adapted `dialog` with `bsddialog` in > >> bsdinstall/scripts.
> >> <https://wiki.freeb= sd.org/RoadmapFromDialogToBSDDialog>
> >>
> >>
> >> Currently, I am addressing the last 4 scripts: auto, bootconf= ig, keymap,
> >> and wlanconfig. These scripts use also the $DIALOG variable a= nd some
> >> "if" to handle Xdialog(1).
> >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `d= ialog`.
> >>
> >
> > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean bs= ddialog?
> >
>
> OK.
>
> >
> >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI ut= ility.
> >
> > bsdinstall(8) uses only dialog(1) in the context of $DIALOG
>
>
> Exactly 1.
>
>
> >
> > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1)
> >
> >
> >> * I seem bsdconfig(8) does not "call" these 4 scrip= ts, so, probably,
> >>=C2=A0 =C2=A0Xdialog(1) is not used in this context (that is `= bsdconfig -X`).
> >>
> >
> > Correct, bsdconfig does use bsdinstall
> >
>
>
> Exactly 2.
>
>
> >
> >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog = to
> >> provide only the support for bsddialog(1) in bsdinstall(8)? > >>
> >
> > I object.
> >
> > I and another developer are adding support for zenity
> >
> > http= s://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig= <https://g= ithub.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig><= br> > >
> > There is also work to resolve the namespace issues in bsdinstall<= br> > >
> > = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdco= nfig <https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig>
> >
> > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support wher= e it exists until those efforts can be completed.
> >
> > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog
>
>
> Exactly 3.
>
>
> Anyway, probably the misunderstanding is at this point. My question is=
> not for bsdconfig but for 4 scripts in bsdinstall.

No, the confusion is that I have my own roadmap that includes fixing namesp= ace issues in bsdinstall before then merging bsdinstall with bsdconfig so t= hat they use a single API.
Any chance we could unify the efforts?

As the code I previously linked to in GitHub demonstrates, I was working on= it in 2020 last, and then the pandemic hit and then I had a child, and the= n two root canals, and then some issues due to a data breech, so it=E2=80= =99s been a very busy couple of years, pandemic aside =E2=80=94 at work we = only just returned to the office last week and had been entirely remote for= over 24 months (and to be honest, it is a little strange to come back into= the office and find *everything* exactly as it was, even to the point that= the fridge is freshly stocked with the same exact foods that were in the f= ridge the day we closed the office; it=E2=80=99s Twilight Zone levels of fr= eaky).


> Let' s say: "should bsdinstall/scripts/auto have the code to = handle
> $DIALOG/LGPL-dialog/Xdialog"
> ```
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if [ "$USE_XDIALOG" ]; then
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes=3Dok no=3Dca= ncel defaultno=3Ddefault-no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extra_args=3D&qu= ot;--wrap --left"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"$= passed_msg"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0else
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes=3Dyes no=3Dn= o defaultno=3Ddefaultno
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extra_args=3D&qu= ot;--cr-wrap"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"$= passed_msg"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0fi
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0EXTRA_DISTS=3D$( eval dialog \
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= backtitle \"$OSNAME Installer\" \
>
> ```
>
> Please note, I have not a strong opinion, if you confirm your needs fo= r
> $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstal= l
> I'll add and preserve these features in the 4 scripts.
> Please let me know, so I can complete the dialog/bsddialog replacement=
> soon.
>

My answer is YES, the code could continue to handle that for three very sim= ple reasons:

1. The effort of your roadmap is to *introduce* bsdinstall and introduction= of something new is easier when remnants of the past can be referenced as = we work toward the goal of:

1.a. Reaching parity

1.b. Removing deprecated code

2. Removing old while adding new means if there is ever a discrepancy:

2.a. I have to go to git to see how old code worked

2.b. I have to install old code to run it (opposed to installing old dialog= and=C2=A0 setting some environment variables)

3. Making fixes to correct an unintended consequence may introduce issues:<= br>
3.a. When I cannot run the head (as described in 2 above) code with old dia= log

3.b. =E2=80=A6 as I have to run two codeines and merge between the two

3.c. =E2=80=A6 and there will be a time in the future when this should be e= xpected to break and that should trigger removal, but not before completing= the transitional period on a roadmap to reach parity



>
> >
> >
> >> I would prefer this solution because I can avoid: to handle s= ome
> >> dialog/Xdialog/bsddialog command line difference and to hook = some
> >> bsdconfig function built on dialog(1) incompatible with bsddi= alog(1)
> >> (for example autosizing, implemented in bsddialog(3) already)= .
> >>
> >
> > The differences in command line should be handled through conditi= onals, but can be the default and opt to handle LGPL-dialog through a USE_G= NU_DIALOG flag
> >
> > bsddialog may support auto-sizing, but so does dialog and Xdialog= .
> >
> > However, ...
> >
> > The sizing code in bsdconfig (used indirectly by bsdinstall) was = written because the auto-sizing that does exist and is available in both di= alog and Xdialog (as well as Zenity) does not provide a cohesive experience= when trying to write a program that is in-reality a series of bespoke dial= ogs.
> >
> > The sizing code makes sure that regardless of which utility you a= re using that the experience is uniform in what is presented to the user. > >
> > Attempting to rely solely on the auto-sizing available from these= separate utilities (including bsddialog) would change the UI/UX.
> >
> > The problem was solved by:
> >
> > 1. Making the stored text used for dialogs dictate how it will lo= ok
> > 2. Painstakingly determining where each utility failed given the = text
> > 3. Determining how to make the utility display the text properly<= br> > >
> > For example, stored text will contain newlines instead of attempt= ing to rely on line wrapping on a box of given size.
> >
> > I would have to evaluate bsddialog=E2=80=99s auto-sizing to deter= mine if it is trust-worthy given not only all the stored texts, but all the= translations as well (as bsdconfig is i18n compatible). It is actually les= s work to just allow bsdconfig to likely treat bsddialog as it is dialog an= d let it perform the size calculations for you.
> >
> > If bsddialog is top be a drop-in replacement, I=E2=80=99m more th= an a little surprised that it cannot accept the sizes calculated for dialog= being passed to it.
> >
> >
> >>
> >> Please note these considerations are only for bsdinstall, bsd= config is
> >> unchanged.
> >>
> >
> > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-= turn relies on dlg_gauge_reallocate(3) from LGPL-dialog?
>
>
>
> I seem these considerations are for bsdconfig so the discussion can > continue in phabricator. Of course I made some error in English in the=
> first email.

No, your English was fine. I perhaps did not explain the we are at perhaps = cross efforts with our distinctly separate roadmaps with their own goals an= d timelines.



>
> Here the topic is bsdinstall.
>
> bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months,
> all the components (written in C) were adapted or rewritten to
> use bsddialog(3). Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7bdf8ce= c6d32
>

I will review and get back with comment.


> Most bsdinstall scripts "call" just `dialog` using its autos= izing
> (without any bsdconfig's=C2=A0 help).
> So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3bffadd= 17853
> The important question was asked above. I would want to understand the=
> right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall<= br> > scripts.
>

Correct. It is part of my roadmap to remove said auto-sizing in bsdinstall.=



> I had some problem using the autosizing functions of bsdconfig for
> bsddialog,

I do not fully understand this. The API examines the text and determines th= e proper size to pass. Can bsddialog not accept a size?




> probably bacause dialog(3) and bsddialog(3) implement
> different auto text wrapping algorithms, or the utilities have differe= nt
> command lines.

Does bsddialog have support for specifying the size of a widget?




> Honestly I am not interested in investigating,

That is an unfortunate statement. I am interested in the work being done, p= erhaps you could be interested in the work I am doing that I have been work= ing on for longer than you have been working on bsddialog.



> I would
> like to improve bsddialog instead of wasting time on a LGPL software > almost ready to leave the BASE.

Leaving existing code in place does not waste time on LGPL software because= :

1. Someone like myself will be installing LGPL dialog from ports and relyin= g on the old code to utilize it:

1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using env= ironment variables) between LGPL dialog and bsdialog

1.b. so that I can compare the two against each other and fix any regressio= ns

Removing the code to handle LGPL dialog at the same time as removing LGPL d= ialog from base kind of makes that hard. As previously explained, that will= force me to perform a series of hacks where I pull down the old tree with = the LGPL handling code and make changes blindly which will only become more= and more difficult as the old code without bsddialog support and new code = (as you propose) without LGPL handling code drift further and further apart= .

I don=E2=80=99t understand what is so difficult about separating the task o= f =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving deprecated feature= s=E2=80=9D to accommodate a transitional period is so difficult =E2=80=94 i= t makes reaching feature parity (which is in bsddialog=E2=80=99s interest) = very difficult if you try and do both of those things at the same time.



> For dpv(3) in distfetch.c, I implemented an "improved mixedgauge&= quot; in
> bsddialog(3) with colors, a callback and bottom info" depending o= nly on
> BSD licensed code.

Cool!



> The complete unicode support is a TODO, although bsddialog provides so= me
> feature already https://bugs.freebsd.org/248968 >

Interesting. Will have a look.


> This is probably another misunderstanding. My goal, after some email a= nd
> chat with others, is to provide a BSD licensed alternative to dialog > for the "BASE needs"; similar not equal, otherwise the effor= t would not
> be feasible for a single.
> Indeed, also the command lines are quite different. Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a8873372714011c7= 3eb15
>

Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for tr= ansitional period, to come back later and remove old, obsolete/deprecated c= ode referring to LGPL dialog).



> So far the replacement process was in phabricator with author(s),
> maintainer(s) and 2/3 members of the core team. Anyone interested can<= br> > notify me to be added in future reviews.
>

I shouldn=E2=80=99t need notification as a principled author/maintainer.

I've found t= hat having a herald rule in phabricator facilitates this. While
y= ou are listed in the MAINTAINERs file, it's use has been falling out
of fashion in the years since we've adopted phabricator. Also, = you've
been kinda AWOL for the last couple of years with acti= vity trailing off
in the 2018 or 2019 time frame, so it's an = understandable, though now
corrected, oversight. 3 or 4 years is = a long time in 'project time' to be away
from the caretak= ing of things.

I wa= s not AWOL. I was (and am) working on my roadmaps.

I meant was that there aren't many commits in= the last 3-4 years for bsdinstall
that were authored by you,= =C2=A0but there were a large number authored by others. It
was a = way of explaining why people might have thought the entry in MAINTAINERS
was stale. It was a poor choice of words, and implied much more tha= n I'd intended.
It was=C2=A0a sloppy=C2=A0shortcut in express= ing this. I'm sorry.

Bsdconfig is over 30,000 lines of code. = It wasn=E2=80=99t written in a day.

I have 5 large= projects I am working on:

1. Bsdinstall namespace=
2. Bsdconfig zenity
3. libfigput
4. Sysconf<= /div>
5. cmb

I am working on them in GitHub in= stead of an f.o branch because I have never been shown how.

Great! That's the new model. It'= s easier for the project to setup, but it makes
it harder for peo= ple to see progress on. there's not been a lot about these things
=
on the mailing lists, but they all sound interesting.

Regar= dless, consider this my notification to be added to add future reviews.
=

You'll find you are happier if you add= the herald rule yourself. It's a bit hidden,
but if you go t= o reviews.freebsd= .org and click on the "More Applications" button
on= the left you'll be able to scroll down to find Herald. It makes it so = people
don't have to remember, and you'll see everything = relevant to the path of the
tree that you register. Obviously peo= ple should remember, but this will also
catch new people that are= interested in contributing that haven't seen this thread.
<= /div>

Thanks. Didn=E2=80= =99t know MAINTAINERS was on the way out. Will look into Herald
=

Sure thing. It's quite helpful.
<= div>
Warner
=C2=A0
=C2=A0
I am available again for review =E2=80=94 though with a child, it may take = some days before I can respond, since I am new to being a parent.

Good luck with your child. They are a joy, but c= an also take up a lot of time.
One of the hardest lessons=C2=A0I = learned when I had my child was that sometimes
you don't have= enough time to influence things as much as you'd have done
b= efore the child and that things in the project will continue to happen none= theless.
The shared nature of FreeBSD allows for these transition= s, and the passing of
code from hand to hand sometimes since ther= e are no 'hard locks' anymore.


Thanks.

I= have a non-working spouse, so theoretically only part of what you said app= lies.
--0000000000008c82a105e040231d-- From nobody Sun Jun 5 20:18:10 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1FC161BD5581 for ; Sun, 5 Jun 2022 20:18:14 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGSc56PR4z3hMh for ; Sun, 5 Jun 2022 20:18:13 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654460293; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zBfYh4DAXBMzv+xbi+DEJ3yK6U+V4tPCLq/zG33hOdY=; b=xSnMDjBVjHH7VtRRyNeDVSRg3HrxRVMYmuJ7qEbS9/UN0Sr+myCedr3bzW598z+zsOPKso 1WNVuBsbpAfZ+UzIosl5a+TuCvrolzKA6LFpuz0/V5/MvD3vBpsuGfuskZ7oY7Rtf5Shfl 3DXkCOj+J0BembGLMtwowy2jD78qFizVLZbYVwkkMCIewsgpM1nzzFdEEX+fx2/Bcl/tJm m+g6Xo3fWdNEtnpL5VEG/yAAoJT6FA3zKgHs6N8YF/UmlR+is60iKgCQ54l8J9j8Ojr67a FDlINm/t5E+nQTJyEDrZ4E7NhG5oOBXXPwgLT9ph50pJOYt9GNqPyVB5apGdPw== Received: from [IPV6:2601:405:4a00:acd:11a8:cd18:f79f:d96b] (unknown [IPv6:2601:405:4a00:acd:11a8:cd18:f79f:d96b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: nwhitehorn/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6FA082FE05 for ; Sun, 5 Jun 2022 20:18:12 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Message-ID: <2d9a9f33-857e-5f42-e323-f8459d1a8197@freebsd.org> Date: Sun, 5 Jun 2022 16:18:10 -0400 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: bsdinstall TUI utility Content-Language: en-US To: freebsd-arch@freebsd.org References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> From: Nathan Whitehorn In-Reply-To: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654460293; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zBfYh4DAXBMzv+xbi+DEJ3yK6U+V4tPCLq/zG33hOdY=; b=e5bNqFpmjrvkH7cC3wVP869ZGKAGT9EE5M61Ppu+epWwmA4/WC56966USkfeAPiCS9B6UZ k7FmXJzgfqN0vD7fyAqGUxK/h11oC/vZqjDelJcPHUaczIFGBFMua3hGbjKHXGzf76wdSt AWYazJZLs18zt45yTb6zgs4TNS7PJqmhTOOSExz8gpVrh2+0AA+KxdfA+f3QKgJM6bH3mH 63/mGr6hlVt529nHMIqVoGEEJ/Q5P7ClKT2R6VfvKtt0rirtAKs/3oWLp4jGI9Y9YuCE0U gJYaOQ5zvPwcQqlG8CIjqNI/vy/auPyrYV/tYqhqPPNyeZb3pH5J8jsXp/wdfw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654460293; a=rsa-sha256; cv=none; b=yWW7LJe57hMGmtlY8YcjiMPJ4xI3Az2cX2iEpthqHYYwvKd11hwbs/SkfUcH60lBM72Ruy jKPW3LekTIdFhdEq5wVyHE1G1Ksr8CZ081sUdet7FhOH0XTnm7uq66Ew4uNyDJs7nY1QK6 mRXYbKowqNVDw4KyJZxSbY5KpDFNzoAXKkv6I0NFI3a0JzxhFUqOLaGaGpQBB9qS3mOtpz PyiWrR314oYp6d06Vkf04wsANdb9i/0KCeoUAj3283oq694gMMMHYOxxI3E0yjbSFcURcq w9H9kYeFQIyb35o39c2wk7t/s3hxwEr19oJ9YzhkF9f8Ibx5wgSgxNKysToXtw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N A few days late to this, but I added Xdialog support kind of on a lark in the original version of the utility. I don't think anyone has ever used it or cared about, and I think it can be nuked without issue. -nathan On 5/28/22 17:59, Alfonso S. Siciliano wrote: > Hello, > > > So far I replaced and adapted `dialog` with `bsddialog` in > bsdinstall/scripts. > > > > Currently, I am addressing the last 4 scripts: auto, bootconfig, keymap, > and wlanconfig. These scripts use also the $DIALOG variable and some > "if" to handle Xdialog(1). > For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. > > * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. > * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably, >   Xdialog(1) is not used in this context (that is `bsdconfig -X`). > > > Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to > provide only the support for bsddialog(1) in bsdinstall(8)? > > I would prefer this solution because I can avoid: to handle some > dialog/Xdialog/bsddialog command line difference and to hook some > bsdconfig function built on dialog(1) incompatible with bsddialog(1) > (for example autosizing, implemented in bsddialog(3) already). > > > Please note these considerations are only for bsdinstall, bsdconfig is > unchanged. > > > Best regards, > Alfonso > From nobody Tue Jun 21 14:01:58 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3626E85C117 for ; Tue, 21 Jun 2022 14:02:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LS7Vn74jsz4SY5 for ; Tue, 21 Jun 2022 14:02:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2e.google.com with SMTP id k25so6133765vso.6 for ; Tue, 21 Jun 2022 07:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=JPIMKDtvugt8M/4TDN18FYmXgOkDahuvEDzY8FsUPsg=; b=la+VUiuCqEE9exq35I4Aq3lkdTrEDtv6wi3jFMpshx+0ZWs2fC9pn5vjeWK7MjZijv r72yppb4kEBrKWiFbK+e3fA9ndRlLBXK5rXzYBZO/eU+frqGAgUhiTG4VfssAPawYq1U fQJFFelaGvpCLBUKj2nHqcYWjpJIH2YcA5lBhus0UEdWOX1ifxws3pUBSMbykEm/MJ+w TsmLHSXqebCEdkAmsFcJo0IpBzAVz2gdyOg5pWinG9rUQJmwRN47KbFGv9yMtBC/vspf MBO1x8qyJDHQ1mJ/gyd0RuV8buN21hI8kuOJs/pH3SVGU2j/4cXbSoh8n2tOw7fyyy8g 6NjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JPIMKDtvugt8M/4TDN18FYmXgOkDahuvEDzY8FsUPsg=; b=pdoE2y7PhJCb9vDryIhQMhF81CqkMmYo4hp+E7Fjsc48hXWIhrLCk/orgawAgH9hBh L5+oWBedI4JVPMwxzFqUyufQftcwe4SEhAMCzXtVgEyE7xac+Uh0YNsBQ4rgi68GBWKo bBae/fkDIQcBOcELQ4p84btfQEBFkGBvCsV/G0K0rT4/ld3yise0Zr7k8Yqp8oQ9nwmJ NTDYvRNdVdyhk6/43vZcPatK5NkckLU9cL7vplGxvuzmVHImp8C82yPbSAdqOzZZCpLs CuSRDlgZb0Ef8cL269Gx+2jrYOGnhvjMDWVajxm2B6Ko6OOHGGcBmRvYaCyFMstBBetM er7A== X-Gm-Message-State: AJIora8qqmH+MHqLghoHd0Fyl/JlcJqFgNwe7U54SypfM0sNdMfdz6Ck tmG7uH+vXzd+dgPQ0qGqhsJPqhCwrUGafa2DWYxH/witwSc= X-Google-Smtp-Source: AGRyM1vB4Zs4jJh4b89qwTJmMaTLHpPsTWj1KpWn+HpNNf4FPDrpovWeiwmsb6h5jqV7Y1QAnH77CsAT2PD2r3m9/aQ= X-Received: by 2002:a05:6102:5716:b0:354:39ba:6ebf with SMTP id dg22-20020a056102571600b0035439ba6ebfmr3236683vsb.53.1655820129025; Tue, 21 Jun 2022 07:02:09 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Tue, 21 Jun 2022 08:01:58 -0600 Message-ID: Subject: Updating reboot's default To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000009a5cca05e1f5aa62" X-Rspamd-Queue-Id: 4LS7Vn74jsz4SY5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=la+VUiuC; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.988]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2e:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000009a5cca05e1f5aa62 Content-Type: text/plain; charset="UTF-8" 15 or 20 years ago, we talked about changing the default for reboot from 'right now' to being safe shutdown. There were arguments made against it due to tiny appliances and such. Time has past, and this oddity has persisted. It's time to revisit that decision. I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate behavior. However, the 'reboot' command will switch from '-q' behavior to '-r' behavior. I'll update the man page, etc to reflect these new defaults. Most of the systems I've been on in the last 10-15 years have had some flavor of 'alias reboot reboot -r' in their login scripts and/or made shell scripts that did this. This will match what everybody else is doing, and will likely result in less astonishment rather than more, even though it changes a long-standing default behavior. Comments? Warner --0000000000009a5cca05e1f5aa62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
15 or 20 years ago, we talked about changing the default f= or reboot from 'right now' to being safe shutdown. There were argum= ents made against it due to tiny appliances and such.

Time has past, and this oddity has persisted. It's time to revisit th= at decision.

I'd propose that we keep 'fas= tboot' and 'fasthalt' having the immediate behavior. However, t= he 'reboot' command will switch from '-q' behavior to '= -r' behavior.

I'll update the man page, et= c to reflect these new defaults. Most of the systems I've been on in th= e last 10-15 years have had some flavor of 'alias reboot reboot -r'= in their login scripts and/or made shell scripts that did this. This will = match what everybody else is doing, and will likely result in less astonish= ment rather than more, even though it changes a long-standing default behav= ior.

Comments?

Warner

--0000000000009a5cca05e1f5aa62-- From nobody Tue Jun 21 14:04:47 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C9D285CB0A for ; Tue, 21 Jun 2022 14:05:01 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LS7Z373KFz4T87 for ; Tue, 21 Jun 2022 14:04:59 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 6B52E320092E; Tue, 21 Jun 2022 10:04:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 21 Jun 2022 10:04:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1655820291; x=1655906691; bh=0rh/pz5e1xqv5JLFvhMorRSbWSm8 vRf2+6ZnzGZQy3U=; b=imuUdQs44K/9qjCgo89pSdHiis342vWvEEAWN8Bi/+hQ sAaWopQGRw8uaGuATutxNFTAWI1Tu5Df/meMA+ySNqQ8+MvU9POCV2C4glS1DvQB qnkoRP4g3CSvarO12IwjHcKWnQU9IpkClEuYbHJAS5GayHwv69mOAtF8xU+Oqw6K tKpBAVzwJu0o5sDYCBaQ8kI6WXz8StTOwxwViHNVOUQ//tjvaaJ7N0GEXAI+2pV+ VbQeWWwV2QqcOx31cfm940gvnIYc/Rs+RLWI3p9Y7n4vMjjmCjoOlSXMskFln8q+ MDft5msB49yWoXPdsVvmzgPnPLDcOFa2tOdnt2Af+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeffedgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehttd ertddttddvnecuhfhrohhmpefvohhmucflohhnvghsuceothhhjhesfhhrvggvsghsugdr ohhrgheqnecuggftrfgrthhtvghrnheplefhjeelteelgfefffeiffevudfggffgveevje egkeegvedtleektdehfedvgeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepthhhjhesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ib75146ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 21 Jun 2022 10:04:50 -0400 (EDT) Date: Tue, 21 Jun 2022 15:04:47 +0100 From: Tom Jones To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Updating reboot's default Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LS7Z373KFz4T87 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=imuUdQs4; dmarc=none; spf=softfail (mx1.freebsd.org: 64.147.123.19 is neither permitted nor denied by domain of thj@freebsd.org) smtp.mailfrom=thj@freebsd.org X-Spamd-Result: default: False [-3.87 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm2]; FREEFALL_USER(0.00)[thj]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.985]; R_SPF_SOFTFAIL(0.00)[~all:c]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.981]; MLMMJ_DEST(0.00)[freebsd-arch]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jun 21, 2022 at 08:01:58AM -0600, Warner Losh wrote: > 15 or 20 years ago, we talked about changing the default for reboot from > 'right now' to being safe shutdown. There were arguments made against it > due to tiny appliances and such. > > Time has past, and this oddity has persisted. It's time to revisit that > decision. > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > behavior. However, the 'reboot' command will switch from '-q' behavior to > '-r' behavior. > > I'll update the man page, etc to reflect these new defaults. Most of the > systems I've been on in the last 10-15 years have had some flavor of 'alias > reboot reboot -r' in their login scripts and/or made shell scripts that did > this. This will match what everybody else is doing, and will likely result > in less astonishment rather than more, even though it changes a > long-standing default behavior. > > Comments? +1 I was perplex for a long time why reboot did this and especially when I was using it to boot test kernels. The current behaviour is not what I or I think most people expect. - Tom From nobody Tue Jun 21 14:05:35 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 00AD785CEBF for ; Tue, 21 Jun 2022 14:05:49 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from smtp1.servers.tyktech.dk (smtp1.servers.tyktech.dk [85.209.118.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LS7Zz4WN6z4TcN for ; Tue, 21 Jun 2022 14:05:47 +0000 (UTC) (envelope-from thomas@gibfest.dk) Subject: Re: Updating reboot's default DKIM-Filter: OpenDKIM Filter v2.10.3 smtp1.servers.tyktech.dk F220E22470 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1655820339; bh=cTnqmT/mzWQCSjrKmHMjxH+28hyNaT818Q1IVLF8qEk=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=S1WT0q/QEYHyBfWlMzB6XnxVqcFFinT9W6PR+mfKSBmD2aZ+1Pv/FufOTgVsXJ9Ws bwkcCJETTxrc1JYlbBsmWACB+Zfn9XjHTsCujy0D2s7PnlV+J3kfIX5Pc+UdVVtB5X 9cpGW5JSQ6JqHPQOInYpJ49XTK+t+73zpYdsDgFGItlVuNN53ypeYEL1WrqdzLre6E i4xi8uU4xUlRMqP2wWXwZycSMsOIEhU84ilUKQAMnNmSQYu8yhj1NOvA1qeJvk8HTY AwPZUuXUA6HW4Kr4HanpvCfVAI4tLaZC/2/NJq8p+5DcOz+0jd58yrFJk1EMI9/QDM WA3yIFyKsyufQ== To: Warner Losh References: Cc: "freebsd-arch@freebsd.org" From: Thomas Steen Rasmussen Message-ID: <80139d9e-5d44-7724-af80-07ebdc23612f@gibfest.dk> Date: Tue, 21 Jun 2022 16:05:35 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LS7Zz4WN6z4TcN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gibfest.dk header.s=default header.b="S1WT0q/Q"; dmarc=pass (policy=reject) header.from=gibfest.dk; spf=pass (mx1.freebsd.org: domain of thomas@gibfest.dk designates 85.209.118.35 as permitted sender) smtp.mailfrom=thomas@gibfest.dk X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gibfest.dk:s=default]; FREEFALL_USER(0.00)[thomas]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gibfest.dk:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gibfest.dk,reject]; NEURAL_HAM_SHORT(-1.00)[-0.995]; MLMMJ_DEST(0.00)[freebsd-arch]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209327, ipnet:85.209.116.0/22, country:DK]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 6/21/22 4:01 PM, Warner Losh wrote: > This will match what everybody else is doing, and > will likely result in less astonishment rather than more, even though it > changes a long-standing default behavior. > > Comments? > > Warner > Hello! Yes please - and thank you for working on this. /Thomas From nobody Tue Jun 21 14:05:40 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 97E0385D11A for ; Tue, 21 Jun 2022 14:05:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LS7b46KcQz4TXR for ; Tue, 21 Jun 2022 14:05:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2c.google.com with SMTP id j6so5595862vsi.0 for ; Tue, 21 Jun 2022 07:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mzgOa7ktw6Bk9C4XOn/x0NI8aehAZaXZiHWnaQ+KAW4=; b=27xXqBZa/77HLWWgZj7wpDpYf5kag98mCM3cMVfm9iSyRpyJqOxwUtGX5EkFHJWqTw Xm1XwYIIwvwbr+FBSWkcbCI0cBLSi0V4iljAEJTYoI+efH88eDkF70V/EGeAfEZ1BJy4 G6cKegt7yVWl4V6fBG0o+Yqw3D4cwgCjMskl5p/Ah9o6W+LMA2Y4RhHHqvWtGwgCoAsx ZmU7fLEcxMnX91I+90xU9JtYx/zIv/mD2whu5xLv6swSE7AtgqYCeKXPWYtgNRRGh/8Z 1fuMAGoFNhsIClNg/kC3M5S9Gi+od1fM2sM64pIpvh9YcNX9/9RdWmI+O+Kfhe9otSH9 s2SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mzgOa7ktw6Bk9C4XOn/x0NI8aehAZaXZiHWnaQ+KAW4=; b=uQHW5i9fBSjtUqxZeXxw+oMpno78aI42zPP7uWd0/ir6PTWZI2P5DimZ51DvMCe+Cm A5VsxKJXE9jaS64PD0hRWLzCejwL/2mz8BTLFxpetJMxqiDQyKCOi2Q5PDYHdl4z9K74 hSUTLB9wfaCq7hA7dTzRvE1Gg+XW2O1IAvnrkvQ2Nw2O/WSOXMBaO+ARCyeO6jALKrIZ iTAlYnnYH6h5uM8zQdusbSEOA9aucMJGZ5MPm1k0xHLRfFLm4NPwAvt0sm82KO2ZNDCQ StYmQuPdmSopAZcDwphVSsXmZ4TMpBEkU90GHCFGeSF5GwglyAIM1v2k3nWqP7RJnQeC A28w== X-Gm-Message-State: AJIora8QiqQIkE3vDykw5Z9b0ICl+dzbDzv0uRxkoeP9dDdHpa7vNOIe Xt8N1BntMqemvr9h1PIZuinucNUmflew9e48iheWznq6p3Y= X-Google-Smtp-Source: AGRyM1uBGAkhzlUbYMG65V1Camb7uvxfrHquTMAQXovBaSiezJOoSnrmX5FvbcIsnM2PEQKyFLDPfIEVmbwKpWnfsUw= X-Received: by 2002:a05:6102:5716:b0:354:39ba:6ebf with SMTP id dg22-20020a056102571600b0035439ba6ebfmr3260327vsb.53.1655820351860; Tue, 21 Jun 2022 07:05:51 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 21 Jun 2022 08:05:40 -0600 Message-ID: Subject: Re: Updating reboot's default To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000e2846505e1f5b7ad" X-Rspamd-Queue-Id: 4LS7b46KcQz4TXR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=27xXqBZa; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.94)[-0.935]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2c:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000e2846505e1f5b7ad Content-Type: text/plain; charset="UTF-8" On Tue, Jun 21, 2022 at 8:01 AM Warner Losh wrote: > 15 or 20 years ago, we talked about changing the default for reboot from > 'right now' to being safe shutdown. There were arguments made against it > due to tiny appliances and such. > > Time has past, and this oddity has persisted. It's time to revisit that > decision. > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > behavior. However, the 'reboot' command will switch from '-q' behavior to > '-r' behavior. > > I'll update the man page, etc to reflect these new defaults. Most of the > systems I've been on in the last 10-15 years have had some flavor of 'alias > reboot reboot -r' in their login scripts and/or made shell scripts that did > this. This will match what everybody else is doing, and will likely result > in less astonishment rather than more, even though it changes a > long-standing default behavior. > > Comments? > I slightly misspoke here. I'm proposing we change the default to like 'shutodwn -r' not to re-root the system... Sorry for any confusion. Warner > > Warner > > --000000000000e2846505e1f5b7ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 21, 2022 at 8:01 AM Warne= r Losh <imp@bsdimp.com> wrote:<= br>
15 or 20 years ago, we talked about changing the default for reboot from &= #39;right now' to being safe shutdown. There were arguments made agains= t it due to tiny appliances and such.

Time has past,= and this oddity has persisted. It's time to revisit that decision.

I'd propose that we keep 'fastboot' and &= #39;fasthalt' having the immediate behavior. However, the 'reboot&#= 39; command will switch from '-q' behavior to '-r' behavior= .

I'll update the man page, etc to reflect the= se new defaults. Most of the systems I've been on in the last 10-15 yea= rs have had some flavor of 'alias reboot reboot -r' in their login = scripts and/or made shell scripts that did this. This will match what every= body else is doing, and will likely result in less astonishment rather than= more, even though it changes a long-standing default behavior.
<= br>
Comments?

I sligh= tly misspoke here. I'm proposing we change the default to like 'shu= todwn=C2=A0-r' not to re-root the system... Sorry for any confusion.

Warner

Warner

=
--000000000000e2846505e1f5b7ad-- From nobody Tue Jun 21 16:17:09 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2A112874CE4 for ; Tue, 21 Jun 2022 16:17:13 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSBVc1thTz4tft for ; Tue, 21 Jun 2022 16:17:12 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 25LGH9La053788; Tue, 21 Jun 2022 09:17:09 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 25LGH9sY053787; Tue, 21 Jun 2022 09:17:09 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202206211617.25LGH9sY053787@gndrsh.dnsmgr.net> Subject: Re: Updating reboot's default In-Reply-To: To: Warner Losh Date: Tue, 21 Jun 2022 09:17:09 -0700 (PDT) CC: "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4LSBVc1thTz4tft X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-1.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.00)[0.005]; MLMMJ_DEST(0.00)[freebsd-arch]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > 15 or 20 years ago, we talked about changing the default for reboot from > 'right now' to being safe shutdown. There were arguments made against it > due to tiny appliances and such. > > Time has past, and this oddity has persisted. It's time to revisit that > decision. > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > behavior. However, the 'reboot' command will switch from '-q' behavior to > '-r' behavior. > > I'll update the man page, etc to reflect these new defaults. Most of the > systems I've been on in the last 10-15 years have had some flavor of 'alias > reboot reboot -r' in their login scripts and/or made shell scripts that did > this. This will match what everybody else is doing, and will likely result > in less astonishment rather than more, even though it changes a > long-standing default behavior. > > Comments? > > Warner That isnt a reboot any more, that is a re-root, and I thought that re-root requires certain other things to be in place for it to work correctly, or perhaps I am mis-remebering that. Also doesnt this preserve a large amount of prior state? -- Rod Grimes rgrimes@freebsd.org From nobody Tue Jun 21 16:20:06 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 02DF287558E for ; Tue, 21 Jun 2022 16:19:53 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSBYh6Ymkz4vR9 for ; Tue, 21 Jun 2022 16:19:52 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655828392; 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=9VuQDPS1B/tHOFKD22B2COx4wFiF4mgSA6bRNWLcO6k=; b=RWZldbY8hGRNMMTACndmZQ1CjJIHuq0Sor5jDlARCgClN5VBqjwApCjyf2T1jnsvX6wC0S NBPqLAKa6OB8YD9gWUiRI5mOGZpCAg4qmW5hi6Cp9qjJkhZYsWa1ttcQL7NL5fYFmlj+gI Wio8ePAXzNGbVP37aVFPEI8Ok6GgUbgwySImJxB2Ei+4CDgTx21DfqAEqa0QcVeDuuwF0j r3F1zEDfd6xeDD3uQlnIWn+bCZgEOtH9KRv/RXeyfXx3KpWBTZnIHGDZtE8vdV5ZKhVxwO 7r1EyRU+NHMegGSt1qRt9abyQy1oTugHA7rXdCMkpExqwLREcUKZXRIFtX7Phw== Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id B927C6221 for ; Tue, 21 Jun 2022 16:19:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f50.google.com with SMTP id t24so10992983lfr.4 for ; Tue, 21 Jun 2022 09:19:52 -0700 (PDT) X-Gm-Message-State: AJIora9xwrdNFoyUMY9ztt5ay3JJJ8A6T2wSywUUsNNbT1YdBgbDISs+ JGZQ1a3NWjxr2cHnjA63BQ77AJmNHP1GWRl7QBg= X-Google-Smtp-Source: AGRyM1tcyncYEtLGt2GmS+mdkaOVsVk/c1BjrcPKVYkSaG57Y/Gc3kjhFZJoc/ee6Qyreq7LOxTqIeHxq0kjn0v+VmQ= X-Received: by 2002:a05:6512:3d08:b0:47f:79a9:66f0 with SMTP id d8-20020a0565123d0800b0047f79a966f0mr3641912lfv.576.1655828391322; Tue, 21 Jun 2022 09:19:51 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202206211617.25LGH9sY053787@gndrsh.dnsmgr.net> In-Reply-To: <202206211617.25LGH9sY053787@gndrsh.dnsmgr.net> From: Kyle Evans Date: Tue, 21 Jun 2022 09:20:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Updating reboot's default To: "Rodney W. Grimes" Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655828392; 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=9VuQDPS1B/tHOFKD22B2COx4wFiF4mgSA6bRNWLcO6k=; b=wyySEeEC50KOZJvYhxqjfmw1I/f5LiybnIVeNCdZjmUjbfExJuS7IaF1kvLig4ErLbmGQA GUYBOQnQB4h9tXlMG2We6iIQT3sGF6czbmxMYCx8IzEq1PhdiVrLRarMKtCyIDDxdvSI+x L5OqbqFDcgFSouGlbQXh2YzdQd9SricnPUvp5Aem+18owbfl8TuDnTJTobRKCVeH/Ht/ZU XmMKRVyl6kTO9j37oSUCoyZ40S4YgHRbP2acSOvhp2d0DN28e+zkVagH38xq535eq3DsQM kWJ4tmo0x03CQCpoNDjbuk5pf1Z08bHu2YgGpjc2/7PKM4Gp/3TGQJySzRgXrA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655828392; a=rsa-sha256; cv=none; b=d1TN6h4YsjJ1DG50gfylq/viatRI6pMk3PX4+goCO0PPYWcCOgPddxFXOdP7EOALuWWiJV 95YWsIiGnbQR9M8R1XW2Z754EovB4KEvWgFUtLYDHpDviYv5qe+XPg6LjzigFTP88H7HCX MVEwDcbOZl687f/M2oje7PjeLOhAiQEHC0MpJ4EB5VWE+aWR0IGaI2cMOoqoJ8pmkejvos dE4x/KAQWIaQBBLz/Gavk58/KRvCJeaDfcFBgbNyfC6cAbxMVSm4umQnCJkkuC3c9szjZe hT+LntfkLhdmCTx9XzHMnMR4ercoFEeg5Jgy6I0/z4QNVfqLm+lt4xr9OeTnjg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, Jun 21, 2022 at 9:17 AM Rodney W. Grimes wrote: > > > 15 or 20 years ago, we talked about changing the default for reboot from > > 'right now' to being safe shutdown. There were arguments made against it > > due to tiny appliances and such. > > > > Time has past, and this oddity has persisted. It's time to revisit that > > decision. > > > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > > behavior. However, the 'reboot' command will switch from '-q' behavior to > > '-r' behavior. > > > > I'll update the man page, etc to reflect these new defaults. Most of the > > systems I've been on in the last 10-15 years have had some flavor of 'alias > > reboot reboot -r' in their login scripts and/or made shell scripts that did > > this. This will match what everybody else is doing, and will likely result > > in less astonishment rather than more, even though it changes a > > long-standing default behavior. > > > > Comments? > > > > Warner > > That isnt a reboot any more, that is a re-root, and I thought > that re-root requires certain other things to be in place for it > to work correctly, or perhaps I am mis-remebering that. Also doesnt > this preserve a large amount of prior state? > Note a later correction -- he meant "shutdown -r", rather than re-root. From nobody Tue Jun 21 16:20:57 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 533DE87594F for ; Tue, 21 Jun 2022 16:21:06 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSBb53K4Bz3Bmj for ; Tue, 21 Jun 2022 16:21:05 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 25LGKvVG053810; Tue, 21 Jun 2022 09:20:57 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 25LGKvbN053809; Tue, 21 Jun 2022 09:20:57 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202206211620.25LGKvbN053809@gndrsh.dnsmgr.net> Subject: Re: Updating reboot's default In-Reply-To: To: Warner Losh Date: Tue, 21 Jun 2022 09:20:57 -0700 (PDT) CC: "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4LSBb53K4Bz3Bmj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-1.74 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.64)[-0.643]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N [ Charset UTF-8 unsupported, converting... ] > On Tue, Jun 21, 2022 at 8:01 AM Warner Losh wrote: > > > 15 or 20 years ago, we talked about changing the default for reboot from > > 'right now' to being safe shutdown. There were arguments made against it > > due to tiny appliances and such. > > > > Time has past, and this oddity has persisted. It's time to revisit that > > decision. > > > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > > behavior. However, the 'reboot' command will switch from '-q' behavior to > > '-r' behavior. > > > > I'll update the man page, etc to reflect these new defaults. Most of the > > systems I've been on in the last 10-15 years have had some flavor of 'alias > > reboot reboot -r' in their login scripts and/or made shell scripts that did > > this. This will match what everybody else is doing, and will likely result > > in less astonishment rather than more, even though it changes a > > long-standing default behavior. > > > > Comments? > > > > I slightly misspoke here. I'm proposing we change the default to like > 'shutodwn -r' not to re-root the system... Sorry for any confusion. Retract my prior objection based on reboot -r being a re-root. BUTT: shutdown -r requires an argument of "time" And what would the time be? aka if you alias reboot "shutdown -r", when I type reboot I'll end up getting a usage error. This is gona cause some confusion, perhaps you mean to alias reboot "shutdown -r now"? -- Rod Grimes rgrimes@freebsd.org From nobody Tue Jun 21 19:07:41 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9B58486EDDD for ; Tue, 21 Jun 2022 19:07:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSGHb5yrMz4b0Z for ; Tue, 21 Jun 2022 19:07:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2d.google.com with SMTP id e7so7533567vsp.13 for ; Tue, 21 Jun 2022 12:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wgSw/e01kgtwoU6ds54nCYtVR6dVEHZ/DZIXbEGJxio=; b=AtrK5ILmccUW4XKNUAwcLL+cLCzfOhrjS2sWA/2S/+571hF1g6hXF/hbUAVINwmc5y dfC8pZxBuZDFtXcRU5/2aNRTmnj3QITeSq5srRo7d2qvozA9dCLI8Ky7oD1arWhx1va1 +4A9N76Z7yMIt6CXQKZCDYCcdqCe3GKdRQSgId5gkV1hHsutdNxjcN/0sma4p6tNQ733 wj9bW2SyitmH738ZM7YUd/D8uisrrb9KMuVaJOwbvVWibqLeakEDbvQsvHnmP/EcHujO Zl7nFwTAR4rVOVc0qMonUgClSDMjq+rXtrZppLOHmGDMdjYLyCy4zcjQHw2SeDCTcMlT zfoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wgSw/e01kgtwoU6ds54nCYtVR6dVEHZ/DZIXbEGJxio=; b=awLW8smqPQniTYZcZaXrzswzVoNWnWB5ZqwaTm7e5afjrA5VrwsKFGVI6kFcdQu8j/ RfQSpz/vTw7UpDs4Eig7YEmwF4cH+bytjzalbQISr0+YCD8dRTOwt+6B1UPDjUznxva0 aCvLGF4gHi3xtFRi4rNQCo0HqURdumK7bKFSWAD0jcTbVWB9NcN6UvLDt0wEGOb8j6fT tfJsBP5sT3ePukBkqN9LxP6eC5TM251rOJuLWNAe2KLDxWPNBZaV5PEb47sucO2VVEql CLWJfrPzYqFyKrxXxVK/jHJvhOn4ERqReFbqb9y/g9KsxMAoA2Wm144o0I5QeWFBeX5s xolw== X-Gm-Message-State: AJIora+TfSW8alJ/XVKDD5FIpCRP8PW6Lx0pcPXxaInMIAu8/Hdk3A3T WOHVLg1T1NB5pKUEs38jR1Z8erqMepdyO1Eg29lTSkVOibw= X-Google-Smtp-Source: AGRyM1suIQj2FnHCGHnEnhQA8WU2FL4NCoZJMAF9Rl1GdiVItIi95pj+6FexhOjD/zMI9lULpr9LsfIJHe6jhd3Za2o= X-Received: by 2002:a05:6102:c4f:b0:351:938d:6863 with SMTP id y15-20020a0561020c4f00b00351938d6863mr11195899vss.12.1655838475220; Tue, 21 Jun 2022 12:07:55 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202206211620.25LGKvbN053809@gndrsh.dnsmgr.net> In-Reply-To: <202206211620.25LGKvbN053809@gndrsh.dnsmgr.net> From: Warner Losh Date: Tue, 21 Jun 2022 13:07:41 -0600 Message-ID: Subject: Re: Updating reboot's default To: "Rodney W. Grimes" Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000001f0f2405e1f9f081" X-Rspamd-Queue-Id: 4LSGHb5yrMz4b0Z X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=AtrK5ILm; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.09 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from]; NEURAL_HAM_SHORT(-0.09)[-0.088]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000001f0f2405e1f9f081 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 21, 2022, 10:20 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > [ Charset UTF-8 unsupported, converting... ] > > On Tue, Jun 21, 2022 at 8:01 AM Warner Losh wrote: > > > > > 15 or 20 years ago, we talked about changing the default for reboot > from > > > 'right now' to being safe shutdown. There were arguments made against > it > > > due to tiny appliances and such. > > > > > > Time has past, and this oddity has persisted. It's time to revisit that > > > decision. > > > > > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > > > behavior. However, the 'reboot' command will switch from '-q' behavior > to > > > '-r' behavior. > > > > > > I'll update the man page, etc to reflect these new defaults. Most of > the > > > systems I've been on in the last 10-15 years have had some flavor of > 'alias > > > reboot reboot -r' in their login scripts and/or made shell scripts > that did > > > this. This will match what everybody else is doing, and will likely > result > > > in less astonishment rather than more, even though it changes a > > > long-standing default behavior. > > > > > > Comments? > > > > > > > I slightly misspoke here. I'm proposing we change the default to like > > 'shutodwn -r' not to re-root the system... Sorry for any confusion. > > Retract my prior objection based on reboot -r being a re-root. > > BUTT: > shutdown -r requires an argument of "time" > And what would the time be? > > aka if you alias reboot "shutdown -r", when I type > reboot I'll end up getting a usage error. > This is gona cause some confusion, perhaps you > mean to alias reboot "shutdown -r now"? > Yes. It would signal init to start the shutdown right now. Warner -- > Rod Grimes > rgrimes@freebsd.org > --0000000000001f0f2405e1f9f081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2022, 10:20 AM Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.ne= t> wrote:
[ Charset UTF-8 un= supported, converting... ]
> On Tue, Jun 21, 2022 at 8:01 AM Warner Losh <imp@bsdimp.com> wro= te:
>
> > 15 or 20 years ago, we talked about changing the default for rebo= ot from
> > 'right now' to being safe shutdown. There were arguments = made against it
> > due to tiny appliances and such.
> >
> > Time has past, and this oddity has persisted. It's time to re= visit that
> > decision.
> >
> > I'd propose that we keep 'fastboot' and 'fasthalt= ' having the immediate
> > behavior. However, the 'reboot' command will switch from = '-q' behavior to
> > '-r' behavior.
> >
> > I'll update the man page, etc to reflect these new defaults. = Most of the
> > systems I've been on in the last 10-15 years have had some fl= avor of 'alias
> > reboot reboot -r' in their login scripts and/or made shell sc= ripts that did
> > this. This will match what everybody else is doing, and will like= ly result
> > in less astonishment rather than more, even though it changes a > > long-standing default behavior.
> >
> > Comments?
> >
>
> I slightly misspoke here. I'm proposing we change the default to l= ike
> 'shutodwn -r' not to re-root the system... Sorry for any confu= sion.

Retract my prior objection based on reboot -r being a re-root.

BUTT:
shutdown -r requires an argument of "time"
And what would the time be?

aka if you alias reboot "shutdown -r", when I type
reboot I'll end up getting a usage error.
This is gona cause some confusion, perhaps you
mean to alias reboot "shutdown -r now"?

Yes. It would signal init = to start the shutdown right now.

Warner=C2=A0

<= br>
--
Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org
--0000000000001f0f2405e1f9f081-- From nobody Wed Jun 22 00:35:43 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0B25A85BD41 for ; Wed, 22 Jun 2022 00:35:52 +0000 (UTC) (envelope-from grog@FreeBSD.org) Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSPYy09rPz4VFw; Wed, 22 Jun 2022 00:35:49 +0000 (UTC) (envelope-from grog@FreeBSD.org) Date: Wed, 22 Jun 2022 10:35:43 +1000 From: Greg 'groggy' Lehey To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Updating reboot's default Message-ID: <20220622003543.GE18075@eureka.lemis.com> References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NklN7DEeGtkPCoo3" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4LSPYy09rPz4VFw X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 121.200.11.253 is neither permitted nor denied by domain of grog@FreeBSD.org) smtp.mailfrom=grog@FreeBSD.org X-Spamd-Result: default: False [2.94 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.11)[-0.107]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; HAS_ORG_HEADER(0.00)[]; VIOLATED_DIRECT_SPF(3.50)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_SHORT(0.75)[0.752]; MLMMJ_DEST(0.00)[freebsd-arch]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:4764, ipnet:121.200.11.0/24, country:AU] X-ThisMailContainsUnwantedMimeParts: N --NklN7DEeGtkPCoo3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 21 June 2022 at 8:01:58 -0600, Warner Losh wrote: > 15 or 20 years ago, we talked about changing the default for reboot from > 'right now' to being safe shutdown. There were arguments made against it > due to tiny appliances and such. > > Time has past, and this oddity has persisted. It's time to revisit that > decision. > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > behavior. However, the 'reboot' command will switch from '-q' behavior to > '-r' behavior. Somehow I hear this echo "If it ain't broke, don't fix it". My understanding has always been that shutdown(8) is the program that shuts down and maybe reboots the system, while reboot(8) is a quick and dirty way to reboot the system, along with halt(8) if you don't want to reboot. So why change this? At the very least you'll confuse people who want to use the old method. My guess is that you have some reason that's not immediately apparent, but what? And no, I don't really have an axe to grind in this matter. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php --NklN7DEeGtkPCoo3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmKyY98ACgkQIubykFB6QiM6JQCgiLp4E8S0HrkJzTN+Kac0SS3B H5kAnjqnHEl3pogB/u2OMlvsRglgP2eT =llBY -----END PGP SIGNATURE----- --NklN7DEeGtkPCoo3-- From nobody Wed Jun 22 02:02:30 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 779548683B8 for ; Wed, 22 Jun 2022 02:02:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSRV971xTz4g3Z for ; Wed, 22 Jun 2022 02:02:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2e.google.com with SMTP id 63so590613vsv.10 for ; Tue, 21 Jun 2022 19:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0nDQN9TcK7VN0kPWNJ0tA93Ld44OO3aBQpASeje9WI8=; b=eakcKMk0k1EKD/hYDGN13Va6pEJX3t4ysdHNYocSWUQ7mkE9nx7424ulWezWI06X+r zpDlEg3d5UA2iIFKS22rSewTTTx4+5A0D1/5kDVY8mmLAbxfVJYU0l76ndhDJHreuIWu w954Td/NBcJhqUvQvXGp8S/MaR5cxlAe96XHcKkKaF11EU40vVRPfFfLjmtRwzkDG2x6 StR9hWIVL6owQQP2Ilk3UAXKS1kVrrZoycjnJ9WGgYk8w/iJnLegRe0hHuaDVOY+t2bC NoOnttY+vRqfoZp49p1vr+lcyuOcqNBSIXUau/V4onGidCRIirJtzI8CksiMgsdn2sFI w+RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0nDQN9TcK7VN0kPWNJ0tA93Ld44OO3aBQpASeje9WI8=; b=hxlhaK3HhMFsYqEBMjokDFJujthUcOYZoPPo0IAz+kmbaIV9xYHZTbplprBRsNU7Wx mpKk01g1s5VOylL0aHeExwH3l0v+8xklF/UNmJK3KhA2IEiCaZL9EIFYwRVKJ9TIvZeh fX3tWlG0F41+HaUUUi2o/Q26TZCGdeFYuiZUR9aBeD309pCtFnbdJBX4kBtVg5vL9kQ5 2PI0A5Qw+0zrYpV34BODd5uqTPavVBhV1BEjp+HTX0KzI95OJRbceRGxuAE9M55WCjs7 eL7oZyQqyftM7N7pRd3l2jGUopRovivrZt1hxqKDQOMDt2CKm27Jz4aP7wjb23INssj1 OMwg== X-Gm-Message-State: AJIora8bPR57RWaiLV/WlO5JKwtd6nlV3Jc37bQvMUu4NlPTmxU4LVg5 qG/oZRjgIIQjYW2Wi1Xf1bKZNTotph7po+yW95ILqA== X-Google-Smtp-Source: AGRyM1spCWtl2x+dB1KaIGKILnEVy0WXEaJZwS85iIO6yedv8IDqDOp3rKDe5o0gi069af7AwAeC04pF7gwUlBcqvR4= X-Received: by 2002:a67:cd90:0:b0:354:5028:f253 with SMTP id r16-20020a67cd90000000b003545028f253mr2635286vsl.6.1655863361369; Tue, 21 Jun 2022 19:02:41 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20220622003543.GE18075@eureka.lemis.com> In-Reply-To: <20220622003543.GE18075@eureka.lemis.com> From: Warner Losh Date: Tue, 21 Jun 2022 20:02:30 -0600 Message-ID: Subject: Re: Updating reboot's default To: "Greg 'groggy' Lehey" Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000738c5605e1ffbb3f" X-Rspamd-Queue-Id: 4LSRV971xTz4g3Z X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=eakcKMk0; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.29 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2e:from]; NEURAL_HAM_MEDIUM(-0.29)[-0.289]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000738c5605e1ffbb3f Content-Type: text/plain; charset="UTF-8" On Tue, Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey wrote: > On Tuesday, 21 June 2022 at 8:01:58 -0600, Warner Losh wrote: > > 15 or 20 years ago, we talked about changing the default for reboot from > > 'right now' to being safe shutdown. There were arguments made against it > > due to tiny appliances and such. > > > > Time has past, and this oddity has persisted. It's time to revisit that > > decision. > > > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > > behavior. However, the 'reboot' command will switch from '-q' behavior to > > '-r' behavior. > > Somehow I hear this echo "If it ain't broke, don't fix it". My > understanding has always been that shutdown(8) is the program that > shuts down and maybe reboots the system, while reboot(8) is a quick > and dirty way to reboot the system, along with halt(8) if you don't > want to reboot. > > So why change this? At the very least you'll confuse people who want > to use the old method. My guess is that you have some reason that's > not immediately apparent, but what? > Other systems have the behavior I'm advocating. We are the odd duck. This means we tend to violate POLA here. And there is no good reason to do this when fastboot is available. Nobody that advocated to keep this difference as useful the last time it came up still wants to advocate. Most people find the behavior annoying and only a vanishingly small minority of people like it. In fact, so far nobody has even asked to please not, let alone come up with a good reason to retain this behavior. So, I'm polling arch@ to see if anyone like that shows up. Warner And no, I don't really have an axe to grind in this matter. > > Greg > -- > Sent from my desktop computer. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php > --000000000000738c5605e1ffbb3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2022, 6:35 PM Greg 'groggy' Le= hey <grog@freebsd.org> wrote:=
On Tuesday, 21 June 2022 at=C2=A0 = 8:01:58 -0600, Warner Losh wrote:
> 15 or 20 years ago, we talked about changing the default for reboot fr= om
> 'right now' to being safe shutdown. There were arguments made = against it
> due to tiny appliances and such.
>
> Time has past, and this oddity has persisted. It's time to revisit= that
> decision.
>
> I'd propose that we keep 'fastboot' and 'fasthalt'= having the immediate
> behavior. However, the 'reboot' command will switch from '= -q' behavior to
> '-r' behavior.

Somehow I hear this echo "If it ain't broke, don't fix it"= ;.=C2=A0 My
understanding has always been that shutdown(8) is the program that
shuts down and maybe reboots the system, while reboot(8) is a quick
and dirty way to reboot the system, along with halt(8) if you don't
want to reboot.

So why change this?=C2=A0 At the very least you'll confuse people who w= ant
to use the old method.=C2=A0 My guess is that you have some reason that'= ;s
not immediately apparent, but what?

Other systems have the behavior I'm = advocating. We are the odd duck. This means we tend to violate POLA here. A= nd there is no good reason to do this when fastboot is available. Nobody th= at advocated to keep this difference as useful the last time it came up sti= ll wants to advocate. Most people find the behavior annoying and only a van= ishingly small minority of people like it. In fact, so far nobody has even = asked to please not, let alone come up with a good reason to retain this be= havior. So, I'm polling arch@ to see if anyone like that shows up.

Warner=C2=A0


And no, I don't really have an axe to grind in this matter.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.=C2=A0 If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.= php
--000000000000738c5605e1ffbb3f-- From nobody Wed Jun 22 07:03:35 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 51D79873A31 for ; Wed, 22 Jun 2022 07:03:46 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSZ9Y1BClz3s0T; Wed, 22 Jun 2022 07:03:45 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 12762c28; Wed, 22 Jun 2022 07:03:36 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id d5ead254 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 22 Jun 2022 07:03:36 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-6986E708-BC30-405F-A67C-32925770B633 Content-Transfer-Encoding: 7bit List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Updating reboot's default From: Michael Gmelin In-Reply-To: Date: Wed, 22 Jun 2022 09:03:35 +0200 Cc: Greg 'groggy' Lehey , Warner Losh , freebsd-arch@freebsd.org Message-Id: <546C53F4-E30F-4DAF-BE33-B1772A23ABAE@freebsd.org> References: To: Warner Losh X-Mailer: iPhone Mail (19E258) X-Rspamd-Queue-Id: 4LSZ9Y1BClz3s0T X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [1.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.87)[-0.867]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(0.97)[0.967]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-6986E708-BC30-405F-A67C-32925770B633 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 22. Jun 2022, at 04:03, Warner Losh wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Tue, Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey wrot= e: >> On Tuesday, 21 June 2022 at 8:01:58 -0600, Warner Losh wrote: >> > 15 or 20 years ago, we talked about changing the default for reboot fro= m >> > 'right now' to being safe shutdown. There were arguments made against i= t >> > due to tiny appliances and such. >> > >> > Time has past, and this oddity has persisted. It's time to revisit that= >> > decision. >> > >> > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate= >> > behavior. However, the 'reboot' command will switch from '-q' behavior t= o >> > '-r' behavior. >>=20 >> Somehow I hear this echo "If it ain't broke, don't fix it". My >> understanding has always been that shutdown(8) is the program that >> shuts down and maybe reboots the system, while reboot(8) is a quick >> and dirty way to reboot the system, along with halt(8) if you don't >> want to reboot. >>=20 >> So why change this? At the very least you'll confuse people who want >> to use the old method. My guess is that you have some reason that's >> not immediately apparent, but what? >=20 >=20 > Other systems have the behavior I'm advocating. We are the odd duck. This m= eans we tend to violate POLA here. And there is no good reason to do this wh= en fastboot is available. Nobody that advocated to keep this difference as u= seful the last time it came up still wants to advocate. Most people find the= behavior annoying and only a vanishingly small minority of people like it. I= n fact, so far nobody has even asked to please not, let alone come up with a= good reason to retain this behavior. So, I'm polling arch@ to see if anyone= like that shows up. >=20 Well, to be honest, I=E2=80=99m used to the current behavior and would prefe= r to keep it (POLA for existing users). I didn=E2=80=99t answer to advocate a= gainst the change as 1. I have no metric to counter your argument that this is a real problem for= people used to other OSes (neither how many people pick up FreeBSD in gener= al nor how many are unpleasantly surprised by how `reboot` works) 2. I will certainly be able to adapt and get used to the new behavior 3. Given the amount of change in the world right now, it=E2=80=99s a =E2=80=9C= pick your battles=E2=80=9D situation. There is and will be so much to suck u= p, arguing about this with someone who clearly put some thought into it seem= s like a waste of everybody=E2=80=99s time. Cheers Michael > Warner=20 >=20 >=20 >> And no, I don't really have an axe to grind in this matter. >>=20 >> Greg >> -- >> Sent from my desktop computer. >> See complete headers for address and phone numbers. >> This message is digitally signed. If your Microsoft mail program >> reports problems, please read http://lemis.com/broken-MUA.php --Apple-Mail-6986E708-BC30-405F-A67C-32925770B633 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 22. Jun 2022, at 04= :03, Warner Losh <imp@bsdimp.com> wrote:

=EF=BB=BF

=
On Tue,= Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey <grog@freebsd.org> wrote:
understanding has always been that shutdown(8) is the program that
shuts down and maybe reboots the system, while reboot(8) is a quick
and dirty way to reboot the system, along with halt(8) if you don't
want to reboot.

So why change this?  At the very least you'll confuse people who want to use the old method.  My guess is that you have some reason that's not immediately apparent, but what?

Other systems have the behavior I'm advoca= ting. We are the odd duck. This means we tend to violate POLA here. And ther= e is no good reason to do this when fastboot is available. Nobody that advoc= ated to keep this difference as useful the last time it came up still wants t= o advocate. Most people find the behavior annoying and only a vanishingly sm= all minority of people like it. In fact, so far nobody has even asked to ple= ase not, let alone come up with a good reason to retain this behavior. So, I= 'm polling arch@ to see if anyone like that shows up.


Well, to be honest, I= =E2=80=99m used to the current behavior and would prefer to keep it (POLA fo= r existing users). I didn=E2=80=99t answer to advocate against the change as=

1. I have no metric to counter your argument that t= his is a real problem for people used to other OSes (neither how many people= pick up FreeBSD in general nor how many are unpleasantly surprised by how `= reboot` works)
2. I will certainly be able to adapt and get used t= o the new behavior
3. Given the amount of change in the world righ= t now, it=E2=80=99s a =E2=80=9Cpick your battles=E2=80=9D situation. There i= s and will be so much to suck up, arguing about this with someone who clearl= y put some thought into it seems like a waste of everybody=E2=80=99s time.

Cheers
Michael

Warner 


=
And no, I don't really have an axe to grind in this matter.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.ph= p
= --Apple-Mail-6986E708-BC30-405F-A67C-32925770B633-- From nobody Wed Jun 22 17:12:14 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9F5D686678A for ; Wed, 22 Jun 2022 17:12:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSqgt002nz3D5P for ; Wed, 22 Jun 2022 17:12:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa29.google.com with SMTP id az35so715193vkb.0 for ; Wed, 22 Jun 2022 10:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OcZnmRCPIwPCXNkcBJLHsLOS+EH+jMYh8k3pd2DRMZM=; b=odEYqcP9mCatB9yYcu6Ms0OoyXCe0h5GamFUBulKq9ftcl172mHSDAjmVkRblqhSJB VkutQUgK8Ir6A5YiXWiO1wf0CNqXKPfH9X+QHyKVDFZB5eFHaMru1hMItIb1jtztNXiS t1L80lK5nVJfNH5LCJ21RD3/SyJr83iPVB8QAoHa79SKKqlfc1YGuuxzvnVThlDcJ2oy kYHfPwthxDg197JRxcO3GWz+rWz/Zp6pqAegTNBOwn7ve0Ql30dg03kQmQQwrp0q8mg8 56lpIZNLe+iyD5qiCm0+vmIt9hX6HLfkIX5qDjFZESGdQBSFZbNzuI/EBTonfrAgQjQ/ QXag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OcZnmRCPIwPCXNkcBJLHsLOS+EH+jMYh8k3pd2DRMZM=; b=oORtVhQUpH8XKQGWuUV01W2J6+5du6mXYchYItPJsU4sOqAj/w3F44aLGUUlSPOutW C7bb3GxgfAL6rSqFtmM/deEzBlI72QSqtdwpYKzJF2uvrC0Y1SabYs1j2H3CWhvmjIdp j6lMzJkn7oMz1NfjGyIrOGxR79Md/iSAAmFGnnuVBy0LLcs3Sx6DEmR1wQTNzBbub15E dMRta+XQWy5lXghmiIpWYyQbx2ndwNLC5dyQRD9ZKk3yrnGD6X+crgAP6YZ0CHWQRa4x W2zXIjM6Z6tJtkzGTTXFoBtW0zBfsVklQkiiIp5cHNCraxiL8xsqSpG1+u0qc3sNZng7 /n6Q== X-Gm-Message-State: AJIora8HMjHhkIFnQl2a7+fSUIebZYN3PHExLngz3zgNAIrihgeL8P7h NQNsRKEADJswesASgkZJEUuqHBRYOphSNf9UNO2UBqWqMsE= X-Google-Smtp-Source: AGRyM1tJOpDGlrr+zvraW6HeQk/SSv5abRPQnCrr3DXFLKMGOsfFPtd0s1+XGq3VSYtgRcFTBrSdrjT+sj+JZyi6uU8= X-Received: by 2002:ac5:cb56:0:b0:35d:f905:e98a with SMTP id s22-20020ac5cb56000000b0035df905e98amr15405549vkl.29.1655917945266; Wed, 22 Jun 2022 10:12:25 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <546C53F4-E30F-4DAF-BE33-B1772A23ABAE@freebsd.org> In-Reply-To: <546C53F4-E30F-4DAF-BE33-B1772A23ABAE@freebsd.org> From: Warner Losh Date: Wed, 22 Jun 2022 11:12:14 -0600 Message-ID: Subject: Re: Updating reboot's default To: Michael Gmelin Cc: "Greg 'groggy' Lehey" , Warner Losh , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000e7bd5e05e20c709e" X-Rspamd-Queue-Id: 4LSqgt002nz3D5P X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=odEYqcP9; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a29) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.94 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.95)[-0.952]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a29:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000e7bd5e05e20c709e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 22, 2022 at 1:03 AM Michael Gmelin wrote: > > > On 22. Jun 2022, at 04:03, Warner Losh wrote: > > =EF=BB=BF > > > On Tue, Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey > wrote: > >> On Tuesday, 21 June 2022 at 8:01:58 -0600, Warner Losh wrote: >> > 15 or 20 years ago, we talked about changing the default for reboot fr= om >> > 'right now' to being safe shutdown. There were arguments made against = it >> > due to tiny appliances and such. >> > >> > Time has past, and this oddity has persisted. It's time to revisit tha= t >> > decision. >> > >> > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediat= e >> > behavior. However, the 'reboot' command will switch from '-q' behavior >> to >> > '-r' behavior. >> >> Somehow I hear this echo "If it ain't broke, don't fix it". My >> understanding has always been that shutdown(8) is the program that >> shuts down and maybe reboots the system, while reboot(8) is a quick >> and dirty way to reboot the system, along with halt(8) if you don't >> want to reboot. >> >> So why change this? At the very least you'll confuse people who want >> to use the old method. My guess is that you have some reason that's >> not immediately apparent, but what? >> > > Other systems have the behavior I'm advocating. We are the odd duck. This > means we tend to violate POLA here. And there is no good reason to do thi= s > when fastboot is available. Nobody that advocated to keep this difference > as useful the last time it came up still wants to advocate. Most people > find the behavior annoying and only a vanishingly small minority of peopl= e > like it. In fact, so far nobody has even asked to please not, let alone > come up with a good reason to retain this behavior. So, I'm polling arch@ > to see if anyone like that shows up. > > > Well, to be honest, I=E2=80=99m used to the current behavior and would pr= efer to > keep it (POLA for existing users). I didn=E2=80=99t answer to advocate ag= ainst the > change as > > 1. I have no metric to counter your argument that this is a real problem > for people used to other OSes (neither how many people pick up FreeBSD in > general nor how many are unpleasantly surprised by how `reboot` works) > 2. I will certainly be able to adapt and get used to the new behavior > 3. Given the amount of change in the world right now, it=E2=80=99s a =E2= =80=9Cpick your > battles=E2=80=9D situation. There is and will be so much to suck up, argu= ing about > this with someone who clearly put some thought into it seems like a waste > of everybody=E2=80=99s time. > I posted so I could understand other views, so I'd like to ask some questions if I may. Is your reliance on the current default due to shell and similar scripts you have? Or is it due to your interactive operations? What do you like about the current behavior: How quickly the reboot happens? Or you have a lot of running processes you don't want killed or to have a chance to clean up? What build process do you use to create your FreeBSD images? Images from the RE, buildworld, nanobsd, poudriere, etc... The only thought I've put into this is from my perspective, and while it is often a good reflection of the larger community, there are times there's a mismatch, so I'd like to at least understand why you hold these views. There may be a simple way to accommodate both sides. Warner > Cheers > Michael > > Warner > > > And no, I don't really have an axe to grind in this matter. >> >> Greg >> -- >> Sent from my desktop computer. >> See complete headers for address and phone numbers. >> This message is digitally signed. If your Microsoft mail program >> reports problems, please read http://lemis.com/broken-MUA.php >> > --000000000000e7bd5e05e20c709e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 22, 2022 at 1:03 AM Micha= el Gmelin <grembo@freebsd.org&= gt; wrote:


On 22. Jun 2022, at 04:03, Warner Losh &= lt;imp@bsdimp.com&g= t; wrote:

=EF=BB=BF


On Tue, Jun 21, 2022, 6:35 PM Greg 'g= roggy' Lehey <= grog@freebsd.org> wrote:
On Tuesday, 21 June 2022 at=C2=A0 8:01:58 -0600, Warner Los= h wrote:
> 15 or 20 years ago, we talked about changing the default for reboot fr= om
> 'right now' to being safe shutdown. There were arguments made = against it
> due to tiny appliances and such.
>
> Time has past, and this oddity has persisted. It's time to revisit= that
> decision.
>
> I'd propose that we keep 'fastboot' and 'fasthalt'= having the immediate
> behavior. However, the 'reboot' command will switch from '= -q' behavior to
> '-r' behavior.

Somehow I hear this echo "If it ain't broke, don't fix it"= ;.=C2=A0 My
understanding has always been that shutdown(8) is the program that
shuts down and maybe reboots the system, while reboot(8) is a quick
and dirty way to reboot the system, along with halt(8) if you don't
want to reboot.

So why change this?=C2=A0 At the very least you'll confuse people who w= ant
to use the old method.=C2=A0 My guess is that you have some reason that'= ;s
not immediately apparent, but what?

Other systems have the behavior I'm = advocating. We are the odd duck. This means we tend to violate POLA here. A= nd there is no good reason to do this when fastboot is available. Nobody th= at advocated to keep this difference as useful the last time it came up sti= ll wants to advocate. Most people find the behavior annoying and only a van= ishingly small minority of people like it. In fact, so far nobody has even = asked to please not, let alone come up with a good reason to retain this be= havior. So, I'm polling arch@ to see if anyone like that shows up.


W= ell, to be honest, I=E2=80=99m used to the current behavior and would prefe= r to keep it (POLA for existing users). I didn=E2=80=99t answer to advocate= against the change as

1. I have no metric to coun= ter your argument that this is a real problem for people used to other OSes= (neither how many people pick up FreeBSD in general nor how many are unple= asantly surprised by how `reboot` works)
2. I will certainly be a= ble to adapt and get used to the new behavior
3. Given the amount= of change in the world right now, it=E2=80=99s a =E2=80=9Cpick your battle= s=E2=80=9D situation. There is and will be so much to suck up, arguing abou= t this with someone who clearly put some thought into it seems like a waste= of everybody=E2=80=99s time.

I= posted so I could understand other views, so I'd like to ask some ques= tions if I may.

Is your reliance on the current de= fault due to shell and similar scripts you have? Or is it due to your inter= active operations?
What do you like about the current behavior: H= ow quickly the reboot happens? Or you have a lot of running processes you d= on't want killed or to have a chance to clean up?
What build = process do you use to create your FreeBSD images? Images from the RE, build= world, nanobsd, poudriere, etc...

The only thought= I've put into this is from my perspective, and while it is often a goo= d reflection of the larger community, there are times there's a mismatc= h, so I'd like to at least understand why you hold these views. There m= ay be a simple way to accommodate=C2=A0both sides.

Warner
=C2=A0
Cheers
Michael

War= ner=C2=A0


And no, I don't really have an axe to grind in this matter.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.=C2=A0 If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.= php
--000000000000e7bd5e05e20c709e-- From nobody Wed Jun 22 17:22:04 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 67BE286775D for ; Wed, 22 Jun 2022 17:22:09 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSqv40Zcsz3DwF; Wed, 22 Jun 2022 17:22:08 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 5241f6f1; Wed, 22 Jun 2022 17:22:05 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 9db16b06 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 22 Jun 2022 17:22:05 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-F8A4AB9A-15A8-449D-BA70-5050D931D38D Content-Transfer-Encoding: 7bit List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Updating reboot's default From: Michael Gmelin In-Reply-To: Date: Wed, 22 Jun 2022 19:22:04 +0200 Cc: Greg 'groggy' Lehey , Warner Losh , freebsd-arch@freebsd.org Message-Id: <59503878-4DF2-49B7-AF40-A3AA506889DA@freebsd.org> References: To: Warner Losh X-Mailer: iPhone Mail (19E258) X-Rspamd-Queue-Id: 4LSqv40Zcsz3DwF X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [2.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; NEURAL_SPAM_SHORT(0.61)[0.605]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(1.00)[0.998]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.70)[0.697]; MLMMJ_DEST(0.00)[freebsd-arch]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-F8A4AB9A-15A8-449D-BA70-5050D931D38D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 22. Jun 2022, at 19:12, Warner Losh wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Wed, Jun 22, 2022 at 1:03 AM Michael Gmelin wrote= : >>=20 >>=20 >>>> On 22. Jun 2022, at 04:03, Warner Losh wrote: >>>>=20 >>> =EF=BB=BF >>>=20 >>>=20 >>>> On Tue, Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey wr= ote: >>>> On Tuesday, 21 June 2022 at 8:01:58 -0600, Warner Losh wrote: >>>> > 15 or 20 years ago, we talked about changing the default for reboot f= rom >>>> > 'right now' to being safe shutdown. There were arguments made against= it >>>> > due to tiny appliances and such. >>>> > >>>> > Time has past, and this oddity has persisted. It's time to revisit th= at >>>> > decision. >>>> > >>>> > I'd propose that we keep 'fastboot' and 'fasthalt' having the immedia= te >>>> > behavior. However, the 'reboot' command will switch from '-q' behavio= r to >>>> > '-r' behavior. >>>>=20 >>>> Somehow I hear this echo "If it ain't broke, don't fix it". My >>>> understanding has always been that shutdown(8) is the program that >>>> shuts down and maybe reboots the system, while reboot(8) is a quick >>>> and dirty way to reboot the system, along with halt(8) if you don't >>>> want to reboot. >>>>=20 >>>> So why change this? At the very least you'll confuse people who want >>>> to use the old method. My guess is that you have some reason that's >>>> not immediately apparent, but what? >>>=20 >>>=20 >>> Other systems have the behavior I'm advocating. We are the odd duck. Thi= s means we tend to violate POLA here. And there is no good reason to do this= when fastboot is available. Nobody that advocated to keep this difference a= s useful the last time it came up still wants to advocate. Most people find t= he behavior annoying and only a vanishingly small minority of people like it= . In fact, so far nobody has even asked to please not, let alone come up wit= h a good reason to retain this behavior. So, I'm polling arch@ to see if any= one like that shows up. >>>=20 >>=20 >> Well, to be honest, I=E2=80=99m used to the current behavior and would pr= efer to keep it (POLA for existing users). I didn=E2=80=99t answer to advoca= te against the change as >>=20 >> 1. I have no metric to counter your argument that this is a real problem f= or people used to other OSes (neither how many people pick up FreeBSD in gen= eral nor how many are unpleasantly surprised by how `reboot` works) >> 2. I will certainly be able to adapt and get used to the new behavior >> 3. Given the amount of change in the world right now, it=E2=80=99s a =E2=80= =9Cpick your battles=E2=80=9D situation. There is and will be so much to suc= k up, arguing about this with someone who clearly put some thought into it s= eems like a waste of everybody=E2=80=99s time. >=20 > I posted so I could understand other views, so I'd like to ask some questi= ons if I may. >=20 > Is your reliance on the current default due to shell and similar scripts y= ou have? Or is it due to your interactive operations? Interactive operation, my playbooks/automation use clean reboot (shutdown -r= ). > What do you like about the current behavior: How quickly the reboot happen= s? Or you have a lot of running processes you don't want killed or to have a= chance to clean up? Both > What build process do you use to create your FreeBSD images? Images from t= he RE, buildworld, nanobsd, poudriere, etc... >=20 Official release & buildworld & poudriere & packer > The only thought I've put into this is from my perspective, and while it i= s often a good reflection of the larger community, there are times there's a= mismatch, so I'd like to at least understand why you hold these views. Ther= e may be a simple way to accommodate both sides. >=20 For me this is almost solely about muscle memory. If changing it serves the m= any, I can adapt and start using `fastboot` again (which I used for many yea= rs, until I realized that `reboot` did exactly the same) If we were redoing things from scratch, what you propose would make more sen= se than the current behavior for sure. Cheers Michael > Warner > =20 >> Cheers >> Michael >>=20 >>> Warner=20 >>>=20 >>>=20 >>>> And no, I don't really have an axe to grind in this matter. >>>>=20 >>>> Greg >>>> -- >>>> Sent from my desktop computer. >>>> See complete headers for address and phone numbers. >>>> This message is digitally signed. If your Microsoft mail program >>>> reports problems, please read http://lemis.com/broken-MUA.php --Apple-Mail-F8A4AB9A-15A8-449D-BA70-5050D931D38D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 22. Jun 2022, at 19= :12, Warner Losh <imp@bsdimp.com> wrote:

=EF=BB=BF


On Wed, Jun 22, 2022 at 1:03 AM Michael Gmelin <grembo@freebsd.org> wrote:


On 22. Jun 2022, at 04:03, Warner Losh <imp@bsdimp.com> wrote:

=
=EF=BB=BF
<= br>
On T= ue, Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey <grog@freebsd.org> wrote:
On Tuesday, 21 June 2022 at  8= :01:58 -0600, Warner Losh wrote:
> 15 or 20 years ago, we talked about changing the default for reboot fro= m
> 'right now' to being safe shutdown. There were arguments made against i= t
> due to tiny appliances and such.
>
> Time has past, and this oddity has persisted. It's time to revisit that=
> decision.
>
> I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate=
> behavior. However, the 'reboot' command will switch from '-q' behavior t= o
> '-r' behavior.

Somehow I hear this echo "If it ain't broke, don't fix it".  My
understanding has always been that shutdown(8) is the program that
shuts down and maybe reboots the system, while reboot(8) is a quick
and dirty way to reboot the system, along with halt(8) if you don't
want to reboot.

So why change this?  At the very least you'll confuse people who want to use the old method.  My guess is that you have some reason that's not immediately apparent, but what?

Other systems have the behavior I'm advoca= ting. We are the odd duck. This means we tend to violate POLA here. And ther= e is no good reason to do this when fastboot is available. Nobody that advoc= ated to keep this difference as useful the last time it came up still wants t= o advocate. Most people find the behavior annoying and only a vanishingly sm= all minority of people like it. In fact, so far nobody has even asked to ple= ase not, let alone come up with a good reason to retain this behavior. So, I= 'm polling arch@ to see if anyone like that shows up.


Well, to be honest, I= =E2=80=99m used to the current behavior and would prefer to keep it (POLA fo= r existing users). I didn=E2=80=99t answer to advocate against the change as=

1. I have no metric to counter your argument that t= his is a real problem for people used to other OSes (neither how many people= pick up FreeBSD in general nor how many are unpleasantly surprised by how `= reboot` works)
2. I will certainly be able to adapt and get used t= o the new behavior
3. Given the amount of change in the world righ= t now, it=E2=80=99s a =E2=80=9Cpick your battles=E2=80=9D situation. There i= s and will be so much to suck up, arguing about this with someone who clearl= y put some thought into it seems like a waste of everybody=E2=80=99s time.

I posted so I could understand ot= her views, so I'd like to ask some questions if I may.

<= div>Is your reliance on the current default due to shell and similar scripts= you have? Or is it due to your interactive operations?

Interactive operation, my playbooks/auto= mation use clean reboot (shutdown -r).


What do you like about the current behavior: How quickly the reboot happe= ns? Or you have a lot of running processes you don't want killed or to have a= chance to clean up?

Both

What build process do you use to c= reate your FreeBSD images? Images from the RE, buildworld, nanobsd, poudrier= e, etc...


=
Official release & buildworld & poudriere & packer


=
The only thought I've put into this is from m= y perspective, and while it is often a good reflection of the larger communi= ty, there are times there's a mismatch, so I'd like to at least understand w= hy you hold these views. There may be a simple way to accommodate both s= ides.


For me this is almost solely about muscle memory. If changing it serves the= many, I can adapt and start using `fastboot` again (which I used for many y= ears, until I realized that `reboot` did exactly the same)

If we were redoing things from scratch, what you propose would make m= ore sense than the current behavior for sure.

Cheer= s
Michael


Warner
=
 
Cheers
Michael

Warner 


And no, I don't really have an axe to grind in this matter.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.ph= p
= --Apple-Mail-F8A4AB9A-15A8-449D-BA70-5050D931D38D-- From nobody Wed Jun 22 19:39:40 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1927885A5AC for ; Wed, 22 Jun 2022 19:39:52 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail-out.smeets.xyz (mail-out.smeets.xyz [IPv6:2a01:4f8:10a:3543:ffff:0:25:11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LStxz01WZz3kZh for ; Wed, 22 Jun 2022 19:39:50 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail.smeets.xyz (mail.smeets.xyz [IPv6:2a01:4f8:10a:3543::25:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail-out.smeets.xyz (Postfix) with ESMTPS id 2075D8E15B; Wed, 22 Jun 2022 21:39:42 +0200 (CEST) Received: from amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) by mail.smeets.xyz (Postfix) with ESMTP id 1020C5C5C; Wed, 22 Jun 2022 21:39:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.xyz Received: from mail.smeets.xyz ([IPv6:2a01:4f8:10a:3543::25:3]) by amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) (amavisd-new, port 10025) with ESMTP id a-F2JcNkeTha; Wed, 22 Jun 2022 21:39:41 +0200 (CEST) Received: from [IPV6:2003:cf:df2f:cb93:e04f:17db:9cdf:c4bc] (p2003000633171a93e04f17db9cdfc4bc.dip0.t-ipconnect.de [IPv6:2003:6:3317:1a93:e04f:17db:9cdf:c4bc]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.smeets.xyz (Postfix) with ESMTPSA id 3A0A05C5B; Wed, 22 Jun 2022 21:39:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smeets.xyz; s=dkim; t=1655926781; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bEaBisjlQcfqeQBWKej1+97eoIryizEb9pjVQNZHqsk=; b=hMOwZ4szY0shSBGr4l5sp9y1a1q5TgTp4Sg7gh4lNMOIgECOWRkZZ2770Dk2+91QkUJyJT CNJRZYQvnLsH0sWJJgndLJbvh9lkx+nYZV91yQ+3GLgpgiUC+4CgE7word5zKRoPN6yshU Ms0J/n5CVA1ZMdACIcr4sPz6ZlUzLn3cHCf7+uAEvy7tFByKExP3cET7JDDnItHmKB9RBZ IFvH2K+LT4HZtEHgi00+8PQoUnqsASwQjFm0P++nEHvuki2y3d2pHMFvJvohrIstLytNYQ huLrTkf0C8kgXfkIReGnTJK6PrJrUNQuXC32vnHGzDKGb+C162SBGL7nAEPkTg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=smeets.xyz; s=ed25519_2022; t=1655926781; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bEaBisjlQcfqeQBWKej1+97eoIryizEb9pjVQNZHqsk=; b=VokwzYSJUUNkxaM6pJ8xtVtWROj1s8QFjxOioqfyFgPfMnNfqiWEfzh4+teME9JCYnO4Qa ilmkAOL2K9V0cMBw== Message-ID: <9ebd7e71-715a-90bc-bd11-13ef369d4f26@smeets.xyz> Date: Wed, 22 Jun 2022 21:39:40 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0 Content-Language: en-US To: Warner Losh , "freebsd-arch@freebsd.org" References: From: Florian Smeets Subject: Re: Updating reboot's default In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------34uTbTaG9WLEwn3yVqBtZ6VQ" X-Rspamd-Queue-Id: 4LStxz01WZz3kZh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smeets.xyz header.s=dkim header.b=hMOwZ4sz; dkim=pass header.d=smeets.xyz header.s=ed25519_2022 header.b=VokwzYSJ; dmarc=pass (policy=reject) header.from=smeets.xyz; spf=pass (mx1.freebsd.org: domain of flo@smeets.xyz designates 2a01:4f8:10a:3543:ffff:0:25:11 as permitted sender) smtp.mailfrom=flo@smeets.xyz X-Spamd-Result: default: False [-3.53 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[smeets.xyz:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[smeets.xyz,reject]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[flo]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(-0.20)[smeets.xyz:s=dkim,smeets.xyz:s=ed25519_2022]; NEURAL_SPAM_SHORT(0.47)[0.472]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------34uTbTaG9WLEwn3yVqBtZ6VQ Content-Type: multipart/mixed; boundary="------------2Jq0BpRoWEzTYti1ZT8kHuG0"; protected-headers="v1" From: Florian Smeets To: Warner Losh , "freebsd-arch@freebsd.org" Message-ID: <9ebd7e71-715a-90bc-bd11-13ef369d4f26@smeets.xyz> Subject: Re: Updating reboot's default References: In-Reply-To: --------------2Jq0BpRoWEzTYti1ZT8kHuG0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjEuMDYuMjIgMTY6MDEsIFdhcm5lciBMb3NoIHdyb3RlOg0KPiAxNSBvciAyMCB5ZWFy cyBhZ28sIHdlIHRhbGtlZCBhYm91dCBjaGFuZ2luZyB0aGUgZGVmYXVsdCBmb3IgcmVib290 IGZyb20gDQo+ICdyaWdodCBub3cnIHRvIGJlaW5nIHNhZmUgc2h1dGRvd24uIFRoZXJlIHdl cmUgYXJndW1lbnRzIG1hZGUgYWdhaW5zdCBpdCANCj4gZHVlIHRvIHRpbnkgYXBwbGlhbmNl cyBhbmQgc3VjaC4NCj4gDQoNCj4gDQo+IENvbW1lbnRzPw0KDQpZZXMsIHBsZWFzZSENCg0K SSd2ZSBiZWVuIGluIHRoZSBjYW1wIHRoYXQgcmVib290IHNob3VsZCBiZSAnc2h1dGRvd24g LXIgbm93JyBmb3IgYSB2ZXJ5IA0KbG9uZyB0aW1lLg0KDQpJZiB5b3UgbG9vayBhdCB0aGlz IHR3aXR0ZXIgdGhyZWFkIGZyb20gYWJvdXQgYSB5ZWFyIGFnbywgdGhlcmUgYXJlIGEgDQpj b3VwbGUgb2YgZXhwZXJpZW5jZWQgRnJlZUJTRCB1c2VycyBhbmQgY29tbWl0dGVycyBpbiB0 aGVyZSB0aGF0IGRpZG4ndCANCmtub3cgdGhlIGRpZmZlcmVuY2UuIA0KaHR0cHM6Ly90d2l0 dGVyLmNvbS9ETGFuZ2lsbGUvc3RhdHVzLzE0MzA5MTQwMzA0MjA1OTg3ODQNCg0KUGVyc29u YWxseSBJJ3ZlIGhhZCB0byByZXN0b3JlIGRhdGFiYXNlcyBtb3JlIHRoYW4gb25jZSBiZWNh dXNlIHNvbWVvbmUgDQp1c2VkIHJlYm9vdCBhbmQgdGhlIGRhdGFiYXNlIHdhcyB0aG9yb3Vn aGx5IGNvcnJ1cHRlZCBhbmQgY291bGRuJ3QgDQpyZWNvdmVyIG9uIGl0cyBvd24uDQoNCkZs b3JpYW4NCg== --------------2Jq0BpRoWEzTYti1ZT8kHuG0-- --------------34uTbTaG9WLEwn3yVqBtZ6VQ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmKzb/wFAwAAAAAACgkQ71uk3NWp88Cx HA//X0rPR2bJlgK8Q6bo3dKcnebI515+neaOsL5TH9Dts7fgL6ZtdYFi8KW8ooUSXuF22UFEUh2N 8a36VieOHfOBSHPSSNcoAgGT7omgc3lGZCv+TkDDWQbJGkHVq7OV+OOs/Lj82uQ1fqivpapPstCP PJG+CAt12QoNhD/I5ySkS1LxZMEN/gqh/XE41BOSN+Euo+65FtJCAOTlTizsIHaOm8ZhKf+HGrcS c9LoCszyNNcbv7WDdbLjqlRVdpWIetY0u1fJYsjHi52IoDociqo9vo9wGFNA41CTZwif6ox6Hd5N kN/pm/bER2zdU1ruYEnu4gyOlWvibvJsNXrHuppfK0NIqMXro2shkWirJQUIF1InQxf3XJKBDXHu uRZH007PgKxvf2M7V6qe9ytlAEprSrboV6LB/v2AwapXFPoItQogk/Gi9e4Pn4m1SQGMDdE6UhfA DUIRwuTuR2bakvRQW/ZqWOEmD3+5Xl/3SznsXnDUdOxJ+AuCcI0JeVekZhFS1DMMHcfedyaFAulo 0pCLPd4ziYo/J2t/tGMaNZNuCdAQrNbwqNWTL0vAeZ6mzW3HuoRVVjGPehABFaXRU63bRzM9eIMF kAgY7AJLPKirrHOy0/duin9WtO39U0A2aMfDiuh0JAicYpCtdRTHLuItqfBxmZAFuEX+qr5bH91b 1Mk= =kdmG -----END PGP SIGNATURE----- --------------34uTbTaG9WLEwn3yVqBtZ6VQ-- From nobody Thu Jun 23 08:33:30 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 039CF863759 for ; Thu, 23 Jun 2022 08:33:33 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTD6h6WNYz3CXg for ; Thu, 23 Jun 2022 08:33:32 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655973212; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2bp3xX+Gf45FbCUPZgnJTNpRyFgajVS2XvLNexeuH1c=; b=FsxLVwhCHy6lPKEEJ+c4svrautiFDMTeCPa/W8NS+i/e2nG74QosqNn21ulTzx+a0epsD/ vby4UGyOAr0mjemLI4Yh99FWZDbBQMHcJfOw4mVR3BS8CJh+VWTT9maN/Ha+96j1W1d5EG 87QL9GY3m7fkdsTaI2YDRl2iAESrAu6W/MbRqrWY1MJv95S/IRN2u3ItLGzbSZJZABzKwf 8gTNOylnmLo5mWUm37i7JKkdGAwYjoDoBavZOz0MYE7LFaBxDq1doElxtx7ZE4Cfr4fV+6 7iXmwfOviRRbxFQHPk90rzwo+M/G8XIqK6QcOGLofTBsIojbzND9L2hLNxlpqA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id BD1B91A538; Thu, 23 Jun 2022 08:33:32 +0000 (UTC) Date: Thu, 23 Jun 2022 10:33:30 +0200 From: Daniel Ebdrup Jensen To: freebsd-arch@freebsd.org Subject: Re: Updating reboot's default Message-ID: <20220623083330.ado2tzlikuyqy5pa@geroi.local> References: <59503878-4DF2-49B7-AF40-A3AA506889DA@freebsd.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ya4iyqp37ie2vyz4" Content-Disposition: inline In-Reply-To: <59503878-4DF2-49B7-AF40-A3AA506889DA@freebsd.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655973212; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2bp3xX+Gf45FbCUPZgnJTNpRyFgajVS2XvLNexeuH1c=; b=i+B+HywrFC2IOsr83ZnIIe7IiDBHovh2zrwRHscRyPdJYeI1IpcfbUmUQzbRz/m8NcFPWA XSq8DJVWC2E2ghuG4XC0s2+rq/uX8xXVygnL/o9MQBKOn9O9zR+8DyCEvTCUmjh+DRNoZi YMh7GchU7Gujj4nlAv0PP4eu35EWk37xmcntgt1RIeBItZWlRJhLa0ZfgOVZSgh5JnBZON 1zX4B8yeGkDR+kB5EFwThDVArMc4UBDCBrFgm9ttLu7wPRVKMj+8RDrwhRGNPmsDxCo9sM Twpc3trWmWiWkC8rg1NvjG/HPIKp2p1M11u+s6Jq65Kme3f9ZlTEVcJIXohGdQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655973212; a=rsa-sha256; cv=none; b=LecSXli9V3wkmJmApdy8ovtOoDJvpKpem2ZGsWGjYeRMKFgoDM+jjiJPC4Xsj5GGHdBV3X tD3ICsNOOeQIkwr2tuYYH142h8WynPqTXxtjcsw+eioOinePjMtT3TzXB4kcKRX6ydhq6W UB3rsz/pbPzqlQCzmlebzSwH0uFPy3UJ3/Rw9mksqbVHPKuT10z/wFJtv5GElBXsCZOF2Z RCyB8fWriTUKH0aIAygm5LXmZbiG0GnHKvQdnxSeFrx+O1vLQJBUnaPeKp/D9HfcOYqU0y T3R3xnZhrx4A84gOQqOMrhRfU0utGETRkhHoWxlDjiwsVk8lGMFdmQ0wrSmkuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --ya4iyqp37ie2vyz4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Wed, Jun 22, 2022 at 07:22:04PM +0200, Michael Gmelin wrote: >> On 22. Jun 2022, at 19:12, Warner Losh wrote: >> What do you like about the current behavior: How quickly the reboot happens? Or you have a lot of running processes you don't want killed or to have a chance to clean up? > >Both I'm curious about this one, because to me reboot has always been there to help in cases where a machine needs to be rebooted _right now_, irrespective of what it's doing, up to and including possibly corrupting various databases that might need more than 5 seconds to finish their work. It seems to me that those things only come about in the case of imminent hardware failure, zero-day exploits against high-value targets, and things of that nature that are otherwise unavoidable, and that're covered by the same clauses that cover force majure in service license agreements about any number of nines. Out of interest, how much quicker is the current reboot compared to shutdown -r? If you have any numbers to share, that'd certainly have my interest. >> The only thought I've put into this is from my perspective, and while it is often a good reflection of the larger community, there are times there's a mismatch, so I'd like to at least understand why you hold these views. There may be a simple way to accommodate both sides. >> > >For me this is almost solely about muscle memory. If changing it serves the many, I can adapt and start using `fastboot` again (which I used for many years, until I realized that `reboot` did exactly the same) As Warner highlights elsewhere, most people have had to alias reboot to `shutdown -r now` - up to and including for system processes. It seems to me that this change would mean that the few people like you who want the behaviour will now have to do this? For example, the x11/ly display manager I'm using lets you pick the command to shut down the system, but it's hardcoding the command to reboot - so if I accidentally press F2 instead of F1 (or switch to a VTY to login and type out the command properly), it could in theory end up being slightly annoying (since I have plenty of ZFS snapshots to restore from. >If we were redoing things from scratch, what you propose would make more sense than the current behavior for sure. > >Cheers >Michael Hi folks, Overall, I'm in favour of making a flagday out of this, and changing the default - because, unless you're coming from a BSD system, you're going to risk behaviour that could be a lot more disasterous than outlined above. So in this instance, it makes sense to change it. Yours, Daniel Ebdrup Jensen --ya4iyqp37ie2vyz4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmK0JVpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87r42gf/cqNkkblDP61sA98VYOzmZsRH4Cs2DLLfvcsTRiSHkFn+x/azpSQEhve6 hMLexYgjE4nhDBMj9BRopO/1gb4w2vkVZroCEeZSq0kO7iFl0Nk9GXq+jko4MVYC 1YQ9LG51nyNICS7f62cCB5POoqw60R6Ia77VM5PthIC/SiqxkX2XDc+iAbaT/maB PaWqNhm361eVK9qmoudFFMzYK1XsALvweIgzR29RTsK4fgTkqVnH/E7PE3377miA k0ERYHbaNFSI+I206OcUBHxBkMJ67b9NwN0hzJX0gRwD0Ah4t6cdbhXUNW60nBvz 4qUL9fKbPSpy8ywMJ/gpIBCaXmdM3A== =n90G -----END PGP SIGNATURE----- --ya4iyqp37ie2vyz4-- From nobody Thu Jun 23 15:42:59 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 186EA85A797 for ; Thu, 23 Jun 2022 15:43:11 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTPfQ0Jglz4syQ; Thu, 23 Jun 2022 15:43:09 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 25NFgxMZ061647; Thu, 23 Jun 2022 08:42:59 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 25NFgxtm061646; Thu, 23 Jun 2022 08:42:59 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202206231542.25NFgxtm061646@gndrsh.dnsmgr.net> Subject: Re: Updating reboot's default In-Reply-To: <546C53F4-E30F-4DAF-BE33-B1772A23ABAE@freebsd.org> To: Michael Gmelin Date: Thu, 23 Jun 2022 08:42:59 -0700 (PDT) CC: Warner Losh , "Greg 'groggy' Lehey" , Warner Losh , freebsd-arch@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4LTPfQ0Jglz4syQ X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.28 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.955]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.49)[0.485]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.85)[0.845]; MLMMJ_DEST(0.00)[freebsd-arch]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > > > > On 22. Jun 2022, at 04:03, Warner Losh wrote: > > > > ? > > > > > >> On Tue, Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey wrote: > >> On Tuesday, 21 June 2022 at 8:01:58 -0600, Warner Losh wrote: > >> > 15 or 20 years ago, we talked about changing the default for reboot from > >> > 'right now' to being safe shutdown. There were arguments made against it > >> > due to tiny appliances and such. > >> > > >> > Time has past, and this oddity has persisted. It's time to revisit that > >> > decision. > >> > > >> > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > >> > behavior. However, the 'reboot' command will switch from '-q' behavior to > >> > '-r' behavior. > >> > >> Somehow I hear this echo "If it ain't broke, don't fix it". My > >> understanding has always been that shutdown(8) is the program that > >> shuts down and maybe reboots the system, while reboot(8) is a quick > >> and dirty way to reboot the system, along with halt(8) if you don't > >> want to reboot. > >> > >> So why change this? At the very least you'll confuse people who want > >> to use the old method. My guess is that you have some reason that's > >> not immediately apparent, but what? > > > > > > Other systems have the behavior I'm advocating. We are the odd duck. This means we tend to violate POLA here. And there is no good reason to do this when fastboot is available. Nobody that advocated to keep this difference as useful the last time it came up still wants to advocate. Most people find the behavior annoying and only a vanishingly small minority of people like it. In fact, so far nobody has even asked to please not, let alone come up with a good reason to retain this behavior. So, I'm polling arch@ to see if anyone like that shows up. > > > > Well, to be honest, I?m used to the current behavior and would prefer to keep it (POLA for existing users). I didn?t answer to advocate against the change as > > 1. I have no metric to counter your argument that this is a real problem for people used to other OSes (neither how many people pick up FreeBSD in general nor how many are unpleasantly surprised by how `reboot` works) +1 > 2. I will certainly be able to adapt and get used to the new behavior +1, though FreeBSD has become a long set of these pain points. > 3. Given the amount of change in the world right now, it?s a ?pick your battles? situation. There is and will be so much to suck up, arguing about this with someone who clearly put some thought into it seems like a waste of everybody?s time. +1, as FreeBSD-- in my world the amount of these changes become less worth voicing any time on. > Cheers > Michael > > > Warner > > > > > >> And no, I don't really have an axe to grind in this matter. > >> > >> Greg > >> -- > >> Sent from my desktop computer. > >> See complete headers for address and phone numbers. > >> This message is digitally signed. If your Microsoft mail program > >> reports problems, please read http://lemis.com/broken-MUA.php -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jun 23 15:45:31 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 998F185BF97 for ; Thu, 23 Jun 2022 15:45:34 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTPj95PJWz4vWg; Thu, 23 Jun 2022 15:45:33 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 25NFjVvF061681; Thu, 23 Jun 2022 08:45:31 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 25NFjV9d061680; Thu, 23 Jun 2022 08:45:31 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202206231545.25NFjV9d061680@gndrsh.dnsmgr.net> Subject: Re: Updating reboot's default In-Reply-To: To: Warner Losh Date: Thu, 23 Jun 2022 08:45:31 -0700 (PDT) CC: Michael Gmelin , "Greg 'groggy' Lehey" , Warner Losh , "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4LTPj95PJWz4vWg X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.17 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.41)[0.412]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.84)[0.844]; MLMMJ_DEST(0.00)[freebsd-arch]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On Wed, Jun 22, 2022 at 1:03 AM Michael Gmelin wrote: > > > > > > > On 22. Jun 2022, at 04:03, Warner Losh wrote: > > > > ? > > > > > > On Tue, Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey > > wrote: > > > >> On Tuesday, 21 June 2022 at 8:01:58 -0600, Warner Losh wrote: > >> > 15 or 20 years ago, we talked about changing the default for reboot from > >> > 'right now' to being safe shutdown. There were arguments made against it > >> > due to tiny appliances and such. > >> > > >> > Time has past, and this oddity has persisted. It's time to revisit that > >> > decision. > >> > > >> > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > >> > behavior. However, the 'reboot' command will switch from '-q' behavior > >> to > >> > '-r' behavior. > >> > >> Somehow I hear this echo "If it ain't broke, don't fix it". My > >> understanding has always been that shutdown(8) is the program that > >> shuts down and maybe reboots the system, while reboot(8) is a quick > >> and dirty way to reboot the system, along with halt(8) if you don't > >> want to reboot. > >> > >> So why change this? At the very least you'll confuse people who want > >> to use the old method. My guess is that you have some reason that's > >> not immediately apparent, but what? > >> > > > > Other systems have the behavior I'm advocating. We are the odd duck. This > > means we tend to violate POLA here. And there is no good reason to do this > > when fastboot is available. Nobody that advocated to keep this difference > > as useful the last time it came up still wants to advocate. Most people > > find the behavior annoying and only a vanishingly small minority of people > > like it. In fact, so far nobody has even asked to please not, let alone > > come up with a good reason to retain this behavior. So, I'm polling arch@ > > to see if anyone like that shows up. > > > > > > Well, to be honest, I?m used to the current behavior and would prefer to > > keep it (POLA for existing users). I didn?t answer to advocate against the > > change as > > > > 1. I have no metric to counter your argument that this is a real problem > > for people used to other OSes (neither how many people pick up FreeBSD in > > general nor how many are unpleasantly surprised by how `reboot` works) > > 2. I will certainly be able to adapt and get used to the new behavior > > 3. Given the amount of change in the world right now, it?s a ?pick your > > battles? situation. There is and will be so much to suck up, arguing about > > this with someone who clearly put some thought into it seems like a waste > > of everybody?s time. > > > > I posted so I could understand other views, so I'd like to ask some > questions if I may. > > Is your reliance on the current default due to shell and similar scripts > you have? Or is it due to your interactive operations? > What do you like about the current behavior: How quickly the reboot > happens? Or you have a lot of running processes you don't want killed or to > have a chance to clean up? > What build process do you use to create your FreeBSD images? Images from > the RE, buildworld, nanobsd, poudriere, etc... > > The only thought I've put into this is from my perspective, and while it is > often a good reflection of the larger community, there are times there's a > mismatch, so I'd like to at least understand why you hold these views. > There may be a simple way to accommodate both sides. I'll once again assert your exposure to the "larger community" is only valid when you restric the set of "community" to be developers. I absolutely assert you are not in tune with the joe blow off the street user of FreeBSD that rarely if ever interacts with the project. > > Warner > > > > Cheers > > Michael > > > > Warner > > > > > > And no, I don't really have an axe to grind in this matter. > >> > >> Greg > >> -- > >> Sent from my desktop computer. > >> See complete headers for address and phone numbers. > >> This message is digitally signed. If your Microsoft mail program > >> reports problems, please read http://lemis.com/broken-MUA.php > >> > > -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jun 23 18:57:52 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D27988629B9 for ; Thu, 23 Jun 2022 18:58:02 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (mail.xzibition.com [52.11.127.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTTzG0XGFz3tJ4 for ; Thu, 23 Jun 2022 18:58:01 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id EE86D209DF for ; Thu, 23 Jun 2022 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id ODxWnPdG-8zX for ; Thu, 23 Jun 2022 11:57:52 -0700 (PDT) Message-ID: <1f81bf6a-4600-9966-b8fb-e62828510850@shatow.net> DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 6389A209D6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shatow.net; s=mxc204805312015; t=1656010672; bh=DjaUtl7DBF16jfSElx3i0NMEJy8Un/QqaH+omksA3Pk=; h=Date:Subject:To:References:From:In-Reply-To; b=jFm7KLZpAChW8lK3lkUnSUVLGSxtqL8d1W7HW7aIoLX3cd6GDcK19M8l039TLOWyh qXLsAkSIumL2RUmq3Z5N1gPbivvt8r8wKt35+pf10h3tLw1COTad9isjYQcJcs2HTU 6A7huxDQrPGiZrveGFcZjg32oc6Kktbej1B0QuTc4suEMNchMAyp6E+oaXfA6KcJ9L Sjpg2w0puS/9glbS0mwdguOlrwmDUvLSv3V6Vg3Fkt6Vg2lc9znKFltBGWTow8cypc 9IBjV2c+R/jY2E8NT2KSOeJQL4VXk80DnMLkDsgCQ8MF6Fcr+KyvvKf06s5zpJdjCF chD/3/u2OH3xQ== Date: Thu, 23 Jun 2022 11:57:52 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Updating reboot's default Content-Language: en-US To: freebsd-arch@freebsd.org References: From: Bryan Drewery In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LTTzG0XGFz3tJ4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=shatow.net header.s=mxc204805312015 header.b=jFm7KLZp; dmarc=pass (policy=none) header.from=shatow.net; spf=pass (mx1.freebsd.org: domain of bryan-lists@shatow.net designates 52.11.127.251 as permitted sender) smtp.mailfrom=bryan-lists@shatow.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[shatow.net:s=mxc204805312015]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[shatow.net:+]; DMARC_POLICY_ALLOW(-0.50)[shatow.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:16509, ipnet:52.10.0.0/15, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 6/21/2022 7:01 AM, Warner Losh wrote: > 15 or 20 years ago, we talked about changing the default for reboot from > 'right now' to being safe shutdown. There were arguments made against it > due to tiny appliances and such. > > Time has past, and this oddity has persisted. It's time to revisit that > decision. > > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediate > behavior. However, the 'reboot' command will switch from '-q' behavior > to '-r' behavior. > > I'll update the man page, etc to reflect these new defaults. Most of the > systems I've been on in the last 10-15 years have had some flavor of > 'alias reboot reboot -r' in their login scripts and/or made shell > scripts that did this. This will match what everybody else is doing, and > will likely result in less astonishment rather than more, even though it > changes a long-standing default behavior. > > Comments? > > Warner > (This isn't about reboot -q as that isn't the default nor does fast* use it) I knew about the distinction of "reboot" and "shutdown -r" but at some point misread the "shutdown -o" branch in shutdown.c and misremembered that they were the same (added in with more Linux exposure). I only ever used "shutdown" when I wanted a controlled, and timed, interactive-user-friendly event. That was the only distinction I thought there was. Reading the difference in the 2 manpages still makes me think that's the only difference. rc.shutdown behavior is not documented in either reboot(8) nor shutdown(8)."reboot" avoids rc.shutdown which can cause things like virtualbox to not save vm state, or not wait for processes that take a long time to save their data to disk (minutes) before they get SIGKILL'd by init after hardcoded as-little as *5* seconds and only as long as 60. This is where the "fast" aspect comes from - because it does not care about your data or give you any way to control the timing. Losing data has been the most astonishing thing for me. reboot - avoids rc.shutdown halt - avoids rc.shutdown fastboot/fasthalt - avoids rc.shutdown shutdown - calls rc.shutdown poweroff - calls rc.shutdown reboot -r - calls rc.shutdown "reboot" suddenly using rc.shutdown is a safer change isn't it? It's technically a violation of historical behavior but it is one towards safety. I would argue it is the opposite of POLA. The behaviors seem arbitrary and inconsistent and more a relic of historical decisions. We could debate semantics about these words as we all have subjective ideas on them, especially shaped by historical behavior. Consider what new fresh users, from Linux and Windows and Mac OS, all think. Or just what the english words mean. None of the words mean "now" or "unsafe" vs "controlled" or "safe" to me. They just mean a specific event occurs. Why is "halt" a "right now" thing but "poweroff" is not? "shutdown" to me means what "poweroff" does today. "reboot" and "shutdown" are almost logically the same with 1 trivial difference: whether the system comes back up. Why would "shutdown -r" make any more sense for rebooting than "reboot" from a new user perspective? Why should words that are practically synonyms, or in the same category logically speaking, be safe on one and unsafe on the other? > The fasthalt and fastboot utilities are nothing more than aliases for the halt and reboot utilities. Well gee "fast" makes sense so why does the [not fast] still use the "fast"?! Why do these fast ones even exist? -- Bryan Drewery From nobody Thu Jun 23 21:56:06 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5143887D6B5 for ; Thu, 23 Jun 2022 21:56:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTYwm1rDFz4nxY; Thu, 23 Jun 2022 21:56:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656021368; 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=IR2H07DyI5qx/J8bOWxQ6c3SQOTD8ewGcnKlMA39tbs=; b=BzlAdxpvSsD/xXD1PbYtKxR4/aqxHIOxw3UpRQpT/D/LINJgPdIbuAPDiSDN07OFgeUDBA UnS7v35Az1p6HAe/Fw6pfnQBziawYy5NQFp2Q1YCahN3oYOBeFYbxsyxCoyOZo9BamDdEu ykEoOoShu8MMCwd1n/N15JfA7uuPkOs02MugBdZsChHTBPGH7EEjtrclJcLIWzb/Q4xlOE T7l3EY7koL01abWH+6tRMHz8GaD89yl9XqHwIU77lHZs2V9BbH+BHZVEylO9wn2b9lwlHk rSGsvKB78kUB649/R1oQ4C9tsud+Wrko6PLiti3KSRbcmYWJU3v6o93CucRhBA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id CE1A729A5; Thu, 23 Jun 2022 21:56:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Thu, 23 Jun 2022 14:56:06 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Time sharing for interrupt threads Content-Language: en-US From: John Baldwin To: arch@FreeBSD.org Cc: gallatin@FreeBSD.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656021368; 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=IR2H07DyI5qx/J8bOWxQ6c3SQOTD8ewGcnKlMA39tbs=; b=fIE/SuinEjSEsWs7u8DbfdGrGIm/+4OePqxU80FL9A/fBTMWL1jwV4mRVKoH+919IMF6Ax 8XZZZrQAFkcsMpvz6TrSKBpnx5z9B1iO0Q7eNdZ7qzBtUsHy4qoFhwutYn3NPGLgSwzdl0 bPgaIgYobZ4MkVHUmf/4BWEMJnCH10SeJOz5BIVWZvIvabv3L9DC5kXCp9VAZAkDyaFY2W UYKbRrzQKk8OF8JQk3DGY+ag+3qvSDiyXmBfftEQdUqwgm5G0ZRlKxA5V2J35785wIucnX hwvipouHMfBa8p4igcat8Zbf4L0qa/wxM489JaCGiBNaIiG2WYGW4m8HikeXsg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656021368; a=rsa-sha256; cv=none; b=ESMx5N/IqXo8V1nyXATqN98UiqbalxrZNRelmN2ZM2iIFEA1zD6hNxFNaQkayGMmmoPhtX oIDyiqIEytenYslY/bcUkHpIs+V3Ffu5BvAuQUmQcZ0pAJAlaER5SNs7SsjrCrnt4JrD4l N+QgM4W7H0JoxXixzqPlKR5zokW4j8BIz4ucuajTO+uns5tTXlJ9KwXBrmq7qOjlc2e2+3 WveTaD3/oCmGAD+775ynG0NYZNYHlkNk0k11LYo4hijKMOYoWX3N3qiQF+rA+5AcJ+cJSR Nxjvz33WX41aJEbp24FKxKUnOEZym3618WaRkdMlLk1FTubuCMQ2OKNs13pB3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 5/4/22 2:48 PM, John Baldwin wrote: > The changes to implement this can be found on the swi_refactor > branch here: https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:swi_refactor I have extended this branch a bit further. It now supports time sharing on 4BSD as well (mostly just for completeness). I've also collapsed the ithread priorities down to just 4 effective values merging all hardware ithreads into a PI_HARDWARE and all SWIs to PI_SOFT. I think I might have moved softclock back to PI_SOFT. I also shuffled the other priority ranges around to move the now-unused priority values down to the user range so that CPU schedulers have a bit more precision/granularity for user processes. Drew did test this under a production loader and did not find any regressions. I would still appreciate some review on the idea though? I have not done any of the work to try to simplify interrupt handling in iflib. -- John Baldwin From nobody Wed Jul 6 08:03:22 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D40721CFB97B for ; Wed, 6 Jul 2022 08:03:42 +0000 (UTC) (envelope-from tdtemccna@gmail.com) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LdBrF5YHSz4fGy for ; Wed, 6 Jul 2022 08:03:41 +0000 (UTC) (envelope-from tdtemccna@gmail.com) Received: by mail-lj1-x236.google.com with SMTP id n15so17413846ljg.8 for ; Wed, 06 Jul 2022 01:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=qNJS8bXJjIJEOjJk4e4xeTOXLNTgbklFiRogoFnIe/0=; b=GXfrF70/UwmaqQRun8LOXhmjKVHXFPcCTIty+unk6CHsOZUC24utMyZCqYlRUvU2rk UB4ACdPQvJLf1mcUFcMVkIYN5spejbHn2fS+G9eoPVXDMKktosrneePs2ojK/krW6Inx i7z1LuKfohtRT6mSZLyQzRNYnHylF7/7NJWNDGhm54WtUbbqteNU4vFkmpHIhUkezrBZ /T/e1vWPGOfgnuvKmldzRPP5KiExjb98tzDuL0punTE96xVCOEYspPwwWj63zmmCce0E URGm+G7Z8LOm/xtDpqcE5JywfVC7UFkY8VFsHS3DDw5w0zftOPC0OYvwmxpI/eHjgzi2 7S8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qNJS8bXJjIJEOjJk4e4xeTOXLNTgbklFiRogoFnIe/0=; b=HcZCURihdI2w+ofKe8UxJdukaWQD5nzc3NQjwvDlBBEHga6FJovXtBQB1+6R6PL27E NN1bfZd7vZulHGSMl2dsx307vdjtB6Rd/maouzatAGLLnUQgbhihBpHz5PLLDe2nGI4h 89OOiocellRPd2UwC35m+pl9YGlq3RzVe3yJrhvrqxmeb3R5gld4Wz+t4NCNf79zntiJ 3h1KLOv0p+J4bZR6ofWbY72zrgM66Ws8TUayqlg2mDAmVzoeHgzs96GziWzxmOrU7l96 jCIe8mM1OGWBK22FI4lgVK6mQQPmkCYPjf7bE1g0PbnYf8VNtK8wrw90iMiWirefe+OM hzwQ== X-Gm-Message-State: AJIora/cEcxach6dbUhTQCNXkFgqkVfxwB5Wmc2ZmT5zi18/ziiFc9CK UWjEIvi85EMb7AyGLQNzUXtnejG7OCaVBVAzKZzkYL4oGUbWsA== X-Google-Smtp-Source: AGRyM1vTrFtp5TMxbpGaJ/10yG+pqc6IyYrCnd/OIOnfw7B9sRoKwJNfr0u1WC4hy0E/PKlqRrbwYmz2iSfv8MVqH+I= X-Received: by 2002:a05:651c:160a:b0:25a:62a4:9085 with SMTP id f10-20020a05651c160a00b0025a62a49085mr21711405ljq.214.1657094613671; Wed, 06 Jul 2022 01:03:33 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Turritopsis Dohrnii Teo En Ming Date: Wed, 6 Jul 2022 16:03:22 +0800 Message-ID: Subject: FreeBSD is a great operating system! To: freebsd-arch@freebsd.org Cc: ceo@teo-en-ming-corp.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LdBrF5YHSz4fGy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="GXfrF70/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of tdtemccna@gmail.com designates 2a00:1450:4864:20::236 as permitted sender) smtp.mailfrom=tdtemccna@gmail.com X-Spamd-Result: default: False [-3.83 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.83)[-0.833]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::236:from]; MLMMJ_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Subject: FreeBSD is a great operating system! Good day from Singapore, I think FreeBSD is a great operating system! I support FreeBSD because the most popular pfSense firewall, the extremely popular OPNsense firewall and the BSD Router Project are all powered by FreeBSD! macOS is also based on FreeBSD! I use pfSense community edition firewall in my home. I am planning to try out OPNsense firewall next. I will continue to support FreeBSD! It is a great operating system! FreeBSD is a very good network operating system. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore 6 July 2022 Wed Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com From nobody Thu Jul 14 15:42:58 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LkJfZ60vhz2pR3Y for ; Thu, 14 Jul 2022 15:43:02 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LkJfY5GLWz4GCl for ; Thu, 14 Jul 2022 15:43:01 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82d.google.com with SMTP id i21so1696827qtw.12 for ; Thu, 14 Jul 2022 08:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:subject:message-id:mime-version :content-disposition; bh=n3vJBVz+5neFzWIbfK0QF66lQwdixMHDVtpDk8Uu34A=; b=pZjE4/k+OfhK19WwdOFjccvO44S01ONTSAJRDfCK0dDAlzw9dmJN2jMo32znxtlaeR y6YotkX7CJCsCzPTuh0yQGf45wDgrqe1mMTHKjKept4vgc8VgVw5vbg+tZuaBCu4+J92 +sK6WJKlF0wq8jxZ/Rg1YsWZw5wCCRpIVP8g2Ontjs1dIWi9wxG2DxmrScCbcqCPrdca E5yzsP/LanyvpMcsRy7hH8piv7B7J7aER4v9XTVtjWmv+IosrIDC5tZ7KmLvKcFOQr/O bXt8psZkkg2r47XUZF92wcqG1WLKERHmgI3OxeKn613+gOD1cKB6uIHJpa8MQb+k0SjH K/Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition; bh=n3vJBVz+5neFzWIbfK0QF66lQwdixMHDVtpDk8Uu34A=; b=Vy12Ap5pkRudqZZnczTYUzTIfHpnsMyDXR/35Ig6aFDmA4TGT/lqN0RVq4IwhTBI/y ONQ1WwQgNUwakPMnb1lk78VbWbw3rQZ034tyUeoLIq4B5qD+BlMcZugi/lBn8sG6oIG7 FJS8IIE4YzEeV62Hav/hdlAS+iqCg8NfH3d9Tp7Xw5CTjRlcPOgqErWjUaXVC6w9swxo /E+hIy89nhObH+1ue/S+E8rjWkRebOLiMp877jlft+L/e3VZ46kOXyF8GkR036KlKmOJ FM33Xhn8lHygwt9A7UQNfwLYlwL+CKDGnMbNuyJP5YJrCdYshqGCFHUdHaeBiO0Sgqr3 h7iA== X-Gm-Message-State: AJIora+wRM8/a6eOlZ6QioNVx7eeQ3uvs36J5S/DCvwhRRDPQExqSrVJ JeXLdhIiUGAhMkJfNWybBzlnHr8XTds= X-Google-Smtp-Source: AGRyM1sRnpw8bYSmM7jTgtWlQCi6Yxil2r076HWofCinDZpO40SIsLApUC/ImXV/PlJxFq15fTPthg== X-Received: by 2002:a05:622a:103:b0:31e:d338:cb88 with SMTP id u3-20020a05622a010300b0031ed338cb88mr2403145qtw.675.1657813380770; Thu, 14 Jul 2022 08:43:00 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id k11-20020ac8140b000000b0031e9d9635d4sm1774424qtj.23.2022.07.14.08.42.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Jul 2022 08:42:59 -0700 (PDT) Date: Thu, 14 Jul 2022 11:42:58 -0400 From: Mark Johnston To: freebsd-arch@freebsd.org Subject: new QAT driver from Intel Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4LkJfY5GLWz4GCl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="pZjE4/k+"; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [0.95 / 15.00]; NEURAL_SPAM_LONG(0.98)[0.977]; NEURAL_HAM_SHORT(-0.56)[-0.559]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; NEURAL_SPAM_MEDIUM(0.24)[0.235]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82d:from]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, A couple of years ago we imported a driver for Intel's QAT hardware. It implemented only the functionality required to offload cryptographic operations from OpenCrypto, mainly for use by IPSec. Recently, Intel has proposed adding the upstream driver to FreeBSD, replacing the existing one: https://reviews.freebsd.org/D34632 This driver maintains the OpenCrypto integration of the old one, while introducing various QAT-specific interfaces to provide offloading of cryptographic and compression operations. One wrinkle is that the new driver does not support legacy Atom C2XXX chipsets, so my plan is to rename sys/dev/qat to sys/dev/qat_c2xxx, and keep it around for now. The patch to do so is here: https://reviews.freebsd.org/D35817 D34632 still needs to be rebased on top of this one. Currently, either patch can be applied to the main branch for testing purposes. I believe this change will result in minimal disruption for users, as the new driver ought to be a drop-in replacement. Currently there's no plan to merge to any stable branches, but that may change. If anyone has any concerns about this change, please let me know; absent any problems, I plan to merge the new driver in a week or so. From nobody Tue Jul 26 16:31:17 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lsj8Z1Jwhz4XSRB for ; Tue, 26 Jul 2022 16:31:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lsj8Y2PmFz3YBF for ; Tue, 26 Jul 2022 16:31:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe31.google.com with SMTP id x125so14149713vsb.13 for ; Tue, 26 Jul 2022 09:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=ZdHP8dGNG/nHA15sapnrJUHEPMLuxXaxIOkR0zVzHI0=; b=zh4exVePn5vjImEC6E6mxbtFuBNS6tL0TESBgq/wG9YJzyDSF3AsacbzU+q0wtlwMk K3fI/ylqVzeH0ic8t4ToqFSyShTB5oPb/sm30mex95Cm08Wz5L+n5sZEn7o7mfTrCXQq zlDaUAKgQHGUeQBWdDsyQ3L1TtsDLJEpaYnWFZx0sla1qCvlauLqEgfrZ2d/hXtKmXD5 DRqvFBVK/od6SR2cT5IAyaXrciGFyFofKPILsmTS7DwUBGjhRjJVCUocuOcfCrjxED+h jDY9aPaQV9ttVfVP9GXNfqvOEJRjBMb1pU0Lm3m0eAuqrzVGt/pv687HZrZ4pjZZYowB mHhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZdHP8dGNG/nHA15sapnrJUHEPMLuxXaxIOkR0zVzHI0=; b=ZJhpj/BRNe27pTt5UAkBtE3zNxz04NJW/KHDj5wT6vDAIZNambreniGbyN+f6vwBXo oPr9VjVsZkFJWzfjzks+EBURxh9MsqxNZztYafL/bp5SGorjonMqXtO2aRSkh7/Ar6vW aNIf2fkDPGbxlQzLwujsCtPdKH1kCzuh+DzGZMEE9TWlPg99+vyTdj4XZMNShfCkPyQM N8cqDZ7JG+gr1NhAygI45EK/2QcqI4ZfxF36F8iUCmE9kTo925QJrCtpWDjBOWyDut7D mt2y8sbP/bLoxjRX0n7REFG3ob7WEbGP5pqNZ/O3V3JAsHUc3Cq0nJjLLqfub5jk0YAU nNNw== X-Gm-Message-State: AJIora9rp/A3jdj+EL7Gj14og3nr5RxDdq1o4p/qzLwAOWDlBaSiRbc7 JjH6Q3VvTdkHU0VKNlLCIGozXzlrd+cVZSK/aBeo4Dq9Ot6N5Q== X-Google-Smtp-Source: AGRyM1unwD4MBh5Ex4TMI5rZk3UKykJFyujMGdV1Fm2dai0s08D1DiPpQrrSTje9gYsoMlOfHwo84QHd+F1ACIx6zzM= X-Received: by 2002:a67:f351:0:b0:358:3289:1c00 with SMTP id p17-20020a67f351000000b0035832891c00mr5227172vsm.40.1658853067787; Tue, 26 Jul 2022 09:31:07 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Tue, 26 Jul 2022 10:31:17 -0600 Message-ID: Subject: Stlye(9) strengthen statements on not using K&R function definitions To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000d730a705e4b7d32b" X-Rspamd-Queue-Id: 4Lsj8Y2PmFz3YBF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=zh4exVeP; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000d730a705e4b7d32b Content-Type: text/plain; charset="UTF-8" Greetings I've posted a review https://reviews.freebsd.org/D35945 which strengths statements about K&R definitions and declarations: don't use them. Most of the K&R code has been removed from the tree (ufs being the last straggler). Future versions of the C standard will remove the K&R definitions and declaration syntax. clang 15 will whine about this construct. The time is ripe to move to language that suggests an outright prohibition. Comments about language? Make them in phabricator. Comments about the idea? Reply here Warner --000000000000d730a705e4b7d32b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings

I've posted a = review https://reviews.freeb= sd.org/D35945 which strengths statements about K&R definitions and = declarations: don't use them. Most of the K&R code has been removed= from the tree (ufs being the last straggler). Future versions of the C sta= ndard will remove the K&R definitions and declaration syntax. clang 15 = will whine about this construct.

The time is ripe = to move to language that suggests an outright prohibition.

Comments about language? Make them in phabricator.
Comme= nts about the idea? Reply here

Warner

--000000000000d730a705e4b7d32b-- From nobody Tue Jul 26 21:03:34 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LsqC83PD7z4XBqg for ; Tue, 26 Jul 2022 21:03:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LsqC72L4Bz3RSX for ; Tue, 26 Jul 2022 21:03:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa35.google.com with SMTP id o193so5115181vka.4 for ; Tue, 26 Jul 2022 14:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=g98Tr1rDGZIuVmwbsSgnwyeSdno3IVltnVca8MED13g=; b=7JDdenwW6cRFN4bYvrDgTb8+1URLhGFJgco2vYJsXXf2YaEzU4F8yOFndQyhXmWlan JottUMPxnmq6QpyyPL9OmV0k+aHABifAGuoCJ0k9n5L3uzh7aVkeaese8KPdCvju1eQS HX9bwcfZ7LeOl6ymFvHnDWumDYHoOjIaGQEVKqtnTtUeBD/e4HgpxtN57Vp0qQ92l5yW fAwiUpyomnLf73Gp1/RXafRVie+zxVevnxKJsSE4Mzj51ZEzTHjemKz7IpywBZfdp+rG 9gjCoY8HAM8HWUdhkztTmffdozPjc1We507pys3GeW3+EqPCOC1RJzdAiWH5h8r5JrKp +UVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=g98Tr1rDGZIuVmwbsSgnwyeSdno3IVltnVca8MED13g=; b=reYSVbO21UAUGL9LwSSX02DLnj2pfW0YuZbyYlQdOAWdftku+v/z0ZmibjpQ4YeK7Q lbl2cQaQuvaVvzSREN6opJNcbUfle7y7Gx93Zj+PI2enA3T9PNmhlESmSfiAgEOYLM2U cVEcIpF6jDNnuEFeJtbZbhQPblLils5aOOHEhWtgmynUHANKkiZzJN5HBCtAZrQ5wwbD jI866obx2W18UsJA5QRbKeDbrUWzKglgwaSQqa9dufnvb6xCriNTKFPH7IVboJgSOWYm eJr/MD6loVc4I+Wrpa+g7hwG8fhNPpGZKUOWxdSWtmUrzXgfyf2u90vAHNYWC4HYZ4xk L8yA== X-Gm-Message-State: AJIora+0ay+SRcMlQ311A/t94VnSUlN9t1pl64zDBT4TO1+1fS1eY5VC PSUnyeP+j58IE3mQS+u139hOYW4tsIbz61mH7FFSOBuVZVEdDw== X-Google-Smtp-Source: AGRyM1tgqHXHj2MLbLquIBa2gU5nKvjJ4F971EjIcsXDkDi60MJ/cyorC7w27WSGCLafswpt0EQZhBnvrFxiFz+RZhw= X-Received: by 2002:ac5:cb69:0:b0:376:f2f:563e with SMTP id l9-20020ac5cb69000000b003760f2f563emr5799125vkn.23.1658869425977; Tue, 26 Jul 2022 14:03:45 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Tue, 26 Jul 2022 15:03:34 -0600 Message-ID: Subject: Style(9): Allow // comments To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000dd50ea05e4bba2ce" X-Rspamd-Queue-Id: 4LsqC72L4Bz3RSX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=7JDdenwW; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a35) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a35:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000dd50ea05e4bba2ce Content-Type: text/plain; charset="UTF-8" So, is it time to allow C++ comments? I think so. https://reviews.freebsd.org/D35960 Comments about how I said it? In the review. Comments on whether or not we should do it? Reply here. Warner --000000000000dd50ea05e4bba2ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, is it time to allow C++ comments? I think so.

=

Comments=C2=A0about how = I said it? In the review.
Comments on whether or not we should do= it? Reply here.

Warner

--000000000000dd50ea05e4bba2ce-- From nobody Wed Jul 27 03:13:22 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LszPf5w5mz4Wv3F for ; Wed, 27 Jul 2022 03:13:26 +0000 (UTC) (envelope-from grog@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LszPf4Xxpz3w80; Wed, 27 Jul 2022 03:13:26 +0000 (UTC) (envelope-from grog@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658891606; 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=gGQxeju83t5tQqQuno7flTcViL9Ax/aa2EWUaNpYRNI=; b=b9MAYEZ0asEcjZA4WlCt/i81vq4ONpcVwC599jduKwPw4ZPQn/7PAZJ0FBGIy7j9HzvLpP RxxZfbUd0/f6M1qaLKel8PIE+O5y29335jFTGlXopb5YK4Pnb0lB6z1+uELG//yNirRrAj 382spEmn/Fo8LUW7YK15eUpBRmIA/n5nstAoqomc5UFN2dpZGUThXgrd9lDN8lInOLIEHj yoiVclC8DTQuaUtSdenSD2qPpLOUq5e9yEmZitFkTNQwNPUftXtopHH4odquuK/xerqRuj lU+Lk5QR6OfWDtj6Wi0ldDJvAXx8yKm5gdL5C33II+YILCU0bTjkQU8c34bMzw== Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: grog/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4LszPd3j0pzmPX; Wed, 27 Jul 2022 03:13:25 +0000 (UTC) (envelope-from grog@FreeBSD.org) Date: Wed, 27 Jul 2022 13:13:22 +1000 From: Greg 'groggy' Lehey To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Style(9): Allow // comments Message-ID: <20220727031322.GG52252@eureka.lemis.com> References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9sSKoi6Rw660DLir" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658891606; 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=gGQxeju83t5tQqQuno7flTcViL9Ax/aa2EWUaNpYRNI=; b=qWCNSqS20jiFMJXuTkDzobDGKdzoYXbE3+UHGbKJXNRhZdxekDDQC8Hz0eFkGD/epvhzwr 65Zydh9Fm7VrPBjWjGkvSPnp5YLii9lrFdPb8jx7xdXH3g4kDfeKp4asUC00OZRpdkZ2IN 5e15/rsdCB7M3Hy12lhngy2pXZsI3Ilt8cSpDrOOzKnZl6qXW482CUHTBDLAPBWUbimy+E Z5RSkNdHRoik4wkzKgQdusgOHlrEXgtAPuNqxJPMYXW6m7wn+wncuuJwJmQX7gGFzVQ/oM 6m66SGcUsAlhQfJTa3N4nNOhVfOdSZTVsGYci/iORu7DB+hpcjdqggaHyrEKFw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658891606; a=rsa-sha256; cv=none; b=ZLjFiW+bNILc2iHMlVnYVvH6/2mVgfwYKzHyp9zXkhA3LHepFc5N4C8xxRIgLu+tuNMibl l4cT5N/HghwkxXQETl4VGT1TZ7tIEo7xuWod0QV+TJk36Lfdr+zfLJtYqv9ozTJuOfJT7H dVh+ktcKeFBrmLSfCFX2yFk1D7PZz1S0/0fcoGzNl3S8nuvalin3vjdYpD/cVHHA4SwDvN R+JhOZkaokhOoCTMvB1mPnC3p904rMDTS7jqj7ThWidPSzg7Xqpqng/I0fVWzX5CazYlcb hyuhhPAJRyYYcl6KFOL5Vv52pYaFKQ5369NT+/KQ5Azm92f/EA8ngsPRVjfkyg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --9sSKoi6Rw660DLir Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 26 July 2022 at 15:03:34 -0600, Warner Losh wrote: > So, is it time to allow C++ comments? I think so. > > https://reviews.freebsd.org/D35960 > > Comments about how I said it? In the review. > Comments on whether or not we should do it? Reply here. My question would be: why do it? Then we have two different comment styles, and there's no obvious (to me) reason why we need that. There's a lot of stuff in style(9) that prohibits perfectly acceptable styles, like the myriad brace conventions. Why not allow them too? Sooner or later, style(9) might become irrelevant. In addition, do all editors DTRT with // comments? Allowing them might confuse them. What would bde have said? Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php --9sSKoi6Rw660DLir Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmLgrVIACgkQIubykFB6QiNzfwCffUDh1UbMLaYJvx3DLfKKgEix QbkAoK/wQ8Ew6JNKj7AwpN1AlGNqBQ1+ =OX9V -----END PGP SIGNATURE----- --9sSKoi6Rw660DLir-- From nobody Wed Jul 27 03:52:33 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lt0H30Lt7z4X1S6 for ; Wed, 27 Jul 2022 03:52:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lt0H21Qbfz3yxl for ; Wed, 27 Jul 2022 03:52:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id a63so13749259vsa.3 for ; Tue, 26 Jul 2022 20:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=fKf6wxuJ0h11cepcqHJSgMG9Un0mHoT+liWuqEByOZc=; b=Ksg2qCmUhn3viq6n7SR+K7Xgb9KmN1T29m/lVIUSO5EAvBdsY/6kF3jU6IaRHLjnSt dCojRh93lMA33U2o5GZcax8vCbI5foLI+pwCppO/xqyE8iPuZIdU3fmNWP8swjK8d/DF pCTneVOzlyPfEJtJR0MhqtjYGQ2f3S3pBaX2vaDNx12HqVJ6xCoRfH0J7vNExSB2C5mo i8RGiMWqRJmsJj6ZkGrzqf78xgaBfGFGbh4aUMVg0yfI/ydhnJeHLbKI3c/xoMLEKKd6 wYGREXKFoHTBtbWBM4QCq3Pqdn4C0f9YkCerzZK308Mv3pc0lj5S7cxbqNZ3c08R5B+a RtrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=fKf6wxuJ0h11cepcqHJSgMG9Un0mHoT+liWuqEByOZc=; b=gWhBsW8c/iYnoY4AFxiR3p5Z6faBWICl4/q899iEva8raKYitcQSi5sWiLTBl2TM55 bnYgE0nqIZmI9/biKXwI2xdIUubgDJdo7w3OyBj7O7hc4sbpKsJm5L466LeagQglXLap a7q1Qpvj/XjljSU7yRHnGGdjBUR46JNlo5ojGHEtVTjHVwgk+itqRE/IwVK2OrpZ02rU chjROjPBDc8UDpIGptu8DzjAU8s6GVyw7G/qxrXO1NHQl8fOj44xRQjpwQPH+GShHTLd UEev7FWkhn2o3wvnJD6qc20gac4Qu9AKRraqQJQyDImC98JEN/kWj8V+KMFbsSB/fJn5 8uGg== X-Gm-Message-State: AJIora9TcaKVaxmUkU2US1zYjUgAh9lC2TF1bJHhf4s3t5yZYFtg0fcB f66npsMRCPTt6k1qVwkj1GZtDccAgSHD+EnZihcPHH5z8hA= X-Google-Smtp-Source: AGRyM1sjt2L8/1zY9l+xmbGqLy5aY/RygJNIAJbsI4Zc4fJf64OLAauO4vnycN7FpBMSPZWKTleOG1fO7g4yo6GxkVU= X-Received: by 2002:a05:6102:346:b0:357:79f5:63ae with SMTP id e6-20020a056102034600b0035779f563aemr6750078vsa.40.1658893965191; Tue, 26 Jul 2022 20:52:45 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20220727031322.GG52252@eureka.lemis.com> In-Reply-To: <20220727031322.GG52252@eureka.lemis.com> From: Warner Losh Date: Tue, 26 Jul 2022 21:52:33 -0600 Message-ID: Subject: Re: Style(9): Allow // comments To: "Greg 'groggy' Lehey" Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000840ca505e4c1597d" X-Rspamd-Queue-Id: 4Lt0H21Qbfz3yxl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Ksg2qCmU; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2a:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000840ca505e4c1597d Content-Type: text/plain; charset="UTF-8" On Tue, Jul 26, 2022 at 9:13 PM Greg 'groggy' Lehey wrote: > On Tuesday, 26 July 2022 at 15:03:34 -0600, Warner Losh wrote: > > So, is it time to allow C++ comments? I think so. > > > > https://reviews.freebsd.org/D35960 > > > > Comments about how I said it? In the review. > > Comments on whether or not we should do it? Reply here. > > My question would be: why do it? People want it. That's a good time to at least evaluate whether or not to allow it and if so, when. > Then we have two different comment > styles, and there's no obvious (to me) reason why we need that. > Why not? > There's a lot of stuff in style(9) that prohibits perfectly acceptable > styles, like the myriad brace conventions. Why not allow them too? > Sooner or later, style(9) might become irrelevant. > Style(9) covers a range of acceptable styles that allow us to move from one part of the code to another w/o encountering culture shock. We've modified it over time as tastes have changed. The // comments are another area that have changed significantly in the last 25 years. > In addition, do all editors DTRT with // comments? Allowing them > might confuse them. > Quite unlikely. // has been around for 30 years. > What would bde have said? > Unsure. He'd have an analysis that had 10 or so salient points, 5 of which nobody else has thought of. :). On the whole he'd probably say that, as articulated, the times that they could be used should be limited to where they'd fit in well with the existing style. He'd likely suggest limiting it to comments on statements and/or comments on variables. John Baldwin did some of this in the review and even his questions shows that the current proposal is incomplete. Warner --000000000000840ca505e4c1597d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 26, 2022 at 9:13 PM Greg = 'groggy' Lehey <grog@freebsd= .org> wrote:
On Tuesday, 26 July 2022 at 15:03:34 -0600, Warner Losh wrote:
> So, is it time to allow C++ comments? I think so.
>
> https://reviews.freebsd.org/D35960
>
> Comments about how I said it? In the review.
> Comments on whether or not we should do it? Reply here.

My question would be: why do it?

People wa= nt it. That's a good time to at least evaluate whether or not to allow = it
and if so, when.
=C2=A0
Then we have two different comment
styles, and there's no obvious (to me) reason why we need that.

Why not?
=C2=A0
There's a lot of stuff in style(9) that prohibits perfectly acceptable<= br> styles, like the myriad brace conventions.=C2=A0 Why not allow them too? Sooner or later, style(9) might become irrelevant.
Style(9) covers a range of acceptable styles that allow us to m= ove from
one part of the code to another w/o encountering culture= shock. We've modified
it over time as tastes have changed. T= he // comments are another area that
have changed significantly i= n the last 25 years.
=C2=A0
In addition, do all editors DTRT with // comments?=C2=A0 Allowing them
might confuse them.

Quite unlikely. // = has been around for 30 years.
=C2=A0
What would bde have said?
<= br>
Unsure. He'd have an analysis that had 10 or so salient p= oints, 5 of which
nobody else has thought of. :). On the whole he= 'd probably say that, as articulated,
the times that they cou= ld be used should be limited to where they'd fit in well with
the existing style. He'd likely suggest limiting it to comments on sta= tements and/or
comments on variables. John Baldwin did some of th= is in the review and even his
questions shows that the current pr= oposal is incomplete.

Warner
--000000000000840ca505e4c1597d-- From nobody Wed Jul 27 04:08:40 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lt0dY1R7Kz4X3k8 for ; Wed, 27 Jul 2022 04:08:49 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4Lt0dX1PCXz40ys for ; Wed, 27 Jul 2022 04:08:47 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) by lax.lemis.com (Postfix) with ESMTP id 4A3972809B; Wed, 27 Jul 2022 04:08:41 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id A07612635BD; Wed, 27 Jul 2022 14:08:40 +1000 (AEST) Date: Wed, 27 Jul 2022 14:08:40 +1000 From: Greg 'groggy' Lehey To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Style(9): Allow // comments Message-ID: <20220727040840.GB3674@eureka.lemis.com> References: <20220727031322.GG52252@eureka.lemis.com> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4Lt0dX1PCXz40ys X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-3.80 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_EQ_ADDR_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FREEFALL_USER(0.00)[grog]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com] X-ThisMailContainsUnwantedMimeParts: N --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 26 July 2022 at 21:52:33 -0600, Warner Losh wrote: > On Tue, Jul 26, 2022 at 9:13 PM Greg 'groggy' Lehey > wrote: > >> On Tuesday, 26 July 2022 at 15:03:34 -0600, Warner Losh wrote: >>> So, is it time to allow C++ comments? I think so. >>> >>> https://reviews.freebsd.org/D35960 >>> >>> Comments about how I said it? In the review. >>> Comments on whether or not we should do it? Reply here. >> >> Then we have two different comment styles, and there's no obvious >> (to me) reason why we need that. > > Why not? I find /* ... */ perfectly adequate. As I say, it's my viewpoint. >> What would bde have said? > > Unsure. He'd have an analysis that had 10 or so salient points, 5 of > which nobody else has thought of. :). Heh. That sounds right. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php --UfEAyuTBtIjiZzX6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmLgukgACgkQIubykFB6QiPUYgCfbspaySIJwMMz+263zYF8Bgk4 vNsAnA/X/w3ecb8ipsGlmkyDpzZxk8Qu =7asy -----END PGP SIGNATURE----- --UfEAyuTBtIjiZzX6-- From nobody Thu Jul 28 15:03:49 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ltv74238nz4X0R0 for ; Thu, 28 Jul 2022 15:04:00 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ltv731T0Xz45g1 for ; Thu, 28 Jul 2022 15:03:59 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 26SF3nut007065; Thu, 28 Jul 2022 08:03:49 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 26SF3nmN007064; Thu, 28 Jul 2022 08:03:49 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202207281503.26SF3nmN007064@gndrsh.dnsmgr.net> Subject: Re: Style(9): Allow // comments In-Reply-To: To: Warner Losh Date: Thu, 28 Jul 2022 08:03:49 -0700 (PDT) CC: "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4Ltv731T0Xz45g1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-2.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > So, is it time to allow C++ comments? I think so. > > https://reviews.freebsd.org/D35960 > > Comments about how I said it? In the review. > Comments on whether or not we should do it? Reply here. I am fence posted on this one, Like Grog I see no great reason or "benifit" that doing this adds to the code, it may infact distract some from the very consistent nature of the BSD code. However in defence of // I do see that len("// ") vs len("/* */") to be of benifit on end of line comments. Given the contraints in the review I am in favor of allowing //. > Warner -- Rod Grimes rgrimes@freebsd.org From nobody Sat Jul 30 23:25:08 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LwLDm3dP0z4Y4T9 for ; Sat, 30 Jul 2022 23:28:56 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LwLDl2wmNz3F9W for ; Sat, 30 Jul 2022 23:28:54 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from lapr.no.berklix.net (p3e9bc828.dip0.t-ipconnect.de [62.155.200.40]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 26UNSrEP023699 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL) for ; Sat, 30 Jul 2022 23:28:53 GMT (envelope-from jhs@berklix.com) Received: from lapr.no.berklix.net (localhost [127.0.0.1]) by lapr.no.berklix.net (8.16.1/8.16.1) with ESMTPS id 26UNP82l028218 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 30 Jul 2022 23:25:08 GMT (envelope-from jhs@lapr.no.berklix.net) Received: (from jhs@localhost) by lapr.no.berklix.net (8.16.1/8.16.1/Submit) id 26UNP8Dl028217; Sun, 31 Jul 2022 01:25:08 +0200 (CEST) (envelope-from jhs) Message-Id: <202207302325.26UNP8Dl028217@lapr.no.berklix.net> To: "freebsd-arch@freebsd.org" Subject: Re: Style(9): Allow // comments From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Thu, 28 Jul 2022 08:03:49 -0700." <202207281503.26SF3nmN007064@gndrsh.dnsmgr.net> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28215.1659223508.1@lapr.no.berklix.net> Content-Transfer-Encoding: quoted-printable Date: Sun, 31 Jul 2022 01:25:08 +0200 X-Rspamd-Queue-Id: 4LwLDl2wmNz3F9W X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[jhs]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[berklix.com]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Beware // as a delimeter in calendar files, exaples below. = Nov 5 Fireworks in UK https://en.wikipedia.org/wiki/Guy_Fawkes_Night I have 248 lines match on http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/usr.bin/calendar/ find . -type f | xargs grep // | grep http | grep -v /no_customise/ | wc = -l Most http[s]:// are in commented out blocks, but some are uncommented, eg: Oct Sun-1 Munich Oktoberfest ends http://www.oktoberfest.de /* Not sure if exact algorithm, probably first Sun. in Oct, * but might be Sunday of 1st full weekend in Oct? = * I've kept a log to later deduce, see * http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/usr.bin/cal= endar/calendars/de_DE.ISO8859-1/bavaria/munich/calendar.other * Start date is more problematic, being * Saturday with 16 days to end on Sunday. * & Parade as Friday with 17 days before end, * An easter-16 type fuctionality would be nice. */ Cheers, -- = Julian Stacey http://berklix.com/jhs/ http://stolenVotes.uk Arm Ukraine, Zap killer Putin, grain & fuel loss hits poorest. http://berklix.eu/ferries/#dover_solution From nobody Sun Jul 31 05:42:44 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LwVXC5Wznz4Y66g for ; Sun, 31 Jul 2022 05:42:51 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LwVXC4phXz3w2c; Sun, 31 Jul 2022 05:42:51 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659246171; 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=SlEjzxNdkJ6N6fcwtBwkLzhw5CfNuthq2T29/9CJ01I=; b=cpoPDTAP1T+KWrmzR+aQbkiGvhOXwQXE4jqSPtezny0W4MJIT+7k1q4dZeyKHr6KKSTCoU WiwZU/CEGPUwSf7xM7wEcdrQ0+iV4AminDottiVPggrc5/sy27Hj8USURYRT7iv7GDxs9I DYt7H4aMv/NrxUJCH3q3ULCZ6q9lSKryGo/cx4z/MqIcZBox5VOaJelDKuqlr33UdkMHqE MTyff+OUyFNdz5WNBxSZQYL9DZ1qLL5M6BSwKVHe15KarCyeUZGncZTx+Ybdh4WyFAbWab d7fAs2cP1VQ3qpPRjv14/GUI+3CjmDLT6MkQvlWYoVhlQdE2kQXwJ7L3/jyvkg== Received: from [IPV6:2003:cd:5f1a:d900:cdf0:14fa:b3bf:f33d] (p200300cd5f1ad900cdf014fab3bff33d.dip0.t-ipconnect.de [IPv6:2003:cd:5f1a:d900:cdf0:14fa:b3bf:f33d]) (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: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4LwVXC0nNWzTN4; Sun, 31 Jul 2022 05:42:50 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Sun, 31 Jul 2022 07:42:44 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.1.0 Subject: Re: Style(9): Allow // comments Content-Language: de-DE, en-US To: "Julian H. Stacey" References: <202207302325.26UNP8Dl028217@lapr.no.berklix.net> From: Stefan Esser Cc: "freebsd-arch@freebsd.org" In-Reply-To: <202207302325.26UNP8Dl028217@lapr.no.berklix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659246171; 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=SlEjzxNdkJ6N6fcwtBwkLzhw5CfNuthq2T29/9CJ01I=; b=unAuv2mSVf714i3kPfbiSgIHzhm/dQ84jbHLnrjUnU0MZcewdNUuAMrePZ4Dl77KKLF9/6 pcjMrpptUpccSg26N7MSG8JD7Ds8vgzxa2HopKgakZzQeQFF5mI8tOEESi0FC9JUvI5sfp t7UnveeNCDvld1BXY7haLkGsEiKMNPRwREg88zyFKAVXKudzkKJvqnF3FKiBHS8BoxO/Kc qJayDpcuFB4DpLNlXfSaUKSLVYKZteBQ3MpFNKmp+Lo7mot1J5O3LcuoAWAzC+3TRrlnld lmUn9mv7VoqACWUeSIiwhooIDQ5oKxYzyC7M1vqkIKO6pC99lLeK/B1DPs5g4A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659246171; a=rsa-sha256; cv=none; b=lAQvLgRIypzQc8CLJyYKQqGoTUCPslUAF4yZCBCBAgbJmyaW0afFPFpkUKJjlG6/uWOHdl TnBH1zGhw3ZyrSlJal5dkQKRUhjs9PiRPq32wph1pAoscZoDTE4w5CVp38YqbrMZ4vEIiV cTZNP5pKRNuK59JRj28ev/xQgOSlirKXECDF7bzfXAkvMNvZM06ITPQei8wqShQ2OUQ0wB PsTfoVBrJAwri0bTYcCpX3HFV7zC5Y2grsa/NEInAEFAnlOl++AC9znyT9CkhfhU3F+Df2 XJ6uEbIt8SlMq7p4xovgOpZ0WKPuWmWIwExlXStx6bUamBlPT9TWGi9lqjmBFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Am 31.07.22 um 01:25 schrieb Julian H. Stacey: > Beware // as a delimeter in calendar files, exaples below. > Nov 5 Fireworks in UK https://en.wikipedia.org/wiki/Guy_Fawkes_Night > > I have 248 lines match on > http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/usr.bin/calendar/ > find . -type f | xargs grep // | grep http | grep -v /no_customise/ | wc -l > > Most http[s]:// are in commented out blocks, but some are uncommented, eg: > > Oct Sun-1 Munich Oktoberfest ends http://www.oktoberfest.de > /* Not sure if exact algorithm, probably first Sun. in Oct, > * but might be Sunday of 1st full weekend in Oct? > * I've kept a log to later deduce, see > * http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/usr.bin/calendar/calendars/de_DE.ISO8859-1/bavaria/munich/calendar.other > * Start date is more problematic, being > * Saturday with 16 days to end on Sunday. > * & Parade as Friday with 17 days before end, > * An easter-16 type fuctionality would be nice. > */ I am not sure what you are trying to say with your comment ... For one thing, calendar files are not C source code, which is the subject of the proposed change to allow C++ style single line commends. And I did not see any issues with the use of // in URLs in calendar files in my testing. I had extended the parsing of calendar files to reintroduce conditional sections, definitions, and comments as previously implemented by processing by the traditional C preprocessor, and I have been waiting for your feedback on whether these features work correctly. The calendar program treats // as the start of a comment only at the beginning of a line or if it follows white space. This detail was missing in the calendar man page and I have just added it on -CURRENT. Please let me know if calendar files are not parsed as expected and as documented. Regards, STefan From nobody Tue Aug 2 14:54:33 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lxygx436dz4YJRv for ; Tue, 2 Aug 2022 14:54:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lxygw5H2yz3fT9 for ; Tue, 2 Aug 2022 14:54:36 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id IrCfo3cKeS8WrItI3o7zwu; Tue, 02 Aug 2022 14:54:35 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id ItI2oUJhKuJwwItI3oaVXU; Tue, 02 Aug 2022 14:54:35 +0000 X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=62e93aab a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=rGBR0eEjUmj9kossqNMA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 032B919C8 for ; Tue, 2 Aug 2022 07:54:34 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id E2DB351D; Tue, 2 Aug 2022 07:54:33 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-arch@freebsd.org Subject: cron @shutdown List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Aug 2022 07:54:33 -0700 Message-Id: <20220802145433.E2DB351D@slippy.cwsent.com> X-CMAE-Envelope: MS4xfEov0Ftd3EUqcclyq7F0srTmOeAc2PFAyXovURX/m2GNyWRtOupq5AcI4i4mwqPf8kSREkT7giW9a4w+QSGXeO3EjFTeDKrIrihokCuhTPDYlalWzINj VYx1k4J1GGWpv2eYhPPh/3lyHpCUg8m7R/tzkwdf9R6KrxetAx87sqC7YqRY3iZUgXwS7kx9uh8tVRtGSkDHxqhjm+edk0Z7JPw= X-Rspamd-Queue-Id: 4Lxygw5H2yz3fT9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_ONE(0.00)[1]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, Does anyone think there might be some utility with an @shutdown crontab(5) "nickname" similar to @reboot but instead when cron shuts down? I pointed out to one of my customers that @reboot might be an option instead of an rc script (or in his case a systemd unit file). Not that an @reboot for FreeBSD cron would contribute to solving his Linux problem but might our users be interested in something like this? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Tue Aug 2 14:56:35 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LxykT0YZzz4YK1D for ; Tue, 2 Aug 2022 14:56:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LxykS0G5Sz3fyD for ; Tue, 2 Aug 2022 14:56:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe32.google.com with SMTP id b124so3114924vsc.9 for ; Tue, 02 Aug 2022 07:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=Tq35107UQiJt/3aNgAHkeUDVjwiH/qAlfAnnXeW/7lI=; b=LObVNOUSijhMtkxZ38c0wNlz0d9+N2enB25GUNo5MI11tDI7gh7iswVgH3ZJDefuxv iqSDCVIA1V29/7EIUt1TyFQ6G9xWMTqAxFlfoQAJNiSThsH80hXxtoILNFpj6H6cg2OL 8kUFVIM6EED67mGh378vcRHsFKTMCkSez55fH+4U+5d7b/yzifAIzwLLsg/zrqbm/tQR XL+ucsLCdc6A3tPFICdZt/WmbnH7ktiicQDm/+5HxRWhQkLBa0mLTcITOGIlDvK23QBq Z+iT4iix85CBckpoM4VUrmZugIQ4WkJ60XI1YgOInvBq2EoQn/bYlv7UiuFmShH7bcLF bCbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Tq35107UQiJt/3aNgAHkeUDVjwiH/qAlfAnnXeW/7lI=; b=B4TpNLTKyRAcXoLF9Vw3c0BINxmIl6rrIuGQ/0dJFrmNz8aDiMuz1zijkPXxQiG/hO 7UFDRIIJaqAl5KPiWlX4d1al67XHToXSKzahqV171C54/EmovCDuNCBewTPaXp78ZFqA y7xNv2Q72W7/5BULdQ+Fx5uy8Yl9ntyk0TKPcUauoqmSy/W/SV5SmnvHU1S2aEdk+EgJ Q//6hMrygkIgY6RKJdYfrilFhSupA7Lcvix+NPq1YhNW9/8A0CKPSMEj5LoOctM32lxm +l9nFNZ93X8sPlyyXnNQwzOPyUejsxP6swdJ+073N8iV36S3Tb71Gz8qJALTIv0Ai8T2 A3MA== X-Gm-Message-State: ACgBeo2otesd6/9O/RWABukkCq/tEY00dWpMcbjtc1+spYpkRcHK/OOv cPLKYE0EZ91yQMZMUOxoLJSz3TPNF01r0CEth5czMysv8nk= X-Google-Smtp-Source: AA6agR7/cCI8TLoq/Lt6NbNsGVq0MbWCQqYtitAuHiAurRmf14iZi5fzHwAbagTiVk0QfK0aPzr0r5QaTPv9HBBD1+M= X-Received: by 2002:a67:ea4f:0:b0:37d:e06a:f3bd with SMTP id r15-20020a67ea4f000000b0037de06af3bdmr4612343vso.41.1659452207146; Tue, 02 Aug 2022 07:56:47 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20220802145433.E2DB351D@slippy.cwsent.com> In-Reply-To: <20220802145433.E2DB351D@slippy.cwsent.com> From: Warner Losh Date: Tue, 2 Aug 2022 08:56:35 -0600 Message-ID: Subject: Re: cron @shutdown To: Cy Schubert Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000543e5405e5435396" X-Rspamd-Queue-Id: 4LxykS0G5Sz3fyD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=LObVNOUS; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e32) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e32:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000543e5405e5435396 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 2, 2022, 8:54 AM Cy Schubert wrote: > Hi, > > Does anyone think there might be some utility with an @shutdown crontab(5) > "nickname" similar to @reboot but instead when cron shuts down? > > I pointed out to one of my customers that @reboot might be an option > instead of an rc script (or in his case a systemd unit file). Not that an > @reboot for FreeBSD cron would contribute to solving his Linux problem but > might our users be interested in something like this? > If it's simple and increases portability, I'm all for it. Warner > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > NTP: Web: https://nwtime.org > > e**(i*pi)+1=0 > > > > --000000000000543e5405e5435396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 2, 2022, 8:54 AM Cy Schubert <Cy.Schubert@cschubert.com> wro= te:
Hi,

Does anyone think there might be some utility with an @shutdown crontab(5) =
"nickname" similar to @reboot but instead when cron shuts down?
I pointed out to one of my customers that @reboot might be an option
instead of an rc script (or in his case a systemd unit file). Not that an <= br> @reboot for FreeBSD cron would contribute to solving his Linux problem but =
might our users be interested in something like this?


If it's simple and increases portability, I'm all for it.

Warner=C2=A0
--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 http://www.FreeBSD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2= =A0 Web:=C2=A0 https://nwtime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e**(i*pi)+1=3D0



--000000000000543e5405e5435396-- From nobody Tue Aug 2 15:02:43 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LxysK50Bhz4YKQR for ; Tue, 2 Aug 2022 15:02:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LxysK0SS0z3gdY for ; Tue, 2 Aug 2022 15:02:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id IfNwo3JQkS8WrItPwo81vZ; Tue, 02 Aug 2022 15:02:44 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id ItPvoUM1TuJwwItPwoaWkO; Tue, 02 Aug 2022 15:02:44 +0000 X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=62e93c94 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=byGlL1sLIYWdIabGiZEA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 4DBD61A5B; Tue, 2 Aug 2022 08:02:43 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 242AF580; Tue, 2 Aug 2022 08:02:43 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: Cy Schubert , "freebsd-arch@freebsd.org" Subject: Re: cron @shutdown In-reply-to: References: <20220802145433.E2DB351D@slippy.cwsent.com> Comments: In-reply-to Warner Losh message dated "Tue, 02 Aug 2022 08:56:35 -0600." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Aug 2022 08:02:43 -0700 Message-Id: <20220802150243.242AF580@slippy.cwsent.com> X-CMAE-Envelope: MS4xfC/aetBi4MvvJ1hK95HGzu+hOuNBa3eT6nkIjLfyzMVrMiUTk5t6UtaLLBuduh3JUGx3I1H/lBM6GxBZFhe8fFiWsut82B1YVabqOPM9VKakYM94y1un L740JVzwwsAPZDMod/sryLONMEqiKERTxGmoEfgAcNKNiv0rBh0SaSV9Vc5mrg3Lvn4e+ptWOHT0uShz66C6vZVLX0uBHAnehU26CPf0TeQXoe4LCut9Xz3l X-Rspamd-Queue-Id: 4LxysK0SS0z3gdY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; TO_DN_EQ_ADDR_SOME(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N In message , Warner Losh writes: > --000000000000543e5405e5435396 > Content-Type: text/plain; charset="UTF-8" > > On Tue, Aug 2, 2022, 8:54 AM Cy Schubert wrote: > > > Hi, > > > > Does anyone think there might be some utility with an @shutdown crontab(5) > > "nickname" similar to @reboot but instead when cron shuts down? > > > > I pointed out to one of my customers that @reboot might be an option > > instead of an rc script (or in his case a systemd unit file). Not that an > > @reboot for FreeBSD cron would contribute to solving his Linux problem but > > might our users be interested in something like this? > > > > > If it's simple and increases portability, I'm all for it. It's simple but there's no Linux equivalent, yet. My thoughts are to implement in FreeBSD then canvas then submit a pull request to the Linux Vixie Cron maintainer and discuss with the various Linux vendors. It's a simple thing to do that empowers end-users who wish to run services on their machines without startup scripts and superuser privileges needed to maintain them -- like at $JOB where privilege separation is somewhat of a religion. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Wed Aug 3 05:37:36 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LyLGz0138z4YkrX for ; Wed, 3 Aug 2022 05:37:46 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LyLGx6Gycz3vS3 for ; Wed, 3 Aug 2022 05:37:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from [100.64.10.103] (c-141-193-140-252.rev.sailinternet.net [141.193.140.252]) by anubis.delphij.net (Postfix) with ESMTPSA id EC2162C693; Tue, 2 Aug 2022 22:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2; t=1659505059; x=1659519459; bh=QG2Dto72ORElMdbvpepD2cWZpJfBNwIYT36X9Ckd/zk=; h=Date:Reply-To:To:Cc:References:From:Subject:In-Reply-To; b=NdDtRmh3FoCL4AVabyUe/JxUIFihZPRCJOO+STPXYeu2lyNs6+nZGyuYZiuayJL2C NIXAMxKZ/+tDJEkqNnuKr7I7nEPdWvCX4FkwTRLWuwtdlQaqL0SJYahhCd2M8jOLnG j1144Qdk1jY1OsxhclDOoxv3fVnftxFduruiO53w11rSUTVYOxJtf56AYr2ilNBrN7 VX1i3UnMe4Q0NgD029th889fNyCVbnzQ4B85v/lsaDA0RpXQcH8ID7QmwhlzUe8lpr tp6aiNiiq+uY0FSWmqMCcFQmSVSPbqIz9GtzegSXCFnf4fnvDRJo5qgVa/9wmSrgPb QXYfu5ylF17Fw== Message-ID: Date: Tue, 2 Aug 2022 22:37:36 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Reply-To: d@delphij.net Content-Language: en-US To: Cy Schubert , Warner Losh Cc: "freebsd-arch@freebsd.org" References: <20220802145433.E2DB351D@slippy.cwsent.com> <20220802150243.242AF580@slippy.cwsent.com> From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= xsFNBFobtgEBEAC0Q9xkugo7ZVc1sk7RHX8yUv/4XXrlvWpoJvgKqLuSK1QYLSXSE8BtTSqq ZD6SRAp59y+YvC7cOAiBz6rBDXFcobLN4pqIkcOFO0555Ns8+AYsy8s10pFEu3Fgwt2d/EYI tamQscBPO1ZQxpFYbbVrn279T6eUSZxTY8ztVLCMDEvP/Xk8rebDCjWfpDxs0z1I+w1slvmh Jbip0Jb+N646+OXMzpHzt9imO9PMl+EG2AYH4de809BUHo+sJQ9V3chpdBBEBPzV7SUH00QA hqIEaXUNU/Yp+ICwjaTwLxPfIdtLIpgVlfE87k8M9OwTIc2rq3QatjW809eNQVmbY2KHbd9f p/l0p/WN4DsDxYo90ZLZhJI29gwwoje2mUxa4bOq6dwe3f4RVWW5ubav9On/p6QgkmyBblIa jCALaav6pKbVlzsgCqxjkpeEzMRPNHebG1CvSpbp0RsKSUFFyaiIjcZ1HvBwaaU2plgjiNCh +db8DLarl9y1SDwPupg9ZAOBfE5WvvRPTXsK8+cMHubsexCuw72+KgsfD/aDQG68z4oovuKh MXP0zfFlax54qzAyE9X/eMjTL9pB+GozedWbqz1tw26Z2fh8HYc3BNo/88SBjeQ1OlTn0wu0 rXqQc1YHbXFpjxwsoJuDlknjCqXxYRY4hDUVBr5RnvNYZiXzywARAQABzRxYaW4gTEkgPGRl bHBoaWpAZGVscGhpai5uZXQ+wsGUBBMBCgA+FiEEok+ddXrWKGfwMqGp524tEWjXywUFAluS VEgCGwMFCQmWyQAFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQ524tEWjXywXw7A/+JKVx Ut9nCP0NmmZiaXCYtT54UY5//ewxbeSNzS9H4P7YcJeOUDrtm4ePGS9bqG+CSgyx2rGgxv01 f8az2L0FcmTa9fjnLqLYix2VfRIAdmuzB6qjgXL3cBFpHyBiak6rBGyKW2OmEloK9DmhiM0e xY5avbdNTG5BqfS1wTgwsZmCUIT/GgHv6x2OoqVy8zxArm15Vd52VNACr5Y06IKOpkNEVrqv 9E+MOEVpgz2oriRnfb4Anvo61ihSqis63yVTh3AS8PAo/ZO9hI+9gAHFQTu90JqOIcBl2Zqu din0FTKmqIMcOP751qz7GwL1GVCE7FVb2utgmWfwG4STHW96alGd7GJAi3IJ8GINPd5XrdH8 FPA8OA4C7t/bp7EQiH4h8v3UYPYIoNy74KXDc5S9G/CeZp51EMJc0ZEFeUJajdaDmE4NChiR JzdnEN7f6xTINLBugjy0stsyulcgvfjOzaCeD06KcL2UZO71kJvMU6E1x5PPyRoLoRSbxpNx Ir1I8iPvhYjfgzIfxxj41Qd9swoxo5vCd1JIKtgfsCzK1zbd9cipd+4qfGaDo4I8/3kIa5JC TFaGdnqnd8Z6rOg8ayXQhLSYAjUPSyeTrClbmyy0DhRoyW1g0oY6ERPPkWmo7lrV+iRQfNBD JE6x1FE3iEdzJN01sTIZpweATFET4PDOwU0EWhu2AQEQANs/Jdg3prIMst3dQNttpn5/1Gqg eaTpr6RDJfTqJ41OvZKH7ZzZ42kRyWt6VULsgHMNLeIqI7v825sEAEzgdnMhmrW2HXPN0G1Y PW1rsmstifXDWtVmnB50X0KzyOoTI6OzBzsJZzyyF25rAzVeBwXZO0CFdI9pKRt9WDhyJbQd sHI7XqDnUUURxeqOPtVQAHYZU6oAy5puyUO0auI+4blCBfjIUyMURvTy8bJ2o6E/DdzaY+Be 8rPu9NsOwjURsEKXlBDiSduSP7mg+DvRo0CSCuwS9qabz5PXDGDLMUV5sFTz0eileGqTDejR UjefKs5uyIcCsP2H4PYRhz/KgX7S3U/67hcBGkHbaO7Y+T+EhLkqURchUdZEv5OUQA3hNire h4AI72JShT8FrObGbDzqwyM0Yp7VeAQgGzn2NrPgxIbxineCRBvPBuPk+46JkVB1uMqYLcyy lW4CtF7EUS7qVKJ6PaHW1fqMxuBA3s6JTqD83RMr86A52QUN/cAwfOFHp+FHpoSTPL4l7gN3 LCHypjyra1ZV4NwxdDJIv1bjL+pXGbLPT+HHBSCIBVkl8tctIRzIIbsArGzyHxmF7Hq9oFDe yuaE+G+dS8JuFhUZif+356wqOLAvCX6fqXnSzlBhNGTi+4XyYnHLS+uRieMNr6lgQE/+Ev1h Jxlcczv/ABEBAAHCwXwEGAEKACYWIQSiT511etYoZ/Ayoannbi0RaNfLBQUCWhu2AQIbDAUJ CZbJAAAKCRDnbi0RaNfLBbnQEACtXAz8ZXrIr3SWAZS8xJ5OCsQ+8WfpCTgzamdC662L70P4 7TnPYhNQBj1HPFLSFQugnwkLzBRjwyxuPA5a9w11GtGU6NwRB0JHO+ngOTQ/IDWyKH3A/eJd TzJtpJmTZhlAwbNV7sqZs43MqGNaiT3xfLE39EWvDPImdCuD0QHAYGTS3ZCr5HPRNlyQIJ4s 1mB3c5XWt1R864aRAOUwYMYLuX09LIihn04/qIU8J4Y4zL1Fbn46Yk5St0cBiJPZ758T0jiY 76f6nHjeCtOTIHJKUcDEo0AQ8n7g5hP/Y6s+vmQ1aFSF4YO8Hwjp9gnpksJfJEWxUTj/sQ6X siEOSm1gRste2U0iu7UCjYkjejfMW0XhH+W9XEF5fgaJtp5/zZYksFfn+w4s6X34uMOcCWfP VpnQ8B0Gh0l7pOj6K8VGEfR6OQohEjoijrG3UU9rYa5rq4V0WD+5BzizsPKC69OgsFAIhXO/ hpQxcUd9TVg6or+qC1tvHxJNG/uRuDhJtdrEjmTybxBEddxqHSZK87TGpE2dhHzhQlzIl9XY eUk7X17bhmbzPJq39BAqBdqfYsDm560vX9DEAlxfMbOrcgrr3CY/1Kkbe8g0btkaCjJmfYbk O0IblFa5N2xGet14AZfXcOtaS2xFWiTkqUeptIM2jPJ5OuuYIG997vjtgApnMg== Organization: The FreeBSD Project Subject: Re: cron @shutdown In-Reply-To: <20220802150243.242AF580@slippy.cwsent.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------zUTKf5ymiKAbojA6YxKDCV2A" X-Rspamd-Queue-Id: 4LyLGx6Gycz3vS3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=m7e2 header.b=NdDtRmh3; dmarc=pass (policy=reject) header.from=delphij.net; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 2001:470:1:117::25 as permitted sender) smtp.mailfrom=delphij@delphij.net X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_BASE64_TEXT(0.10)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[delphij]; HAS_REPLYTO(0.00)[d@delphij.net]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; HAS_ORG_HEADER(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------zUTKf5ymiKAbojA6YxKDCV2A Content-Type: multipart/mixed; boundary="------------9xC076snZM3ZlQatpoiNKYM5"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Cy Schubert , Warner Losh Cc: "freebsd-arch@freebsd.org" Message-ID: Subject: Re: cron @shutdown References: <20220802145433.E2DB351D@slippy.cwsent.com> <20220802150243.242AF580@slippy.cwsent.com> In-Reply-To: <20220802150243.242AF580@slippy.cwsent.com> --------------9xC076snZM3ZlQatpoiNKYM5 Content-Type: multipart/mixed; boundary="------------ENoDMwfUfNpN9onwCryBmga0" --------------ENoDMwfUfNpN9onwCryBmga0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQoNCk9uIDgvMi8yMiAwODowMiwgQ3kgU2NodWJlcnQgd3JvdGU6DQo+IEluIG1lc3NhZ2Ug PENBTkNaZGZvOUpaekg4R2tBK2QxZGRpNmNBVGZiTjFlMCs1X2ozQUxEcG1nVDYzRVlEUUBt YWlsLmdtYWlsLmMNCj4gb20+DQo+ICwgV2FybmVyIExvc2ggd3JpdGVzOg0KPj4gLS0wMDAw MDAwMDAwMDA1NDNlNTQwNWU1NDM1Mzk2DQo+PiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47 IGNoYXJzZXQ9IlVURi04Ig0KPj4NCj4+IE9uIFR1ZSwgQXVnIDIsIDIwMjIsIDg6NTQgQU0g Q3kgU2NodWJlcnQgPEN5LlNjaHViZXJ0QGNzY2h1YmVydC5jb20+IHdyb3RlOg0KPj4NCj4+ PiBIaSwNCj4+Pg0KPj4+IERvZXMgYW55b25lIHRoaW5rIHRoZXJlIG1pZ2h0IGJlIHNvbWUg dXRpbGl0eSB3aXRoIGFuIEBzaHV0ZG93biBjcm9udGFiKDUpDQo+Pj4gIm5pY2tuYW1lIiBz aW1pbGFyIHRvIEByZWJvb3QgYnV0IGluc3RlYWQgd2hlbiBjcm9uIHNodXRzIGRvd24/DQo+ Pj4NCj4+PiBJIHBvaW50ZWQgb3V0IHRvIG9uZSBvZiBteSBjdXN0b21lcnMgdGhhdCBAcmVi b290IG1pZ2h0IGJlIGFuIG9wdGlvbg0KPj4+IGluc3RlYWQgb2YgYW4gcmMgc2NyaXB0IChv ciBpbiBoaXMgY2FzZSBhIHN5c3RlbWQgdW5pdCBmaWxlKS4gTm90IHRoYXQgYW4NCj4+PiBA cmVib290IGZvciBGcmVlQlNEIGNyb24gd291bGQgY29udHJpYnV0ZSB0byBzb2x2aW5nIGhp cyBMaW51eCBwcm9ibGVtIGJ1dA0KPj4+IG1pZ2h0IG91ciB1c2VycyBiZSBpbnRlcmVzdGVk IGluIHNvbWV0aGluZyBsaWtlIHRoaXM/DQo+Pj4NCj4+DQo+Pg0KPj4gSWYgaXQncyBzaW1w bGUgYW5kIGluY3JlYXNlcyBwb3J0YWJpbGl0eSwgSSdtIGFsbCBmb3IgaXQuDQo+IA0KPiBJ dCdzIHNpbXBsZSBidXQgdGhlcmUncyBubyBMaW51eCBlcXVpdmFsZW50LCB5ZXQuIE15IHRo b3VnaHRzIGFyZSB0bw0KPiBpbXBsZW1lbnQgaW4gRnJlZUJTRCB0aGVuIGNhbnZhcyB0aGVu IHN1Ym1pdCBhIHB1bGwgcmVxdWVzdCB0byB0aGUgTGludXgNCj4gVml4aWUgQ3JvbiBtYWlu dGFpbmVyIGFuZCBkaXNjdXNzIHdpdGggdGhlIHZhcmlvdXMgTGludXggdmVuZG9ycy4NCg0K SSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCB1cGRhdGluZyBvdXIgY3JvbiB3aXRoIE9wZW5C U0QncyBjcm9uKDgpIG9yIGEgDQpuZXdlciB2aXhpZS1jcm9uIHZlcnNpb24gZmlyc3QuICBU aGVyZSBhcmUgYSBsb3Qgb2YgaW1wcm92ZW1lbnRzIHRoYXQgDQp3b3VsZCBiZSB1c2VmdWwg Zm9yIHVzIHRvby4NCg0KUmVnYXJkaW5nIEBzaHV0ZG93biwgSSdkIHNlY29uZCBXYXJuZXIg dGhhdCBpZiBpdCdzIHNpbXBsZSB0byBpbXBsZW1lbnQsIA0Kd2Ugc2hvdWxkIGhhdmUgaXQu ICBIb3dldmVyLCB3ZSBzaG91bGQgYWxzbyBrZWVwIGluIG1pbmQgdGhhdCBkZWxheWluZyAN CnNodXRkb3duIGNhbiBiZSBiYWQgYXMgZXZlbnR1YWxseSB0aGUgc2h1dGRvd24gcHJvY2Vz cyB3b3VsZCBzZW5kIA0KU0lHS0lMTCB0byBldmVyeW9uZSwgYW5kIHRoZSB0aW1lciBzdGFy dHMgYmVmb3JlIGNyb24gcmVjZWl2ZXMgU0lHVEVSTS4gDQogIFNvIHRoZSB1c2VyICptaWdo dCogd2FudCB0aGVpciBzb2Z0d2FyZSB0byBiZSBtb3JlIHJvYnVzdCB3aXRoIGNyYXNoZXMg DQphbmQgZGV2ZWxvcGVycyBzaG91bGQgZm9jdXMgbW9yZSBvbiBob3cgdG8gbWFrZSB0aGUg c29mdHdhcmUgdG8gcmVjb3ZlciANCnF1aWNrbHkgZnJvbSBhIGNyYXNoLCBiZWNhdXNlIGNy YXNoIGNhbiBub3QgYmUgYXZvaWRlZDogaGFyZHdhcmUgaXNzdWUsIA0KdXNlciBzZW5kaW5n IFNJR0tJTEwsIGJ1Z3MsIGV0Yy4gY2FuIGFsbCBjYXVzZSBpdCB0byBjcmFzaC4gT24gdGhl IG90aGVyIA0KaGFuZCwgbWFraW5nIHRvbyBtdWNoIGVmZm9ydCB3aXRoIGhvdyB0byAicHJv cGVybHkiIHNodXRkb3duIGdlbmVyYWxseSANCm1ha2VzIHRoZSBzaXR1YXRpb24gd29yc2Us IGFuZCBzb21ldGltZXMgdGhleSBkb24ndCBjb250cmlidXRlIHRvIGEgDQpiZXR0ZXIgc3Rv cC10by1zdGFydC1hbmQtcmVhZHktdG8tdXNlIHRpbWUgY29tcGFyZWQgdG8gYSANCmNyYXNo LW9ubHktd2l0aC1mYXN0LXJlY292ZXJ5IGRlc2lnbiwgc28gd2hpbGUgaXQgY2FuIGJlIHJl YWxseSB1c2VmdWwgDQpmb3Igc29tZSBzY2VuYXJpb3MsIGl0J3MgcHJvYmFibHkgbm90IHRo ZSBiZXN0IHRoaW5nIHRoYXQgdGhlIHVzZXIgDQpzaG91bGQgZG8uDQoNCkNoZWVycywNCg== --------------ENoDMwfUfNpN9onwCryBmga0 Content-Type: application/pgp-keys; name="OpenPGP_0xE76E2D1168D7CB05.asc" Content-Disposition: attachment; filename="OpenPGP_0xE76E2D1168D7CB05.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFobtgEBEAC0Q9xkugo7ZVc1sk7RHX8yUv/4XXrlvWpoJvgKqLuSK1QYLSXS E8BtTSqqZD6SRAp59y+YvC7cOAiBz6rBDXFcobLN4pqIkcOFO0555Ns8+AYsy8s1 0pFEu3Fgwt2d/EYItamQscBPO1ZQxpFYbbVrn279T6eUSZxTY8ztVLCMDEvP/Xk8 rebDCjWfpDxs0z1I+w1slvmhJbip0Jb+N646+OXMzpHzt9imO9PMl+EG2AYH4de8 09BUHo+sJQ9V3chpdBBEBPzV7SUH00QAhqIEaXUNU/Yp+ICwjaTwLxPfIdtLIpgV lfE87k8M9OwTIc2rq3QatjW809eNQVmbY2KHbd9fp/l0p/WN4DsDxYo90ZLZhJI2 9gwwoje2mUxa4bOq6dwe3f4RVWW5ubav9On/p6QgkmyBblIajCALaav6pKbVlzsg CqxjkpeEzMRPNHebG1CvSpbp0RsKSUFFyaiIjcZ1HvBwaaU2plgjiNCh+db8DLar l9y1SDwPupg9ZAOBfE5WvvRPTXsK8+cMHubsexCuw72+KgsfD/aDQG68z4oovuKh MXP0zfFlax54qzAyE9X/eMjTL9pB+GozedWbqz1tw26Z2fh8HYc3BNo/88SBjeQ1 OlTn0wu0rXqQc1YHbXFpjxwsoJuDlknjCqXxYRY4hDUVBr5RnvNYZiXzywARAQAB zRxYaW4gTEkgPGRlbHBoaWpAZGVscGhpai5uZXQ+wsGUBBMBCgA+FiEEok+ddXrW KGfwMqGp524tEWjXywUFAluSVEgCGwMFCQmWyQAFCwkIBwMFFQoJCAsFFgIDAQAC HgECF4AACgkQ524tEWjXywXw7A/+JKVxUt9nCP0NmmZiaXCYtT54UY5//ewxbeSN zS9H4P7YcJeOUDrtm4ePGS9bqG+CSgyx2rGgxv01f8az2L0FcmTa9fjnLqLYix2V fRIAdmuzB6qjgXL3cBFpHyBiak6rBGyKW2OmEloK9DmhiM0exY5avbdNTG5BqfS1 wTgwsZmCUIT/GgHv6x2OoqVy8zxArm15Vd52VNACr5Y06IKOpkNEVrqv9E+MOEVp gz2oriRnfb4Anvo61ihSqis63yVTh3AS8PAo/ZO9hI+9gAHFQTu90JqOIcBl2Zqu din0FTKmqIMcOP751qz7GwL1GVCE7FVb2utgmWfwG4STHW96alGd7GJAi3IJ8GIN Pd5XrdH8FPA8OA4C7t/bp7EQiH4h8v3UYPYIoNy74KXDc5S9G/CeZp51EMJc0ZEF eUJajdaDmE4NChiRJzdnEN7f6xTINLBugjy0stsyulcgvfjOzaCeD06KcL2UZO71 kJvMU6E1x5PPyRoLoRSbxpNxIr1I8iPvhYjfgzIfxxj41Qd9swoxo5vCd1JIKtgf sCzK1zbd9cipd+4qfGaDo4I8/3kIa5JCTFaGdnqnd8Z6rOg8ayXQhLSYAjUPSyeT rClbmyy0DhRoyW1g0oY6ERPPkWmo7lrV+iRQfNBDJE6x1FE3iEdzJN01sTIZpweA TFET4PDOwU0EWhu2AQEQANs/Jdg3prIMst3dQNttpn5/1GqgeaTpr6RDJfTqJ41O vZKH7ZzZ42kRyWt6VULsgHMNLeIqI7v825sEAEzgdnMhmrW2HXPN0G1YPW1rsmst ifXDWtVmnB50X0KzyOoTI6OzBzsJZzyyF25rAzVeBwXZO0CFdI9pKRt9WDhyJbQd sHI7XqDnUUURxeqOPtVQAHYZU6oAy5puyUO0auI+4blCBfjIUyMURvTy8bJ2o6E/ DdzaY+Be8rPu9NsOwjURsEKXlBDiSduSP7mg+DvRo0CSCuwS9qabz5PXDGDLMUV5 sFTz0eileGqTDejRUjefKs5uyIcCsP2H4PYRhz/KgX7S3U/67hcBGkHbaO7Y+T+E hLkqURchUdZEv5OUQA3hNireh4AI72JShT8FrObGbDzqwyM0Yp7VeAQgGzn2NrPg xIbxineCRBvPBuPk+46JkVB1uMqYLcyylW4CtF7EUS7qVKJ6PaHW1fqMxuBA3s6J TqD83RMr86A52QUN/cAwfOFHp+FHpoSTPL4l7gN3LCHypjyra1ZV4NwxdDJIv1bj L+pXGbLPT+HHBSCIBVkl8tctIRzIIbsArGzyHxmF7Hq9oFDeyuaE+G+dS8JuFhUZ if+356wqOLAvCX6fqXnSzlBhNGTi+4XyYnHLS+uRieMNr6lgQE/+Ev1hJxlcczv/ ABEBAAHCwXwEGAEKACYWIQSiT511etYoZ/Ayoannbi0RaNfLBQUCWhu2AQIbDAUJ CZbJAAAKCRDnbi0RaNfLBbnQEACtXAz8ZXrIr3SWAZS8xJ5OCsQ+8WfpCTgzamdC 662L70P47TnPYhNQBj1HPFLSFQugnwkLzBRjwyxuPA5a9w11GtGU6NwRB0JHO+ng OTQ/IDWyKH3A/eJdTzJtpJmTZhlAwbNV7sqZs43MqGNaiT3xfLE39EWvDPImdCuD 0QHAYGTS3ZCr5HPRNlyQIJ4s1mB3c5XWt1R864aRAOUwYMYLuX09LIihn04/qIU8 J4Y4zL1Fbn46Yk5St0cBiJPZ758T0jiY76f6nHjeCtOTIHJKUcDEo0AQ8n7g5hP/ Y6s+vmQ1aFSF4YO8Hwjp9gnpksJfJEWxUTj/sQ6XsiEOSm1gRste2U0iu7UCjYkj ejfMW0XhH+W9XEF5fgaJtp5/zZYksFfn+w4s6X34uMOcCWfPVpnQ8B0Gh0l7pOj6 K8VGEfR6OQohEjoijrG3UU9rYa5rq4V0WD+5BzizsPKC69OgsFAIhXO/hpQxcUd9 TVg6or+qC1tvHxJNG/uRuDhJtdrEjmTybxBEddxqHSZK87TGpE2dhHzhQlzIl9XY eUk7X17bhmbzPJq39BAqBdqfYsDm560vX9DEAlxfMbOrcgrr3CY/1Kkbe8g0btka CjJmfYbkO0IblFa5N2xGet14AZfXcOtaS2xFWiTkqUeptIM2jPJ5OuuYIG997vjt gApnMg=3D=3D =3D9XGL -----END PGP PUBLIC KEY BLOCK----- --------------ENoDMwfUfNpN9onwCryBmga0-- --------------9xC076snZM3ZlQatpoiNKYM5-- --------------zUTKf5ymiKAbojA6YxKDCV2A Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEok+ddXrWKGfwMqGp524tEWjXywUFAmLqCaAFAwAAAAAACgkQ524tEWjXywUQ YA/6ApqZzl2uK21+pj6IT0DeotQmtEUg/PolljqjzHKa1JY/uU8FPnXbfF08J+M9cWJf7x4bTxh9 ArLf2PBFKQzCkUDoG2DpOy8N8Thvio1Cx5axFDQgaY97PYaAhYI9DFigZmH2fGj/iun3dv9FIlHY J3OhyPpbSVsg0F9hE0a7aa8thWb6Md6dZaaxFvqn8SJiUiHHgFrKdp0BV3A1gcLVKsAjkNIl5X3j TJaasuNdpn9KWMjAv0RbLPjorWQqlK7hjyjgtMD4hVII3fnn2RSNKX45AC/EJgzCZiUCv4C8x1Gm 9x36HNPTeRuCbztcUiPCdKM/gIVj0Vkd9R92P9F3CI8gph8MeyQTih8V6P1Vq0ZRtOIA+0lw219t j8a+PVo1Dstr5wf9CwrhTuRxvkEIMNAmAlZcIEW6zLrnFCM5BM8YjeY4LVGK4KEWiWUgwzUO5xl2 sWdfaAge0heNleoQoxhDcnbdtuI1mFf7x1nTbt5IPs4zBiGNjZZLu+yAFZ2gd3ssC1D6iRBCtyJ6 oc5qVGDPYIdwNOaRtYI9VEsbXSdk9vKl1OeZpLAQ+RcFaj/yOrWAUFZsGiawgI1AHoaFsC7P9K1K 3TH8NpW8Csxmm9M9DMyODYrDkD/hOYfRXSiJZoGYyNaED9jjjb1sKUV7FoNkVkibGjOlEgnjp17e +Jk= =6eTB -----END PGP SIGNATURE----- --------------zUTKf5ymiKAbojA6YxKDCV2A-- From nobody Wed Aug 3 06:54:33 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LyN0J46QYz4Xh50 for ; Wed, 3 Aug 2022 06:55:12 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LyN0H3cwsz419g for ; Wed, 3 Aug 2022 06:55:11 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 87EBBE4E for ; Wed, 3 Aug 2022 08:54:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1659509699; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=U09T/JrbAvwDe34pY/b8Uq7/UGGbZ3QSVKIbWWXBGEM=; b=UB+6zGQwn5+GASzQ64kZSH0Fr95BW5Xv5oyd4hvohVKIjLjnWiyNwdNtpAlFSBPQfWomkI hsYFzAxnrgBslZ3GSozwD8xM9olbOmu0zgXgxiq+g59pcV7FExDTDvN/996ie6zTjNHVOb gldMpxgCYZEO5k6t3jdpgVvBEnqRTgxTywzvFNBTKodvqimUwoHNlfIfLjv1ba9zabVz3s 30NLNedacqcPr7+qPcrFAfjglmk+HSY6GmsMQ7M8+ChkBu3amoS4M7IXA7VB/Bc3gU5qPO M5x4pFF2KJFQMH+6XxRSdcI3WbiX29lzQ2ddp2YzH34O/g94A/568PQlqP7upg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id B61CB4781 for ; Wed, 3 Aug 2022 08:54:39 +0200 (CEST) Date: Wed, 03 Aug 2022 08:54:33 +0200 Message-ID: <20220803085433.Horde.aghywmAauLjH7fJCEFFzNvn@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-arch@freebsd.org Subject: Re: cron @shutdown In-Reply-To: <20220802145433.E2DB351D@slippy.cwsent.com> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_f4H1u9XgQt8vJJvlrnF57bh"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4LyN0H3cwsz419g X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=UB+6zGQw; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[leidinger.net:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_f4H1u9XgQt8vJJvlrnF57bh Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Cy Schubert (from Tue, 02 Aug 2022=20= =20 07:54:33=20-0700): > Hi, > > Does anyone think there might be some utility with an @shutdown crontab(5= ) > "nickname" similar to @reboot but instead when cron shuts down? > > I pointed out to one of my customers that @reboot might be an option > instead of an rc script (or in his case a systemd unit file). Not that an > @reboot for FreeBSD cron would contribute to solving his Linux problem bu= t > might our users be interested in something like this? I'm a little bit puzzled... "@stop" (when cron is stopped) is easy to implement, but the use cases=20= =20 for=20this are ... IMO very limited (and I would question if another way=20= =20 of=20implementing the application logic where this is used may be better). "@shutdown" is not only a simple change to cron but also needs some=20=20 logic=20to distinguish a stop/restart of crond from a full system=20=20 shutdown.=20As such from a layering logic I would rather go with a rc=20=20 script=20instead of a cron entry. I understand that real-world ... "rules" ... can lead to situations=20=20 where=20@shutdown would make life more easy. How far do we want to go=20=20 there?=20Where do we draw a line between layering violations and stupid=20= =20 policies=20or convenience or "I don't want to talk with a colleague"=20=20 situations=20(or whatever it is)? This message is not a "no-vote", it is a "take a step back, take a=20=20 deep=20breath, and ask yourself if we really want to do that". Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_f4H1u9XgQt8vJJvlrnF57bh Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmLqG6kACgkQEg2wmwP4 2IYRIhAAhpAtEBiI9xoNzXaVjdWxlphXxR6K3R6tNPzk1rGtt33/PKwHXXUgS2AM VPMEr/CrzrTe7JkbBhLZVx9bQ+aOTdBe4gReg4kwV41Xu/NWuzhbiPIt4xCR2SH2 bEo+N/dKW8jaxCygOXryMVbD+h96HnEcpUIiZrrP9Od9lKVDgtQZcIdGI4SQbSw/ vTAIeMx4FsZR75+wW2Ux5GuYVG2PcYAel6I4RmfqTl/2QPIVR1dHN7EF/YBSuiLO /209igigWtY0T/1j3bONp0xW+tFM2osek73I1FFHAe7anOB/Vl40qt5QUn9cFmXI RcqeQB7+Nv4kxMBYmbYPaQ+hCzl9GNEAQIJtklhx043na3IgCUAXxhKH0nRgwMh6 hFbVlLUYVOlx9O2tlNilb0xo2Vx+MYFXA56kIm0lSgMGHaCPliZ33alJ0JOsvY7O MT0Lz/BVH0W6Rmm7cmJT/SGWTxqPAkyye7etGUqoCQAPeJlUbf09SHb/PM40YweA oTrkPid82HH7PYmAvZuQN5hI1WLHHnx/PczXy/fotC7L5uPRobH9p7dumeSQs2+b SdfpKBqrL+ryI3I63eswmrEEsXz9oAkkQvR0yHRcV9m6CUL07CH7IWoBw1Zedxu3 GuhK/wlPdG9qZ0eeuhmJOgVj4BZI6zPh2hq0GzoIJzB+FyMyiMQ= =S22F -----END PGP SIGNATURE----- --=_f4H1u9XgQt8vJJvlrnF57bh-- From nobody Wed Aug 3 14:12:11 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LyYhb2Cz4z4Xl6r for ; Wed, 3 Aug 2022 14:12:15 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LyYhZ1P8Wz3gc2 for ; Wed, 3 Aug 2022 14:12:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id JDdio4nHJS8WrJF6boBRB8; Wed, 03 Aug 2022 14:12:13 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id JF6ZoZzYEuJwwJF6aocmIF; Wed, 03 Aug 2022 14:12:13 +0000 X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=62ea823d a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=SWg00rOMAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=gtWtWwIOMQObqhY5BlsA:9 a=CjuIK1q_8ugA:10 a=nWvTgx2JuP7DHgfbJPXu:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 9497411E; Wed, 3 Aug 2022 07:12:11 -0700 (PDT) Received: from slippy (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id 591F1205; Wed, 3 Aug 2022 07:12:11 -0700 (PDT) Date: Wed, 3 Aug 2022 07:12:11 -0700 From: Cy Schubert To: Xin Li Cc: d@delphij.net, Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: cron @shutdown Message-ID: <20220803071211.78164688@slippy> In-Reply-To: References: <20220802145433.E2DB351D@slippy.cwsent.com> <20220802150243.242AF580@slippy.cwsent.com> Organization: KOMQUATS X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfEdRL2mZ3lmiXd5RDAGwHWQrGHRnG4s+A7xntbU1PKoQ3IxKBLd32TtGTM97f26y6UvPHYtTMfr96LFtcdpS00ouGOtmf8aDMcaEsbpcUrCfazRtdPZC RgImzHfn8jHst+S938wLf2dtSG1Jxvf9zS9qmU83wn/NdqgDeW6tZwDUgLp/fh3sJZCKvRA3fl2Ckp7x0VdasUNSGJnPzPVao+PX+/1hWdiHnx8SR3Wd3Mhf H8X++KEznRRwPoGK49MFm9UUVWqrPsflUhncDWzbMCFyGiT/yYL5nbCOYRzsqFq+ X-Rspamd-Queue-Id: 4LyYhZ1P8Wz3gc2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.79 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 2 Aug 2022 22:37:36 -0700 Xin Li wrote: > On 8/2/22 08:02, Cy Schubert wrote: > > In message > om> > > , Warner Losh writes: > >> --000000000000543e5405e5435396 > >> Content-Type: text/plain; charset="UTF-8" > >> > >> On Tue, Aug 2, 2022, 8:54 AM Cy Schubert wrote: > >> > >>> Hi, > >>> > >>> Does anyone think there might be some utility with an @shutdown crontab(5) > >>> "nickname" similar to @reboot but instead when cron shuts down? > >>> > >>> I pointed out to one of my customers that @reboot might be an option > >>> instead of an rc script (or in his case a systemd unit file). Not that an > >>> @reboot for FreeBSD cron would contribute to solving his Linux problem but > >>> might our users be interested in something like this? > >>> > >> > >> > >> If it's simple and increases portability, I'm all for it. > > > > It's simple but there's no Linux equivalent, yet. My thoughts are to > > implement in FreeBSD then canvas then submit a pull request to the Linux > > Vixie Cron maintainer and discuss with the various Linux vendors. > > I think it would be worth updating our cron with OpenBSD's cron(8) or a > newer vixie-cron version first. There are a lot of improvements that > would be useful for us too. We could look at OpenBSD's cron but the Vixie-cron, as installed on Red Hat, is IMO a regression as it doesn't implement some of the "nicknames" we already support. > > Regarding @shutdown, I'd second Warner that if it's simple to implement, > we should have it. However, we should also keep in mind that delaying > shutdown can be bad as eventually the shutdown process would send > SIGKILL to everyone, and the timer starts before cron receives SIGTERM. > So the user *might* want their software to be more robust with crashes > and developers should focus more on how to make the software to recover > quickly from a crash, because crash can not be avoided: hardware issue, > user sending SIGKILL, bugs, etc. can all cause it to crash. On the other > hand, making too much effort with how to "properly" shutdown generally > makes the situation worse, and sometimes they don't contribute to a > better stop-to-start-and-ready-to-use time compared to a > crash-only-with-fast-recovery design, so while it can be really useful > for some scenarios, it's probably not the best thing that the user > should do. This makes my suggestion regressive as there is a greater chance an end-user script would exceed the ninety second timeout. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Wed Aug 3 15:19:15 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LybB45pNQz4XvXw for ; Wed, 3 Aug 2022 15:19:24 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LybB36q5Mz3qBc for ; Wed, 3 Aug 2022 15:19:23 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 273FJG9J030333; Wed, 3 Aug 2022 08:19:16 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 273FJG3t030332; Wed, 3 Aug 2022 08:19:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202208031519.273FJG3t030332@gndrsh.dnsmgr.net> Subject: Re: cron @shutdown In-Reply-To: <20220803085433.Horde.aghywmAauLjH7fJCEFFzNvn@webmail.leidinger.net> To: Alexander Leidinger Date: Wed, 3 Aug 2022 08:19:15 -0700 (PDT) CC: freebsd-arch@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4LybB36q5Mz3qBc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-2.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[dnsmgr.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Quoting Cy Schubert (from Tue, 02 Aug 2022 > 07:54:33 -0700): > > > Hi, > > > > Does anyone think there might be some utility with an @shutdown crontab(5) > > "nickname" similar to @reboot but instead when cron shuts down? > > > > I pointed out to one of my customers that @reboot might be an option > > instead of an rc script (or in his case a systemd unit file). Not that an > > @reboot for FreeBSD cron would contribute to solving his Linux problem but > > might our users be interested in something like this? > > I'm a little bit puzzled... > "@stop" (when cron is stopped) is easy to implement, but the use cases > for this are ... IMO very limited (and I would question if another way > of implementing the application logic where this is used may be better). > "@shutdown" is not only a simple change to cron but also needs some > logic to distinguish a stop/restart of crond from a full system > shutdown. As such from a layering logic I would rather go with a rc > script instead of a cron entry. > > I understand that real-world ... "rules" ... can lead to situations > where @shutdown would make life more easy. How far do we want to go > there? Where do we draw a line between layering violations and stupid > policies or convenience or "I don't want to talk with a colleague" > situations (or whatever it is)? > > This message is not a "no-vote", it is a "take a step back, take a > deep breath, and ask yourself if we really want to do that". > > Bye, > Alexander. This message is a no-vote, based on the layering violation, but even without that I fully support this notion of asking "do we really want to do this", and "what are all the new bugs that come along". Shall @shutdown only be allow for "root" cron tables? What happens if 50 users add @shutdown entries, or one user adds a very long one, that leads me to say, yep, this has to be a "root" only entry. Well if it is root only, does this really belong in cron at all? Anyway.. I think @shutdown, @reboot, are a Bad Ideas. -- Rod Grimes rgrimes@freebsd.org From nobody Fri Aug 5 12:25:38 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LzlDr0jxLz4Xq9D for ; Fri, 5 Aug 2022 12:25:48 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [138.201.35.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LzlDq1Npyz47YR for ; Fri, 5 Aug 2022 12:25:47 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from [IPV6:2001:9e8:94a:d00:7953:23d:578a:a749] (unknown [IPv6:2001:9e8:94a:d00:7953:23d:578a:a749]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 28A362331C for ; Fri, 5 Aug 2022 12:25:40 +0000 (UTC) Message-ID: <6c1ce943-bcd8-3a34-f59c-1b60d05f23fa@rlwinm.de> Date: Fri, 5 Aug 2022 14:25:38 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: cron @shutdown Content-Language: en-US To: freebsd-arch@freebsd.org References: <20220802145433.E2DB351D@slippy.cwsent.com> From: Jan Bramkamp In-Reply-To: <20220802145433.E2DB351D@slippy.cwsent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LzlDq1Npyz47YR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 138.201.35.217 as permitted sender) smtp.mailfrom=crest@rlwinm.de 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)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:138.201.0.0/16, country:DE]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[rlwinm.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02.08.22 16:54, Cy Schubert wrote: > Hi, > > Does anyone think there might be some utility with an @shutdown crontab(5) > "nickname" similar to @reboot but instead when cron shuts down? > > I pointed out to one of my customers that @reboot might be an option > instead of an rc script (or in his case a systemd unit file). Not that an > @reboot for FreeBSD cron would contribute to solving his Linux problem but > might our users be interested in something like this? How would this interact with signaling and restarting the cron daemon? Are there status files or something similar allowing cron to tell a `pkill cron` from a `service cron restart` from a real `shutdown -p now`? From nobody Mon Aug 8 00:01:49 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M1GgR4XN3z4YDlh for ; Mon, 8 Aug 2022 00:05:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M1GgQ3Jktz3nM9; Mon, 8 Aug 2022 00:05:38 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from lapr.no.berklix.net (p3e9bc45e.dip0.t-ipconnect.de [62.155.196.94]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 27805U3L002432 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Mon, 8 Aug 2022 00:05:31 GMT (envelope-from jhs@berklix.com) Received: from lapr.no.berklix.net (localhost [127.0.0.1]) by lapr.no.berklix.net (8.16.1/8.16.1) with ESMTPS id 27801nN5027370 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 8 Aug 2022 00:01:49 GMT (envelope-from jhs@lapr.no.berklix.net) Received: (from jhs@localhost) by lapr.no.berklix.net (8.16.1/8.16.1/Submit) id 27801nru027369; Mon, 8 Aug 2022 02:01:49 +0200 (CEST) (envelope-from jhs) Message-Id: <202208080001.27801nru027369@lapr.no.berklix.net> To: Stefan Esser cc: "freebsd-arch@freebsd.org" Subject: Re: Style(9): Allow // comments From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Sun, 31 Jul 2022 07:42:44 +0200." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27367.1659916909.1@lapr.no.berklix.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 08 Aug 2022 02:01:49 +0200 X-Rspamd-Queue-Id: 4M1GgQ3Jktz3nM9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[berklix.com]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Stefan & arch@ (Apologies for delay, traveling) Stefan Esser wrote: Sun, 31 Jul 2022 07:42:44 +0200 > Am 31.07.22 um 01:25 schrieb Julian H. Stacey: > > Beware // as a delimeter in calendar files, exaples below. > > Nov 5 Fireworks in UK https://en.wikipedia.org/wiki/Guy_Fawkes_Night > > > > I have 248 lines match on > > http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/usr.bin/calend= ar/ > > find . -type f | xargs grep // | grep http | grep -v /no_customise/ = | wc -l > > > > Most http[s]:// are in commented out blocks, but some are uncommented,= eg: > > > > Oct Sun-1 Munich Oktoberfest ends http://www.oktoberfest.de > > /* Not sure if exact algorithm, probably first Sun. in Oct, > > * but might be Sunday of 1st full weekend in Oct? > > * I've kept a log to later deduce, see > > * http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/usr.bin= /calendar/calendars/de_DE.ISO8859-1/bavaria/munich/calendar.other > > * Start date is more problematic, being > > * Saturday with 16 days to end on Sunday. > > * & Parade as Friday with 17 days before end, > > * An easter-16 type fuctionality would be nice. > > */ > > I am not sure what you are trying to say with your comment ... > > For one thing, calendar files are not C source code, which is the subjec= t > of the proposed change to allow C++ style single line commends. OK Thanks > And I did not see any issues with the use of // in URLs in calendar file= s > in my testing. I had problems before with numerous of my own calendar files = (on hosts from 9.2-rel to current), & some were // related, ( Maybe I'd re-introduced // usage in my calendars, hoping to migrate my old hosts to newer releases, then got stuck on old releases. Now I'm travelling with laptop, other (non calendar) problems forced me back from current to stable, & stable to 12.3-release, with a 9.3 fallback bootble, & no up to date current. When I return I'll have a 9.2 as well again, & a current sometime later again. ) Before my earlier post, I checked man calendar (on 12.3-rel, & as // wasn't listed, just /* */, & as I want my calendars to run on 9.2 (& way older back to 4.11 & 6.4) through current, I purged all my // comments leaving just // as text in http://www etc. > I had extended the parsing of calendar files to reintroduce conditional > sections, definitions, and comments as previously implemented by process= ing > by the traditional C preprocessor, Nice. I'd half forgotten that. > and I have been waiting for your feedback > on whether these features work correctly. Apologies, I've been distracted by constant time wasters starting with Brexit. I trawled my mail archive, & found one mail to you re. calendar of Sun, 25 Oct 2020 01:35:07 +0200, if there's others you'r waiting on, please resend to me. > The calendar program treats // as the start of a comment only at the beg= inning > of a line or if it follows white space. This detail was missing in the c= alendar > man page and I have just added it on -CURRENT. Useful, Noted to my ~/.calendar/calendar so I see it on older releases. > Please let me know if calendar files are not parsed as expected and as > documented. Thanks, will do. > Regards, STefan Cheers, -- = Julian Stacey http://berklix.com/jhs/ http://stolenVotes.uk Arm Ukraine, Zap killer Putin, grain & fuel loss hits poorest. From nobody Mon Aug 8 08:48:25 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M1VGh4fctz4YXF7 for ; Mon, 8 Aug 2022 08:48:28 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M1VGh45Tnz3NbQ; Mon, 8 Aug 2022 08:48:28 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659948508; 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=80PfytZNxm5r2LSInXXXNLYEUGEVk4E2PxOrM882Ua4=; b=libbqsxJpXoUz7Xo+pD+KVPBY9HfWDdHIHbh0Z8kiYF0m7hKCt7IR0W8wpNOU34Q1iTkIp cAhQ7Y0Fy3kxI5mbFjRqihpH91jyTtoiPGOhaKFIUddWcfqlPfVpfRDVxYomCoaJwG1Ktp AeW0P7deXT991PYaWdX1XSohIOw/Uur1LgBfLKbFN8itM9lX+evJB84AZBZcOHxQiwvtc/ jbeQ7228A2TZe3J88PuLb8Pnt9oQrkGIiOtFBLW1DJ+V+7leujgmhaN1LSiFhboAKqpF1D wXt14EFc+YR5oDkIDAcXQ67sFUMEVBYaeA+f/L3NPPldQj+PuYypzl68QH59hw== Received: from [IPV6:2003:cd:5f1a:d200:51ed:194c:fb1c:a3d5] (p200300cd5f1ad20051ed194cfb1ca3d5.dip0.t-ipconnect.de [IPv6:2003:cd:5f1a:d200:51ed:194c:fb1c:a3d5]) (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: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M1VGg5VppzpdY; Mon, 8 Aug 2022 08:48:27 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <918d22a0-a009-d718-6bfb-32f6338e332e@FreeBSD.org> Date: Mon, 8 Aug 2022 10:48:25 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.1.1 From: Stefan Esser Subject: Re: Style(9): Allow // comments Content-Language: de-DE, en-US To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" References: <202208080001.27801nru027369@lapr.no.berklix.net> In-Reply-To: <202208080001.27801nru027369@lapr.no.berklix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659948508; 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=80PfytZNxm5r2LSInXXXNLYEUGEVk4E2PxOrM882Ua4=; b=oVqWHyu7lA+FNfEZheTz8gE2NfgqnoHudI6T2/gs2yeihDAPmlK2TX9t3+77Mu8LRwfdq/ kobYRfz/RCGOrwcLqyfU4viVZLkvHkoBHBEvQUlyLjf+zR3ELELxhBoXs73zewxsk8hg5l 1DwT6Cs4Th3bURRCCu3PlT3Ad/wUIJL7AgTSN+WaYPV2GUkh3+QhYENU0L62psu5cprPI0 h5uNX+o7ZpJ4K9NyYDCOPL0CYqPYg4aX2V8zYAfRrnB1VLkjzxgUSSvD3CtDLjyU93haGP kxKDufGc4sc49qYrx7m+AFWFT1VJinz96IVG6egghJbIZdCJ/JHrny/16VZbVQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659948508; a=rsa-sha256; cv=none; b=Y/2gb/vL0rLvdbMnpCG5VGbJ7FkNV6+lJj+jfIiqJk4Ydzt+DP5oopzae8S3C0+Rioih8n N8cYIpwrK8shCbtlxC5fBcXHT0XBg++3uMVgq1xe8CvZOX4q74IOy4fmICxzd732ej9T0/ kL0Z++DEcJZx6NilZFWenW3wicsAkVMLi/5WedqL7ZEF3yS3iQAGFcYivrNXi2PQAzTR8n Z5yCQlEWPSpKCUNcQJx/b7msmQ65coMo9WUiZWSAVaLGKkl+625f4jQWPRyr+AMw6/hY7c Ky2wrB88W9HROmwPhfasIuOE9u5us4oGE52iORf3dyBl4U2qTQbUfUmP4xPiIA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Am 08.08.22 um 02:01 schrieb Julian H. Stacey: > Hi Stefan & arch@ > (Apologies for delay, traveling) > > Stefan Esser wrote: Sun, 31 Jul 2022 07:42:44 +0200 [...] >> And I did not see any issues with the use of // in URLs in calendar files >> in my testing. > > I had problems before with numerous of my own calendar files > (on hosts from 9.2-rel to current), & some were // related, ( > Maybe I'd re-introduced // usage in my calendars, hoping > to migrate my old hosts to newer releases, then got stuck > on old releases. > Now I'm travelling with laptop, other (non calendar) problems > forced me back from current to stable, & stable to 12.3-release, > with a 9.3 fallback bootble, & no up to date current. When > I return I'll have a 9.2 as well again, & a current sometime > later again. ) Only very rudimentary pre-processing of calendar entries was implemented in the calendar program between September 2013 and October 2020, due to the removal of piping through the traditional C pre-processor. The improved parsing of C pre-processor commands has been merged to FreeBSD-12, but not to FreeBSD-11 and before. On older releases I'd suggest to use the deskutils/calendar port to provide a version that parses calendar files identical to the version in -CURRENT. > Before my earlier post, I checked man calendar (on 12.3-rel, & as // > wasn't listed, just /* */, & as I want my calendars to run on 9.2 > (& way older back to 4.11 & 6.4) through current, I purged all my // > comments leaving just // as text in http://www etc. I'm not sure that the calendar port can be built on very old FreeBSD releases. IIRC, I have tested it on FreeBSD-11, some time ago, but not on any prior version. The calendar port depends on the calendar-data port, which provides updated entries for EoL FreeBSD releases, too. But it depends on ICONV features, since the entries have been converted to UTF-8 for easier maintenance. [...] > Apologies, I've been distracted by constant time wasters starting > with Brexit. I trawled my mail archive, & found one mail to you re. > calendar of Sun, 25 Oct 2020 01:35:07 +0200, if there's others you'r > waiting on, please resend to me. Yes, that's part of the mail thread I was thinking of ... I took no reply as "it's working well enough for me" ;-) >> The calendar program treats // as the start of a comment only at the beginning >> of a line or if it follows white space. This detail was missing in the calendar >> man page and I have just added it on -CURRENT. > > Useful, Noted to my ~/.calendar/calendar so I see it on older releases. I have just updated the deskutils/calendar port to match -CURRENT. The only change was the better description of // in the man page. >> Please let me know if calendar files are not parsed as expected and as >> documented. > > Thanks, will do. Please send examples of entries that do not parse as expected. I have not worked on the parsing of calendar entries for a while, but if something is missing or not working as expected, I'll put it on my ToDo list. One feature that has been requested (but is not trivial to implement, given the structure of the code) is correct processing of UK bank holidays that fall on a weekend. (The same logic would be applicable to e.g. Japanese bank holidays, too.) Regards, STefan From nobody Thu Aug 11 03:54:24 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M3CcF5m9kz4YY5D for ; Thu, 11 Aug 2022 03:54:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M3CcD5pnFz3ycW for ; Thu, 11 Aug 2022 03:54:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x931.google.com with SMTP id f15so6531536uao.12 for ; Wed, 10 Aug 2022 20:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=VOOO0iuYvWTxwpcJ+jAaKta2xFQriAacjZDFuaFtzn8=; b=jbT3eMA1A3TjUsU0j/O5qv4eZjzbOcoOs3i/+fLFgmivi1gf0KDEXHT4eHdv16BF5N 2jjHNXIhvVeEegaRn2EvtFoqMUFDiqGZo6oqgVJ1TgEe6dI/+WtBFQAaM7ZNLWg/xktA zEnOXVTdCPNRMt+VKhUG9h7cHMa4Kt6lwgpHtdpdmKZq5MYjJkDe5wcwe1PFVTH0Y2pB 4DZQYvSW9Ydav/vCFiz46kLjVF0Ktm1rVo15C2CWqN2aScMVAUXfN6iT643yBJyxRc8G VlkMvH3o4bmZoKUwJD/4Say625/7Hn6BCSAhvbwxTxpC3zoshlgzkT/cILYp5GindMk9 npJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=VOOO0iuYvWTxwpcJ+jAaKta2xFQriAacjZDFuaFtzn8=; b=QQT2kNuxZWM0nhUuuk05xfXIT9gqWv7s17Bxwa2XrgAUTgyQXInBpY9i3lJMGz37B4 qZIxsoWZUWF1TxFt4BLQYdjnjzVQs5ohUmrb6risqEWYuMq9mbbGx75mKacd7zsfT1vt mzSXb9+vBb+w9MGDtE++r5MdwhPJn1i+ymkZbR2O0ibOv8FimGNPqXCvpVWUtfOjGc9s 13hfvHqOODGufsRb5qfLNQZy59dA6a6R7euSd9QRMNnHGnHC1BwWYvPJe8DZpd+QRwWo R0l2QJlwww+h2T2NNCRWoicUBNdnUxJSEN0wAs6+go83pTYTNEXjw7VxesN00zm8mnUI 7fXg== X-Gm-Message-State: ACgBeo3ZPbpMD4zve6BL+5OY4hrHUw8x2gI+nswj6h6L6o1/+L5qxKE3 GhLZ5eduksWcCenrUb4pB9Djn7MkchQGTUjPeUo6VHLsJNs= X-Google-Smtp-Source: AA6agR6QPCj4iHwEeuwuVYF9SnHIGi6pt+lvNh3vba2gQRExoHOGaRp2zVpmMhsieV7yO0Vz3UHCF0jW4aDM5pIW338= X-Received: by 2002:a05:6130:112:b0:38c:4226:62f2 with SMTP id h18-20020a056130011200b0038c422662f2mr13441046uag.82.1660190075391; Wed, 10 Aug 2022 20:54:35 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Wed, 10 Aug 2022 21:54:24 -0600 Message-ID: Subject: BIOS /boot/loader is full, time to make some hard choices To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000b4247305e5ef1fca" X-Rspamd-Queue-Id: 4M3CcD5pnFz3ycW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=jbT3eMA1; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::931) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::931:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000b4247305e5ef1fca Content-Type: text/plain; charset="UTF-8" Greetings, I just wasted a day chasing a problem with /boot/loader being too large. Due to a number of limitations in our infrastructure, we have a hard limit of 640k hard limit of total memory usage (though we can use upper memory for things like cache). 640k includes all the 'text' of the loader, plus btx, plus data, bss and stack. The BIOS calls we make are limited to 1MB due to calling them in 16-bit mode and needing to use SEGMENT:OFFSET addressing for various addresses (which on the IBM-PC means 640k). So, we're stuck with a limit of about 510,000 bytes for /boot/loader. Up through at last FreeBSD/12 (2020) /boot/loader was about 330kB. Now we're over 500kB due to a lot of extra things that have happened since then: frame buffer, OpenZFS being larger and pulling in more crypto and decompression software, and new filesystems. Between them all, we're pushing the hard limits. Now, we could in theory allow loading in high memory, have loadable modules in the loader, etc. I don't like this idea because we're going to kill BIOS in a few years and all these things add extra hair to a poorly tested, less well supported path. We need to subset what's in the BIOS loader. We need to make more things optional, and we need to set a policy to know how to choose between this and that when (not if) we run out of space again. I plan on making it easier to compile out certain file systems globally, as well as certain large features (possibly also some crypto / decompression algorithms). The policy I'm proposing is to include as many filesystems, crypto and compression in the boot loader that fit, in that order. And then other features as space allows. This means that /boot/loader.efi will have all these things (since there's no limits there), but for /boot/loader (BIOS) we'll have a subset. If we still want to have the graphics support in the BIOS loader for the installer, we'll have to leave out filesystem support, crypto support, etc. For the cd image and/or the memstick image this is fine: we only need to boot off of UFS/CD9660 (since we don't build ZFS images yet), so we can have the graphics support, but since we install so many different filesystems, with different features for crypto and/or decompression, we may need to skip graphics for the default /boot/loader we install for BIOS booting. So, since we still have a little time, we have time to talk about the future we want, but *I* also have only a limited amount of time to do tooling here. Doing build stuff is in scope. Reworking things, say, so we can have loadable modules likely isn't. Warner --000000000000b4247305e5ef1fca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I just wasted a day chasing = a problem with /boot/loader being too large.

Due t= o a number of limitations in our infrastructure, we have a hard limit of 64= 0k hard limit of total memory usage (though we can use upper memory for thi= ngs like cache). 640k includes all the 'text' of the loader, plus b= tx, plus data, bss and stack. The BIOS calls we make are limited to 1MB due= to calling them in 16-bit mode and needing to use SEGMENT:OFFSET addressin= g for various addresses (which on the IBM-PC means 640k).

So, we're stuck with a limit of about 510,000 bytes for /boot/l= oader. Up through at last FreeBSD/12 (2020) /boot/loader was about 330kB. N= ow we're over 500kB due to a lot of extra things that have happened sin= ce then: frame buffer, OpenZFS being larger and pulling in more crypto and = decompression software, and new filesystems. Between them all, we're pu= shing the hard limits.

Now, we could in theory all= ow loading in high memory, have loadable modules in the loader, etc. I don&= #39;t like this idea because we're going to kill BIOS in a few years an= d all these things add extra hair to a poorly tested, less well supported p= ath.

We need to subset what's in the BIOS load= er. We need to make more things optional, and we need to set a policy to kn= ow how to choose between this and that when (not if) we run out of space ag= ain. I plan on making it easier to compile out certain file systems globall= y, as well as certain large features (possibly also some crypto / decompres= sion algorithms).

The policy I'm proposing is = to include as many filesystems, crypto and compression in the boot loader t= hat fit, in that order. And then other features as space allows. This means= that /boot/loader.efi will have all these things (since there's no lim= its there), but for /boot/loader (BIOS) we'll have a subset. If we stil= l want to have the graphics support in the BIOS loader for the installer, w= e'll have to leave out filesystem support, crypto support, etc. For the= cd image and/or the memstick image this is fine: we only need to boot off = of UFS/CD9660 (since we don't build ZFS images yet), so we can have the= graphics support, but since we install so many different filesystems, with= different features for crypto and/or decompression, we may need to skip gr= aphics for the default /boot/loader we install for BIOS booting.
=
So, since we still have a little time, we have time to talk = about the future we want, but *I* also have only a limited amount of time t= o do tooling here. Doing build stuff is in scope. Reworking things, say, so= we can have loadable modules likely isn't.

Wa= rner

--000000000000b4247305e5ef1fca-- From nobody Mon Aug 15 18:07:21 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M62LP5gc0z4Zdx8 for ; Mon, 15 Aug 2022 18:07:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M62LP0ZlPz43nl for ; Mon, 15 Aug 2022 18:07:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id NbR5ohCrfSp39NeUloncBU; Mon, 15 Aug 2022 18:07:23 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id NeUkolXRGGRNlNeUloHqPt; Mon, 15 Aug 2022 18:07:23 +0000 X-Authority-Analysis: v=2.4 cv=Sfrky9du c=1 sm=1 tr=0 ts=62fa8b5b a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=IFAQD64IciCuwa0SpHkA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id DB8A532B; Mon, 15 Aug 2022 11:07:21 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id AE83B126; Mon, 15 Aug 2022 11:07:21 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Jan Bramkamp cc: freebsd-arch@freebsd.org Subject: Re: cron @shutdown In-reply-to: <6c1ce943-bcd8-3a34-f59c-1b60d05f23fa@rlwinm.de> References: <20220802145433.E2DB351D@slippy.cwsent.com> <6c1ce943-bcd8-3a34-f59c-1b60d05f23fa@rlwinm.de> Comments: In-reply-to Jan Bramkamp message dated "Fri, 05 Aug 2022 14:25:38 +0200." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Aug 2022 11:07:21 -0700 Message-Id: <20220815180721.AE83B126@slippy.cwsent.com> X-CMAE-Envelope: MS4xfH3nizNa9cxwPSwRW69kCFUYvG/yAdTECDmp9mpB9i8V4FEjogwADObfRT3EaNbshWn+9HwUsBhb0YM/crxY+lEmynAedWjSE8HKiCsFnJ5ouyNHQpCp icVsxE44sDtlh1XKeYD9XUxzt8iyeuDXpSobkIzizdTEM99iwTXq4H0ES9rH2F1jR/PwF4L2kQJQhKKEfNGpr7o9SCzBDLsS7UhYlacaMMaCqM6HDwq7Pvzx X-Rspamd-Queue-Id: 4M62LP0ZlPz43nl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N In message <6c1ce943-bcd8-3a34-f59c-1b60d05f23fa@rlwinm.de>, Jan Bramkamp write s: > On 02.08.22 16:54, Cy Schubert wrote: > > Hi, > > > > Does anyone think there might be some utility with an @shutdown crontab(5) > > "nickname" similar to @reboot but instead when cron shuts down? > > > > I pointed out to one of my customers that @reboot might be an option > > instead of an rc script (or in his case a systemd unit file). Not that an > > @reboot for FreeBSD cron would contribute to solving his Linux problem but > > might our users be interested in something like this? > How would this interact with signaling and restarting the cron daemon? > Are there status files or something similar allowing cron to tell a > `pkill cron` from a `service cron restart` from a real `shutdown -p now`? > Typically cron is rarely restarted. However, at $JOB it is expected that scripts that are called in this manner should use some kind of lock file to avoid starting another instance of the applicaion. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Thu Sep 8 10:50:28 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MNbWF32xBz4bp8X; Thu, 8 Sep 2022 10:50:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MNbWD2Stgz4065; Thu, 8 Sep 2022 10:50:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.232.223.95]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6361726050E; Thu, 8 Sep 2022 12:50:31 +0200 (CEST) Message-ID: Date: Thu, 8 Sep 2022 12:50:28 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US To: FreeBSD Current , "freebsd-arch@freebsd.org" From: Hans Petter Selasky Subject: [RFC] Proposal adding new sorting algorithm, bsort() to libc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MNbWD2Stgz4065 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org 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)[-1.000]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org,freebsd-current@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[selasky.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N See: https://reviews.freebsd.org/D36493 Looking through base I see qsort() being used in places it shouldn't be used. For example in fts_open(). If for example you fill a directory with 64k simply numerical file names in the wrong order and ask fts_open() to sort these ascending for example, qsort() will end stuck for a long-long time. So either switch to mergesort, or if malloc() is unacceptable, use something like bsort() which I've implemented in the above review as a drop-in replacement for qsort(). The advantage with bsort() is that in can be CPU accelerated, due to fixed comparison patterns. Quick sort is not always a quick sorting algorithm. Quick means simple, and not clever this time. For the qsort's bad pattern, sorting 4096 entries 1024 times in a row took: qsort: 15 seconds bsort: 230 milliseconds (non-CPU accelerated) mergesort: 30 milliseconds The problem with qsort() is that as the array size grows, the time consumption just gets worse and worse for the bad-patterns. Sorry there is no nice and fancy paper yet about this. --HPS From nobody Thu Sep 8 11:37:16 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MNcYG54jzz4bv47; Thu, 8 Sep 2022 11:37:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MNcYF5rfRz44dX; Thu, 8 Sep 2022 11:37:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.232.223.95]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 631E4260525; Thu, 8 Sep 2022 13:37:20 +0200 (CEST) Message-ID: <6883e9bf-fce2-4514-e8b4-0689b4ecf6e4@selasky.org> Date: Thu, 8 Sep 2022 13:37:16 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [RFC] Proposal adding new sorting algorithm, bsort() to libc Content-Language: en-US From: Hans Petter Selasky To: FreeBSD Current , "freebsd-arch@freebsd.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MNcYF5rfRz44dX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org,freebsd-current@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[selasky.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 9/8/22 12:50, Hans Petter Selasky wrote: > See: > https://reviews.freebsd.org/D36493 > > Looking through base I see qsort() being used in places it shouldn't be > used. For example in fts_open(). > > If for example you fill a directory with 64k simply numerical file names > in the wrong order and ask fts_open() to sort these ascending for > example, qsort() will end stuck for a long-long time. So either switch > to mergesort, or if malloc() is unacceptable, use something like bsort() > which I've implemented in the above review as a drop-in replacement for > qsort(). The advantage with bsort() is that in can be CPU accelerated, > due to fixed comparison patterns. > > Quick sort is not always a quick sorting algorithm. Quick means simple, > and not clever this time. > > For the qsort's bad pattern, sorting 4096 entries 1024 times in a row took: > > qsort: 15 seconds > bsort: 230 milliseconds (non-CPU accelerated) > mergesort: 30 milliseconds > > The problem with qsort() is that as the array size grows, the time > consumption just gets worse and worse for the bad-patterns. > > Sorry there is no nice and fancy paper yet about this. > > --HPS > Hi, Also see the "kill_ls.c" test program I attached to D36493, which shows the direct affect of qsort() on the regular "ls" command! --HPS From nobody Thu Sep 8 13:52:08 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MNgXy3nggz4c8cY for ; Thu, 8 Sep 2022 13:52:18 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MNgXx47jFz3KFw for ; Thu, 8 Sep 2022 13:52:17 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.16.1/8.16.1) with ESMTPS id 288Dq9TT024585 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 8 Sep 2022 13:52:09 GMT (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 288Dq8Ot024584 for freebsd-arch@freebsd.org; Thu, 8 Sep 2022 15:52:08 +0200 (CEST) (envelope-from fuz) Date: Thu, 8 Sep 2022 15:52:08 +0200 From: Robert Clausecker To: "freebsd-arch@freebsd.org" Subject: Re: [RFC] Proposal adding new sorting algorithm, bsort() to libc Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4MNgXx47jFz3KFw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[fuz.su]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > See: > https://reviews.freebsd.org/D36493 Looks interesting! Any particular reason you add a new function to the libc instead of just replacing qsort(3) with the new algorithm? Yours, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Thu Sep 8 14:19:25 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MNh8N5Py2z4cCMS for ; Thu, 8 Sep 2022 14:19:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MNh8M0jygz3Lnh for ; Thu, 8 Sep 2022 14:19:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.232.223.95]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id ECCEF2603D2; Thu, 8 Sep 2022 16:19:27 +0200 (CEST) Message-ID: <1e609631-37e2-3818-37e3-72773758ff40@selasky.org> Date: Thu, 8 Sep 2022 16:19:25 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [RFC] Proposal adding new sorting algorithm, bsort() to libc Content-Language: en-US To: Robert Clausecker , "freebsd-arch@freebsd.org" References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MNh8M0jygz3Lnh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[selasky.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 9/8/22 15:52, Robert Clausecker wrote: >> See: >> https://reviews.freebsd.org/D36493 > > Looks interesting! Any particular reason you add a new function to the > libc instead of just replacing qsort(3) with the new algorithm? > > Yours, > Robert Clausecker > Hi, It's a good question. My plan was first to establish the concept about bsort() and then at some point remove qsort() and make those qsort() functions symbol aliases for bsort(). There are several write-ups about "trying to fix qsort()". Here is a link for one of them: https://www.raygard.net/2022/02/27/Re-engineering-a-qsort-part-4/ The question is, if there is a fix for qsort() in FreeBSD, will there be a fix in other operating systems too? That's one argument for giving bitonic sort an own name. --HPS From nobody Sun Sep 11 23:25:31 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQm7D32S3z4bjVM for ; Sun, 11 Sep 2022 23:25:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MQm7C3fhfz3hn2 for ; Sun, 11 Sep 2022 23:25:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92f.google.com with SMTP id u14so2571021ual.3 for ; Sun, 11 Sep 2022 16:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=sG3o+GQ79SMG0t29aDFdKW5dIELeFe5BsAQRR5fWclc=; b=dcMjblK/rDj+5XR3d0PHx+XP4sImmzc9ukXaUlpO/4diTMZaCEBuieL/FdLysZ3Mn7 jAKn/sgZZWoJWlVdepJwW7kGWkB+drZelajydx/5k5Cfj2UeBGWu5wK924xvVR5N+pZN RTIOsGY+zC/7aIUjHwIVVxX+4Vr/Bzprod94I4QGqTawmeZPw3ysynoujiSD/3Gimn93 82JPqikRx3kA3GpuUgeILxQLPPe64TdY+xTizRCz5fyZ9tUfDTMJjGfszSXoTDLwTRm2 zG0Dynzr5VfDnktfI+JHkvKBTlZpHxEyKctFsY9XTYZLCdxQSCRE0W82W3GOARw00Zby QeiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=sG3o+GQ79SMG0t29aDFdKW5dIELeFe5BsAQRR5fWclc=; b=4GzWey9Z7kzxA/SEzLOMoY+9teLKHNJsD3X32RAY7AaY+ixMaeCgVeBiCWkkTVeAOZ AupR8tris2AEa9JylDl9Z5pr6F5osCwyQgCWL7mYSe1AhspZFHkG7/rvocNxn4kKl9G2 I2Sy5xY37wJByL1VkX7xwcU0K4B2iq1CfBP4JoS7WHwN2b8NaWbh6IdzaMiXblkHX/0T vJ69m/CAo9wW1NNuPU1cdq/6dNbhgUhPJoKZjOy6rETLMDpkUqWo8217CcTTjVdsXKoy OCD1jNZFXzkH8vXjdchmn+kT+XMH90IrOkQtOkv1XgqdL9KElbQj6RWXPC0kM7Vm/n7D aKZQ== X-Gm-Message-State: ACgBeo0+ctC8PVwKp4Xp3W1mmUtuv8ajrRhvYIoJTB+nynHf0KMq95b7 26dD1nw5QZNZ0TJS45Zx93QyfujLVKbPaWw9SE/spyEwUrGjVw== X-Google-Smtp-Source: AA6agR47aUmUF6rqmBLweObVzg9ccxT+eKqTY+tnKHc07voQvZwXt89myKrWodDcgHo6KNsBaSOdepup53KrnVoxmLc= X-Received: by 2002:ab0:3bc6:0:b0:381:c4db:ef5 with SMTP id q6-20020ab03bc6000000b00381c4db0ef5mr8566479uaw.81.1662938741942; Sun, 11 Sep 2022 16:25:41 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Sun, 11 Sep 2022 17:25:31 -0600 Message-ID: Subject: Removing splxxx functions To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000ff41bd05e86f1898" X-Rspamd-Queue-Id: 4MQm7C3fhfz3hn2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="dcMjblK/"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92f:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000ff41bd05e86f1898 Content-Type: text/plain; charset="UTF-8" I intend to remove all the splxxx functions. Firewire, syscons, smbfs and tpm are the only things that use them. I plan on copying the function definitions to relevant header files... Or just deleting the function calls since they've been a nop now just shy of two decades (depending on how you count things). I'll leave it to others to decide if any of these should be deprecated in a separate thread. Comments? Warner --000000000000ff41bd05e86f1898 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I intend to remove all the splxxx functions.

Firewire, syscons, smbfs and tpm are the only=C2=A0things that use th= em.

I plan on copying the function definitions to = relevant=C2=A0header files... Or just deleting the function calls since the= y've been a nop now just shy of two decades (depending on how you count= things).

I'll leave it to others to decide if= any of these should be deprecated in a separate thread.

Comments?

Warner

--000000000000ff41bd05e86f1898-- From nobody Mon Sep 12 06:27:46 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQxVQ4YFpz4cZQW for ; Mon, 12 Sep 2022 06:27:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MQxVP1Cdbz3Ggs for ; Mon, 12 Sep 2022 06:27:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 1D5EF89281; Mon, 12 Sep 2022 06:27:48 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 28C6RlGm029212 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 12 Sep 2022 06:27:47 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 28C6RkOl029211; Mon, 12 Sep 2022 06:27:46 GMT (envelope-from phk) Message-Id: <202209120627.28C6RkOl029211@critter.freebsd.dk> To: Warner Losh cc: "freebsd-arch@freebsd.org" Subject: Re: Removing splxxx functions In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29209.1662964066.1@critter.freebsd.dk> Date: Mon, 12 Sep 2022 06:27:46 +0000 X-Rspamd-Queue-Id: 4MQxVP1Cdbz3Ggs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FREEFALL_USER(0.00)[phk]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] X-ThisMailContainsUnwantedMimeParts: N -------- Warner Losh writes: > I intend to remove all the splxxx functions. > [...] > Comments? Finally! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Mon Sep 12 09:15:55 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MR1DJ5CBhz4by2G for ; Mon, 12 Sep 2022 09:16:00 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MR1DH72Xyz3XwZ for ; Mon, 12 Sep 2022 09:15:59 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: (Authenticated sender: gnn@neville-neil.com) by mail.gandi.net (Postfix) with ESMTPSA id 2F3001BF212; Mon, 12 Sep 2022 09:15:55 +0000 (UTC) From: George Neville-Neil To: Poul-Henning Kamp Cc: Warner Losh , freebsd-arch@freebsd.org Subject: Re: Removing splxxx functions Date: Mon, 12 Sep 2022 10:15:55 +0100 X-Mailer: MailMate (1.14r5852) Message-ID: In-Reply-To: <202209120627.28C6RkOl029211@critter.freebsd.dk> References: <202209120627.28C6RkOl029211@critter.freebsd.dk> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4MR1DH72Xyz3XwZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::228 is neither permitted nor denied by domain of gnn@freebsd.org) smtp.mailfrom=gnn@freebsd.org X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::228:from]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; DMARC_NA(0.00)[freebsd.org]; FREEFALL_USER(0.00)[gnn]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12 Sep 2022, at 7:27, Poul-Henning Kamp wrote: > -------- > Warner Losh writes: > >> I intend to remove all the splxxx functions. >> [...] >> Comments? > > Finally! > Do it! Best, George From nobody Mon Sep 12 09:30:04 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MR1Xk4rVLz4c0pY for ; Mon, 12 Sep 2022 09:30:14 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MR1Xj6zWFz3bmC; Mon, 12 Sep 2022 09:30:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.232.223.95]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2EE8A260276; Mon, 12 Sep 2022 11:30:06 +0200 (CEST) Message-ID: Date: Mon, 12 Sep 2022 11:30:04 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: Removing splxxx functions Content-Language: en-US To: George Neville-Neil , Poul-Henning Kamp Cc: Warner Losh , freebsd-arch@freebsd.org References: <202209120627.28C6RkOl029211@critter.freebsd.dk> From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MR1Xj6zWFz3bmC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org 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)[-1.000]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[selasky.org]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 9/12/22 11:15, George Neville-Neil wrote: > > > On 12 Sep 2022, at 7:27, Poul-Henning Kamp wrote: > >> -------- >> Warner Losh writes: >> >>> I intend to remove all the splxxx functions. >>> [...] >>> Comments? >> >> Finally! >> > > Do it! > +1 --HPS From nobody Tue Sep 20 14:18:44 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MX3Yx54Ddz4cMJP for ; Tue, 20 Sep 2022 14:18:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MX3Yx43glz3Zys for ; Tue, 20 Sep 2022 14:18:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4MX3Yx37DWzl6b for ; Tue, 20 Sep 2022 14:18:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 28KEIjmj001060 for ; Tue, 20 Sep 2022 14:18:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 28KEIjOu001059 for arch@FreeBSD.org; Tue, 20 Sep 2022 14:18:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: arch@FreeBSD.org Subject: [Bug 121073] [kernel] [patch] run chroot as an unprivileged user Date: Tue, 20 Sep 2022 14:18:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663683525; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/2wBAeSlbuUuC4HIIq7c9AQ/ItoJpknpwfWRzkGLb3o=; b=gxwP2kX5p80iKMe4x50KW+oD7FE7F1ptBjAGgptveMlDgxuoTCd3xTKVTWKdGrK1xmSu2z VnqerEiWd6JPimiEN3kQXS0xiWSpmWhS5l9aXJgRXg0uBlDR+6ma53dFjie7OxBMpIZTgo 9HYnPN8M8zsvWMFyNfSy4BYfOetT2gI+44fdh/6GIKojDY+fqvJLBOW74ylx6VaoxVFf5j uVnWJk0jC30F3QkNctm9RU4mTVEAZk6Vaw0kUsfCYZXM6igdT2PmcpQ/jaazd81cskKMhc R9vicMexNGukU77wPSgh1zN1lw+zPU5nmGCUlPNWD1edfj+Z3RC2KDaQGEquKw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663683525; a=rsa-sha256; cv=none; b=X4i+WpnYa11uNog89HWvYc6xeD4Pa/8WTJGsgxMMNoYBw1f79iXrncTAotc9koDEwDv6kl zQnqotprkELXc9/L+fT5DKnqlog3nmcAMmZFnTegr/RsJlrugd74zalrQuB1AjPZhswOHA 5Zvc8tbQOk8p4NgAh7VVQ2qpEzK/9OZu4DaKxLZoNNR/Yr1ZJR4w2KYMTMXeGDgtzr4lAO lA1hzQzq3aO9d8am6f7xaPWm4Hh9KDmABo5rkiaRqL+6xEgLIohJlPV8qMgYl7hJqEa63m nIN6uGV9o1hDOlsMlnBbIq7S2FE8S+IiV4rdLjzRxMVAYMFrOouitq2hT99Sgw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D121073 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |Overcome By Events --- Comment #13 from Ed Maste --- Implemented in: commit a40cf4175c90142442d0c6515f6c83956336699b Author: Edward Tomasz Napierala Date: Tue Jul 20 08:56:04 2021 +0000 Implement unprivileged chroot This builds on recently introduced NO_NEW_PRIVS flag to implement unprivileged chroot, enabled by `security.bsd.unprivileged_chroot`. It allows non-root processes to chroot(2), provided they have the NO_NEW_PRIVS flag set. The chroot(8) utility gets a new flag, -n, which sets NO_NEW_PRIVS before chrooting. Reviewed By: kib Sponsored By: EPSRC Relnotes: yes Differential Revision: https://reviews.freebsd.org/D30130 --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Sep 20 15:38:01 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MX5KV4C4kz4cbrX for ; Tue, 20 Sep 2022 15:38:06 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MX5KT63m8z3jj5 for ; Tue, 20 Sep 2022 15:38:05 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf31.google.com with SMTP id s13so2261400qvq.10 for ; Tue, 20 Sep 2022 08:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=NeJhSD4D06+0X8Z9qqdoIJHoiawh+grckS1VL9ACVzI=; b=Eq6pq/CvtrRG6aYHGmcSX17NPbTJiUOIzieGjtPguzf7VYZeeDwFv+kzaK3fhA7FI5 yCSRgxoCbjK7xiEmib9m7Gpo+Eu3jr2o0VEpSYMUWy7kFmzUCDm4gu+iO557xxSoi7QD HLp48+JeFK266Pp2/U0a5Vk22gfTd3Do4kw8oBP8mjhQ8NnQxc2mHG0i/a1FCXQqPBBR DnINjR7IbyoYNYChznuZ7lYqXf/KMfzjDWDWrJoQy1YuXgMqrNj4nOVEBC/PyMj8TMmE Yd4oC8FTy3NBwHS1TiXbSR/Wc9gA/kirbWliBS5IE7Z1EgSDPV7JywDLaHW2qZkaGjZT xIsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=NeJhSD4D06+0X8Z9qqdoIJHoiawh+grckS1VL9ACVzI=; b=gQxaYanfeLT67OjK1QoEZs/SxoYMhKs+xBkHQGTVQGEFju2TEKcgRECzWS52nNXfNC eiW0gdiTnwwRxUlS4K7GqE6UH6Fr+cfbq65K4nplUjqlctBfQnTrnDbcC09MO9xZGHTT 3o/01iqL8QWfqsuSjhPMSNRwsMHguWAFgETi7WjDbGYhshkWMvyT0O/CSr6Scy9cXUpm uNzDJAQ1uK+ovmgqgw1f57IU8BEpp8Yp0NNZs2iLnB3xDmRoBABg02ApMht2BQXgAoB5 8DGsWoALitAOljK9rQFAsKgmthRDV5Ook8xtaIUrZ9Sz+m/qhdUSPlhCGzMAecz0SPWD ABgQ== X-Gm-Message-State: ACrzQf1PbWD+QupljKggpvDCffXwuRISQHMUlBH1Q+R08/bEDug/kSBT WaLGGM61cB90QWDVq0KuV+T1NjcVdHeWUw== X-Google-Smtp-Source: AMsMyM7ZyQz2cLzV2xyZMC+B5n+ftGCBuDVcr2C10r9vJS2vc3F8A7fmRvVO7IfZVR2qXA+EG0swMQ== X-Received: by 2002:a05:6214:5285:b0:474:69d7:c22b with SMTP id kj5-20020a056214528500b0047469d7c22bmr19977323qvb.97.1663688284263; Tue, 20 Sep 2022 08:38:04 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-219-215.bltmmd.fios.verizon.net. [100.16.219.215]) by smtp.gmail.com with ESMTPSA id l27-20020a37f91b000000b006af3f3b385csm29667qkj.98.2022.09.20.08.38.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Sep 2022 08:38:02 -0700 (PDT) Date: Tue, 20 Sep 2022 11:38:01 -0400 From: Shawn Webb To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Stlye(9) strengthen statements on not using K&R function definitions Message-ID: <20220920153801.wzsrphd2ychvfbgm@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pol5wi4ctdp2w6ma" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4MX5KT63m8z3jj5 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b="Eq6pq/Cv"; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::f31 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f31:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[hardenedbsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_EQ_ADDR_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --pol5wi4ctdp2w6ma Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 26, 2022 at 10:31:17AM -0600, Warner Losh wrote: > Greetings >=20 > I've posted a review https://reviews.freebsd.org/D35945 which strengths > statements about K&R definitions and declarations: don't use them. Most of > the K&R code has been removed from the tree (ufs being the last straggler= ). > Future versions of the C standard will remove the K&R definitions and > declaration syntax. clang 15 will whine about this construct. >=20 > The time is ripe to move to language that suggests an outright prohibitio= n. >=20 > Comments about language? Make them in phabricator. > Comments about the idea? Reply here FYI: I did notice the other day that less(1) strictly uses K&R. --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --pol5wi4ctdp2w6ma Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmMp3lIACgkQ/y5nonf4 4fqSSBAAiqr4euJb6XE8m5tp13ma8N9+dDNNe8ISE+27LUpKMA3HwSLROsCO1tHN 3hZnjAUwIWHVzrY4KRBYVK47v+CQtY/a77fem21rfwWElHNkcS2lv5ylKfic/XYj SodE5OW4GScbY0M9zYjh7k5ITIc+Hpo8w4G90e9WJZryEfwrW85aEuF5wiQ3qVCl H9Uh1t/cunRAdormwi/bmdHG/DV3N7PRa5LNduxJ+4bC13uN63aKsXzwAUKRvC2x CGntVV/fTCBTjyMAgM8JqGl0zoJ+l40H0+G3B+uUrNqq3k1IHTrSrTsR42eCPNVX 8fhhUQoN4j7GkGrvWqb4R1TweYFl2ImpJkqJYQCYj8mshMTlfXDtP5JiOjEAQB/i ZizVgfqEC0FkyvjwEU3zD2Wna1dNb9dUaerks3YC22r9qCemu1b4FFReUvyO57/y zkPPr/4ch+4KNA9SXF+URVIFAj2PZ+Q8akyPt+LgyO7AivnuoZTyrItDUGV68QHD dPHlM9BebNzkNF13317aT+y/QS8pjbLJ+uZSeXCKBv6SunCLhNsvjUR0G3kTduZq B8r+Gi9Xe7+FqJ5norY8YE0QjDkUw+7eFf2z9Q2xC5Ymkv00VhrPKFH2SyJykL8U Xq6fqFpEGJ+B17HIs0CCHgIsAoB5ryAXD0E86yuVVizQnw3Dj0c= =n9mf -----END PGP SIGNATURE----- --pol5wi4ctdp2w6ma-- From nobody Tue Sep 20 19:09:55 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MXB206wSDz4d96X for ; Tue, 20 Sep 2022 19:10:00 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MXB1z5qbPz46MG for ; Tue, 20 Sep 2022 19:09:59 +0000 (UTC) (envelope-from garyj@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1663700996; bh=3ejJVdLDp9CHKH8WmoMG120jSnsu8U8Cb7uhJmDepIM=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References: Reply-To; b=YFqBQ+HKlMOxsG7VVpNa8g1gUozMg0Oo+2Yqjly2mbZwbZbmz4P2mVr/qI6KfAv/y JizydefcmcL0thx69DjPqnmYFAd40y4goXXEVeii54RpyJpAqdGHhonTETnNcEpYY/ ZKh/SZF6FJkFnOwXAFOxdNTG8Jvyo2JC94xwnD7M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from ernst.home ([91.2.53.8]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCbEf-1oRgM31Xm7-009eg8; Tue, 20 Sep 2022 21:09:56 +0200 Date: Tue, 20 Sep 2022 21:09:55 +0200 From: Gary Jennejohn To: Shawn Webb Cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: Stlye(9) strengthen statements on not using K&R function definitions Message-ID: <20220920210955.7ee9fd9f@ernst.home> In-Reply-To: <20220920153801.wzsrphd2ychvfbgm@mutt-hbsd> References: <20220920153801.wzsrphd2ychvfbgm@mutt-hbsd> Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ZcxY5uCtk5oHzBmxRiHBcH6T/E0kMaCCy1zqe7egrUdNiwLUx88 V3vBAZ3dEoEgHZX3Jc2Aces/0iRlr//boJBIQ+8T6PV8OeSepEz4eupSFC+CSkAatZACiZ+ 2KUT1idzkCJMMDnOm9LykiUlYOV/cuBSDvTJXMOOwUzWVFvaf3fNe1SWf5+jqboAG29Eytq xREQwJjm4KTHwyIm8Ui2A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:TYsbHN6/o2w=:5M3/BZTedJKJhQbJa53v1m wTAAuCfd7tqSG7E8m0wH4F7HbgesE0IRipcCVdiDqq25cm5KcAEphRCHhODlJCbouJyg3tsGh TgZMLoX6xst+PV+gjvyPGBfqmB16e0oKH76YkrO/b9/gkWy6zJ8iB6T1aZBpwF03QI6ySEzrp Q84yAYoRF4L0Bq8Ql1vUnAUCyX0ynO28+gJE2iz2aW6MY3VfwxyRw3AlIXNv+SvysPotZvIJP zmUbZfa2Xk1AcFO9r4RnLaaRHgm6WQSFZVpJE7liIR81Wtc0ACLAsfS70YlEVXjYgve7c9nWH NNJWAODdS6bHybSpKhXqGRS+rOpWPgsabIcdYrIz+noQ5JJKyyHWoDnc7M4y7jl9gl2BQgQ2+ EzgYbHGuw78xvLZf59uXTszTYuzx1fQWIbMYLZF9TDwOH9j41RcpHqufCMeNVR3osqsbbJafM TETedv+X/K5iwciZKwP1T/+4pi4akdgroc7ZU2UrMEgwCZ1JsnZ7D1MWYJ+TxdzMzJb6cC8Mz ICuNRIECt/yF8qzjOFKp2zsbicHLw0+WZ/tPssapL1vqLfaSM+3nORtKQXPFEbuCgd5jR04eP NLB37JkPEC4xDIjvIWob984hKuz9/TlsspBQASwuOraTNfgzWxTytAbr1NwQTq0yBZwH6pmAA KbwVG1MsN7LIWA/I6Kk2P3UrU31hwSmaBaXGD3mpf1EwJld8bXWKZLN1s3qXs7+hSXyjKNx7c oXKaIjcJ482huljCYy1p3ZLkw9TEjwOLAuZ769Ij8/3ifPmJCXDXv62GCQo5C6lf1xxOqzXi5 wkYw4UPUWCn/rAr76yHNjHV7qffGhf5HPBK4ZmmwMaqvZnb11YVThmwwz58Lu003VRX73ADr3 Uq3guRWCc0rC8jUJtb9GVjg/uDJ84Vj4HADZmj+In6q4MjHf/16P+GcZ9RYAvmGUaYPcKhIzL YJjT+OO3boym9MDKpiJixJKJ2qTRVLwtzOMMszNyK/og/zyv3sNCF4VH22+T/fInaaoHDDoSF 4HnyqRhwls5pXCbtA+EUy3q+jDFLBMt8aCJwNItiVEYx4S4T9w16eOfIG2pmpPG22Y7cbkPMS nOn7g1KvxWcVhrVg5mIdwYFzHh18viZZHVqMqnbYINoAHCHKvVz8hIve1MsRjukxipdClYXbh J1S4s= X-Rspamd-Queue-Id: 4MXB1z5qbPz46MG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=YFqBQ+HK; dmarc=pass (policy=none) header.from=gmx.de; spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.15.18 as permitted sender) smtp.mailfrom=garyj@gmx.de X-Spamd-Result: default: False [-3.08 / 15.00]; DWL_DNSWL_LOW(-1.00)[gmx.net:dkim]; NEURAL_HAM_SHORT(-0.93)[-0.928]; NEURAL_HAM_MEDIUM(-0.80)[-0.796]; NEURAL_SPAM_LONG(0.75)[0.748]; DMARC_POLICY_ALLOW(-0.50)[gmx.de,none]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25:c]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.18:from]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_REPLYTO(0.00)[gmx.de]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.18:from]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[garyj@gmx.de]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmx.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; FREEMAIL_ENVFROM(0.00)[gmx.de]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 20 Sep 2022 11:38:01 -0400 Shawn Webb wrote: > On Tue, Jul 26, 2022 at 10:31:17AM -0600, Warner Losh wrote: > > Greetings > > > > I've posted a review https://reviews.freebsd.org/D35945 which strength= s > > statements about K&R definitions and declarations: don't use them. Mos= t of > > the K&R code has been removed from the tree (ufs being the last stragg= ler). > > Future versions of the C standard will remove the K&R definitions and > > declaration syntax. clang 15 will whine about this construct. > > > > The time is ripe to move to language that suggests an outright prohibi= tion. > > > > Comments about language? Make them in phabricator. > > Comments about the idea? Reply here > > FYI: I did notice the other day that less(1) strictly uses K&R. > Yes, but less is under contrib. The K&R purge should be limited to pure FreeBSD code IMHO. =2D- Gary Jennejohn From nobody Tue Sep 20 20:59:48 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MXDSy04b6z4cBbv for ; Tue, 20 Sep 2022 21:00:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MXDSx04cWz3LX7 for ; Tue, 20 Sep 2022 21:00:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92f.google.com with SMTP id b7so1590876uas.2 for ; Tue, 20 Sep 2022 14:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=TjHny6pltLxybpPSwkXMbzM75ZbqF7sB7C9xicedHeU=; b=uAkCcYiWi+qV3+jALPYQhWWS2fJDrxO4/0o8uc8ZpspGa96gCcm32yY2kcJvcM/jfQ GI5BFJ98q3xcjdYR2nNZyrCdpKieVKIXfIU5DBfL2GAH+fXz0J8X+ygNBJ6onH4e1K4B 6Kul7tRjaMVTro6KHZMiwL5hGh2toojtmeaZNSzenNLPKOxrB/aOnnmXJpJ9Ou2SVDpK No+TqHR8eHOIOYs3u0+0IQe9gCGPxheY5P7Yj1LyuqkZ0CBZZdhCjpLYM+mez509tSDL MSiCBEylYruUTAbW/htlJ4TRhre608c7E5lsL+l2Saa6wFMfkosdvTirHC56OFw1ybYZ 7sDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=TjHny6pltLxybpPSwkXMbzM75ZbqF7sB7C9xicedHeU=; b=LSYTnV3BrD8qV8wheMgiSUCYsvqQDov8tKfqPLhzeDzaRKWwBkhFS/mJ5a0U61QfoT 8H/9tzh1vPfuT2J18s41eX2BIXOSKwPVwxONRW7L+471l62Zd3yEB4BXi0rzgu95uaUJ bjUi3KNmfdFc1ssouTgci1Vm3AGs/TwnzAUtiQlkxXMvCvLyOgvRxwHGbDNIKsPuBNSM by7NBaCntJ8WwKPovlAZIer3kBIRtQS3IGXDpkSM9bIQONfvypardIRco4q8O+3fiIY3 ZgORcO8rUy9wKgRsAEigk3mdFo0OQ6shHae8nszpb3PZ4auSf+jS06RF9f1/WYKqR2Kg +UjQ== X-Gm-Message-State: ACrzQf1tn/Pg2Q88lSdmFKF6GxTb9RgOeD9Ric1z+IIY674CVVSn8Q48 KeoZVALXQE05wTn4FlG+B7i+APFXTbjTX3I13a1COGB281c= X-Google-Smtp-Source: AMsMyM6jDCsr8jVf4J8g13zQzglmOpT+nOWeecXLW6ni5Mw9VcPP9GZOSwxSlMNPIZj3jqlUh55sjoSQcYWZBNSHwXU= X-Received: by 2002:ab0:2b05:0:b0:3af:13aa:b107 with SMTP id e5-20020ab02b05000000b003af13aab107mr9497750uar.20.1663707599836; Tue, 20 Sep 2022 13:59:59 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20220920153801.wzsrphd2ychvfbgm@mutt-hbsd> <20220920210955.7ee9fd9f@ernst.home> In-Reply-To: <20220920210955.7ee9fd9f@ernst.home> From: Warner Losh Date: Tue, 20 Sep 2022 14:59:48 -0600 Message-ID: Subject: Re: Stlye(9) strengthen statements on not using K&R function definitions To: garyj@gmx.de Cc: Shawn Webb , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000007fb15c05e9221cf7" X-Rspamd-Queue-Id: 4MXDSx04cWz3LX7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=uAkCcYiW; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FREEMAIL_TO(0.00)[gmx.de]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92f:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000007fb15c05e9221cf7 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 20, 2022 at 1:09 PM Gary Jennejohn wrote: > On Tue, 20 Sep 2022 11:38:01 -0400 > Shawn Webb wrote: > > > On Tue, Jul 26, 2022 at 10:31:17AM -0600, Warner Losh wrote: > > > Greetings > > > > > > I've posted a review https://reviews.freebsd.org/D35945 which > strengths > > > statements about K&R definitions and declarations: don't use them. > Most of > > > the K&R code has been removed from the tree (ufs being the last > straggler). > > > Future versions of the C standard will remove the K&R definitions and > > > declaration syntax. clang 15 will whine about this construct. > > > > > > The time is ripe to move to language that suggests an outright > prohibition. > > > > > > Comments about language? Make them in phabricator. > > > Comments about the idea? Reply here > > > > FYI: I did notice the other day that less(1) strictly uses K&R. > > > > Yes, but less is under contrib. The K&R purge should be limited to pure > FreeBSD code IMHO. > style(9) has never been about contrib code. less likely will need to update if it wants to keep building on newer compilers, and we'll pickup those changes. Warner --0000000000007fb15c05e9221cf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 20, 2022 at 1:09 PM Gary = Jennejohn <garyj@gmx.de> wrote:
On Tue, 20 Sep 20= 22 11:38:01 -0400
Shawn Webb <shawn.webb@hardenedbsd.org> wrote:

> On Tue, Jul 26, 2022 at 10:31:17AM -0600, Warner Losh wrote:
> > Greetings
> >
> > I've posted a review https://reviews.freebsd.org/D35= 945 which strengths
> > statements about K&R definitions and declarations: don't = use them. Most of
> > the K&R code has been removed from the tree (ufs being the la= st straggler).
> > Future versions of the C standard will remove the K&R definit= ions and
> > declaration syntax. clang 15 will whine about this construct.
> >
> > The time is ripe to move to language that suggests an outright pr= ohibition.
> >
> > Comments about language? Make them in phabricator.
> > Comments about the idea? Reply here
>
> FYI: I did notice the other day that less(1) strictly uses K&R. >

Yes, but less is under contrib.=C2=A0 The K&R purge should be limited t= o pure
FreeBSD code IMHO.

style(9) has never b= een about contrib code. less likely will need to update if it wants to keep= building on newer compilers, and we'll pickup those changes.

Warner
--0000000000007fb15c05e9221cf7-- From nobody Tue Sep 20 23:47:38 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MXJBM2RP7z4cgtb for ; Tue, 20 Sep 2022 23:47:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MXJBM0g3dz3gQ6 for ; Tue, 20 Sep 2022 23:47:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4MXJBL4m3qzss4 for ; Tue, 20 Sep 2022 23:47:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 28KNlcnS082790 for ; Tue, 20 Sep 2022 23:47:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 28KNlc32082789 for arch@FreeBSD.org; Tue, 20 Sep 2022 23:47:38 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: arch@FreeBSD.org Subject: [Bug 121073] [kernel] [patch] run chroot as an unprivileged user Date: Tue, 20 Sep 2022 23:47:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: trasz@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: priority assigned_to resolution bug_file_loc version Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663717659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zfum5VnDXTDADPZqDdWtV+q1/YYhlhl8S3hWFoSFRCc=; b=DeQjvriGO4Lhx5//T6pPYjZVJnSZvZNf096yQHkwCfJV66QdPCj5GEYdB6b8I4OyLDpZ6l QOKNU1aQsHVP0MaiOvac/JhlKzxOPefL/4P/8CwV3F/CacZ92rlFh9lG3Y6/lp/9lZ/lo+ wMPRmO0NSWseqbm5ofVGVpv0QHee/CEZK9RMtu/db3BRtxctWRZOUwwYs/uKFNHa5eBN0o y24NIFeEj4ksKEF281qfdlbj46CQNYgg3xLS0Iraa9dWLCloEY1a9VrYvN6usK3q/aoy87 n2OW8vC1Nt2Di5EhBS24tZ+oxq7F8OSlGwzl8RbWceTXd0/Y//jsovmqMkjXNQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663717659; a=rsa-sha256; cv=none; b=RmuQDQNPghkvpRkA1E7y07QgZf9MXXfXjudytlKVd88MGfc31575rppJmKdtNrEq3F1rTN BvIveetvgP286iZgIxbwOrKI38JVYrQ+XSzov7R/sJK/LCrbEpH7iqUax2C0xSxa/DkhYo FLBTBTZxzlifjj8o5CulvyhnCAn7rhqgRg6vyqGcrOUI5nFmN6hn2yptK6kJp2hp01H2VZ 8x8KP9ph4osRH5LFRX2uBRNzOxJdKtxufGxTjWLtNFwIb293bIdwuD7IIl9n+Y6xg6XCZi vwXqpirHNQxxskuCVE7e74aDl6E3FAAaMlHt33niuTlmHIFEB/OHub2v0mea9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D121073 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|Normal |--- Assignee|bugs@FreeBSD.org |trasz@FreeBSD.org Resolution|Overcome By Events |FIXED URL| |https://reviews.freebsd.org | |/D30130 Version|8.0-CURRENT |12.2-RELEASE --- Comment #14 from Kubilay Kocak --- ^Triage: - Correct resolutions (FIXED .. 'issue as reported', by commit, even if no= t by patch attached here) - Assign to committer that resolved - Add meta (review) - Set version to earliest (currently) supported branch/version @trasz If this ended up being MFC'd to stable/13 (was probably current at t= he time?) or stable/12, please set mfc-stableX flags as appropriate --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Wed Sep 21 17:17:10 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MXlTL3LXSz4d38V for ; Wed, 21 Sep 2022 17:17:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MXlTL1dh1z3TTn for ; Wed, 21 Sep 2022 17:17:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4MXlTL0b8kz170y for ; Wed, 21 Sep 2022 17:17:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 28LHHA7G057526 for ; Wed, 21 Sep 2022 17:17:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 28LHHAZe057525 for arch@FreeBSD.org; Wed, 21 Sep 2022 17:17:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: arch@FreeBSD.org Subject: [Bug 121073] [kernel] [patch] run chroot as an unprivileged user Date: Wed, 21 Sep 2022 17:17:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pstef@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: trasz@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663780630; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lAXMnmo4R2kBKQM6Cip03UGq/tEWRV/QrkTv1IWzmdI=; b=fYT4OOUiCLq+ZxEQvEu6y8s5mfi6oW78p6xPCOLVL8rVa1bLg2qEUTHgwippiTks1lUYCd DRVwwUKrNAoP0L1nSge0DJ7CNBwB3tdCBgtkYAJJ8ryU5+MlfGu6rojVRp6WCiOiHzTA6Z FsQ1H8XNVb6pTNirua2HvNjccsnDW+y7A/C2VQGqpJmyfHEznDQ1hAi2ont+qpunKCZLnJ +18ZjUah7+LdXD/ihdzYrJoEEyPrK06X505q0V5eKmZYWzesvMqwj+0B7pPqfOr/oCcuDP MfAF1lKOBPk3MYy5hPymc4jjKaYsUPFcuLIgk3GizP2F6WznIHCtd3Kxvl17Rw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663780630; a=rsa-sha256; cv=none; b=m+uUmjwotyVBnRVywbuGSdSvJseRklma9N9roBBEaIpjlmi66TtA9yxzioHV1E6YR2aZHw 3aeRiP9L/+uNqtnaCiqF/BymwDKrHU9vw7OhfRcgEJj0ILl6x1it3+INM89YtiGOr51blB n/WcIC9EbMsBK0ATKh/z6LQoXei2CYBkFkb9ZGBp/xy5HG7YYM7IVoJpddwGWNZuhT5LTX j+99XJGQUDM7J6ykDxYKdlE9CW0CoJ3MjGiviynUuho9fnXLivxCB6NYNM8tAma2Zk4X0W Zq2x0pQ1lBNxU92/abYz5CK0vxMGIBBD1p/KwqObW0q7V3Ha2o8hSgNBgccufg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D121073 Piotr Pawel Stefaniak changed: What |Removed |Added ---------------------------------------------------------------------------- CC|arch@FreeBSD.org |pstef@freebsd.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Mon Oct 3 18:43:10 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mh8qB104jz4dvND for ; Mon, 3 Oct 2022 18:43:18 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mh8q90K6qz41Kp for ; Mon, 3 Oct 2022 18:43:17 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 61C833C0199; Mon, 3 Oct 2022 18:43:10 +0000 (UTC) Date: Mon, 3 Oct 2022 18:43:10 +0000 From: Brooks Davis To: freebsd-arch@freebsd.org Subject: enabling float128 support in clang? Message-ID: <20221003184310.GA20951@spindle.one-eyed-alien.net> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4Mh8q90K6qz41Kp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-2.90 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[brooks]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable TL;DR: Is there a reason not to enable float128 support in clang for x86? Due to a build breakage with the flang runtime, I recently noticed that=20 unlike most other OSes we don't support float128 in clang. It's enable in modern GCC and other OSes have it enable in clang: - Hakiu 2018: https://reviews.llvm.org/D54901 - Solaris 2018: https://reviews.llvm.org/D41240 - WASM 2019: https://reviews.llvm.org/D57154 - Dragonfly 2021: https://reviews.llvm.org/D111760 - OpenBSD (history hard to find...) Is there a known reason not to enable this? Patch to enable below (I'm a bit skeptical of the __FLOAT128__ part as GCC doesn't define it...) -- Brooks diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targets/= OSTargets.h index c75f7d9fbafe..ea95f40e81a0 100644 --- a/clang/lib/Basic/Targets/OSTargets.h +++ b/clang/lib/Basic/Targets/OSTargets.h @@ -232,6 +232,9 @@ protected: // setting this to 1 is conforming even if all the basic source // character literals have the same encoding as char and wchar_t. Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1"); + + if (this->HasFloat128) + Builder.defineMacro("__FLOAT128__"); } =20 public: @@ -241,6 +244,7 @@ public: default: case llvm::Triple::x86: case llvm::Triple::x86_64: + this->HasFloat128 =3D true; this->MCountName =3D ".mcount"; break; case llvm::Triple::mips: --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJjOy09AAoJEKzQXbSebgfAntkH/2+tGDC6GKQclxKHY+712v4F OeSKHWdYh6A5qrQU0E/5pvJx4UoJ3fwffgJF3vdMzy822pN2ti/H1Ohf8W4ywETK kTNDpgUrhecPFozpBnC9LQYWAXO4tBlBXZ7xL1b2LLFVz3UZSJRGv3v//+fHZ05u SMv2HvMK2mEOzXZGqqVQ9TWgx8YXlxst5fFjU6K2QZX8vkRqzSHW8F7achI+/ddh hCp22I1OA/ikTHMjz+s0WCi953LEtRBz+t30jJWP9kMIi+irbYkbwYrLkOHWIpt4 kzpte4AsVJMhTHUb71FTRbTMtbdTsgpuoH6t+Y4IdLYAbnaZ+7G7KSr67k0QVyc= =kJOs -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From nobody Mon Oct 3 20:36:55 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MhCLX5xhtz4f7Cj for ; Mon, 3 Oct 2022 20:37:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhCLW1KPMz48hx for ; Mon, 3 Oct 2022 20:37:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664829423; bh=zERPOnnYInhBtVApbS6kyhEVSvOuRJYRAYJAXTObkiU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=atvenIX+V17xmeDvJqybB6ddA5eedfc6ZI/Oge4zRkYD+vuKsIOYO3GwIMw4TMu8Y1Ka1GILOeptNi5IkAaA6MH1aVN7vEQ5y9+7rzCjncLRn66LuvOdpNJxJ1255RyT5Eti8y+iaY5eS3p3HsSoKInYtslLEkXEjdA177vlYlNHbBeeVi/IzIZ9m5bgBMxlNZ+rIr+pyVsBV/GPGhf4XwbIfkHHSjNm255YpyWEOzE/NgSnhwMWZbuK8IAfvRSGay4OYdeCbalqBXon02TwrS02N3hghclOK3hkRoOJtSk1qDdfAhS02HzGUeKThF/nULp2Nu1ChA9z6LwuXE5JkA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664829423; bh=NTN144a1SXv/x8/81dpQ3Z8kQZSpIejFjWTchCWk2BE=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jZAgAEN1S3PY8y2LUkBL+ZaRHEstNNkrLjQUkoeyTMY/MC/iRhle7RmNK0q1e+4/6YOnTM0lEdCD9wzZlJGtX0C5Iod+X+NVQQFrsnzbn+zmrKZqqp4Ybo7ne+QZLDkYg+jRyqLaKsaq8UEdRG/uaSdGCcjtRhymxDKl1SWI8Tw5urODEu3RT1Rt81JznIYfLccNhdny5s+wZCby0XIDZjuB0Bg2j35oDDqVNtycYRJrndY8HVBeQkmx3UoxkxNZBYcBZUgflwIYAUZg2j651kTfi8mZn9UaRfKGQez5wL9c6fLS5quCIjKKTfW6odTEHSPg2pr5ZDyx7tmkl0l/hw== X-YMail-OSG: XupZURQVM1kM8_ljmzqQvC.7Do2scf6uJMfugHOo7SEfgMasRHDVZDJYgmzic8a _PKK_EEXcC3Fodd0cznDXT12lrrfYsmh2ix6Iq1OGZzF7FSMYYj6l0Y_Ec0ETXk2bVNLJZABy2I5 5vSoB.mM99uyZ8hr.stcFLLSLGs8yYzzIkt7sZuhS9umoUUehX7A8QgsrZUjRtjTtRtHh1E_xuJw ja9RJ8W249amWBUtetmYNaJBgqKNdISyMRgYVXSfK31QC1KS3YQQsN9iP7.n5HHKiyrISk6unuUM Bz0b_UxMGPICadZFIX7bJvHtVC9f0HCUJugn9w5oCbW2c3UxC2PUxgZYWaduDcIuXOFk61q3C2X9 QKzp0E8oLtJTp_0nV1xhhgJsa8X.BQylMyMOhhLyz.RqgR5EjaVWDwyillCglhQ0MK4aaWi03_W. hpAau0qYsTJ5VU_VkdqFH9PPsDZTAPDQsotTegfQXm0X6.QklcnXkr21Zr7C2imcto4vv.DCFBOk K9XamtT9emWFEiGZ_z6Mr_Au.aV6Mq6ech48uy2si6OXeT_JM.FEp3r89veoOQwYJyG9gP2intiZ nwPTvcG2vpG_Ez7AyAyDHA9.wGkS9wi6gFzeue1YfzzKv9oUDe0OgKQ9bWcPVD6lag6HR_Qwzzh2 k5AqHO0bZcdkBJeAcY5cHgXzWZwT0tv1WbdzgY2vOQCPzkM0e72Msak_9dth66IHyUYO5tZssbJG KqvxBXcrqldPw.iod0jsSnGyYrs1VAhdYSAtDi1_A7nVZvSfomjZC5P2VwAtXMOfdn3Hrmve9.4d RgzhDg86vhdZA_tkgWAUS9o9eiovgPorjgdWE2HZV7BMpy9U.V5sAllTgWmWcXsASpM2Q24kN.nE xBpcupGElKMXJd5ASFmsCQnOLKDb2WFiAp2HZFmUpuVOdemfUDA6V9P4CY4fFT5rrsAmUueb0_HY QCMwy7PIOtUH9kbhRQaT9M6GmgOAoQQfOVu0.suSAnXGxfKh5vcf6XF_oUlkqAtnm9MOKXYsYLRg Wq_CnUo9bMYvRw62YxIg3QWE8nDzrtYXoTi1iraB8hM9U4WtT72spel0ntnW_clI5shW6TVEMGY6 8Jtwuo4OpFNWDOTd85gJKT9RtgHYOoBQPHfqI1w2FAkH1_lB2eF0iazZMdcdbDggeR0sewSLlfcu V2N5SypYSBe1fUIBir9e.PtrXY_y3esEE1kGRfV3oQOToPE3ShmzP00op9tM11x.KvEJxUdT0LBY Ry1NgGLXgBohFIJDRJi0Y1oU85BYEUIOdxDaLGAN6UYxYfQVBjEO3LZcdiZFffChCQbDIZFbaA2O myZk4YIWCSH6EW_rOfJqGOWFZaePUeYXdqfcbVsRGLrKrbVsoIZqFvMjgoIVkP9maI4TOn0rerZD FOG1femJHl5aHbYdNzplEiexXcqQqYAVO4pHXHkLjOup9oKU76j2KnD5cQVLG1gB.MCtpAIyxaxa GYwXg_uqTq5TAqIRiYxfKGmDt2HYKhSW9AvpaRU9GetCe4mv5jULRqAsLkINpfaVvOmWVupjFPK4 iP9Ne1_SHp33DNVIXfOSHxMQUisl2CYkw7.7pOguTqqueNyMVHM4VFdBtdbjzE7A6mDb.d3qtAiR FnG.LBK8v6cTM9PU87WkHdUrVLFenMpXaJBqX9vz8INawZr1hkXtnt_uFLD.pQSTJiPVTaoqXoUt O3h86oQb47wmuLe6JnGwMFVOToBCRo.RgCskZzqGw6b6DVSRY0yFaUNlvqo_4uk8nTUd5wvU2r2F GdBGz54XUYUeprZUFeBuvzDNJ.WBPTSNDh0INUdkzKiqrOJZTXwdZGzB1t8HtcG7E9SvEoagDkkI f_UYGbYf1oe_iDGSVzonZefzaoLXGVnTL8flJ1AjB6pRHDI3EQXb3PJPFgBUti6IyjnscVxWUoPn A1w34_sDXn46kqJkL2ooQrVPX5_KSPRF2UTHsLAjN1YOPXxp8Ax5wk6A06_4AZNY.WlW.newMArn ON6El4nPh_UtiUXtcumIkJrvxaZ6u6YHUcBQjW7I.Jz.H4QfuDPP0H1LlBvr41EXQBdKLJFydV3V 5qkSTmDQoFfeWI_bj9G_4LDVFc5aOiEDZ3aBQSK0jlB7.PapAVAzoPjedYAvLplbZfqrbMfQSStZ mZyENZznr5ZHSqTRLFrAla8fk133aRcaqyQFkPxT4y.HxIx7X0XjMbkal5p2tDweqwhHgPot.eD7 ndszWbmAKqYdgyrYRuHJGH_Lgt1SBOavXhFT0ue8RVXhSq5HCWcSDw.lC6Wo2stkZAsnVSrTFZjD KXBofXmdZb2ZC.0coU8WG X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 3 Oct 2022 20:37:03 +0000 Received: by hermes--production-bf1-5fb9f4c8b8-xkh8s (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e2dd45383dd40fea825e0cd91ad6d2d6; Mon, 03 Oct 2022 20:36:58 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: RE: enabling float128 support in clang? Message-Id: <2705ED56-AD0E-4FC4-AB32-E96D297BEDDB@yahoo.com> Date: Mon, 3 Oct 2022 13:36:55 -0700 To: Brooks Davis , freebsd-arch X-Mailer: Apple Mail (2.3696.120.41.1.1) References: <2705ED56-AD0E-4FC4-AB32-E96D297BEDDB.ref@yahoo.com> X-Rspamd-Queue-Id: 4MhCLW1KPMz48hx X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=atvenIX+; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.56 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.06)[-0.063]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Brooks Davis wrote on Date: Mon, 03 Oct 2022 18:43:10 UTC : > TL;DR: Is there a reason not to enable float128 support in clang for > x86? >=20 > Due to a build breakage with the flang runtime, I recently noticed = that=20 > unlike most other OSes we don't support float128 in clang. It's = enable > in modern GCC and other OSes have it enable in clang: > - Hakiu 2018: https://reviews.llvm.org/D54901 > - Solaris 2018: https://reviews.llvm.org/D41240 > - WASM 2019: https://reviews.llvm.org/D57154 > - Dragonfly 2021: https://reviews.llvm.org/D111760 > - OpenBSD (history hard to find...) >=20 > Is there a known reason not to enable this? >=20 > Patch to enable below (I'm a bit skeptical of the __FLOAT128__ part as > GCC doesn't define it...) >=20 > -- Brooks >=20 > diff --git a/clang/lib/Basic/Targets/OSTargets.h = b/clang/lib/Basic/Targets/OSTargets.h > index c75f7d9fbafe..ea95f40e81a0 100644 > --- a/clang/lib/Basic/Targets/OSTargets.h > +++ b/clang/lib/Basic/Targets/OSTargets.h > @@ -232,6 +232,9 @@ protected: > // setting this to 1 is conforming even if all the basic source > // character literals have the same encoding as char and wchar_t. > Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1"); > + > + if (this->HasFloat128) > + Builder.defineMacro("__FLOAT128__"); > } > =20 > public: > @@ -241,6 +244,7 @@ public: > default: > case llvm::Triple::x86: > case llvm::Triple::x86_64: > + this->HasFloat128 =3D true; > this->MCountName =3D ".mcount"; > break; > case llvm::Triple::mips: >=20 >=20 See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238129 for some past exchanges on this. =46rom comment #3: QUOTE of Dimitry Andric: As mentioned on the mailing list, it is not a matter of just "enabling" = float128. Somebody has to step up and write a BSD licensed quadmath.h, = to start with. END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Oct 3 21:02:59 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MhCwP3ZMhz4f9s6 for ; Mon, 3 Oct 2022 21:03:01 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhCwN5Lmsz3Drp; Mon, 3 Oct 2022 21:03:00 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B6F003C0199; Mon, 3 Oct 2022 21:02:59 +0000 (UTC) Date: Mon, 3 Oct 2022 21:02:59 +0000 From: Brooks Davis To: Mark Millard Cc: Brooks Davis , freebsd-arch Subject: Re: enabling float128 support in clang? Message-ID: <20221003210259.GA83024@spindle.one-eyed-alien.net> References: <2705ED56-AD0E-4FC4-AB32-E96D297BEDDB.ref@yahoo.com> <2705ED56-AD0E-4FC4-AB32-E96D297BEDDB@yahoo.com> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <2705ED56-AD0E-4FC4-AB32-E96D297BEDDB@yahoo.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4MhCwN5Lmsz3Drp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-2.90 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; FREEMAIL_TO(0.00)[yahoo.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[brooks]; DMARC_NA(0.00)[freebsd.org]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2022 at 01:36:55PM -0700, Mark Millard wrote: > Brooks Davis wrote on > Date: Mon, 03 Oct 2022 18:43:10 UTC : >=20 > > TL;DR: Is there a reason not to enable float128 support in clang for > > x86? > >=20 > > Due to a build breakage with the flang runtime, I recently noticed that= =20 > > unlike most other OSes we don't support float128 in clang. It's enable > > in modern GCC and other OSes have it enable in clang: > > - Hakiu 2018: https://reviews.llvm.org/D54901 > > - Solaris 2018: https://reviews.llvm.org/D41240 > > - WASM 2019: https://reviews.llvm.org/D57154 > > - Dragonfly 2021: https://reviews.llvm.org/D111760 > > - OpenBSD (history hard to find...) > >=20 > > Is there a known reason not to enable this? > >=20 > > Patch to enable below (I'm a bit skeptical of the __FLOAT128__ part as > > GCC doesn't define it...) > >=20 > > -- Brooks > >=20 > > diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targ= ets/OSTargets.h > > index c75f7d9fbafe..ea95f40e81a0 100644 > > --- a/clang/lib/Basic/Targets/OSTargets.h > > +++ b/clang/lib/Basic/Targets/OSTargets.h > > @@ -232,6 +232,9 @@ protected: > > // setting this to 1 is conforming even if all the basic source > > // character literals have the same encoding as char and wchar_t. > > Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1"); > > + > > + if (this->HasFloat128) > > + Builder.defineMacro("__FLOAT128__"); > > } > > =20 > > public: > > @@ -241,6 +244,7 @@ public: > > default: > > case llvm::Triple::x86: > > case llvm::Triple::x86_64: > > + this->HasFloat128 =3D true; > > this->MCountName =3D ".mcount"; > > break; > > case llvm::Triple::mips: > >=20 > >=20 >=20 >=20 > See: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238129 >=20 > for some past exchanges on this. From comment #3: >=20 > QUOTE of Dimitry Andric: > As mentioned on the mailing list, it is not a matter of just "enabling" f= loat128. Somebody has to step up and write a BSD licensed quadmath.h, to st= art with. > END QUOTE Looking that over, I'm not sure we've made the right decision (and I don't think my reply in the thread makes sense). Right now we're in a state where we couldn't build a BSD libquadmath if one existed unless it was pure assembly which surely isn't where we want to be. That being said, it's possible that only having compiler support would be a problem due to either ports or the compiler itself using libquadmath functions once enabled, but it doesn't look like other OSes did anything about library support when they turned on basic support. -- Brooks --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJjO04DAAoJEKzQXbSebgfAB50H/2SIELYsz/8kjQZl97fxyRem oKXBhOx7GCky1udcxsYIbUMFNwNLnPQ+o0g+aB3C2XnbaQJmWMrzbpnUG6Jv1Ap1 FAWubFAQVaDYDMRiOg7rm7/SVk035eIfQPEeAGa8bfayJAeV3JedWH0KEYdtqbF/ wN/Oo//Z26NfyKyrEfVLPuYznrB4pXEiiDnkC0CzMWFwZzgrIaPtdE5XETJ/pMAA yUx1Fj3kBw284WGTOK+F34Njr2JJAKYK7NGuVT9iPqqo6vxD+OUBRsvYwPaU7VnE vn0sT3zj5S1u5DPHwgHe8528bBen7wUmIO1LW/pOYflv6nuFr8kjjPtxk2T3xww= =w1zb -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From nobody Tue Oct 4 15:02:05 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mhgsn1Skvz4f2vy for ; Tue, 4 Oct 2022 15:02:21 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mhgsl3J5gz3rCP; Tue, 4 Oct 2022 15:02:19 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: by mail-pj1-f44.google.com with SMTP id e11-20020a17090a77cb00b00205edbfd646so18882008pjs.1; Tue, 04 Oct 2022 08:02:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Runx/p+++m/9K670Nuj9oU89utcrd+rUaLdRZqydh7o=; b=VWzLciDtjqcDq5Ar6KkLCDXuoaJOGsKkpUGa4K988wN59DhLuBC5p3w2r8ssznu5wt NdCgu6T4X91Hi/Srs+mo/CTWJJlVeQRF1l54+/Sfszuec0LLFpjEzTtEGud51LdJKicl eMIDyUdjn5Y5W9U1GFDH3KV5jth+xmB/7qOpjzXkdfi8qvywxHUYNWTtyjDubWEnyC8e pBYXwI0IlGSZmVMtrXvJaK5AjXZbcyDq95+YFbIIDO7Gr4dIS9YuS8Ekx98SdGmGIQE3 hU5opgrPw/MNMHHUEF2d7/q9SZB3FOpg4a0OSLqHJaVAR4YENPiQp64VGcVEZuY/DJJi XSTQ== X-Gm-Message-State: ACrzQf2K3DFch2ol5FmlpNvSQ2/SZP8y6XUjFxSVriPUuHYfdIoHLAjC KMU78Q2zlhjoAQDuEl0FDUewU6PUJmTRKS6k X-Google-Smtp-Source: AMsMyM7gHCKagGWKoFf9J128CYvwLRVWeJmwvvnOhdlEMKC4zJ/vOYFKlTePfAb0BeAqSyqQNyseDA== X-Received: by 2002:a17:90a:aa8c:b0:205:98b8:f8d5 with SMTP id l12-20020a17090aaa8c00b0020598b8f8d5mr151652pjq.159.1664895737854; Tue, 04 Oct 2022 08:02:17 -0700 (PDT) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com. [209.85.210.171]) by smtp.gmail.com with ESMTPSA id a3-20020a170902ecc300b00176a5767fb0sm9133145plh.94.2022.10.04.08.02.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Oct 2022 08:02:17 -0700 (PDT) Received: by mail-pf1-f171.google.com with SMTP id q7so5777153pfl.9; Tue, 04 Oct 2022 08:02:16 -0700 (PDT) X-Received: by 2002:a05:6a00:1312:b0:536:fefd:e64a with SMTP id j18-20020a056a00131200b00536fefde64amr27619875pfu.26.1664895736546; Tue, 04 Oct 2022 08:02:16 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20221003184310.GA20951@spindle.one-eyed-alien.net> In-Reply-To: <20221003184310.GA20951@spindle.one-eyed-alien.net> From: Alexander Richardson Date: Tue, 4 Oct 2022 16:02:05 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: enabling float128 support in clang? To: Brooks Davis Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Mhgsl3J5gz3rCP X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of arichardson.kde@gmail.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=arichardson.kde@gmail.com X-Spamd-Result: default: False [-2.09 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; FORGED_SENDER(0.30)[arichardson@freebsd.org,arichardsonkde@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.216.44:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[209.85.216.44:from,209.85.210.171:received]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[arichardson@freebsd.org,arichardsonkde@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 3 Oct 2022 at 19:43, Brooks Davis wrote: > > TL;DR: Is there a reason not to enable float128 support in clang for > x86? > > Due to a build breakage with the flang runtime, I recently noticed that > unlike most other OSes we don't support float128 in clang. It's enable > in modern GCC and other OSes have it enable in clang: > - Hakiu 2018: https://reviews.llvm.org/D54901 > - Solaris 2018: https://reviews.llvm.org/D41240 > - WASM 2019: https://reviews.llvm.org/D57154 > - Dragonfly 2021: https://reviews.llvm.org/D111760 > - OpenBSD (history hard to find...) > > Is there a known reason not to enable this? > > Patch to enable below (I'm a bit skeptical of the __FLOAT128__ part as > GCC doesn't define it...) > > -- Brooks > > diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targets/OSTargets.h > index c75f7d9fbafe..ea95f40e81a0 100644 > --- a/clang/lib/Basic/Targets/OSTargets.h > +++ b/clang/lib/Basic/Targets/OSTargets.h > @@ -232,6 +232,9 @@ protected: > // setting this to 1 is conforming even if all the basic source > // character literals have the same encoding as char and wchar_t. > Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1"); > + > + if (this->HasFloat128) > + Builder.defineMacro("__FLOAT128__"); > } > > public: > @@ -241,6 +244,7 @@ public: > default: > case llvm::Triple::x86: > case llvm::Triple::x86_64: > + this->HasFloat128 = true; > this->MCountName = ".mcount"; > break; > case llvm::Triple::mips: > I think this makes sense and may even motivate me to try and get the necessary library calls merged to compiler-rt (https://reviews.llvm.org/D98261). One thing to note is that your current patch will also enable float128 for AArch64 (and other targets), which I don't believe any other OS does. I think it makes sense to restrict it to just x86 to avoid executing code in the compiler that has not been well tested. I believe for all other supported architectures long double is the same as float128 so it probably doesn't make too much sense to enable it there anyway. Alex From nobody Tue Oct 4 15:57:39 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mhj5d4FQ0z4f83w for ; Tue, 4 Oct 2022 15:57:41 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mhj5c4JWXz3xQw; Tue, 4 Oct 2022 15:57:40 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id D2B2A3C0199; Tue, 4 Oct 2022 15:57:39 +0000 (UTC) Date: Tue, 4 Oct 2022 15:57:39 +0000 From: Brooks Davis To: Alexander Richardson Cc: Brooks Davis , freebsd-arch@freebsd.org Subject: Re: enabling float128 support in clang? Message-ID: <20221004155739.GA84006@spindle.one-eyed-alien.net> References: <20221003184310.GA20951@spindle.one-eyed-alien.net> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4Mhj5c4JWXz3xQw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-2.90 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[freebsd.org]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 04, 2022 at 04:02:05PM +0100, Alexander Richardson wrote: > On Mon, 3 Oct 2022 at 19:43, Brooks Davis wrote: > > > > TL;DR: Is there a reason not to enable float128 support in clang for > > x86? > > > > Due to a build breakage with the flang runtime, I recently noticed that > > unlike most other OSes we don't support float128 in clang. It's enable > > in modern GCC and other OSes have it enable in clang: > > - Hakiu 2018: https://reviews.llvm.org/D54901 > > - Solaris 2018: https://reviews.llvm.org/D41240 > > - WASM 2019: https://reviews.llvm.org/D57154 > > - Dragonfly 2021: https://reviews.llvm.org/D111760 > > - OpenBSD (history hard to find...) > > > > Is there a known reason not to enable this? > > > > Patch to enable below (I'm a bit skeptical of the __FLOAT128__ part as > > GCC doesn't define it...) > > > > -- Brooks > > > > diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targ= ets/OSTargets.h > > index c75f7d9fbafe..ea95f40e81a0 100644 > > --- a/clang/lib/Basic/Targets/OSTargets.h > > +++ b/clang/lib/Basic/Targets/OSTargets.h > > @@ -232,6 +232,9 @@ protected: > > // setting this to 1 is conforming even if all the basic source > > // character literals have the same encoding as char and wchar_t. > > Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1"); > > + > > + if (this->HasFloat128) > > + Builder.defineMacro("__FLOAT128__"); > > } > > > > public: > > @@ -241,6 +244,7 @@ public: > > default: > > case llvm::Triple::x86: > > case llvm::Triple::x86_64: > > + this->HasFloat128 =3D true; > > this->MCountName =3D ".mcount"; > > break; > > case llvm::Triple::mips: > > >=20 > I think this makes sense and may even motivate me to try and get the > necessary library calls merged to compiler-rt > (https://reviews.llvm.org/D98261). Sounds good. I'll submit a review. > One thing to note is that your current patch will also enable float128 > for AArch64 (and other targets), which I don't believe any other OS > does. > I think it makes sense to restrict it to just x86 to avoid executing > code in the compiler that has not been well tested. I believe for all > other supported architectures long double is the same as float128 so > it probably doesn't make too much sense to enable it there anyway. Oops, that was an oversight. Thanks for catching. I'll restructure the block like the OpenBSD one (x86 falls through to default). -- Brooks --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJjPFfzAAoJEKzQXbSebgfAU0AH/RtCX+FFx9GAsXccCNC9Ml5Y thlaGG8HVKz7J9Hk275MXhOeUgbq5OxC+zPX+LNttPD5u9PEGgB7T6ID+FC7uNuD 3mLgJXlCY1snS0szG1BJ8M5/6HfIzG1F9WlKZFdokZKOVsAGyePMakylN2M7hV2b Es4dq4r5/jT8QiVNuC/h8vayZCFgX30HL7ZwCkuyfJJOm6gfUIraTF1m8/0ch5FD d69lzuXPr/KjEvsmJbp9uBJzcG06DW2rfpnXXLdhN3i+oMQCXVZoYUIc+CM4tu0G XX1E606EJU7NDwcLm7QcrKVk01nEt38mu7eE5LudibpQoEVBakT5DPbxEBYIdd8= =56d0 -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From nobody Tue Oct 4 16:05:21 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MhjGV2L6Fz4f93M for ; Tue, 4 Oct 2022 16:05:22 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhjGT3LGcz40bQ; Tue, 4 Oct 2022 16:05:21 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 1593B3C0199; Tue, 4 Oct 2022 16:05:21 +0000 (UTC) Date: Tue, 4 Oct 2022 16:05:21 +0000 From: Brooks Davis To: Alexander Richardson Cc: freebsd-arch@freebsd.org Subject: Re: enabling float128 support in clang? Message-ID: <20221004160521.GB84006@spindle.one-eyed-alien.net> References: <20221003184310.GA20951@spindle.one-eyed-alien.net> <20221004155739.GA84006@spindle.one-eyed-alien.net> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline In-Reply-To: <20221004155739.GA84006@spindle.one-eyed-alien.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4MhjGT3LGcz40bQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-2.90 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEFALL_USER(0.00)[brooks]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 04, 2022 at 03:57:39PM +0000, Brooks Davis wrote: > On Tue, Oct 04, 2022 at 04:02:05PM +0100, Alexander Richardson wrote: > > On Mon, 3 Oct 2022 at 19:43, Brooks Davis wrote: > > > > > > TL;DR: Is there a reason not to enable float128 support in clang for > > > x86? > > > > > > Due to a build breakage with the flang runtime, I recently noticed th= at > > > unlike most other OSes we don't support float128 in clang. It's enab= le > > > in modern GCC and other OSes have it enable in clang: > > > - Hakiu 2018: https://reviews.llvm.org/D54901 > > > - Solaris 2018: https://reviews.llvm.org/D41240 > > > - WASM 2019: https://reviews.llvm.org/D57154 > > > - Dragonfly 2021: https://reviews.llvm.org/D111760 > > > - OpenBSD (history hard to find...) > > > > > > Is there a known reason not to enable this? > > > > > > Patch to enable below (I'm a bit skeptical of the __FLOAT128__ part as > > > GCC doesn't define it...) > > > > > > -- Brooks > > > > > > diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Ta= rgets/OSTargets.h > > > index c75f7d9fbafe..ea95f40e81a0 100644 > > > --- a/clang/lib/Basic/Targets/OSTargets.h > > > +++ b/clang/lib/Basic/Targets/OSTargets.h > > > @@ -232,6 +232,9 @@ protected: > > > // setting this to 1 is conforming even if all the basic source > > > // character literals have the same encoding as char and wchar_t. > > > Builder.defineMacro("__STDC_MB_MIGHT_NEQ_WC__", "1"); > > > + > > > + if (this->HasFloat128) > > > + Builder.defineMacro("__FLOAT128__"); > > > } > > > > > > public: > > > @@ -241,6 +244,7 @@ public: > > > default: > > > case llvm::Triple::x86: > > > case llvm::Triple::x86_64: > > > + this->HasFloat128 =3D true; > > > this->MCountName =3D ".mcount"; > > > break; > > > case llvm::Triple::mips: > > > > >=20 > > I think this makes sense and may even motivate me to try and get the > > necessary library calls merged to compiler-rt > > (https://reviews.llvm.org/D98261). >=20 > Sounds good. I'll submit a review. https://reviews.llvm.org/D98261 -- Brooks --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJjPFnAAAoJEKzQXbSebgfAOp8IAJxiHSDSDfoLEPJeofqWePuD f/pGVUu5OQTJ2+QxvDPkAqPvX/bDsBKCzCQ1bsNoBWMGsilTVO1MoLsXvuVZMmcM PhiYcZEgnQdJ84XSOnCYzqL35r1u2GgpWvbxqJFqdIB2bkx+sVbdMMbrx1TtRjhs JDzbx+ARE0A9qMQepw+sQb/lC5I/Q311OZXxBcoucA8JFI8YtECk59BrAGN7munP s0smDXobexPpw8lXj7IoYyX8Um7QuT6Zm41aAQMZp/esEzq3ZDoFbHsERMyPRvQZ BLo7vKwFUyeXO4AfWWnEvkRIaKI9XT0XcKnUOqxyrfeai4BWiNkqktGk6uaHcMo= =M5Qr -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From nobody Thu Oct 13 13:05:33 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mp8rx1Tjvz4fwSJ for ; Thu, 13 Oct 2022 13:05:37 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mp8rx0xrkz3F0l for ; Thu, 13 Oct 2022 13:05:37 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1665666337; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ZTE3dAMFkW0a9AT+2GZpsnMKmUSI/ozWFL3jl01Y61s=; b=Fr+AUVCkGeetzdtTXGNjiooULuozFyzwcl5hiLd5vJrmKzeRN5wm8X3WHdmDyZHdRpjjpY k5R57GiD9W0SVhrSm/RHNkCLA9f26DjpONnso5zn11FekGeALPlUJabyg1ADbY6n6KUqAr Q5CKecF12xUwGxQoihSoLDIGfSJG+qBlxU0DRkmtbqbn9Q58Q6i1cDGhXMdvwEHucuN9gp jI/quCuYXopdhXPj6pYnWH4XNgsMI46NO3sXb+kJjNy2Zc3VWFD2q3/ba4K9+ph+thR8JD PzvgOrrrNwJQ8aecw5tVmzmBB3hCv2E3UxhqM0+Wwg/XS0VhCl/cLOj7HBAfzA== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mp8rw6K0bz18R4 for ; Thu, 13 Oct 2022 13:05:36 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 95AB212290B; Thu, 13 Oct 2022 15:05:33 +0200 (CEST) Date: Thu, 13 Oct 2022 15:05:33 +0200 From: Baptiste Daroussin To: arch@freeBSD.org Subject: Switching from sendmail to Dragonfly Mail Agent by default Message-ID: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1665666337; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ZTE3dAMFkW0a9AT+2GZpsnMKmUSI/ozWFL3jl01Y61s=; b=HUOsZxDL7bLtZNLuFOkRAmvdJtoppIRAaCurpTGV/FZAIGEi3pjyhkSOZ2ANDTT01XjiU3 pX/kHHiPvv4TtWnQquj9uMBgLosuVM8sMg0Vd6/sNIvZ7A6yGS08rDrZ3eWii0xdZad0S6 eTMNxvKl7AXXkYJipRTrLVv1Xz1F8poOoSz/4qXp/BU3iK6gIojzud7IjvsOIshue328Go kb/bVC7WqE7hJaG/Sxo/PIqRnd6q3dOkIN5DBwaY4UNwwKS1P0hEj860GeuTgsxVsThTle m2U+lLep6Oqeuvs5ryzB9z8jDPjjdfk4PdV7nkUUBjrhXVzOlK4J1b06mrpzvA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665666337; a=rsa-sha256; cv=none; b=DvWcjukjFIwJW7wZfAK7bYz5RFayS4bKO1ceA0dhZdY+62ZKOCNEWkImaStwos+Bg3hF81 LwrCJT+0EuP21zLAlz+SU9xImXGbCfdGyXUiVfiLbBUBB2tXKf1MCxeDpHb3dDVxogn7+h ahYMlhJZJ+V9Wei/TJc58RixoYO7PIZPfRcyH/y5Uski2BH/koaOKsbUj5DmMAuQx/WfOm viDnQ2rXqta3S+DAwTOXSyE4F+KXkbMZutN8Rp9kI06hOGIMFGO59MV4GUPUgDzLfPVTyo V17sRZZKbaSPKimT7lQzarLgIl1Nnl3na3zuOoPKgrzCl7zEipD7Uxls1LXN3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello everyone, As of today, on a default FreeBSD setup, a mailer agent is configured in order to be able to distribute locally emails (from crontab for example) and/or for relaying those emails. This role has been served by a stripped down version of sendmail up to now. By stripped down, I mean it is built without the support for feature that would make it a full featured MTA, like no support for ldap. Long time ago we have imported Dragonfly Mail Agent, a minimalistic MTA born within the Dragonfly Project, covering exactly those needs and only those. It has matured slowly over the time and we believe we have addressed all the major issues reported preventing it from being the default. For FreeBSD 14 we would like to activate it by default. It means: - install by default mailer.conf from dma (and install the one from sendmail in /usr/share/example/sendmail) - activate sendmail_enable=NONE by default in /etc/default/rc.conf - make mailwrappe fallback on dma. If noone brings an obvious blocker, this change will happen in the next couple of weeks! Best regards, Bapt From nobody Thu Oct 13 17:55:15 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpHH838jhz4fHDq for ; Thu, 13 Oct 2022 17:55:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MpHH826QFz3s8D for ; Thu, 13 Oct 2022 17:55:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1665683716; 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=4BmfBngJC+jvkZDXChdKYu2xuNo9lOY0H/VKheIQkWc=; b=pVkuiao7CQYZ5djgXLlqvNyMmecL7MMr6V72q9qB4gpvVomiRb4d5juipaAHdLt/YcBPLY KxR+8lfpXw63jRCqEegtVYcFocDiWW3a3XnvsoPehPdpV8/EBGIQcwCL3cRl+Wzs+t4Jsj YvikR8e3vBePHwM5tbRmKJJ48OVixWIk6OjCZ4JDoxuGsu0//i/H44yoax11poctC4KvCz Edv2WdDtN33I1gFF4witrw1lqdLQbfvkLvc8I8IeJvV0i3OcHQref0RypYJ2HBfl+MMJJs PUb0NLNrEfJcnz1uRB8hxJb7clIzJduKwzdaXptaFzAuInUFp+60pYtAQn+TYg== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MpHH76sltz193G for ; Thu, 13 Oct 2022 17:55:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> Date: Thu, 13 Oct 2022 10:55:15 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Content-Language: en-US From: John Baldwin To: 'freebsd-arch' Subject: Re-importing WireGuard driver and utilities Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1665683716; 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=4BmfBngJC+jvkZDXChdKYu2xuNo9lOY0H/VKheIQkWc=; b=gizrsvicaUPr53zDW6nZS9cV1MZz85NbNoNnz2dSrwVB878qGoXgAoZvI3xkqZOc15HTy9 0gfYYXHL8wmWpJSVCLulyHE3VLpiS1c4edUuEU2D6YfnVPQsTmh2c4qslOCTGc/URNu/zC SNjibAJzd+kSe62c0fGd9lxuzPzr2xiq1Fhbbw82zvMmmkEC4/pIYP2V0yLkRHKk3cqIqy OSLI5Gd102hfGwfbgpj26W8de6L7I1NhHlfwhE8ERwkNjw/wt1gjM2jxQIkouOjxhqwg4x MuJQuUt7ny2o66SbxV3JTFtfvHoqvbjQwPeKEuTe4szgTEyMUmNEc8bHAWk0zw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665683716; a=rsa-sha256; cv=none; b=bvQ21E/FEnwQhIGdlG0XYdxz1HSbhT4CsM7RaTZsLtPMAANYnzxbeTRYnAAxTZq7cDGfXC 257MOefqiAJFMmI12DUlme29BfhRslQhZp84avxAclv4zFDGRZwQDxS2EvuqoarVnv8WjU pLR6aU6GIIaOA32emrE6N+L2NUuzpozFA75psDZNkOlaZt08pqHdKuhyioMWJwdSmVdapk 6/rdvjRJkhiWFxmzxVSa86SjdZi9XVEuOfW4AzsOIj3bhIqVpO61QbUnRTzHyL1RFSFxP1 pNzlk91SGLtfyhPfcYsXhX4kHoqOKcvvv6idI/oFbHRdItXxRcg4zDc49XcSIQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Over the past several months, I have spent some time reviewing the WireGuard driver including its interactions with the rest of the kernel and its use of crypto in the kernel. This work was sponsored by the FreeBSD Foundation and had a few goals: 1) Review the driver generally and how it interacted with other parts of the kernel. 2) Review the use of crypto in the driver and evaluate the feasibility of using existing kernel crypto code where possible. Specifically included in this goal was aiming to make use of accelerated software crypto via the ossl(4) driver for datapath crypto. 3) Work with upstream to fix any issues encoutered and evaluate the potential for reintegrating into the source tree. In terms of the driver in general, I found a few minor nits and developed fixes for those that were accepted upstream. I did make one non-trivial change (also accepted upstream) to fix a CPU scheduling inefficiency that dated back to the originally-imported driver. Initially, each input or output packet resulted in scheduling encryption or decryption tasks on every CPU in the system. I modified this part of the driver to follow the Linux driver and instead schedule a single task on a single CPU (chosen via round-robin) for each packet. This improved throughput in my (simple) tests over epair interfaces far more than switching to use ossl(4) for the datapath crypto. Another user also reported that this change alone reduced the power overhead of FreeBSD VMs using WireGuard in ESXi to be nearly on par with Linux due to avoiding wasted CPU cycles on tasks that did no actual work. For the crypto used in the driver, I have extended existing crypto APIs in the kernel to support the algorithms used by WireGuard that weren't already present (and these changes are already in main). In general I have not imported any new crypto code into the kernel, but have added wrappers (often with APIs compatible with Linux) for existing (but previously unused) routines from libsodium. That said, in my review of the driver I also found that the existing crypto implementations in the WireGuard driver were fine from a correctness standpoint. Still, I prefer to minimize the number of copies of crypto algorithm implementations when possible to minimize future maintenance. One bit of crypto is still used directly by the WireGuard driver which is the use of the Blake2 hashes. In particular, the construction of the Blake2 hashes requires the length of the desired digest as an input into initializing the authentication state (similar to how CBC-MAC used in AES-CCM encodes L in block 0). Here FreeBSD's in-kernel Blake2 implementation is somewhat broken as it hardcodes only a single digest length. While OCF itself supports a notion of variable digest lengths via the csp_mlen field, the software auth_xform interface does not pass this length down to the Init() or SetKey() routines, so the auth_xform wrappers of Blake2 are not able to support variable digest lengths. This could be fixed in the future by altering the auth_xform interface. However, WireGuard's use of Blake2 is not a good fit for OCF. Instead, adding an explicit "library" API around the existing Blake2 implementation is probably the most straightforward path if we want to eliminate the last of WireGuard's internal crypto. On the third question, I feel that the current driver is stable and suitable for bring back into the source tree. One question compared to the previous driver import is how to manage the configuration of WireGuard tunnels. The previous driver added new commands to ifconfig(8) that largely mapped one to one with commands passed to the upstream wg(8) tool. Upstream WireGuard has since relicensed their upstream wg(8) tool under a dual MIT/GPL license permitting direct use on FreeBSD. Using the existing tooling means that existing recipes for configuring WireGuard on Linux using wg(8) also apply directly on FreeBSD. It also provides a more seamless transition path for existing users of the WireGuard driver and utility in ports vs adding FreeBSD-specific extensions to ifconfig(8). Given all that, Kyle Evans, Ed Maste, and myself would like to move forward with importing the current WireGuard driver and wg(8) utility into FreeBSD. From upstream's perspective, the driver should simply move into the tree and be maintained directly in the tree (e.g. as sys/dev/wg). The wg(8) tool, on the other hand, will be continued to be maintained by upstream, and so would be imported as normal third-party software into contrib/. I have uploaded the main driver for review (along with some followup local cleanup changes) to https://reviews.freebsd.org/D36909. The cleanups are included in the phabricator stack off of that review. -- John Baldwin From nobody Sat Oct 15 15:51:31 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MqSRV6YFcz4f7Wn for ; Sat, 15 Oct 2022 15:51:34 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MqSRV1CFBz3py2; Sat, 15 Oct 2022 15:51:34 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id jjPCofKXKSp39jjRlo09iv; Sat, 15 Oct 2022 15:51:33 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id jjRjoqTGkiEh7jjRkoqmyz; Sat, 15 Oct 2022 15:51:33 +0000 X-Authority-Analysis: v=2.4 cv=O9kqATxW c=1 sm=1 tr=0 ts=634ad705 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=Qawa6l4ZSaYA:10 a=w16vAm4-AAAA:8 a=uRGV6jrSAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=fkMIT_TdZBG-oRpx3PQA:9 a=CjuIK1q_8ugA:10 a=-FEs8UIgK8oA:10 a=eWus_ag6ds_90y4h1ov8:22 a=lToKLy6fa7oMdS687PPA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 9046D15E; Sat, 15 Oct 2022 08:51:31 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 7E9137C; Sat, 15 Oct 2022 08:51:31 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Baptiste Daroussin cc: arch@freeBSD.org Subject: Re: Switching from sendmail to Dragonfly Mail Agent by default In-reply-to: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> References: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> Comments: In-reply-to Baptiste Daroussin message dated "Thu, 13 Oct 2022 15:05:33 +0200." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Oct 2022 08:51:31 -0700 Message-Id: <20221015155131.7E9137C@slippy.cwsent.com> X-CMAE-Envelope: MS4xfE5fxagbLjmVvdaasheZYkrbqJEM1R+ofhp9HZ9r6id51xUz6KpyPvIAThdgGd8MGGrg+OEEB7mP8g7G8GDD8jSYKLwEGHDGL1/zc+H/I/ece/tokKNH qtfxiB+w0bQdSRf/XWn6QW7eCG7A7FN9zcDBL+VPgeuOsQN7ukiI4td5JOXPQJbESWv5t3ypa3xSn50vm6kQYP/88+WcCzKCYxZs+0Jys3ZYLY6gWf7lX8mt X-Rspamd-Queue-Id: 4MqSRV1CFBz3py2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.79 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.987]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[arch@freebsd.org]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N In message <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu>, Baptiste Daroussin writes: > Hello everyone, > > As of today, on a default FreeBSD setup, a mailer agent is configured in orde > r > to be able to distribute locally emails (from crontab for example) and/or for > relaying those emails. This role has been served by a stripped down version o > f > sendmail up to now. By stripped down, I mean it is built without the support > for feature that would make it a full featured MTA, like no support for ldap. > > Long time ago we have imported Dragonfly Mail Agent, a minimalistic MTA born > within the Dragonfly Project, covering exactly those needs and only those. > > It has matured slowly over the time and we believe we have addressed all the > major issues reported preventing it from being the default. > > For FreeBSD 14 we would like to activate it by default. > > It means: > - install by default mailer.conf from dma (and install the one from sendmail > in /usr/share/example/sendmail) > - activate sendmail_enable=NONE by default in /etc/default/rc.conf > - make mailwrappe fallback on dma. > > If noone brings an obvious blocker, this change will happen in the next coupl > e > of weeks! We should add a comment suggesting that if people forward email they should install one of the packages. A little background: My site here at home is primarily postfix with a single machine (sandbox) running sendmail. I had switched the sandbox machine's MTA from sendmail to dma. The sandbox machine's aliases(5) forwards root's email to an alias on my gateway which in turn sends it to me (stored in an MH folder using procmail for later viewing). This broke because dma doesn't honour aliases; root's mailbox on the sandbox machine contained all root's email that should have been forwarded. As dma is a local-only delivery agent we should explain this to avoid POLA following new installs, giving the user the option to install postfix, exim or sendmail from packages. A local delivery agent is all that's needed to support a fresh new install until the sysadmin can install any needed packages to support their application. Having said all this, given that sendmail no longer has the lion's share of the market -- the last time I looked it had something like 3% market share while Exim (not my choice due to its horrible security in recent years) had approximately 60% market share, Postfix was about 33%, with Exchange and a few others rounding it off. This clearly tells us that we're in the right direction WRT sendmail and MTA in general. Also the fact that Sendmail is now owned by Proofpoint, I don't know how much effort they're putting into the open source version of Sendmail. Development appears to have slowed to a crawl. Personally, I'd discourage Exim due to its horrible security history. IMO Exim is the new sendmail: https://stack.watch/product/exim/exim/. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Sat Oct 15 16:44:36 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MqTcp2VRpz4fFC5 for ; Sat, 15 Oct 2022 16:44:42 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MqTcp20j6z3whp; Sat, 15 Oct 2022 16:44:42 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1665852282; 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=6KTQV6xmRs6dtq2jjjlN+b3hBpRhzlVJrTgFOVrxxuQ=; b=ALWQ4CATJlZgSz9GxttsCBQ8s8fY7dMHBInvz73zGkv9lyczXt7m20Nl71iz0UOTqyj1Zb XknN8YrCrWq1dCD1eyLV4ab7GtICrP8RHYc8g4/hSwHKmrYGirzoHYadvWxDae1Onlqyuh prvyvnam804TGmWFrFyedT+eUVYjSQOg61Piskjeh3SWILEjiQuWgKQ9rQTU3QaGQZL9bC x5dfUXX1jfm92vBWIp8R5IZSwe5keNLy/OhFB610Ehskmz+vtwrdOQnWPkrCAZpgJc0YHO jrpc05EbTGxy7cbqvZSK76C9qgSPJxmmDzNuWP2C4X2sRu/JydHkXF394y7kfg== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MqTcp0Fn5z1KRd; Sat, 15 Oct 2022 16:44:42 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from [IPv6:::1] (2a02-8428-078f-2201-9776-90a3-bcb0-86f1.rev.sfr.net [IPv6:2a02:8428:78f:2201:9776:90a3:bcb0:86f1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aniel.nours.eu (Postfix) with ESMTPSA id 1B43D185DB9; Sat, 15 Oct 2022 18:44:38 +0200 (CEST) Date: Sat, 15 Oct 2022 18:44:36 +0200 From: Baptiste Daroussin To: Cy Schubert CC: arch@freeBSD.org Subject: Re: Switching from sendmail to Dragonfly Mail Agent by default User-Agent: K-9 Mail for Android In-Reply-To: <20221015155131.7E9137C@slippy.cwsent.com> References: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> <20221015155131.7E9137C@slippy.cwsent.com> Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1665852282; 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=6KTQV6xmRs6dtq2jjjlN+b3hBpRhzlVJrTgFOVrxxuQ=; b=B1iTA/vZWcwVYTtSLG4fvAtxgx/xf3OO7slOH8l9mjHf3KJJjfcmElH7IWuHvmOa3vbW+J MV7rOJpcrVFkqujK/nOv/zdFEfROJUJ9ejj4yTtAzIqo8BNN531N8TqqSuAELhCibqc8Vd C8kpzXRh1dK2ThtsRh+Adwjc7HyD0XMkP293CsZuY8uxKO9FTB5nnHnV/Z6F8rAuPpZV7S +Q0VAwGVs9Vb1ZEQyjjK2+nk+jKw/Kyhjjov81Y1Gt3OgP0H6jw4SFKjSW420NxRPGBUPt WVcRce66VQ0pw2zW3Dj9s30QnA7J/Iwi7uK5hxccgs/AaGbXkzJDyRChFQgREw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665852282; a=rsa-sha256; cv=none; b=rSMSOdODT5s7SjesQQ8q2Aj038rTS2jnjg9plzHlU3j0I9Iy2IOkhubEQERCwukqqsFyjV rUEA8rjkr5RiigiKus8WOWsgNuHTwH4fJWzcP5bYCWpFWtLqFForqPDEb0084Iqa5yVO5T IWWUxRORi0V4VrmZ42hF0j3u7UbTyV6p+NiwstWrK63QQKu2al/HN2ntn7WkdXAzSaFPaL FBbtbi5A5sw5A/MYG1QH/3KuOV+Xgkog1t7AR6XHu5nQEXKgowFFd+j4T2yQYbVgPwe9UR 3dsCItmlt0drPow7jBWLFvIRGAwvImXHv+jDqp/bSoEtYt2L5eoDGMWIIChkGw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Le 15 octobre 2022 17:51:31 GMT+02:00, Cy Schubert a =C3=A9crit=C2=A0: >In message <20221013130533=2En33j6fziwkqnjppc@aniel=2Enours=2Eeu>, Baptis= te=20 >Daroussin > writes: >> Hello everyone, >> >> As of today, on a default FreeBSD setup, a mailer agent is configured i= n orde >> r >> to be able to distribute locally emails (from crontab for example) and/= or for >> relaying those emails=2E This role has been served by a stripped down v= ersion o >> f >> sendmail up to now=2E By stripped down, I mean it is built without the = support >> for feature that would make it a full featured MTA, like no support for= ldap=2E >> >> Long time ago we have imported Dragonfly Mail Agent, a minimalistic MTA= born >> within the Dragonfly Project, covering exactly those needs and only tho= se=2E >> >> It has matured slowly over the time and we believe we have addressed al= l the >> major issues reported preventing it from being the default=2E >> >> For FreeBSD 14 we would like to activate it by default=2E >> >> It means: >> - install by default mailer=2Econf from dma (and install the one from s= endmail >> in /usr/share/example/sendmail) >> - activate sendmail_enable=3DNONE by default in /etc/default/rc=2Econf >> - make mailwrappe fallback on dma=2E >> >> If noone brings an obvious blocker, this change will happen in the next= coupl >> e >> of weeks! > >We should add a comment suggesting that if people forward email they shou= ld=20 >install one of the packages=2E > >A little background: > >My site here at home is primarily postfix with a single machine (sandbox)= =20 >running sendmail=2E I had switched the sandbox machine's MTA from sendmai= l to=20 >dma=2E The sandbox machine's aliases(5) forwards root's email to an alias= on=20 >my gateway which in turn sends it to me (stored in an MH folder using=20 >procmail for later viewing)=2E This broke because dma doesn't honour alia= ses;=20 >root's mailbox on the sandbox machine contained all root's email that=20 >should have been forwarded=2E > dma do support alias (not =2Eforward) >As dma is a local-only delivery agent we should explain this to avoid POL= A=20 >following new installs, giving the user the option to install postfix, ex= im=20 >or sendmail from packages=2E A local delivery agent is all that's needed = to=20 >support a fresh new install until the sysadmin can install any needed=20 >packages to support their application=2E > dma is not a local-only delivery agent, it does also support relaying as s= tated in my initial email Bapt From nobody Sat Oct 15 16:58:03 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MqTwG4fdWz4fGjb for ; Sat, 15 Oct 2022 16:58:06 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MqTwF6XP9z3x88; Sat, 15 Oct 2022 16:58:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id jdOIoDyoPS8WrjkU9oyjQn; Sat, 15 Oct 2022 16:58:05 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id jkU7ouN90zeTTjkU8ofjLY; Sat, 15 Oct 2022 16:58:05 +0000 X-Authority-Analysis: v=2.4 cv=EY/b/dqC c=1 sm=1 tr=0 ts=634ae69d a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=Qawa6l4ZSaYA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=4PlNfG6tGf47BuXimjgA:9 a=CjuIK1q_8ugA:10 a=UJ0tAi3fqDAA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 479B1232; Sat, 15 Oct 2022 09:58:03 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 281901A1; Sat, 15 Oct 2022 09:58:03 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Baptiste Daroussin cc: Cy Schubert , arch@freeBSD.org Subject: Re: Switching from sendmail to Dragonfly Mail Agent by default In-reply-to: References: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> <20221015155131.7E9137C@slippy.cwsent.com> Comments: In-reply-to Baptiste Daroussin message dated "Sat, 15 Oct 2022 18:44:36 +0200." List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Oct 2022 09:58:03 -0700 Message-Id: <20221015165803.281901A1@slippy.cwsent.com> X-CMAE-Envelope: MS4xfJhC2mGs9UJA4V01bugmN80nKVA2pDzBkYT1IY4r6gMKuNo5Hf7rlduVizYhxDnkJ5+a0D1bQrg8gAM1anT4McH/ZOXtOdGlGH9o/YGAPggqDdIoUZmp w6FahA563cNlFq+EHSMTDR0INkprddmPODFs2WGZfP1olY0IEU7zgtvDDRol3+/E51ieTLhLX+7JuPe9H2tQXIJ2XQVwgw1kHPcCyFAP+Ktz1kINSM4hBvSi X-Rspamd-Queue-Id: 4MqTwF6XP9z3x88 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.69 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.989]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com] X-ThisMailContainsUnwantedMimeParts: N In message , Baptiste Darouss in writes: > > > > Le 15 octobre 2022 17:51:31 GMT+02:00, Cy Schubert t=2Ecom> a =C3=A9crit=C2=A0: > >In message <20221013130533=2En33j6fziwkqnjppc@aniel=2Enours=2Eeu>, Baptis= > te=20 > >Daroussin > > writes: > >> Hello everyone, > >> > >> As of today, on a default FreeBSD setup, a mailer agent is configured i= > n orde > >> r > >> to be able to distribute locally emails (from crontab for example) and/= > or for > >> relaying those emails=2E This role has been served by a stripped down v= > ersion o > >> f > >> sendmail up to now=2E By stripped down, I mean it is built without the = > support > >> for feature that would make it a full featured MTA, like no support for= > ldap=2E > >> > >> Long time ago we have imported Dragonfly Mail Agent, a minimalistic MTA= > born > >> within the Dragonfly Project, covering exactly those needs and only tho= > se=2E > >> > >> It has matured slowly over the time and we believe we have addressed al= > l the > >> major issues reported preventing it from being the default=2E > >> > >> For FreeBSD 14 we would like to activate it by default=2E > >> > >> It means: > >> - install by default mailer=2Econf from dma (and install the one from s= > endmail > >> in /usr/share/example/sendmail) > >> - activate sendmail_enable=3DNONE by default in /etc/default/rc=2Econf > >> - make mailwrappe fallback on dma=2E > >> > >> If noone brings an obvious blocker, this change will happen in the next= > coupl > >> e > >> of weeks! > > > >We should add a comment suggesting that if people forward email they shou= > ld=20 > >install one of the packages=2E > > > >A little background: > > > >My site here at home is primarily postfix with a single machine (sandbox)= > =20 > >running sendmail=2E I had switched the sandbox machine's MTA from sendmai= > l to=20 > >dma=2E The sandbox machine's aliases(5) forwards root's email to an alias= > on=20 > >my gateway which in turn sends it to me (stored in an MH folder using=20 > >procmail for later viewing)=2E This broke because dma doesn't honour alia= > ses;=20 > >root's mailbox on the sandbox machine contained all root's email that=20 > >should have been forwarded=2E > > > > dma do support alias (not .forward) That's what happened. I couldn't recall exactly. The .forward on that machine is on an NFS share. > > >As dma is a local-only delivery agent we should explain this to avoid POL= > A=20 > >following new installs, giving the user the option to install postfix, ex= > im=20 > >or sendmail from packages=2E A local delivery agent is all that's needed = > to=20 > >support a fresh new install until the sysadmin can install any needed=20 > >packages to support their application=2E > > > > dma is not a local-only delivery agent, it does also support relaying as s= > tated in my initial email. > > Bapt -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Sat Oct 15 18:23:49 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MqWqK4H9Qz4fR4m for ; Sat, 15 Oct 2022 18:23:57 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward503p.mail.yandex.net (forward503p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MqWqH4Ktdz45Sj; Sat, 15 Oct 2022 18:23:55 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from myt5-69594d4a41fa.qloud-c.yandex.net (myt5-69594d4a41fa.qloud-c.yandex.net [IPv6:2a02:6b8:c12:3ca5:0:640:6959:4d4a]) by forward503p.mail.yandex.net (Yandex) with ESMTP id C54EA110142C; Sat, 15 Oct 2022 21:23:51 +0300 (MSK) Received: by myt5-69594d4a41fa.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 3sy1yoZu5K-Noj8OJZP; Sat, 15 Oct 2022 21:23:50 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1665858231; bh=9Jh7ceQImBD0fPheGRw36e79zS3y76q7HK22f1aGowQ=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=fXQiclDDDuAaEIH/Zu839D5F+KvHT5JyvAZgsxyZ1v6zyb2UEKTLSs1yyO6tdyTZo KtITz2Sf+1bVmc0pjRh0j6TCeSdFDAf41AQ5psXTg2XrO5FqAuDwEzSNLnq0Urrvf0 3gw0dTCcg3lxEsyi1tndm5RjvlHnrAoa/JxPN0TM= Content-Type: text/plain; charset=utf-8 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Re-importing WireGuard driver and utilities From: "Alexander V. Chernikov" In-Reply-To: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> Date: Sat, 15 Oct 2022 19:23:49 +0100 Cc: freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <04EAB90E-06B7-43DC-8D70-8A403E789458@ipfw.ru> References: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MqWqH4Ktdz45Sj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=fXQiclDD; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 2a02:6b8:0:1472:2741:0:8b7:122 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1472::/64]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[ipfw.ru:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:208722, ipnet:2a02:6b8::/32, country:FI]; FREEFALL_USER(0.00)[melifaro]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[ipfw.ru]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 13 Oct 2022, at 18:55, John Baldwin wrote: >=20 > Over the past several months, I have spent some time reviewing the > WireGuard driver including its interactions with the rest of the > kernel and its use of crypto in the kernel. This work was sponsored > by the FreeBSD Foundation and had a few goals: >=20 > 1) Review the driver generally and how it interacted with other parts > of the kernel. >=20 > 2) Review the use of crypto in the driver and evaluate the feasibility > of using existing kernel crypto code where possible. Specifically > included in this goal was aiming to make use of accelerated > software crypto via the ossl(4) driver for datapath crypto. >=20 > 3) Work with upstream to fix any issues encoutered and evaluate the > potential for reintegrating into the source tree. >=20 > In terms of the driver in general, I found a few minor nits and > developed fixes for those that were accepted upstream. I did make one > non-trivial change (also accepted upstream) to fix a CPU scheduling > inefficiency that dated back to the originally-imported driver. > Initially, each input or output packet resulted in scheduling > encryption or decryption tasks on every CPU in the system. I modified > this part of the driver to follow the Linux driver and instead > schedule a single task on a single CPU (chosen via round-robin) for > each packet. This improved throughput in my (simple) tests over epair > interfaces far more than switching to use ossl(4) for the datapath > crypto. Another user also reported that this change alone reduced the > power overhead of FreeBSD VMs using WireGuard in ESXi to be nearly on > par with Linux due to avoiding wasted CPU cycles on tasks that did no > actual work. >=20 > For the crypto used in the driver, I have extended existing crypto > APIs in the kernel to support the algorithms used by WireGuard that > weren't already present (and these changes are already in main). In > general I have not imported any new crypto code into the kernel, but > have added wrappers (often with APIs compatible with Linux) for > existing (but previously unused) routines from libsodium. >=20 > That said, in my review of the driver I also found that the existing > crypto implementations in the WireGuard driver were fine from a > correctness standpoint. Still, I prefer to minimize the number of > copies of crypto algorithm implementations when possible to minimize > future maintenance. >=20 > One bit of crypto is still used directly by the WireGuard driver which > is the use of the Blake2 hashes. In particular, the construction of > the Blake2 hashes requires the length of the desired digest as an > input into initializing the authentication state (similar to how > CBC-MAC used in AES-CCM encodes L in block 0). Here FreeBSD's > in-kernel Blake2 implementation is somewhat broken as it hardcodes > only a single digest length. While OCF itself supports a notion of > variable digest lengths via the csp_mlen field, the software > auth_xform interface does not pass this length down to the Init() or > SetKey() routines, so the auth_xform wrappers of Blake2 are not able > to support variable digest lengths. This could be fixed in the future > by altering the auth_xform interface. However, WireGuard's use of > Blake2 is not a good fit for OCF. Instead, adding an explicit > "library" API around the existing Blake2 implementation is probably > the most straightforward path if we want to eliminate the last of > WireGuard's internal crypto. >=20 > On the third question, I feel that the current driver is stable and > suitable for bring back into the source tree. >=20 > One question compared to the previous driver import is how to manage > the configuration of WireGuard tunnels. The previous driver added new > commands to ifconfig(8) that largely mapped one to one with commands > passed to the upstream wg(8) tool. Upstream WireGuard has since > relicensed their upstream wg(8) tool under a dual MIT/GPL license > permitting direct use on FreeBSD. Using the existing tooling means > that existing recipes for configuring WireGuard on Linux using wg(8) > also apply directly on FreeBSD. It also provides a more seamless > transition path for existing users of the WireGuard driver and utility > in ports vs adding FreeBSD-specific extensions to ifconfig(8). >=20 > Given all that, Kyle Evans, Ed Maste, and myself would like to move > forward with importing the current WireGuard driver and wg(8) utility > into FreeBSD. =46rom upstream's perspective, the driver should simply > move into the tree and be maintained directly in the tree (e.g. as > sys/dev/wg). The wg(8) tool, on the other hand, will be continued to > be maintained by upstream, and so would be imported as normal > third-party software into contrib/. I love the separation boundary (provided that upstream is happy with = it). Having wg(8) as a separate utility, that=E2=80=99s maintained by = the software author is also great. Do you folks have any opinion on the interface used to control the = driver? Currently, wg(8) uses netlink on Linux, ioctl+nvlist on FreeBSD = and some custom ioctls on OpenBSD. Netlink support recently landed to main & there are plans to merge it to = 13-S so it=E2=80=99s available in 13.2. Any thoughts on switching our interface to netlink? I=E2=80=99m happy to = write the interface & tests if there are no objections. >=20 > I have uploaded the main driver for review (along with some followup > local cleanup changes) to https://reviews.freebsd.org/D36909. The > cleanups are included in the phabricator stack off of that review. >=20 > --=20 > John Baldwin >=20 From nobody Thu Oct 20 16:20:04 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MtXrL2d3kz4fyKJ for ; Thu, 20 Oct 2022 16:20:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MtXrK2NGcz47Np for ; Thu, 20 Oct 2022 16:20:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x62f.google.com with SMTP id d26so655656eje.10 for ; Thu, 20 Oct 2022 09:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=B45keYcPqeCdgB3q9TQ6J1ENqwlP9rBDA72G9DGDdlg=; b=W2LVbL0Spvl6z7yRJeLaM+0tuYKyicl3EBkHyYXv0HsS2Etn6lMXcW709lzXQzE/Gn U1N/WSnYoa3Ef3EJ6FAH2hytI7duVcF+lzTefO8GCjrAEbTJMqotdCxGXlPx08l9+RNB GY0max7YY1VIs+5GdqNGFAuBXQ3M4Ebr6lOE4GYpJnGPEjxuUzi+WSkQ27jkQSsSU+pV feOsRF1yYyVWfL+MLbjD+lx87jWXIWdSTxCaLx+02StNdhNSA1SOuW9Bx7EPG2ahkBrV CMPD6J8AU2lxUdzd0sDwvonwHucqlDVcp2GGbkvWjm3n0H2ciNoZr+TJNfT6TTqexiQz IP/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=B45keYcPqeCdgB3q9TQ6J1ENqwlP9rBDA72G9DGDdlg=; b=WlLuHKSSk1wnp7AEtmpWvJdc0r8ylStGvgu5arEeXWSo87iFo/TAtfsYCdu2I+tWES 32a0aXtZykd0+kYg/pqGSO7R5ZDoeSXJa/QmaxEa9G51zb/oJsJIicrg1B82AVvK10Dv 4O6aeovMZ6gvjC7Fsi59I7XgVelbVvYkFdUmZFk/qReTH/J4QIbEq91mm9wzFS/oh3cY kgXrRK5JTHky6dYkSS3WpchhqsBYbfGacg2yLG75Kx19Sd/UyqjmLyfSEbGJmg0lGMwZ b3e4IAmLQM1d46sx2fc6tKYMRW3e0ddKskorGw2hr/F4eeHMYgICmt+OR1PTcb/N5NKm mvKQ== X-Gm-Message-State: ACrzQf10bJ/GNauTqmGSOEJycKftIZ2pgjgUpJ6gIZvsb8zdhxt4wj6Y zbHZtZrhGyanmeOm/JEBHy8x1XA+N4rolVSs+tp07lFybvc= X-Google-Smtp-Source: AMsMyM4IxDDCXGWRD92Qh4uq4S9F/o9JS1GAtxmIyb0Sw2IQK1lRDHcVKe1+KeslZMXZh7SXuwpMdoQL5E3vPPGR8rE= X-Received: by 2002:a17:906:328c:b0:780:7574:ced2 with SMTP id 12-20020a170906328c00b007807574ced2mr11796886ejw.634.1666282815714; Thu, 20 Oct 2022 09:20:15 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Thu, 20 Oct 2022 10:20:04 -0600 Message-ID: Subject: metamode recursive descent change To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000005391c405eb79b384" X-Rspamd-Queue-Id: 4MtXrK2NGcz47Np X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=W2LVbL0S; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000005391c405eb79b384 Content-Type: text/plain; charset="UTF-8" Greetings, I've been running with this patch https://reviews.freebsd.org/D37071 for a little while. In meta mode, it will suppress printing of ==> for the recursive descent, as well as most of the -- xxx -- lines associated with that. It does so only in meta mode. This reduces the noise of metamode builds, makes them run faster (way less output) and highlights better the always rebuilt stuff, which should help get those items fixed. It does represent a behavior change, so I thought I'd send a heads up here and see what people think... Warner --0000000000005391c405eb79b384 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I've been running with t= his patch=C2=A0=C2=A0https://reviews.freebsd.org/D37071 for a little while. In m= eta mode, it will suppress=C2=A0printing of =3D=3D> for the recursive de= scent, as well as most of the -- xxx -- lines associated with that. It does= so only in meta mode.

This reduces the noise of m= etamode builds, makes them run faster (way less output) and highlights bett= er the always rebuilt stuff, which should help get those items fixed.
=

It does represent a behavior change, so I thought I'= ;d send a heads up here and see what people think...

Warner

--0000000000005391c405eb79b384-- From nobody Thu Oct 20 19:07:45 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MtcYd6dZlz4gL5n for ; Thu, 20 Oct 2022 19:07:49 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MtcYc4HHVz3FjN for ; Thu, 20 Oct 2022 19:07:48 +0000 (UTC) (envelope-from garyj@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1666292866; bh=wKhir0jXGQWm9+Fgt5bwKov4gu0tgkdIIZDKs9hXYB8=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References: Reply-To; b=l0QWFWLIkRMY0AJICe3VlIvqd8kaccUGB4l1J0HqfD1VWEZig1vn+Zpc0gzROUIRq gNXiaIXMuBwhaN37Weagjt1mEUc2Ojadpw3fAc2VOkQqxDeXeWleiP6OQ3OdBGwfL4 jzsPPbQckbjZuDfeHL50tYXKcvo47XG4HAeykM+I= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from ernst.home ([217.226.63.123]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M1psI-1onmkj3vc8-002HC7; Thu, 20 Oct 2022 21:07:46 +0200 Date: Thu, 20 Oct 2022 21:07:45 +0200 From: Gary Jennejohn To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: metamode recursive descent change Message-ID: <20221020210745.2e8d3aca@ernst.home> In-Reply-To: References: Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:aX+z+/C/MMr5w4yzCob+vVtcf+Llw/sam8g6Oigw7aHBam4t8HG Seii3PCtF0+jIz4T5MNklTs2V9AhdjCC8M1KuU59o/2UvoTSnh8M3J8QSFlPup2BhmASikz OS/RkysXp0iK249iMRiKk8dMSB0Tor6EY3dMnDPvw9tZI2torzLrDgNwr3FmMUE7ojr7g0K yF+GDVUFW3I+sOC6xOW0A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:T0qQL4vEfsA=:HOecfw86ozhpNWw8vv1RFq tTv4k7OCYGR7NvJrpMw/tgvzsWVOOH8xK7bMJkUEj1toyGEaKQX91VpPkGwSUCq4z5KzTuCSC vyalAIq4oG58SZsJ8GUC8XbZ+YbAHhh1z302e2ah1CO3ZPivBJi/eM4bHREi0b4LKsq6Gvopm 4ZHPuml2g/HOWVgjWgdiPHXCpsQs3g8rCqc/4U/IA89+E/lZgO7GqgO60Be0h8A1BFMldXadD /+cF6+y1EixvSeUNJXgR0YuxxEjI7QCbDHMjeJoMUfBc1sOfvgTEfXN+cPVE7/JAIEyxF/dZV qw7U5wtTmimA0OlhjiBFtfpQGmPPtg2G09oPehM5WQMf/br6oFQVwa8aeuvtg+NsnKvD2tQbL po6eu+JySVmqhuQ+d5q2crjSxeKlk2m0+cMYbjKfMdHuytK9UX5Cx2btsj2Fjs+aKx3X2zH1i nKLU53r5nw9RhqAsNJRIaqalLBUrRMo8rZLNC12llipOpM7O4SQcMSNSEw0Ici1xqmJ3BLAOQ PkzC0Z9TWwTZCWpFDYZD3qU2gQ6BqUZ0HYVSjWzTTnQQHBRJ0WtGcC65rOAtg6/KBOkKo18Dk tX77xiHUrUzgGFTKLMRiiWE1WfmoJrfFZWRYllMnu+g2tiML+l/4AzBf+cAAMAiPHB0DmSvXg hvO2DXolsmT9p9clQyFOR+VO+tyvZScjlGPB8mYlzAUHnXtzwuomE92rp2YuBs1l2i0vj/MZf NoSCk1g956zD/SE8goNhJ1deEzpXOFyTt02HMnQR57AFu0xFeUbMRkGgFlDHQuIrjs+x/AZSM eO+dH6xujazFNunbQDnSEfZMDNqJ7Z8vOMl1pgM4jKE941UIKw2ydET1DoGvjN4OWtSzxgEHn z44qGAFgSdtaj7HTqXXcy31bBYwY7WzZVKVyQSdqwnQLCnQrTg6jLWgISokOXuchgiDjgM3jd gzmm73g4WRDQohlk71d1ZjYDTcKo6/pqOQKa0Yxv9E4fE7XQIFR1R8eM1GpTn7089+a/GZCyU rEabOVESqLirN4g3Ax0MHAY4PVl0k2HcFdFlfEdhdSC/y9N6MmujORbJ1KMMLqU/IbYCcYRDG SuVFOPvYUYEn0brPhJcAWQhVnwrvFDSyWoXEKz2zkliRoKvoaKRJIECQrm+bMhke4++IIcc+E nCnTlI4QceTx+V5JAzqIkUXn7pWaVGpcrxWZ+0KmT+r/nFBATvzKCVQ3o5ELsR5Jki/pzNRHP W4uV3nZXQzxB4CE4zEGb7GJwH0wUAHTtkvmlf6iQuRg382l5SzSv+yDkU+lfVEq9gMSKufgOM H8zaD9//W6tk8VpLfHGiMrSNotNTccsm7BiY4shLuNjzcVdafT0TJtO8d5rTs/I8OCAG/JNJ4 53afeTOduY1wUCRlmN01nguRDl1vdK0sZpAKaE5dUed8He9GjjxemMYA8FAomjNmjZ7c9xX5J k4Q+Zmgfmg6AfiBIr6qSsEvGZq1j6qPeUQUvH0V5JOrix791KED/RPBuv38PDBtQrxNx1dpvq JW24/m6ttmVA0+H8War/RJzHAjF9aGT59l+LvqTq+XJYX X-Rspamd-Queue-Id: 4MtcYc4HHVz3FjN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=l0QWFWLI; dmarc=pass (policy=none) header.from=gmx.de; spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.15.15 as permitted sender) smtp.mailfrom=garyj@gmx.de X-Spamd-Result: default: False [-4.99 / 15.00]; DWL_DNSWL_LOW(-1.00)[gmx.net:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.894]; DMARC_POLICY_ALLOW(-0.50)[gmx.de,none]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.15:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmx.de]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.15:from]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[garyj@gmx.de]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; FREEMAIL_ENVFROM(0.00)[gmx.de]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmx.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmx.net:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 20 Oct 2022 10:20:04 -0600 Warner Losh wrote: > Greetings, > > I've been running with this patch https://reviews.freebsd.org/D37071 fo= r a > little while. In meta mode, it will suppress printing of =3D=3D> for the > recursive descent, as well as most of the -- xxx -- lines associated wit= h > that. It does so only in meta mode. > > This reduces the noise of metamode builds, makes them run faster (way le= ss > output) and highlights better the always rebuilt stuff, which should hel= p > get those items fixed. > > It does represent a behavior change, so I thought I'd send a heads up he= re > and see what people think... > I'm all for it! Less noise and faster compiles are always good IMHO. =2D- Gary Jennejohn From nobody Tue Oct 25 00:38:58 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MxCjw4jwGz4g3sx for ; Tue, 25 Oct 2022 00:39:00 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MxCjw4CtHz3Q8N; Tue, 25 Oct 2022 00:39:00 +0000 (UTC) (envelope-from gbe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666658340; 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=Zh7O2hbRlC7ZjRoz6zOYHde2y4jEaICvqgLxseVZ5vk=; b=QLCXWeLN8WNWiyUNeQYJoSc+MD3f1SGHd3Nt7uzGaIVRuAiU/2TmEoRoETYCp7X2wL1h1H K5lA4/wtTPsyPNhmOxl82yiyKokHsObShvqykNg68rT2U2SK/7ib+RhZ2dHYG//3fBSa+5 9xyygeM7A2vFf66T7RQorL/HiU4bPPJNhHL5W1JWSpmiU2bYRSJd+scBQ4BXhL4d23A+Ia 8Lhmy6/cxDOBGESWXzOg8g8glllkiyTSGose6N5ZKcKBbUTGMT6EH5Tx+UgYg8+WacevZ3 a+WlThPBAqiGkvVArlIqlonnoM1htuzFk51oBE7TOBXa+TIkvUUiKtN1IcoOuw== Received: from localhost (p200300cb870da5040da9c3f56283cc73.dip0.t-ipconnect.de [IPv6:2003:cb:870d:a504:da9:c3f5:6283:cc73]) (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: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MxCjw0Ck1zslX; Tue, 25 Oct 2022 00:38:59 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Tue, 25 Oct 2022 02:38:58 +0200 From: Gordon Bergling To: Baptiste Daroussin Cc: arch@freebsd.org Subject: Re: Switching from sendmail to Dragonfly Mail Agent by default Message-ID: References: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fAvhd0C8m5L0ZNXE" Content-Disposition: inline In-Reply-To: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> X-Url: X-Operating-System: FreeBSD 13.1-STABLE amd64 X-Host-Uptime: 2:28AM up 6:33, 2 users, load averages: 0.19, 0.17, 0.16 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666658340; 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=Zh7O2hbRlC7ZjRoz6zOYHde2y4jEaICvqgLxseVZ5vk=; b=mVsPMWMON8Zf5bKeG/Zo7BUilhA2Lw+4iOVlAgOubMfIcgrfLzg1KAhcIyvozBQQIEe7Tq FTOLaNm+vjFIOr7x+Bi3hsCiQyfrdxjzS/VjOKDVEiq1gVeLe70ICQJbrVKKypsy8XS5pN hfN00FviqCd7w08u1AgPYiyOjL375pjh/EIanw4T1vjtOCprXXcGZQV+tcXXoIoFnuZK1C R7H8LJASPLiVZPX1iXmbasra1znugjafbADL12Xc1wxMaP3xR+oSJuz9pLy+v1BP2xWtHf lPveoK+2m155wmlroQrS28DO7DTjB6l/a3eF2qchMyd41IlqYcQS9FeqXlVyrQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666658340; a=rsa-sha256; cv=none; b=FDOR61CdxKGGN9hlQG3srKKeL/77dRRpMidkPfQ5ddzQnwWCpwiwOyOPteYEUjKelCK0kf egMzw/PqbqU+L+tP9YDoItVRCsk1ESrud0uhUIGEv1CSsg21hAkFkkApanEN6OHidIkpap x6vBBZ3NqaurIpKtap/q6Y8fLpOMOPMDyks2ZqLURSXNQn+Cg2ffyrWwevl5fM0JnWgcfy vcwHytVoMJmktHMwY3hJch9FSinXAPo5ntW8xCiqO4Iq4QPIGXPM798cbsRdzlBv9oRQ7r aacPQ7JmIypftq8xX3CLjC/QFgjSwLYGPe9lx8e34QeGgyUH18lSDR2EgfoPPg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --fAvhd0C8m5L0ZNXE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Bapt, On Thu, Oct 13, 2022 at 03:05:33PM +0200, Baptiste Daroussin wrote: > Hello everyone, >=20 > As of today, on a default FreeBSD setup, a mailer agent is configured in = order > to be able to distribute locally emails (from crontab for example) and/or= for > relaying those emails. This role has been served by a stripped down versi= on of > sendmail up to now. By stripped down, I mean it is built without the supp= ort > for feature that would make it a full featured MTA, like no support for l= dap. >=20 > Long time ago we have imported Dragonfly Mail Agent, a minimalistic MTA b= orn > within the Dragonfly Project, covering exactly those needs and only those. >=20 > It has matured slowly over the time and we believe we have addressed all = the > major issues reported preventing it from being the default. >=20 > For FreeBSD 14 we would like to activate it by default. >=20 > It means: > - install by default mailer.conf from dma (and install the one from sendm= ail > in /usr/share/example/sendmail) > - activate sendmail_enable=3DNONE by default in /etc/default/rc.conf > - make mailwrappe fallback on dma. >=20 > If noone brings an obvious blocker, this change will happen in the next c= ouple > of weeks! In general +1. I personaly use msmtp for mail delivery since I don't want to mess with a full MTA configuration. If we enable DMA by default, we also sh= ould update the existing documentation. I recently discovered that following rc.= conf values are needed for local delivery of status e-mails from rc-scripts. sendmail_submit_enable=3D"YES" sendmail_msp_queue_enable=3D"YES" But since we have DMA already in base, the switch would be more then welcom= e, to move to a BSD-licsended, simple to use solution. --Gordon --fAvhd0C8m5L0ZNXE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAmNXMCBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP 09zfeAf9Fwn2QymbdQeYji0/i8CBiA7bHvMsNUXIXVW9MXUuALKsERTYE4bF8xaH bvyhJEC8r0qmpFba4jAKciX+yxy9fyqrY+OyXcLkPiMRLZjLjbtBNGt6ZYYRfZBL lLcmLNoWC7y2VkR1TwcdV3HpwOEPXUQ+I6r2IAJ0lzdXJ2PUBOtArYNCvxB0LHyC e8mH4E1YfZ5HY7erHDk2Ie2G4LmVEwkP6ocS4ygE80jBS+0NSlO5anABZ7qqgzZW Hy9HCsjq+iaW7jWYk7D/S+o7XOZAkdXsBmr6x7s5Ciz8yGpvfyk2SGq63XCs/9TT FkhJKX6mr4SfSzss1uZORgkpgTeHEA== =wFqM -----END PGP SIGNATURE----- --fAvhd0C8m5L0ZNXE-- From nobody Tue Oct 25 00:58:03 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MxD7y3Ywtz4g6DX for ; Tue, 25 Oct 2022 00:58:06 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MxD7y32lXz3SJq; Tue, 25 Oct 2022 00:58:06 +0000 (UTC) (envelope-from gbe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666659486; 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=I1mbduchBi9dOqne5/Rua31ZE0beW7fdNYWcB2JHwDQ=; b=lyFcKibHLMX2dq7NQO8ql2M7n5URj903t/SOvMah3eeO1IjeuMjP5J6MHVS5tmA03YlT6y Jcxn/VOzRFzkqWuGcBHXNw1PYSbx5gTX/w/Cl2WpA4G9dO4yWZQv0DdHhqYX47EcVW+S43 n3wC/6X0zUYKeAa7vo38K+XK3cj0COVjZatGi4ACry6oiCnmf79ayr8Ewx1wcFBmjwBH2u 1/UkNk/K7tk/5R7xVYrgzsg12KE2zjjlWHNY+/XeLGbOxDXdrxf5v136rVhMpiudD54u8h wakqiWvkh688LOonH/6Wy5UGIXndLQZFJT/eti6mPAqnRmKoE9Of5F+cQ8RWHQ== Received: from localhost (p200300cb870da5085c5b5a8c6b77c95b.dip0.t-ipconnect.de [IPv6:2003:cb:870d:a508:5c5b:5a8c:6b77:c95b]) (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: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MxD7x60yCzsvH; Tue, 25 Oct 2022 00:58:05 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Tue, 25 Oct 2022 02:58:03 +0200 From: Gordon Bergling To: John Baldwin Cc: 'freebsd-arch' Subject: Re: Re-importing WireGuard driver and utilities Message-ID: References: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yyg8EWsBxtiNpFij" Content-Disposition: inline In-Reply-To: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> X-Url: X-Operating-System: FreeBSD 13.1-STABLE amd64 X-Host-Uptime: 2:28AM up 6:33, 2 users, load averages: 0.19, 0.17, 0.16 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666659486; 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=I1mbduchBi9dOqne5/Rua31ZE0beW7fdNYWcB2JHwDQ=; b=LhUoJejKZlJzP1fdw1+A2mPtv4UxW3kDgHp81Eoq4pd2BzReZoiBnjVm5Rddpcb3q956Cj 2GmeAMa4RZSauonKn/wPoSKb+8pt6zVrotpkXlhkN3xs4HOYvG2NZB8xcu3cO9DC4/tDZh 6gPm1qE4MXs02rmLUkH48XuemBG9hth/ylUvFgMLs6i8KFroxQfwwDS7s6vK3wzWKalQxZ +kBitnxknZ2ZmDBACNISFMm3Sl9KZbYdR+2Kp/fDeRgBfSj0FaqXf7bYlCmNEw72aj1bQM MYSbNsIp5DQqlm4V6fiD0fvwIhnTCLacTEzUiuEaxUlYqmod3s19G8Ul/XHsGw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666659486; a=rsa-sha256; cv=none; b=XWHVdwwd+NipGA3tPYt8CxkDC2nqBkS+kB+Dle+5RPji5vHi89x1QAnDF2R7iNexcyHr7I K8DLVq4xx2yoIrXkPraDPH6fHMR/KVAyU/HJkpVVbtWqMfhNg5+heGwxmyCDnM9SOV/5HP 52gl6FJ8Yzhx/FE7rjc4W6SMnmkx925LAutg6RWlx0eFvjIwq4GHf7By41alF8B1dFkrGg xwGAc0xtXP/2L8mKwQZtl4LEIXFX05poASNd031cDeuR55NixzmGFxXrMx3D65sEG4OPTY An1KjV8evcqbUUZVGJk108ElC/D/zUTMsDjQJA+AhmXUn+6v/4XYKYwza8oQOA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --yyg8EWsBxtiNpFij Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi John, On Thu, Oct 13, 2022 at 10:55:15AM -0700, John Baldwin wrote: > Over the past several months, I have spent some time reviewing the > WireGuard driver including its interactions with the rest of the > kernel and its use of crypto in the kernel. This work was sponsored > by the FreeBSD Foundation and had a few goals: >=20 > 1) Review the driver generally and how it interacted with other parts > of the kernel. >=20 > 2) Review the use of crypto in the driver and evaluate the feasibility > of using existing kernel crypto code where possible. Specifically > included in this goal was aiming to make use of accelerated > software crypto via the ossl(4) driver for datapath crypto. >=20 > 3) Work with upstream to fix any issues encoutered and evaluate the > potential for reintegrating into the source tree. >=20 > In terms of the driver in general, I found a few minor nits and > developed fixes for those that were accepted upstream. I did make one > non-trivial change (also accepted upstream) to fix a CPU scheduling > inefficiency that dated back to the originally-imported driver. > Initially, each input or output packet resulted in scheduling > encryption or decryption tasks on every CPU in the system. I modified > this part of the driver to follow the Linux driver and instead > schedule a single task on a single CPU (chosen via round-robin) for > each packet. This improved throughput in my (simple) tests over epair > interfaces far more than switching to use ossl(4) for the datapath > crypto. Another user also reported that this change alone reduced the > power overhead of FreeBSD VMs using WireGuard in ESXi to be nearly on > par with Linux due to avoiding wasted CPU cycles on tasks that did no > actual work. >=20 > For the crypto used in the driver, I have extended existing crypto > APIs in the kernel to support the algorithms used by WireGuard that > weren't already present (and these changes are already in main). In > general I have not imported any new crypto code into the kernel, but > have added wrappers (often with APIs compatible with Linux) for > existing (but previously unused) routines from libsodium. >=20 > That said, in my review of the driver I also found that the existing > crypto implementations in the WireGuard driver were fine from a > correctness standpoint. Still, I prefer to minimize the number of > copies of crypto algorithm implementations when possible to minimize > future maintenance. >=20 > One bit of crypto is still used directly by the WireGuard driver which > is the use of the Blake2 hashes. In particular, the construction of > the Blake2 hashes requires the length of the desired digest as an > input into initializing the authentication state (similar to how > CBC-MAC used in AES-CCM encodes L in block 0). Here FreeBSD's > in-kernel Blake2 implementation is somewhat broken as it hardcodes > only a single digest length. While OCF itself supports a notion of > variable digest lengths via the csp_mlen field, the software > auth_xform interface does not pass this length down to the Init() or > SetKey() routines, so the auth_xform wrappers of Blake2 are not able > to support variable digest lengths. This could be fixed in the future > by altering the auth_xform interface. However, WireGuard's use of > Blake2 is not a good fit for OCF. Instead, adding an explicit > "library" API around the existing Blake2 implementation is probably > the most straightforward path if we want to eliminate the last of > WireGuard's internal crypto. >=20 > On the third question, I feel that the current driver is stable and > suitable for bring back into the source tree. >=20 > One question compared to the previous driver import is how to manage > the configuration of WireGuard tunnels. The previous driver added new > commands to ifconfig(8) that largely mapped one to one with commands > passed to the upstream wg(8) tool. Upstream WireGuard has since > relicensed their upstream wg(8) tool under a dual MIT/GPL license > permitting direct use on FreeBSD. Using the existing tooling means > that existing recipes for configuring WireGuard on Linux using wg(8) > also apply directly on FreeBSD. It also provides a more seamless > transition path for existing users of the WireGuard driver and utility > in ports vs adding FreeBSD-specific extensions to ifconfig(8). >=20 > Given all that, Kyle Evans, Ed Maste, and myself would like to move > forward with importing the current WireGuard driver and wg(8) utility > into FreeBSD. From upstream's perspective, the driver should simply > move into the tree and be maintained directly in the tree (e.g. as > sys/dev/wg). The wg(8) tool, on the other hand, will be continued to > be maintained by upstream, and so would be imported as normal > third-party software into contrib/. >=20 > I have uploaded the main driver for review (along with some followup > local cleanup changes) to https://reviews.freebsd.org/D36909. The > cleanups are included in the phabricator stack off of that review. Thanks for the heads up and from my side a big +1. I use WireGuard personal= ly for a few VPN things in my home lab and have it in base is more then welcom= e. --Gordon --yyg8EWsBxtiNpFij Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAmNXNI5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP 09zKjggAw3OpN+/stfkxSER/DSikj9OC/yB8FV1riGlKXRAgw2UBVS5D+PKCpovI 0QFT5MUv6iaJDbz0zIchLYxiQ16rOM4i+4OG4/lkBkYybQ+/jkWqYxORlDdkbQ/2 J558AB1A5q1LXe6J+HfZTuYQdoQPO1ESV6D0facrDfAH5IX2OAQRLaMMsdiHqOen 40igYOa5xeexajc3yo1C3rPpAt0TvHrErN+D3ctdQJJQHduFdPCWqd13SKv/NBeO bK2AgrIOzlB8YJ2UhfL3Yp6HWT0QLIzkn9rxNwES4SVJmP4xm+3fUcZHiflhP3aA Bb/lQtcC6stG7PXVMHHbgwWXCbZcug== =F3mr -----END PGP SIGNATURE----- --yyg8EWsBxtiNpFij-- From nobody Wed Oct 26 16:07:05 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MyDGM3Srrz4gWtD; Wed, 26 Oct 2022 16:07:07 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MyDGM2p12z3TqT; Wed, 26 Oct 2022 16:07:07 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666800427; 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=uEKunhXK9n8kMGX6ExxwLISYT7z5ILTH0/CWYgHyvlQ=; b=N8aqlGNm/7Ua+//zTwYnRhlt4XerR9lNopp02R2NQPpsTBZlh8a3dvqYiNEMz8rH6tH8mS 4kg20OkJHvUnFiJbXn44vJJJjCOdMlNwMZxFPcrikYuqu2qgsrz0iFdbLxJrQa4C5s80/c 2y4NmRr83Ezm3wNYxv51K3kFaeIYiqdyV4us7394rP5veA8Ckx+gVECGrl1ZgqECfFhLEf Ob8cR/3hyeaRITinXElV/2YX/mXNcxcfV0cP9kw+Lobr2Efi7l7he5R60yYuaFIjbN+o/K metQWTYwtgDUyzNAONqbGNJGbrqiIwq6maMfSU2puulu7A9jv3ba4ts0PZhFGQ== Received: from [192.168.1.151] (host-173-212-76-127.public.eastlink.ca [173.212.76.127]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MyDGM0Z4Qz1RLt; Wed, 26 Oct 2022 16:07:06 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: Date: Wed, 26 Oct 2022 13:07:05 -0300 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Content-Language: en-CA From: Mitchell Horne Subject: Documentation of /usr/src directory layout To: freebsd-arch@freebsd.org, "freebsd-doc@FreeBSD.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666800427; 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=uEKunhXK9n8kMGX6ExxwLISYT7z5ILTH0/CWYgHyvlQ=; b=cXDMEPKfu56LzERUDfvRyl2d9gQw02LCPp/p9Xf4UDHOVLThnaIEewxeEoXFje44E6yqbg VvpxUhz95nI71hXll9eU3eDnG8KarOREiNo+e4JJoKJ/nHTqmkEJp9vzjsgnqdVLhdtU7J whv0+WbtFWs3YEMy4v8h4e05V2tm+OMCLwLRCNRBFJUMXXiOpminHB37adodxvnkozuncw e+rmRCPR1nArY1uPjtgu3gN4KbC0LkPq/oD4tug/YL3rgxCFVZne0sEVd6qdxwMEMMINAu +TI4/mxc55fCeHysT4nUlVODxgqvpQb2ET4PPfF0bEKLAY/zhPi/581bmlbcFg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666800427; a=rsa-sha256; cv=none; b=UUkv4vc7Q+Jq2Ffxb/hxa/IQUYpNoqCnk5PZ3VQUwoQV0oUdEH4qzchv/XMDCU0wI37OpI tVvzfKmm23OBUWqKWc8lYc6CgAl90TiZp6DyGhXkjGh90sTqfwlV9O50JIjViqsS+lTin6 ///0t20YL+jgP/fuSaXWDi5sh+kHihfbLfwRCw6h+RM79pAhF4sOeGlMNoOg5SdUuiVYR9 guyZ8hII6AS9GGOSTMTvDittTqooWA0VBvv8OZsSuQnrxmpSwQXuxUlkqObcQqCyKA5VaW P9T2C4mXJMGvJifi9uJj6yYH5FndRrk8ODuNiqrpz2W0SqwYqs6bdGQeeQ7WiA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello, Currently, hier(7) contains detailed but outdated [1] documentation of the directory structure under /usr/src. The src tree's README.md file duplicates much of this information by maintaining a distinctly incomplete table. I propose that we reduce the maintenance overhead by keeping one of these lists as the source of truth. README.md is the more natural option here: being located at the root of the src tree it is more discoverable (especially for those new to the src tree), and the raw markdown text is much more human-readable than mdoc. Of course, the added benefit is that README.md is presented front-and-center when browsing the git repository on GitHub, GitLab, etc. See it on my fork [2]. The list of /usr/src subdirectories will be removed from hier(7) and replaced with a sentence informing the reader they can consult README.md for the details. I have retained and improved the list of directories under sys/ from hier(7), but to avoid polluting the top-level source roadmap I have added a secondary sys/README.md which documents the layout of the kernel sources. I do not expect these changes to be contentious, but I'd like to cast a wider net for review. Productive feedback is welcome by email or directly in the Phabricator reviews: https://reviews.freebsd.org/D37132 https://reviews.freebsd.org/D37133 https://reviews.freebsd.org/D37134 https://reviews.freebsd.org/D37135 https://reviews.freebsd.org/D37136 Also, this information is duplicated in at least one more place: the Developer's Handbook [3]. I intend to address this too after the current series of changes is complete. Most likely, this will be done by replacing the list with a link to the README.md file in cgit. Thanks! Mitchell [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261349 [2] https://github.com/mhorne/freebsd/tree/hier [3] https://docs.freebsd.org/en/books/developers-handbook/introduction/#introduction-layout From nobody Wed Oct 26 16:24:29 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MyDfb3Cwzz4gZJ4 for ; Wed, 26 Oct 2022 16:24:39 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [138.201.35.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MyDfZ4FxWz3WQ5 for ; Wed, 26 Oct 2022 16:24:38 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from [IPV6:2001:9e8:958:5000:3c0c:4b24:172a:e2ce] (unknown [IPv6:2001:9e8:958:5000:3c0c:4b24:172a:e2ce]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 14D8130772 for ; Wed, 26 Oct 2022 16:24:31 +0000 (UTC) Message-ID: <827fd52f-b488-aed0-0d4e-b6cbb4b8e580@rlwinm.de> Date: Wed, 26 Oct 2022 18:24:29 +0200 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: Switching from sendmail to Dragonfly Mail Agent by default To: freebsd-arch@freebsd.org References: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> Content-Language: en-US From: Jan Bramkamp In-Reply-To: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MyDfZ4FxWz3WQ5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 138.201.35.217 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:138.201.0.0/16, country:DE]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[rlwinm.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 13.10.22 15:05, Baptiste Daroussin wrote: > Hello everyone, > > As of today, on a default FreeBSD setup, a mailer agent is configured in order > to be able to distribute locally emails (from crontab for example) and/or for > relaying those emails. This role has been served by a stripped down version of > sendmail up to now. By stripped down, I mean it is built without the support > for feature that would make it a full featured MTA, like no support for ldap. > > Long time ago we have imported Dragonfly Mail Agent, a minimalistic MTA born > within the Dragonfly Project, covering exactly those needs and only those. > > It has matured slowly over the time and we believe we have addressed all the > major issues reported preventing it from being the default. > > For FreeBSD 14 we would like to activate it by default. > > It means: > - install by default mailer.conf from dma (and install the one from sendmail > in /usr/share/example/sendmail) > - activate sendmail_enable=NONE by default in /etc/default/rc.conf > - make mailwrappe fallback on dma. > > If noone brings an obvious blocker, this change will happen in the next couple > of weeks! Thanks for touching this touchy subject. From nobody Wed Oct 26 17:19:38 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MyFtK1c8fz4gjJk for ; Wed, 26 Oct 2022 17:19:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MyFtJ2mzPz3chr; Wed, 26 Oct 2022 17:19:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-pg1-f169.google.com with SMTP id s196so15512328pgs.3; Wed, 26 Oct 2022 10:19:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=2ZnHVkqK0rs4MidbleRGN8OteaXHmXXGox3V2sU6eBI=; b=TjpCgMCTNqnAAjXo9bCCzd3leRoas9Jfb+WczSkJuwMc8uJT59Z+dr0DiJCXO3Zub+ epAv/NJePaiLJD0wMeV4Zwn0tOGT9idumoq5JL+mdKdQ5VwTlbnNY8u+q3o65lmhT2TP i1kGX1dLv89dZvnoJtx2hmCj6NjcAT2hXr63mknffEOeHcqsxuUjv21Is70DBTsAZYBY xaep0OhISVFc+OIcKrv+2ywjvNuc3eYerD5IE2ggPqzrTdXN83aVrXvcpTdlqZyhDrKJ LzjzwFdIK+/yDck5acgpQlqdVgH6xKl4yV72S3tuQni4j6WCS6OGoftmIj8nwOUj+wZH tvVA== X-Gm-Message-State: ACrzQf0pqreQ1E0Gq3Cg8IrfHEQ4Q6izizjwwO380ABkL4DQH/hxXk6V zPDjTNx5V4VL5J/aZmbvc+6QYAOu4lElXRE/KH3mJvVO X-Google-Smtp-Source: AMsMyM6YlYee2pbPqBF98iMcovMH8fXeWqF0V5Ui02pXSCr3yT4a1eYAhAhOIRCqmaHH9f6XTau1YFb2U3rla4a0Aos= X-Received: by 2002:aa7:9292:0:b0:56b:c4d3:a723 with SMTP id j18-20020aa79292000000b0056bc4d3a723mr17757059pfa.57.1666804790970; Wed, 26 Oct 2022 10:19:50 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20221013130533.n33j6fziwkqnjppc@aniel.nours.eu> <20221015155131.7E9137C@slippy.cwsent.com> In-Reply-To: From: Ed Maste Date: Wed, 26 Oct 2022 13:19:38 -0400 Message-ID: Subject: Re: Switching from sendmail to Dragonfly Mail Agent by default To: Baptiste Daroussin Cc: Cy Schubert , arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MyFtJ2mzPz3chr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.215.169 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.215.169:from]; MLMMJ_DEST(0.00)[arch@freebsd.org]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.215.169:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sat, 15 Oct 2022 at 12:44, Baptiste Daroussin wrote: > > dma do support alias (not .forward) It wouldn't be too hard to add .forward support. I can help if someone wants to take that on, or will try to take a look before FreeBSD 14 if nobody else does. From nobody Wed Oct 26 18:06:27 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MyGwL28f9z4gqFT; Wed, 26 Oct 2022 18:06:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MyGwK27Gzz3njZ; Wed, 26 Oct 2022 18:06:41 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-pl1-f169.google.com with SMTP id p3so13983252pld.10; Wed, 26 Oct 2022 11:06:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=m5Cp/3WPqXK1mKltwL/ucS06/HcVbAKYuzn+BzwEPeY=; b=dBlE8MiZ3qRE2i0WJqs9H966ttTARKowwlE9kvffbhqH/ZXwSNS0rxPIbHbr1/vhL+ qDVKfT/wEO8EAHP7/ARqNn9zXFFcxXYFG7S2yU4FBACuKsY1syIcD1b2RZ+JUvQ0Yt5G U7/h8q3ChcMewrA0hwzEgNqqW9CS2Miil8yfWuU+cGzzsKmjecP39MgcVMnmWqDPuYYc ooR68lqwaJGXVOuXPz7BWbhJJIdowPbpuXgHfrwTnnBuM2wgk58plHzM3vVg3jAr8X8z xTAkZDhzXR0FyF/ASv6Ln9kYPh2fyjdFtKWXYx96Fboabmr+xITSX+AEv9UKEWGyzQaD KNUQ== X-Gm-Message-State: ACrzQf0B/pjLHkVFbCfzgW3kBO0rEYXn1EQsDSJz6MXQpmvR85m6XWbO cvtP1C4RXnD+ccig1YrhDBS4ry8afRKw6cRHzn+DtPWQ X-Google-Smtp-Source: AMsMyM5AIs7TenPX3FHOc1TnwevOs9MVNl4gH9aFFwjafHp4EqjqzMaJJgpUK9oW58pbRhrFZM+rBarlFRN4PfxT7QQ= X-Received: by 2002:a17:902:ccd1:b0:186:5ee4:cf49 with SMTP id z17-20020a170902ccd100b001865ee4cf49mr36372226ple.26.1666807599743; Wed, 26 Oct 2022 11:06:39 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Wed, 26 Oct 2022 14:06:27 -0400 Message-ID: Subject: Re: Documentation of /usr/src directory layout To: Mitchell Horne Cc: freebsd-arch@freebsd.org, "freebsd-doc@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MyGwK27Gzz3njZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.09 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.214.169:from]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.214.169:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-doc@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[carpeddiem]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Wed, 26 Oct 2022 at 12:07, Mitchell Horne wrote: > > I propose that we reduce the maintenance overhead by keeping one of > these lists as the source of truth. README.md is the more natural option > here: being located at the root of the src tree it is more discoverable > (especially for those new to the src tree), and the raw markdown text is > much more human-readable than mdoc. Of course, the added benefit is that > README.md is presented front-and-center when browsing the git repository > on GitHub, GitLab, etc. See it on my fork [2]. Thanks Mitchell, overall I think this is a great idea. One question, is README.md the right place for this or should we add a CONTRIBUTING.md or similar? From nobody Wed Oct 26 18:41:40 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MyHhj18Tyz4gvvc; Wed, 26 Oct 2022 18:41:41 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MyHhj0jfdz3sGR; Wed, 26 Oct 2022 18:41:41 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666809701; 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=/7dIXsc3+qfTdUNvJvms+m5oVDICEuB9G+tElPyWOi4=; b=Nwl6pOYE9MRAonbJiFF44Mzj2vg4InUPtAWIOp8TpSovkF1datafPWtJB0C3KiBY0R+Yoc Aau9+TzG7oJRHsvkjXUN/FzoVjvGi3ZHdvV3av2iMMhp8qBC2Rw7hOWW+Zw1YoMQCeT4// ENjarWZOp9FqRR6AgGSwaznO2TxQTF/L5NTiQxpr/QGei1NRy9qE3ex45Cfs8OBp5AOswu JH1DbVMq4X8Krh/sGCuYrzuDe0deaqm3DSBb4+/iSCrSjzlJCiTDZfMBjko52dVLn7FFSy z+rsNbsvOydQP9MCzW3JS7+oCLtrAQuSru4i5kaY8N4PVdyOwTdfMN/S/m04aw== Received: from [192.168.1.151] (host-173-212-76-127.public.eastlink.ca [173.212.76.127]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MyHhh5WgbzVBn; Wed, 26 Oct 2022 18:41:40 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: <1e1fce17-5953-9fc3-e1c4-59bbf5086e0c@freebsd.org> Date: Wed, 26 Oct 2022 15:41:40 -0300 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: Documentation of /usr/src directory layout Content-Language: en-CA To: Ed Maste Cc: freebsd-arch@freebsd.org, "freebsd-doc@FreeBSD.org" References: From: Mitchell Horne In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666809701; 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=/7dIXsc3+qfTdUNvJvms+m5oVDICEuB9G+tElPyWOi4=; b=BwoPe86qlUchlGCActRRNQGduDTOrfUP/wCbg2IVPywVIpJ98E8GwRV16P37mxpk7whdEM Zj/hIyflkgzvFQ9t9vaD1z96y6Fi5TElJgda6qiibuXqGBKrQ8OkIqSa6eYn2uyk9NEQCM MUxV7O2eBCfPLtUDae7Zrvc0t3A2xwpNPYymoJie/oQ3tuUXHTTRazsFwVfNNfjN141Lq6 N0+AXB7nJr3+WUSwiSiIXWD36TKkpnR1GHA+o/BGatAIJMbDTeE0XqAd4lswjaBdWDDAoU mh/1MEwKy/G/5bVcGtOlPS5ivFFz60crOjRQgE7eJDn+h3chXBjHjgT7wALkFw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666809701; a=rsa-sha256; cv=none; b=qS3rUxkU218UQFHbPgOEsTaYnLoaLO1StNUc2pZr5Wx54rIW1aX9IWEgY1I4cr5M++muNA Mm7nCY8HdhIoXv09vh6sOJc6FW9Af2UHUmE3IgJDJeWP7MgQNxb9TTku6F5X3rbod/R9Hw lerGy+VrhArwFw5xPtYPWAU88ffBgPhjkoQghGNXLbisOouzgXD41EQOXCNbT+5u2k47h5 kUDaKwqEJBaJ/UhdGY6L1XGcQhhmlkCPPzfcT03z9BpL9C5tKSLHGpdujB/QTmlq8t+jYF dhpnDBHrzLCOFCIUFQe6mV0YbkVdOEtjPYJ3GLI/gjgJav7UfxocUe0mc88Aog== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 10/26/22 15:06, Ed Maste wrote: > On Wed, 26 Oct 2022 at 12:07, Mitchell Horne wrote: >> >> I propose that we reduce the maintenance overhead by keeping one of >> these lists as the source of truth. README.md is the more natural option >> here: being located at the root of the src tree it is more discoverable >> (especially for those new to the src tree), and the raw markdown text is >> much more human-readable than mdoc. Of course, the added benefit is that >> README.md is presented front-and-center when browsing the git repository >> on GitHub, GitLab, etc. See it on my fork [2]. > > Thanks Mitchell, overall I think this is a great idea. One question, > is README.md the right place for this or should we add a > CONTRIBUTING.md or similar? IMO, it is appropriate to keep this in README.md, if for no other reason than the file is quite small -- 42 lines after my changes, including the table. But I consider it analogous to having a map displayed at a park entrance, or a table of contents at the start of a book. From nobody Fri Oct 28 21:13:13 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MzZyg0rFMz4ftDS for ; Fri, 28 Oct 2022 21:13:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MzZyg0Ch3z3FSw; Fri, 28 Oct 2022 21:13:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666991595; 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=+MeHWNeOcaVOZPyPkbx8RkubyGDwR3SegjSH2Na5418=; b=WhrDKJusNTydwQ/3sOwfh7pPaNIJJsnW7OXQ1LeiltPupht0LCAJ+rcU5sQOMmnhDnb6D4 ICG6NcAHqHjj5PIs3bKB5g6Vyp2rIbam4E+N9kLpf5ZpShdjE+BDNDvjjFlEmCDZ1++ZjE KQS7vkaDZ7cwuCWQM44l5Iu+bDKtheftP+q4LGavz7FMvH2wn0YEoSly71lR4JqETcjrES gi7kE7ztguJsP1Cew1SRO+yBRKuhTaSna1yvhl1gb+pipwM9mDnLyH/wHUTvO8wJLWXg9l znWSVlC2X+RjezRYEbQFAOw8RFl7bZHUycEMgcq8hc9wuRCYaTlJcg5afvE8CA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MzZyf49Wfz1NJP; Fri, 28 Oct 2022 21:13:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <6b80ff72-a652-40ad-1e8a-6b671bc18a5d@FreeBSD.org> Date: Fri, 28 Oct 2022 14:13:13 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: Re-importing WireGuard driver and utilities Content-Language: en-US To: "Alexander V. Chernikov" Cc: freebsd-arch References: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> <04EAB90E-06B7-43DC-8D70-8A403E789458@ipfw.ru> From: John Baldwin In-Reply-To: <04EAB90E-06B7-43DC-8D70-8A403E789458@ipfw.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666991595; 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=+MeHWNeOcaVOZPyPkbx8RkubyGDwR3SegjSH2Na5418=; b=yruhT1VRDmJiYGUhFlmrsopJvRZKZmk+Qy9DjbDHPh0+a8JMOpCH0Qggf1o7R4x7ANIWEv rpcAZlvu31vL8eGIiNp4ft/Pwmch1xfYfc/9lsgsKSTsAmt6VUUUrvpu48pz18n/VthgMD tbLsUTJS35c+pk/Ku7L8bcZY1ozj+DE/Nxj3N0VDzs4QraftmCEJfUE8kTwCjEZAETimvx S+9ezip1+dRX2SS1kJ/qs5CNxOwGQaLrtcutKawiMmt8gRglaU/VhOxuoJ2waB6z9QRB1k 7WlL+CK1EIM7Z0L5CuA5KeSrAUiaHjcw3vg9HOr6S1MLGHYd62qhlbwp8V5KUA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666991595; a=rsa-sha256; cv=none; b=X+/p4Ql9GetLouM+RD908VGfLuCJvbLYZMaUxDVKN4uJ8xaOHVb6Amz1j8k3jdnX0ZLDgF dJksKSvfbnh7Q92Hq8e24wPjYromI0bdSZ2VcUG8xmUx/irdFCn7OXMZqjS1mxyvpLB0oK 9i+UZAY4Y7+E0h3OYPMqcsfw+KgwAb7ov8OdRxCjeBinB04CdMweRmVtRcA+cAnzGJeup0 rDfS69u9XXdKyThY/hA8G54INWtaSsMFRdS8ocQoRO+ioosHj9jzbWftxAADZWKoOCIVhB kj5WlHG8JRXb4qZJtvqlYcnExdYP5eSNz6cKJmEHENwnktJ8SDP0traiSXtxUQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 10/15/22 11:23 AM, Alexander V. Chernikov wrote: > On 13 Oct 2022, at 18:55, John Baldwin wrote: >> >> Over the past several months, I have spent some time reviewing the >> WireGuard driver including its interactions with the rest of the >> kernel and its use of crypto in the kernel. This work was sponsored >> by the FreeBSD Foundation and had a few goals: >> >> 1) Review the driver generally and how it interacted with other parts >> of the kernel. >> >> 2) Review the use of crypto in the driver and evaluate the feasibility >> of using existing kernel crypto code where possible. Specifically >> included in this goal was aiming to make use of accelerated >> software crypto via the ossl(4) driver for datapath crypto. >> >> 3) Work with upstream to fix any issues encoutered and evaluate the >> potential for reintegrating into the source tree. >> >> In terms of the driver in general, I found a few minor nits and >> developed fixes for those that were accepted upstream. I did make one >> non-trivial change (also accepted upstream) to fix a CPU scheduling >> inefficiency that dated back to the originally-imported driver. >> Initially, each input or output packet resulted in scheduling >> encryption or decryption tasks on every CPU in the system. I modified >> this part of the driver to follow the Linux driver and instead >> schedule a single task on a single CPU (chosen via round-robin) for >> each packet. This improved throughput in my (simple) tests over epair >> interfaces far more than switching to use ossl(4) for the datapath >> crypto. Another user also reported that this change alone reduced the >> power overhead of FreeBSD VMs using WireGuard in ESXi to be nearly on >> par with Linux due to avoiding wasted CPU cycles on tasks that did no >> actual work. >> >> For the crypto used in the driver, I have extended existing crypto >> APIs in the kernel to support the algorithms used by WireGuard that >> weren't already present (and these changes are already in main). In >> general I have not imported any new crypto code into the kernel, but >> have added wrappers (often with APIs compatible with Linux) for >> existing (but previously unused) routines from libsodium. >> >> That said, in my review of the driver I also found that the existing >> crypto implementations in the WireGuard driver were fine from a >> correctness standpoint. Still, I prefer to minimize the number of >> copies of crypto algorithm implementations when possible to minimize >> future maintenance. >> >> One bit of crypto is still used directly by the WireGuard driver which >> is the use of the Blake2 hashes. In particular, the construction of >> the Blake2 hashes requires the length of the desired digest as an >> input into initializing the authentication state (similar to how >> CBC-MAC used in AES-CCM encodes L in block 0). Here FreeBSD's >> in-kernel Blake2 implementation is somewhat broken as it hardcodes >> only a single digest length. While OCF itself supports a notion of >> variable digest lengths via the csp_mlen field, the software >> auth_xform interface does not pass this length down to the Init() or >> SetKey() routines, so the auth_xform wrappers of Blake2 are not able >> to support variable digest lengths. This could be fixed in the future >> by altering the auth_xform interface. However, WireGuard's use of >> Blake2 is not a good fit for OCF. Instead, adding an explicit >> "library" API around the existing Blake2 implementation is probably >> the most straightforward path if we want to eliminate the last of >> WireGuard's internal crypto. >> >> On the third question, I feel that the current driver is stable and >> suitable for bring back into the source tree. >> >> One question compared to the previous driver import is how to manage >> the configuration of WireGuard tunnels. The previous driver added new >> commands to ifconfig(8) that largely mapped one to one with commands >> passed to the upstream wg(8) tool. Upstream WireGuard has since >> relicensed their upstream wg(8) tool under a dual MIT/GPL license >> permitting direct use on FreeBSD. Using the existing tooling means >> that existing recipes for configuring WireGuard on Linux using wg(8) >> also apply directly on FreeBSD. It also provides a more seamless >> transition path for existing users of the WireGuard driver and utility >> in ports vs adding FreeBSD-specific extensions to ifconfig(8). >> >> Given all that, Kyle Evans, Ed Maste, and myself would like to move >> forward with importing the current WireGuard driver and wg(8) utility >> into FreeBSD. From upstream's perspective, the driver should simply >> move into the tree and be maintained directly in the tree (e.g. as >> sys/dev/wg). The wg(8) tool, on the other hand, will be continued to >> be maintained by upstream, and so would be imported as normal >> third-party software into contrib/. > I love the separation boundary (provided that upstream is happy with it). Having wg(8) as a separate utility, that’s maintained by the software author is also great. > Do you folks have any opinion on the interface used to control the driver? Currently, wg(8) uses netlink on Linux, ioctl+nvlist on FreeBSD and some custom ioctls on OpenBSD. > Netlink support recently landed to main & there are plans to merge it to 13-S so it’s available in 13.2. > Any thoughts on switching our interface to netlink? I’m happy to write the interface & tests if there are no objections. I don't have any strong opinions either way. We'd likely have to keep the ioctl approach under suitable COMPAT_FREEBSD options if we adopted netlink going forward. -- John Baldwin From nobody Sun Oct 30 20:02:22 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N0nJC0K22z4gT0p for ; Sun, 30 Oct 2022 20:02:35 +0000 (UTC) (envelope-from contact@evilham.com) Received: from yggdrasil.evilham.com (yggdrasil.evilham.com [IPv6:2a02:2770::216:3eff:fee1:cf9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N0nJB1Zs4z3ZNC; Sun, 30 Oct 2022 20:02:34 +0000 (UTC) (envelope-from contact@evilham.com) From: Evilham DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=evilham.com; s=mail; t=1667160145; bh=wyEwMOeW9qV9ZhUFr4Hc9zZ65loczdytvA9VApyUYsA=; h=From:To:Cc:Subject:References:In-reply-to:Date; b=kv2oBWhnPENcvbRS8JVZ7f2XpG/9gWo95BiJgPB5wq87jSJFAzu+yamDx3ZAmvCXG nt0iBZXtzJzEC/on55s0BKxKmUCtmz5J3UbecFenhVogeF2fUupMn/LcZbXa0nIeaa krXAnQtblVUzEDf8wZCQFkf78bYbj5IRxwHs92vE= To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: Re-importing WireGuard driver and utilities References: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> In-reply-to: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> Date: Sun, 30 Oct 2022 21:02:22 +0100 Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Rspamd-Queue-Id: 4N0nJB1Zs4z3ZNC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=evilham.com header.s=mail header.b=kv2oBWhn; dmarc=pass (policy=quarantine) header.from=evilham.com; spf=pass (mx1.freebsd.org: domain of contact@evilham.com designates 2a02:2770::216:3eff:fee1:cf9 as permitted sender) smtp.mailfrom=contact@evilham.com X-Spamd-Result: default: False [-3.91 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.97)[-0.970]; NEURAL_HAM_SHORT(-0.94)[-0.941]; DMARC_POLICY_ALLOW(-0.50)[evilham.com,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[evilham.com:s=mail]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[evilham.com:+]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:196752, ipnet:2a02:2770::/32, country:NL] X-ThisMailContainsUnwantedMimeParts: N Hey, On dj., oct. 13 2022, John Baldwin wrote: > Over the past several months, I have spent some time reviewing > the > WireGuard driver including its interactions with the rest of the > kernel and its use of crypto in the kernel. This work was > sponsored > by the FreeBSD Foundation and had a few goals: Thanks for all the work, I noticed something that might be related to how these changes interact with pkgbase: On pkg upgrade: - FreeBSD-runtime-dev-14.snap20221029192512 [evilham-base] conflicts with FreeBSD-runtime-14.snap20221029192512 [evilham-base] on /usr/include/dev/wg/if_wg.h Aka: the if_wg.h headers are included on both packages, how is this fixed? :-D would love to learn that. Cheers, -- Evilham From nobody Mon Oct 31 18:02:18 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N1LbB3HXSz4gqHp for ; Mon, 31 Oct 2022 18:02:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N1LbB2njXz3nX8; Mon, 31 Oct 2022 18:02:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1667239350; 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=FIWyctIT2ulgtpOnab7NVBX6XMSvQQbmp8q54+0ij5E=; b=b+ERd9Zo4ysFdI2869s/LbC7n0hFJUwSI9MdU0liEz+vu5KIEeVwfey4fkHCbLzvjoaSSb u2F2+mzEWZ6mp4YZTGh+4jzpsjgeEiFZ8zg2XJIUY5V0Vw16dTHhzhAhWULVkNe0SIHGev vplO61beAS1FuKyVG+UEHF2/UDk4iz06b44wMZiQyKqQroHGwn2IjTz8xkNwwcBHxq9FXA waJlZtueqoGWSczBZcfLQIumRwppYv3x13apadTSeIiqhIQtepkiHyFsSUwfuTW+YmjfLq +aBXqwQa9gnsgFY8v2WqVZieNiieUEbJ7bIhn9xtEs5NLURGgE+q8AVol8M9rQ== Received: from [10.0.0.92] (c-98-35-126-114.hsd1.ca.comcast.net [98.35.126.114]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4N1Lb84jbczc6K; Mon, 31 Oct 2022 18:02:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <81989eb2-75e2-b779-0c4b-99cd07d99218@FreeBSD.org> Date: Mon, 31 Oct 2022 11:02:18 -0700 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: Re-importing WireGuard driver and utilities Content-Language: en-US To: Evilham Cc: freebsd-arch@freebsd.org References: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1667239350; 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=FIWyctIT2ulgtpOnab7NVBX6XMSvQQbmp8q54+0ij5E=; b=Pk4WgfJkl6IIF6JVdNruiIXGao/hZ5iG7mOkBrzQAVBu3nofoISNm2Il/aIE1GKapIyIPM Z6yOm8tWt/hUtke0w5CcqlP+gZmb1xpUms/gUuTnsK3kdQfnf2DIugevE+53Yt9WBLO12f usJ9RkV+K9rGmVrxhsfo5dG+z+TBoLmrl47M+SjssX91ywBlL1ddVCGza+OF3o3Q5+yeVN 8BPbW7iBfauxfiApauN95GPzmD0fuH2Quz/l1ZVzJdM82aaPSI0W88Qnpi/5KenXAe8ZKZ Kd2ubwBmNedrRA+6bJrx9l5QFNNokNXqm5ymHMX2RgqR9ccs7bHz0xoFR9AgFQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667239350; a=rsa-sha256; cv=none; b=siohTQpdIQTCpZhEXZ8lnUApvQ4AQbll9ISdIy2Jnb3trROx9lUkkc0RAJwbwkKUQaSKqT rqTIAIhIUm4eNTTkk/6N67/B73LOG0LJQyl3MrYm4XRs/JQpltk0BAX7pGe81vUFqu1VFE 0EBsrp9DyEupwrw+L6ZACntJWGOiMvEpHX+UuUKKtxFLXaq+t8CnJ2AsuGE077vOtDtYeE ixlHBQMt8JLV1cTARdY6bNRBhKlUCNJW6XgwdmptGND1+h4N27I8nOauIJF4taO7HN+Als nJV/QkppF9WACwx3E99R+erOT8mLNU3M2MMVXTiqKxroHbbxpQevGJo6N9bS1A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 10/30/22 1:02 PM, Evilham wrote: > Hey, > > On dj., oct. 13 2022, John Baldwin wrote: > >> Over the past several months, I have spent some time reviewing >> the >> WireGuard driver including its interactions with the rest of the >> kernel and its use of crypto in the kernel. This work was >> sponsored >> by the FreeBSD Foundation and had a few goals: > > Thanks for all the work, I noticed something that might be related > to how these changes interact with pkgbase: > > On pkg upgrade: > > - FreeBSD-runtime-dev-14.snap20221029192512 [evilham-base] > conflicts with FreeBSD-runtime-14.snap20221029192512 > [evilham-base] on /usr/include/dev/wg/if_wg.h > > Aka: the if_wg.h headers are included on both packages, how is > this fixed? :-D would love to learn that. I have no idea. I can't figure out how it ended up in runtime-dev reading include/Makefile which has a default PACKAGES of runtime. -- John Baldwin From nobody Tue Nov 1 08:19:08 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N1jbr5vH0z4ggTY for ; Tue, 1 Nov 2022 08:19:20 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N1jbq6LHbz3CgR for ; Tue, 1 Nov 2022 08:19:19 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-vk1-xa34.google.com with SMTP id g16so6569598vkl.11 for ; Tue, 01 Nov 2022 01:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P/ya/yOr+jXSpc3+RNJWMRYgrtTDS/r9a7u0SK7Dv94=; b=Py5ZI2xl8iabMp29BXUahM0u7Vyz0W9RPzDdVQprNQ626cgrF0X481duqRXlZ5IqVD 2+15jIY85AQaafo0aetCNcxCpt6W3VGhWZ0/oDzoOzS+wNt5Vjj7GKaMJIZoiS2lgECB 4Blu7mZpaPis2BQVUYLWmHv4d2z99iDfogi5+4ghcFJaxOC8HHM7TA/G+SibsRCByaTq SkXjME1h3h2wQI1nsl0J9s7VDU01938W/AhU8fSPQJ++X074mnGbIVR2AIPe0ST03YAK JtIC/CscTDJEcwrwW/7n8XeCismMseALb+PHXyb1OzDGeprRvjvBpLGZRm+P0OvewIGf AGxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=P/ya/yOr+jXSpc3+RNJWMRYgrtTDS/r9a7u0SK7Dv94=; b=z/9zdiceJBlBiDfq5yBHZvwBpESK+q+ZGtdPImgSaRJiRig1WtdVKBsraJmcKLQ7s6 5+NEQXaq9Ynh/ORItTpK6/PDL4zUWV2OFQuHJFZiiqq5pE1l6/nQ0zJv1/cTrmrQISa8 AU80ndlIsq/PNSyFH1j5k1satJKDbjS7ni91LXIkQZB8urqyI4atHvQmN1fYBbj0mxvd ejAy222J2n9000soHIuwa5JDrdDws2NjuT1RwL1lg8Rl/iNw0dhKv2WkdUkXcgRlDkku qiD+gUp4eUqP/Y7/BmgdDFAHmvBJgbnhLOS956Stiq9GUD50bsFmWIRRPo3p5ML18psw /hyg== X-Gm-Message-State: ACrzQf1uaRilQlmbtUbF2SVie5nU+2AgtC/gJNTVwrI/1QyTs7mrQsdt K0i4/wTa5SK6gCLfBbuHKaXu4FSxS+7pq06dCdurdA== X-Google-Smtp-Source: AMsMyM7ma2jaKUXXgcslI1eqkInrclCZy4cXmReFVwOIKxWXjnHOU5JGBvAwl5U7kWoK9Ib3L8pwrYGe55sj7RvEAQc= X-Received: by 2002:a1f:3445:0:b0:3ab:c197:8f4f with SMTP id b66-20020a1f3445000000b003abc1978f4fmr6870511vka.13.1667290759091; Tue, 01 Nov 2022 01:19:19 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <742c4fe8-4c25-d7e5-1df3-b2851d90e630@FreeBSD.org> <81989eb2-75e2-b779-0c4b-99cd07d99218@FreeBSD.org> In-Reply-To: <81989eb2-75e2-b779-0c4b-99cd07d99218@FreeBSD.org> From: Doug Rabson Date: Tue, 1 Nov 2022 08:19:08 +0000 Message-ID: Subject: Re: Re-importing WireGuard driver and utilities To: John Baldwin Cc: Evilham , freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006eec2a05ec6461e4" X-Rspamd-Queue-Id: 4N1jbq6LHbz3CgR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rabson-org.20210112.gappssmtp.com header.s=20210112 header.b=Py5ZI2xl; dmarc=none; spf=pass (mx1.freebsd.org: domain of dfr@rabson.org designates 2607:f8b0:4864:20::a34 as permitted sender) smtp.mailfrom=dfr@rabson.org X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[rabson-org.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a34:from]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[rabson-org.20210112.gappssmtp.com:+]; DMARC_NA(0.00)[rabson.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[dfr]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000006eec2a05ec6461e4 Content-Type: text/plain; charset="UTF-8" On Mon, 31 Oct 2022 at 18:02, John Baldwin wrote: > On 10/30/22 1:02 PM, Evilham wrote: > > Hey, > > > > On dj., oct. 13 2022, John Baldwin wrote: > > > >> Over the past several months, I have spent some time reviewing > >> the > >> WireGuard driver including its interactions with the rest of the > >> kernel and its use of crypto in the kernel. This work was > >> sponsored > >> by the FreeBSD Foundation and had a few goals: > > > > Thanks for all the work, I noticed something that might be related > > to how these changes interact with pkgbase: > > > > On pkg upgrade: > > > > - FreeBSD-runtime-dev-14.snap20221029192512 [evilham-base] > > conflicts with FreeBSD-runtime-14.snap20221029192512 > > [evilham-base] on /usr/include/dev/wg/if_wg.h > > > > Aka: the if_wg.h headers are included on both packages, how is > > this fixed? :-D would love to learn that. > > I have no idea. I can't figure out how it ended up in runtime-dev > reading include/Makefile which has a default PACKAGES of runtime. > Include files for PACKAGE=foo end up in a sibling package foo-dev. Not sure exactly where this happens - bsd.incs.mk is confusing me. --0000000000006eec2a05ec6461e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 31 Oct 2022 at 18:02, John Ba= ldwin <jhb@freebsd.org> wrote:=
On 10/30/22 1:02 PM, Evilham wrote:
> Hey,
>
> On dj., oct. 13 2022, John Baldwin wrote:
>
>> Over the past several months, I have spent some time reviewing
>> the
>> WireGuard driver including its interactions with the rest of the >> kernel and its use of crypto in the kernel.=C2=A0 This work was >> sponsored
>> by the FreeBSD Foundation and had a few goals:
>
> Thanks for all the work, I noticed something that might be related
> to how these changes interact with pkgbase:
>
> On pkg upgrade:
>
>=C2=A0 =C2=A0 - FreeBSD-runtime-dev-14.snap20221029192512 [evilham-base= ]
>=C2=A0 =C2=A0 conflicts with FreeBSD-runtime-14.snap20221029192512
>=C2=A0 =C2=A0 [evilham-base] on /usr/include/dev/wg/if_wg.h
>
> Aka: the if_wg.h headers are included on both packages, how is
> this fixed? :-D would love to learn that.

I have no idea.=C2=A0 I can't figure out how it ended up in runtime-dev=
reading include/Makefile which has a default PACKAGES of runtime.

Include files for PACKAGE=3Dfoo end up in a sibl= ing package foo-dev. Not sure exactly where this happens - bsd.incs.mk is confusing me.

<= /div> --0000000000006eec2a05ec6461e4-- From nobody Wed Nov 9 15:00:50 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6p7T45Qfz4XHnM for ; Wed, 9 Nov 2022 15:00:53 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6p7T3dtlz4FX2 for ; Wed, 9 Nov 2022 15:00:53 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668006053; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=NIqfOEUqZBEbE9Z539Q5d74cpPP6HtkXlJNDZa8yfow=; b=QpShPmhtwcOfkEPWHL/wzYTMuWeSLrF85ypPoMiyJnKvkoIcc4a2ORAcHRLgPshvz+Y0wa qU91vnCK7hnnhUoPJSnjbXqSA0aGKTJ55EITz/SFjR/0mqxtohsCo998HFJKxFrp2sQxkX FDATB+UIOG19vr16j5uQWaTJIfVwb6IDNNZESeNdiSqPobeO5+RTKzS+84NuYcyPGZ/NU3 pCk0fXDba9JeaNTAVb0RU/3JolGa46nQguuUK0pwBukq1Z2GXlXNdtNItNYuDBqInow2Hy ZSbOHGCSV8q6gmvo/qvfSYriAPHN+45ZZaTk0Zd0Lf3tKt+5UT7yMdeVWco/kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668006053; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=NIqfOEUqZBEbE9Z539Q5d74cpPP6HtkXlJNDZa8yfow=; b=UBTpZdOP5TwwMOGVNYIEtPU5HE74PVtLzG51+XQLluXAzdtFiZKqhmyKRiqyBfpVFZXMh2 xK2Vk8ADRWbBHio3YDitTR/OlXV79Jr+VRLBZA0EtWXk4jauYufw+JygbwVNckcQfmPfMZ IuViyTR85XCpvkVZNpOnZsqEwSHGAALZ3zz0q3zOtfCyKz5nEXQPD33sUme+0wb8gf9Nok QS/yOPK9bf0f+ZGZnlb0AH1LmezRvvUDSrw15nXdBeZsDYpQTBemojgGD3yz0GygB6O+ow BkQZzjcn9P7mSRHZlEPvWinyaeqD8ro0rNPSpA10m6jJF4Tr93K7UrW9Z6hv6Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668006053; a=rsa-sha256; cv=none; b=LuBJNGEgjj3m+JH1SKMA3kmPc/59CVgcSVWMVeWlUomJBQLE7WP8WcQLcJZpfrkbMd2J+d zAMPkKBwymc/TSKd0M2/nohWp6rfnN1S7zZerG6F7c3HrGnh+A1FdWZ8USHNdyBFvd26v1 uPyvtyqQOrni6sbSrrCaVCt0xKhvl39q/eBh4ricrGOaYhoOaNXVt76VRsnr4Krzy8cm4n 9yiYN2c8Ufcd50+GVqB3FQMpFv6Z42b5/5x+pun49NId02oKcARvp+Lod+KtPygyhTWhXZ EBdLb7f3rzTXW6qDLCGuyaFaTwBxVxvIrQAZ5Pb7pqjXNKOzCnvO2snZTupo7A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4N6p7T208Sz1PvW for ; Wed, 9 Nov 2022 15:00:53 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id D2B9042D26; Wed, 9 Nov 2022 16:00:50 +0100 (CET) Date: Wed, 9 Nov 2022 16:00:50 +0100 From: Baptiste Daroussin To: arch@freebsd.org Subject: Retire mta_start_script Message-ID: <20221109150050.zkef3rgftym6pv64@aniel.nours.eu> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-ThisMailContainsUnwantedMimeParts: N Hello everyone, I do plan on retiring mta_start_script and what goes with it: - /etc/rc.d/othermta the othermta mecanism (calling mta_start_script if defined to something different than /etc/rc.sendmail) As far as I am aware all mta in the ports tree are not using this mecanism. I do plan on just retiring all of this for FreeBSD 14.0. If no argumented objections is made, I will retire next week. Best regards, Bapt From nobody Wed Nov 9 15:18:03 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6pWQ5Mcgz4XL5H for ; Wed, 9 Nov 2022 15:18:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6pWQ2sXKz4HZP; Wed, 9 Nov 2022 15:18:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 2A9FI3vV050427 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 9 Nov 2022 07:18:03 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 2A9FI3sF050426; Wed, 9 Nov 2022 07:18:03 -0800 (PST) (envelope-from sgk) Date: Wed, 9 Nov 2022 07:18:03 -0800 From: Steve Kargl To: Baptiste Daroussin Cc: arch@freebsd.org Subject: Re: Retire mta_start_script Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <20221109150050.zkef3rgftym6pv64@aniel.nours.eu> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221109150050.zkef3rgftym6pv64@aniel.nours.eu> X-Rspamd-Queue-Id: 4N6pWQ2sXKz4HZP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-ThisMailContainsUnwantedMimeParts: N On Wed, Nov 09, 2022 at 04:00:50PM +0100, Baptiste Daroussin wrote: > > I do plan on retiring mta_start_script and what goes with it: > - /etc/rc.d/othermta > > the othermta mecanism (calling mta_start_script if defined to something > different than /etc/rc.sendmail) > > As far as I am aware all mta in the ports tree are not using this mecanism. > > I do plan on just retiring all of this for FreeBSD 14.0. > > If no argumented objections is made, I will retire next week. > What are the effects on the in-tree sendmail? Are you planning to remove it as well? -- Steve From nobody Wed Nov 9 15:59:57 2022 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6qRg1sYJz4d9rp for ; Wed, 9 Nov 2022 15:59:59 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6qRg1P0Hz4NK6; Wed, 9 Nov 2022 15:59:59 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668009599; 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=ozsG5nYHg+l/yVWgA7aN94USVGv3/PTzA6vTLnxPsQw=; b=V0EXPkkKQ5J/B0TxyFBPokt2dPTAkgb99FLmNzwsNDdNOB0KEr2Zsjwne2vOdrXsWE5SiQ LBqW+NaVQilH7JMljrRpBGyjBXS91zQJ6AZHO6zDf/MXZ9dY0HRtCJ8j8Pv6el34DbqBZe WE6k2pGo0jk7gaX+DsoHMGVjT7sVgt35wpjhq8p4C9QIahpJjbfna7iNmzQRH87v9PBZUx 8abMW+4pOWx7cSuB6469/DaEO71QrOFpo8C8lI0AHSnPwXvMrPKDPxt/Oo+9YWR8hOISja 1K5eo5QOHuRD57JK7vCYpzKe5rAc6Nt5AeZWzQsPRcnDggxnOqVmRJe8G+gw/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668009599; 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=ozsG5nYHg+l/yVWgA7aN94USVGv3/PTzA6vTLnxPsQw=; b=pqJeNIJ5hu/JCKj394hH6IVga7d3WI8J26nE8o1G1GWUrMLmHbkuTllLqwKG/MW115OQXP JbDZRfd/k6Sjb4kPpAhcFHuZiLbowsm5ol9Q5NwpLEs0hcD7kHzxA2hRnXBooK0XRre/iR iLjE02O0M4v+coVtgdBHgBwZqsdIxh7020WNBdh+UhuePKcziIhLGej64xYCzBGyXTgA64 rUDeuKRBJ79Rp5j8pLs98ZHbeOnVF7GoJdyTWdNiS8dc2xyKnVcE09VvhSHqlFJTq5T5XK WY/r/81hq/U3Bj+fToCT/f7WfPZgoKYlPS7zeZqK1FPF9XPtGt5oGpDKEogb1g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668009599; a=rsa-sha256; cv=none; b=lmmCAM0hJe+5huUi1A7Cyq4ojXk5paIf0DS4NcATMj++ggeGKqNfZNatMr+6/R/kWUl+gj fNxoFc7igCQm72JuZFRKawVjT5t9F8e8Z1JvuvbHTdjyC+s5lxCA0w1hkn0Jiy/w245ppO uDvk3jxxMzCFJJdgeBvft2V4hqoVen8TMouHoMQchb8Zs6q/WFH1Lt20KR45X4V2+lhluQ TLSY/wYZQTzdd3JEJhZ9OSKl1a4UH+yM8vr4Y8rd/FZY4tyJ0NGSCJvILVpyLE06xIAeVx 5sL/eMnOPTGf8y+deVKEXFRA4MsJ+V8zb8fEq0Hf5HmCd4PSo5IO/Sl5jrNYCw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (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: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4N6qRf6nZzz1Pj5; Wed, 9 Nov 2022 15:59:58 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id AC54E43D50; Wed, 9 Nov 2022 16:59:57 +0100 (CET) Date: Wed, 9 Nov 2022 16:59:57 +0100 From: Baptiste Daroussin To: Steve Kargl Cc: arch@freebsd.org Subject: Re: Retire mta_start_script Message-ID: <20221109155957.hiejmef3q3rb2e2w@aniel.nours.eu> References: <20221109150050.zkef3rgftym6pv64@aniel.nours.eu> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Wed, Nov 09, 2022 at 07:18:03AM -0800, Steve Kargl wrote: > On Wed, Nov 09, 2022 at 04:00:50PM +0100, Baptiste Daroussin wrote: > > > > I do plan on retiring mta_start_script and what goes with it: > > - /etc/rc.d/othermta > > > > the othermta mecanism (calling mta_start_script if defined to something > > different than /etc/rc.sendmail) > > > > As far as I am aware all mta in the ports tree are not using this mecanism. > > > > I do plan on just retiring all of this for FreeBSD 14.0. > > > > If no argumented objections is made, I will retire next week. > > > > What are the effects on the in-tree sendmail? Are you planning > to remove it as well? 0 effect on the in-tree sendmail which does not use this at all but uses rc.d/sendmail for the last 20 years or so. No I have no plan to remove sendmail yet, at least not for 14.0. Best regards, Bapt From nobody Wed Nov 9 20:01:41 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6wpq4lGZz4XDwt for ; Wed, 9 Nov 2022 20:01:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6wpp4wGwz3vnl for ; Wed, 9 Nov 2022 20:01:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=aMKnbOdG; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::536) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x536.google.com with SMTP id a67so28648016edf.12 for ; Wed, 09 Nov 2022 12:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=jjNeTrLyLx+uJFEZJWzdmp/7dCqWawcAAd10HVGbHZA=; b=aMKnbOdGGZqpKEgv1GA1SEhfCsw0b8K5IbA9cnJPX6oJsnwX1d1KWEiXJtFqrbThMo IZD901/OK9o31Q7f5K79P4tQYJhpW/SV1GRSEkBopQIMz+juC7yQcC79eaQHGond6Nen syCKUZD6q1num2MGllmvYcXzVS5VCmFXQ4OZyBn0gcLpB8Pnrgq6gndkc4wi2jzoyP0a ns4DvyN+vKnrK3tf7hf2XIE/yDC9aBzFBnLQauMeFMnjLvgIrO7X53hZ9cg5xmW3RVEE nwSVoMIHmzjyGJIZIrOYP3abGvDenOGq/Techqd0tJSd7Tfa3cv/YitQF8xf5vleQo9G wOGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jjNeTrLyLx+uJFEZJWzdmp/7dCqWawcAAd10HVGbHZA=; b=D8nP5UFcaIUohR7dAD5C0+WpIz2yaiX3dawYZMTmvLg4c+gXszz9nAE8K/kRSMOz0l zccAfK2kDiYmGGZPkwVeFSRIxj2udW5Lev5fhYGcv4X/eY+h2wGOYgn8776N+N3PCQJy kyKePDejk9vJl5Sy+BGoH2Y1nXmQ3ZTp2PqNfvIhvTUTTocOX3vISACwh2hydRU1VPWr kJyiDMVP1VSU2maaXf3IXY7nZ+QvYmtGkarxnuzf0dcUXChQC8mCm/si67Kpu49Mgd1w wBblpwgTYxSQRlO9VzHJ/KGvCy3efEetOkRqzhtfnsuLAvOFFF0RuB4DUa40qcP1/rwj VMpw== X-Gm-Message-State: ACrzQf1HTXfUI/0O4CHWspGvZ6S7dCJUNJYg23uZAZvb3gYn3qsLp+qb zJC3RKLDZoU3zHwizP8VlQA8FwzOOts1smFBgiNn7ApgDIQ= X-Google-Smtp-Source: AMsMyM5AstGyyWUado1Unz/+AxIoDU8X/zWN2pT1CireXnYmvFZGugzMaVbJsjfrA0Vn9S8Xfm+OvaW0NCGHjDLVbJs= X-Received: by 2002:a05:6402:94e:b0:463:525e:8738 with SMTP id h14-20020a056402094e00b00463525e8738mr53342783edz.154.1668024112327; Wed, 09 Nov 2022 12:01:52 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Wed, 9 Nov 2022 13:01:41 -0700 Message-ID: Subject: Dropping firewire support from boot loader To: "freebsd-arch@freebsd.org" , Kyle Evans Content-Type: multipart/alternative; boundary="000000000000b1603405ed0f2081" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4N6wpp4wGwz3vnl X-ThisMailContainsUnwantedMimeParts: N --000000000000b1603405ed0f2081 Content-Type: text/plain; charset="UTF-8" I'd like to drop firewire support from the boot loader. It's not been used in quite some time, as far as I can tell. Nor have I (or anybody else) tested it in forever. Is anybody still using it? Does anybody know if it works? Any objections to removing it from FreeBSD 14? Warner --000000000000b1603405ed0f2081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to drop firewire support from the boot loader= . It's not been used in quite some time, as far as I can tell. Nor have= I (or anybody else) tested it in forever.

Is anybody st= ill using it? Does anybody know if it works? Any objections to removing it = from FreeBSD 14?

Warner
--000000000000b1603405ed0f2081-- From nobody Wed Nov 9 22:42:19 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N70NK19FXz4dSjq for ; Wed, 9 Nov 2022 22:42:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N70ND4GS9z3Cyx for ; Wed, 9 Nov 2022 22:42:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fAFn2mEh; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668033754; bh=7ddX1aoYHGnWawnBJQn4Qvc83MCQ2G9JioPnbATtTqs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=fAFn2mEhgVmgVeCqg04Ozec3fNVVYto5WvPYeLrm0fFFkkXgOkbdbOe+tNueYrIhGxD9KsJbMvbX4nRRSM6cy1OPFAfu37XNCHEXlmrMbCvGnRiIIiYqgDSs5K7YPnPK1s+trIc01YNOWcvttRKN0J7OPcelkKkzVP1MBFIOMENbLwvejgjSOJ8ZRJ0rPaq7GvQVM6/2f8NdMEfd84nHn+Xr3h8x7Y1WgTRY9tH0TqM4mMX2R6t80bSeSf6c8I7sZ3TdJsgraPEXe2ZlrkM9LJq5tFEXmcMKCs0CGVzSfZg+O7yBKOlBZJTHdtA+CI4KVjvkl865fvBGCILupDULpw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668033754; bh=wcjlYPRYtIJWlVsNvhmN1zhaOik4jtmlQ6+GfUvja9T=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=i6uaWZdqi4wgqmy3YoGdACvy0pxoQXAC9FR+Ny3yFGeh/16JfjmcAdNK6yU6+UoKS64+dgG/DCo15VJMjkwUyfXQcE6itUkcxJZX9hjcmym+ZCmjIZwcRX061MesOHYcaO7GT+SxBVUJf8L7SFtqMrS2BeOHFElc0THIOl9ZpifFw6X6JW8P5EY+2wjU/MpEldgzVeNFfJtEj2uYrb/n5XYyMlg08E22jp1ERRm6lN+xP0EfmvKWqdhiUruEEJGxVRTTeOFl2d7H1FwWvcNu27W2OX+8OjfIec6W15eShfTVYHe1qQIa4v0QW/Sl1NqShi/8Sw7pnjR2NgzdceoACg== X-YMail-OSG: PRrKxT0VM1n3jNlNMsWIXF0KEQKLQ7A0HgRPkA5ejPwgHFaupuX3mWBqWvX6noG o5eGKk7dPWC3aGt2ab_hrZzDnx.OLVRnhH6sBegHi4mSHYHbxRNTMUndHG2zOMcHBrvfORh1MSOu ZB5PVO9OzAMXSbtUTtQK1jPgCKdyFEQ9PlnfjDS2OwR0WZoMpRcPe6mkt2fCw_WMwrkSHqxTxSOJ aDxREmXpI6yT6NEmu8_5NE3.DHR_z90g08st5tGFM3qk.R3a_qZOSxpoHqB9qkIvUbgxi8tgH2tr _bcmHFQf0l0_RVW_PTGeJ4VUhmCpalaYSXlunvos9nTFK75W3HiNwAGwVQYfA_Qa7wb_6um2KMIx mnmi0Kc8ELFMnqt47dEj5D0wRjuI4KDfCQ.tIvWHOSk6cKd7egGqgCD3VO7CgCe8vbmZq4b4T4Br lwLF4r88UU2qDRMvT8hU7hMwfODox3qwEQr9KCJmHrb.H753mp9SZL_Oi0wmUBaZ3jkKDLXgipG0 dw_34MrqEVOCzNkL0EwdOro8nBiRddjF1Mvy5WuZi4ZcJpjdE9d0Lz.NXAEo6sBJW._yqPLK2S9C Nc.LCn9SCijkrSTei8sBmq2kj7tIITVIZInEFAXboqui9p7HmZXHPkNT_ipnB0LImd0Y6bZ6mDEA HAdzgpwnmJqdVDssCicY3vN40CmBr66.EgjI2J5sVYmMlOmcgfW7ZzkkW.vL_0rShdd26djPoABh P7rqxXCPD6A62aMlET3pZIvN5eErN98R5iHTV0UFaNeUz0KWarDabL4SOp6FtG4xMazG0WDymSI7 w9LgbWMZdPFUyXsNFkik7qQkAEDtKJWhDxd8Bs7oBSHTlIXs5KDU8fR9yCk4garLtNK8c2ucqO5h mQU3ZxBri4C0PMtOkrwuggk9l86y5ZD03Firo8JFM9BK7wUyVblKjmYAJ4Shdovu.JQuZNfJSvp. wyl6k7QNNs3SDyyZBzoraMysTjuFhO0Abs3r9fDR4rHEUuhELXDC2xDeJuAO1DreiV.iYic4bqO5 1_LBml9qquGmnadp_Q.8juWOu.z45YbC5sSi_4vCyHx1wHYU4hjTgdixA_vDxJNXP3SmR9ZMZy4E lNv6kU3enbr4cib_G6QbBzenyN1iNNSm6I8QBCoTRUKY3lcUoMpklHtCmyBHOSuzMBxNUnUxVfsu GZ1rKfvgCymoLdscQ4nwcJcnFhRfo4k_hLSfo6vLmgOx.Kr_7aT_maMw4j4dpXEvBuwFa4nWM_hr HKRZIzFp9.FnHV2.7wCz3kNRpHmNi7zwjMSSFO19Eq08ls6JqK9PyqfHLKfXdkhF4Nd_sNdGdlMM yBaP25jBr2gWJkgtE3j8cfqFPnLR6a8GY.V_tw2VBnsO985ybnpcudgHfzzV9RBN89HgmK9J4tXA gUrv8WFniRUQLgDwNN6X44zk32aJk_jFmT.JugwpR3p7iUOq9g4OOozSR8yjCIpU4NuR91_ZK96B Z7Hi_bYD8Rnnz7EPxFv8JtH5wWR3YpbLpNfkcZhCrU2FhnM0Fno9C7E7hRRuRDL35IFqSWoBh8eP BhSXGXBkwXEG4P_4haQ9y3cEXnLQtyelLwahwkabxmMRHhW_mq4E5KUl1gXmmsvHEshVWDAsFmL5 3yV5VtX360rO8PLwFs39ssZHJRfcxRr.KxQ04ObMPEL52ZcVp1hvjNsfi0LxiEwALcXrVURITlnD K0KZSjLpZLEGl6GcL_5uDhhQ4XLt4TneHWzgzHNc2RcrY3FhKrgcd5BVSG2G7hcZeOrBR6oJwWM5 1vtFDZh1_ij7KYMxE800j_4Qdacz_.OuNRjmRhMwJOszujzf2su64vqdUmqvoaYlj2ulwYNGoVgw xRyc0QECP2c48EzLqQeKgXIGyqgtNnhgqInDrODolclwMMAFqMRdWujpfE6Bu6y_9.U.Dg8I4QQ6 vnQDLESnLPxSrEmqiMRe2nPFiHI7QuoUlFU3zeA4YOEf6nZQFEatKJp0WM8aOMNcxeCK6HEpkAOt Q50Rg4cU1k9HADkJUJ_OuI5OinuA7s9Jn.cahKQnFU77NJ2zXAKx5GJxDtx_atWOAOEXhgLY70n4 nycErrKypJQK_MGcNXpSDyAwYA2OFZF0Lna2egssFYkGCPYxFTd1768_EVrj40rHr.wi2ifvJF1Q 4mTxHMWMqsXTwN5QHLObxbOHRcaHIgAjh7Zy4Z.sxs91.CYCpYnaWpHlhCY7UmZFd7Nd3.xOn5cM E8Yg3a_so4xvMtH00UefM8KqWYEqSshNfwklp6OM47Wg098LhFYCq9JVCnEKXHVTBYiiU5F8.rOR 2ays- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Nov 2022 22:42:34 +0000 Received: by hermes--production-bf1-5878955b5f-gz9tn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1ddff08038e591bcff9614baf115008d; Wed, 09 Nov 2022 22:42:32 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: RE: Dropping firewire support from boot loader Message-Id: Date: Wed, 9 Nov 2022 14:42:19 -0800 To: Warner Losh , freebsd-arch , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3731.200.110.1.12) References: X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; SUBJECT_ENDS_SPACES(0.50)[]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org] X-Rspamd-Queue-Id: 4N70ND4GS9z3Cyx X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote on Date: Wed, 09 Nov 2022 20:01:41 UTC : > I'd like to drop firewire support from the boot loader. It's not been used > in quite some time, as far as I can tell. Nor have I (or anybody else) > tested it in forever. > > Is anybody still using it? Does anybody know if it works? Any objections to > removing it from FreeBSD 14? I would suggest that old PowerMac's might be the most likely usage context. I no longer have a PowerPC context of any kind. I mostly booted from SATA SSD's back when I had access to working PowerMacs. I've not been able to remember if I'd tried FireWire based booting of FreeBSD or what the status was if/when I did. I did use the cross machine FireWire means of looking into boot crashes, as it could report some console output even after the display quit updating for some problems I had. (I never had a serial console context on any of the old PowerMacs.) I do not remember much detail about this use. I'm not sure if I can submit to freebsd-ppc any more but I'll try for this reply. If it does not show up, you may need to send your own message there if you want a message about the issue there. === Mark Millard marklmi at yahoo.com From nobody Wed Nov 9 22:51:48 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N70bD6YS4z4dTZv for ; Wed, 9 Nov 2022 22:52:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N70b83bLZz3F1V for ; Wed, 9 Nov 2022 22:52:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="SY3eQ/Bd"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668034322; bh=8VR3XvPR/sYxKInmakso+kIpWF6Fe96Gq1aKUYtyR3c=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=SY3eQ/BdHUdfzA7bnsLXiHnlATaFXTZHBcvmFNpaOGAd+5wKfCdvRr1Th8W87pezFo8/NF5Z+z6sKQU0g9Toy6t96kbXUoDtn/596nUo6WgOo5/DMfYByxvqfRx2twi8HLH9+gllFUQnEHgf4ChxL9hgcJOQLooykaBqDxwHLPdlQBIXOVRszqWZzVEMpgq/CH/45EQOFuBysAyWfJ/OsmBGUaUdVPssl77iFsgljWd7DQ4imO6/3QzEZIHc+DR4o3atJ35NP7lrHyUUSxNOOLTX+t8mgbSDYSSvqDgjZhKiD8fs1fr2ZTbRH2gEQKiikoVXs3Oy7DfFJjjhpsb4tg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668034322; bh=CSvxP9lwdDeUF+iTg3cpygsG998Aa86aKWThCfs1mmC=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=RZgfRPxQgS/zd6srItJyLzPmmHXy6zNQa5Bc8/OcpxI+MP2QCyaMKF8wsAw0Uz4oc88zEmjaWdmzG1gWSpqoqzEpovoKdi3IQtbuDmjZPIzHO3J6cEI+yeENIiYqF3twt/6C7gfVJMGfOPT9RhS8XJaa4fbFkQ5U4da2UxH0RIHDscuNrfB1wk7EKU9bnsGphdozZ/DP/P+rOXBHNU940f9jF/xt0Wa/C1Kr3WCBk+sFJhnWHjSi75WPzuAIHl0VnxdYbgzUAqgDXAPTal2mQ8v1Sj9hyQlJKkTJ+vF/33eNnKYW12NY1AbSeK81j4Z9ohKVk/zaCb/No13/2xGd3g== X-YMail-OSG: 6cauBqEVM1k3gT39SKilMd9isLOxAWuBBz2vDcdSqVYIImt8tS9HoGN6.YKEr5k q.GI_5UDzxxN1npckuSWjBJ23pPbKKQyrct6Komg0y2pWAaPqsSUDdJK7DmUv.3LgQyW4XZnkzCt VcrgiuN_KNxSjSAq1NTNJp_Rwmh_Tj4X6wQqdtlTL.T00huASiPJDTzN37nTkUhTijVhVsH7lfHH ZKG22uJbWGrxqUPzx574vOIXVzcfqNSZwt7HgdqRIoSy77KhsMN_VDz_0JctUDOMmx0JE9tzApSa BjHWfhtwzkrY666kyDJB3pCqIqrDJt5wDFhs_MBKO5aD36T0fgtXAWgL8.9Aksq_CHmJ1gqPoEc4 .70klEG2O1pv47NYYLaeYU_O.zAJoqXzo7g3XXF6tTn1c.YLVla8FFcjdgomoXD0UbNBum7KzSE8 JkWgmS_67upMAFUVFN9Jgnq2Y69IFK0Pin5kKWrbCxgoxvA7TZRGyqquFCsHi3CcMTjELL1oXBef PkIEZmYTwS1wtGDXQPTIb9i2Lk_9TAkychuLEImPEsRCGytbTQJYQBKuTBqJbLwGX3Xt_zzeIuQ_ R9ZjYsD3bFTKfeLgEiju_id48tol.37gcx2BK2j_kjQge2a_m1XlZPKIZcQrjIG7lRHBfx9rHZN. fkCNf0r3ihLoFLQYrxWdjFlJx_njjXompdGt71TM7AoK37avtou1FdNdLmFj3xD_ZKUsu4Y_ouFu DX6erB0_5KhV8OIVz9Ca2NNhCfuODVAQxeaLftoS7l4SjNr5Y1ZcatnLTJpE35oMMcgCft3caTlc 1NQLt7iXdxLCEHgQl5ZgUirGB52n5bwhQoS7o7UPErdamC_GAUfYCbl5iP_sJ1mIf_Kn3qrinIAh A4.9JhU0NiW1nS5bsu62R2i56EKTbd4G3GaooX4vMIChAs2z.VvRrSxDVuHGUE_WYCZjlMr1gDFu lq5R8WtBMFlR1YqHEU.M209zxDBXCiJ1LD67cGUO6KG5wIMcKZtHV._JKDIDd_LMFBra4jPIyqJz TGLD7Ty1T2TvwiYBptjLqOIykIaTbesblrLP73dySYb8QTkJpy5eJr.p7YtdGpzU1UOCmqWPyz9R 1oYJiI3xJEkTYVV7hPaFC3Gumu801vaSmhzABG0nQ9bMN7p0gJFVsERXq3u64FY.AaOrlxiXwEye vNvATIcvcPE6tk5uoxmwyleXLFrp9RJZynIO8gkFiiuY3K0NTVsj_sXf59zMVUHgaWRKIfwH2P3x HIBVYXOumA2RmftvUzb7mRLoHVUKmsz5ml0v3h.MHNw4PSfMWTXnF0lcK3NenaVOzFsqFndRoPCU tpS1irMNeZekM4rXuS3K.nH4_sG6Me_MC9CwRejEqs_ju7GJagQPMa4kQYz1rKyd4_9QIiiN39Dy 0X0q.H8hnXAW0slOPzBKqUlV8vl3X4A7P9zkr14ydqMsUUuvx07oHsGtHi5Q5viIeTDLZUye7bEb pPWxVvS6DQI3NSm8FX4HOZi_BxKHgSliaDmuwsWOrHRdmj0d8MdELkI0XMSYn8e0XXB8_YmQkIt9 dMFD2iWgZtOSw0Cl_CAJE3FhyzF3krYtizg7sg1Xe3sUevmKBvXKt7Q0dx8kKij3A7oqS3YEheQw AP1PyJ1Ja4qKFVHofdfL.7YTK96mF7NPltZezHYXY2KWvLUJfxhawEXNXUzdf4wzFv0j_cBg9BPJ dgLWg7Bv9.fJHjz9YBZWyiluzEH1NF_aD5oIKUxhY.y0aoHAo.s04KlIeN5jhDF_NCLl5bknYAU7 l4Bcvme5fLPQsyggqSec9Ec9uu7vy3fz9rdFeFTsyOa92ze2kB0Tpn5kj73jDCMEgvr0XBdozPxG rzdJsn.MKzZ3ysx048HM2CnNnan32CA8UoiK.by9BVH9kV7IsJKqGZaXSP5SnUDYN0volFRZRkwo q_5HUw5Y9M6E4voe1BCvT_ntF1BsvMBIGwYdI9VmeO6_R_xNRc9hpQrGbmlGECQbC6zpztG6w.Pu lHOYY9BE2U.k_nrPVpLQuFuGaHZRuDvmzpVaBqKMnyYpR9l9DC6tBR3JdPWsu0iteYCLzoD.gZBI FG4nBQqjmnxo2WfRFq9PiNYCDESE9lwHPeaytVkFsBUl5CNhI4lv0BJ09ad8nDV1D2JrzUJg4Ip0 Gnr7j2rIyvXOEbDQ_.OYQKYS_zEbSnRPjZYXzN21hbBpTO3kRcxIayfAzAC3LLgPdexTPwrW6F99 AXJwNeLuHDD.IzBrfF4TegzOdnn9ljcSWatMAr1DxP4.lWht_cGkvogmhmi3nw9M1Rjobhf3AP5l XZXBB X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Nov 2022 22:52:02 +0000 Received: by hermes--production-ne1-6bcfb7fb87-qqz4t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d1230743686023b53ca0d3c79731c2ba; Wed, 09 Nov 2022 22:52:00 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: Dropping firewire support from boot loader Date: Wed, 9 Nov 2022 14:51:48 -0800 References: To: Warner Losh , freebsd-arch In-Reply-To: Message-Id: <849BB304-8772-4B37-8842-E5CC3B89FBDF@yahoo.com> X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org] X-Rspamd-Queue-Id: 4N70b83bLZz3F1V X-ThisMailContainsUnwantedMimeParts: N On Nov 9, 2022, at 14:42, Mark Millard wrote: > Warner Losh wrote on > Date: Wed, 09 Nov 2022 20:01:41 UTC : >=20 >> I'd like to drop firewire support from the boot loader. It's not been = used >> in quite some time, as far as I can tell. Nor have I (or anybody = else) >> tested it in forever. >>=20 >> Is anybody still using it? Does anybody know if it works? Any = objections to >> removing it from FreeBSD 14? >=20 > I would suggest that old PowerMac's might be the most > likely usage context. >=20 > I no longer have a PowerPC context of any kind. I mostly > booted from SATA SSD's back when I had access to working > PowerMacs. I've not been able to remember if I'd tried > FireWire based booting of FreeBSD or what the status was > if/when I did. >=20 > I did use the cross machine FireWire means of looking > into boot crashes, as it could report some console > output even after the display quit updating for some > problems I had. (I never had a serial console context > on any of the old PowerMacs.) I do not remember much > detail about this use. >=20 > I'm not sure if I can submit to freebsd-ppc any more but > I'll try for this reply. If it does not show up, you may > need to send your own message there if you want a message > about the issue there. FYI . . . I'm no longer a member of freebsd-ppc and can not submit to the list as long as that is the case: the message bounced back from freebsd-ppc for this reason. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 9 23:55:42 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N720r03b7z4dfyJ for ; Wed, 9 Nov 2022 23:55:56 +0000 (UTC) (envelope-from wlosh@bsdimp.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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N720q1ndBz3MVt for ; Wed, 9 Nov 2022 23:55:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x631.google.com with SMTP id 13so1030909ejn.3 for ; Wed, 09 Nov 2022 15:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tivkZkH9iB7XjyHv85+D8LtWkQpXpVe4VCYFR0LDeVw=; b=6h/Pi4sOSOdx7LH+Se5h7lDg8FT/HFhPxwA6jEONrNBWVXrjnrd/KmnpSWu2NsFkpj BUZfJU4lJxKc0AofC/IU/K8IuPRzJ0563jmL5bt5AFEoyhEAhW1paBadnk4c3O0rFkBH kYzB98NL3ZuCcfYa4P7VVqnS8SWGVLSlAHD0MMfUc43tbCya/mEovmtRs9FLl/s3zP4z 8H/AYdfj034UU2ED1BGny99cnJi1ml0DolaMHjJY0bGY3GjAw/908VvMo/PEw7jkNImw nke0/ubqZM4glZP6oeDjbKqp2hIvM1WQNhA6OGqyA+8FhriNbYwAYdUoNlG8H1xfIlr9 DQUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=tivkZkH9iB7XjyHv85+D8LtWkQpXpVe4VCYFR0LDeVw=; b=P7e4HRs0rLhgdnJP4u5pI9pkACOaySIlOeRyRCfnkk2bl55FMlSVg6BhHezm3obNmK VpF/F/VF0uNQd95EhbO2aubHQhYsBYymAlY2W1rNZKIRCQZoBMnTHLnmxGerWu6PwYua iOwzEsUxTq+YWVRZO0ScOYVq7r2T48b+jP2zf1Mqw8aOKyS+2rueQ1wCCoJULN+/9zYW iE3oaC2ogS2ToHnWaPKM+rswmRkASo9uakbNeZ5YiiThe+j38QP210cTp/5IBT2i6AA0 QlznTwphQS7HtVUSf4IEN04vfqhVPsUygB9+twGO5hNhJsyYN3qmrqvpMfdGWHma98QB QXXQ== X-Gm-Message-State: ACrzQf1Sm0KNj2KrofC5TJgxkhmvXrikoOGUguOTQjBAV3QVwAHWM0Fu VYeVHcPHTO2zTr4sQZsIb/sRGxbx7gqI/3PAGf31Kg== X-Google-Smtp-Source: AMsMyM7JPth7Bo/RWBOZLhRJxJo80uzvG5tEZDLnPX5SbAClWl4RaCYZoSWGsDW9N836omKAiq7oCzfSLDJvBB2k2po= X-Received: by 2002:a17:907:2710:b0:7ad:86f9:9bad with SMTP id w16-20020a170907271000b007ad86f99badmr59568842ejk.32.1668038153704; Wed, 09 Nov 2022 15:55:53 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 9 Nov 2022 16:55:42 -0700 Message-ID: Subject: Re: Dropping firewire support from boot loader To: Mark Millard Cc: freebsd-arch , FreeBSD PowerPC ML Content-Type: multipart/alternative; boundary="0000000000009fb48405ed126587" X-Rspamd-Queue-Id: 4N720q1ndBz3MVt X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N --0000000000009fb48405ed126587 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 9, 2022 at 3:42 PM Mark Millard wrote: > Warner Losh wrote on > Date: Wed, 09 Nov 2022 20:01:41 UTC : > > > I'd like to drop firewire support from the boot loader. It's not been > used > > in quite some time, as far as I can tell. Nor have I (or anybody else) > > tested it in forever. > > > > Is anybody still using it? Does anybody know if it works? Any objections > to > > removing it from FreeBSD 14? > > I would suggest that old PowerMac's might be the most > likely usage context. > Right now, though, this is an i386 only feature... Warner --0000000000009fb48405ed126587 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 9, 2022 at 3:42 PM Mark M= illard <marklmi@yahoo.com> w= rote:
Warner Los= h <imp_at_bsdimp.com> wrote on
Date: Wed, 09 Nov 2022 20:01:41 UTC :

> I'd like to drop firewire support from the boot loader. It's n= ot been used
> in quite some time, as far as I can tell. Nor have I (or anybody else)=
> tested it in forever.
>
> Is anybody still using it? Does anybody know if it works? Any objectio= ns to
> removing it from FreeBSD 14?

I would suggest that old PowerMac's might be the most
likely usage context.

Right now, though= , this is an i386 only feature...

Warner
--0000000000009fb48405ed126587-- From nobody Thu Nov 10 10:07:27 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N7HZb6Xhlz4XNkj; Thu, 10 Nov 2022 10:07:35 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4N7HZb3dtkz3nHL; Thu, 10 Nov 2022 10:07:35 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (gw.br-thn-01.caladan.net.uk [80.71.4.65] (may be forged)) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 2AAA7SHU092516; Thu, 10 Nov 2022 10:07:28 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Dropping firewire support from boot loader From: Bob Bishop In-Reply-To: Date: Thu, 10 Nov 2022 10:07:27 +0000 Cc: Mark Millard , freebsd-arch , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4N7HZb3dtkz3nHL X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB] X-ThisMailContainsUnwantedMimeParts: N Hi, > On 9 Nov 2022, at 23:55, Warner Losh wrote: >=20 >=20 >=20 > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard wrote: > Warner Losh wrote on > Date: Wed, 09 Nov 2022 20:01:41 UTC : >=20 > > I'd like to drop firewire support from the boot loader. It's not = been used > > in quite some time, as far as I can tell. Nor have I (or anybody = else) > > tested it in forever. > >=20 > > Is anybody still using it? Does anybody know if it works? Any = objections to > > removing it from FreeBSD 14? I think I still have hardware that will do this. I can check it out if = anyone cares...=20 > I would suggest that old PowerMac's might be the most > likely usage context. >=20 > Right now, though, this is an i386 only feature... >=20 > Warner -- Bob Bishop rb@gid.co.uk From nobody Thu Nov 10 21:53:04 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N7bDv3pw2z4XNhr for ; Thu, 10 Nov 2022 21:53:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N7bDs5hGTz4Kt4 for ; Thu, 10 Nov 2022 21:53:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=1G596tzH; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::633) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x633.google.com with SMTP id t25so8460156ejb.8 for ; Thu, 10 Nov 2022 13:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=LHIFs8vzXQoz063kPoGRdyaEWkRt9iXMCbHX1nZl5DE=; b=1G596tzHh4hVNXI9hbolHIol997wCeSXodU+diMkTNu3iMRqdgOLFZKLAnKgG9duGL NoH38TNlb+9iJ9DJscsNMUS3HYm9FTJPu9NiYaVROowa6v9q9wsqQaIW3mvzB2G6+jWS Ph6wYZvKlb3KBdV4/xRbR4iklXdv13IizvfPWo3TfHkUIOpwqFrBLvht74GYVXBbuZE6 iwiSd263Lm1iXfMlKimo8+ulPYq156ZVpo4Fo9Px76g+o5rY/NhTKre/i+8HV5f6YkxJ pMujCYLWxa8YP0RRlbZR8R5vxxSymrdrFABiEMWusLG7zEv48GdUFq1V3aoPs9ydlBoA U84Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=LHIFs8vzXQoz063kPoGRdyaEWkRt9iXMCbHX1nZl5DE=; b=VuHIP42wFDe0l+tX8G9OZjAP1Hq9WVDD7fPw4taUepTtDM6FzPY93DblYrVb+SJch+ zYhZHPtWvkc2aR3MHN1pnkACHexCKNfG4C2Asv7Bi3K/rptOnm9SFppkonvN5HSOtxDu xYItw/dUkpULuIijljf03rcU0T/eMwG3/0dsbLUGrzHiKcipbuFMRWsQPa62vlvh0fLU Bx41aoQIzArxnkND72lEP/2ar7L/hkhR4UuuQLgfu17/DM1Um4HHXgPXPEg8dfPz1B8Q JbdIf4OPlFLCqXkA/paYCryyz9oxfxyPC4ummRmxRbtGrUYi0AGDU09K+dfBfqfQ1/FW Oyhw== X-Gm-Message-State: ACrzQf2Cv3UcuzcE9x4tGLNM44GcQdx252istlQFfAfJfQH4w6sgbtfd AQiqhm4iZtMJZ39E01WE+VjrX0DbAonS+rXQe0fndex10vZ9Tg== X-Google-Smtp-Source: AMsMyM71jDDBYV9sAtn5lZvtkZ2MMHOFuACoQPV/Gkzh+Sfbj29XHtfjB9F/Ph58NG2xGbsWDzIMib5mI3WhmtDe9uI= X-Received: by 2002:a17:906:9d14:b0:799:9ace:e868 with SMTP id fn20-20020a1709069d1400b007999acee868mr3845179ejc.451.1668117195634; Thu, 10 Nov 2022 13:53:15 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 10 Nov 2022 14:53:04 -0700 Message-ID: Subject: Re: Dropping firewire support from boot loader Cc: freebsd-arch Content-Type: multipart/alternative; boundary="000000000000e3d4a505ed24cc1d" X-Spamd-Bar: / X-Spamd-Result: default: False [0.55 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.55)[0.546]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4N7bDs5hGTz4Kt4 X-ThisMailContainsUnwantedMimeParts: N --000000000000e3d4a505ed24cc1d Content-Type: text/plain; charset="UTF-8" I've created a diff: https://reviews.freebsd.org/D37334 Warner On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop wrote: > Hi, > > > On 9 Nov 2022, at 23:55, Warner Losh wrote: > > > > > > > > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard wrote: > > Warner Losh wrote on > > Date: Wed, 09 Nov 2022 20:01:41 UTC : > > > > > I'd like to drop firewire support from the boot loader. It's not been > used > > > in quite some time, as far as I can tell. Nor have I (or anybody else) > > > tested it in forever. > > > > > > Is anybody still using it? Does anybody know if it works? Any > objections to > > > removing it from FreeBSD 14? > > I think I still have hardware that will do this. I can check it out if > anyone cares... > > > I would suggest that old PowerMac's might be the most > > likely usage context. > > > > Right now, though, this is an i386 only feature... > > > > Warner > > -- > Bob Bishop > rb@gid.co.uk > > > > > --000000000000e3d4a505ed24cc1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've created a diff:=C2=A0https://reviews.freebsd.org/D37334

Warner

On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop <rb@gid.co.uk> wrote:
Hi,

> On 9 Nov 2022, at 23:55, Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Wed, Nov 9, 2022 at 3:42 PM Mark Millard <marklmi@yahoo.com> wrote:
> Warner Losh <imp_at_bsdimp.com> wrote on
> Date: Wed, 09 Nov 2022 20:01:41 UTC :
>
> > I'd like to drop firewire support from the boot loader. It= 9;s not been used
> > in quite some time, as far as I can tell. Nor have I (or anybody = else)
> > tested it in forever.
> >
> > Is anybody still using it? Does anybody know if it works? Any obj= ections to
> > removing it from FreeBSD 14?

I think I still have hardware that will do this. I can check it out if anyo= ne cares...

> I would suggest that old PowerMac's might be the most
> likely usage context.
>
> Right now, though, this is an i386 only feature...
>
> Warner

--
Bob Bishop
rb@gid.co.uk




--000000000000e3d4a505ed24cc1d-- From nobody Fri Nov 11 22:40:16 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N8DDp5l9xz4YSHw for ; Fri, 11 Nov 2022 22:40:26 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4N8DDn52Nfz3K2b for ; Fri, 11 Nov 2022 22:40:25 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk; dmarc=none Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 2ABMeGut036314; Fri, 11 Nov 2022 22:40:17 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Dropping firewire support from boot loader From: Bob Bishop In-Reply-To: Date: Fri, 11 Nov 2022 22:40:16 +0000 Cc: freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <8AED1B55-8756-402E-8749-4433639CBA19@gid.co.uk> References: To: Warner Losh X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[gid.co.uk]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4N8DDn52Nfz3K2b X-ThisMailContainsUnwantedMimeParts: N Hi, I do have hardware still, but the driver isn=E2=80=99t in GENERIC so I = can=E2=80=99t test without doing a big build. > On 10 Nov 2022, at 21:53, Warner Losh wrote: >=20 > I've created a diff: https://reviews.freebsd.org/D37334 >=20 > Warner >=20 > On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop wrote: > Hi, >=20 > > On 9 Nov 2022, at 23:55, Warner Losh wrote: > >=20 > >=20 > >=20 > > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard = wrote: > > Warner Losh wrote on > > Date: Wed, 09 Nov 2022 20:01:41 UTC : > >=20 > > > I'd like to drop firewire support from the boot loader. It's not = been used > > > in quite some time, as far as I can tell. Nor have I (or anybody = else) > > > tested it in forever. > > >=20 > > > Is anybody still using it? Does anybody know if it works? Any = objections to > > > removing it from FreeBSD 14? >=20 > I think I still have hardware that will do this. I can check it out if = anyone cares...=20 >=20 > > I would suggest that old PowerMac's might be the most > > likely usage context. > >=20 > > Right now, though, this is an i386 only feature... > >=20 > > Warner >=20 > -- > Bob Bishop > rb@gid.co.uk >=20 >=20 >=20 >=20 -- Bob Bishop rb@gid.co.uk From nobody Fri Nov 11 22:43:13 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N8DJ36vZ1z4YTPs for ; Fri, 11 Nov 2022 22:43:15 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4N8DJ22yJGz3LVm for ; Fri, 11 Nov 2022 22:43:14 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk; dmarc=none Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 2ABMhDab036382; Fri, 11 Nov 2022 22:43:13 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Dropping firewire support from boot loader From: Bob Bishop In-Reply-To: Date: Fri, 11 Nov 2022 22:43:13 +0000 Cc: freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[gid.co.uk]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4N8DJ22yJGz3LVm X-ThisMailContainsUnwantedMimeParts: N I wrote: > I do have hardware still, but the driver isn=E2=80=99t in GENERIC so I = can=E2=80=99t test without doing a big build. As you were. I=E2=80=99ll see if I can get an install done with = firewire.ko > On 10 Nov 2022, at 21:53, Warner Losh wrote: >=20 > I've created a diff: https://reviews.freebsd.org/D37334 >=20 > Warner >=20 > On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop wrote: > Hi, >=20 >> On 9 Nov 2022, at 23:55, Warner Losh wrote: >>=20 >>=20 >>=20 >> On Wed, Nov 9, 2022 at 3:42 PM Mark Millard = wrote: >> Warner Losh wrote on >> Date: Wed, 09 Nov 2022 20:01:41 UTC : >>=20 >>> I'd like to drop firewire support from the boot loader. It's not = been used >>> in quite some time, as far as I can tell. Nor have I (or anybody = else) >>> tested it in forever. >>>=20 >>> Is anybody still using it? Does anybody know if it works? Any = objections to >>> removing it from FreeBSD 14? >=20 > I think I still have hardware that will do this. I can check it out if = anyone cares...=20 >=20 >> I would suggest that old PowerMac's might be the most >> likely usage context. >>=20 >> Right now, though, this is an i386 only feature... >>=20 >> Warner >=20 > -- > Bob Bishop > rb@gid.co.uk >=20 >=20 >=20 >=20 -- Bob Bishop rb@gid.co.uk From nobody Sat Nov 12 20:25:06 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N8nBJ4DFYz4fv18 for ; Sat, 12 Nov 2022 20:25:12 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4N8nBH36gMz3p5Q for ; Sat, 12 Nov 2022 20:25:11 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk; dmarc=none Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 2ACKP7rg092568; Sat, 12 Nov 2022 20:25:07 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Dropping firewire support from boot loader From: Bob Bishop In-Reply-To: Date: Sat, 12 Nov 2022 20:25:06 +0000 Cc: freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <5E84C24A-E90F-4EE2-B054-EEDCC23DD6E6@gid.co.uk> References: To: Warner Losh X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[gid.co.uk]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4N8nBH36gMz3p5Q X-ThisMailContainsUnwantedMimeParts: N Hi, Well, the kernel support =E2=80=98just works=E2=80=99 so installing on = to a firewire disk is straightforward; just load up firewire.ko and = sbp.ko, and the disk comes up through CAM. However, I couldn=E2=80=99t get the loader to see the disk; I don=E2=80=99= t think this build of the loader includes the firewire bits. Not helped = on my hardware because the BIOS doesn=E2=80=99t have firewire disk boot = support. > On 10 Nov 2022, at 21:53, Warner Losh wrote: >=20 > I've created a diff: https://reviews.freebsd.org/D37334 >=20 > Warner >=20 > On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop wrote: > Hi, >=20 > > On 9 Nov 2022, at 23:55, Warner Losh wrote: > >=20 > >=20 > >=20 > > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard = wrote: > > Warner Losh wrote on > > Date: Wed, 09 Nov 2022 20:01:41 UTC : > >=20 > > > I'd like to drop firewire support from the boot loader. It's not = been used > > > in quite some time, as far as I can tell. Nor have I (or anybody = else) > > > tested it in forever. > > >=20 > > > Is anybody still using it? Does anybody know if it works? Any = objections to > > > removing it from FreeBSD 14? >=20 > I think I still have hardware that will do this. I can check it out if = anyone cares...=20 >=20 > > I would suggest that old PowerMac's might be the most > > likely usage context. > >=20 > > Right now, though, this is an i386 only feature... > >=20 > > Warner >=20 > -- > Bob Bishop > rb@gid.co.uk >=20 >=20 >=20 >=20 -- Bob Bishop rb@gid.co.uk From nobody Sat Nov 12 20:49:26 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N8nkW5J9Wz4g09J for ; Sat, 12 Nov 2022 20:49:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N8nkW2BDQz3ssS for ; Sat, 12 Nov 2022 20:49:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x633.google.com with SMTP id q9so19984394ejd.0 for ; Sat, 12 Nov 2022 12:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RDrdHbG2W+msS4JdpgseKLIw5oWv4bvt4Gc+x8HilOA=; b=MwTVxBFWQ6OPfwCr3jQOOb2ARlfihUNtQRwJMFxpdK/DED5ih02Eq/+CO70QeTXHwE /+lvdKpsOl4OPku/kem9lU2hzrjz5qaHnFSD75k7M1fHgna4sv9WiY6WSKwsDFU7GlhQ i3JS+Gcjzf8FaFPxFCSFK+0HX5fd9lIQ7xwuBSHmmPmmNyXyPcalptnClaf5b0AynIK8 1RznxKDmiL22ksCmexLqOgS7sOR8zZa9ExqVf9eFUkfpSraBhhi0p5Ae392qcnDG3IQu 8qDcywNmBhmmnWh0ldJx8wduzXNKEQkGTzKctbs9a9llyIn8mxIWxcfCH6n27CpoHcyg ne5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=RDrdHbG2W+msS4JdpgseKLIw5oWv4bvt4Gc+x8HilOA=; b=RL4cUkR+qRe9mCH6XTRDSGnVisDBVFZd/EvpEWgA8+dN9qOqUs3YJdDH4XDDIM/OFd yAOdUfIo1714GbJh65bIZmBimLMpiGEiusHoHuDlAf63bh0/pADL6O4vtl+TwC+fvzE8 +hs5oH+ciBpSpjeQ2azi6FtF7N9xRwJz6z8cALoLOG3UYnQQq1R0T/IPU7CLZlFxz561 9sOpa9bkP/vb/A3M7PbV+L6CciRNyH9hRY6xFeOr7ZU8h1MalBAgQXvRKrZemZf8eKqI V+RlYtuFXJT3Ok7aJgfNxXwCMAiZ0iXOFQhsjUhBIS58B3W/2pYlRKc5ZS3dt4h4mAGg EWKw== X-Gm-Message-State: ANoB5pkBJFYzV7Kd6YQqWwXQONZSGjbBK0vbkMz22bFbunUWZVUNWKz7 wQ/Q3PtwWPwf490r2CMXL0Cvcl7Ar9Kuk3met6kUtw== X-Google-Smtp-Source: AA0mqf7sTK6BfxkN31Vv/bq0CyhJqgrppLGTeCHpqoWXw9AbS+mMU2xgb0xjpny/NxzZieItLBBewrzDb+WNNlgnMRw= X-Received: by 2002:a17:906:c048:b0:7ae:d116:fabb with SMTP id bm8-20020a170906c04800b007aed116fabbmr5019267ejb.317.1668286177754; Sat, 12 Nov 2022 12:49:37 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <5E84C24A-E90F-4EE2-B054-EEDCC23DD6E6@gid.co.uk> In-Reply-To: <5E84C24A-E90F-4EE2-B054-EEDCC23DD6E6@gid.co.uk> From: Warner Losh Date: Sat, 12 Nov 2022 13:49:26 -0700 Message-ID: Subject: Re: Dropping firewire support from boot loader To: Bob Bishop Cc: freebsd-arch Content-Type: multipart/alternative; boundary="000000000000025bac05ed4c2584" X-Rspamd-Queue-Id: 4N8nkW2BDQz3ssS X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N --000000000000025bac05ed4c2584 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 12, 2022, 1:25 PM Bob Bishop wrote: > Hi, > > Well, the kernel support =E2=80=98just works=E2=80=99 so installing on to= a firewire disk > is straightforward; just load up firewire.ko and sbp.ko, and the disk com= es > up through CAM. > > However, I couldn=E2=80=99t get the loader to see the disk; I don=E2=80= =99t think this > build of the loader includes the firewire bits. Not helped on my hardware > because the BIOS doesn=E2=80=99t have firewire disk boot support. > Firmware isn't built by default. You need a special build for that... what is loading /boot/loader? Not sure you could boot the system with it if the bios doesn't support it (except by having a tiny disk that the BIOS understands and using that to boot off the fireworks root). Warner Warner > On 10 Nov 2022, at 21:53, Warner Losh wrote: > > > > I've created a diff: https://reviews.freebsd.org/D37334 > > > > Warner > > > > On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop wrote: > > Hi, > > > > > On 9 Nov 2022, at 23:55, Warner Losh wrote: > > > > > > > > > > > > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard wrote= : > > > Warner Losh wrote on > > > Date: Wed, 09 Nov 2022 20:01:41 UTC : > > > > > > > I'd like to drop firewire support from the boot loader. It's not > been used > > > > in quite some time, as far as I can tell. Nor have I (or anybody > else) > > > > tested it in forever. > > > > > > > > Is anybody still using it? Does anybody know if it works? Any > objections to > > > > removing it from FreeBSD 14? > > > > I think I still have hardware that will do this. I can check it out if > anyone cares... > > > > > I would suggest that old PowerMac's might be the most > > > likely usage context. > > > > > > Right now, though, this is an i386 only feature... > > > > > > Warner > > > > -- > > Bob Bishop > > rb@gid.co.uk > > > > > > > > > > -- > Bob Bishop > rb@gid.co.uk > > > > > --000000000000025bac05ed4c2584 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 12, 2022, 1:25 PM Bob Bishop <rb@gid.co.uk> wrote:
Hi,

Well, the kernel support =E2=80=98just works=E2=80=99 so installing on to a= firewire disk is straightforward; just load up firewire.ko and sbp.ko, and= the disk comes up through CAM.

However, I couldn=E2=80=99t get the loader to see the disk; I don=E2=80=99t= think this build of the loader includes the firewire bits. Not helped on m= y hardware because the BIOS doesn=E2=80=99t have firewire disk boot support= .

Firmware isn't built by default. You need a special build for that... = what is loading /boot/loader? Not sure you could boot the system with it if= the bios doesn't support it (except by having a tiny disk that the BIO= S understands and using that to boot off the fireworks root).

Warner=C2=A0
<= br>
Warner=C2=A0

> On 10 Nov 2022, at 21:53, Warner Losh <imp@bsdimp.com> wrote: >
> I've created a diff: https://reviews.freebsd.o= rg/D37334
>
> Warner
>
> On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop <rb@gid.co.uk> wrote: > Hi,
>
> > On 9 Nov 2022, at 23:55, Warner Losh <imp@bsdimp.com> wrote= :
> >
> >
> >
> > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard <marklmi@yahoo.com<= /a>> wrote:
> > Warner Losh <imp_at_bsdimp.com> wrote on
> > Date: Wed, 09 Nov 2022 20:01:41 UTC :
> >
> > > I'd like to drop firewire support from the boot loader. = It's not been used
> > > in quite some time, as far as I can tell. Nor have I (or any= body else)
> > > tested it in forever.
> > >
> > > Is anybody still using it? Does anybody know if it works? An= y objections to
> > > removing it from FreeBSD 14?
>
> I think I still have hardware that will do this. I can check it out if= anyone cares...
>
> > I would suggest that old PowerMac's might be the most
> > likely usage context.
> >
> > Right now, though, this is an i386 only feature...
> >
> > Warner
>
> --
> Bob Bishop
> r= b@gid.co.uk
>
>
>
>

--
Bob Bishop
rb@gid= .co.uk




--000000000000025bac05ed4c2584-- From nobody Mon Nov 14 16:34:25 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N9vzM62lPz4hVb7 for ; Mon, 14 Nov 2022 16:34:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N9vzL3rMsz49Fk for ; Mon, 14 Nov 2022 16:34:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=QioQuTnY; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::630) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x630.google.com with SMTP id n12so29657084eja.11 for ; Mon, 14 Nov 2022 08:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=WHea0hTik27DJsnD83yUN+XpRb1VgoBnbG8AQnO/MX0=; b=QioQuTnYTg9DBzBBr08KB2QWfFvm3d7X+MEjbQZEwqnc2Timyr6fLbgsH2frlrl8Sw 6QfOB8Sf4C4NexdCubgIfKSNxRO+XWY7fj9tP0ymrjUPREWhkl4tsp/gtVJbGEd6Ief5 oCZexkC6fETJYDB5GpkgvLBm0QCFegsnr33l7V4Vo0vVReQM/KmWEvfzEuaaj7WQxE55 t0YkDrGekQFve6QWZDaH7GNNoq5MTB2iq8Ko9FJ5ghPRjannxtsCR2J0il+mIufxzOPx vSyDBBcXt8DCbF0Gjoq/ZVysJ0LtQVLQIACPNgrpqgGMtOmmpnw4GXwDjW5SY53bthrb jqLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WHea0hTik27DJsnD83yUN+XpRb1VgoBnbG8AQnO/MX0=; b=V2pkMmit+f2tlPPRpv6jp0rlFjJRvBtM3nvMbBCi8QPm/9T8G6lwA7oekkREpCTgX9 pcKKbxlMMJY/NQ/MJio9IeJ5aEhvgtve4t+iHApZ6HsbBATAm2TuZRO+JxCEFABP5V4L wjKBS4TjWv05kzK9c5giss3UuiZ3+DJOWI7xUCYwEpD1iAOmVCadkZyIt+5WqdzyMbX6 lVOC9+Ko84TrwV/6bfMEQLfxmNRIZ6/iuMiDEjAOB7KV3fYfb0p2maHMpdfvGQ7ZUMy8 WK+UBdx1MTE0sWElGTFrPMKHizlGyUtovbtkLCYgKO2wJhkPMr8X+9Lf9qUyuU7S0iXX 68lg== X-Gm-Message-State: ANoB5pnjeL6R8pA75zXvGYLfyeS9p+4yBMwBqnFos2O8Q6yGdzw0ezQY l/weL3iE8fM+ZeQ1DA4GIMTqPQhxiW/DMYwl4qx7JAQSs5Y= X-Google-Smtp-Source: AA0mqf4XivDoL4RAUElyUXynsmBsWlwxja92kOvV+oyJDO94fh0nwBXYxEzYdYH1Llp+zFz5Y3tyehPMmP2KOVlAtM8= X-Received: by 2002:a17:907:a604:b0:799:9ace:e868 with SMTP id vt4-20020a170907a60400b007999acee868mr10461043ejc.451.1668443676574; Mon, 14 Nov 2022 08:34:36 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Mon, 14 Nov 2022 09:34:25 -0700 Message-ID: Subject: Boot Loader: OFW network booting support To: "freebsd-arch@freebsd.org" , FreeBSD PowerPC ML Content-Type: multipart/alternative; boundary="000000000000abb0cb05ed70d06c" X-Spamd-Result: default: False [-1.00 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4N9vzL3rMsz49Fk X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N --000000000000abb0cb05ed70d06c Content-Type: text/plain; charset="UTF-8" I'd like to drop support for OFW network booting. These days, the only OpenFirmware machines are really old Mac G4 and G5 machines. Nothing else can use it (it used to be shared with sparc64 machines). I'm in the process of reworking some of the disk code, which touches the OFW disk code which would force me to write extra code for OFW since it doesn't fit the pattern we have on other architectures very well. So, rather than do a lot of work I can barely test (I might have an old G4 mac in my dad's old thing), I'm thinking about dropping the support, especially since I don't think it's been used by anybody in a long time. Before I do that, though, I'd see if anyone is actively using it... Warner --000000000000abb0cb05ed70d06c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to drop support for OFW network booting.
=
These days, the only OpenFirmware machines are really old Ma= c G4 and G5 machines. Nothing=C2=A0else can use it (it used to be shared wi= th sparc64 machines).

I'm in the process of re= working some of the disk code, which touches the OFW disk code which would = force me to write extra code for OFW since it doesn't fit the pattern w= e have on other architectures=C2=A0very well.

So, = rather than do a lot of work I can barely test (I might have an old G4 mac = in my dad's old thing), I'm thinking about dropping the support, es= pecially since I don't think it's been used by anybody in a long ti= me.

Before I do that, though, I'd see if anyon= e is actively using it...

Warner
--000000000000abb0cb05ed70d06c-- From nobody Mon Nov 14 19:33:01 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N9zxR2SBqz4d8S9 for ; Mon, 14 Nov 2022 19:33:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N9zxQ62xYz3HVs for ; Mon, 14 Nov 2022 19:33:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id x102so3577233ede.0 for ; Mon, 14 Nov 2022 11:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=md9FEhDN/2dusCdcx9PqqIEfB4WgJP8JFkl1lT7Xnms=; b=V6tHWMpRvYFAzb1XNU/zxSUXKMyW/5A6dUgYxEwR/a1yqlWIIpBWiov5E8cVNyc2oy RPmij9obNJ/WoDmxrWQiU+rpnWHTpD3OWQk4GXVQcF9wBI7mF5VoSTti+SY2xMHU9IOF rMj16RXwmCelw6S2VRxWK1A/uLrS5jUsLQzVsuAe5U0S3BljEWbDiA/mB91Rm7GpX6jL Cd0ZNsI4Es6LdCztUyhFO4mK4lH5L+nChbMn0/0Xktx1sg22rUnn1pSw6krKBG6mr8ha i2u/pKMFJf3dgNLNiWBzwuOds8a0q2gBTFXAz6HBi3Mnu0HxPPwtJI+yQJ8N+PCmPo/o iI7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=md9FEhDN/2dusCdcx9PqqIEfB4WgJP8JFkl1lT7Xnms=; b=mYhVGnU7bLn/C9iEqdnCak9nnQMSffdc5DMJz4Q3rhmQ5pU/D/IEJ/eGR8nScL7wXJ z1KrbP5g6Kl/WKuGT7T/5UiSMLHApsKM1Ym7vRMZ54hffjSmoMG//x/pQUFWtzBMKBT6 vQo/M3MGBsjHXLjt89nAD2rFhB1zLiacWlJtVp6IjTtK4ABw+Giilw//31t+NCc7OvkW VlHRmzB54QCYlimEtjMNB9u11ErwEcaMGy9hokCidbDXBkDpom+hH+KppPKN8Cjiz8dp KAMHO88ECFPGxraFehXdOWig0eJ6rRy9N0mrKZcggqdTEn5P3nYVMkKCX2s2Xz7bFkSF w0tA== X-Gm-Message-State: ANoB5pmhQvr6Y9TyVDPeX3yhm3DBYR5YSYi+NGbAbvjJyE0AIO0pPY+C dzsPUkun3dk2fVso2zuQ4igu1X7WgRyN/ANrBgddWA== X-Google-Smtp-Source: AA0mqf7AHrMCp2mytstVp4E6UbusJytGjq92hXLicPqn/yiOGlSgLcETSwoc83tBBjWF+7EMK1r3hNZtQ1yDDJYTCZs= X-Received: by 2002:a50:fa87:0:b0:467:4a80:719b with SMTP id w7-20020a50fa87000000b004674a80719bmr12832497edr.174.1668454393227; Mon, 14 Nov 2022 11:33:13 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <5e072d6cb3bfebd24d48d2a9a851fc7a@bsdforge.com> In-Reply-To: <5e072d6cb3bfebd24d48d2a9a851fc7a@bsdforge.com> From: Warner Losh Date: Mon, 14 Nov 2022 12:33:01 -0700 Message-ID: Subject: Re: Boot Loader: OFW network booting support To: Chris Cc: "freebsd-arch@freebsd.org" , FreeBSD PowerPC ML Content-Type: multipart/alternative; boundary="0000000000006ec83205ed734f79" X-Rspamd-Queue-Id: 4N9zxQ62xYz3HVs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000006ec83205ed734f79 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 14, 2022, 12:29 PM Chris wrote: > On 2022-11-14 08:34, Warner Losh wrote: > > I'd like to drop support for OFW network booting. > > > > These days, the only OpenFirmware machines are really old Mac G4 and G5 > > machines. Nothing else can use it (it used to be shared with sparc64 > > machines). > > > > I'm in the process of reworking some of the disk code, which touches the > > OFW disk code which would force me to write extra code for OFW since it > > doesn't fit the pattern we have on other architectures very well. > > > > So, rather than do a lot of work I can barely test (I might have an old > G4 > > mac in my dad's old thing), I'm thinking about dropping the support, > > especially since I don't think it's been used by anybody in a long time. > > > > Before I do that, though, I'd see if anyone is actively using it... > I have a dual proc/800Mhz G4. But I would call it "hobby" class. Nothing > that should require me to need or you continue FreeBSD (current) support. > Ever net boot it? Warner > Thanks for asking. :-) > > > > Warner > --Chris --0000000000006ec83205ed734f79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Nov 14, 2022, 12:29 PM Chris <bsd-lists@bsdforge.com> wrote:
On 2022-11-14 08:34, Warner Losh wrote:
> I'd like to drop support for OFW network booting.
>
> These days, the only OpenFirmware machines are really old Mac G4 and G= 5
> machines. Nothing else can use it (it used to be shared with sparc64 > machines).
>
> I'm in the process of reworking some of the disk code, which touch= es the
> OFW disk code which would force me to write extra code for OFW since i= t
> doesn't fit the pattern we have on other architectures very well.<= br> >
> So, rather than do a lot of work I can barely test (I might have an ol= d G4
> mac in my dad's old thing), I'm thinking about dropping the su= pport,
> especially since I don't think it's been used by anybody in a = long time.
>
> Before I do that, though, I'd see if anyone is actively using it..= .
I have a dual proc/800Mhz G4. But I would call it "hobby" class. = Nothing
that should require me to need or you continue FreeBSD (current) support.

Ever net boot it?

Warner=C2=A0
Thanks for asking. :-)
>
> Warner
--Chris
--0000000000006ec83205ed734f79-- From nobody Mon Nov 14 19:55:58 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NB0Rp5ffCz4dC5h for ; Mon, 14 Nov 2022 19:56:06 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4NB0Rp2VVQz3Kqv for ; Mon, 14 Nov 2022 19:56:06 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 2AEJtwF6057023; Mon, 14 Nov 2022 19:55:59 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Boot Loader: OFW network booting support From: Bob Bishop In-Reply-To: Date: Mon, 14 Nov 2022 19:55:58 +0000 Cc: "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <02C7CADB-D8B3-41F3-90A1-074F9274B7DE@gid.co.uk> References: To: Warner Losh X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4NB0Rp2VVQz3Kqv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Hi, > On 14 Nov 2022, at 16:34, Warner Losh wrote: >=20 > I'd like to drop support for OFW network booting. >=20 > These days, the only OpenFirmware machines are really old Mac G4 and = G5 machines. Nothing else can use it (it used to be shared with sparc64 = machines). >=20 > I'm in the process of reworking some of the disk code, which touches = the OFW disk code which would force me to write extra code for OFW since = it doesn't fit the pattern we have on other architectures very well. >=20 > So, rather than do a lot of work I can barely test (I might have an = old G4 mac in my dad's old thing), I'm thinking about dropping the = support, especially since I don't think it's been used by anybody in a = long time. >=20 > Before I do that, though, I'd see if anyone is actively using it... Not using it, but it will not surprise you to learn that I have a G4 = Mac... > Warner -- Bob Bishop t: +44 (0)118 940 1243 rb@gid.co.uk m: +44 (0)783 626 4518 From nobody Tue Nov 15 01:30:11 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NB7sH5s3Sz4hPw4; Tue, 15 Nov 2022 01:30:11 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NB7sH5Qlpz43Wy; Tue, 15 Nov 2022 01:30:11 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668475811; 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=cgAxxRisR0INJYwa5/LIbgSFubV0nvV1/dpJIxk8ukE=; b=ekKpe+gp0iMZ5GuHtuo9dLJBZhHVodhKzpKTo3q98MU6O6PKKlE6mFNjQUX9a7rV/HEVmd pmQtXbOzRiwwBTLjNJwvQlCVBtGmJ/Y5bvdmOQHjibakYhfASX+iESYT8CtzxSiLRW8xNc D/BTxFRI7pnVWolL5OMXE7l8RMuD8LaPws4OT0BmYD/yDOB5YprT10IYCxS/BRNTdB34Ug oGnAqJpUWunkpNZKrBmNzYVdw6ydwjVuKuY5ALgeoM1IqJHA3b+Bdt2A8P1eM5dryidVNO V8Gtrbt9O+hr6stVEjFq1z+CrjlRf8g6d0y3rYQThacK2cO9O/eSgThw5PSI3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668475811; 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=cgAxxRisR0INJYwa5/LIbgSFubV0nvV1/dpJIxk8ukE=; b=ss1PMLR0UyQSx2DT/drZU7aQL0p12srtRJM3yUkcm3v75xy6jEwzH/GWW7A4dxqjpcGxz5 0YcIv59ye6iVej78YrCJe73i27t7ALzrZxzvOgwWwMHITbXoQ3CsL6cSGfvuC5M/0MMXZ/ rJZXnP7Xj5DuCJvinRg4Nw0AKiRQayCS+fviCCMePvkGp5K8dX41QSb+h5lNyOKNLhqYHi /UL2IInqXSyg9AamxX2NZ5n8YpdXNMQB9tp2wbiUMQ2Npcyy39myWck6/71wdRJebJcfNH uoXlvdqCpbbf7I5Csh72B+1sDt0u1TXl8wUnXmKRDCXZ1jKvZqc4zINcoLmG6A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668475811; a=rsa-sha256; cv=none; b=TDa3apPk1AtPazT37vnnCoTB9Ks6LblZtvlRbUfZesdEUtui6NtIezwsVrc2OI6lCiGsEL EM2CY/KttBD+1rbm9KyGPPjmyvBl9xtPo5Ey1mMLvO0x0l3jeJ/hz4+Wz+/9LpOfUCPJaW siR7DFNk97UztRMr6vgrxjcxYZ+u+a+rGKDI8ki2/XN3XQpb3RDGyb1YO699XMgcpnEOPC kHjhKjVQo7+qpu4jiY6ObzPc3lAuhJNY54nLjDEuigZsPb0edl2vzHGr2D31Eb5yaaC/iG oZXpPNmCtJdPeS20QoX/d6l3jqGfI9rxK0dj1LC+y+swhhd8wKlHRzrIIJQHuA== Received: by freefall.freebsd.org (Postfix, from userid 1033) id B09361C9F0; Tue, 15 Nov 2022 01:30:11 +0000 (UTC) Date: Tue, 15 Nov 2022 01:30:11 +0000 From: Alexey Dokuchaev To: Warner Losh Cc: "freebsd-arch@freebsd.org" , FreeBSD PowerPC ML Subject: Re: Boot Loader: OFW network booting support Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Mon, Nov 14, 2022 at 09:34:25AM -0700, Warner Losh wrote: > I'd like to drop support for OFW network booting. > > These days, the only OpenFirmware machines are really old Mac G4 and G5 > machines. Nothing else can use it (it used to be shared with sparc64 > machines). Which are still in use. Particularly, Mac mini G4 and Power Mac G5 make good backup/storage boxes and just nice piece of hardware to have around. > So, rather than do a lot of work I can barely test (I might have an old G4 > mac in my dad's old thing), I'm thinking about dropping the support, > especially since I don't think it's been used by anybody in a long time. Netbooting had always been preferred over to flashing optical media due to how easy it is to setup. This is the first option recommended by grehan@ in his guide* and that's how I installed FreeBSD on all my G4/G5 machines. My votes goes to keep it. ./danfe *) https://people.freebsd.org/~grehan/install.html From nobody Tue Nov 15 17:04:12 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBXbF5gVsz4hFsj for ; Tue, 15 Nov 2022 17:04:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBXbF3Ydqz3xqt for ; Tue, 15 Nov 2022 17:04:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id n12so37575125eja.11 for ; Tue, 15 Nov 2022 09:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1LGpoyz85bH4CbR6GFFz9ktsQ5yvJvM/d56upEGlHhE=; b=WIEjJKUXTr2j+dROzUoYbvu8t6rzx4/ScVEFkO3Ix+XoH675sqVqbuvEL6iBfpxJD2 YUtc222/bg6BMQnBR/HgFnZ8sRxGDq2aruDJ7biz4zpOxUAdjY6ZYKZO+NE7DSm44ie3 Ij/AA52z4pcr7WM3STmTqokdcJkCZXFQ1JHmchKoLmmfO10LrxWPMSyD+V8GVZRtDh/l DV2NPhi1APu51c+UjDNe1ny1vuNwn47IG1oRGcejzKQ8QiGMJ/JFzWO8hpB50flnKd0M 9Mo1GNqoXRaYqjIQZX9HdvMq7sKDaunWZGTMWho0k2sXzAIyaEyNubEoahUjpqRAncQa FSvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=1LGpoyz85bH4CbR6GFFz9ktsQ5yvJvM/d56upEGlHhE=; b=qii4DmaowSG/J5Oq3+HP7uzLPaeowPhIBjBcsf7HeMGLekunt1/Zu5jEBQJPjg721C IWww92flfDIzFpmhV/VXxWAYF86KHI+fWg8EisnRt2UCufwYp3trmoW5+vEkvsdhZFkX MCoVz5+VcXIWij4tPfw8hmegj7chVnJ99CPUSIjOP18BpTeRJZqoi9Yn+cmxBqo6QGc9 nhF6xh5mfbzr1FZyUaeIn8WyphqAkfSm1HLFx7vsEbca1aXCgu6bxwGrBOTsZOjCMsul /sBIpTDSraajUXwfeOcSPs1elFoDS9iUzzk9SEp0s92ol26hzdshjovu6Dr37WonD9Jy xDQQ== X-Gm-Message-State: ANoB5plNaZmbXh2J4xamvacuNiUFd0a+HpMd0ntPecN0mfUaetNNK8se 4KLCfvWUH0NjCrRL04/bcyRhdeUPPlXPRPagXxQyjA== X-Google-Smtp-Source: AA0mqf6AdEerTfq6sA/jvZKTnhWZfQJZQkUrWCrVTNwe+eiSE8WB8DCMsagMOpfIy5lIH87Xf+KmsDAaWVDFXhicgBU= X-Received: by 2002:a17:907:bc6:b0:7ae:1e53:95b2 with SMTP id ez6-20020a1709070bc600b007ae1e5395b2mr14165540ejc.333.1668531863361; Tue, 15 Nov 2022 09:04:23 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 15 Nov 2022 10:04:12 -0700 Message-ID: Subject: Re: Boot Loader: OFW network booting support To: Alexey Dokuchaev Cc: "freebsd-arch@freebsd.org" , FreeBSD PowerPC ML Content-Type: multipart/alternative; boundary="00000000000003303005ed8559c4" X-Rspamd-Queue-Id: 4NBXbF3Ydqz3xqt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000003303005ed8559c4 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 14, 2022, 6:30 PM Alexey Dokuchaev wrote: > On Mon, Nov 14, 2022 at 09:34:25AM -0700, Warner Losh wrote: > > I'd like to drop support for OFW network booting. > > > > These days, the only OpenFirmware machines are really old Mac G4 and G5 > > machines. Nothing else can use it (it used to be shared with sparc64 > > machines). > > Which are still in use. Particularly, Mac mini G4 and Power Mac G5 make > good backup/storage boxes and just nice piece of hardware to have around. > Ok. But surely not a lot of them anymore... > So, rather than do a lot of work I can barely test (I might have an old G4 > > mac in my dad's old thing), I'm thinking about dropping the support, > > especially since I don't think it's been used by anybody in a long time. > > Netbooting had always been preferred over to flashing optical media due > to how easy it is to setup. This is the first option recommended by > grehan@ > in his guide* and that's how I installed FreeBSD on all my G4/G5 machines. > > My votes goes to keep it. > You are asking for at least two hours of my time to code and test what i know i can. Likely 4 or 5 more if I have to setup and debug netbooting for an old g4 Mac tower I have (including time to find vga monitors, keyboards etc that I have, but are buried in my crawlspace). So here's the deal. If someone has the ability to test and shows that it's working today and promises to test my changes and help me debug it, then I'll keep it and add the new code that's needed to continue to support this feature. Alternatively, if someone has the recipe for FreeBSD/powerpc on QEMU that includes OpenFirmware for disks and networking, I'll do the testing and legwork to get my netboot setup locally. Otherwise, I'm going to save myself some time and this feature will be no more. I'm not going to speculatively waste time for something nobody can even be bothered to demonstrate still works :) Harsh, yes, I know, but better to be up-front about it and quietly break it which I'm pretty sure is what will happen if I don't test the new code. Warner ./danfe > > *) https://people.freebsd.org/~grehan/install.html > --00000000000003303005ed8559c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 14, 2022, 6:30 PM Alexey = Dokuchaev <danfe@= freebsd.org> wrote:
On Mon, = Nov 14, 2022 at 09:34:25AM -0700, Warner Losh wrote:
> I'd like to drop support for OFW network booting.
>
> These days, the only OpenFirmware machines are really old Mac G4 and G= 5
> machines. Nothing else can use it (it used to be shared with sparc64 > machines).

Which are still in use.=C2=A0 Particularly, Mac mini G4 and Power Mac G5 ma= ke
good backup/storage boxes and just nice piece of hardware to have around.

Ok= . But surely not a lot of them anymore...

=
> So, rather than do a lot of work I can barely test (I might have an ol= d G4
> mac in my dad's old thing), I'm thinking about dropping the su= pport,
> especially since I don't think it's been used by anybody in a = long time.

Netbooting had always been preferred over to flashing optical media due
to how easy it is to setup.=C2=A0 This is the first option recommended by g= rehan@
in his guide* and that's how I installed FreeBSD on all my G4/G5 machin= es.

My votes goes to keep it.
You are asking for at least two hours of my time t= o code and test what i know i can. Likely 4 or 5 more if I have to setup an= d debug netbooting for an old g4 Mac tower I have (including time to find v= ga monitors, keyboards etc that I have, but are buried in my crawlspace).

So here's the deal. I= f someone has the ability to test and shows that it's working today and= promises to test my changes and help me debug it, then I'll keep it an= d add the new code that's needed to continue to support this feature.

Alternatively, if someone= has the recipe=C2=A0for FreeBSD/powerpc on QEMU that includes OpenFirmware= for disks and networking, I'll do the testing and legwork to get my ne= tboot setup locally.

Otherwise, I'= ;m going to save myself some time and this feature will be no more. I'm= not going to speculatively waste time for something nobody can even be bot= hered to demonstrate still works :) Harsh, yes, I know, but better to be up= -front about it and quietly break it which I'm pretty sure is what will= happen if I don't test the new code.

--00000000000003303005ed8559c4-- From nobody Tue Nov 15 17:37:36 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBYKp5dqyz4hKPJ for ; Tue, 15 Nov 2022 17:37:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBYKn5nhHz43Vm for ; Tue, 15 Nov 2022 17:37:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=jT5+uixs; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::633) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x633.google.com with SMTP id k2so37901812ejr.2 for ; Tue, 15 Nov 2022 09:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IT/T+OzSRuG6oLX73iqAd8Hrn+UT/owsdaUOUTt8OIc=; b=jT5+uixsdgju+4kR+2Bq3wrbTPRCD27b0wEe2xhTxe32MwNqXz0h2QGMUUJtnlD4Sz 2XHlZYM20vjvAd0xnmqe9a7XxGiFRZA30YJ3J3jf8PFhW7+oapt/MHs8FYLKJeBJIj2a h7ZQIqHKPboV0bluNxM+ACvFCOUlcTcE/mQbFx+C33aFaB6W2XtWVrEkGSsmrgnBFQHy hhCY33ZvPbSmrtwtm8QgmrA476GIzZoAzhFHcLKvVf0Inj1cMoTmnV0zuuENA7vWvizL 53AJRtDeY/H8zAecQoEEypJ31oVD3w9veF+Iwse2DjiVJT5dpx5wDreQCiSs2zhV+zOp pYZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IT/T+OzSRuG6oLX73iqAd8Hrn+UT/owsdaUOUTt8OIc=; b=sGIY/EfjSRGaQlzvnTGVi45B+XfTfn4p/1legt/8k5tZKvvqTXZ7rI3Ukh8pS4gbK3 9D3xhU523UIYU7lsdgsDCXfx8k72rhNeiaQbcyCBht5+4SsPMEuLGn2lI7qEQQoURavz sUcdG8fUjuauBMbDYpPn8VAKp+4Anhlc6/aDwDcJhyQPY5BqcBLY5wWIENNHwwcUI7V/ aHP+RDSsIL4L6x/Hs0r3tBCYqNJ8pfFeKQy5wQluDn/S+ewoWZzZahifYrtcR0Z9YjJ1 XWYoiJ5J0xA1Y3VPoD3xkgKSdSODkOrMSlfLVpc7HqoDxpG+iquY5dvSKxm1giajOQd4 0iWg== X-Gm-Message-State: ANoB5pmDKWYzw+Tq+QmtUrjyE3eNusFucOfPy3x28d50oq7r7SAGPsG0 AmTFfgXGO1GHbi6RmKfv2zm6cv5IWBRb1pIEWFosSKBjdJs= X-Google-Smtp-Source: AA0mqf5I6WvRBcUZWphnCj0iSSKFbXOWvhByZ6uGYF7o+0aDYvBsKTKZGagyN+4quCbTM4yJ33EcMUI+LOHzRGbiw4Y= X-Received: by 2002:a17:907:6f06:b0:790:b74b:abf2 with SMTP id sy6-20020a1709076f0600b00790b74babf2mr14674217ejc.634.1668533867579; Tue, 15 Nov 2022 09:37:47 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Tue, 15 Nov 2022 10:37:36 -0700 Message-ID: Subject: Giant Locked drivers To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000079261e05ed85d014" X-Spamd-Result: default: False [-2.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NBYKn5nhHz43Vm X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N --00000000000079261e05ed85d014 Content-Type: text/plain; charset="UTF-8" Greetings, It's no secret fiant-locked drivers' days are numbered. We've been more sluggish about eliminating Giant than had been hoped. I plan in the coming weeks to add a tunable 'debug.giant_drivers' which initially will be set to enable/disable giant-locked drivers in the tree. When set to 0, you get today's behavior. If set to 1, it will no longer allow drivers that don't request MPSAFE interrupt handlers from registering (the interrupt setup will return an error). This will allow us to understand what is lost if we throw the switch, and allow users to proactively test their systems to see if they are affected or not (and if they are, if they want to live without the functionality, or want to fund work in the area). Comments? Warner --00000000000079261e05ed85d014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

It's no secret fiant-loc= ked drivers' days are numbered. We've been more sluggish about elim= inating Giant than had been hoped. I plan in the coming weeks to add a tuna= ble 'debug.giant_drivers' which initially will be set to enable/dis= able giant-locked drivers in the tree.

When s= et to 0, you get today's behavior. If set to 1, it will no longer allow= drivers that don't request MPSAFE interrupt handlers=C2=A0from registe= ring (the interrupt setup will return an error).

T= his will allow us to understand what is lost if we throw the switch, and al= low users to proactively=C2=A0test their systems to see if they are affecte= d=C2=A0or not (and if they are, if they want to live without the functional= ity, or want to fund work in the area).

Comments?<= /div>

Warner
--00000000000079261e05ed85d014-- From nobody Tue Nov 15 17:52:24 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBYfp2Z98z4hLtN for ; Tue, 15 Nov 2022 17:52:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBYfn6XM6z45Bd for ; Tue, 15 Nov 2022 17:52:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 2AFHqOvI066850 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 15 Nov 2022 09:52:24 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 2AFHqOiS066849; Tue, 15 Nov 2022 09:52:24 -0800 (PST) (envelope-from sgk) Date: Tue, 15 Nov 2022 09:52:24 -0800 From: Steve Kargl To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Giant Locked drivers Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4NBYfn6XM6z45Bd X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote: > > It's no secret fiant-locked drivers' days are numbered. We've been more > sluggish about eliminating Giant than had been hoped. I plan in the coming > weeks to add a tunable 'debug.giant_drivers' which initially will be set to > enable/disable giant-locked drivers in the tree. > > When set to 0, you get today's behavior. If set to 1, it will no longer > allow drivers that don't request MPSAFE interrupt handlers from registering > (the interrupt setup will return an error). > > This will allow us to understand what is lost if we throw the switch, and > allow users to proactively test their systems to see if they are > affected or not (and if they are, if they want to live without the > functionality, or want to fund work in the area). > > Comments? > Is there a list of effected drivers? Grepping /var/run/dmesg.boot on my system shows only "atkbd0: [GIANT-LOCKED]". A scan of atkbd(4) shows This driver is required for the console driver syscons(4) or vt(4). So, setting debug.giant_drivers=1 will brick all FreeBSD workstations? -- Steve From nobody Tue Nov 15 17:56:46 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBYlw4KJNz4hMPy for ; Tue, 15 Nov 2022 17:57:00 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBYlw2Cs6z45gr for ; Tue, 15 Nov 2022 17:57:00 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-f171.google.com with SMTP id 136so13964740pga.1 for ; Tue, 15 Nov 2022 09:57:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=LIkk0PBuHeQ3YTPpkaa5SLH8dtSyRAiIdzmiBmlWH3M=; b=AWhHrh+236WUsLMvKR87uXN1RXTkXFZEaI/QRq4w2JdOSMOWAlHdV2UKf2YYXaf1ug iFjevff0B4oas6BA6ucu2WGgaH58Sd1f7xtyO2ooJHOfewDW/MN5Dz1nP+mGDYEZbols z5gOI7XNr9Rk7LqDT2DVNL3tAQgxWX3PD+IZS8JxE7pCjXU744sl66RjSeuV3evMev2S DGy0ItusiI3ntDDEcbiX5lUs7Nl9FVHKPlGT+86Bc2dkzEw9co6sgHVF8jLDTHrHPxU/ vSMOZ7PG7e2aLkTtNj1xZXQfWqVI6ZXsxzccEbqivvmWUNW06oZqQ+7MMoR0gGAI1U3n ZkQQ== X-Gm-Message-State: ANoB5pnQInJgkipdsPlqdECsuoQ81UAXGq+yMOyYCcXCCaCkk25eEkQx KxhE8bMyBtjleUV5EdS/CJUVsiTwRTpy7cZ4cYc= X-Google-Smtp-Source: AA0mqf4WGmmNk7pCa8MEoWEMUXyPO+JD52RbPjs9EohmE6GSk3rY4Hx+PEpiq75c3vuVPbWLwqu4gmRw6ogSV8V7K7k= X-Received: by 2002:a63:ec03:0:b0:473:e2bb:7fc7 with SMTP id j3-20020a63ec03000000b00473e2bb7fc7mr16755602pgh.40.1668535018678; Tue, 15 Nov 2022 09:56:58 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 15 Nov 2022 12:56:46 -0500 Message-ID: Subject: Re: Giant Locked drivers To: Warner Losh Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4NBYlw2Cs6z45gr X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, 15 Nov 2022 at 12:37, Warner Losh wrote: > > Greetings, > > It's no secret Giant-locked drivers' days are numbered. We've been more s= luggish about eliminating Giant than had been hoped. I plan in the coming w= eeks to add a tunable 'debug.giant_drivers' which initially will be set to = enable/disable giant-locked drivers in the tree. > > When set to 0, you get today's behavior. If set to 1, it will no longer a= llow drivers that don't request MPSAFE interrupt handlers from registering = (the interrupt setup will return an error). I think having such a tunable is a good idea, but let's use positive-sense sysctls, so that we set the enable sysctl to 1 to allow Giant-locked drivers and to 0 to disable. From nobody Tue Nov 15 17:58:04 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBYnQ15ZPz4hMn7 for ; Tue, 15 Nov 2022 17:58:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBYnP69J4z45xP for ; Tue, 15 Nov 2022 17:58:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id u24so22955892edd.13 for ; Tue, 15 Nov 2022 09:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4d5vHEmehKHQywy87QrSFQaPj6nhf19UQuj2qx90tP8=; b=uuzjO/I+LzGwp5ra6sAGNKFdpTBlC9XcGUJs3r2cJRq/vMy8/gHi5hbghrebifjVDl x+UxR3UDVh/fcrVUOkojbZzCyAe81lMNjaNlacLk73pJ3yySTB/3X1RNGRl2hIIpckma 79a63Z7gABEaNWYvY26mwo8TBiAEmN29vqVxmRXVaVWJnfPPRIpI6XdXL3R3I8zvlmgN /7eA8aVumRkeBN71bJ5QqEXUUMJYBkBcE5yWAH2QWJcVCq6XkgcGPwdBcAbXBFZ5F8Hq 60YygJM8mnLbko5U9x2ivhUOKX8/2I7Dg7j5Pu5rN8kJCveZ7pLyT1MJsMItlB5RF/BD d8Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=4d5vHEmehKHQywy87QrSFQaPj6nhf19UQuj2qx90tP8=; b=y3ZAdMFzwzYNE2Kg+yxm3iamKaaCU2VIEmG9ylWxzzu6k3E164gNEMCKNLdoK4LZQB Pr7LYU1+6824jSZDuv4bKHjMc8n9RIwwLsjUbn2rDLAmhJz1Z0c0xc+yW3pBDjA6o8Ng 14uxkCbMhrXmTWuhyzwjq4yLrfJs92tvTjcz2LmtAqCIbJ1PNiBcl4wLI95DBYAHjCwv CziNiJ6oYnQuR7rf/rOBEQKzJh84x97CqBLE25AAT9pdk5sl12ROPyT9ziJvPYO2Yh83 eE7WGd+Qw/8N/dq5OBdTBjkI+ETaXk+aZlQe2zf9ggf6fT+308FVzDkR0ueY5rUgGxSX omsw== X-Gm-Message-State: ANoB5pkBguoyrHsaOBDUaz0ZqKri0M6J/LraAf3Wpe2v4XdQJA4qfxZz YGjQbcaML4igr2tfoV4nqyM9jfLgTPCYYFH2uhPDtgcDYR4= X-Google-Smtp-Source: AA0mqf6aQ8eIimKV6NRt5VxUQ+aUww7GhecREw4AdoQ+HnkZAZfInCT+BsZF6BrOdbk2lc1cFmL4vmpI8ewUW7zQNRw= X-Received: by 2002:aa7:de92:0:b0:467:8fb6:d11 with SMTP id j18-20020aa7de92000000b004678fb60d11mr12982617edv.421.1668535096168; Tue, 15 Nov 2022 09:58:16 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 15 Nov 2022 10:58:04 -0700 Message-ID: Subject: Re: Giant Locked drivers To: sgk@troutmask.apl.washington.edu Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000b442b905ed86198b" X-Rspamd-Queue-Id: 4NBYnP69J4z45xP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000b442b905ed86198b Content-Type: text/plain; charset="UTF-8" On Tue, Nov 15, 2022 at 10:52 AM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote: > > > > It's no secret fiant-locked drivers' days are numbered. We've been more > > sluggish about eliminating Giant than had been hoped. I plan in the > coming > > weeks to add a tunable 'debug.giant_drivers' which initially will be set > to > > enable/disable giant-locked drivers in the tree. > > > > When set to 0, you get today's behavior. If set to 1, it will no longer > > allow drivers that don't request MPSAFE interrupt handlers from > registering > > (the interrupt setup will return an error). > > > > This will allow us to understand what is lost if we throw the switch, and > > allow users to proactively test their systems to see if they are > > affected or not (and if they are, if they want to live without the > > functionality, or want to fund work in the area). > > > > Comments? > > > > Is there a list of effected drivers? Grepping /var/run/dmesg.boot > on my system shows only "atkbd0: [GIANT-LOCKED]". A scan of atkbd(4) > shows > > This driver is required for the console driver syscons(4) or vt(4). > > So, setting debug.giant_drivers=1 will brick all FreeBSD workstations? > You could still access them via serial port or the network. And I think USB-based systems would be fine. The comment you quoted is slightly overstated. And yes, the point is to show the pain and get people to get off their !$#^ and do something if they care. Warner --000000000000b442b905ed86198b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 15, 2022 at 10:52 AM Stev= e Kargl <sgk@troutma= sk.apl.washington.edu> wrote:
On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh = wrote:
>
> It's no secret fiant-locked drivers' days are numbered. We'= ;ve been more
> sluggish about eliminating Giant than had been hoped. I plan in the co= ming
> weeks to add a tunable 'debug.giant_drivers' which initially w= ill be set to
> enable/disable giant-locked drivers in the tree.
>
> When set to 0, you get today's behavior. If set to 1, it will no l= onger
> allow drivers that don't request MPSAFE interrupt handlers from re= gistering
> (the interrupt setup will return an error).
>
> This will allow us to understand what is lost if we throw the switch, = and
> allow users to proactively test their systems to see if they are
> affected or not (and if they are, if they want to live without the
> functionality, or want to fund work in the area).
>
> Comments?
>

Is there a list of effected drivers?=C2=A0 Grepping /var/run/dmesg.boot
on my system shows only "atkbd0: [GIANT-LOCKED]".=C2=A0 A scan of= atkbd(4)
shows

=C2=A0 =C2=A0This driver is required for the console driver syscons(4) or v= t(4).

So, setting debug.giant_drivers=3D1 will brick all FreeBSD workstations?

You could still access them via serial po= rt or the network.

And I think USB-based systems w= ould be fine. The comment you quoted is slightly overstated.

=
And yes, the point is to show the pain and get people to get off= their !$#^ and do something if they care.

Warner<= /div>
--000000000000b442b905ed86198b-- From nobody Tue Nov 15 18:41:04 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBZkz03yMz4hSTg for ; Tue, 15 Nov 2022 18:41:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBZky4PCnz4DYn for ; Tue, 15 Nov 2022 18:41:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id EA83289284; Tue, 15 Nov 2022 18:41:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 2AFIf5LA070673 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 15 Nov 2022 18:41:05 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 2AFIf464070672; Tue, 15 Nov 2022 18:41:04 GMT (envelope-from phk) Message-Id: <202211151841.2AFIf464070672@critter.freebsd.dk> To: sgk@troutmask.apl.washington.edu cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: Giant Locked drivers In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70670.1668537664.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2022 18:41:04 +0000 X-Rspamd-Queue-Id: 4NBZky4PCnz4DYn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N -------- Steve Kargl writes: > Is there a list of effected drivers? Grepping /var/run/dmesg.boot > on my system shows only "atkbd0: [GIANT-LOCKED]". A scan of atkbd(4) > shows > > This driver is required for the console driver syscons(4) or vt(4). > > So, setting debug.giant_drivers=3D1 will brick all FreeBSD workstations? critter phk> grep -i giant /var/run/dmesg.boot = atkbd0: [GIANT-LOCKED] psm0: [GIANT-LOCKED] WARNING: Device "psm" is Giant locked and may be deleted before FreeBS= D 14.0. critter phk> = -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Wed Nov 16 10:43:30 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NC05M1SZHz4hY1c for ; Wed, 16 Nov 2022 10:43:35 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NC05K2xhnz436l for ; Wed, 16 Nov 2022 10:43:33 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.de header.s=s31663417 header.b=p7NXHSng; spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.17.22 as permitted sender) smtp.mailfrom=garyj@gmx.de; dmarc=pass (policy=none) header.from=gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1668595411; bh=0kze4rvNWqeO813278Ot1BPK4SLd7sex00GxRdzSAFE=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References: Reply-To; b=p7NXHSng1sH2AOZ5lR6q58eS2iwg3UXg3aqFA1xrQEDB0LjNsPZmnXj3dmQvXziAn k0FtK3atWqUreQTSJTDkGho3KZEtCtuZGDb9N5beZtkOAa5F7jWeRBzhz9XxPokHKC 6EoGC228WuA8I6WRK3rLv+CB9V6e0mSz8xazToYShHNRAMHQl4gPqrVzo3PrLzgbBq durgmePgloyODKWI6t6bij3kFA0mzTTj6EbmAyOPY6rr+DtG7tHeqji8CsGt8ijdFP Ok3k4CfhEvmMkTTO+bR6i97OOsv9PyxTcIIv1BYJgAZgsYsWDPb9kp5AZnAQPY7m3n RW9pobUv5mx5w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.2.49.186]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MIwz4-1ogSpV0ECg-00KSek for ; Wed, 16 Nov 2022 11:43:31 +0100 Date: Wed, 16 Nov 2022 11:43:30 +0100 From: Gary Jennejohn To: "freebsd-arch@freebsd.org" Subject: Re: Giant Locked drivers Message-ID: <20221116114330.5407311a@ernst.home> In-Reply-To: References: Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:vKhg31PdOgyKEsEz22abdTson7jFSMzyuJSs9jxAMX1X6EeMqZh 346mdD5fmGC7DPrvrAuMXtK3Bt2g+aBWs6Wyl934LHiOkFdfVaq6EwU50KgwNCSaIMI3vBY NczjL5fUtvXv0LA/xumhocgbv4YYvY+8Ne/EbSYjkb04AIqlFlcLMpGFxTO1NQHSlaAekNf vvNQNrUbgpBcN0VWFRAuw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:bBGFd/1LuXQ=;1xtTpXUOoKzVDfJRSUWD9ZB8vIC nobnggPTEXocfPfARsZKrGLaZhxNbz2FHvCa0xuZP3HRZRv+Ukwn7H/LvONwVtYQekty4jCWL f6pHxhs0HqblSHO3fiuVOba/xak38o9V7cxn32q21oIr4mpRYryeCzR4eOr0Ru9NBELbW+63P eK7whpZrWAQzbZLsL1BUaENCPSfM6X/Rw1pAyHqRSuWSnGxhHgj6S4S+o063w7wdm+QhVAYo3 eOLVfTjsyNUzpHxk9U2x7K2bgRmFmidHev8Wh3WPiWhoogf23ZOQxkwPyTEFtqnqlFOjWjKKc elCxG0yz2YYwbJFfsSsP9sWh/ECEceLMvxuGU03ehJ2rsMqN+BeqNRu68vW+hueIU7Huu8Ldy c/DU7uS1jsTtwF57n5rCY/nceggPr7CIeNwVJnn3sxIC8QEinNYefK1bMw7LEPGAcL4+mdHmT hsKqJy5m39RXrJwRxemFF0KY6FSvHshQJtVtpiammpOmKYQxx05EATYD5Me6wMo5GTNnpP4Lp JGSZ5kGRFXL61ao1a7vaT5tNeNu/1jXbAgN31TXm06FbuYwy6+ulF0ZggB2p5KzyIwvr8aT7T 2OyuMf3m0L6nPElyUBFsrEbP2MLHU+ltLabkthdr4Myo4nlV+vJJdI3ekMrY8p7gBiKQFe6Yo ALu6Rp2gwl2rx+t46KbvObUGEG8sQv3kgJFUxhYUpSVdLkhhYBwMqNzII1FB0mK4XsR4Jc5aw O80AbRuTtd3flmSFwy10gLvsRevEWANBquLaqbpIRW1T/tSz10WuQE9D6xETdn5//sKVOhnOA T4fUKg/r681i0n2dp11ceQzxkITSzSllkYPrQJdfHWFf+zZ9/MVnDJw6t/yF09Nuu8AmJRzD0 XxQKXU65h3anDVnVLMzwnlEduQjivppLAYmjcQKPLwETtO5x0HAX73YwB1pL7M9//hgwDcnJ+ pl2Bww== X-Spamd-Result: default: False [-2.45 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.65)[0.653]; DMARC_POLICY_ALLOW(-0.50)[gmx.de,none]; R_DKIM_ALLOW(-0.20)[gmx.de:s=s31663417]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.22:from]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_ALL(0.00)[]; FREEMAIL_REPLYTO(0.00)[gmx.de]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.22:from]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[garyj@gmx.de]; ARC_NA(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmx.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmx.de:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; FREEMAIL_ENVFROM(0.00)[gmx.de]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4NC05K2xhnz436l X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Tue, 15 Nov 2022 10:58:04 -0700 Warner Losh wrote: > On Tue, Nov 15, 2022 at 10:52 AM Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > > > On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote: > [...] > [...] > [...] > [...] > [...] > [...] > [...] > > > > Is there a list of effected drivers? Grepping /var/run/dmesg.boot > > on my system shows only "atkbd0: [GIANT-LOCKED]". A scan of atkbd(4) > > shows > > > > This driver is required for the console driver syscons(4) or vt(4). > > > > So, setting debug.giant_drivers=3D1 will brick all FreeBSD workstation= s? > > > > You could still access them via serial port or the network. > > And I think USB-based systems would be fine. The comment you quoted is > slightly overstated. > > And yes, the point is to show the pain and get people to get off their != $#^ > and do something if they care. > I use a USB keyboard and a USB mouse. On my machine I see: grep -i giant /var/run/dmesg.boot WARNING: Device "consolectl" is Giant locked and may be deleted before FreeBSD 14.0. /dev/consolectl is used by both syscons and vt. Exactly what consolectl is used for I can't say, since there's no man page. =2D- Gary Jennejohn From nobody Wed Nov 16 13:44:41 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NC46b0fjjz4XKRD for ; Wed, 16 Nov 2022 13:44:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NC46Z5Qv2z4Rkv for ; Wed, 16 Nov 2022 13:44:54 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-f178.google.com with SMTP id h193so16663581pgc.10 for ; Wed, 16 Nov 2022 05:44:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=tHjRJLiEPUzYvdiuvkXlnM65GFS48ojngAGUO2tfHAA=; b=oMZlR2vJ+2H1nFIn27Qn9r0Sf/yEKKT1Lm2IItjYk7ntKraUqV5g/rBRly9sT4mmQ9 yykdDT/VDbZFoczLmJAZXCZCXxGm89V4inVUM4yJbnJMpgytzv5rEhGAsvOmdutiuDiZ A7cXPUEnJ/o8arlUMwVmKeS5g14hJd9Kbqnh0LxbNSfrUTdEVMTjCvsny/8jdACXJOkq u3u4sQA5+5e02Um25SAagY31j8z4JgwypzEBOpOl7qvF/cpfmVKXhDb/QpvDXuV/1QaL kxGNp/5amk5saAf7EWZIDqs2Gw1JmhudsyeELqGif3yTiI/9iLaZkS/3+NiLpFOF2Paq i8hw== X-Gm-Message-State: ANoB5pmU9kFV4uUXjpyEIOF2/u2V1hgEpA/BeOHA7i+Kv4kko8qh+B6c sRhPrPrMB6vljTNyB1MCvyBy3QQwRpgV8jQ217wvGJNHd1U= X-Google-Smtp-Source: AA0mqf7OzBiQP2w+r4fM2C7mWnub+B6+nJGQbt5XaT4rX/XMWMCvT7i4NKiKwVjaCChgMXQTRR6Fstb5yK8RMu8vzcQ= X-Received: by 2002:a63:c116:0:b0:46a:e818:b622 with SMTP id w22-20020a63c116000000b0046ae818b622mr20334107pgf.550.1668606293308; Wed, 16 Nov 2022 05:44:53 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20221116114330.5407311a@ernst.home> In-Reply-To: <20221116114330.5407311a@ernst.home> From: Ed Maste Date: Wed, 16 Nov 2022 08:44:41 -0500 Message-ID: Subject: Re: Giant Locked drivers To: garyj@gmx.de Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4NC46Z5Qv2z4Rkv X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, 16 Nov 2022 at 05:43, Gary Jennejohn wrote: > > grep -i giant /var/run/dmesg.boot > WARNING: Device "consolectl" is Giant locked and may be deleted before > FreeBSD 14.0. For vt consolectl is implemented in sys/dev/vt/vt_consolectl.c. It implements two ioctls: CONS_GETVERS (which returns a constant version number) and CONS_MOUSECTL (for mouse events, from e.g. moused). What FreeBSD version are you running? NYC*BUG's dmesgd turns up consolectl Giant warnings only for 12.x and 13.0. From nobody Wed Nov 16 14:20:22 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NC4vY1gDGz4d7Vg for ; Wed, 16 Nov 2022 14:20:25 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NC4vX4CFzz4Tdw; Wed, 16 Nov 2022 14:20:24 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1668608422; bh=rZ25EAn0akc43tKv0LJaXGTTzBCs2mwyVPhnDh4tCfM=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References: Reply-To; b=BMtpXlivJqFx2doHfec5GrqW7L/Li6no+m8dW6h9wiB8CNTbqP46NOIsSAZu/r6eL 0czrT8kMrJZOcwFqRVhVOhh1waaWxDa5AvmD+32UVZJ7aVK29DAEYY/VZUKTCMgQod 4T5JCuFLODWQailS7MyhggOHLZz/DSQrrSePJztCUd7qZH6GBJGsDckvS0Lar1vMVA 2a0sTSDxrCbRNnCiQTOrZSEVYEgAGUQq5TSjCF054dw+tT6VRoI4MbYpSzgbfdAe7G 1mb//CUAIVifdU9pWDv1lA3hQRGu0PvFKf/Ay2gCs2TIifjHENrfCmcBMyxPqkPZ3X Rmt8CTQhHOI6g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.2.49.186]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MTABZ-1oWkP32shz-00UcSd; Wed, 16 Nov 2022 15:20:22 +0100 Date: Wed, 16 Nov 2022 15:20:22 +0100 From: Gary Jennejohn To: Ed Maste Cc: "freebsd-arch@freebsd.org" Subject: Re: Giant Locked drivers Message-ID: <20221116152022.5f3441c9@ernst.home> In-Reply-To: References: <20221116114330.5407311a@ernst.home> Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:aRjhF6UBx3FHFzUigdsmNB2xIqraRMApYPJe1wP/+YCqfokhWm4 4fkj0YUGpRcwxxPAzADD2JnWzuEJ/97/O6NdHh+SxZFdscsCHLHWahkjrXLs7SRQ85n06k/ FjW2wA/xlR7bmZkf0xSSU+i3BcRtdupwngNNPryWfpg8kMa3bwzO61N0q5X7S8WA6LCH+nw owCoJGYXMWtP+tRRS58BQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:pe1oPW4rqEc=;nbs0aqL01cBMOu9Ypu33F+IeK81 8yAnfoM7Z15TvBGJYaRpI66kgZhdPMFQeF4XZPLoyKgk5SBZHHGFRou9gfNvkn0WOuuYzewUQ Hh/UdVy8gPV+dYC+/3Qoh003HF5JTE6mhvO0yORb6BRVamGITrZm9BWY6+fvsam28WHzQuq2q gpb6mj4hs7SB19ujewa7dTu6ZNtTKlpoZJ9icGKXelJyM/pGwyAhMbiyGLR68BU+WMKAU8gCp rJFxUl1Z7/d+REylnErsL9BNHnwtQIggXzJYt7eippOF+S4vs+VOkoqozkJIDvgLgOM0L/fT5 RmBku/7g9VM9C2Fz+61vwBSjYFpQEe3N9txrv503lg5AZ7zlHJNs36wlJLGvdhBd7QqAk9LlF d3LKuZ2VXJ+5hK06oVzMLsPZsHjU3A9GVZg4MN9EcZYPKABxGBtK3qmxvRWFUITgzUEdLJsqp 5Uf4kvBk34p4BLPbFjtpWjh6Txp4TfCKanSil6Od+8VFIHyXsb+DRGGwX4Qa6K3Mxg3sexYR0 cFQ9x8dCZdRgTxZ1uCaMGRZZOVrJBvb3VuJ/wljqupAA+66pEOeOTBXfvFjSdGexRCTJe4G4z afXPqJFvfJtPff/F+7LRM87githUOzAKARxhYCUFay4vSEcbBCHCOA7HcOmnEmcuW/SgA+OQ3 6KxJczB5JR5HU70RBrcg41j68t82QI66JfHrmO4JGQSgorYzlNK6ECRg3LonuUvWFm1Dg3oSp wbVXcbd/pVLuT3ET9P9SkRyDpf2MEq2Andtz2BjJrJ9omS3Y6b6uLGNOCQQjvJqQnLISQ8y5/ d0i5FfXlAogKS1vu/8afnYKe4/yXQWR8lUd2mdgc8Yh6fXr7cgd3/V7PCUxq5+C8bKtkXZLke Em2fg5apxClMxWPjxMtp50ketNaLLf1LAwJVcFkzrRkR5uA75+MfIT0bAKrscMJfAtbah1RfY v9Sl2g== X-Rspamd-Queue-Id: 4NC4vX4CFzz4Tdw X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, 16 Nov 2022 08:44:41 -0500 Ed Maste wrote: > On Wed, 16 Nov 2022 at 05:43, Gary Jennejohn wrote: > > > > grep -i giant /var/run/dmesg.boot > > WARNING: Device "consolectl" is Giant locked and may be deleted before > > FreeBSD 14.0. > > For vt consolectl is implemented in sys/dev/vt/vt_consolectl.c. It > implements two ioctls: CONS_GETVERS (which returns a constant version > number) and CONS_MOUSECTL (for mouse events, from e.g. moused). What > FreeBSD version are you running? NYC*BUG's dmesgd turns up consolectl > Giant warnings only for 12.x and 13.0. current from today. I switched from syscons to vt today but I'm still seeing that warning. I suspect some really old file under /etc/rc.d since I hardly ever update that stuff. My system boots just fine using what's already under /etc and "never change a running system" is my philosophy. BTW I had to make a change to /usr/ports/x11/nvidia-driver because it tries to get the softc for syscons, which is not present when only vt is in the kernel config file. =2D- Gary Jennejohn From nobody Fri Nov 18 00:15:56 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NCy4b0W2Vz4hbj2 for ; Fri, 18 Nov 2022 00:16:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NCy4Y345Bz3k0c for ; Fri, 18 Nov 2022 00:16:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="ZaQ0u/oV"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668730571; bh=y/hzS3GoNgDfcWGJfmmvrrA0PlWiXsouxVc0Qd6Z1qw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ZaQ0u/oVOvj13LyxliM3IWxbswSE+xRlx+6iBK6XZvAcRs5eQIcaJyWlpXZl0+qscNJJ2ZUArYbxizKAMuaGkS3dXhAKd1pnvVn1//GihqJ578NAEUzeMBUyFVvJJx73neSB0XTo9xKzwlihlv8bQ/5FZmn0d4Emu3zTVZG/2jKP8HdqjRigHAjAdaG1bm8VMGEcLUNNAizt83Q35netFYXj0rlycMn6+E0sgmtPcBSNlLBM+l3s+j27V41qDpgAs21fgmJI0v4T4NjT89rwbsQM50HQsFL/S7Kqn8REaUUH7RYnL2C/MuHnShbROHTaxWLKhuH5H+eepSoOt1ysDQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668730571; bh=N5Odu+XhxD/JckmEeCIjrCQadzNQwhqdNfvJJlQjoQ8=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=MrJHUmh/x0Q0StT7zAnR6Mex/erUzeaMD0QPXcmA8LNqcqL/uXg7af5YcnPauifReI2pDHMzbUtI2ox6IAlLyrAnWUir93FIrZlFmRBJiMurueH7WRicgwN19HJt264vdZ9i3044bAcl/s1DILc7iivRxvkjJTh2pT4e4tqh7fVNtYWP8a10wJuqpGpL0X3Ygu9Lutuz/3nnfhqyZkVcyLpTke/0nJjNjbUqsfy+WVST6DSnQxJ3Rd0UnRoOAivja0WnQ3ADSqyG22EoNbu/WUb0G6kbJecNBm+HAkunxx3teLxLq67dHCEqL3cmaCjWJ5ERkjcJcrY37ewnZm4q7g== X-YMail-OSG: dOLnFKIVM1nnDm7PTdlja2Ml8V79gPpA.vNIPtRrTfpcCQZF_mtfjdpCv9cXEda KdirAzbEiMjAdBfMB7dl.VysN.hr2FnprTfeNbiPxIgv0gj.LN9MC0qGXOoLMHloqJVrWNgjlcvr F21LmcN9WLg6OWPLLDBbabiSdI1N3dvX1TDX4iljII39FryZfH3dRUihwC341zQdDKTo60u9NnVg NeXl57pReEiN4qNoAx7XtwjkTgO.2bbavTpXVazkgCImqcTfjdoFE0jlxueemleGmK8KftMw8P7_ .zv2pEiR2NdppjHJFXhVY.IwF8lLlDXrB96vgcx30FZJLfg8pPaCmukts8b6UKdXkWweeE4Zpy02 ZpUYQ76QHL1v7LrJ4BOHM89z7ouSwv00BQUoDjB50uEQBJkfnpcmbtf6J2T5SspOTRBrgRmOfosm Md3T5aTiuCj6zUBOZG0LYqqNaH8SOSG41kHEmPiEIQgF3dCjhqefH6Rx5RTNUW8xgRbvLdlLm61L g4YQxbFKVcC2GhcOn9iHr0_Gj_YPDjoJiWWk0pkVkbm.JUI7qO.TJ85GDzw.T.v7ip0cB9oJEXE_ DFeK.7.lBtcwgDlXhsyDD64073dUck1Bnx4xtcAf6pu82j65d77qJkHucNBe4DuAXuZWHkhcrqid Gczs3BTbWUBftTJppRv440mI2Iwfv8_LsCT_0nw4g38fKoQPVOsAxe_mG83U965MrsN.YlWT21Td j4f3ddUSyEcBtnwNhwnIn_09qqIf5__JOh1NBWpJEQjm_AH6D4Dwq3OpT21VfW7UvH_Wm3Z0kVwr rUTnG0BF3AWTkcfdE4ouz5.3X8OWlLIYN7Wm9wZyHvARupPEKp460e1F8ILOG.fmNhCdB1J74_FF qPujo7GJV2Q0CfcuQHbGqTVhOf2JSnHEo2RWgp1ADiW9NrGqeKqFoE4ZPmk2_BeANxGSq_g_xRfH HheSK6HB1IjEiA7w8aYz5kbUO816ZPolVxKDst5GqbYq6YTHSC1KIoa_rpIPsMrChGkphVTvijke vjgj.XkykyCZZIeZ2X5gaAsc3hRhGOVT1A36b1umkZQzM2GDZt9iC03guvjvBlXqlH6XuxVrmiPr grf.McXv40Q.T6VyBszmW1c.wf9dGYtbuUXb2D1LDbhZKKZ6F_DhZGZgPplqNn5l1JiBA9hWkcWi fKUqHW385lcV6FzFoEHgQ8IwJo6ymVQonGqsGeFSiORzGgaLXmRYJQU1Guwi1XTIhM6J4jj12e2q Cfeg2UeUYIQ_3Y5.oRwCTwSeit3dpf9PbYeaFo5vWf96m.edHCfo1nCQYZfUWYKAzGtzDEDSZEvr jBbUoJOojReTWyieCIxYwqieVjpQXe4AEFW2OovNc0WZDsQ24aZcLknuab74ARuey9xr_HxdZhXs Uop4MWTGVb8XuOEGUZZf9HrKi0jBXgeUFPAODPi9FAC_jx9wblfnXd.j9KQxQCv7ormVMrppBkKc eru1VUR.tHzKKJHDNZ0_X2j2iGIdcXZNWWN3sdfwUG5pgT2.zcfAcrarKgcPePzwet2YNTU2.hSn TCI8KUkKCMwSy7Y4PGJSTDrgAun3SrOewXJhg1HBzizCzbKoPpuyumZi9gZCgoIiPTdbsOTEDwMY il7xuOrP8976pt6OeS5Q8KxUdm3H45pHnidLVlprxWaXSoEsPP61j7oV5ev7NqA5PAw4Lc7HpiWM 8LfQ9NXzmyw4v9vUfj7jmm3eleriuEZhjGKtCFKcEEiFleUcovniZxHXOe3awxs4IYhFfxQNe5.o PQt4oZw6Jlsc6TgYHn4x5Ln7mBtOuYc5niwDYpwN4SmgQwDn6SGOASEIleYJgbf4MxxsnUz0z2Fv Ofg530Vu05FVS4ZWxlMVYxf4WGd5MaOwpWOhSam53GUUTShXKbg1KBp0SLDTTj5VPWzqeIho57Dm ie1kU0a_oLzyoG35jw2g0.HTObWCTuCkvrsTKzFN24mcxuq3hTGz0tuwx6jeeATel5ZCk8bxRoU7 VGS.qwi9xF6aAHzF0ULvd.4Yyct8hsNNA8zhUNsJU6AzX7pC64cm9b9YC.4zes5YZFJwkNiFO9dG .RbHikFRvunbZv_99qIAe6EkwOPeAhrj6c645bXqpU0KLH4q3DPY3vxS4QOiruEXjqYt2BSu._8e dxOZt27_mzy2jt518MH1xx7sjuvVFU70K.4uvwaFB5vMUzXEH9AaEbaNiARD4FGDbygIVWY_lHtt zYLdwkFUmWaclGs_HCJMc8PS3TjFURcnSEquQHPYBaGtO_5MDokGwSeeOdrpyJ2dJymK5espljM5 UWw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 18 Nov 2022 00:16:11 +0000 Received: by hermes--production-ne1-6bcfb7fb87-sgghd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4d707983992ba1a557b50d569c4a287c; Fri, 18 Nov 2022 00:16:08 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: RE: Giant Locked drivers Message-Id: <0663EE5E-0311-4D26-BEEE-A75053332A56@yahoo.com> Date: Thu, 17 Nov 2022 16:15:56 -0800 To: Warner Losh , freebsd-arch X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <0663EE5E-0311-4D26-BEEE-A75053332A56.ref@yahoo.com> X-Spamd-Result: default: False [-3.41 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.909]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from] X-Rspamd-Queue-Id: 4NCy4Y345Bz3k0c X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote on Date: Tue, 15 Nov 2022 17:37:36 UTC : > It's no secret fiant-locked drivers' days are numbered. We've been = more > sluggish about eliminating Giant than had been hoped. I plan in the = coming > weeks to add a tunable 'debug.giant_drivers' which initially will be = set to > enable/disable giant-locked drivers in the tree. >=20 > When set to 0, you get today's behavior. If set to 1, it will no = longer > allow drivers that don't request MPSAFE interrupt handlers from = registering > (the interrupt setup will return an error). >=20 > This will allow us to understand what is lost if we throw the switch, = and > allow users to proactively test their systems to see if they are > affected or not (and if they are, if they want to live without the > functionality, or want to fund work in the area). I'll just list where I see giant referenced in var/log/messages in recent times. Summary: I only see 2 types in my rather limited type of contexts: atkbd0 and fb. ThreadRipper 1950X system: # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #55 = main-n259064-f83db6441a2f-dirty: Sun Nov 6 16:31:55 PST 2022 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400073 1400073 # grep -i giant /var/log/messages Nov 6 20:11:56 amd64_ZFS kernel: atkbd0: [GIANT-LOCKED] Nov 13 15:08:15 amd64_ZFS kernel: atkbd0: [GIANT-LOCKED] The system does have video hardware present and in use. (The only system where this is normal in my FreeBSD contexts.) Does have: PS/2 keyboard and USB mouse present. RPi4B 8 GiByte system (booted as aarch64): (HDMI, USB kyboard, USB mouse present for test. None normally used.) (I'll not explicitly test 4 GiByte, RPi3B, or RPi2B v1.2 .) # uname -apKU FreeBSD RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #49 = main-n259064-f83db6441a2f-dirty: Tue Nov 15 13:39:35 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400073 1400073 # grep -i giant /var/log/messages . . . Nov 17 14:57:25 RPi_4_3_2v1p2 kernel: WARNING: Device "fb" is Giant = locked and may be deleted before FreeBSD 14.0. (Seeing such requires having a HDMI cable to a powered monitor in place --something I do not normally have.) RPi2B v1.1 (armv7): (HDMI, USB kyboard, USB mouse present for test. None normally used.) # uname -apKU FreeBSD OPiP2E_RPI2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT #51 = main-n259064-f83db6441a2f-dirty: Sun Nov 6 23:47:56 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a= rmv7/sys/GENERIC-NODBG-CA7 arm armv7 1400073 1400073 # grep -i giant /var/log/messages . . . Nov 17 15:37:09 OPiP2E_RPI2v1p1 kernel: WARNING: Device "fb" is Giant = locked and may be deleted before FreeBSD 14.0. I did not get any examples of giant in /var/log/messages for: (HDMI, USB kyboard, USB mouse present for test. None normally = used.) Rock64 (aarch64) Orange Pi+ 2ed (armv7) That looks to possibly be just lack of HDMI support in FreeBSD. For example, through U-Boot the Orange Pi+ 2ed did show output via HDMI but no more was added after U-Boot was done. The following had no video hardware present, no keyboard, and no mouse --and also had no references to giant in /var/log/messages : HoneyComb (aarch64) MACCHIATObin Double Shot (aarch64) I no longer have access to any powerpc* systems. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 18 12:30:56 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NDGNT3yhxz4hF1b for ; Fri, 18 Nov 2022 12:31:05 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4NDGNS4hnTz3hFP for ; Fri, 18 Nov 2022 12:31:04 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk; dmarc=none Received: from smtpclient.apple ([194.32.164.25]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 2AICUuOq048965; Fri, 18 Nov 2022 12:30:56 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Dropping firewire support from boot loader From: rb@gid.co.uk In-Reply-To: Date: Fri, 18 Nov 2022 12:30:56 +0000 Cc: freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <8FAA2C39-3394-49A8-865D-CF580A3EB52C@gid.co.uk> References: <5E84C24A-E90F-4EE2-B054-EEDCC23DD6E6@gid.co.uk> To: Warner Losh X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[gid.co.uk]; FROM_NO_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4NDGNS4hnTz3hFP X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N Hi, It doesn=E2=80=99t seem to work. Building with LOADER_FIREWIRE_SUPPORT = doesn=E2=80=99t actually get libfirewire.a built but adding the subdir = to the list fixes that. The resulting loader booted from a USB stick goes BTX Halted straight = away. > On 12 Nov 2022, at 20:49, Warner Losh wrote: >=20 >=20 >=20 > On Sat, Nov 12, 2022, 1:25 PM Bob Bishop wrote: > Hi, >=20 > Well, the kernel support =E2=80=98just works=E2=80=99 so installing on = to a firewire disk is straightforward; just load up firewire.ko and = sbp.ko, and the disk comes up through CAM. >=20 > However, I couldn=E2=80=99t get the loader to see the disk; I don=E2=80=99= t think this build of the loader includes the firewire bits. Not helped = on my hardware because the BIOS doesn=E2=80=99t have firewire disk boot = support. >=20 > Firmware isn't built by default. You need a special build for that... = what is loading /boot/loader? Not sure you could boot the system with it = if the bios doesn't support it (except by having a tiny disk that the = BIOS understands and using that to boot off the fireworks root). >=20 > Warner=20 >=20 > Warner=20 >=20 > > On 10 Nov 2022, at 21:53, Warner Losh wrote: > >=20 > > I've created a diff: https://reviews.freebsd.org/D37334 > >=20 > > Warner > >=20 > > On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop wrote: > > Hi, > >=20 > > > On 9 Nov 2022, at 23:55, Warner Losh wrote: > > >=20 > > >=20 > > >=20 > > > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard = wrote: > > > Warner Losh wrote on > > > Date: Wed, 09 Nov 2022 20:01:41 UTC : > > >=20 > > > > I'd like to drop firewire support from the boot loader. It's not = been used > > > > in quite some time, as far as I can tell. Nor have I (or anybody = else) > > > > tested it in forever. > > > >=20 > > > > Is anybody still using it? Does anybody know if it works? Any = objections to > > > > removing it from FreeBSD 14? > >=20 > > I think I still have hardware that will do this. I can check it out = if anyone cares...=20 > >=20 > > > I would suggest that old PowerMac's might be the most > > > likely usage context. > > >=20 > > > Right now, though, this is an i386 only feature... > > >=20 > > > Warner > >=20 > > -- > > Bob Bishop > > rb@gid.co.uk > >=20 > >=20 > >=20 > >=20 >=20 > -- > Bob Bishop > rb@gid.co.uk >=20 >=20 >=20 >=20 -- Bob Bishop t: +44 (0)118 940 1243 rb@gid.co.uk m: +44 (0)783 626 4518 From nobody Fri Nov 18 17:32:58 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NDP580hq8z4hy9b for ; Fri, 18 Nov 2022 17:33:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NDP575qS1z4873 for ; Fri, 18 Nov 2022 17:33:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62f.google.com with SMTP id f18so14753247ejz.5 for ; Fri, 18 Nov 2022 09:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PJdIdl384Lcwh/i21wS80A9PiXVOP4uzk8zkU+aLZCE=; b=IvPvXz7K3wpjbFO+5lX+aHDvUrzVoGpJn8S7Ahk6uLpYjpVc/Ub5odEFY9X86A05m0 yfyU492nDOqLie38fWva9bawYA9BWOLUh0ig6zSDor2XYnfyqZNKbPWQWI7GnQuQPMWQ io56yAiKW7J6jRLJaAJCvNmxmElj7h7sVHqYIAddj/A9SGJL0WBImSv0nV+jTn3wQXVm rnQYH3c7nPsyxA9dzIgwqOzBGOBd6qZ7S4HGoeZPyyYtqptGSOiUZazQ+u9zNvS4+tgH wnbMkNhrFQkglAdcIOfYahhERESa1ql444Ema3clDCJFD0yHf+m7ommdpecl1vgTrNch 31fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=PJdIdl384Lcwh/i21wS80A9PiXVOP4uzk8zkU+aLZCE=; b=iCc2W5hXkkoGc12Cur3tH35FIoaj4cY67I1FSX9rGVb6Oonp5IihjsQqBhAMqHnYdW CDDJ445ewEvbydGj9BFNUWBKa0rHvXUs57AjFww2fiEeHshkxz6YpQTwmco9xrlw5q4b vIWY9/Xl2KNEBU/EbAgOkZPZ0Bb3u68fwiImBweQlOBcUNxk3pyRRTFKgOZLu/rQi8gI f6xpJQhsx2zR027T5byhsoLBqBRnDUaI9NcnvWU22LwWtEbgyVaUohtXeAJrgZgQtwRN Fs4hCox/GOZt9MpFL2f4IN+ijM9Np68P6WEgP3iGdfb8JJQTkTxkjvTsF+otgpSgU/nL nRcA== X-Gm-Message-State: ANoB5pmg8okYrTvWGoiccF8EJT+MiuBucB0BwZYriuvdrZ2Md95Jpjjq WkuzGPfwUuJ5XN17NA1YKYQjsaxTYJKCBnN0Gl+Tl59lGFs= X-Google-Smtp-Source: AA0mqf6S1iv/H/wYhsjRp2vsmfClHD3kW8fzQOWPIWCV5Qrn32VC/3VJG5Nyp5dKldujHRKVWR7KJz5ZcZ3466JFsWI= X-Received: by 2002:a17:906:cc9b:b0:799:9ace:e868 with SMTP id oq27-20020a170906cc9b00b007999acee868mr6617280ejb.451.1668792789426; Fri, 18 Nov 2022 09:33:09 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <5E84C24A-E90F-4EE2-B054-EEDCC23DD6E6@gid.co.uk> <8FAA2C39-3394-49A8-865D-CF580A3EB52C@gid.co.uk> In-Reply-To: <8FAA2C39-3394-49A8-865D-CF580A3EB52C@gid.co.uk> From: Warner Losh Date: Fri, 18 Nov 2022 10:32:58 -0700 Message-ID: Subject: Re: Dropping firewire support from boot loader To: rb@gid.co.uk Cc: freebsd-arch Content-Type: multipart/alternative; boundary="0000000000006b04e705edc2195d" X-Rspamd-Queue-Id: 4NDP575qS1z4873 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000006b04e705edc2195d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks for trying all this out. I'm going to go ahead and retire it. If someone wants to bring it back after testing and fixing, we can talk about it then. Warner On Fri, Nov 18, 2022 at 5:30 AM wrote: > Hi, > > It doesn=E2=80=99t seem to work. Building with LOADER_FIREWIRE_SUPPORT do= esn=E2=80=99t > actually get libfirewire.a built but adding the subdir to the list fixes > that. > > The resulting loader booted from a USB stick goes BTX Halted straight awa= y. > > > On 12 Nov 2022, at 20:49, Warner Losh wrote: > > > > > > > > On Sat, Nov 12, 2022, 1:25 PM Bob Bishop wrote: > > Hi, > > > > Well, the kernel support =E2=80=98just works=E2=80=99 so installing on = to a firewire > disk is straightforward; just load up firewire.ko and sbp.ko, and the dis= k > comes up through CAM. > > > > However, I couldn=E2=80=99t get the loader to see the disk; I don=E2=80= =99t think this > build of the loader includes the firewire bits. Not helped on my hardware > because the BIOS doesn=E2=80=99t have firewire disk boot support. > > > > Firmware isn't built by default. You need a special build for that... > what is loading /boot/loader? Not sure you could boot the system with it = if > the bios doesn't support it (except by having a tiny disk that the BIOS > understands and using that to boot off the fireworks root). > > > > Warner > > > > Warner > > > > > On 10 Nov 2022, at 21:53, Warner Losh wrote: > > > > > > I've created a diff: https://reviews.freebsd.org/D37334 > > > > > > Warner > > > > > > On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop wrote: > > > Hi, > > > > > > > On 9 Nov 2022, at 23:55, Warner Losh wrote: > > > > > > > > > > > > > > > > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard > wrote: > > > > Warner Losh wrote on > > > > Date: Wed, 09 Nov 2022 20:01:41 UTC : > > > > > > > > > I'd like to drop firewire support from the boot loader. It's not > been used > > > > > in quite some time, as far as I can tell. Nor have I (or anybody > else) > > > > > tested it in forever. > > > > > > > > > > Is anybody still using it? Does anybody know if it works? Any > objections to > > > > > removing it from FreeBSD 14? > > > > > > I think I still have hardware that will do this. I can check it out i= f > anyone cares... > > > > > > > I would suggest that old PowerMac's might be the most > > > > likely usage context. > > > > > > > > Right now, though, this is an i386 only feature... > > > > > > > > Warner > > > > > > -- > > > Bob Bishop > > > rb@gid.co.uk > > > > > > > > > > > > > > > > -- > > Bob Bishop > > rb@gid.co.uk > > > > > > > > > > > -- > Bob Bishop t: +44 (0)118 940 1243 > rb@gid.co.uk m: +44 (0)783 626 4518 > > > > > > --0000000000006b04e705edc2195d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,

Thanks for trying al= l this out. I'm going to go ahead and retire it. If someone wants to br= ing it back after testing and fixing, we can talk=C2=A0about it then.
=

Warner

On Fri, Nov 18, 2022 at 5:30 AM <rb@gid.co.uk> wrote:
Hi,

It doesn=E2=80=99t seem to work. Building with LOADER_FIREWIRE_SUPPORT does= n=E2=80=99t actually get libfirewire.a built but adding the subdir to the l= ist fixes that.

The resulting loader booted from a USB stick goes BTX Halted straight away.=

> On 12 Nov 2022, at 20:49, Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Sat, Nov 12, 2022, 1:25 PM Bob Bishop <rb@gid.co.uk> wrote:
> Hi,
>
> Well, the kernel support =E2=80=98just works=E2=80=99 so installing on= to a firewire disk is straightforward; just load up firewire.ko and sbp.ko= , and the disk comes up through CAM.
>
> However, I couldn=E2=80=99t get the loader to see the disk; I don=E2= =80=99t think this build of the loader includes the firewire bits. Not help= ed on my hardware because the BIOS doesn=E2=80=99t have firewire disk boot = support.
>
> Firmware isn't built by default. You need a special build for that= ... what is loading /boot/loader? Not sure you could boot the system with i= t if the bios doesn't support it (except by having a tiny disk that the= BIOS understands and using that to boot off the fireworks root).
>
> Warner
>
> Warner
>
> > On 10 Nov 2022, at 21:53, Warner Losh <imp@bsdimp.com> wrote:
> >
> > I've created a diff: https://reviews.freebsd.org/D37= 334
> >
> > Warner
> >
> > On Thu, Nov 10, 2022 at 3:07 AM Bob Bishop <rb@gid.co.uk> wrote:
> > Hi,
> >
> > > On 9 Nov 2022, at 23:55, Warner Losh <imp@bsdimp.com> wrote:
> > >
> > >
> > >
> > > On Wed, Nov 9, 2022 at 3:42 PM Mark Millard <marklmi@yahoo.com> wrote:=
> > > Warner Losh <imp_at_bsdimp.com> wrote on
> > > Date: Wed, 09 Nov 2022 20:01:41 UTC :
> > >
> > > > I'd like to drop firewire support from the boot loa= der. It's not been used
> > > > in quite some time, as far as I can tell. Nor have I (o= r anybody else)
> > > > tested it in forever.
> > > >
> > > > Is anybody still using it? Does anybody know if it work= s? Any objections to
> > > > removing it from FreeBSD 14?
> >
> > I think I still have hardware that will do this. I can check it o= ut if anyone cares...
> >
> > > I would suggest that old PowerMac's might be the most > > > likely usage context.
> > >
> > > Right now, though, this is an i386 only feature...
> > >
> > > Warner
> >
> > --
> > Bob Bishop
> > rb@gid.co.uk
> >
> >
> >
> >
>
> --
> Bob Bishop
> rb@gid.co.uk
>
>
>
>


--
Bob Bishop=C2=A0 =C2=A0 =C2=A0 =C2=A0t: +44 (0)118 940 1243
rb@gid.co.uk=C2=A0 = =C2=A0 =C2=A0m: +44 (0)783 626 4518





--0000000000006b04e705edc2195d-- From nobody Sat Nov 19 04:47:47 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NDh3d5fqmz4hlj3 for ; Sat, 19 Nov 2022 04:47:57 +0000 (UTC) (envelope-from white-wolf@minix-c11.org) Received: from 1.mo583.mail-out.ovh.net (1.mo583.mail-out.ovh.net [188.165.57.91]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NDh3c4Y1lz3tLf for ; Sat, 19 Nov 2022 04:47:56 +0000 (UTC) (envelope-from white-wolf@minix-c11.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of white-wolf@minix-c11.org designates 188.165.57.91 as permitted sender) smtp.mailfrom=white-wolf@minix-c11.org; dmarc=none Received: from player731.ha.ovh.net (unknown [10.110.171.5]) by mo583.mail-out.ovh.net (Postfix) with ESMTP id 088C1226F7 for ; Sat, 19 Nov 2022 04:47:48 +0000 (UTC) Received: from minix-c11.org (83.141.95.92.rev.sfr.net [92.95.141.83]) (Authenticated sender: white-wolf@minix-c11.org) by player731.ha.ovh.net (Postfix) with ESMTPSA id A4596309E08DB for ; Sat, 19 Nov 2022 04:47:48 +0000 (UTC) X-OVh-ClientIp:92.95.141.83 Message-ID: Subject: FreeBSD won't boot on virt-manager, host debian-stable with amd64-12.3 and aarch64-12.3 iso From: white-wolf To: freebsd-arch@FreeBSD.org Date: Sat, 19 Nov 2022 05:47:47 +0100 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 6914151329683165882 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvgedrhedugdejiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepkffuhffvffgtfggggfesthejredttderjeenucfhrhhomhepfihhihhtvgdqfiholhhfuceofihhihhtvgdqfiholhhfsehmihhnihigqdgtuddurdhorhhgqeenucggtffrrghtthgvrhhnpeefvedttddthedtuddugeeuveevieegfeejgefhkeffgefgudehkeehteekudeftdenucfkphepuddvjedrtddrtddruddpledvrdelhedrudeguddrkeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpeeofihhihhtvgdqfiholhhfsehmihhnihigqdgtuddurdhorhhgqedpnhgspghrtghpthhtohepuddprhgtphhtthhopehfrhgvvggsshguqdgrrhgthheshfhrvggvuefuffdrohhrghdpoffvtefjohhsthepmhhoheekfedpmhhouggvpehsmhhtphhouhht X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:mail-out.ovh.net]; RWL_MAILSPIKE_GOOD(-0.10)[188.165.57.91:from]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:16276, ipnet:188.165.0.0/16, country:FR]; DMARC_NA(0.00)[minix-c11.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4NDh3c4Y1lz3tLf X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N hi, i try FreeBSD amd64 and aarch64 on virt-manager, host debian-stable but won't boot topology : socket=2 core=2 theard=2 UEFI for the twice and cortex-a57 and cortex-a52 for aarch64 From nobody Sat Nov 19 04:49:26 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NDh5c6fKWz4hm4K for ; Sat, 19 Nov 2022 04:49:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NDh5c4grxz3tYt for ; Sat, 19 Nov 2022 04:49:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id ud5so17601335ejc.4 for ; Fri, 18 Nov 2022 20:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ipuW9U7QajsW3DEDrwB0u47wpkSxIWow6+4JZ85OyNw=; b=RtES7XgPn+x0MILnMvTBbLP+ZN5Nf9CosxSDm/kwPC7MDzxVmahVXkeAGJ/SZpLneN 0LT7/ViIqc1hAxfz7MWrBJGoHKWvnPJoTr+VWieBx3PF9elPl73v38vVqHvivCjFMQ0L I6xI8j/AUwpKbDCqPE2tW2TtPWGGkt4MQqKpLLt7zVQxBnklvj09QsgX+ZIAoJDxJsYb CCh+hggY00Pgg8bE0qhFYZloCx7AI2CI2NQywZj7ZoOIJML+HMcz7zWj5iP5lzoVdh0/ qL2guvZvL6jUegVSGA9HwWvYoESbltS/nhll6rLITFM+tPOFzefezBe2vnM0IegOhilE Uz7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=ipuW9U7QajsW3DEDrwB0u47wpkSxIWow6+4JZ85OyNw=; b=bXoRscHFvqbZz2tzfDH9Xc4zNcgo8lYuHImQnwGblsaGyHdOeMtbhfmiZ2EX4MVnLl UKfe22AQQKjQDBQUV75F8dgp3W4eesH1bQywldmi3mgaxGOrPQhxRxRBHM3ImpsBdLzq uBVuLxdWRkT+E0+S13cYZwG9DzDvItObjr2h5Sn2fUEZ0V34F9qrm00nnQEa3AokHvcF 34yYVA1povH2EMIgXIcXfkeK9W6rLw9/Xz5rvZwLD2qWK++DRDSoiRXSG+I/orNtagol VTl6+tqT6O7Ksw78rlbBfceBe8ShN46+S/4XGqSbjEsimEF97uS9Z6LtNU+TRgRolf6m sU4A== X-Gm-Message-State: ANoB5pnrcfHkVou8NIeyVFcRL1mHEWzQbvM+jHRyAikKymwVU5xfZgB6 ngCr34qI1+LqqZRtjtygdCqkhcxY1NWkhsp12/2c9f9n2u4= X-Google-Smtp-Source: AA0mqf5d5O4M5NuLquZKFqOvvpftjdAJ/7X4ggsXh0YjfRSdwOogb8/sBpBjVmcqn56JQGFHIb4UX7ejqVIuR05hr3o= X-Received: by 2002:a17:906:22d0:b0:7b2:a7aa:173d with SMTP id q16-20020a17090622d000b007b2a7aa173dmr6313587eja.140.1668833378948; Fri, 18 Nov 2022 20:49:38 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 18 Nov 2022 21:49:26 -0700 Message-ID: Subject: Re: FreeBSD won't boot on virt-manager, host debian-stable with amd64-12.3 and aarch64-12.3 iso To: white-wolf Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000bdf11f05edcb8c48" X-Rspamd-Queue-Id: 4NDh5c4grxz3tYt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000bdf11f05edcb8c48 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 18, 2022, 9:48 PM white-wolf wrote: > hi, > i try FreeBSD amd64 and aarch64 on virt-manager, host debian-stable but > won't boot > > topology : > socket=2 > core=2 > theard=2 > > UEFI for the twice and cortex-a57 and cortex-a52 for aarch64 > Where does it stop booting? Warner > --000000000000bdf11f05edcb8c48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 18, 2022, 9:48 PM white-wolf <white-wolf@minix-c11.org> wrote= :
hi,
i try FreeBSD amd64 and aarch64 on virt-manager, host debian-stable but
won't boot

topology :
socket=3D2
core=3D2
theard=3D2

UEFI for the twice and cortex-a57 and cortex-a52 for aarch64

Where does it s= top booting?

Warner=C2= =A0
--000000000000bdf11f05edcb8c48-- From nobody Sat Nov 19 04:53:09 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NDh9z5zBdz4hmFk for ; Sat, 19 Nov 2022 04:53:27 +0000 (UTC) (envelope-from manickaselvam@gmail.com) Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NDh9z3g0cz3vLW for ; Sat, 19 Nov 2022 04:53:27 +0000 (UTC) (envelope-from manickaselvam@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-13bd19c3b68so8267833fac.7 for ; Fri, 18 Nov 2022 20:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2BKMP60qCeiOhb/GeYlWvYJCCAxovOs6/N3et2wi6U4=; b=JtayxQGbZnBXlZA4tlBB00O6e3ebqx3z0xjY6I2SUhzjUO1azSdLbfgWfXg59MWTeU cPfcZQD9cWy42FSRj5RLxCHjBfrFnvw7AnivJnsGB+Butzh6gXm8aR8/v9G9NTZCeyB+ Sqi1N/uIksjUnnnWzAO0ELayYCCf0c49kIGAuf8Kd70veDxWHkGvlPowLe54npEFNI3E qJIEuyUXpT4ca4uJyQiK6cxQhL0dvnXiRutdqwufWBVqlfHmCHgsW1ZyCa3y/Rl9hyW6 TVTd7yjn+tg5iiYdXU6OZA5FxZNJfQkk6ywfK1KFjDzuSWvwI34BlHwtZ7G67TDZJzZ9 IiIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=2BKMP60qCeiOhb/GeYlWvYJCCAxovOs6/N3et2wi6U4=; b=vQHyWl52HwWc/5ueHdoVc//H7CTqkifwpn/HFWE8fE919GwMIrQkP7UYCP3lb+//pr 50a5BNEe6J+JDXOgUh8FNhPCZGUOZI+xOGL0tJ64IKnrT3vscGZLwq2eQ9g2LCx6COp+ eR7LZJBr9TRfSwITwCMgpTxgjMT3HR6Yj4lN1DCKdsGd++OF1ACIzv2eH+m/kEdi+rj7 q2kNoM2UQSYoJLdng74/oNQbOAqec/qPOOTMcsrx7Dwt3Qtk4k31YHXvRajDpfZ+j08/ vbaBVaY799j8XTaDc6SSWy9luKkW8RvPSMBWV3sT+I3i0d+9DVDlNGKt6n1CDm/ibnRl j60A== X-Gm-Message-State: ANoB5pmy1fA4lhVpexW9Iamrrydh5GFi59iSAfY/COz5AX+ZZ5gMzT3/ WujcRrmTydHHRIEryV5lJV5LuunIMrKpw0tFJXHlSFXb X-Google-Smtp-Source: AA0mqf5sx+ymQ1h8NDkPYVERd6bVn3a3/2NTNF8igYsdPPJDDgaC+BUNHrzibhz57PgJg46j92/U3anJ+rmeD1nlr/k= X-Received: by 2002:a05:6870:6c06:b0:13c:c80:fc40 with SMTP id na6-20020a0568706c0600b0013c0c80fc40mr5721540oab.231.1668833606134; Fri, 18 Nov 2022 20:53:26 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Manickam Dhayalan Date: Sat, 19 Nov 2022 10:23:09 +0530 Message-ID: Subject: Re: FreeBSD won't boot on virt-manager, host debian-stable with amd64-12.3 and aarch64-12.3 iso To: white-wolf Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000048722f05edcb9a5c" X-Rspamd-Queue-Id: 4NDh9z3g0cz3vLW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000048722f05edcb9a5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could you please help me unsubscribe this group? Manickam manickaselvam@gmail.com El s=C3=A1b., 19 nov. 2022 10:18 a. m., white-wolf escribi=C3=B3: > hi, > i try FreeBSD amd64 and aarch64 on virt-manager, host debian-stable but > won't boot > > topology : > socket=3D2 > core=3D2 > theard=3D2 > > UEFI for the twice and cortex-a57 and cortex-a52 for aarch64 > > > --00000000000048722f05edcb9a5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could you please help me unsubscribe this group?

Manickam

El s= =C3=A1b., 19 nov. 2022 10:18 a.=C2=A0m., white-wolf <white-wolf@minix-c11.org> escribi=C3=B3:
hi,
i try FreeBSD amd64 and aarch64 on virt-manager, host debian-stable but
won't boot

topology :
socket=3D2
core=3D2
theard=3D2

UEFI for the twice and cortex-a57 and cortex-a52 for aarch64


--00000000000048722f05edcb9a5c-- From nobody Mon Nov 21 04:47:33 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NFvyG39TXz4hRG9; Mon, 21 Nov 2022 04:47:34 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NFvyG1g4cz4G1B; Mon, 21 Nov 2022 04:47:34 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669006054; 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=QxppQ2MN9AL2K0SDEjKJD7jVGUDRBQK6FSNHjOiccpE=; b=yDEbBoT1CTP5Im+zKGy5ruPyXZ6gFxe203XSSQz8/77XklBH9bgGlftuV3WYbiw6+dPJIU X49fzzqh6+Dc7GJaRGN8OQsqy9lDVQzFI8UdMPdHMiY7Ay9O6NC5g9oDOAXP5QEPU/Vzcz zAsOJnbjxotHJ9aD6Ny6cXNPewKyh5vZdYjHZA2+DhiUUYwYRy7cyypWUl86dHXoIyFcBT 4dqQvm4KF6kMHe8afA6Of1DiiDJT6BGSqc3NlzB1DmdyLgThGENhn0/9VclJlJKvBVY2cp jJQGLuOnL/73lc6auSikmC7L3EYtWZPkxyeGZk3NMe/uLwkmScvhz1E/IHgAoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669006054; 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=QxppQ2MN9AL2K0SDEjKJD7jVGUDRBQK6FSNHjOiccpE=; b=Nb00NIsDe7o0cXKbtkRVkLFWsD4ouAeVrqFyockTVYnzMhZa7uB/VprBBf1QwBPWI3cHoG B/Ecq/23zUOklrAGQyzMbpVOnfRGC3dgnQAw144oi03zTupdGDsdUfAKmMrQpMBIHc9PNG RnmU4wQrztlKWHKC3exPJ64/sVEZJ2xFjWxfdLRZw/fEh8sgIjB3RweQAeDeF14Vfbn6Pk KFO0eCzN1LLpfNdKdCxCCTRFIqa6to5A4N7N2JHJ/Xl5KDk0zEZJkI+bb3Jqx1ldI77jSD rXYWzacuPOYTTEkLU9uy5zlItUBOXju5x2G8v4uyjUEKwn/COwFQo1GgsNj7fQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669006054; a=rsa-sha256; cv=none; b=aTCVZyXNJyOUzZa2cBSll3jedN0iEQFDIfnciCha4pMnfbmees6yc/d/6Fx4etYejT3Zp2 JVwniWjmtAIFfQ6gdx3Keoca7gSK9XPvz5D+1TqNjNB1x5YkkuYWScoSrnQ/QPVEKF/Fzy c7twMwiXdZxq4bLLx+NggFZjjMBtwh5zguezWSKYpNs0zentuTH/FFArenC8r0peHIeqs3 Tht695/fS6vs0BfKhZvuJqmdzNXR+ey4EZtw7Y5tz/Nbhpmlwd21zaA6vckualzgWY3w1o XNfsexCLhibGGhXVegqdpugX393dF6x6eBuzvJBg23pN12BJ8gOKp7tUd1R5OQ== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 084977364; Mon, 21 Nov 2022 04:47:33 +0000 (UTC) Date: Mon, 21 Nov 2022 04:47:33 +0000 From: Alexey Dokuchaev To: Warner Losh Cc: "freebsd-arch@freebsd.org" , FreeBSD PowerPC ML Subject: Re: Boot Loader: OFW network booting support Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 15, 2022 at 10:04:12AM -0700, Warner Losh wrote: > ... > So here's the deal. If someone has the ability to test and shows that it's > working today and promises to test my changes and help me debug it, then > I'll keep it and add the new code that's needed to continue to support this > feature. I'd happily test anything on my venerable Mac mini G4 (which I currently use to ensure ports' endian-cleanness and 32-bit compliance). > Alternatively, if someone has the recipe for FreeBSD/powerpc on QEMU that > includes OpenFirmware for disks and networking, I'll do the testing and > legwork to get my netboot setup locally. I'll play with that as well. I recall last time I needed it, finding that our Wiki doesn't have much working examples of different systems' emuation was frustrating, so at the very least I could probably expand it. ./danfe From nobody Wed Nov 23 19:33:59 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NHWX91gV0z4j7pf for ; Wed, 23 Nov 2022 19:34:01 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NHWX90rLZz3nSR for ; Wed, 23 Nov 2022 19:34:01 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669232041; 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=cPqQfl0dpa/ZIlrUHlQpN4BTHCh5FwUvRPnBLfsQEws=; b=cYo4oGGqCYZ6d5OXHDq7rWyjfXDEIFfpqG5RrPScO4PFwdH66+h3kwcY795rpkYmsjIbgz o/iR+eUqF3zvGgMvDRK6Db6YTiXofF5szP0KP0qDzKFEtB9DkWgsiOTKt151Xxq/0X6AX/ rw2OhSnovb6b5Wcyu9SvISjoGc3uvAcDYPJ3SYAUP8AJPMegn6ED4vEjFsk1omsfwacByN yXkQjcP011f2LTJtr/6gTshg0hJGLXtK1tH+oqyaAxYmMX9kiyZuMtEzvL28SsBZl7B2h3 2UyGfAeRbBvG9FDE/4abuvyK+iZvtc8JokU7nKE5Xq7uRp+a7Gab3gPJF8pqrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669232041; 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=cPqQfl0dpa/ZIlrUHlQpN4BTHCh5FwUvRPnBLfsQEws=; b=Ts7UTepsqa73wtF5nmkkI2li1rTFuKhz0vCxuVUUTjrMu1REkuVLusrCaUlI7v/eY/pI+J iCEpR3QTCbQAgPLKXmI/SQeshOMGoSa2jGh9ZdwNXGyt6RT35eZdJmKi6exvt76EQZq1Rn fjBKRYX/tp/BerXe0ZtPoZOzCGB0gVBAxis+7P4ntK97PkbMeqMi19E3c6v8SnYKqGoRkh FhwMQsD9z28nhwfQ008VZeA4xZAz83r7TJg9hEqu7yre8hGSoRSIHpBwSGcgPjKoyPoZxc nt5iLcW3V9hPsIT5JCFxlpUSCPWqoDg7b9zw/zhx2kX8Lizgu00VzUbAdjISJw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669232041; a=rsa-sha256; cv=none; b=aTqx+l6YQ63J1O8IxFrsvD8LT19DD/22sDjp2Eu6gLaT9EKLzyG3daFf0RiB6dOd/crsf5 j+V1K3HuHwz3i+C/VxFxUobceVUcEPymaLRdtAUkdYpNadNLwBHrs4Jw0CE7Fl3f1SFE6J AJ66uH9ngx8r9QBlpHtrOSQ5I27LoxbMNPKkHl1AGom7Um69LtyrYVQ7OQ/Fcpq3IGA/06 NeOxLR+uDPxzekuFiSn+OrIobmkhgRP2vDactneViPGf7HYB8uH3fJkMuEs6Z0vlbdi4Kk OYynXJYocSituFJbjDecXjq150mzsgBdB6zm28kUYECsYveXiSrV6vU0w4HZhA== Received: from ralga-linux (dsl-74-83-251-217.fuse.net [74.83.251.217]) (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 4NHWX869VPz10Kr for ; Wed, 23 Nov 2022 19:34:00 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Wed, 23 Nov 2022 14:33:59 -0500 From: Justin Hibbits To: freebsd-arch@freebsd.org Subject: Modularizing the network stack with a driver API Message-ID: <20221123143359.2370ed89@ralga-linux> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; powerpc64le-unknown-linux-gnu) Importance: high X-Priority: 1 (Highest) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N Hi everyone, Back in 2014 Marcel Moolenaar started the thread "Roadmap for ifnet(9) for FreeBSD 11" (https://lists.freebsd.org/pipermail/freebsd-arch/2014-May/015379.html), and after 8 years we want to revisit this. This email is to kick things off again, and further design discussions. I've spent time off and on as able over the last couple years porting -CURRENT to this "DrvAPI", and have something that compiles. Much of the work was committed at the time of the initial discussion in 2014, with enhancements done off and on since then. Also, much of the shortcomings listed at https://wiki.freebsd.org/projects/ifnet have not been addressed at all yet. Most of the work I've done in the recent port has been purely mechanical and scripted, fixing build failures along the way. The current work in progress can be found in my personal repository at https://github.com/chmeeedalf/freebsd/tree/drvapi . The goal of this first step is to get things started, address design feedback, and move forward in main. - Justin From nobody Wed Nov 23 20:23:03 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NHXcm6rGtz4jD0N for ; Wed, 23 Nov 2022 20:23:04 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NHXcm6KNrz3t9b; Wed, 23 Nov 2022 20:23:04 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669234984; 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=wKh4ww5yqcj6bLOuPt6bAD8QMXR4zXyBvSGUm9D+sTA=; b=tZWPBDD1EUmLM11KQEuoEh5eNl4nrXZNjng2G/M3BH8xB0WgbQ2+0+dxaN5QVsFM40Bhso zEO6zJqDCLJUsikEXyaxCGbTJz25ByiKhe4z3OZRGVS1Uj0Mz/mVgH/rSbNUHoKvY58Zwk VjESGqYs5T1fNLtdR6LCYMRUZH09lkt8ksAvHnjawJ9Y96FdTzP9mbTphcL/Mw++bNq6tt F+C6XeY61cU84bhbZ2/M5jUFQkvZ2V/hzv3pG8ZvBV5o9j4eI/fCBT2djLa3H1D3L1pEMi cqf6QFLP92fru96V6zHSuBCVtngwnsjMuUwd9hkzKq3nEQeX5KUNFX0aoZ2oXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669234984; 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=wKh4ww5yqcj6bLOuPt6bAD8QMXR4zXyBvSGUm9D+sTA=; b=L3ql/c6rNF2eeKuHd3oaGzJnFz6/eAWnsqD0ap4yYh5mXxJh2cIJafgwoEmWPJu/CwLWm+ xQg5qRin2JqnW/a4f1n8Wo+81Z7tJL0fxOZ/aQpWoT413/mSr2nI9mSJqkFdFGhUz9FgBf Jib8tdONiukJydek0JNMuewNGhQSlu7ctK2DCvLZuf7EMnrbHsNj/qKZ5oa4U5L126G0fs 9bO9fLk6KXXYYtXVTj1hB32mjT1QU7Jyv/AfLsMwvBeEvpRCjHsTQmtgOUzNnBB9FWo7uH E+RVuLkymDUD70jvByakf+76B2bGH1/yrKsNppS+BTxQ5q0GEIYrzvB/xGsIrQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669234984; a=rsa-sha256; cv=none; b=qD3oJiWU25RQsDzNE468uO18lNbUXuR3A0vNhAUyDfM/yP0BKXFtIevy6bGsDFV+gZHBtp r+z8TlcHjmjPKNiQeMnylrHZLlUOpR5GPGjZelJMgmyu1t0qRle8BxJaXLoro38m0fjZ2d cBbkCYQB8eJeCSwPyiS72XJQ2ejXwhfTEjerzvn3PJ5m/Aj3s07mbxBtklvnsoGXBg6YCc Y7hwqcYyUwFhEfLEaP+yaDtXgMnwdEq+R8eJJ9wCvvPuwdFmpGRBXc89iNMZxfMUSjj4le rpZV+yDruimwqeGWPlfT3RxyoH/Aw5LUsmzc/sMMUERWBnCY24qrUBEH6phEfA== Received: from ralga-linux (dsl-74-83-251-217.fuse.net [74.83.251.217]) (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 4NHXcm4NxTz1091; Wed, 23 Nov 2022 20:23:04 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Wed, 23 Nov 2022 15:23:03 -0500 From: Justin Hibbits To: George Neville-Neil Cc: freebsd-arch@freebsd.org Subject: Re: Modularizing the network stack with a driver API Message-ID: <20221123152303.6ff602e7@ralga-linux> In-Reply-To: References: <20221123143359.2370ed89@ralga-linux> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; powerpc64le-unknown-linux-gnu) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On Wed, 23 Nov 2022 15:09:01 -0500 George Neville-Neil wrote: > On 23 Nov 2022, at 14:33, Justin Hibbits wrote: > > > Hi everyone, > > > > Back in 2014 Marcel Moolenaar started the thread "Roadmap for > > ifnet(9) for FreeBSD 11" > > (https://lists.freebsd.org/pipermail/freebsd-arch/2014-May/015379.html), > > and after 8 years we want to revisit this. This email is to kick > > things off again, and further design discussions. > > > > I've spent time off and on as able over the last couple years > > porting -CURRENT to this "DrvAPI", and have something that > > compiles. Much of the work was committed at the time of the > > initial discussion in 2014, with enhancements done off and on since > > then. Also, much of the shortcomings listed at > > https://wiki.freebsd.org/projects/ifnet have not been addressed at > > all yet. > > > > Most of the work I've done in the recent port has been purely > > mechanical and scripted, fixing build failures along the way. The > > current work in progress can be found in my personal repository at > > https://github.com/chmeeedalf/freebsd/tree/drvapi . The goal of > > this first step is to get things started, address design feedback, > > and move forward in main. > > > > Can you say how this does (or does not) work with the ifLib effort? > I'm happy to have a better driver API for our NIC drivers just > wondering if this replaces, enhances, or has nothing to do with > what's there now. I know that only a few drivers picked up ifLib > (Intel) the last time I looked. > > Best, > George I think they're complementary. Someone can correct my understanding, but iflib looks like a driver library, taking care of the commonalities of hardware drivers (transmit/receive queuing, packet processing), while the DrvAPI is for interfacing with the network stack, abstracting the stack away behind this API - Justin From nobody Sun Nov 27 21:35:31 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NL22s6VYpz4hsgh for ; Sun, 27 Nov 2022 21:35:49 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NL22s64Ptz3Ntt for ; Sun, 27 Nov 2022 21:35:49 +0000 (UTC) (envelope-from netchild@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669584949; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PD0xdSBFeAAOk7nQC/zqzvTOsxxJXcNB4H8woI02svo=; b=Rlz0Fdjja4nTYmgUSDTGJHMMkOLMtRPRh3yCPtws3jFaG9gnOBfrs96thIu0bDoszXmJ79 QqauUvAd1Tj+F59olM6/Rqg0qqDR5P4ZCeCybNd/3hc8Ty8+gIgVD5txukWRo8Ou/MhJQ3 fu0phzbcZahyAJ/zWJ9XxFb+WxxI7Qql66HC/Fv9TB8on+23fc6Za4TbH7LojMZslCg38K dZMWxhh6DtZeg83cIhLKHAr+ibXCEu9/GcoTgv2Mg3h4btBYB0hHIargWtdkKnDQqruJcG 6fBGgzxKq0wZd1WvWenIT+nARA9N52jbdWCEHe1dyGLKLMng5dzjMe9OLj8Bcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669584949; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PD0xdSBFeAAOk7nQC/zqzvTOsxxJXcNB4H8woI02svo=; b=EMjCtM7CN+N9zb3ml17ptC7UCF/QFDu5+j1KwZD7euNWrwY0DLuoFOqgjVu6GZkvqQRhlZ l+75AF0Ryz8gfgRHhUl9D7WFAR1SFzYiHsBxYUcNXShkOvcnECIspbS8RSrI6MnGvOqtiu 5gVPP5O/h24ihaEedAwGZORhZrPTKpaj1TastowgKZnxEDWaFXgMG0bbTgRZsYK4QillUw F1O3Zt3howjtFZwld965PnkIiCSEMVhtQFJFn2OzRcbdeY5SMm+2cNlAR4g33djTg0ytbY QstN4wwyDug546oFimVUgoleAsGIfr5/NmGzUfAPqzyAr8FTn/EpJTd5WGWXbQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669584949; a=rsa-sha256; cv=none; b=j+ZIaxLU0AL1idPHIjARzoji7KTQwcH/Fmq6eP1ntmyqrcsFk/f28L1dvGG2P3/WOj365w 05c9la3DcyJqN18etc5mbmRbd3XxuJHXa2c9NzQXkZsS2WyeaI6qqkum16v1v4joFfQSfz JB4p4gFRo/YKZyEVSyPHuXA/pm8UJ4YeKpcnbwGDuw9/EViL9OszZaHpE7AZ9AB/mS0Pyg XLRwam48UWPVKTxfnz9qskVY47Wr23nEOQjlg32mdl9078YB5P4kDHG1TpnYdZfPwHA2wv pT8x81i9XVq2i/mpRt/hWPL8i1gZ0ATbrCAXu/Uf+LzKpXfybGtWHOJvwG/vnw== Received: from outgoing.leidinger.net (p5b165cc5.dip0.t-ipconnect.de [91.22.92.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) (Authenticated sender: netchild) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NL22s4DcdznQx for ; Sun, 27 Nov 2022 21:35:49 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from webmail.leidinger.net (localhost [127.0.0.1]) by outgoing.leidinger.net (Postfix) with ESMTP id D262E2773 for ; Sun, 27 Nov 2022 22:35:31 +0100 (CET) Received: from www (uid 80) (envelope-from netchild@freebsd.org) id 96226 by webmail.leidinger.net (DragonFly Mail Agent v0.13+ on webmail.leidinger.net); Sun, 27 Nov 2022 22:35:31 +0100 Date: Sun, 27 Nov 2022 22:35:31 +0100 Message-ID: <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> From: Alexander Leidinger To: Warner Losh , freebsd-arch@freebsd.org Subject: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_y6uaaNWq-rdHC5mSDphLTBl"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_y6uaaNWq-rdHC5mSDphLTBl Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Warner Losh (from Fri, 25 Nov 2022 09:41:28 -0700)= : > Please revert this. We keep older updating entries on purpose. You purged > way too much. Let's chat about how much to remove in arch@. They are for > more than just source updates, so your reasoning is wrong. They are also > there for users updating their products which can have a larger leap in > time. We've traditionally kept closer to 5-10 years here for that reason. Reverted. UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit=20= =20 excessive=20(more than 9 years of development work so far), isn't it? I don't get the "more than just src updates" part. If we don't talk=20=20 about=20the source code, isn't src/UPATING not the wrong place to store=20= =20 it? In=20terms of updating products, I understand that updating them every 2=20= =20 years=20may be a little bit expensive/excessive for some vendors, but=20=20 taking=20every UPDATING from every stable branch in-between doesn't look=20= =20 too=20much time consuming to me. And compared to the huge amount of=20=20 changes=20between N-2 and N... taking UPDATING from all stable branches=20= =20 in-beteen=20is nothing. Nevertheless, 4-5 years I consider OK-ish,=20=20 nearly=2010 years is ... ugh ... a life-time or two in the computer=20=20 world.=20If we look e.g. at the PlayStation (yes, just one of the=20=20 products=20which has FreeBSD inside, but personally I consider it one of=20= =20 the=20more stable ones than some network products which have a shorter=20= =20 shelf-time=20than the PS-line from an OS-version-tracking point of=20=20 view),=20there are around 6 years in-between models, and they surely=20=20 haven't=20started developing a month before the release date. So where do we draw the line for UPDATING, 2 major versions (~4=20=20 years),=203 major versions (~6 years)? ~10 years (~5 major versions)=20=20 looks=20overly excessive to me. That's not something you want to try to=20= =20 catch=20up, that's rather a new development than a catch-up. Bye, Alexander. > On Fri, Nov 25, 2022, 2:23 AM Alexander Leidinger > wrote: > >> The branch main has been updated by netchild: >> >> URL: >> https://cgit.FreeBSD.org/src/commit/?id=3Dff0c7816db696d31adc437134dcad4= 5a70ad5889 >> >> commit ff0c7816db696d31adc437134dcad45a70ad5889 >> Author: Alexander Leidinger >> AuthorDate: 2022-11-25 09:17:14 +0000 >> Commit: Alexander Leidinger >> CommitDate: 2022-11-25 09:17:14 +0000 >> >> Remove UPDATING entries from old branches. >> >> We only support updates from major version N to N+1: >> stable/13 was branched on 20210122, remove all old entries from >> stable/10 >> branch point in 2013 to 20210122. [~2k lines trimmed] --=20 http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_y6uaaNWq-rdHC5mSDphLTBl Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmOD2CMACgkQEg2wmwP4 2IauEA//VB1INrLpqIih+eBiEqXfoee+1UTC98LghVA2kBAGegpv7cIfa1Stk6nh GNm36lBqTOEIsm1IgFaLQI5XJ84Lm2JNlwkv6v6C+LBzbwIq+FGLd0DY3O/lW94K Gc18Lfxv9dOBNU1BWY+MZgscJ3yL8ht6W/atSLbBf2OlMSyg0shtBHNQATguFWuX lPRgR/6yXpAS+tM43tnizhjyVQ5MwF5IFuNLgD6IGXNM7zeHCtp7FpOqp4oQmcIf ihyWeHdYwiT59R/1cklLghDO+S0tmvkKNzs/KtU/Sy4aN+D5U3WFaQJ+y8hjgkw/ sIvM31fJ1G5Orl0AUa3nRGqao98EBfv82+mvNwCEo6IHi371t4dHexa6OXZkf/K9 hM+O7mqWYekmoXKWQ38IvywjxSTN40qj42Fd4bOild3YYA3ND31KmQ/Wbp3uu07c /lR7EVM6ub9XX6qPeAA2CM2UD/lAHDh4QIMxymB25tBb/Lgk7sCcTUFNxmrAu9Ao pgdySc4Ob8Lu+sPElc5TpYAHaxkAYzeX+GbwqYEeZxw8Y8SwRocCFoQClg1GU4xQ zH6kU777yTlhc4mwN7hkoG6piCeKr1iddRrOuzzlV7jhD1CwoC/Ag/xjwy9YDM6W Wtuwg4L9z9kftw9DQd8gmblxNi64HdXz/8MW7W1nQYle68eeGoU= =W0dR -----END PGP SIGNATURE----- --=_y6uaaNWq-rdHC5mSDphLTBl-- From nobody Mon Nov 28 02:17:21 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NL8Hw5w4yz4hb5q for ; Mon, 28 Nov 2022 02:17:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NL8Hw3dk2z41D9 for ; Mon, 28 Nov 2022 02:17:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x633.google.com with SMTP id n20so22560571ejh.0 for ; Sun, 27 Nov 2022 18:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=phJ4S/bVHDJK0F6NyXUceb+mK2YrLtITbJF2GVmx+Qg=; b=33QtTxUYh9LzIz9w+FQnE46qrjwxqXcNOJLFhBYCaoB1bzoleIZkiXoAOSh/gw0BCN fHztH1aCZzneMYlV8P3sjBQ4ABaYTvUz2byd/E32fgmmQ/jPDRLHPzItmre1wiEpfDQ6 D5UjxSWXgWCYS0840zg3r0xaF6k819wHDrxz0xiUIhxmtbZbNRbpQ03k1AOzu+U/Y+Kd 0GKisIVZT1FJZq8mFgGh+5McTkRSro+fMpfI7UAscyO38/kdzU8Y798kviOgmoieOEVD 0OlHfN3g2v7u5MGeDPqH3zGvG4gkY9LHhRXiYotf15MmXY4SeV9UfLr/Ziaars+U2FPx VKeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=phJ4S/bVHDJK0F6NyXUceb+mK2YrLtITbJF2GVmx+Qg=; b=LQqXHIoaEjM4+SK6Dn+1mbDelUFctcLyeRFwvmFbJOW/0TPK8TvLM5INT5XisegEPN 83YrInw1kV7EfZgR/uD4g5En3lIE7ffa76MKtXICgKH8ZntCxJ/KdNXuHRiL3D3dLMNd vZsRb8KyxGRyD3uAVQqLp+NmDXSx4mdEhIz9yTsZGS7VFdrqgpl/FOXQaUeZjT7UKPqB qeB9ZHCt3Scs3SndL2fMspLZVARhgOkJiE5wGKWZo/OCaC324GXPKgmIxwpSeW9Qp5O/ 0NZR1Kjxhf7CfjUphjw6gy+UWh2qKIwuPvqJ3bdEXN6XsrkKKgIbhpc8/KkbxD1ZYEYG roxg== X-Gm-Message-State: ANoB5pnepcZnrZKzLsRWVfaq3H/8rbYfhuNS7T9ry6qs4xkoXEZZAWoL Sy6jTmbpoZjwasyJDn446IdV+74Azp5fhk2Zv0FNpH1WIIU= X-Google-Smtp-Source: AA0mqf7h6SFZYyjOmBkTcnAASMxAP6vENaF5+vIxlmkCWL6bhhDO9f5saw6/Eh2VbiyqFbXuoO8kPzKNCyxvPxIJnEg= X-Received: by 2002:a17:906:f84d:b0:7b9:631b:7dfb with SMTP id ks13-20020a170906f84d00b007b9631b7dfbmr22458029ejb.32.1669601848487; Sun, 27 Nov 2022 18:17:28 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> In-Reply-To: <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> From: Warner Losh Date: Sun, 27 Nov 2022 19:17:21 -0700 Message-ID: Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) To: Alexander Leidinger Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000018842805ee7e79c4" X-Rspamd-Queue-Id: 4NL8Hw3dk2z41D9 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000018842805ee7e79c4 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger wrote: > Quoting Warner Losh (from Fri, 25 Nov 2022 09:41:28 > -0700): > > > Please revert this. We keep older updating entries on purpose. You purged > > way too much. Let's chat about how much to remove in arch@. They are for > > more than just source updates, so your reasoning is wrong. They are also > > there for users updating their products which can have a larger leap in > > time. We've traditionally kept closer to 5-10 years here for that reason. > > Reverted. > > UPDATING as far back as stable/10 (= 4 major updates) is a little bit > excessive (more than 9 years of development work so far), isn't it? > Yes. It's about one release too old, maybe two. More on one or two in a bit. > I don't get the "more than just src updates" part. If we don't talk > about the source code, isn't src/UPATING not the wrong place to store > it? > More than just 'make buildworld updating' or ''updating a system from src' is what I mean. > In terms of updating products, I understand that updating them every 2 > years may be a little bit expensive/excessive for some vendors, but > taking every UPDATING from every stable branch in-between doesn't look > too much time consuming to me. And compared to the huge amount of > changes between N-2 and N... taking UPDATING from all stable branches > in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish, > nearly 10 years is ... ugh ... a life-time or two in the computer > world. If we look e.g. at the PlayStation (yes, just one of the > products which has FreeBSD inside, but personally I consider it one of > the more stable ones than some network products which have a shorter > shelf-time than the PS-line from an OS-version-tracking point of > view), there are around 6 years in-between models, and they surely > haven't started developing a month before the release date. > So, let's look at what it's used for to see how much we need. If you look at it that way, you'll see that we're not crazy lagging. > So where do we draw the line for UPDATING, 2 major versions (~4 > years), 3 major versions (~6 years)? ~10 years (~5 major versions) > looks overly excessive to me. That's not something you want to try to > catch up, that's rather a new development than a catch-up OK. Traditionally we've lagged a major release or two from what's officially supported by the project. Right now the 10.x stuff is definitely too old. The 11.x stuff is borderline (but likely relevant), the 12.x stuff is still quite relevant. We need to look at who is updating. Many people have only recently updated from 11. Almost everybody has updated from 10 by now. Lots of people are using 12 and it's still supported. Most of the folks that have source products with lots of changes have updated to at least 12 as far as I've been able to tell. But many haven't jumped to 13 or current yet. There are many people still updating their VMs from 11. Traditionally, they wait until after 11.x goes unsupported before they update. It's only been unsupported for just over 1 year. In the past, this is where upgrading is hitting full speed (I've received feedback in the past at conferences that people often put it off for up to 18 months)... 10.x has been unsupported for more than 3 years, so historically everybody has moved on. So the 10.x entries are definitely stale... The 11 entries are on the edge... I'd normally have removed the 10.x entries when 13 was branched, but I was asleep at the wheel this time.... Though looking at the logs, I've been not so great about this. Better at some times, worse at others.... So in my opinion, 10.x entries should have already been gone. 11.x entries are likely useful enough to keep, but they are waning fast. 12.x entries are likely being used all the time by people upgrading from still-supported releases. We've traditionally weighted towards retention because the cost of retention has been super low. This suggests we delete up to the 11 branch point now, and to the 12 branch point when 14 branches in 6 months or so... Warner --00000000000018842805ee7e79c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 27, 2022 at 2:35 PM Alexa= nder Leidinger <netchild@freebsd.org> wrote:
Quoting Warner Losh <imp@bsdimp.com> (from Fri, 25 Nov 2022 09:41:= 28 -0700):

> Please revert this. We keep older updating entries on purpose. You pur= ged
> way too much. Let's chat about how much to remove in arch@. They a= re for
> more than just source updates, so your reasoning is wrong. They are al= so
> there for users updating their products which can have a larger leap i= n
> time. We've traditionally kept closer to 5-10 years here for that = reason.

Reverted.

UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit=C2= =A0
excessive (more than 9 years of development work so far), isn't it?
=

Yes. It's about one release too old, m= aybe two. More on one or two in a bit.
=C2=A0
I don't get the "more than just src updates" part. If we don&= #39;t talk=C2=A0
about the source code, isn't src/UPATING not the wrong place to store= =C2=A0
it?

More than just 'make buildworld= updating' or ''updating a system from src'
is wh= at I mean.
=C2=A0
In terms of updating products, I understand that updating them every 2=C2= =A0
years may be a little bit expensive/excessive for some vendors, but=C2=A0 <= br> taking every UPDATING from every stable branch in-between doesn't look= =C2=A0
too much time consuming to me. And compared to the huge amount of=C2=A0 changes between N-2 and N... taking UPDATING from all stable branches=C2=A0=
in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish,=C2=A0
nearly 10 years is ... ugh ... a life-time or two in the computer=C2=A0 world. If we look e.g. at the PlayStation (yes, just one of the=C2=A0
products which has FreeBSD inside, but personally I consider it one of=C2= =A0
the more stable ones than some network products which have a shorter=C2=A0 =
shelf-time than the PS-line from an OS-version-tracking point of=C2=A0
view), there are around 6 years in-between models, and they surely=C2=A0 haven't started developing a month before the release date.

So, let's look at what it's used for to se= e how much we need. If you
look at it that way, you'll see th= at we're not crazy lagging.
=C2=A0
So where do we draw the line for UPDATING, 2 major versions (~4=C2=A0
years), 3 major versions (~6 years)? ~10 years (~5 major versions)=C2=A0 looks overly excessive to me. That's not something you want to try to= =C2=A0
catch up, that's rather a new development than a catch-up
<= div>
OK. Traditionally we've lagged a major release or tw= o from what's
officially supported by the project. Right now = the 10.x stuff is definitely
too old. The 11.x stuff is borderlin= e (but likely relevant), the 12.x stuff
is still quite relevant.<= br>

We need to look at who is updating. Many peopl= e have only recently
updated from 11. Almost everybody has update= d from 10 by now. Lots
of people are using 12 and it's still = supported.

Most of the folks that have source prod= ucts with lots of changes have
updated to at least 12 as far as I= 've been able to tell. But many haven't
jumped to 13 or c= urrent yet.

There are many people still updating t= heir VMs from 11. Traditionally, they
wait until after 11.x goes = unsupported before they update. It's only been
unsupported fo= r just over 1 year. In the past, this is where upgrading is
hitti= ng full speed (I've received feedback in the past at conferences that
people often put it off for up to 18 months)... 10.x has been unsu= pported
for more than 3 years, so historically everybody has move= d on. So the
10.x entries are definitely stale... The 11 entries = are on the edge...=C2=A0 I'd
normally have removed the 10.x e= ntries when 13 was branched, but
I was asleep at the wheel this t= ime.... Though looking at the logs, I've
been not so great ab= out this. Better at some times, worse at others....

So in my opinion, 10.x entries should have already been gone. 11.x
<= div>entries are likely useful enough to keep, but they are waning fast. 12.= x
entries are likely being used all the time by people upgrading = from still-supported
releases. We've traditionally weighted t= owards retention because the
cost of retention has been super low= .

This suggests we delete up to the 11 branch poin= t now, and to the 12
branch point when 14 branches in 6 months or= =C2=A0so...

Warner

<= /div> --00000000000018842805ee7e79c4-- From nobody Mon Nov 28 03:12:08 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NL9W83WWPz4hkBT for ; Mon, 28 Nov 2022 03:12:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NL9W70HR8z44tg for ; Mon, 28 Nov 2022 03:12:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=ph5VIsZF; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::632) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x632.google.com with SMTP id gu23so4437869ejb.10 for ; Sun, 27 Nov 2022 19:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0fjmwPWoEmdXNq5TLT2ppioMkqssQXiQ3js/DXNG3Jk=; b=ph5VIsZFRWEBEwIWDb5qtf9BEdyKyHb5h4dQMolBfpgA55JL5ab57fh9OqjNmsCSiw WOBj9Gq8XLptgjotrh0HJF8IF+vS8g2YWRFWxVFCr+AnHeFs1+vptxFvh1m/9RAR7sM9 C25qBZdH7IiDgfu6XjqrIeWGYwrCVRfcxgBtlgzJB2Tx6YgD/qOVGbxqQ20vA3P8evT5 ozGfvSy7TxIughx55DaeG2rS1vpj7vu2ulHiPJebSvtwkKQN7u5erOeXTGN/oTuNdFwx gJUs622iWEzHTfWoFm6gFYm7mqG9gfVqkY04FzMGasSVx6863sh18uPv3KFCXrf7/Ng1 c6JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=0fjmwPWoEmdXNq5TLT2ppioMkqssQXiQ3js/DXNG3Jk=; b=SfSA15DJ06D2LZOxc4L7zI0MbnzJIw+PFu7rDO5nUVDDJr5Lkt0wOZ/WtQhdE+cvuX MyNkstBY46JWHK8LyKoSj5ccDb7kdXTxI055L6mrHQhyO6wdWXxGQehxE+zshJcmWEl7 9V+CwMkgg+l/687bYVsixMutd+9btmJhsSfYvZUm7jwZ3uT7wNxIEiTdy2XmLbtDJ5u6 KO8Vzb5UOgZGES2mcfI/PNCQzBRrsUig1Y2O6tU6QVnktE7GXMD5hNPLTrv8zcYnI00F Nq22jS150+3u953smXdeW2DtcLNjUJo3lYX5+Ecd4VqGkE/71im86QpDzZ3wH9iEjZNV k5Jg== X-Gm-Message-State: ANoB5plcvlmUWQcvrFAklt5kZ1ixbcW8nIAW7h75d9/6wYLo5dP7uOSr LhtbHEiTO44Xiol35WHH6gkVWHnCDMZqJWMNLuhsqygaUzo= X-Google-Smtp-Source: AA0mqf6Gp/VYo/k82TKdpK+rVW1Mu7gnoKmklLTv9dH4Uxo3LmcQt+fPL5SP/tRk6f8giMBVHfHXGipggB4IEs2gKMI= X-Received: by 2002:a17:906:684a:b0:7bc:73e6:b2c3 with SMTP id a10-20020a170906684a00b007bc73e6b2c3mr11754277ejs.451.1669605136313; Sun, 27 Nov 2022 19:12:16 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> In-Reply-To: From: Warner Losh Date: Sun, 27 Nov 2022 20:12:08 -0700 Message-ID: Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) To: Alexander Leidinger Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000010c4a005ee7f3dbf" X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4NL9W70HR8z44tg X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000010c4a005ee7f3dbf Content-Type: text/plain; charset="UTF-8" On Sun, Nov 27, 2022 at 7:17 PM Warner Losh wrote: > > > On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger > wrote: > >> Quoting Warner Losh (from Fri, 25 Nov 2022 09:41:28 >> -0700): >> >> > Please revert this. We keep older updating entries on purpose. You >> purged >> > way too much. Let's chat about how much to remove in arch@. They are >> for >> > more than just source updates, so your reasoning is wrong. They are also >> > there for users updating their products which can have a larger leap in >> > time. We've traditionally kept closer to 5-10 years here for that >> reason. >> >> Reverted. >> >> UPDATING as far back as stable/10 (= 4 major updates) is a little bit >> excessive (more than 9 years of development work so far), isn't it? >> > > Yes. It's about one release too old, maybe two. More on one or two in a > bit. > > >> I don't get the "more than just src updates" part. If we don't talk >> about the source code, isn't src/UPATING not the wrong place to store >> it? >> > > More than just 'make buildworld updating' or ''updating a system from src' > is what I mean. > > >> In terms of updating products, I understand that updating them every 2 >> years may be a little bit expensive/excessive for some vendors, but >> taking every UPDATING from every stable branch in-between doesn't look >> too much time consuming to me. And compared to the huge amount of >> changes between N-2 and N... taking UPDATING from all stable branches >> in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish, >> nearly 10 years is ... ugh ... a life-time or two in the computer >> world. If we look e.g. at the PlayStation (yes, just one of the >> products which has FreeBSD inside, but personally I consider it one of >> the more stable ones than some network products which have a shorter >> shelf-time than the PS-line from an OS-version-tracking point of >> view), there are around 6 years in-between models, and they surely >> haven't started developing a month before the release date. >> > > So, let's look at what it's used for to see how much we need. If you > look at it that way, you'll see that we're not crazy lagging. > > >> So where do we draw the line for UPDATING, 2 major versions (~4 >> years), 3 major versions (~6 years)? ~10 years (~5 major versions) >> looks overly excessive to me. That's not something you want to try to >> catch up, that's rather a new development than a catch-up > > > OK. Traditionally we've lagged a major release or two from what's > officially supported by the project. Right now the 10.x stuff is definitely > too old. The 11.x stuff is borderline (but likely relevant), the 12.x stuff > is still quite relevant. > > We need to look at who is updating. Many people have only recently > updated from 11. Almost everybody has updated from 10 by now. Lots > of people are using 12 and it's still supported. > > Most of the folks that have source products with lots of changes have > updated to at least 12 as far as I've been able to tell. But many haven't > jumped to 13 or current yet. > > There are many people still updating their VMs from 11. Traditionally, they > wait until after 11.x goes unsupported before they update. It's only been > unsupported for just over 1 year. In the past, this is where upgrading is > hitting full speed (I've received feedback in the past at conferences that > people often put it off for up to 18 months)... 10.x has been unsupported > for more than 3 years, so historically everybody has moved on. So the > I can't do math.... More than 4 years... > 10.x entries are definitely stale... The 11 entries are on the edge... I'd > normally have removed the 10.x entries when 13 was branched, but > I was asleep at the wheel this time.... Though looking at the logs, I've > been not so great about this. Better at some times, worse at others.... > So in my opinion, 10.x entries should have already been gone. 11.x > entries are likely useful enough to keep, but they are waning fast. 12.x > entries are likely being used all the time by people upgrading from > still-supported > releases. We've traditionally weighted towards retention because the > cost of retention has been super low. > > This suggests we delete up to the 11 branch point now, and to the 12 > branch point when 14 branches in 6 months or so... > 13.x was branched about 6.5 years ago. When 14 is branched, it will be 7 years and we'll removing the to the 12 branch point which will be four and half years. This seems like a good range to oscillate between. Warner --00000000000010c4a005ee7f3dbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 27, 2022 at 7:17 PM Warne= r Losh <imp@bsdimp.com> wrote:<= br>


On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger &= lt;netchild@freeb= sd.org> wrote:
Quoting Warner Losh <imp@bsdimp.com> (from Fri, 25 Nov 2022 09:41:28 -0700):

> Please revert this. We keep older updating entries on purpose. You pur= ged
> way too much. Let's chat about how much to remove in arch@. They a= re for
> more than just source updates, so your reasoning is wrong. They are al= so
> there for users updating their products which can have a larger leap i= n
> time. We've traditionally kept closer to 5-10 years here for that = reason.

Reverted.

UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit=C2= =A0
excessive (more than 9 years of development work so far), isn't it?
=

Yes. It's about one release too old, m= aybe two. More on one or two in a bit.
=C2=A0
I don't get the "more than just src updates" part. If we don&= #39;t talk=C2=A0
about the source code, isn't src/UPATING not the wrong place to store= =C2=A0
it?

More than just 'make buildworld= updating' or ''updating a system from src'
is wh= at I mean.
=C2=A0
In terms of updating products, I understand that updating them every 2=C2= =A0
years may be a little bit expensive/excessive for some vendors, but=C2=A0 <= br> taking every UPDATING from every stable branch in-between doesn't look= =C2=A0
too much time consuming to me. And compared to the huge amount of=C2=A0 changes between N-2 and N... taking UPDATING from all stable branches=C2=A0=
in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish,=C2=A0
nearly 10 years is ... ugh ... a life-time or two in the computer=C2=A0 world. If we look e.g. at the PlayStation (yes, just one of the=C2=A0
products which has FreeBSD inside, but personally I consider it one of=C2= =A0
the more stable ones than some network products which have a shorter=C2=A0 =
shelf-time than the PS-line from an OS-version-tracking point of=C2=A0
view), there are around 6 years in-between models, and they surely=C2=A0 haven't started developing a month before the release date.

So, let's look at what it's used for to se= e how much we need. If you
look at it that way, you'll see th= at we're not crazy lagging.
=C2=A0
So where do we draw the line for UPDATING, 2 major versions (~4=C2=A0
years), 3 major versions (~6 years)? ~10 years (~5 major versions)=C2=A0 looks overly excessive to me. That's not something you want to try to= =C2=A0
catch up, that's rather a new development than a catch-up
<= div>
OK. Traditionally we've lagged a major release or tw= o from what's
officially supported by the project. Right now = the 10.x stuff is definitely
too old. The 11.x stuff is borderlin= e (but likely relevant), the 12.x stuff
is still quite relevant.<= br>

We need to look at who is updating. Many peopl= e have only recently
updated from 11. Almost everybody has update= d from 10 by now. Lots
of people are using 12 and it's still = supported.

Most of the folks that have source prod= ucts with lots of changes have
updated to at least 12 as far as I= 've been able to tell. But many haven't
jumped to 13 or c= urrent yet.

There are many people still updating t= heir VMs from 11. Traditionally, they
wait until after 11.x goes = unsupported before they update. It's only been
unsupported fo= r just over 1 year. In the past, this is where upgrading is
hitti= ng full speed (I've received feedback in the past at conferences that
people often put it off for up to 18 months)... 10.x has been unsu= pported
for more than 3 years, so historically everybody has move= d on. So the

I can't = do math.... More than 4 years...
=C2=A0
<= div>10.x entries are definitely stale... The 11 entries are on the edge...= =C2=A0 I'd
normally have removed the 10.x entries when 13 was= branched, but
I was asleep at the wheel this time.... Though loo= king at the logs, I've
been not so great about this. Better a= t some times, worse at others....

So in my opinion, 10.x entries should have alre= ady been gone. 11.x
entries are likely useful enough to keep, but= they are waning fast. 12.x
entries are likely being used all the= time by people upgrading from still-supported
releases. We'v= e traditionally weighted towards retention because the
cost of re= tention has been super low.

This suggests we delet= e up to the 11 branch point now, and to the 12
branch point when = 14 branches in 6 months or=C2=A0so...
13.x was branched about 6.5 years ago. When 14 is branched, it= will be
7 years and we'll removing the to the 12 branch poin= t which will be
four and half years. This seems like a good range= to oscillate between.

Warner
--00000000000010c4a005ee7f3dbf-- From nobody Mon Nov 28 06:34:45 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLG0l2CbQz4jFjB for ; Mon, 28 Nov 2022 06:34:47 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLG0l2012z4MFb for ; Mon, 28 Nov 2022 06:34:47 +0000 (UTC) (envelope-from netchild@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669617287; 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=aDtxaKi/4Nv9+qmLQmfItsYNBKebz9uN37pdlynvJq0=; b=FVLqnbBItRmWJFQFOpG4W8m+BbEAI/WktVjFijHgj3zzD7o76zY6dVPvX8M6PQzFiyMIfV Y82OE4mLCUIn1mvqPnhABaz0XgorWzQeY07ScfHo88AjzVpk6MQzRoY82qKO7OVRa1cPx2 jyw8rg+jHJWwcuRapEwxivBBPXKLjzxbP7+gs+7PJZ/VL1uN/LFAuUo6N7LndcIB6vKW30 WjH+RLXFvk53i+6b/FH/7RJiL1wB+3eG7tnUcxWK7lamcilIexi01E4n3/XKxLRmAJbgc1 QnkWp2lpu76+7waHdgO07JbB+ZDvkWly7k2g0rOmLLY6xAujd39mVu/E1r2X5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669617287; 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=aDtxaKi/4Nv9+qmLQmfItsYNBKebz9uN37pdlynvJq0=; b=yX3YhqRQlg+VNdCXiZ+byCUG5at5QSXF2Pkp+eSaCqNPKTMbxtyRf+EtEgn4sfg5rPnLMh aNlBnw6kpwAJ26BWMWqCPbvASLE+WBAhGHlYn6gEWVxaARVqdPPxDV5sy0yq1Mb/yv86ok ttrFDIZklZyUIYkDg5XE6xW4HtksBRjves7AjkMLZix6h7ps21j/6QIesyp0At4iB8wduE SERNTawjGa3j7cAYLK471O7zg3jxvMYURUzzqnJhFUGgxu3Z+9MmQ09tBCC2sikDz0+iOx UDY6Yb35FmknyVJi+xkID04VIHtsMbbt6LWEqUt5VVyjX+gvrJgfGNST6J1nJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669617287; a=rsa-sha256; cv=none; b=OgmcV65p0vx1lxYXFzZASjp6X9RgO09twfcoNvlpydachvsJp1NYRujwnQQ5PwcV+8aHqr yykO0BxvniySKcMnJ3ZJXJwp45vuWiwEMkRfIOzld0Df8CvNEvBJRm2ZR1ogqlGcmhGLba NBxtyfKWtZBtI1+TOMfreKuFVZEFu9h15Gl9oqJ2Ous4drVIJ4GmOzcj5CxcIQbCnDqbIC S7a2y1dAM00wdFk3roHXGiUOA+RYQUA7W48fUvIULZvFeuFEhjHgD/3aHqUyLahtq1G87I 97zchFnNsnEVKKUXgjq6FLI/lCbabzsJICmpUWnfxD4fkg66oOuXCd/PeDaM2w== Received: from outgoing.leidinger.net (p5b165cc5.dip0.t-ipconnect.de [91.22.92.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) (Authenticated sender: netchild) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NLG0k5SRzz10Q7 for ; Mon, 28 Nov 2022 06:34:46 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from webmail.leidinger.net (localhost [127.0.0.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 48C7C3725 for ; Mon, 28 Nov 2022 07:34:45 +0100 (CET) Received: from www (uid 80) (envelope-from netchild@freebsd.org) id 973a7 by webmail.leidinger.net (DragonFly Mail Agent v0.13+ on webmail.leidinger.net); Mon, 28 Nov 2022 07:34:45 +0100 Date: Mon, 28 Nov 2022 07:34:45 +0100 Message-ID: <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> From: Alexander Leidinger To: Warner Losh Cc: freebsd-arch@freebsd.org Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_f5TKObAqox9-yUs7xdpdxiJ"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_f5TKObAqox9-yUs7xdpdxiJ Content-Type: multipart/alternative; boundary="=_X7mvh9gX9Jvp14GBBpwWt-V" This message is in MIME format. --=_X7mvh9gX9Jvp14GBBpwWt-V Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Description: Textnachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Warner Losh (from Sun, 27 Nov 2022 20:12:08 -070= 0): > =C2=A0 > > On Sun, Nov 27, 2022 at 7:17 PM Warner Losh wrote= : > >> =C2=A0 >> >> On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger=20=20 >>=20 wrote: >> >>> Quoting Warner Losh (from Fri, 25 Nov 2022=20=20 >>>=2009:41:28 -0700): >>> >>>> Please revert this. We keep older updating entries on purpose. You pur= ged >>>> way too much. Let's chat about how much to remove in arch@. They are f= or >>>> more than just source updates, so your reasoning is wrong. They are al= so >>>> there for users updating their products which can have a larger leap i= n >>>> time. We've traditionally kept closer to 5-10 years here for that reas= on. >>> >>> Reverted. >>> >>> UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit= =C2=A0 >>> excessive (more than 9 years of development work so far), isn't it? >> >> =C2=A0 >> Yes. It's about one release too old, maybe two. More on one=20=20 >>=20or two in a bit. >> =C2=A0 >> >>> I don't get the "more than just src updates" part. If we don't talk=C2= =A0 >>> about the source code, isn't src/UPATING not the wrong place to store= =C2=A0 >>> it? >> >> =C2=A0 >> More than just 'make buildworld updating' or ''updating a=20=20 >>=20system from src' >> is what I mean. >> =C2=A0 >> >>> In terms of updating products, I understand that updating them every 2= =C2=A0 >>> years may be a little bit expensive/excessive for some vendors, but=C2= =A0 >>> taking every UPDATING from every stable branch in-between doesn't look= =C2=A0 >>> too much time consuming to me. And compared to the huge amount of=C2=A0 >>> changes between N-2 and N... taking UPDATING from all stable branches= =C2=A0 >>> in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish,=C2=A0 >>> nearly 10 years is ... ugh ... a life-time or two in the computer=C2=A0 >>> world. If we look e.g. at the PlayStation (yes, just one of the=C2=A0 >>> products which has FreeBSD inside, but personally I consider it one of= =C2=A0 >>> the more stable ones than some network products which have a shorter=C2= =A0 >>> shelf-time than the PS-line from an OS-version-tracking point of=C2=A0 >>> view), there are around 6 years in-between models, and they surely=C2= =A0 >>> haven't started developing a month before the release date. >> >> =C2=A0 >> So, let's look at what it's used for to see how much we need. If = you >> look at it that way, you'll see that we're not crazy lagging. >> =C2=A0 >> >>> So where do we draw the line for UPDATING, 2 major versions (~4=C2=A0 >>> years), 3 major versions (~6 years)? ~10 years (~5 major versions)=C2= =A0 >>> looks overly excessive to me. That's not something you want to try to= =C2=A0 >>> catch up, that's rather a new development than a catch-up >> >> =C2=A0 >> OK. Traditionally we've lagged a major release or two from what's >> officially supported by the project. Right now the 10.x=20=20 >>=20stuff is definitely >> too old. The 11.x stuff is borderline (but likely relevant),=20= =20 >>=20the 12.x stuff >> is still quite relevant. >> =C2=A0 >> We need to look at who is updating. Many people have only recentl= y >> updated from 11. Almost everybody has updated from 10 by now. Lot= s >> of people are using 12 and it's still supported. >> =C2=A0 >> Most of the folks that have source products with lots of changes = have >> updated to at least 12 as far as I've been able to tell. But=20= =20 >>=20many haven't >> jumped to 13 or current yet. >> =C2=A0 >> There are many people still updating their VMs from 11.=20=20 >>=20Traditionally, they >> wait until after 11.x goes unsupported before they update.=20=20 >>=20It's only been >> unsupported for just over 1 year. In the past, this is where=20= =20 >>=20upgrading is >> hitting full speed (I've received feedback in the past at=20=20 >>=20conferences that >> people often put it off for up to 18 months)... 10.x has=20=20 >>=20been unsupported >> for more than 3 years, so historically everybody has moved on. So= the > > =C2=A0 > I can't do math.... More than 4 years... > =C2=A0 > >> 10.x entries are definitely stale... The 11 entries are on the edge...= =C2=A0 I'd >> normally have removed the 10.x entries when 13 was branched, but >> I was asleep at the wheel this time.... Though looking at=20=20 >>=20the logs, I've >> been not so great about this. Better at some times, worse at=20= =20 >>=20others.... > > =C2=A0 > >> So in my opinion, 10.x entries should have already been gone. 11.x >> entries are likely useful enough to keep, but they are=20=20 >>=20waning fast. 12.x >> entries are likely being used all the time by people=20=20 >>=20upgrading from still-supported >> releases. We've traditionally weighted towards retention because = the >> cost of retention has been super low. >> =C2=A0 >> This suggests we delete up to the 11 branch point now, and to the= 12 >> branch point when 14 branches in 6 months or=C2=A0so... > > =C2=A0 > 13.x was branched about 6.5 years ago. When 14 is branched, it will b= e > 7 years and we'll removing the to the 12 branch point which will be > four and half years. This seems like a good range to oscillate betwee= n. If I understand it correctly, you want to target a policy of: Just before the branch of stable/N we remove old entries from UPDATING=20= =20 and=20keep the data of N-2 branches =3D deleting the data of N-3. stable/14 -> keep 13+12 and delete 11. Basically we both are aligned and think N-2 is on the edge. I don't=20=20 mind=20to live with this edge... Do we want to document that somewhere? RE-tasklist? Inside UPDATING=20=20 (top=20or bottom)? What about removing the entries of 10? Now or with next branch? I=20=20 would=20vote to do it now, what's done is done. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_X7mvh9gX9Jvp14GBBpwWt-V Content-Type: text/html; charset=utf-8 Content-Description: HTML-Nachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Quoting Warner Losh <imp@bsdimp.com= > (from Sun, 27 Nov 2022 20:12:08 -0700):

 

On Sun, Nov 27, 2022 at 7:17 PM Warne= r Losh <imp@bsdimp.com> wrote:<= /div>
 

On Sun, Nov 27, 2022 at 2:35 PM Alexa= nder Leidinger <netchild@freebsd.org> wrote:

Quoting Warner Losh <imp@bsdimp.com> (from Fri, 25 Nov 2022 09:41:28 -0700):

> Please revert this. We keep older updating entries on purpose. You pur= ged
> way too much. Let's chat about how much to remove in arch@. They are f= or
> more than just source updates, so your reasoning is wrong. They are al= so
> there for users updating their products which can have a larger leap i= n
> time. We've traditionally kept closer to 5-10 years here for that reas= on.

Reverted.

UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit&nbs= p;
excessive (more than 9 years of development work so far), isn't it?

 
Yes. It's about one release too old, maybe two. More on one or two in = a bit.
 

I don't get the "more than just src updates" part. If we don't talk = ;
about the source code, isn't src/UPATING not the wrong place to store =
it?

 
More than just 'make buildworld updating' or ''updating a system from = src'
is what I mean.
 

In terms of updating products, I understand that updating them every 2&n= bsp;
years may be a little bit expensive/excessive for some vendors, but  taking every UPDATING from every stable branch in-between doesn't look = ;
too much time consuming to me. And compared to the huge amount of 
changes between N-2 and N... taking UPDATING from all stable branches =
in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish, 
nearly 10 years is ... ugh ... a life-time or two in the computer 
world. If we look e.g. at the PlayStation (yes, just one of the 
products which has FreeBSD inside, but personally I consider it one of = ;
the more stable ones than some network products which have a shorter <= br> shelf-time than the PS-line from an OS-version-tracking point of 
view), there are around 6 years in-between models, and they surely  haven't started developing a month before the release date.

 
So, let's look at what it's used for to see how much we need. If you
look at it that way, you'll see that we're not crazy lagging.
 

So where do we draw the line for UPDATING, 2 major versions (~4  years), 3 major versions (~6 years)? ~10 years (~5 major versions)  looks overly excessive to me. That's not something you want to try to =
catch up, that's rather a new development than a catch-up

 
OK. Traditionally we've lagged a major release or two from what's
officially supported by the project. Right now the 10.x stuff is defin= itely
too old. The 11.x stuff is borderline (but likely relevant), the 12.x = stuff
is still quite relevant.
 
We need to look at who is updating. Many people have only recently
updated from 11. Almost everybody has updated from 10 by now. Lots
of people are using 12 and it's still supported.
 
Most of the folks that have source products with lots of changes have<= /div>
updated to at least 12 as far as I've been able to tell. But many have= n't
jumped to 13 or current yet.
 
There are many people still updating their VMs from 11. Traditionally,= they
wait until after 11.x goes unsupported before they update. It's only b= een
unsupported for just over 1 year. In the past, this is where upgrading= is
hitting full speed (I've received feedback in the past at conferences = that
people often put it off for up to 18 months)... 10.x has been unsuppor= ted
for more than 3 years, so historically everybody has moved on. So the<= /div>
 
I can't do math.... More than 4 years...
 
10.x entries are definitely stale... The 11 entries are on the edge...=   I'd
normally have removed the 10.x entries when 13 was branched, but
I was asleep at the wheel this time.... Though looking at the logs, I'= ve
been not so great about this. Better at some times, worse at others...= .
 
So in my opinion, 10.x entries should have already been gone. 11.x
entries are likely useful enough to keep, but they are waning fast. 12= .x
entries are likely being used all the time by people upgrading from st= ill-supported
releases. We've traditionally weighted towards retention because the
cost of retention has been super low.
 
This suggests we delete up to the 11 branch point now, and to the 12
branch point when 14 branches in 6 months or so...
 
13.x was branched about 6.5 years ago. When 14 is branched, it will be=
7 years and we'll removing the to the 12 branch point which will be
four and half years. This seems like a good range to oscillate between= .


If I understand it correctly, you want to target a policy of:
Just before the branch of stable/N we remove old entries from UPDATING and = keep the data of N-2 branches =3D deleting the data of N-3.

stable/14 -> keep 13+12 and delete 11.

Basically we both are aligned and think N-2 is on the edge. I don't mind to= live with this edge...

Do we want to document that somewhere? RE-tasklist? Inside UPDATING (top or= bottom)?

What about removing the entries of 10? Now or with next branch? I would vot= e to do it now, what's done is done.

Bye,
Alexander.

--=_X7mvh9gX9Jvp14GBBpwWt-V-- --=_f5TKObAqox9-yUs7xdpdxiJ Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmOEVoQACgkQEg2wmwP4 2IYWvw//UPS4D/avmOXW6SzXFMvv9y5n0KqDhr3vhp8iQn1suDV3AhBStvc7yhlm iDV4OiOrfbLJ91/eaBWsxvo3VXGacYI6G3iMJtQY7+8mqbYrVQfaa5oVzg/52QFc dJ0FH5vKGqkXv72ggEzcaXtDlD0koBq4tf9zY45tgmqeyFNZuSGhkc/ZIUqZS8EM 3agTqDvtD6QCLStDzUHeiL/RMGDv4lEQN+kH4MALYO3Vbi2KzrFFMLsy+171y6ZJ 48lzHgPYL3oCwDS9zFZpD/J2sFeOsNdj7V2OzwunKUBO0XmGOvuiUvmOe/1+4BYQ qe05XYgok6eNGLLnoNGrQHSFV0HXCyA3KjgzNy8ABJNenGHNcQwXDIe3KLWHmsdr cpEzf0EOKnPsgzxVlix7wHONBdj4NY0cmfiNufXisIVEOtOO7UvEXpZRviJ2i0ig 90iNnoaRRYQjNrQ497XxMNvYEPp37aV0ncjPJFNIg8DLcE9ybytrFl/RgA+fxU7H MijNFSRL7syDOm04o9ReF/sW/uA99c7MEcEjWc6t8jF0ycky8FDpJoXEJD/klQ7s aQDKbItH6sgQLplfHnLAGeTEsFV3NNRL8MDsLoCxuiuD8S8oJ5rxSaZzVisFaD6y 9s99VwSdamcw3p+ED6NH/3NHT/TjhLhVSDSbQM1uedLRxPvnOWA= =0k0x -----END PGP SIGNATURE----- --=_f5TKObAqox9-yUs7xdpdxiJ-- From nobody Mon Nov 28 07:20:49 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLH260dmNz4jMmP for ; Mon, 28 Nov 2022 07:21:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLH255q7Kz4Ryr for ; Mon, 28 Nov 2022 07:21:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x636.google.com with SMTP id fy37so23457571ejc.11 for ; Sun, 27 Nov 2022 23:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=B9VaEXJWTE70GJIa9SxM+o1tELXfxgJ4Jrf7H/iFyR0=; b=4xxZ626uD6/eHKFisITZMcw7Pl5DF/Bt1RYmjLRpPvqYqH55lIpwkykt9jUqUwb8zC 2LHh3iE5t0Y8bMcgK8dElZ5Fn5bLOWRjm6B+7+czXVrW25VuX1X1G12/y1YxCuUgu4ay 2/U+4+Ytx6wvoQipP3LDuIZ6BQSJtaR2//37u07Gmi7FlF5L3ktjPwK3KLxwoRDYBDLw /fDeZVED/3z9LTns9PzODZnOVpFPs7akBJBk4Uf9jrGFMEiR5uM+uFN4Duurt5zKtHsk O1lroc3FIT/iPAg8tOT7d0qeEad41CgjFVpdaNuZoOe8fvAV2BsEBAaJnqOd0B4aYT7d kUPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=B9VaEXJWTE70GJIa9SxM+o1tELXfxgJ4Jrf7H/iFyR0=; b=E0bo1sfFzkoO/i9IcVgqZpQDj45YSPsLwUEytUyA80R8mzdvsH7Q/ZEyHXw4TpoN0g /fXClT0ZulhTvp1BoVp1uSdIa0XlZ5FSiMlpEnAg2/x8xG53+ABTkFhUU9Uy4nVEmBVZ GpmIBiBwpoJlqag3TC6j0Hvp3UPYrN6Mqux33DbWznzaaAvgR35qta77mWuFANxTH+wl qUEIS3FkFgSJTqKfD3L+kaDnE/hK04xz4qtm+ql1ixh6bPsyPnlz/qwhWAeV1cbZxyNd 653Ln2XpgWJ4PkdenMV80LZ00wlU9ZPhw/8teUEmdHZp+y9R+KxLcnRn2cqjAOTcnC2A DBLg== X-Gm-Message-State: ANoB5pkjR6K8BXBUv1IiEiiQb5Qff1nj4tjne6sTJOKBPspLbYuvbJjp Rdqeres49o5S5fZN+FJelrp5rzVFaT6ufaXt/bc2qaUxpiY= X-Google-Smtp-Source: AA0mqf7mSg4JdN9/4GpsCpnMmRJ8OhtbN3F1wS6hODmXJNIP7SoNXvZ3av5yGFrPORz7iTYyJ9Y7okI1nW+qaxNgREw= X-Received: by 2002:a17:907:206f:b0:7bb:cc6b:86d6 with SMTP id qp15-20020a170907206f00b007bbcc6b86d6mr15046560ejb.252.1669620060273; Sun, 27 Nov 2022 23:21:00 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> In-Reply-To: <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> From: Warner Losh Date: Mon, 28 Nov 2022 00:20:49 -0700 Message-ID: Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) To: Alexander Leidinger Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009a4f5705ee82b6c2" X-Rspamd-Queue-Id: 4NLH255q7Kz4Ryr X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000009a4f5705ee82b6c2 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 27, 2022 at 11:34 PM Alexander Leidinger wrote: > Quoting Warner Losh (from Sun, 27 Nov 2022 20:12:08 > -0700): > > > > On Sun, Nov 27, 2022 at 7:17 PM Warner Losh wrote: > >> >> >> On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger >> wrote: >> >>> Quoting Warner Losh (from Fri, 25 Nov 2022 09:41:28 >>> -0700): >>> >>> > Please revert this. We keep older updating entries on purpose. You >>> purged >>> > way too much. Let's chat about how much to remove in arch@. They are >>> for >>> > more than just source updates, so your reasoning is wrong. They are >>> also >>> > there for users updating their products which can have a larger leap in >>> > time. We've traditionally kept closer to 5-10 years here for that >>> reason. >>> >>> Reverted. >>> >>> UPDATING as far back as stable/10 (= 4 major updates) is a little bit >>> excessive (more than 9 years of development work so far), isn't it? >>> >> >> Yes. It's about one release too old, maybe two. More on one or two in a >> bit. >> >> >>> I don't get the "more than just src updates" part. If we don't talk >>> about the source code, isn't src/UPATING not the wrong place to store >>> it? >>> >> >> More than just 'make buildworld updating' or ''updating a system from src' >> is what I mean. >> >> >>> In terms of updating products, I understand that updating them every 2 >>> years may be a little bit expensive/excessive for some vendors, but >>> taking every UPDATING from every stable branch in-between doesn't look >>> too much time consuming to me. And compared to the huge amount of >>> changes between N-2 and N... taking UPDATING from all stable branches >>> in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish, >>> nearly 10 years is ... ugh ... a life-time or two in the computer >>> world. If we look e.g. at the PlayStation (yes, just one of the >>> products which has FreeBSD inside, but personally I consider it one of >>> the more stable ones than some network products which have a shorter >>> shelf-time than the PS-line from an OS-version-tracking point of >>> view), there are around 6 years in-between models, and they surely >>> haven't started developing a month before the release date. >>> >> >> So, let's look at what it's used for to see how much we need. If you >> look at it that way, you'll see that we're not crazy lagging. >> >> >>> So where do we draw the line for UPDATING, 2 major versions (~4 >>> years), 3 major versions (~6 years)? ~10 years (~5 major versions) >>> looks overly excessive to me. That's not something you want to try to >>> catch up, that's rather a new development than a catch-up >>> >> >> OK. Traditionally we've lagged a major release or two from what's >> officially supported by the project. Right now the 10.x stuff is >> definitely >> too old. The 11.x stuff is borderline (but likely relevant), the 12.x >> stuff >> is still quite relevant. >> >> We need to look at who is updating. Many people have only recently >> updated from 11. Almost everybody has updated from 10 by now. Lots >> of people are using 12 and it's still supported. >> >> Most of the folks that have source products with lots of changes have >> updated to at least 12 as far as I've been able to tell. But many haven't >> jumped to 13 or current yet. >> >> There are many people still updating their VMs from 11. Traditionally, >> they >> wait until after 11.x goes unsupported before they update. It's only been >> unsupported for just over 1 year. In the past, this is where upgrading is >> hitting full speed (I've received feedback in the past at conferences that >> people often put it off for up to 18 months)... 10.x has been unsupported >> for more than 3 years, so historically everybody has moved on. So the >> > > I can't do math.... More than 4 years... > > >> 10.x entries are definitely stale... The 11 entries are on the edge... >> I'd >> normally have removed the 10.x entries when 13 was branched, but >> I was asleep at the wheel this time.... Though looking at the logs, I've >> been not so great about this. Better at some times, worse at others.... >> > > >> So in my opinion, 10.x entries should have already been gone. 11.x >> entries are likely useful enough to keep, but they are waning fast. 12.x >> entries are likely being used all the time by people upgrading from >> still-supported >> releases. We've traditionally weighted towards retention because the >> cost of retention has been super low. >> >> This suggests we delete up to the 11 branch point now, and to the 12 >> branch point when 14 branches in 6 months or so... >> > > 13.x was branched about 6.5 years ago. When 14 is branched, it will be > 7 years and we'll removing the to the 12 branch point which will be > four and half years. This seems like a good range to oscillate between. > > > If I understand it correctly, you want to target a policy of: > Just before the branch of stable/N we remove old entries from UPDATING and > keep the data of N-2 branches = deleting the data of N-3. > > stable/14 -> keep 13+12 and delete 11. > > Basically we both are aligned and think N-2 is on the edge. I don't mind > to live with this edge... > > Do we want to document that somewhere? RE-tasklist? Inside UPDATING (top > or bottom)? > > What about removing the entries of 10? Now or with next branch? I would > vote to do it now, what's done is done. > I think we should remove entries before the 11 branch now. I'll create a review with that. Warner --0000000000009a4f5705ee82b6c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 27, 2022 at 11:34 PM Alex= ander Leidinger <netchild@freebs= d.org> wrote:

Quoting Warner Losh <imp@bsdimp.com> (from Sun, 27 Nov 2022 20:12:08 -0700):

=C2=A0

On Sun, Nov 27, 2022 at 7:17 PM Warne= r Losh <imp@bsdimp.c= om> wrote:
=C2=A0

On Sun, Nov 27, 2022 at 2:35 PM Alexa= nder Leidinger <netchild@freebsd.org> wrote:

Quoting Warner Losh <imp@bsdimp.com> (from Fri, 25 Nov 2022 09:41:28 -0700):

> Please revert this. We keep older updating entries on purpose. You pur= ged
> way too much. Let's chat about how much to remove in arch@. They a= re for
> more than just source updates, so your reasoning is wrong. They are al= so
> there for users updating their products which can have a larger leap i= n
> time. We've traditionally kept closer to 5-10 years here for that = reason.

Reverted.

UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit=C2= =A0
excessive (more than 9 years of development work so far), isn't it?

=C2=A0
Yes. It's about one release too old, maybe two. More on one or two= in a bit.
=C2=A0

I don't get the "more than just src updates" part. If we d= on't talk=C2=A0
about the source code, isn't src/UPATING not the wrong place to store= =C2=A0
it?

=C2=A0
More than just 'make buildworld updating' or ''updatin= g a system from src'
is what I mean.
=C2=A0

In terms of updating products, I understand that updating them every 2= =C2=A0
years may be a little bit expensive/excessive for some vendors, but=C2=A0 taking every UPDATING from every stable branch in-between doesn't look= =C2=A0
too much time consuming to me. And compared to the huge amount of=C2=A0
changes between N-2 and N... taking UPDATING from all stable branches=C2=A0=
in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish,=C2=A0
nearly 10 years is ... ugh ... a life-time or two in the computer=C2=A0
world. If we look e.g. at the PlayStation (yes, just one of the=C2=A0
products which has FreeBSD inside, but personally I consider it one of=C2= =A0
the more stable ones than some network products which have a shorter=C2=A0<= br> shelf-time than the PS-line from an OS-version-tracking point of=C2=A0
view), there are around 6 years in-between models, and they surely=C2=A0 haven't started developing a month before the release date.

=C2=A0
So, let's look at what it's used for to see how much we need. = If you
look at it that way, you'll see that we're not crazy lagging.<= /div>
=C2=A0

So where do we draw the line for UPDATING, 2 major versions (~4=C2=A0 years), 3 major versions (~6 years)? ~10 years (~5 major versions)=C2=A0 looks overly excessive to me. That's not something you want to try to= =C2=A0
catch up, that's rather a new development than a catch-up

=C2=A0
OK. Traditionally we've lagged a major release or two from what= 9;s
officially supported by the project. Right now the 10.x stuff is defin= itely
too old. The 11.x stuff is borderline (but likely relevant), the 12.x = stuff
is still quite relevant.
=C2=A0
We need to look at who is updating. Many people have only recently
updated from 11. Almost everybody has updated from 10 by now. Lots
of people are using 12 and it's still supported.
=C2=A0
Most of the folks that have source products with lots of changes have<= /div>
updated to at least 12 as far as I've been able to tell. But many = haven't
jumped to 13 or current yet.
=C2=A0
There are many people still updating their VMs from 11. Traditionally,= they
wait until after 11.x goes unsupported before they update. It's on= ly been
unsupported for just over 1 year. In the past, this is where upgrading= is
hitting full speed (I've received feedback in the past at conferen= ces that
people often put it off for up to 18 months)... 10.x has been unsuppor= ted
for more than 3 years, so historically everybody has moved on. So the<= /div>
=C2=A0
I can't do math.... More than 4 years...
=C2=A0
10.x entries are definitely stale... The 11 entries are on the edge...= =C2=A0 I'd
normally have removed the 10.x entries when 13 was branched, but
I was asleep at the wheel this time.... Though looking at the logs, I&= #39;ve
been not so great about this. Better at some times, worse at others...= .
=C2=A0
So in my opinion, 10.x entries should have already been gone. 11.x
entries are likely useful enough to keep, but they are waning fast. 12= .x
entries are likely being used all the time by people upgrading from st= ill-supported
releases. We've traditionally weighted towards retention because t= he
cost of retention has been super low.
=C2=A0
This suggests we delete up to the 11 branch point now, and to the 12
branch point when 14 branches in 6 months or=C2=A0so...
=C2=A0
13.x was branched about 6.5 years ago. When 14 is branched, it will be=
7 years and we'll removing the to the 12 branch point which will b= e
four and half years. This seems like a good range to oscillate between= .


If I understand it correctly, you want to target a policy of:
Just before the branch of stable/N we remove old entries from UPDATING and = keep the data of N-2 branches =3D deleting the data of N-3.

stable/14 -> keep 13+12 and delete 11.

Basically we both are aligned and think N-2 is on the edge. I don't min= d to live with this edge...

Do we want to document that somewhere? RE-tasklist? Inside UPDATING (top or= bottom)?

What about removing the entries of 10? Now or with next branch? I would vot= e to do it now, what's done is done.


I think we should remove entries before the 11 branch now. I'll= create a review with that.

Warner
--0000000000009a4f5705ee82b6c2-- From nobody Mon Nov 28 07:38:24 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLHQK67CMz4jPTq for ; Mon, 28 Nov 2022 07:38:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLHQJ6LgLz4TYw for ; Mon, 28 Nov 2022 07:38:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=hBg39haA; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62a) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x62a.google.com with SMTP id td2so9480634ejc.5 for ; Sun, 27 Nov 2022 23:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TOGAppEscx4TjfZqC1eIi/BjiI/LVqPbF6HAvOsy9Lw=; b=hBg39haA7UcczCZ2v/0GTjv3g/L2p44mwqOPLu3C4KG3uolrt9XhHeYoSasiR6aW2j eNgr5nBc89ZiDAeDz7le6+vjVo+2IZDGUQHOh8cRqWU2TlKnVhbaJ2G/lK8GnBivOm7+ nYNeVei0PsLUq4/KLUfmk667fYlrsn7M+m21nVvZnR44DqH8sCKn4b6VY2fvGn9bVTIe R2xksqcxodXoWAhjf9LyQ8wjENIZsr7dtyKBRyEFZ4Ew6JYGBS5tcca/zUXrYdki1Gws 7EZN78p+FwORGOlKRnIEEYUGjR6w+vx1IbGeuLeUoBdbos6WKIvdgtmT8Cy/7i2ZHJXy VRuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=TOGAppEscx4TjfZqC1eIi/BjiI/LVqPbF6HAvOsy9Lw=; b=LBZuO//1J28ZmCzMcgoHwXOMVJIYjjUoxhaz39U1u/0FtqEZOeOpm+r5h3UbS/2mWS PlT2iGcd+8Mct81ESM5SoKpyPJKOXkEZwlPFW3rcdbxdAaK5oFGeBz1lLEIuGApgQMVx L4A5O4Pdlu6qkaQ5BrKCoqLgYDSkGN072LYLhV+7KoQ2U7+hGZec471hEDpajmbS2Q4e U7hgSa1nvI+ImlviYGH3GT1oB47jUbHSOtkmsNOeXmgdaTCj//ySZfoZ5ZY7mMw64gNe UvWrcOVaFg16R7rbL3DYx8CxzYLCGMM6pEWflcM4E3wFgaoeqpZ41ogb7hcvSSd0IyII +i/w== X-Gm-Message-State: ANoB5plzqkygH3CNNYnC4Aqe/I6AKrhvPtWyaR6Hcuu/SFr7Nhviq4wo kokCicLjn7gqTTSLGibyHiA4xHDVfhdg1x0omBt+kO15DHCnMw== X-Google-Smtp-Source: AA0mqf7HuB2w5zI+Uu1+Cj6e57y0+W1VskbB7edxGka9wyxoBIh620R0W6C05HreUeU6dKIIlBr/HYs/rIvvRuWxQNE= X-Received: by 2002:a17:907:206f:b0:7bb:cc6b:86d6 with SMTP id qp15-20020a170907206f00b007bbcc6b86d6mr15092020ejb.252.1669621111432; Sun, 27 Nov 2022 23:38:31 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> <20221128073445.Horde.UA46E1-_SRAS-yFXkM8r5q7@webmail.leidinger.net> In-Reply-To: From: Warner Losh Date: Mon, 28 Nov 2022 00:38:24 -0700 Message-ID: Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) To: Alexander Leidinger Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000041bc3d05ee82f5b5" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NLHQJ6LgLz4TYw X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000041bc3d05ee82f5b5 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 28, 2022 at 12:20 AM Warner Losh wrote: > > > On Sun, Nov 27, 2022 at 11:34 PM Alexander Leidinger > wrote: > >> Quoting Warner Losh (from Sun, 27 Nov 2022 20:12:08 >> -0700): >> >> >> >> On Sun, Nov 27, 2022 at 7:17 PM Warner Losh wrote: >> >>> >>> >>> On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger < >>> netchild@freebsd.org> wrote: >>> >>>> Quoting Warner Losh (from Fri, 25 Nov 2022 09:41:28 >>>> -0700): >>>> >>>> > Please revert this. We keep older updating entries on purpose. You >>>> purged >>>> > way too much. Let's chat about how much to remove in arch@. They are >>>> for >>>> > more than just source updates, so your reasoning is wrong. They are >>>> also >>>> > there for users updating their products which can have a larger leap >>>> in >>>> > time. We've traditionally kept closer to 5-10 years here for that >>>> reason. >>>> >>>> Reverted. >>>> >>>> UPDATING as far back as stable/10 (= 4 major updates) is a little bit >>>> excessive (more than 9 years of development work so far), isn't it? >>>> >>> >>> Yes. It's about one release too old, maybe two. More on one or two in a >>> bit. >>> >>> >>>> I don't get the "more than just src updates" part. If we don't talk >>>> about the source code, isn't src/UPATING not the wrong place to store >>>> it? >>>> >>> >>> More than just 'make buildworld updating' or ''updating a system from >>> src' >>> is what I mean. >>> >>> >>>> In terms of updating products, I understand that updating them every 2 >>>> years may be a little bit expensive/excessive for some vendors, but >>>> taking every UPDATING from every stable branch in-between doesn't look >>>> too much time consuming to me. And compared to the huge amount of >>>> changes between N-2 and N... taking UPDATING from all stable branches >>>> in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish, >>>> nearly 10 years is ... ugh ... a life-time or two in the computer >>>> world. If we look e.g. at the PlayStation (yes, just one of the >>>> products which has FreeBSD inside, but personally I consider it one of >>>> the more stable ones than some network products which have a shorter >>>> shelf-time than the PS-line from an OS-version-tracking point of >>>> view), there are around 6 years in-between models, and they surely >>>> haven't started developing a month before the release date. >>>> >>> >>> So, let's look at what it's used for to see how much we need. If you >>> look at it that way, you'll see that we're not crazy lagging. >>> >>> >>>> So where do we draw the line for UPDATING, 2 major versions (~4 >>>> years), 3 major versions (~6 years)? ~10 years (~5 major versions) >>>> looks overly excessive to me. That's not something you want to try to >>>> catch up, that's rather a new development than a catch-up >>>> >>> >>> OK. Traditionally we've lagged a major release or two from what's >>> officially supported by the project. Right now the 10.x stuff is >>> definitely >>> too old. The 11.x stuff is borderline (but likely relevant), the 12.x >>> stuff >>> is still quite relevant. >>> >>> We need to look at who is updating. Many people have only recently >>> updated from 11. Almost everybody has updated from 10 by now. Lots >>> of people are using 12 and it's still supported. >>> >>> Most of the folks that have source products with lots of changes have >>> updated to at least 12 as far as I've been able to tell. But many haven't >>> jumped to 13 or current yet. >>> >>> There are many people still updating their VMs from 11. Traditionally, >>> they >>> wait until after 11.x goes unsupported before they update. It's only been >>> unsupported for just over 1 year. In the past, this is where upgrading is >>> hitting full speed (I've received feedback in the past at conferences >>> that >>> people often put it off for up to 18 months)... 10.x has been unsupported >>> for more than 3 years, so historically everybody has moved on. So the >>> >> >> I can't do math.... More than 4 years... >> >> >>> 10.x entries are definitely stale... The 11 entries are on the edge... >>> I'd >>> normally have removed the 10.x entries when 13 was branched, but >>> I was asleep at the wheel this time.... Though looking at the logs, I've >>> been not so great about this. Better at some times, worse at others.... >>> >> >> >>> So in my opinion, 10.x entries should have already been gone. 11.x >>> entries are likely useful enough to keep, but they are waning fast. 12.x >>> entries are likely being used all the time by people upgrading from >>> still-supported >>> releases. We've traditionally weighted towards retention because the >>> cost of retention has been super low. >>> >>> This suggests we delete up to the 11 branch point now, and to the 12 >>> branch point when 14 branches in 6 months or so... >>> >> >> 13.x was branched about 6.5 years ago. When 14 is branched, it will be >> 7 years and we'll removing the to the 12 branch point which will be >> four and half years. This seems like a good range to oscillate between. >> >> >> If I understand it correctly, you want to target a policy of: >> Just before the branch of stable/N we remove old entries from UPDATING >> and keep the data of N-2 branches = deleting the data of N-3. >> >> stable/14 -> keep 13+12 and delete 11. >> >> Basically we both are aligned and think N-2 is on the edge. I don't mind >> to live with this edge... >> >> Do we want to document that somewhere? RE-tasklist? Inside UPDATING (top >> or bottom)? >> >> What about removing the entries of 10? Now or with next branch? I would >> vote to do it now, what's done is done. >> > > I think we should remove entries before the 11 branch now. I'll create a > review with that. > https://reviews.freebsd.org/D37514 has the changes for UPDATING. We likely should document this in the RE-tasklis, with the caveat that the sequence is 'create a new branch, trim UPDATING in -current only' rather than the opposite to the stable/XX branch has the older data. I think I trimmed the right amount. We likely should also have $SOMEBODY review the build / updating / etc instructions at each release so we can keep them up to date as well as technology evolves. Warner --00000000000041bc3d05ee82f5b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 28, 2022 at 12:20 AM Warn= er Losh <imp@bsdimp.com> wrote:=


On Sun, Nov 27, 2022 at 11:34 PM Alexander Leidinger= <netchild@fre= ebsd.org> wrote:

Quoting Warner Losh <imp@bsdimp.com> (from Sun, 27 Nov 2022 20:12:08 -0700):

=C2=A0

On Sun, Nov 27, 2022 at 7:17 PM Warne= r Losh <imp@bsdimp.c= om> wrote:
=C2=A0

On Sun, Nov 27, 2022 at 2:35 PM Alexa= nder Leidinger <netchild@freebsd.org> wrote:

Quoting Warner Losh <imp@bsdimp.com> (from Fri, 25 Nov 2022 09:41:28 -0700):

> Please revert this. We keep older updating entries on purpose. You pur= ged
> way too much. Let's chat about how much to remove in arch@. They a= re for
> more than just source updates, so your reasoning is wrong. They are al= so
> there for users updating their products which can have a larger leap i= n
> time. We've traditionally kept closer to 5-10 years here for that = reason.

Reverted.

UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit=C2= =A0
excessive (more than 9 years of development work so far), isn't it?

=C2=A0
Yes. It's about one release too old, maybe two. More on one or two= in a bit.
=C2=A0

I don't get the "more than just src updates" part. If we d= on't talk=C2=A0
about the source code, isn't src/UPATING not the wrong place to store= =C2=A0
it?

=C2=A0
More than just 'make buildworld updating' or ''updatin= g a system from src'
is what I mean.
=C2=A0

In terms of updating products, I understand that updating them every 2= =C2=A0
years may be a little bit expensive/excessive for some vendors, but=C2=A0 taking every UPDATING from every stable branch in-between doesn't look= =C2=A0
too much time consuming to me. And compared to the huge amount of=C2=A0
changes between N-2 and N... taking UPDATING from all stable branches=C2=A0=
in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish,=C2=A0
nearly 10 years is ... ugh ... a life-time or two in the computer=C2=A0
world. If we look e.g. at the PlayStation (yes, just one of the=C2=A0
products which has FreeBSD inside, but personally I consider it one of=C2= =A0
the more stable ones than some network products which have a shorter=C2=A0<= br> shelf-time than the PS-line from an OS-version-tracking point of=C2=A0
view), there are around 6 years in-between models, and they surely=C2=A0 haven't started developing a month before the release date.

=C2=A0
So, let's look at what it's used for to see how much we need. = If you
look at it that way, you'll see that we're not crazy lagging.<= /div>
=C2=A0

So where do we draw the line for UPDATING, 2 major versions (~4=C2=A0 years), 3 major versions (~6 years)? ~10 years (~5 major versions)=C2=A0 looks overly excessive to me. That's not something you want to try to= =C2=A0
catch up, that's rather a new development than a catch-up

=C2=A0
OK. Traditionally we've lagged a major release or two from what= 9;s
officially supported by the project. Right now the 10.x stuff is defin= itely
too old. The 11.x stuff is borderline (but likely relevant), the 12.x = stuff
is still quite relevant.
=C2=A0
We need to look at who is updating. Many people have only recently
updated from 11. Almost everybody has updated from 10 by now. Lots
of people are using 12 and it's still supported.
=C2=A0
Most of the folks that have source products with lots of changes have<= /div>
updated to at least 12 as far as I've been able to tell. But many = haven't
jumped to 13 or current yet.
=C2=A0
There are many people still updating their VMs from 11. Traditionally,= they
wait until after 11.x goes unsupported before they update. It's on= ly been
unsupported for just over 1 year. In the past, this is where upgrading= is
hitting full speed (I've received feedback in the past at conferen= ces that
people often put it off for up to 18 months)... 10.x has been unsuppor= ted
for more than 3 years, so historically everybody has moved on. So the<= /div>
=C2=A0
I can't do math.... More than 4 years...
=C2=A0
10.x entries are definitely stale... The 11 entries are on the edge...= =C2=A0 I'd
normally have removed the 10.x entries when 13 was branched, but
I was asleep at the wheel this time.... Though looking at the logs, I&= #39;ve
been not so great about this. Better at some times, worse at others...= .
=C2=A0
So in my opinion, 10.x entries should have already been gone. 11.x
entries are likely useful enough to keep, but they are waning fast. 12= .x
entries are likely being used all the time by people upgrading from st= ill-supported
releases. We've traditionally weighted towards retention because t= he
cost of retention has been super low.
=C2=A0
This suggests we delete up to the 11 branch point now, and to the 12
branch point when 14 branches in 6 months or=C2=A0so...
=C2=A0
13.x was branched about 6.5 years ago. When 14 is branched, it will be=
7 years and we'll removing the to the 12 branch point which will b= e
four and half years. This seems like a good range to oscillate between= .


If I understand it correctly, you want to target a policy of:
Just before the branch of stable/N we remove old entries from UPDATING and = keep the data of N-2 branches =3D deleting the data of N-3.

stable/14 -> keep 13+12 and delete 11.

Basically we both are aligned and think N-2 is on the edge. I don't min= d to live with this edge...

Do we want to document that somewhere? RE-tasklist? Inside UPDATING (top or= bottom)?

What about removing the entries of 10? Now or with next branch? I would vot= e to do it now, what's done is done.


I think we should remove entries before the 11 branch now. I'll= create a review with that.

https://reviews.freebsd.o= rg/D37514

has the changes for UPDATING. We lik= ely should document this in the RE-tasklis, with the caveat that the sequen= ce is 'create a new branch, trim UPDATING in -current only' rather = than the opposite to the stable/XX branch has the older data.
I think I trimmed the right amount.

We= likely should also have $SOMEBODY review the build / updating / etc instru= ctions at each release so we can keep them up to date as well as technology= evolves.

Warner
--00000000000041bc3d05ee82f5b5-- From nobody Mon Nov 28 09:21:50 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLKjl3rpKz4jdg7 for ; Mon, 28 Nov 2022 09:22:03 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLKjj0Xd8z4d2h for ; Mon, 28 Nov 2022 09:22:00 +0000 (UTC) (envelope-from hps@selasky.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org; dmarc=none Received: from [10.36.2.69] (unknown [84.210.222.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 549A126019B; Mon, 28 Nov 2022 10:21:53 +0100 (CET) Message-ID: Date: Mon, 28 Nov 2022 10:21:50 +0100 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [RFC] Proposal adding new sorting algorithm, bsort() to libc From: Hans Petter Selasky To: Robert Clausecker , "freebsd-arch@freebsd.org" References: <1e609631-37e2-3818-37e3-72773758ff40@selasky.org> Content-Language: en-US In-Reply-To: <1e609631-37e2-3818-37e3-72773758ff40@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.28 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.982]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[selasky.org]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4NLKjj0Xd8z4d2h X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 9/8/22 16:19, Hans Petter Selasky wrote: > On 9/8/22 15:52, Robert Clausecker wrote: >>> See: >>> https://reviews.freebsd.org/D36493 >> >> Looks interesting!  Any particular reason you add a new function to the >> libc instead of just replacing qsort(3) with the new algorithm? >> >> Yours, >> Robert Clausecker >> > > Hi, > > It's a good question. My plan was first to establish the concept about > bsort() and then at some point remove qsort() and make those qsort() > functions symbol aliases for bsort(). > > There are several write-ups about "trying to fix qsort()". Here is a > link for one of them: > > https://www.raygard.net/2022/02/27/Re-engineering-a-qsort-part-4/ > > The question is, if there is a fix for qsort() in FreeBSD, will there be > a fix in other operating systems too? That's one argument for giving > bitonic sort an own name. > > --HPS > Update - interested parties - please have a look! https://reviews.freebsd.org/D36493 --HPS From nobody Mon Nov 28 20:25:55 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLcSC1F0kz4hq3s for ; Mon, 28 Nov 2022 20:26:19 +0000 (UTC) (envelope-from ehem@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLcSB2d2nz3HHC for ; Mon, 28 Nov 2022 20:26:18 +0000 (UTC) (envelope-from ehem@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of ehem@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=ehem@m5p.com; dmarc=none Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPS id 2ASKPxOq044580 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 28 Nov 2022 15:26:04 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.16.1/8.15.2/Submit) id 2ASKPttl044579 for freebsd-arch@freebsd.org; Mon, 28 Nov 2022 12:25:55 -0800 (PST) (envelope-from ehem) Date: Mon, 28 Nov 2022 12:25:55 -0800 From: Elliott Mitchell To: freebsd-arch@freebsd.org Subject: Interrupts, Interrupted, Part I Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[m5p.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Queue-Id: 4NLcSB2d2nz3HHC X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N For interrupting devices, interrupts on FreeBSD are fine. The bus interface provides a reasonable mechanism for allocating a device's interrupts. A large number of devices work fine without extensions so this appears reasonable. For interrupt controllers the situation is a horror. The x86 PIC interface has greatly evolved since the mid-1990s, but portions make it clear just how old the interface is. Interrupts on PowerPC work sufficiently differently that PowerPC has a similar, but not identical interface which doesn't share any source code with x86. When ARM was brought to FreeBSD, it had different issues with the interface. As such "INTRNG" is a third interface which shares no source code and is quite different from the other two. One of the first issues to resolve is the distinct naming of the headers. Both PowerPC and x86 have their headers as . Since INTRNG was envisioned as being platform-independent (does manage to cover both ARM and RISC-V, at least one MIPS device used it) its headers are named . This seems to mark the aspirations of the interfaces. Unfortunately this makes compatibility worse as you need a differently named header in one case. I think one of these names needs to be chosen as the standard and have everyone move to it. Being in "machine/" already marks the headers as potentially being incompatible, so I suggest is the better option. Could D35559 collect some opinions and then maybe this can progress? Even if the interrupt interfaces are rather distinct they *do* have quite a number of common points. All of them have a structure which serves to wrap the "intr_event" structure. As such I think it would be rather handy for all the interrupt interfaces to have an "interrupt_t" type. This makes common code which doesn't need to touch the internals easier. All 3 interfaces include the functionality of resolving an interrupt number to the associated structure. Yet of the 3, only x86 has the function "intr_lookup_source()" to provide that to the outside. For a machine-independent interface I'm inclined to think "intr_lookup()" is better as not all architectures refer to the structure as "source". >From 9b33b154b531, the justification for having the interrupt number in the intr_event structure is to allow MI source code to lookup interrupt numbers. Problem is, this lookup is a (slow) linear search whereas 2 of 3 architecture interfaces have an efficient lookup. The third could implement hashing for efficient lookup. Worse, this interface was restricted to the event core, so it simply fails to be useful for interrupt controllers. Once there is an MI interface and MI type, this becomes simple to use the existing heavily used interface. As such there were detours, but D32504 looks like a good solution. I hope the changes make this acceptable. Yet I still need reviews and then a committer... -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 From nobody Mon Nov 28 20:27:35 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLcTq13yyz4hqnf for ; Mon, 28 Nov 2022 20:27:43 +0000 (UTC) (envelope-from ehem@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLcTp40RZz3Hd2 for ; Mon, 28 Nov 2022 20:27:42 +0000 (UTC) (envelope-from ehem@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of ehem@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=ehem@m5p.com; dmarc=none Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPS id 2ASKRZ73044608 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 28 Nov 2022 15:27:40 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.16.1/8.15.2/Submit) id 2ASKRZG6044607 for freebsd-arch@freebsd.org; Mon, 28 Nov 2022 12:27:35 -0800 (PST) (envelope-from ehem) Date: Mon, 28 Nov 2022 12:27:35 -0800 From: Elliott Mitchell To: freebsd-arch@freebsd.org Subject: Interrupts, Interrupted, Part II Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com X-Spamd-Result: default: False [-3.28 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.976]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[m5p.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Queue-Id: 4NLcTp40RZz3Hd2 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N As part of trying to get a project into FreeBSD yet another issue showed up. There has been a push to get this functioning on top of INTRNG. This should be doable, but a problem arose. Due to this being a very dynamic PIC (hotplug PICs may be difficult in hardware, they're easy in software) it seems best to register interrupts during allocation and then fully release them during release. Problem is the call sequence: intr_isrc_deregister() -> (for non-IPI interrupts) isrc_release_counters() -> panic("%s: not implemented", __func__) The inverse of isrc_release_counters() is isrc_setup_counters(). These two are for setup/teardown of the "intrnames" and "intrcnt" arrays. Initially I was thinking "intrnames" and "intrcnt" were likely to be deeply intertwined into the FreeBSD kernel, they've been around since the mid-1990s. Yet upon examination, only two places use these two global variables. First, they are used by watchdog_fire() for reporting interrupts in case it triggers. Second, the functions sysctl_intrnames() and sysctl_intrcnt() use them for their sysctls (which are then used by `vmstat -i`). That is a *really* short list of uses. With the default parameters the "intrnames" array will tend to be roughly ~2MB and "intrcnt" would be roughly 128KB. That isn't huge, but an average system is only going to use perhaps 15% of that. The only benefit I see of having "intrnames" and "intrcnt" is they make those 2 sections of source code simpler. Yet by consuming noticeable amounts of memory, they make other sections slower. If they saw heavy usage this might be worthwhile, but I doubt they see enough for that to justify their existence. In light of this I've created D36610 for their removal. Portions of my initial implementation are likely to be rejected, but I like the idea. Notably this has a net removal of almost 100 lines of source code per architecture. THAT seems the characteristic of something whose time has passed. One spot likely to be rejected is the watchdog_fire() replacement implementation. I had been thinking the architecture interrupt tables were a good source of replacement data, but I'm now doubtful of this. In particular the functionality proposed in D36609 doesn't seem quite right. I now suspect it may be better to add a function to sys/kern/kern_intr.c for reporting this, but I'm unsure what to name it. The other spot is the "hw.intrnames" and "hw.intrcnt" sysctl()s really need work. Much of removed duplicated source code from the architectures appears to be directed towards maintaining compatibility with the existing sysctl()s. The difficult reimplementation also suggests these need a careful reimplementation. Their behavior hints at their long history, but their behavior is also rather poor for real use. I suggest there really should instead be a "hw.interrupts" sysctl() which provides the interrupt name, counter and stray count as triplets. This would ensure consistency between the two, avoiding the potential for an interrupt being added or removed between reading "hw.intrnames" and "hw.intrcnt". The format of the "hw.intrnames" speaks to its history. At some point pre-2003 it\0was\0a\0NUL\0separated\0list\0of\0strings. When interrupt names became changeable packing the strings became a problem. As such they were padded with spaces which allowed the old approach of finding the next interrupt name using `strlen()` to continue working, even though the entries were actually fixed-length. Problem is, since 2003 `vmstat -i` has never been updated to work with the current situation. As such, trying to figure out the whys behind everything has been difficult. Then there was at least one lurking bug just to make things more interesting. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 From nobody Tue Nov 29 21:59:50 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NMGTv51mlz4hdVY for ; Tue, 29 Nov 2022 22:00:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NMGTt6SWCz3l5Z for ; Tue, 29 Nov 2022 22:00:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="v/95roQJ"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::632) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x632.google.com with SMTP id ho10so37119486ejc.1 for ; Tue, 29 Nov 2022 14:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tNc2JIaR3xyN/rXjdSSmKv9SL6uXrT0ODj45ZOgBMOY=; b=v/95roQJEQVxBGejEyHRXnUl1s4EZx8D5HVBZlchSa6Ow2JgZ2oy3vHeio2MwKmn4b 8njoIDVGyJFb8sO19whbPvpokHzn1T6uJTT5dm1kpNbyXDHi4toFTNQF5nIA5LK70/QK G/Dg1mVNDsSVF3XivTSEt8aSt0DqEE5S1DKvfuhHG0VWLmSLUvuq6V6mMlD9iSBeoKj7 NI2Rhc85nQUvNsDCcloNZwB35YCypnkzQTOHvtPwazir3lhGJ5TjdgWla8kADCbRR8qp zaWiJk7gz2kZoeXDhofrDHX1ZqC8Hh4E7FLQo3PuQ5haoKdXhocSgscDbWupculNWda0 bktw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=tNc2JIaR3xyN/rXjdSSmKv9SL6uXrT0ODj45ZOgBMOY=; b=poC8QDyATjK0HQc1EfuPHd5bv4vsiinTMTKCA1Xe3hFisolC/uVXuKJ3H3dilwig0X 13nC+W42JrGkIzYoVT10PP2rb1Sad7S0J7vAT3TePMXfJt2Ht5ahNcRKCoR1cyAjzuEf MAm4WLIOKMU0G/LOolc05LgTiXT6n3e3ExY6UjBAna1SFI+TENcwiOAVVPKJp1P75ub9 1TMn/tBdDJumdk5bwmUOBal+nBEGxCk+fOV3/m/w9KJCtIVP38tOztuA6Gm/2JOsk4vz yKSvyBc8yehyaSVMD9HSsWvDjsvdh5BLHyYXG3lFWvP14jEootjPWXBDQvgltvlVdXGD MKrQ== X-Gm-Message-State: ANoB5pmnbz9z4MoQ3dvXmAFg2aGGgCKK5AUo/CoP9drKuVYVZjUE1ocn Di39fcxheVAjvXLkDg5BmtdmgRrkAAc+eGFSW2fKSQ== X-Google-Smtp-Source: AA0mqf7pot654jhbJe9MWBjqmQvn87ZQtGzyeDNcTQZvteZa/wHdmyjEsGUkuBuL9f9akKyLnTwZkjyxOH2gzr3xh+E= X-Received: by 2002:a17:906:f84d:b0:7b9:631b:7dfb with SMTP id ks13-20020a170906f84d00b007b9631b7dfbmr31026376ejb.32.1669759201508; Tue, 29 Nov 2022 14:00:01 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 29 Nov 2022 14:59:50 -0700 Message-ID: Subject: Re: Boot Loader: OFW network booting support To: Alexey Dokuchaev Cc: "freebsd-arch@freebsd.org" , FreeBSD PowerPC ML Content-Type: multipart/alternative; boundary="000000000000111b5805eea31c1f" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NMGTt6SWCz3l5Z X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000111b5805eea31c1f Content-Type: text/plain; charset="UTF-8" On Sun, Nov 20, 2022 at 9:47 PM Alexey Dokuchaev wrote: > On Tue, Nov 15, 2022 at 10:04:12AM -0700, Warner Losh wrote: > > ... > > So here's the deal. If someone has the ability to test and shows that > it's > > working today and promises to test my changes and help me debug it, then > > I'll keep it and add the new code that's needed to continue to support > this > > feature. > > I'd happily test anything on my venerable Mac mini G4 (which I currently > use to ensure ports' endian-cleanness and 32-bit compliance). > OK. There's a patch-train available at https://reviews.freebsd.org/D37560, but I don't know if you'll be able to easily apply it (there's 22 reviews). Alternatively, you can try the boot-devs branch at https://github.com/bsdimp/freebsd.git which is the same thing. > > Alternatively, if someone has the recipe for FreeBSD/powerpc on QEMU that > > includes OpenFirmware for disks and networking, I'll do the testing and > > legwork to get my netboot setup locally. > > I'll play with that as well. I recall last time I needed it, finding that > our Wiki doesn't have much working examples of different systems' emuation > was frustrating, so at the very least I could probably expand it. > Yea. I've managed to get mac99 emulation on qemu-system-powerpc working well enough to do the test boot, at least for disks. Still haven't found the secret decoder ring for netbooting with openfirmware, though. There's a network stack in the current Open BIOS used by qemu, though, so there may be hope. Warner --000000000000111b5805eea31c1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 20, 2022 at 9:47 PM Alexe= y Dokuchaev <danfe@freebsd.org&= gt; wrote:
On Tu= e, Nov 15, 2022 at 10:04:12AM -0700, Warner Losh wrote:
> ...
> So here's the deal. If someone has the ability to test and shows t= hat it's
> working today and promises to test my changes and help me debug it, th= en
> I'll keep it and add the new code that's needed to continue to= support this
> feature.

I'd happily test anything on my venerable Mac mini G4 (which I currentl= y
use to ensure ports' endian-cleanness and 32-bit compliance).

OK. There's a patch-train available at https://reviews.freebsd.org/D3756= 0, but I don't know if you'll be able to easily apply it (there= 's 22 reviews).

Alternatively, you can try the= boot-devs branch at http= s://github.com/bsdimp/freebsd.git which is the same thing.
= =C2=A0
> Alternatively, if someone has the recipe for FreeBSD/powerpc on QEMU t= hat
> includes OpenFirmware for disks and networking, I'll do the testin= g and
> legwork to get my netboot setup locally.

I'll play with that as well.=C2=A0 I recall last time I needed it, find= ing that
our Wiki doesn't have much working examples of different systems' e= muation
was frustrating, so at the very least I could probably expand it.

Yea. I've managed to get mac99 emulation on = qemu-system-powerpc working well enough to do the test boot, at least for d= isks. Still haven't found the secret decoder ring for netbooting with o= penfirmware, though. There's a network stack in the current Open BIOS u= sed by qemu, though, so there may be hope.

Warner= =C2=A0
--000000000000111b5805eea31c1f-- From nobody Fri Dec 2 00:33:00 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNYns2J6kz4jp8J for ; Fri, 2 Dec 2022 00:33:21 +0000 (UTC) (envelope-from ehem@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNYnr465kz41Lv for ; Fri, 2 Dec 2022 00:33:20 +0000 (UTC) (envelope-from ehem@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of ehem@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=ehem@m5p.com; dmarc=none Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPS id 2B20X1GB066339 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 1 Dec 2022 19:33:07 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.16.1/8.15.2/Submit) id 2B20X0cv066338; Thu, 1 Dec 2022 16:33:00 -0800 (PST) (envelope-from ehem) Date: Thu, 1 Dec 2022 16:33:00 -0800 From: Elliott Mitchell To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Giant Locked drivers Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com X-Spamd-Result: default: False [-3.26 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.962]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[m5p.com]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Queue-Id: 4NNYnr465kz41Lv X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote: > When set to 0, you get today's behavior. If set to 1, it will no longer > allow drivers that don't request MPSAFE interrupt handlers from registering > (the interrupt setup will return an error). > > This will allow us to understand what is lost if we throw the switch, and > allow users to proactively test their systems to see if they are > affected or not (and if they are, if they want to live without the > functionality, or want to fund work in the area). > > Comments? Partially building on Ed Maste's idea; perhaps the value 1 should be allow giant-locked drivers and -1 should disallow giant-locked drivers. Then use 0 for interesting behavior. Perhaps a value of 0 should be switched to 1 90% of the time and -1 1% of the time. Theory being to be annoying enough to attact attention, but not annoying enough to be turned off. I'm at least partially joking, but it might be a way to cause progress (or might cause trouble). In other news in two handy VMs. On x86: (a full VM with hardware emulation) atkbd0: [GIANT-LOCKED] psm0: [GIANT-LOCKED] WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0. On ARM64: (basically pure VM with no emulated hardware) So right now everyone is reporting x86 console devices and nothing else. This suggests the x86 console is urgent for giant removal. Then perhaps it will be viable to default to disabled (or perhaps something else will float to the top). -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 From nobody Fri Dec 2 03:13:08 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNdLZ04CVz4hxWS for ; Fri, 2 Dec 2022 03:13:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNdLX5Yzyz4LL8 for ; Fri, 2 Dec 2022 03:13:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Y9mqhVTN; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669950803; bh=8ntEew5ORVcEt/rEPFNZPbzIOHR5vuTllFmaiqvrY0Y=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Y9mqhVTN7cYzxrbvuo7vY58uMGnmWlYbHNEJpi0MANhnxr4nad6+9WJvU4S1WI8GvTod4s5z9AdYCcx5pbkJ/r1rg+kKgOws4D4Ms3TOKWkMiIH57EEX72Y4Rq2yB0JLFLXzmhlsd2ALvClTCZAhCwgSRAiT6Rxwg43sUvAESALXiKof2f6sgUBfApN0IDQafPNdiKS9a5T9iSo88o7ZR1sGogNpf90rsYPoCltQceC/NR6o58MyR73GHFetYUx/TtYSaVf/nzhkwpVDZMdcgQWOo0fQDrk1CS+epFeH+SfXOicdmSvy4iMcPqyTrEb9mzMbtMM+Zf7AwvsNuMUEKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669950803; bh=VDdpBP0eJeyxOtKg1wDdfnmL2Z8TV1VZNNsr+PR+u4+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kzYdi+r0HnHtu3ytn2J+7hvY+J9XPiiGr/csmKoSqr0DlvXhsyuPZk4NrzHXKar0EGdNX9HposmVjrv5+303Tn4VvoUGH3GDzi5dYknQiutC1D5XE1YTyxQA9pR1jFnQxdmcLqJDYgDnYqjoBeZt/7qUXvOmUaaZ+gj/Jvz6/Xy6DT6bJNqaIBN7a6WK+jooJg+yMxGNMMpSco+yYXLM3ZmAEmkaAynjzd+THbghl8veMW2RZOJzc/3/b0JxJyVr1tFk55Ood5F6LoRmthlLwPPj7Bf0sHndTUtG8wmr945d68y3t4xK1DO4y8tZjOn42/tPn7eaU17J4iG6ZQzFDg== X-YMail-OSG: Hvq79vwVM1kBYW2foRD906NNNRnLIGhZbgl7sIuFsceDZZ4BDqIQEJ0UDcNuyJS qaV5y8vL0I_is.vPtn1C5m.kFN1Wfh7w.YtkH7DRpXMnAylcmdu3703Irn29l7Iwjzu_ZRYnuvEe zwoCj_TAh3T15f7hYpp64KjwyulPK3xAn61lTHtTg6SmgkNBa4yyMa3qohZJ5srBuBE8j3LwzbWX 5lVYZ9NQpzu961klM0tZQUKnC2q74s9Yl0m04nnowxIa_KpepJMADU.2jC_nIAg55chEUPsfsglz fAbvH8cgYV1ECARZKXGGc9cUjTcass5hkQwbJHOi9bgd19GtWw_aSnhMgLxk5hxr0GIy6VhaK5cU v2jzWt.hWtAdHGPEHHaTuLCtRCtxy2UzsKQL01dcbJApO6m88Zks__FYA8TV76FhQuEqQRsgcC6o la.Ew4uzkwL3fcX19U3nI_voMHR4q_UfI5X7gnhu_KXxwjz_c1QS41mBtwX49Ea9WWDtaljmO4Ih W9u978cDc3BmNo88HFuqwthlWwEO3qtbDtOZuWYQmINPEooJ89pCSlrXKgpMoNFf8UljojA5RDtU Be2xWkF7lrT5bc5E76ISAbWHxDk_yDoILqs1G2VU0iPgMkK.zLsqu_PvGVWbbDlSnNjB.29ZCjBt _4A_tdwvZEudFO.iVfK8pfeIyQ2EStmLauT91KfjGhtlOv5VjMr_g6TEjQkXnJ5NePnVqMJNePWP Ch5V1dZC7pOaYPbf7s8lqQhVPaiKU2.oWa1H6Vx.ZR6vJ_tmwooD6gCtNh5_LaKGO_isrtet_8MX E.WmylvrBVQF5n1BpiB.ifT_wL75H2Jyf2rdiHSyxLM4ZBbbG6uHgsiq6kcKoi1AbFQ_0bOiUtV7 .q9fvH6wXE0MdXzflqYgW04ryQ4UPsH6k0_7vTPoJHEteJIvCWmIkrLVpXIgnFd4bLDNbxpL94XF b7FaqQ2GZHgTC9ePk6eCFjsKwDufC559AQzsZ3Wv8pvQVpeg._y1gySuzwEJFW6JIMWG2aNFr157 yVxQqXeJkBX4mIvgrNFmE9NrmQ1NebGVeP.HhIrRLeYxuyIFrfosT_kGjbDrsB404oM_LPrXRPGg tItDBZ.BNl13Kiy5qo4sXbx5pk_QKxAc0yjErovjgfiMdIwCEo2n28U3Mnzoe2qo1namYmBcdijI 9a9ByAGmWwrKz.gFGpwlCHuvOJIVEmKGwj_NowO4NC4GPGub.FXFB_7vIvwWh51b59FOCTy2LAwF if2nNVit9NSQlm5pv9vSE6YYopgaozQH_unirH7KzMcXKK6FHf_IC8X6SECwAoP3AB2WKBnY5FpH _Wv_BOQ9E0G7cR65U11ev45bkI291ZWJHZwM1wMR0INkCU7LQeoQb.XzzTmWi8uzpcMrUD1jJXym _8RxhTHTTkgYbk7WgvEe77436hrhY3gx2AbwhlH8xZySyKpKTPhBnwLC4js41EIAPRhnoCoKfStp w4E4l5z6MtahmA3gQ3WPZRD.XlEEx1Qq5saF32lRj6Y5HTmOETyRt4j0BPT6rTJsHXdBW2uMZ00. E_vQUq0AaHKqfN.ne7rtIoCRYV2xjoRrALCG7FiCWXkFqJ.d8cHmiCfx_RVpyEm1ddqgHmqwAR78 iLprtbKFXWoBBheTKT6x09YOHGY40pyworjPwDwBlFVP81i.yypJwUHBTy0.pGfsIX1XWX6d3oGT QY2WCrzxdkGku0ehH61Fddxq5GrkWQcBMYoGPlGdriZyavrt0kuAzsTemlpoMLHACZz2YNgjTtBy rifhC9P_1XujuRdlMyVk9PXIC.0EhU4o_VhZpwaYD_LWa3Fj.Z.5EDM1geRhNbmspHiulpfvkrwt F_fNCJjNspqeyWhk44vB7NzrMww_K9O8keXrGod.Erl2nKY1smJ4JpqMAed93mvtPVgye0v4sz0g mOwciw3drslhMs8vB4aOCkDGH8b_BiQKvtvvkQ1uEw3zXimG54wv96ki3wpa7RBeXXQkjJWwBTdt TJyV16Dl4hPUwaACPu1XGQdIbouuNYVVG0p7bo8YSjMA.mAMXW7NkvRAN9eOtIaXnNsLxqTOwvXH Gd3FrMBTFLl72_5BUvXXmnQ2UvDH8JQyIWLKX_.D4ec94r3hV2VuV95e1tH1QwVk0Ej809VxnZ5O y0Ful.jREo3lzQtzAN46VjLEUYooelaFGKpXRvx.3.eGb.6ANNCO.hhu85dsggLctAAmVWqXdOs6 WHiF_ToKHFKAwGzyFLP2afYPx9zgmPX7G9K5w.AdMm_NXbyGyTv0PuyaRRFvyf4lS2ohyaw6H29b O X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 2 Dec 2022 03:13:23 +0000 Received: by hermes--production-gq1-d898c4779-66ldg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6754d8ef4762c0bb6816a712fd71dcfa; Fri, 02 Dec 2022 03:13:18 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: Giant Locked drivers Message-Id: <9C63C7CB-0416-4F7F-80DB-28C5002A5F36@yahoo.com> Date: Thu, 1 Dec 2022 19:13:08 -0800 To: ehem+freebsd@m5p.com, freebsd-arch X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <9C63C7CB-0416-4F7F-80DB-28C5002A5F36.ref@yahoo.com> X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[freebsd]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org] X-Rspamd-Queue-Id: 4NNdLX5Yzyz4LL8 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Elliott Mitchell wrote on Date: Fri, 02 Dec 2022 00:33:00 UTC : > On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote: > > When set to 0, you get today's behavior. If set to 1, it will no = longer > > allow drivers that don't request MPSAFE interrupt handlers from = registering > > (the interrupt setup will return an error). > >=20 > > This will allow us to understand what is lost if we throw the = switch, and > > allow users to proactively test their systems to see if they are > > affected or not (and if they are, if they want to live without the > > functionality, or want to fund work in the area). > >=20 > > Comments? >=20 > . . . >=20 >=20 > In other news in two handy VMs. On x86: (a full VM with hardware = emulation) >=20 > atkbd0: [GIANT-LOCKED] > psm0: [GIANT-LOCKED] > WARNING: Device "psm" is Giant locked and may be deleted before = FreeBSD 14.0. >=20 > On ARM64: (basically pure VM with no emulated hardware) >=20 > >=20 > So right now everyone is reporting x86 console devices and nothing = else. In = https://lists.freebsd.org/archives/freebsd-arch/2022-November/000290.html I reported that RPi*'s list: WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD = 14.0. The other two types of small board computers that I have access to do not have software support for the video. I've no evidence beyond those tests to know if the issue is specific to the RPi*'s vs. more general. > This suggests the x86 console is urgent for giant removal. Then = perhaps > it will be viable to default to disabled (or perhaps something else = will > float to the top). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 2 03:19:12 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNdTW6vrdz4hyB1 for ; Fri, 2 Dec 2022 03:19:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNdTW2tPxz4Lpv for ; Fri, 2 Dec 2022 03:19:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62b.google.com with SMTP id n20so8809477ejh.0 for ; Thu, 01 Dec 2022 19:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YGzhb8kJbMXHu+jDhzGJ9prIsI7aGqG19yQ8qRD5df0=; b=Xq0ekYe0GOGR4m0RH6b6W0LGZqWVQrbUB2+jGbj3fX1Ik3vPr0MbBrpxrnnIO7gu7/ 1iPl8c1zoi55C6LnmB21VhLo+PajdD/Hyxdx8Hg3nYe9JZoobSU42sQGPhrDt4SNaOO+ cBT3YjxttWfQL/7nka2sNNWnskkhoppekniAATYtCLNbRNfpE/xBuPIufc4cscZvYvRG Y3sNeF8engIkivK9bfREBRh6rVGoLCB+bVjNUiLGk7qNTbYD3UqsYUmh1LuVZKHoKBAQ hCzjy8TTUidzNi3U7TC0/N2ZsT+7Qg+PwTIo+5ihf7Y/oAkhiULZS8c3c2odY3+fwV5Z jBuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=YGzhb8kJbMXHu+jDhzGJ9prIsI7aGqG19yQ8qRD5df0=; b=M/F+T2+Bd7mwUxHfhihcDV5LGKkhgyq6rNcbhkVIxlkkTaAbLfLltoSzL05FyFmNjv jtlzUInQDVmKtcFQSsGosXmjcdSIJeXLWKgqQeiJJd2cJCMM9Y1ZG4+tm7DEi5/MWRh+ EottfY0ha6L7yOyOfagu8pIicPrDH/aoO/rppzQ272esLabdwP9SxsYayis5aTQRoYh+ ORnUHHJR/m7o4upTmqQG7CWb9sukQ9GiYfG2Ex1cpy5KGzwPmS7x/R8iF+lW3BuPAzHa aSzyFS3QIZ10QaCJYgIRNKVbJHtj0SMN+H3B+SnL+AT3zb73Plz4bAljt3J77gjHJ6zg /ZfQ== X-Gm-Message-State: ANoB5pmw+WXVWV2MeuOBoRZsx9lJsxLOMvLplwsd1WFRYByo76DsB7GS JOWWkd8a5r+ZUu82EVmMX8u4h241Vpfke4QCFF9Msw== X-Google-Smtp-Source: AA0mqf4Hu7LuzKg+Z0YL15KNuSsSaSlv1G0xxIVbsCpNhbv57gssojPfU5cQ1EHZpt8J3Y15LzaEjW5WGKGegMp1rc0= X-Received: by 2002:a17:906:f24f:b0:7c0:b069:8e5b with SMTP id gy15-20020a170906f24f00b007c0b0698e5bmr4845155ejb.252.1669951165044; Thu, 01 Dec 2022 19:19:25 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <9C63C7CB-0416-4F7F-80DB-28C5002A5F36.ref@yahoo.com> <9C63C7CB-0416-4F7F-80DB-28C5002A5F36@yahoo.com> In-Reply-To: <9C63C7CB-0416-4F7F-80DB-28C5002A5F36@yahoo.com> From: Warner Losh Date: Thu, 1 Dec 2022 20:19:12 -0700 Message-ID: Subject: Re: Giant Locked drivers To: Mark Millard Cc: ehem+freebsd@m5p.com, freebsd-arch Content-Type: multipart/alternative; boundary="000000000000fc319c05eecfcddd" X-Rspamd-Queue-Id: 4NNdTW2tPxz4Lpv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[freebsd]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000fc319c05eecfcddd Content-Type: text/plain; charset="UTF-8" On Thu, Dec 1, 2022, 8:13 PM Mark Millard wrote: > Elliott Mitchell wrote on > Date: Fri, 02 Dec 2022 00:33:00 UTC : > > > On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote: > > > When set to 0, you get today's behavior. If set to 1, it will no longer > > > allow drivers that don't request MPSAFE interrupt handlers from > registering > > > (the interrupt setup will return an error). > > > > > > This will allow us to understand what is lost if we throw the switch, > and > > > allow users to proactively test their systems to see if they are > > > affected or not (and if they are, if they want to live without the > > > functionality, or want to fund work in the area). > > > > > > Comments? > > > > . . . > > > > > > In other news in two handy VMs. On x86: (a full VM with hardware > emulation) > > > > atkbd0: [GIANT-LOCKED] > > psm0: [GIANT-LOCKED] > > WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD > 14.0. > > > > On ARM64: (basically pure VM with no emulated hardware) > > > > > > > > So right now everyone is reporting x86 console devices and nothing else. > > In > https://lists.freebsd.org/archives/freebsd-arch/2022-November/000290.html > I reported that RPi*'s list: > > WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD > 14.0. > > The other two types of small board computers that I have > access to do not have software support for the video. > > I've no evidence beyond those tests to know if the issue is > specific to the RPi*'s vs. more general. > > > This suggests the x86 console is urgent for giant removal. Then perhaps > > it will be viable to default to disabled (or perhaps something else will > > float to the top). > I have the start of patches for newbus. But the console complex is trick since it's one of the few places multiple drivers are all locked by Giant and some care is needed. Warner --000000000000fc319c05eecfcddd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 1, 2022, 8:13 PM Mark Millard <marklmi@yahoo.com> wrote:
Elliott Mitchell <ehem+freebsd_at= _m5p.com> wrote on
Date: Fri, 02 Dec 2022 00:33:00 UTC :

> On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote:
> > When set to 0, you get today's behavior. If set to 1, it will= no longer
> > allow drivers that don't request MPSAFE interrupt handlers fr= om registering
> > (the interrupt setup will return an error).
> >
> > This will allow us to understand what is lost if we throw the swi= tch, and
> > allow users to proactively test their systems to see if they are<= br> > > affected or not (and if they are, if they want to live without th= e
> > functionality, or want to fund work in the area).
> >
> > Comments?
>
> . . .
>
>
> In other news in two handy VMs. On x86: (a full VM with hardware emula= tion)
>
> atkbd0: [GIANT-LOCKED]
> psm0: [GIANT-LOCKED]
> WARNING: Device "psm" is Giant locked and may be deleted bef= ore FreeBSD 14.0.
>
> On ARM64: (basically pure VM with no emulated hardware)
>
> <nothing>
>
> So right now everyone is reporting x86 console devices and nothing els= e.

In https://lists= .freebsd.org/archives/freebsd-arch/2022-November/000290.html
I reported that RPi*'s list:

WARNING: Device "fb" is Giant locked and may be deleted before Fr= eeBSD 14.0.

The other two types of small board computers that I have
access to do not have software support for the video.

I've no evidence beyond those tests to know if the issue is
specific to the RPi*'s vs. more general.

> This suggests the x86 console is urgent for giant removal. Then perhap= s
> it will be viable to default to disabled (or perhaps something else wi= ll
> float to the top).

<= /div>

I have the start of patc= hes for newbus.

But the = console complex is trick since it's one of the few places multiple driv= ers are all locked by Giant and some care is needed.=C2=A0

Warner=C2=A0
--000000000000fc319c05eecfcddd-- From nobody Fri Dec 2 20:05:32 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NP3pP6Y0cz4j8sT; Fri, 2 Dec 2022 20:05:33 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NP3pP643Sz4FPc; Fri, 2 Dec 2022 20:05:33 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670011533; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7H/ir/IrOw3NZcpZd/yyxYesynakd/BTawRSg5ZZlUU=; b=GTc0OcS506kCvjcZiV8mlUUwoX/m3Y7Pq9KLBTPQK5kma9759/76G6VFN/kQX8EtywpwiH JP5XedruLEC2Dh3p3cf5gB9CI3STCDxaPQTuc/+DmVRUdIZP2+eEMX7UJaxim+FE5XUEzR 58Cj1ByUPCG1BTzerCbIcMsKe75P45nUMHqnJO6CIaQUEc4Fy921B1LGMExhfuBmUdqykY kR+bzttQ59nqAuQMM+z/i4lqBQlBM/MCMSbM7rA4PnnU31aeIroznHJAA/SRrZlJqPRDwR /MtlqLkMxdoJy/lL7i8+pdd25q02pCCtyfEEtSt3WHXrzfkGJ4EXcn+x/YtnwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670011533; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7H/ir/IrOw3NZcpZd/yyxYesynakd/BTawRSg5ZZlUU=; b=oXipEdd9qZ0/K2qNm9We/xoSUeKvjpW+hV3YQQ8L2BTdwiWoMYBQXhkRA7LlwDZCcaPASb dxNZ9J5v8AT21Y1DdfmxCnmFG/pONrIY187a1FqMnrYNBFv7Rco50vPqKtiD06r1kmTJ19 Tl6OlKd8EpFQN+bq28gEnbpW1abdvgNbNVctqQf6becU59zM/8AAszItj381dp8kgmYJUo +ARtTDpO0/9zc+3zZtHmUY4h1bIqI1doyydYfgwFRSaPokT6uohygRVGgI6Sh6Y9zCKubL dxiC56mxCfH5yWQwBCcI6yW0vYndOA8el6lRegwu4rpF/7qwuiah42t+NhMfHw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670011533; a=rsa-sha256; cv=none; b=PxaU+0wCDGCQoJ+/28x/rTY23rGn7ge0zrT+Y5TeeoR6BSVo1lQ0ZBhLiZVh3AwwZR9JaR jrJGu4gZf/DfWpIv/LJXDB1j1IWVHIHt+DyqINJbjoLCqDsG4mEOBxMj/4paBBuX6V3WmR hY7GiMXtNs8YELZ3xXApJfTIKDmbsY0mwKFCelRTHcGcu98lpR43o84ao/GwZSxFZZjmn8 lZxvfsOc9FGEdpV+znPEVRuRPrHwgUYnGLm08t/tEa3SfXgmlRy1DvFSdAi65teWhDblWP Ar85AIC+kYFAv0cSnuVQOHTUJRjb0v8cb3467hBBJN9PgF0CJ4Y/LfRkBeEX0g== Received: from ralga-linux (dsl-74-83-251-217.fuse.net [74.83.251.217]) (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 4NP3pP3vnszjJl; Fri, 2 Dec 2022 20:05:33 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Fri, 2 Dec 2022 15:05:32 -0500 From: Justin Hibbits To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: Modularizing the network stack with a driver API Message-ID: <20221202150532.562e7059@ralga-linux> In-Reply-To: <20221123143359.2370ed89@ralga-linux> References: <20221123143359.2370ed89@ralga-linux> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; powerpc64le-unknown-linux-gnu) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On Wed, 23 Nov 2022 14:33:59 -0500 Justin Hibbits wrote: > Hi everyone, > > Back in 2014 Marcel Moolenaar started the thread "Roadmap for ifnet(9) > for FreeBSD 11" > (https://lists.freebsd.org/pipermail/freebsd-arch/2014-May/015379.html), > and after 8 years we want to revisit this. This email is to kick > things off again, and further design discussions. > > I've spent time off and on as able over the last couple years porting > -CURRENT to this "DrvAPI", and have something that compiles. Much of > the work was committed at the time of the initial discussion in 2014, > with enhancements done off and on since then. Also, much of the > shortcomings listed at https://wiki.freebsd.org/projects/ifnet have > not been addressed at all yet. > > Most of the work I've done in the recent port has been purely > mechanical and scripted, fixing build failures along the way. The > current work in progress can be found in my personal repository at > https://github.com/chmeeedalf/freebsd/tree/drvapi . The goal of this > first step is to get things started, address design feedback, and move > forward in main. > > > > - Justin > Gentle ping on this, since it may have gotten lost over the last long weekend for some people. Adding net@ for a wider audience. - Justin From nobody Tue Dec 13 17:48:24 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NWmFM6T7rz4kN3N for ; Tue, 13 Dec 2022 17:48:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NWmFL1S0Gz49dd for ; Tue, 13 Dec 2022 17:48:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="T/DE3A5A"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::634) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x634.google.com with SMTP id m18so38365162eji.5 for ; Tue, 13 Dec 2022 09:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=HyssrJq8BLUQkklEoMQwGWqDGJH3V00oShdrcvb3lcg=; b=T/DE3A5Ai/HjS9HogyCbPx+CCq6eK/P/v07LJQzIQt4H3T4Lg/RfDGskbKWaLfRU0b xvqE2y7zKgQ/YLPXYxvgxITWAvVYJlnsQNA3HXUBS7N0EdMgvC211hMJX7kjFBIWdRVh Hk3f6+8waoPtyYVMcL64nnTwXlWd4+gAN7UQsXkj2+cg6RLbQKyEv8Wdg/MJlOjH7R7V +NLFnV9ov3t1F40fApxvOfNxQQotgNnAGWcRa89MufZPeCB1HjPTz2WBWzXSA9Wfrvnp AiYJN5/h83mVKhlcRTlxLlWTNHQuJniNUKR+vs3ZTUoQCYQ7/78EarUVAE4ZkKL6IV3+ Tv1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=HyssrJq8BLUQkklEoMQwGWqDGJH3V00oShdrcvb3lcg=; b=bUzCxTRR3oSTCm0yHECKdcikfbwxl6dFnsdLDUWe81Of/KFT+OpX7gmNgt4onb6wWO cEBlN/Figywrkyjh4reaB03NMDLgTsooUfgx9qmfTLkNgr9V+eV17CCnvwxtgOd3k0ua 4OQrRtF3i+WPMaRbvVnjNQAoxNARQEh/eVzhm6HJdYs5vtGVWYmHhU5dN7yvOZYwdpry 2vAjUqDsgY5VK9SQfjfch5SVwUfPgUxyAN55k265JB3fvWBjXWA4x+HePfxgenvptGc+ Yx7kGbtNuyTpGe5ZM1iFT7LAqvK1mk+Y3PW2G1q/9BXJvabeR0EU1o8asRtIqpPzLuHo CegQ== X-Gm-Message-State: ANoB5pnyfA++cmVkvwBB2AEjkLbIrphVhZx1+5dHZnzicCn+kfVRaNx9 YS2txteizsNQ/ZVmgubPLhWBY6w3aywCJwGz+3Zv0xM/cQ3GHg== X-Google-Smtp-Source: AA0mqf710Ci/mewCW10KkReozSXaM3gLVkWc/51oZ/U2HpysL8D2dB9Ovo8MnSz/7MhuzoXuGVScLqqF2OyWO0vxOLI= X-Received: by 2002:a17:906:5a0c:b0:7c0:faca:4d5e with SMTP id mx12-20020a1709065a0c00b007c0faca4d5emr13210247ejc.140.1670953715997; Tue, 13 Dec 2022 09:48:35 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 13 Dec 2022 10:48:24 -0700 Message-ID: Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000adafd305efb93a37" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NWmFL1S0Gz49dd X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000adafd305efb93a37 Content-Type: text/plain; charset="UTF-8" Sorry for the lag of a year, it's been a crazy time for me and this fell through the cracks. On Thu, Oct 28, 2021 at 9:37 AM Warner Losh wrote: > Greetings, > > Given that the number of available and useful armv6 boards has fallen to > almost zero, the time has come to look hard at armv6. > > There's a number of options. > > 1. Keep it as is. This will only happen if there's a lot more users than > we think (and we think there's nearly zero users of FreeBSD 13 and newer > that would want to run FreeBSD 14). > > 2. Stop building packages. Given it's small to non-existent user base, it > makes no sense to provide a package building service for it. > 2a. We should likely do this anyway for all stable branches since it's a > net negative in terms of cost/benefit analysis: lots of effort to produce, > very little use. > > 3. Disconnect it from universe: This will mean it will rot, though. It's a > necessary step in removal. > > 4. Remove support for armv6 in base entirely. This will orphan any RPiB > and RPi0 users out there. However, the RPiB hasn't been sold in a few > years, and the RPI0's connectivity is severely lacking given no SDIO > support. > > So, which of these steps do we do before FreeBSD 14 and which before > FreeBSD 15? > > My vote would be to do 1-4 for 14 including 2a. > After discussing this offline and distilling the responses here, on IRC, etc, I'd like to propose we do the following: (1) Stop building packages for armv6 entirely, on all branches. While there are some users, they can still use poudriere to build package sets themselves. Usage data suggests there's not enough demand for these packages. (2) Move armv6 to an 'EXTRA' target in make universe (eg make universe EXTRA_TARGETS=t). Powerpc does this today with powerpcspe since it's not completely supported in base. People that care can continue to build it as part of universe and we'll fix things that are broken, reported to us and have patches that don't regress other platforms. (3) After the stable/14 branch next May or June, we'll remove build support from ports (very little) and src. We'll also start to tear down armv6 support as we see it and are working in other areas, and expect that work to be done before stable/15 is branched in a predicted 2025. (4) Immediately stop including armv6 -current snapshots as generated by re@. (5) re@ won't create armv6 release images or artifacts for stable/14, 14.0, etc. Users wishing to build it can do so. I've send email to re@ asking about #4 and #5. Warner --000000000000adafd305efb93a37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the lag of a year, it's been a crazy ti= me for me and this fell through the cracks.

On Thu, Oct 28, 2021 at 9:37 AM = Warner Losh <imp@bsdimp.com> wr= ote:
Greetings,

Given that the number of available = and useful armv6 boards has fallen to almost zero, the time has come to loo= k hard at armv6.

There's a number of options.<= /div>

1. Keep it as is. This will=C2=A0only happen if th= ere's a lot more users than we think (and we think=C2=A0there's nea= rly zero users of FreeBSD 13 and newer that would want to run FreeBSD 14).<= /div>

2. Stop building packages. Given it's small to= non-existent user base, it makes no sense to provide a package building se= rvice for it.
2a. We should likely do this anyway for all stable = branches since it's a net negative in terms of cost/benefit analysis: l= ots of effort to produce, very little use.

3. Disc= onnect it from universe: This will mean it will rot, though. It's a nec= essary step in removal.

4. Remove support for armv= 6 in base entirely. This will orphan any RPiB and RPi0 users out there. How= ever, the RPiB hasn't been sold in a few years, and the RPI0's conn= ectivity is severely=C2=A0lacking given no SDIO support.

So, which of these steps do we do before FreeBSD 14 and which before= FreeBSD 15?

My vote would be to do 1-4 for 14 inc= luding 2a.

After discussing thi= s offline and distilling the responses here, on IRC, etc, I'd like to p= ropose we do the following:

(1) Stop building pack= ages for armv6 entirely, on all branches. While there are some users, they = can still use poudriere to build package sets themselves. Usage data sugges= ts there's not enough demand for these packages.
(2) Move arm= v6 to an 'EXTRA' target in make universe (eg make universe EXTRA_TA= RGETS=3Dt). Powerpc does this today with powerpcspe since it's not comp= letely supported in base. People that care can continue to build it as part= of universe and we'll fix things that are broken, reported to us and h= ave patches that don't regress other platforms.
(3) After the= stable/14 branch next May or June, we'll remove build support from por= ts (very little) and src. We'll also start to tear down armv6 support a= s we see it and are working in other areas, and expect that work to be done= before stable/15 is branched in a predicted 2025.
(4) Immediatel= y stop including armv6 -current snapshots as generated by re@.
(5= ) re@ won't create armv6 release images or artifacts for stable/14, 14.= 0, etc. Users wishing to build it can do so.

I'= ;ve send email to re@ asking about #4 and #5.

Warn= er
--000000000000adafd305efb93a37-- From nobody Tue Dec 13 19:23:53 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NWpMW0K96z4kZ1h for ; Tue, 13 Dec 2022 19:24:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NWpMV0Dp1z4P1N for ; Tue, 13 Dec 2022 19:24:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="ZOvA/FJ7"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::534) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x534.google.com with SMTP id v8so19289151edi.3 for ; Tue, 13 Dec 2022 11:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=JxiWpZGIk1zUisPoiQdc0sc4kERS3fZ07x6pB5zLNnY=; b=ZOvA/FJ7oQFWPywsXc0c9vecRwWnWQJZ9mYzXJ5Un4VOGYqNSEAnXo77BJ65mdzZju +/y0SSZHxCqmVLNX0Wx+oDZJHieygQI2kccDqVLOdea5EHBvJ/zY8ukf4zPYSnXDYKX+ 7koxxZMsEUhO8KuxiHyz5kYmT4lWejnQe58SCs2fM3dN9CzzfHMYeXLGKGXjUZ6JTj8C xxyMnPn4iNo4IgCozzTmEZEbzESuUHitqSYYQTSvrFO6XbywsZ0liuZOF2s+3SbG/3e6 kdc5HaqfUhVKQTMz41Ggly70BeVmUWJYiNJiO0zrnXHDa/fTLZej8J/OuBgWVnU9S3Xm 1QWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=JxiWpZGIk1zUisPoiQdc0sc4kERS3fZ07x6pB5zLNnY=; b=M+KykBJpHPJ2PfJ+lI0EnRs3mE+dTdnep3FZfU/pgde5dxux6BvI0ztcOs9hziLfEn t4JDbTJHqAUZQan0QsGmWJjkWYmyggBpmwCh+awxPqqPZ3p+C4PHBvQaRRbbG5bylz8l m8IxpiJs/akhtd94/0PGQSUINTUVPllpb/7SkIXRqQ7ajVl7lPSOkn/y21pMunfmkU9O szpRkEXwdBJ9J7ptEmHM/5ZIg5wTLDHEg2FIopF/A1xYyXZ1laAvYhZh2IBBgWY6CllZ gSFcDF+FpCaLniehvvQvFn0ieI2pLRVKWoXO4S0kRGC5bdJ7yGSv0qF0kzjIATd+Kgkf /Oeg== X-Gm-Message-State: ANoB5pmSSv9jZc4mSTdpssh+JbH34IyqAiqG4NrXMyLSkIhBiSKXYI+4 D3YwxekNgmwgOstJUzRjyAIJsFwvbkTjOnhxq+RdqVhLu79BkQ== X-Google-Smtp-Source: AA0mqf5GNYlG/vAdpJNxxxGwSUvz2ACTwlnYBtVsls+5ATIVuhb/TGgOM+Y/nIEaGOaWo/AXkFiYzuGwo1Cw0GnC+EU= X-Received: by 2002:a05:6402:1107:b0:463:9b53:cbf6 with SMTP id u7-20020a056402110700b004639b53cbf6mr79901229edv.173.1670959444715; Tue, 13 Dec 2022 11:24:04 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 13 Dec 2022 12:23:53 -0700 Message-ID: Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000022ffc605efba90fe" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NWpMV0Dp1z4P1N X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000022ffc605efba90fe Content-Type: text/plain; charset="UTF-8" On Tue, Dec 13, 2022 at 10:48 AM Warner Losh wrote: > Sorry for the lag of a year, it's been a crazy time for me and this fell > through the cracks. > > On Thu, Oct 28, 2021 at 9:37 AM Warner Losh wrote: > >> Greetings, >> >> Given that the number of available and useful armv6 boards has fallen to >> almost zero, the time has come to look hard at armv6. >> >> There's a number of options. >> >> 1. Keep it as is. This will only happen if there's a lot more users than >> we think (and we think there's nearly zero users of FreeBSD 13 and newer >> that would want to run FreeBSD 14). >> >> 2. Stop building packages. Given it's small to non-existent user base, it >> makes no sense to provide a package building service for it. >> 2a. We should likely do this anyway for all stable branches since it's a >> net negative in terms of cost/benefit analysis: lots of effort to produce, >> very little use. >> >> 3. Disconnect it from universe: This will mean it will rot, though. It's >> a necessary step in removal. >> >> 4. Remove support for armv6 in base entirely. This will orphan any RPiB >> and RPi0 users out there. However, the RPiB hasn't been sold in a few >> years, and the RPI0's connectivity is severely lacking given no SDIO >> support. >> >> So, which of these steps do we do before FreeBSD 14 and which before >> FreeBSD 15? >> >> My vote would be to do 1-4 for 14 including 2a. >> > > After discussing this offline and distilling the responses here, on IRC, > etc, I'd like to propose we do the following: > > (1) Stop building packages for armv6 entirely, on all branches. While > there are some users, they can still use poudriere to build package sets > themselves. Usage data suggests there's not enough demand for these > packages. > (2) Move armv6 to an 'EXTRA' target in make universe (eg make universe > EXTRA_TARGETS=t). Powerpc does this today with powerpcspe since it's not > completely supported in base. People that care can continue to build it as > part of universe and we'll fix things that are broken, reported to us and > have patches that don't regress other platforms. > (3) After the stable/14 branch next May or June, we'll remove build > support from ports (very little) and src. We'll also start to tear down > armv6 support as we see it and are working in other areas, and expect that > work to be done before stable/15 is branched in a predicted 2025. > (4) Immediately stop including armv6 -current snapshots as generated by re@ > . > (5) re@ won't create armv6 release images or artifacts for stable/14, > 14.0, etc. Users wishing to build it can do so. > Oh, and #6: Demote armv6 (but not armv7) to tier 3. It's been kinda de-facto there for a while anyway, and this will make the signalling clear that the runway for armv6 is running out. > I've send email to re@ asking about #4 and #5. > > Warner > --00000000000022ffc605efba90fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 13, 2022 at 10:48 AM Warn= er Losh <imp@bsdimp.com> wrote:=
Sorry for the lag of a year, it's been a crazy time for me and t= his fell through the cracks.

On Thu, Oct 28, 2021 at 9:37 AM Warner Losh &= lt;imp@bsdimp.com&g= t; wrote:
Greetings,

Given that the number of avail= able and useful armv6 boards has fallen to almost zero, the time has come t= o look hard at armv6.

There's a number of opti= ons.

1. Keep it as is. This will=C2=A0only happen = if there's a lot more users than we think (and we think=C2=A0there'= s nearly zero users of FreeBSD 13 and newer that would want to run FreeBSD = 14).

2. Stop building packages. Given it's sma= ll to non-existent user base, it makes no sense to provide a package buildi= ng service for it.
2a. We should likely do this anyway for all st= able branches since it's a net negative in terms of cost/benefit analys= is: lots of effort to produce, very little use.

3.= Disconnect it from universe: This will mean it will rot, though. It's = a necessary step in removal.

4. Remove support for= armv6 in base entirely. This will orphan any RPiB and RPi0 users out there= . However, the RPiB hasn't been sold in a few years, and the RPI0's= connectivity is severely=C2=A0lacking given no SDIO support.
So, which of these steps do we do before FreeBSD 14 and which b= efore FreeBSD 15?

My vote would be to do 1-4 for 1= 4 including 2a.

After discussin= g this offline and distilling the responses here, on IRC, etc, I'd like= to propose we do the following:

(1) Stop building= packages for armv6 entirely, on all branches. While there are some users, = they can still use poudriere to build package sets themselves. Usage data s= uggests there's not enough demand for these packages.
(2) Mov= e armv6 to an 'EXTRA' target in make universe (eg make universe EXT= RA_TARGETS=3Dt). Powerpc does this today with powerpcspe since it's not= completely supported in base. People that care can continue to build it as= part of universe and we'll fix things that are broken, reported to us = and have patches that don't regress other platforms.
(3) Afte= r the stable/14 branch next May or June, we'll remove build support fro= m ports (very little) and src. We'll also start to tear down armv6 supp= ort as we see it and are working in other areas, and expect that work to be= done before stable/15 is branched in a predicted 2025.
(4) Immed= iately stop including armv6 -current snapshots as generated by re@.
(5) re@ won't create armv6 release images or artifacts for stable/14= , 14.0, etc. Users wishing to build it can do so.

Oh, and #6: Demote armv6 (but not armv7) to tier 3= . It's been kinda de-facto there for a while anyway, and this will make= the signalling clear that the runway for armv6 is running out.
= =C2=A0
I've send email to re@ asking about= #4 and #5.

Warner
--00000000000022ffc605efba90fe-- From nobody Tue Dec 13 19:34:30 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NWpbm4Kdfz4kb5Y for ; Tue, 13 Dec 2022 19:34:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NWpbl28MRz4QYD for ; Tue, 13 Dec 2022 19:34:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=mlGyW7JS; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::633) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x633.google.com with SMTP id t17so39187572eju.1 for ; Tue, 13 Dec 2022 11:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=5GntIFDKC/ykg8WzkkhWJaXE35mf9I9QzXcjQkb3J3Y=; b=mlGyW7JSN4mjGfghR7q34jiafinSC8TgjdgdjDaXaxm4Uyiiq3OjoV9J+aCMYVSk9v AoUIFXDsjoa4UkqMvro79fFisym/UgSPAYDK/3Iy02id1y5hTQVBm5FmoHFrnOqRW2Ru nU+dcSPtAKqI0vEndZ4cF84N425fUmfEmGzVcUCEupD/oLJo4My23lMH4bz5bI7cjNdE j1vQbdvGTw0C70LIRk2Y/QhWHi8wqYknumVRvLZYHDECr5WZloHfW8TLljRXZdvQ2GNJ YJIUvonPx4y1ThVW7HitBcgbOyMjnrdFMw93lOZibpJz1bbemWVWanV+daQG0gzzydwB NHpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=5GntIFDKC/ykg8WzkkhWJaXE35mf9I9QzXcjQkb3J3Y=; b=YM7RgHo0H3dCpvA6hXsEhiOtOPi/SM0W3TBRgDRYr38RBGpXSrFZR+hoXIhD01yxMI 1N45J+8tfSYp8+ziK/BLSz6lb1PW4gb3LrxNcL+KWGxBUJCciIQJBwBV8G4/f94Y00Dm /WIJvSQu9BlWnP1r3AKQUaupFT0IwZF729fPJREOYvhkOSI1ha52IqtExYZJ+ALvvAsI xLN6oEBPIM+P0GtB2kAgEX4ozgHTYxa34GmzQi+E4Rqpro0fhvenL6xBP3kFvD+DxELu uje8YLfkG4SZWd8JigwQcE5t5Yl1KxN3eF4HLcKdCSZkH5ckZQvdiAawNKAgIxOlCi1Y OELQ== X-Gm-Message-State: ANoB5pm9DjGPtVVFwdX8w3wgNJVo/AoSnXjduobsZ0he15iwnY2/usiy nEQWrV5AIfPRZQtKZ5+PyVcuJTPywbG2xuYXMF8WUwrQTLwlcg== X-Google-Smtp-Source: AA0mqf69q1cj0exLGNiuCdzA2X+UXoYeNvcrIYCh3figbKgRHAXPvTzSrrhMqLmSuyVeskfXE3HRPbzd4CyqrtltaJQ= X-Received: by 2002:a17:907:98ed:b0:7c0:e7a6:cd2d with SMTP id ke13-20020a17090798ed00b007c0e7a6cd2dmr16060342ejc.317.1670960081734; Tue, 13 Dec 2022 11:34:41 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 13 Dec 2022 12:34:30 -0700 Message-ID: Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000001b264505efbab6e1" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NWpbl28MRz4QYD X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000001b264505efbab6e1 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 13, 2022, 12:23 PM Warner Losh wrote: > > > On Tue, Dec 13, 2022 at 10:48 AM Warner Losh wrote: > >> Sorry for the lag of a year, it's been a crazy time for me and this fell >> through the cracks. >> >> On Thu, Oct 28, 2021 at 9:37 AM Warner Losh wrote: >> >>> Greetings, >>> >>> Given that the number of available and useful armv6 boards has fallen to >>> almost zero, the time has come to look hard at armv6. >>> >>> There's a number of options. >>> >>> 1. Keep it as is. This will only happen if there's a lot more users than >>> we think (and we think there's nearly zero users of FreeBSD 13 and newer >>> that would want to run FreeBSD 14). >>> >>> 2. Stop building packages. Given it's small to non-existent user base, >>> it makes no sense to provide a package building service for it. >>> 2a. We should likely do this anyway for all stable branches since it's a >>> net negative in terms of cost/benefit analysis: lots of effort to produce, >>> very little use. >>> >>> 3. Disconnect it from universe: This will mean it will rot, though. It's >>> a necessary step in removal. >>> >>> 4. Remove support for armv6 in base entirely. This will orphan any RPiB >>> and RPi0 users out there. However, the RPiB hasn't been sold in a few >>> years, and the RPI0's connectivity is severely lacking given no SDIO >>> support. >>> >>> So, which of these steps do we do before FreeBSD 14 and which before >>> FreeBSD 15? >>> >>> My vote would be to do 1-4 for 14 including 2a. >>> >> >> After discussing this offline and distilling the responses here, on IRC, >> etc, I'd like to propose we do the following: >> >> (1) Stop building packages for armv6 entirely, on all branches. While >> there are some users, they can still use poudriere to build package sets >> themselves. Usage data suggests there's not enough demand for these >> packages. >> (2) Move armv6 to an 'EXTRA' target in make universe (eg make universe >> EXTRA_TARGETS=t). Powerpc does this today with powerpcspe since it's not >> completely supported in base. People that care can continue to build it as >> part of universe and we'll fix things that are broken, reported to us and >> have patches that don't regress other platforms. >> (3) After the stable/14 branch next May or June, we'll remove build >> support from ports (very little) and src. We'll also start to tear down >> armv6 support as we see it and are working in other areas, and expect that >> work to be done before stable/15 is branched in a predicted 2025. >> (4) Immediately stop including armv6 -current snapshots as generated by >> re@. >> (5) re@ won't create armv6 release images or artifacts for stable/14, >> 14.0, etc. Users wishing to build it can do so. >> > > Oh, and #6: Demote armv6 (but not armv7) to tier 3. It's been kinda > de-facto there for a while anyway, and this will make the signalling clear > that the runway for armv6 is running out. > As a reminder: this is only the original Raspberry Pi B and the original Pi 0 models. Supported replacements for both of these are available from Raspberry and other vendors. Warner > >> I've send email to re@ asking about #4 and #5. >> >> Warner >> > --0000000000001b264505efbab6e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Dec 13, 2022, 12:23 PM Warner Losh <imp@bsdimp.com> wrote:


On Tue, Dec 13,= 2022 at 10:48 AM Warner Losh <imp@bsdimp.com> wrote:
Sorry fo= r the lag of a year, it's been a crazy time for me and this fell throug= h the cracks.

On Thu, Oct 28, 2021 at 9:37 AM Warner Losh <imp@bsdimp.com= > wrote:
Greetings,

Given that the number of ava= ilable and useful armv6 boards has fallen to almost zero, the time has come= to look hard at armv6.

There's a number of op= tions.

1. Keep it as is. This will=C2=A0only happe= n if there's a lot more users than we think (and we think=C2=A0there= 9;s nearly zero users of FreeBSD 13 and newer that would want to run FreeBS= D 14).

2. Stop building packages. Given it's s= mall to non-existent user base, it makes no sense to provide a package buil= ding service for it.
2a. We should likely do this anyway for all = stable branches since it's a net negative in terms of cost/benefit anal= ysis: lots of effort to produce, very little use.

= 3. Disconnect it from universe: This will mean it will rot, though. It'= s a necessary step in removal.

4. Remove support f= or armv6 in base entirely. This will orphan any RPiB and RPi0 users out the= re. However, the RPiB hasn't been sold in a few years, and the RPI0'= ;s connectivity is severely=C2=A0lacking given no SDIO support.
<= br>
So, which of these steps do we do before FreeBSD 14 and which= before FreeBSD 15?

My vote would be to do 1-4 for= 14 including 2a.

After discuss= ing this offline and distilling the responses here, on IRC, etc, I'd li= ke to propose we do the following:

(1) Stop buildi= ng packages for armv6 entirely, on all branches. While there are some users= , they can still use poudriere to build package sets themselves. Usage data= suggests there's not enough demand for these packages.
(2) M= ove armv6 to an 'EXTRA' target in make universe (eg make universe E= XTRA_TARGETS=3Dt). Powerpc does this today with powerpcspe since it's n= ot completely supported in base. People that care can continue to build it = as part of universe and we'll fix things that are broken, reported to u= s and have patches that don't regress other platforms.
(3) Af= ter the stable/14 branch next May or June, we'll remove build support f= rom ports (very little) and src. We'll also start to tear down armv6 su= pport as we see it and are working in other areas, and expect that work to = be done before stable/15 is branched in a predicted 2025.
(4) Imm= ediately stop including armv6 -current snapshots as generated by re@.
=
(5) re@ won't create armv6 release images or artifacts for stable/= 14, 14.0, etc. Users wishing to build it can do so.

Oh, and #6: Demote armv6 (but not armv7) to tier= 3. It's been kinda de-facto there for a while anyway, and this will ma= ke the signalling clear that the runway for armv6 is running out.

As a reminder: this is only the original Raspberry Pi B and the origina= l Pi 0 models. Supported replacements for both of these are available from = Raspberry and other vendors.

Warner

=C2=A0
I've send e= mail to re@ asking about #4 and #5.

Warner
--0000000000001b264505efbab6e1-- From nobody Tue Dec 13 23:52:16 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NWwKH5KTsz4k8nh for ; Tue, 13 Dec 2022 23:52:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NWwKG3tFZz40Mj for ; Tue, 13 Dec 2022 23:52:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bbb7suPR; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670975552; bh=TLxKCQ6c1JqYkAwN+JiqrO1xVAldMxMXqgBfxs4T5fc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=bbb7suPRsrZyumqOsZ/oevHh4Z6m8qO8SNWIia5/w/96bu89lCfHqxoKHJr0fiVbNRIbtD4pT1l/kVmsc2wKD+yJBZXwhfLZO8R8lzZZPrsv0Jx5FIGkYBzPlJakuchDRqmfvjRs5NapIWeZs+pAkOBpdFcFmZBiDC2G6t8F4tOoMsAF4PI866ekXgzGQysRcLBWHqahp6kwX8Of8z/VyxcUZ3VrnydxRkRvj+xA+PDpbQwSvQOQrOpBzjlO+g8xWLSUhw2HEKrbwIdOZm4+2Zh+vQF8FBMtf18ojdg02bfwZ4DLwF4qBR4LRLaV13k0OxIZcpixUJWQ6iiBjmMDsQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670975552; bh=7i5HqFcMWxTa+sbSmdXM7QfAOn7X4RM2Ma/CwaDNVis=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=RbB9yLLs0q9pb91HRST3JPpMTpmJBb/Q+ZqOMdxz/gWQ0kT0mI/8LjdsvQG1ScowEs9gMPcQLsYXoDaAsDqgfIK4+HIefz5FVHS2HsBrHUu9d4ZEaRFPzl4AxfY8WHFhSuwiT+W+Nvnb3IlxDzd+X2E7ETTXZQJ+k4av2LSOKG8NNeSrD5YU4QvinqNIXguaf5jiQK4LAxgkuS8nt3uMOlJMlMADONhHXeDcI4RlHJVy3xcFUdWqvW7KoeVpRa+LMX/aY6osobpjVyPcmX9OhxYjednb4syMa4ZgsPZ2g/CWjQCtrTIhMdjLXLTF1XUHn3WjiHaNNtl6uAGPQVB8LQ== X-YMail-OSG: i9igVxMVM1mcCrQ_WPyZu0C6afkVhpXpGOCo_h2aMDqEh.y1VCXj4Z4gW5aUsRH r4xzLsk14SeVkBYy2YIdKU1hRY4ZRMVpKx6R7Lp01aA6wsFgPWtKT7BwRgy5QhCv53Y9lTxXrzFU yMXZmpV7KbmI1z06tZ3bKD5VkKGkFR4jmTDcI7monspQCE2RpxplvDIBDnvYJRTLYejb9g4Ief9A Dy_1IUK3J8uUJLWswmxYLS2qMcYpqK5Wo8FzhrqBozmdkaqPKRMvFqPiYhF7z2TSURwZgqIUFLhS 9PUU6fFNoq2ng5m.HMUIjdBsebwCERHryZURblRgy.Ysc.WkDoDtVJDm7bq996b1tUt0w08eRGzi 7bXMePK6DANEcCzOVbVlyAUYENB.TCgKTCwnW7rgJ9zMaSjBJ0biJElRMg0rczr0c6QscxTuyc2g CMNUlHiERGt27E7Zvy5Z.RR5H4mssHrcDMCVhLOjkPgH6LviodeXUZQgos9FAG5t8nrrmtCdDjhV hZ03t84wRcNWQfftp._AHZ24ueZVDc6CA0ZaXFDI_m3IAg8PDqTctLyQ27AMO5VRTizcChDGv4ov N1m4syJKm4EI7mH9bbHdk_IAsUz6rv8fgHoekRIo9S5Omy2ZTaqS8zph3dtg7cjknWm55qnp9tkW jugJHy6TEqI6BKJmdlqIogS0E3WBB_.vnj27Qbx5tEKEffqeLnk5z01EWHdHbgnqmPoowhhwDZya oJOO.vSLibGPnq.Z9zNnqCnRLef.SH3MniNslDG43TrAa.9UmPd_dWWGiisTGAw8TW9zYrED7ba_ aK0_DYDWwHjrdqmAq_CzD3lALzPkXYutGB7TnxO4lj4kcwetDtGJDemMx3xVqziBlVE7yMdH_v5M hvm8hwlH5FH__EQ5vz8XNa6crOfLVrGw6PQZcr6pxoxQxk44oAKv13c_1JCqZ5RJNvoUBcn5gQJD Lc0I4soziW084wYO_FhFV7nBJPiFcd9RZeHWbDoCg_JcdRq8wZGMWfOsiyMvTMih8mh57yW_r23l cjjbuzuzSjvKryBqaCNpWE4BOqdttbsFysgxPeWXWDVHfszT5QnkII58rNySzyWVay6dxFmMPLc7 qcgUnxgmtYRyMnhfuWAEGVKOiIcPxIArxsGFlft1jG5uAp0BQ52EdTGmU3xrewR47_pHx6I0kRl8 qmMrCYSvE2p8NRrOILKgjY6iwkUic.c._W_9Vjhvt2kQYhRE3YiVi2fQdg3y7e.hs.z9aKlSfwJI SG8Beo_4q8SCruE0reLsXxdLzwgKA_ESnX.zLyThLLl1gFB4u82szTryAjeg6L8yaHWXxtOZIkG5 uMe2WX27D_f0QFX4AXznes7n5Q52jAU_a4iDL.O_BqAKGD3xOb06ZmET6Z0rLXFeXS2gZY0Aic7E 27x6rNdT0_b46JJPBzE6fxnL9g2fH.HqvTh5WVntljLTh4PAf7_q9PdugZdRkQOWgyzzUGp0_Xp1 A2jb91k14.Gi4caLCwL3XmS2hybQRLZKueXCLffOhSDBGlK4Qgtac3hGg055Tf0K9ut.7TYWYHfy RvV0tpWNqr5.yavKYOTt8CE8CsZctMZpocqonlDJscPAu8URz7zOohDJV9lIX5r3RXeQzy8GcUwj d4RXtkiGz51uoNYUby9wrTJfogSv4Wluxt1PoY50ipH7Cn7Ve9KDreNIj7_41EEojUaA2bp_24p0 huw6YKrjIxS.aZyRRhFXcB6DhWaS5PW_YVMTkfO3f3nTf5EYfrQLwZsNjCuysNFUSzEug393um65 Ukum02bkpw.3EngqYuVezpLMWZXUtmiHWAUx2kaP8z2u_3JtJEzppX.QyhlVRnNccozzxi2Skvkt c6bYthDl6KLNjNuC5uA4ju5_gLz8YA8RFd6LUEyOgXxsJ7ncWF4bvXmMKuQw2WleZSkjX_zj1V31 goR4bNTVSMPvreaZBue3PIdviHwiuMwDMtnsC5NTXCLQPM8wCafTH_PjBaCk66tnP8rdqX_EKdKG cMY_T5S1y5ah.EIb2k9dEtTGNqACAPTtqPV9QIfIzAWxSqZzdbj61sUKWUMBpVwafmxjQrne8qci DonnwL_Th8YH.HF_9wjm1LXSwre0tWBDoQ_21KjC7CF.VDlPXUNmc6QJjZ7MOih4QMkbcbL8w8PV Lq3Knmv1ZmQCilGPBM69LNMwihH97NrO49vMjbUoE.XIVwb0pwAC0aVXWMuaLH8wY2dNhpcUJ0Od 0_f3wbxcjLC90lwzYal1KOxEk8YSJ.I3R0m9ppaF4NXmOLSiL0tuPpsT3rzenFbAw8tmdCCmb8YZ s6g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 13 Dec 2022 23:52:32 +0000 Received: by hermes--production-ne1-7b69748c4d-kwzvj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bd7beebe1356f1f2815627b5a57cca4f; Tue, 13 Dec 2022 23:52:28 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed Message-Id: Date: Tue, 13 Dec 2022 15:52:16 -0800 To: Warner Losh , freebsd-arch X-Mailer: Apple Mail (2.3731.200.110.1.12) References: X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.986]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from] X-Rspamd-Queue-Id: 4NWwKG3tFZz40Mj X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote on Date: Tue, 13 Dec 2022 19:23:53 UTC : > On Tue, Dec 13, 2022 at 10:48 AM Warner Losh wrote: > > > Sorry for the lag of a year, it's been a crazy time for me and this fell > > through the cracks. > > . . . > > > > Oh, and #6: Demote armv6 (but not armv7) to tier 3. It's been kinda > de-facto there for a while anyway, and this will make the signalling clear > that the runway for armv6 is running out. > Yea. Some other adjustments to: https://www.freebsd.org/platforms/arm/ would likely be appropriate, not just things strongly tied to just armv6. Primarily, in: QUOTE 32-bit ARMv6 and ARMv7 is officially a Tier 2 architecture, as the FreeBSD project does not provide official releases or pre-built packages for this platform due to it primarily targeting the embedded arena. END QUOTE FreeBSD does provide pre-built packages for armv7, now much better than when qemu based building was in use. (The aarch64 based builders can execute armv7 and are used for armv7 package building these days.) (armv6 builds uses qemu on amd64, which significantly limits what gets built and provided: lots fails to be built. armv7 use to have that status as well.) Also, the likes of: http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/ does have some armv6 and armv7 materials for 12.3/ , 12.4/ , 13.0/ , and 13.1/ . The wording above might stop someone from even looking for the material. (This sort of status is not a recent change.) Sure looks to be official material. (No implication of a change from Tier 2 for armv7. But the existing wording used to indicate example justifications is --and has been-- misleading.) === Mark Millard marklmi at yahoo.com From nobody Wed Dec 14 02:22:10 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NWzfY3r04z4kTjn for ; Wed, 14 Dec 2022 02:22:45 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NWzfX1x3nz4Gqr for ; Wed, 14 Dec 2022 02:22:44 +0000 (UTC) (envelope-from jhs@berklix.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com; dmarc=none Received: from mart.js.berklix.net (p4fe6de95.dip0.t-ipconnect.de [79.230.222.149]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 2BE2MQDK017993 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2022 02:22:36 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 2BE2MKFw010583 for ; Wed, 14 Dec 2022 03:22:20 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 2BE2MAoG074349 for ; Wed, 14 Dec 2022 03:22:20 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <202212140222.2BE2MAoG074349@fire.js.berklix.net> To: freebsd-arch Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Tue, 13 Dec 2022 15:52:16 -0800." Date: Wed, 14 Dec 2022 03:22:10 +0100 X-Spamd-Result: default: False [-2.05 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.95)[-0.953]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[jhs]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[berklix.com]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4NWzfX1x3nz4Gqr X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Hi, Reference: > From: Mark Millard > Date: Tue, 13 Dec 2022 15:52:16 -0800 Mark Millard wrote: > Warner Losh wrote on > Date: Tue, 13 Dec 2022 19:23:53 UTC : > > > On Tue, Dec 13, 2022 at 10:48 AM Warner Losh wrote: > > > > > Sorry for the lag of a year, it's been a crazy time for me and this fell > > > through the cracks. > > > . . . > > > > > > > Oh, and #6: Demote armv6 (but not armv7) to tier 3. It's been kinda > > de-facto there for a while anyway, and this will make the signalling clear > > that the runway for armv6 is running out. > > > > > Yea. Some other adjustments to: > > https://www.freebsd.org/platforms/arm/ > > would likely be appropriate, not just things > strongly tied to just armv6. Primarily, in: > > QUOTE > 32-bit ARMv6 and ARMv7 is officially a Tier 2 architecture, > as the FreeBSD project does not provide official releases > or pre-built packages for this platform due to it primarily > targeting the embedded arena. > END QUOTE > > FreeBSD does provide pre-built packages for armv7, now much > better than when qemu based building was in use. (The aarch64 > based builders can execute armv7 and are used for armv7 > package building these days.) > > (armv6 builds uses qemu on amd64, which significantly limits > what gets built and provided: lots fails to be built. armv7 > use to have that status as well.) > > Also, the likes of: > > http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/ > > does have some armv6 and armv7 materials for 12.3/ , 12.4/ , > 13.0/ , and 13.1/ . The wording above might stop someone > from even looking for the material. (This sort of status > is not a recent change.) Sure looks to be official material. > > (No implication of a change from Tier 2 for armv7. But the > existing wording used to indicate example justifications is > --and has been-- misleading.) Extending wordings associated with each Pi dd image, would be very welcome, to specificaly list all hardware version of a Pi each image of v6, v7, aarch64, the image should boot. As a newbie to Raspberry Pi (but not FreeBSD) I have long been confused which image is for which version of Pi hardware. I previously had some kind of a 3B, & now have a "Pi 3 Model B+", but have not got beyond booting images, starting to customise /etc/ & then it crashes yet again, needing yet another dd, & repeat, Being certain one is using the right image would be nice. My notes: http://www.berklix.org/~jhs/pi/#images Cheers, -- Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK Arm Ukraine, Zap Putin. http://berklix.eu/ferries/#dover_solution From nobody Wed Dec 14 02:59:55 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NX0Tm2C5gz4kYmf for ; Wed, 14 Dec 2022 03:00:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NX0Tk75nKz4JGy for ; Wed, 14 Dec 2022 03:00:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gDbgqvuP; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670986807; bh=A0tiQCSU/diBNaLdZ7lTJZSntkv2sgQnCZTQkHEmgJM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=gDbgqvuPdypvXgz6FP93AXFuaKwZd2yuNsYNq+Akzb2RusuUnfne3xmnMGyu4VU3uyU7EkA0z+f05MACwF6xe/P0Zc4okHR2yf4B8fQr1bBcxMqNH26fNx1QdwOM49NDbNSsufzAjxC5oCbRpjiH99ejRVgT8mrDCJB07Sr0XyXQ1pAppde37KWNvSBszkqwikJmcjxw/Sc64VCSFqJFbkV+JTXvngunlBTax0Yd4afW9mZYMbDmCqoLU5e3WAl6SerPQcSGtZGFQBsVMgohqZ69fHS1ksWGev3V/DmHnJW5eDwknevFVCq/eELx5MJ1UTycYeJA5AicJqrZOxKO4Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670986807; bh=9ExPkV28dBr6knokbpUVoLtfA+NLe5fH3iU8AbPW+uf=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Yu/bKKfK/EYrbxA8oF/TXysT5lBZffk5fED+tFwBUdTgjVtzveqrZxRcKQevwANvVKdK79dV70938mG5OJ3Yf9hKcU99wLVATwZwbryMM6+IalYctTjEFvPMb4+9T9O0bn90HxTRDHJtcPTflV2AZi/CaI7az+SUG0H6vI2ogXN86wUrrHukVs5ubvKc6Y+3MCmTJvYcGKcJCwDHKzkuZOnyZgANiO/PA9B47ioNi9tLqsOh7HLvsPnxxStEHIrqjv1E75IXo9PZYLXxDZrB2J5HyxjLAJ4UE5KYSeEvg4cSW7fNZk5TShddCPTFd6OBk4w7j8Q0/TrWq5lCjiWDqw== X-YMail-OSG: wX7wQVoVM1mgoNJIwJEU1gvFVACuudwmCNgqKUpxRumz4gIy3HAtjTvlWSpbLa9 sqxd8ZE9tVEZrHhF5J1ylYuhs9K5i6o_lhAEVQatdUHF7MnJHRAFAoiUBEFfX12zKWoXy8fK0qXV Ox3MrhNkT8l.44._Wy8TwYlW8T5Oy7cGo_B.46.kmpPl5O9iORtcfcZ3rUe30X50u9dz6xjNKbyp BIIMZXjXbY.38.pLMex76Ii39Njp5OsxpY0t55DbSt._zY1MND5Hr4OuRscADbKsvZAqFDNRE.Rh SL3XwTw8HQW6rwZf8pPg42dVFtsZEoycSR1Rn6DLCSWFxRT8nSmUNsxlSTZIi2QTp80ELBlRuAFi 0tQ2tvNwDuSvLEzXACFb33E7vRQLyZdfkwjbt_d0XagL2sRx_p.18bv2K.rLcyTmnxkTDO.pmfob N0uuBp76dMNVicLZvw6nSSQrLvFkDYF3WlKwsUID5kLyzaHw8pqlUPsPvg2AKVr_y8PsT6StOa2i PEba39YtMr4ntocLsH1f2Z01Ldus0OLhGoVt7VdJcdEFTBeH.ygXoNv5Esue7NRewAA2jGGtJNJL XPM8W4eoJZUem2U0AiYayaxGBirOnX6QkoAP_itSV0tGBhNMzslYgSka0r1mW1hCAlwtu60fphNU cnbFAqBD2ERSH4ALcb3Ylx0ksrTgtKf3nPXAO5an0QzyQbshhLEQ1fNfw.aVkp4.LCGrDYkVbY2Q ze5FeQHfhYiJgJgemCUPOAqOACOxOt4ErT6JH9hm49SWCm.tbbk28m1eR6bjKSDzDNQI46bna0Fl bjVzsRPZsTCAi_8obq._LNLrfxBZpp6xyt9SYeO552WrfTi95hkC9ymi4pvVobjubtO8mkzCJvJK rDDQHonlrB4liPAjFKfwLO1fWxWygjM9OoXgQytP4ipFnilLA1TktTigA3o325goYaaATmdi25XY ZZCb.rqkUBgAS8YeVNOjdPW_N.ChvIcFRZ.nolI08iF9Un1QFwIYVHlCeL8Xww8VkufEkSjoIuQr LT_pkXM8HOHBZUv9sUpSZaWbA5OVjpuT0EtmbCri6vHVrUaBlQUGWbkfpmbK_FHYDqs8JbEtvN4c QUc7F.3niNbjOJrQF.B.v26hWZS.D0IApejREgwikb7S0EpebPD80TZG36Ios82QCcA6wx0lHCPA XVLcvTlU8zUqnouEXEDJWxSz9.0LN_LTfJtC0oeDrz85B3qFcuqMj_M5qrXFBF1BQU1NiJSTPSjd VnctkqoYh5iRxjHUGkqfTKmQyDNZcH8eTqsYWgJ0O79HaHXXdlrID_0ovOaxOovCM6gwyXwMwope _w5Dke0Mo7P20zqJXAhd3S_wtCAd86V.PVhKv9twB6GaQvpXOQudtswxDOGo_S_BzfZgueNRCi99 yLRcAqrqzM0LM2R8MgA9OFC0PtjhqVwPnjQ8TQdXvAmcNbiBJ08I7xKAzEAbPLZTOnbDbUAGFaW5 R5EJ80Uv25b0z0Bb_Yc1ciol9fhZ7kvTeOM2mNwt_P2JtvqRVY2YpdlYNOI5yswrnwVUzp3wVqgE PoZYuI.DtW6cqvojUeSldbLxIEyC8aIQcsTRK0bkRclXFnNxYAKuvWy9f0NarYlyldldz0ejVzos zdzx9buoU.ruN6ALcDD0vy2B.kBKZF5BW6eZJMXznwMuBe0G7qSdsF_tZnI91N._Pho.1KOXsNwm InZS.mwRkvzynZYH4dAT6WNJTTAQG4UAP6w_bKfHacD6X1PJp_3ziNBqJPw9E1wNMvHJa.GHoVhC Yk9pkvtml.1tZcl2G46.ye_dyl45C0X.uMc7p2HmQya.COIUb2pINKJu1tLqAyzvvU0y9Rg_LCCl 6U6Mi.nP0iEr9Gu7SoLE8kcA2Kb3_m4fOykmIqyg007LBoNvvWmC15.MizPlQxKQKw5QH5_Ig9yZ ZP9UnSgI_r0q1sf01Z.1_O9d7DfceJ4hO1pj68ot0KniLkP35ta6EwUBAO6sggjR19UQ1.hdrCkB fq_gaRE9iMXjEkuloTH38ge4lw5UtErMAeVqhNOI0df4R2U.2YoXIcUHOhTNoNNdBLF_Ra4fPNFO i2MV3m7P.q8urwzuxtPdoLkg6NPqbbzS36cvPat2KsJK.86l7opSj9IlsTe_zM2qaatPNih89qw4 MWDkhneEMHkAUhG3BM3su995SxWNqkCqHLfj9OD1lzKDN6d7ZeZYm26Ge0XNjvEK0wCJOZXkPOBx a8Mi1Kod4b2WNde_j4kjzObh2NRyawXQm4j33QD12Y5Kqo6stYhaXD3PQWSC4HNOZzI0z66aeDH0 C X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 14 Dec 2022 03:00:07 +0000 Received: by hermes--production-gq1-d898c4779-vt5gr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3ede138ed9bb1f1b75b5c7a5c33fc9d9; Wed, 14 Dec 2022 03:00:06 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed Message-Id: <2B085458-762B-423F-AD83-054E6762D654@yahoo.com> Date: Tue, 13 Dec 2022 18:59:55 -0800 To: jhs@berklix.com, freebsd-arch X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <2B085458-762B-423F-AD83-054E6762D654.ref@yahoo.com> X-Spamd-Result: default: False [-3.43 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.930]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from] X-Rspamd-Queue-Id: 4NX0Tk75nKz4JGy X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Julian H. Stacey wrte on Date: Wed, 14 Dec 2022 02:22:10 UTC : > Hi, Reference: > > From: Mark Millard > > Date: Tue, 13 Dec 2022 15:52:16 -0800 > > . . . > > Extending wordings associated with each Pi dd image, would be very > welcome, to specificaly list all hardware version of a Pi each image > of v6, v7, aarch64, the image should boot. > > As a newbie to Raspberry Pi (but not FreeBSD) I have long been confused > which image is for which version of Pi hardware. > > I previously had some kind of a 3B, & now have a "Pi 3 Model B+", > but have not got beyond booting images, starting to customise /etc/ > & then it crashes yet again, needing yet another dd, & repeat, > Being certain one is using the right image would be nice. > > My notes: http://www.berklix.org/~jhs/pi/#images This subject area is more appropriate to freebsd-arm than freebsd-arch. So I'll reply again, but to the freebsd-arm list instead. === Mark Millard marklmi at yahoo.com From nobody Wed Dec 14 15:50:35 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NXKZw6GCgz4jg0Q for ; Wed, 14 Dec 2022 15:50:48 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NXKZw4BPcz4lMw for ; Wed, 14 Dec 2022 15:50:48 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-f179.google.com with SMTP id d7so3731329pll.9 for ; Wed, 14 Dec 2022 07:50:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=kwEY/Xb+wnl1E7RS5sxenT8lNg5w0Se/uaq9hCyEofY=; b=NdEetKeAcX8jT62H9RoxoKcUzQkOb1GUujURwzSdUPVYUV0zbS47/eWw5veNZavElW yCyNjJ5lxq+4im5Zeb+4s2nlt1ErADU0VsmZMxYl8hsBTUhmJqD3Io2qhpkO94ELUMJ+ kN6yDZfmPHqvyx6DSKqvKLF0u7PZS2AYp1rMsYvMA/01MQG5Fc6AvKSH96M5uM3i6hqZ uJofpSbvamJpFnjVqEZiRwrVAS1YnRhBALLqyH3FJcBMiIS9DHNRkt0x0Mon7GSEE9fP cmLIyjF5EP9NjpewM9g0T8a1dRly9P/ZnS+otWJY2G2xFcZvWlRm/deIxB+j9snMxcwz H/Gg== X-Gm-Message-State: ANoB5pn+FHAm5mcLTXFgPetzMVegPH8QZvo+fwYPtJOr2hK+IHfTqjY7 XCTGVmpT3wcu2ItKo9zEYGKkZWnu4hf0sSAf9KxtbauixxA= X-Google-Smtp-Source: AA0mqf78SIyb2jwVbGkzPNnS2W7izfObtJhCl/7fT9JmEIOIaVEuN+Br9WBnZXvbCfxfsJA/p4ndh1IiSZu0FYIyEU0= X-Received: by 2002:a17:902:7e08:b0:189:fae5:e957 with SMTP id b8-20020a1709027e0800b00189fae5e957mr6133789plm.85.1671033047142; Wed, 14 Dec 2022 07:50:47 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202212140222.2BE2MAoG074349@fire.js.berklix.net> In-Reply-To: <202212140222.2BE2MAoG074349@fire.js.berklix.net> From: Ed Maste Date: Wed, 14 Dec 2022 10:50:35 -0500 Message-ID: Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed To: "Julian H. Stacey" Cc: freebsd-arch Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4NXKZw4BPcz4lMw X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, 13 Dec 2022 at 21:22, Julian H. Stacey wrote: > > Extending wordings associated with each Pi dd image, would be very > welcome, to specificaly list all hardware version of a Pi each image > of v6, v7, aarch64, the image should boot. > > As a newbie to Raspberry Pi (but not FreeBSD) I have long been confused > which image is for which version of Pi hardware. The Raspberry Pi model naming convention is indeed confusing. The armv6 Raspberry Pis are those with the BCM2835 SoC. These are the original Raspberry Pi (A, B, A+, B+) and the Raspberry Pi Zero (including W variants, except 2 W). These are all the ones that would be desupported after FreeBSD 14 in Warner's proposal. Raspberry Pi 2 uses armv7 images. You can use aarch64 images on 3, 4 and Zero 2. From nobody Wed Dec 14 16:10:29 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NXL1s4JcFz4jj7m for ; Wed, 14 Dec 2022 16:10:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NXL1s2Y1xz3FPJ for ; Wed, 14 Dec 2022 16:10:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id vv4so45701416ejc.2 for ; Wed, 14 Dec 2022 08:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=e1gI76ZClw7btF/eW7ecgTIi0Ga/zVsfXcqD4TpkZ9w=; b=na6DJO3sQ/yY8eFyWQ+z099iEHcfNqiHdJuXq2rvGURN8IDYBzYtUFY/pUs5QMTEEy mLyDi1KRL5ps5HCjitUUGwQ+i7CZ9a7XNY7RSHsk0Y/5ydzty40FSNsT0i0nTmZaEU0C Z51xS4aV9AxYu2jWFX3EZznFI1DUadmxKVPDPdRWzqC9DsgEXL1JNdQFB6VEkWvV3nP2 zesZWGdVS3XbH5vlVyJ5g28DZFdc7KmUt3BGvGGRaaGR9K/dLTIJph+G1TPEPD+HTjkd XfFWlxMsO9BWl0uDseVXvUj9CtbF6Qg4rBRg1bwfNwQWXsFguRL2CCECNwpK4nHsKU8p Os7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=e1gI76ZClw7btF/eW7ecgTIi0Ga/zVsfXcqD4TpkZ9w=; b=sbGdw5t3Dd/8tfty2pdX1bFVzrmUKSK0JQ9l7uffb17wMJVvkaItSsl89sBA8yjb9S 1OR17PHZ8e5dXCBksxDINGQ4PZDseEWCVZL1YXxo8vWULM5jbkJag9qEzr+ws0fgmX42 o2Ql4TTHxUWr4fDt90qCDlXx/jDJl6XsQ3GkQA+9oeni7ZHjMHFQtlXhC23dvlsinUp9 VvWelbKKnMJ3DVSbAdYrmxWmZ7VzcSLZTTt+ieedJH86yf72sDtpVwmgI+48Jdmr8lU1 al6ymGDfpE+SdM8WAjPKlUeiwwaLYrQJk08QlvLZKpFh/HQwGV2OifMvdrSgUhLHoWCk L88w== X-Gm-Message-State: ANoB5pljyNVJ0oJ6Z4CzPik9Vpfs9+Bs+Ll+AQnWgtJfIdTRnMrUE0yZ +1gMGUFbJysSuEwGEiwi2u6/sHJipqdsgcief4N0aPkwYEQepw== X-Google-Smtp-Source: AA0mqf4iZSEva2RQ3T7IB2a7aZjtg36mDqgTGYBev8tT/NmkxutpOdEiPRKfKA8/ivNhkSA/ciNDEmpHVOFCoBpqkJQ= X-Received: by 2002:a17:907:98ed:b0:7c0:e7a6:cd2d with SMTP id ke13-20020a17090798ed00b007c0e7a6cd2dmr16294365ejc.317.1671034240068; Wed, 14 Dec 2022 08:10:40 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202212140222.2BE2MAoG074349@fire.js.berklix.net> In-Reply-To: From: Warner Losh Date: Wed, 14 Dec 2022 09:10:29 -0700 Message-ID: Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed To: Ed Maste Cc: "Julian H. Stacey" , freebsd-arch Content-Type: multipart/alternative; boundary="0000000000004985d205efcbfa3c" X-Rspamd-Queue-Id: 4NXL1s2Y1xz3FPJ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000004985d205efcbfa3c Content-Type: text/plain; charset="UTF-8" On Wed, Dec 14, 2022 at 8:50 AM Ed Maste wrote: > On Tue, 13 Dec 2022 at 21:22, Julian H. Stacey wrote: > > > > Extending wordings associated with each Pi dd image, would be very > > welcome, to specificaly list all hardware version of a Pi each image > > of v6, v7, aarch64, the image should boot. > > > > As a newbie to Raspberry Pi (but not FreeBSD) I have long been confused > > which image is for which version of Pi hardware. > > The Raspberry Pi model naming convention is indeed confusing. The > armv6 Raspberry Pis are those with the BCM2835 SoC. These are the > original Raspberry Pi (A, B, A+, B+) and the Raspberry Pi Zero > (including W variants, except 2 W). These are all the ones that would > be desupported after FreeBSD 14 in Warner's proposal. > Yes. The original Raspberry models are hard to come by in volume these days, at least relative to the later ones. Even the RPi 2's are hard to find, relatively speaking. Sure, you can find them in the after market and on ebay, but they haven't shipped in volume from Raspberry in years. The Zero and ZeroW are more available, but have always been poorly supported since we don't support any networking on them that's not a USB add-on device. There are a number of follow-on products from both Raspberry and others that fit the niche of the original Zero and ZeroW. > Raspberry Pi 2 uses armv7 images. You can use aarch64 images on 3, 4 and > Zero 2. > The RPi 2 1.1 and earlier uses armv7 images, but the 1.2 and later can use aarch64 images. Modulo missing dtb files, you can also boot the armv7 images on later rpi if you want / need to. I've not tried it lately, but have done it accidentally a few times over the years on the RPi 3's that I often confused with my RPi 2's when I'm not paying close attention... I don't think it's an officially supported and tested configuration (though the best way to find out is to make an absolute statement like this in public). Warner --0000000000004985d205efcbfa3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 14, 2022 at 8:50 AM Ed Ma= ste <emaste@freebsd.org> wr= ote:
On Tue, 13 = Dec 2022 at 21:22, Julian H. Stacey <jhs@berklix.com> wrote:
>
> Extending wordings associated with each Pi dd image, would be very
> welcome, to specificaly list all hardware version of a Pi each image > of v6, v7, aarch64, the image should boot.
>
> As a newbie to Raspberry Pi (but not FreeBSD) I have long been confuse= d
> which image is for which version of Pi hardware.

The Raspberry Pi model naming convention is indeed confusing. The
armv6 Raspberry Pis are those with the BCM2835 SoC. These are the
original Raspberry Pi (A, B, A+, B+) and the Raspberry Pi Zero
(including W variants, except 2 W). These are all the ones that would
be desupported after FreeBSD 14 in Warner's proposal.
<= div>
Yes. The original Raspberry models are hard to come by i= n volume these days,
at least relative to the later ones. Even th= e RPi 2's are hard to find, relatively speaking.
Sure, you ca= n find them in the after market and on ebay, but they haven't shipped
in volume from Raspberry in years. The Zero and ZeroW are more ava= ilable, but have
always been poorly supported since we don't = support any networking on them that's
not a USB add-on device= . There are a number of follow-on products from both
Raspberry an= d others that fit the niche of the original Zero and ZeroW.
=C2= =A0
Raspberry Pi 2 uses armv7 images. You can use aarch64 images on 3, 4 and Ze= ro 2.

The RPi 2 1.1 and earlier uses ar= mv7 images, but the 1.2 and later can use aarch64 images.
Modulo = missing dtb files, you can also boot the armv7 images on later rpi if you w= ant / need to.
I've not tried it lately, but have done it acc= identally a few times over the years on the RPi 3's that
I of= ten confused with my RPi 2's when I'm not paying close attention...= I don't think it's an officially
supported and tested co= nfiguration (though the best way to find out is to make an absolute
statement like this in public).

Warner
--0000000000004985d205efcbfa3c-- From nobody Wed Dec 21 14:58:05 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ncc5F0sv1z1H7nY for ; Wed, 21 Dec 2022 14:58:25 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ncc5D1xFkz4NNQ; Wed, 21 Dec 2022 14:58:24 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=none Received: by mail-pl1-f169.google.com with SMTP id w20so9171332ply.12; Wed, 21 Dec 2022 06:58:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=6JtwNsNrGwTMf+i9ImxOFoztAx72vAsiJPVyxnifX8o=; b=Zd65eTmzTa49d6TYodNuLFX/f/l0n3gjYsCQ6v45NZ8P+0PdiN5uypzqmBS7rE5wMA ugYeAlwI4HR5kvhYV83tNPz4PuCI7eYOXgSkzQ7K+lLjd3/1Vrp20C6P3m8qumdxambe Mwlq5iV8VxyWIIONwaVj7zj/+wNamS5pVuDJMdgrZDj/ter4mUbPNmBmLSngjFBPRKiG vWXeRJ8yOLugRWB4DVIImCrZS2Nw1B3OVwtL5AAMtTrKCgvO2CrdjHDsmZtjJjDaKUJ8 Mv+H1e5LmFkZ2YV8Ju39+R74u9JgFDb/I+NAqDCPYzhwA+dqKE53VcvdeFy7//WFvnGQ nT5w== X-Gm-Message-State: AFqh2koF/mFEDkzVb3QKEFIzv7s0Xn9ekabzL+YHqZDUnN0x+J1Sy7UR NAaXiSh0zeXkgbV1p7ht9kfNOWeDOjjc6AyINh89Lonh X-Google-Smtp-Source: AMrXdXtJnwQw+PVQ4Ca7NWOX7NXmB/03pn5m16NAoL28ZVKpmHOlPeJaDYjFVK59Ib27R5KrxqiryBGtsxXRAO2khe4= X-Received: by 2002:a17:90a:f86:b0:219:ef02:b354 with SMTP id 6-20020a17090a0f8600b00219ef02b354mr160330pjz.168.1671634701439; Wed, 21 Dec 2022 06:58:21 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <20221123143359.2370ed89@ralga-linux> In-Reply-To: <20221123143359.2370ed89@ralga-linux> From: Ed Maste Date: Wed, 21 Dec 2022 09:58:05 -0500 Message-ID: Subject: Re: Modularizing the network stack with a driver API To: Justin Hibbits Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.13 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.214.169:from]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.03)[-0.028]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[209.85.214.169:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; FREEFALL_USER(0.00)[carpeddiem]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Ncc5D1xFkz4NNQ X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Wed, 23 Nov 2022 at 14:34, Justin Hibbits wrote: > > Most of the work I've done in the recent port has been purely > mechanical and scripted, fixing build failures along the way. The > current work in progress can be found in my personal repository at > https://github.com/chmeeedalf/freebsd/tree/drvapi . The goal of this > first step is to get things started, address design feedback, and move > forward in main. Thanks for picking up this long-neglected effort. One comment, let's make sure that documentation gets updated as we go - right now ifnet(9) documents struct ifnet's internals and makes no reference to any of the accessor functions. The man page likely needs significant work at some point as it's already quite long, but we should at least mention that direct access to ifnet internals is undesired, and list the accessors.