From nobody Mon May 17 10:01:52 2021 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 62FE08581C0 for ; Mon, 17 May 2021 10:01:55 +0000 (UTC) (envelope-from avg@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 4FkF6C2Sb6z3lfb for ; Mon, 17 May 2021 10:01:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 0799C2599B for ; Mon, 17 May 2021 10:01:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Subject: Re: adaptive spinning: fall back to sleep / block? From: Andriy Gapon To: arch@FreeBSD.org References: <202102251856.11PIuxwF020948@gitrepo.freebsd.org> <19884f0f-115d-a60c-2ef2-72400f96f8a7@uabsd.com> Message-ID: Date: Mon, 17 May 2021 13:01:52 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.10.1 List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/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 On 09/04/2021 12:56, Andriy Gapon wrote: > > > Until I recently looked at the actual code I was under an impression that > the adaptive spinning is bounded and that after some time / number of spins a > thread would go to a sleep queue or a turnstile. But it looks that the spinning > is actually unbounded as long as its conditions hold (some other thread owns the > lock and that thread is running, the owner could be changing too). > > In my opinion, it does not make sense to spin for "too long". > If there was not an opportunity to take a lock quickly, then it's better to > block waiting for it rather than keep occupying a processor. For instance, the > spinning can prevent another runnable thread from running. Any opinions about this? Thank you. > I think that if a lock is heavily contended or its hold times are on the longer > side (or both), then the adaptive spinning can make the system behavior > (performance, responsiveness) worse. > > Finally, I was under an impression that 'adaptive' meant some heuristic on > whether and when to do the spinning. _A lock owner is running_ seems to be too > simple to qualify as 'adaptive'. > > As an example, this looks like a relatively sophisticated implementation of the > "adaptiveness": > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.cpp#l1919 > But, JIMHO, simply having a hard limit on the spin count would be better than > what we have now. > > P.S. > This is not an area that I know well, so my confusion and ideas may be absurd. > On the other hand, I could not find any justification for the current unbounded > "adaptive" spinning. > > -- Andriy Gapon From nobody Mon May 17 10:23:20 2021 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 9F40B85CF8D for ; Mon, 17 May 2021 10:23:23 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkFZy3R0gz3qBJ; Mon, 17 May 2021 10:23:22 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lf1-x135.google.com with SMTP id j6so5331145lfr.11; Mon, 17 May 2021 03:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dAvc/3h0mweo/jZePq27EWd/2HbO5xC/+7M9Cw0hi4Q=; b=YnXheMAJPRXdiCsLfTNinggHufx7ocMa8u2NtuocgfTJ0gnY2piUAk8BlsH9z+oQbX DyAKZGBPKDIi3wznJmuf8YW0c0woJxDq2AaV3buYuTaWSTwjkQ2v4F/qfTVK4Uiy7rSU BBo3JY9r9mPanf5gGVKs/z4qaINhV4r3B9MK9gZuJFcGw5SjHHfiegySvg9xEWZ4ageg Q6l2d1cvBb2L1Uafz8GdSTWVA1C9EOA8JnVYZJsD6AqFLq1IcXJvH4M4thOBmAMxjiZ4 4oa9i1VkowyVBATGrc/VUBjnC9a0LEfZwyY7Z9kf9uUeTyg1zDqNsGFG+h/Ri0FzPP2s 3OAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dAvc/3h0mweo/jZePq27EWd/2HbO5xC/+7M9Cw0hi4Q=; b=HOhE/PFbE/2PUzuEw4ooJV0XovkamoNfWpapYT7zD/zLYKCfWEcFO7zGwLLc1LegWi ShwJxY3coqNEQ9AUvO9j2gvmvlFrBt0ZPdblweDFyM1saM6+5Zjze0hkUJpusYwo3fpB TcgZKc/XCD2GwJHCxzJcjrhtyBvQFJvsgl6H4Vn5H2HhPVSWbxMOAkNFZUHnsnd5zO6x 0wCRe9k1Il+0MAAOxoeMXL/5jBHiJI7AgaF7HdNZO+Pwcr22GhTPBPSsi4l/JTfVqk3Y uah148FrXZ69snEzqgGxiZi8GokU7akizERMT3opm8Da1s2bw4RT3XSMcpMxhNuEwaZy D95g== X-Gm-Message-State: AOAM531wj8YpHFous/DxaQMqFKGMJ2+w8DWkso0es3kgF2R79URj/KbK gPJU0f1ZlOcE9087AgEqmXHOrVdkdO3DewZaxPyWc5+k X-Google-Smtp-Source: ABdhPJz4DgZkPbZSJ2CcDwY3VpbRbffBJXS22wwUJCw0ZjXo4u2BISqmp08APhvN11UUjAvzlaEKHttz3/6oNaE7fgk= X-Received: by 2002:ac2:4470:: with SMTP id y16mr8687599lfl.266.1621247000863; Mon, 17 May 2021 03:23:20 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:485:0:0:0:0 with HTTP; Mon, 17 May 2021 03:23:20 -0700 (PDT) In-Reply-To: References: <202102251856.11PIuxwF020948@gitrepo.freebsd.org> <19884f0f-115d-a60c-2ef2-72400f96f8a7@uabsd.com> From: Mateusz Guzik Date: Mon, 17 May 2021 12:23:20 +0200 Message-ID: Subject: Re: adaptive spinning: fall back to sleep / block? To: Andriy Gapon Cc: arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4FkFZy3R0gz3qBJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=YnXheMAJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.28 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.85)[-0.854]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::135:from]; 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(-0.42)[-0.425]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::135:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::135:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[arch] On 4/9/21, Andriy Gapon wrote: > > > Until I recently looked at the actual code I was under an impression that > the adaptive spinning is bounded and that after some time / number of spins > a > thread would go to a sleep queue or a turnstile. But it looks that the > spinning > is actually unbounded as long as its conditions hold (some other thread owns > the > lock and that thread is running, the owner could be changing too). > > In my opinion, it does not make sense to spin for "too long". > If there was not an opportunity to take a lock quickly, then it's better to > block waiting for it rather than keep occupying a processor. For instance, > the > spinning can prevent another runnable thread from running. > > I think that if a lock is heavily contended or its hold times are on the > longer > side (or both), then the adaptive spinning can make the system behavior > (performance, responsiveness) worse. > > Finally, I was under an impression that 'adaptive' meant some heuristic on > whether and when to do the spinning. _A lock owner is running_ seems to be > too > simple to qualify as 'adaptive'. > > As an example, this looks like a relatively sophisticated implementation of > the > "adaptiveness": > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.cpp#l1919 > But, JIMHO, simply having a hard limit on the spin count would be better > than > what we have now. > There is no clear cut answer to this that I'm aware of. Ultimately all behavior in face of contention is about damage control. It's not hard to make a counter point to going off cpu after a timeout: 1. going off cpu is also a serializing operation, that is threads can content on doing so, albeit less than on the original lock 2. existence of blocked waiters makes it more expensive to release the lock, making contention worse and even then it is unclear what wake up policy you would like to enact (e.g., do you hand off the lock to the oldest sleeper? do you wake everyone and let them fight it out? all choices suffer problems) 3. consider a thread which holds foo_lock and now contends on bar_lock and decides to go off cpu. if there is a thread which waits on foo_lock, it will also go off cpu. This kind of behavior easily leads to dramatic collapse in throughput, even on top of whatever problems which are present due to contention to begin with. Now, locking primitives in the FreeBSD kernel are problematic in at least 3 ways: 1. there are no fairness guarantees, for example a constant stream of threads can end up excluding some threads for a long time 2. there is no support for locking under kvm (as in the kernel does not take advantage of it) 3. rw locking is using cas loops instead of add imo, if doing anything serious with locks, the 3 above problems needs to be solved, in that order. I can't stress enough the lack of fairness, which arbitrary going to sleep will only exacerbate. As noted earlier, I don't know if timeout sleep is an inherently good or bad idea, but I'm confident playing with it in the situation is on the bad side. -- Mateusz Guzik From nobody Mon May 17 11:44:34 2021 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 AC9EB84D55F for ; Mon, 17 May 2021 11:44:36 +0000 (UTC) (envelope-from avg@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 4FkHNh4X1pz4Y8n; Mon, 17 May 2021 11:44:36 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 2EBD426A82; Mon, 17 May 2021 11:44:36 +0000 (UTC) (envelope-from avg@freebsd.org) From: Andriy Gapon To: Mateusz Guzik Cc: arch@freebsd.org References: <202102251856.11PIuxwF020948@gitrepo.freebsd.org> <19884f0f-115d-a60c-2ef2-72400f96f8a7@uabsd.com> Subject: Re: adaptive spinning: fall back to sleep / block? Message-ID: Date: Mon, 17 May 2021 14:44:34 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.10.1 List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/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: 8bit X-Spam: Yes On 17/05/2021 13:23, Mateusz Guzik wrote: > On 4/9/21, Andriy Gapon wrote: >> >> >> Until I recently looked at the actual code I was under an impression that >> the adaptive spinning is bounded and that after some time / number of spins >> a >> thread would go to a sleep queue or a turnstile. But it looks that the >> spinning >> is actually unbounded as long as its conditions hold (some other thread owns >> the >> lock and that thread is running, the owner could be changing too). >> >> In my opinion, it does not make sense to spin for "too long". >> If there was not an opportunity to take a lock quickly, then it's better to >> block waiting for it rather than keep occupying a processor. For instance, >> the >> spinning can prevent another runnable thread from running. >> >> I think that if a lock is heavily contended or its hold times are on the >> longer >> side (or both), then the adaptive spinning can make the system behavior >> (performance, responsiveness) worse. >> >> Finally, I was under an impression that 'adaptive' meant some heuristic on >> whether and when to do the spinning. _A lock owner is running_ seems to be >> too >> simple to qualify as 'adaptive'. >> >> As an example, this looks like a relatively sophisticated implementation of >> the >> "adaptiveness": >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.cpp#l1919 >> But, JIMHO, simply having a hard limit on the spin count would be better >> than >> what we have now. >> > > There is no clear cut answer to this that I'm aware of. Ultimately all > behavior in face of contention is about damage control. > > It's not hard to make a counter point to going off cpu after a timeout: > 1. going off cpu is also a serializing operation, that is threads can > content on doing so, albeit less than on the original lock > 2. existence of blocked waiters makes it more expensive to release the > lock, making contention worse and even then it is unclear what wake up > policy you would like to enact (e.g., do you hand off the lock to the > oldest sleeper? do you wake everyone and let them fight it out? all > choices suffer problems) > 3. consider a thread which holds foo_lock and now contends on bar_lock > and decides to go off cpu. if there is a thread which waits on > foo_lock, it will also go off cpu. This kind of behavior easily leads > to dramatic collapse in throughput, even on top of whatever problems > which are present due to contention to begin with. > > Now, locking primitives in the FreeBSD kernel are problematic in at > least 3 ways: > 1. there are no fairness guarantees, for example a constant stream of > threads can end up excluding some threads for a long time > 2. there is no support for locking under kvm (as in the kernel does > not take advantage of it) > 3. rw locking is using cas loops instead of add > > imo, if doing anything serious with locks, the 3 above problems needs > to be solved, in that order. > > I can't stress enough the lack of fairness, which arbitrary going to > sleep will only exacerbate. As noted earlier, I don't know if timeout > sleep is an inherently good or bad idea, but I'm confident playing > with it in the situation is on the bad side. I agree with you. And it looks like we do not disagree in general . I just want to make a clarification, maybe redundant, that you seem to be mostly concerned about effects on threads that contend on same locks or related lock chains. I am more concerned about effects on completely unrelated threads. Yes, sleeping and waking introduces overhead (and not only) on threads doing them and threads depending on those threads. But spinning, when it happens on a large share of CPUs (e.g., ~ 100% of them), introduces a penalty on the whole system. At work, where a substantial part of our application lives in kernel, I regularly debug issues that seem to happen because of CPUs starvation. And a common theme between them is that many CPUs are tied in the lock spinning. FreeBSD as a general purpose OS does not seem to suffer from the same issues (at least, that I know of), but we have quite a lot of additional kernel threads and kernel locks. So, maybe instead of trying to experiment with FreeBSD I should try to experiment with our derivative product first. Thank you for the feedback and additional information. -- Andriy Gapon From nobody Mon May 17 12:49:08 2021 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 05C1585AEFD for ; Mon, 17 May 2021 12:49:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkJqC6S4hz4kbY; Mon, 17 May 2021 12:49:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lj1-x234.google.com with SMTP id v5so7044525ljg.12; Mon, 17 May 2021 05:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gFO5Pm4ZvV0Q5lXy2dyYLTyMae7gHzlswkMn4+evqNw=; b=mIp04LAOM//JNBXQdGrZa39AZIpKggPbpLRRELWqfM/xU7+h0kBSitOIuVLBh5oV6w G/0xb5vfFLvVRytvOIeOdGSHLyOuLg58fFNmgBZxiBJqLOK7X4ALR0pgEvK5ryiKMDTX hYC4oAQcSmN0qB85vdUA0IK92VUxAP5IFMnPwnE1ziUB80+3niP1x+7v/K+/PF6cxQCR hfeLosXND6Cp6ajtsQaqH/JjuuKbIj3c/9ELueddz4AFgYUcvnmRJHJZ9XRAzfbBUVcA pIlMHQIn7UiFwtapWpMXIFubR6n/2je9ZWwsU9imINNFyoVo0TWBnTt8GymB8M2iL/k7 iJig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gFO5Pm4ZvV0Q5lXy2dyYLTyMae7gHzlswkMn4+evqNw=; b=NkBW7liXhHy5cXI0iJodq0VKiI9PgSbgyh+xDuZ/uZhhbmiv0hjf/hjv6E3CJvyNHZ jDwckVN0En7eFckf/bMrdNqZjNX5VHCTxSCi9+E7kxHGnw3V27hcHRUy1GvqjM1dl/9V S0qx8yiRYa3FZ6hB6B1Ljjn0v/qKQ+qJWzzXixA3NhkbOcpm8XT+YwviJZZomGn4YLig 1AOC+CfgHfckbGg29msHFUibbfZM3UOEuERTd4Fw0Q3sWzB0q3RNmMhY5RgD8md+th06 6aqmLkVr0YuZuJb1kERyl+fD1qeyaKgHVJZ23Tsn7En8JqiqHA1MESPT46sUlPp9wfIc UmJg== X-Gm-Message-State: AOAM532EgYddKQojCiXfuAyYyYG8TGAiDrrTe0igowqhDES/QTFEQYFS Gf/+a/1kdM+CsIl+8i0NsKaYJwYCrBOlKqi9AMEqwyyZ X-Google-Smtp-Source: ABdhPJyN2wlxw15RqucTNyLaI38ZZBPqFIpnWwcAEyNKXHUFRcA/23JLQmlfUDfnfDfKl9rXHOISW5fZrOFbPoPtq88= X-Received: by 2002:a2e:b605:: with SMTP id r5mr47491933ljn.483.1621255749474; Mon, 17 May 2021 05:49:09 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:485:0:0:0:0 with HTTP; Mon, 17 May 2021 05:49:08 -0700 (PDT) In-Reply-To: References: <202102251856.11PIuxwF020948@gitrepo.freebsd.org> <19884f0f-115d-a60c-2ef2-72400f96f8a7@uabsd.com> From: Mateusz Guzik Date: Mon, 17 May 2021 14:49:08 +0200 Message-ID: Subject: Re: adaptive spinning: fall back to sleep / block? To: Andriy Gapon Cc: arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4FkJqC6S4hz4kbY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] On 5/17/21, Andriy Gapon wrote: > On 17/05/2021 13:23, Mateusz Guzik wrote: >> On 4/9/21, Andriy Gapon wrote: >>> >>> >>> Until I recently looked at the actual code I was under an impression >>> that >>> the adaptive spinning is bounded and that after some time / number of >>> spins >>> a >>> thread would go to a sleep queue or a turnstile. But it looks that the >>> spinning >>> is actually unbounded as long as its conditions hold (some other thread >>> owns >>> the >>> lock and that thread is running, the owner could be changing too). >>> >>> In my opinion, it does not make sense to spin for "too long". >>> If there was not an opportunity to take a lock quickly, then it's better >>> to >>> block waiting for it rather than keep occupying a processor. For >>> instance, >>> the >>> spinning can prevent another runnable thread from running. >>> >>> I think that if a lock is heavily contended or its hold times are on the >>> longer >>> side (or both), then the adaptive spinning can make the system behavior >>> (performance, responsiveness) worse. >>> >>> Finally, I was under an impression that 'adaptive' meant some heuristic >>> on >>> whether and when to do the spinning. _A lock owner is running_ seems to >>> be >>> too >>> simple to qualify as 'adaptive'. >>> >>> As an example, this looks like a relatively sophisticated implementation >>> of >>> the >>> "adaptiveness": >>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.cpp#l1919 >>> But, JIMHO, simply having a hard limit on the spin count would be better >>> than >>> what we have now. >>> >> >> There is no clear cut answer to this that I'm aware of. Ultimately all >> behavior in face of contention is about damage control. >> >> It's not hard to make a counter point to going off cpu after a timeout: >> 1. going off cpu is also a serializing operation, that is threads can >> content on doing so, albeit less than on the original lock >> 2. existence of blocked waiters makes it more expensive to release the >> lock, making contention worse and even then it is unclear what wake up >> policy you would like to enact (e.g., do you hand off the lock to the >> oldest sleeper? do you wake everyone and let them fight it out? all >> choices suffer problems) >> 3. consider a thread which holds foo_lock and now contends on bar_lock >> and decides to go off cpu. if there is a thread which waits on >> foo_lock, it will also go off cpu. This kind of behavior easily leads >> to dramatic collapse in throughput, even on top of whatever problems >> which are present due to contention to begin with. >> >> Now, locking primitives in the FreeBSD kernel are problematic in at >> least 3 ways: >> 1. there are no fairness guarantees, for example a constant stream of >> threads can end up excluding some threads for a long time >> 2. there is no support for locking under kvm (as in the kernel does >> not take advantage of it) >> 3. rw locking is using cas loops instead of add >> >> imo, if doing anything serious with locks, the 3 above problems needs >> to be solved, in that order. >> >> I can't stress enough the lack of fairness, which arbitrary going to >> sleep will only exacerbate. As noted earlier, I don't know if timeout >> sleep is an inherently good or bad idea, but I'm confident playing >> with it in the situation is on the bad side. > > I agree with you. And it looks like we do not disagree in general > . > I just want to make a clarification, maybe redundant, that you seem to be > mostly > concerned about effects on threads that contend on same locks or related > lock > chains. I am more concerned about effects on completely unrelated threads. > You can't ignore the other kind. Regardless, even the "unrelated" threads get affected by what's happening in the kernel. > Yes, sleeping and waking introduces overhead (and not only) on threads doing > > them and threads depending on those threads. But spinning, when it happens > on a > large share of CPUs (e.g., ~ 100% of them), introduces a penalty on the > whole > system. > And going off cpu can easily introduce even more penalty after you wake threads up. > At work, where a substantial part of our application lives in kernel, I > regularly debug issues that seem to happen because of CPUs starvation. And > a > common theme between them is that many CPUs are tied in the lock spinning. If you have so much contention that you run into this, the actual bug is that the workload itself does not scale. As noted earlier, playing with locking primitives is only a damage control measure. That said, even if you can't fix scalability issues per se, you may get some wins as follows: - play with sysctl debug.lock.delay_max, in particular try to lower it significantly - adding should_yield checks around lock_delay calls to go off cpu if you wait long enough may be a quasi-timeout - at least make sure the contended locks are not false shared (e.g., with __exclusive_cache_line, but warning: it only helps for in-kernel code, not modules; you will have to pad by hand otherwise) -- Mateusz Guzik From nobody Mon May 17 15:13: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 CC4AB85DFF5 for ; Mon, 17 May 2021 17:52:56 +0000 (UTC) (envelope-from noreply@wetransfer.com) Received: from kohacek.cz (cst-prg-230-120.cust.vodafone.cz [46.135.230.120]) (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 4FkRYg6tLcz4lFZ for ; Mon, 17 May 2021 17:52:55 +0000 (UTC) (envelope-from noreply@wetransfer.com) Received: from wetransfer.com (unknown [199.96.83.13]) by kohacek.cz (Postfix) with ESMTPA id 5C40455A23E5 for ; Mon, 17 May 2021 17:13:46 +0200 (CEST) From: WeTransfer To: freebsd-arch@freebsd.org Subject: info@freebsd.org Sent you files via Wetransfer Date: 17 May 2021 08:13:45 -0700 Message-ID: <20210517081344.9ACA465DE6013908@wetransfer.com> List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0012_C657D2AC.1412365F" X-MailScanner-ID: 5C40455A23E5.A429A X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-SpamScore: s X-MailScanner-From: noreply@wetransfer.com X-Spam-Status: No X-Rspamd-Queue-Id: 4FkRYg6tLcz4lFZ X-Spamd-Bar: +++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=wetransfer.com (policy=quarantine); spf=fail (mx1.freebsd.org: domain of noreply@wetransfer.com does not designate 46.135.230.120 as permitted sender) smtp.mailfrom=noreply@wetransfer.com X-Spamd-Result: default: False [7.65 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[46.135.230.120:from]; MIME_TRACE(0.00)[0:+,1:~,2:~]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:16019, ipnet:46.135.0.0/16, country:CZ]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; RBL_NIXSPAM(4.00)[46.135.230.120:from]; FROM_HAS_DN(0.00)[]; DMARC_POLICY_QUARANTINE(1.50)[wetransfer.com : No valid SPF, No valid DKIM,quarantine]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/related]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[46.135.230.120:from:127.0.2.255]; MANY_INVISIBLE_PARTS(0.05)[1]; NEURAL_SPAM_LONG(1.00)[1.000]; MIME_HTML_ONLY(0.20)[]; RBL_SENDERSCORE(2.00)[46.135.230.120:from]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,body]; MAILMAN_DEST(0.00)[freebsd-arch] X-Spam: Yes ------=_NextPart_000_0012_C657D2AC.1412365F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable



info@freebsd.org
sent you some files
Get your files
&n= bsp;
 
 
<= /TD>
=

To make sure our emails arrive, = please add noreply@wetr= ansfer.com to   your contacts.
About WeTransfer    ・    Help    ・    Legal   ・     Report this transfer as spam

= ------=_NextPart_000_0012_C657D2AC.1412365F Content-Type: image/png; name="unnamed.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAHAAAAA8CAYAAAC+ej5cAAAABHNCSVQICAgIfAhkiAAACLZJ REFUeJztnH1sXWUdxz/f53TtWmgYewO3MPAFedGIBOKCwFg3xjIGTMPagHS9nUSJGpFoJmJE ICHEFwxqCBpA13YMTEdUYDCW9fZuCogwXjICIjiE6YaxG2Ns69vuPT//cOjW3t7z2vZO7yfp H33u73l+33O+59zzvJ0LFSpUqFChQoUKFSpUqFDh/wml0ci8dpspmFUwZsiYYY4ZVuADwCQn 6k0cbVAvqMenzmCCg2pzePg4c0iGMHw5zPfxBQdwDAKD+OwT7DXHXoO9Dvb60OPEDvnsMLGj yrFj0kS2rmlSXxrHFIWFnTZ5cJBp5JnqjGkFMcWJAd/Y7Yl3gF2Ta9m6pkmFtHNHMnDRY1Yz 0MOnDc4x4zTgVPM5RaI+bWGxMHwc24BXEa/K2FJt5NYv15tpppnXbjOBBvNp8EWDjA+G0NaL Y7PgaSA7J0PXLZKfVEsoA28yc5s6WCFjhRlTkiYdc0SX4Lpcq15O0szcDltoPtfLaEgsyXgL xy+9Gu7tulI7YrcTJqhhpa02+FzcJGWB2Oc8LuhepuejVp230q4w41smzkhdltgvcfP5s/jx LQ3KR64fFNDQZheZsT6evDJDPL2xVeeEDV/YaZMHevkFxmdGUxYAYosnGrMZvRalmguMMJbE FlVmGMy+eKUdHyb2wg47r38fL46JeQDGJwrG7xtWWaS7PNhAsTC2qDJDhvphQVDc/HZbWvDZ KHHCWOj6D8Z0K7BxQYd9PGyVYANhUgJJZYcFHM/8VXa+X+A+M7yx0nQYxqRBn44vbrYJYcID DfTDmXzEYG7k45l/n52eL/CQiZqx1DQUGWe+9jLfDhP7P2VOEho7rTp/gN/KOHa8tQBgXJdZ aRODwgINdPBOOorKA+cXP55d+/my4OSx1jMixqS3XHAHMtBAg7fTUVQeyA0/nsWr7VjfuHE8 9JTE5/KgkEADBbFnCcoSb/jx9A7yHcTk8ZBTEuPDQSFh7sCt6agZf0zY5Gr+emhZY6d5ZrSO k6TSOGYFhwQg8Zd01JQBPn8fulqxq49zy/LuA/CpCwoJ7sQ4Xk9HzfjjNPxYfOPS8dASBhPb g2ICDTw6z0vpyCkLih3LZWOuIixiW1BIoIEPLde7psOfG0cq5njh0P8ve8jqMT46XnqC8MTj QTFhB/IvJtRSFjgON7BvP6EmtscFwwceCAoLZaAnIq+hlRsyBj7yMf50aJlfKF8D5bivO6Pk z0AAE08llzS+mOPZu8/WgcPK8uVpoBk9Tnw9TGwoA6vgj4jIq8VlhXhiaJEvpo+HlFKY6HNV XJHNaFeY+FAGbmjRfrPDnx9HHDbcQBmD4yFlRIzeKnFZrkXdYauEXo1QkSv4SMGEHTVh+GPA QU8KbfdJ/MCMvUnakXiyZgJnZDPqilIvtIGe8bvossoDwUuPXqXdQ8t9JTfQ+bhcq673PE4z sVrGQCRt4jlE85wMc9YvU+RZr6rQiY4ip14K47ZSnQDBhmLlTvQULFnbJmoWdNj0DS3aDjQv Xm1f7Rtkie+YbT5nyZgJTELUydiDY6cPr0lsktGVa9VzABtb4+UPbWBXk/Zc0GbPCELv6ioX zI1o4PaCyGPhz0MxCsZ8Do7ZDt7pbQf//qvBTJISXi7DibYib6xLW8CoY/SeWGBTsY82tGg/ sDlpioJxVVDMaJgHEQ30qnh0NESMKo7u9uXqH+ljQTZpChmL57XbnKTtxCGSgdlmXlCIGfJy QvBIyc+V3EAAK3D34tU25vtpIhkoyTAeHC0xaSNRmFjHb0rF1EzjKRl7kuYyccr+AdZe2GnH JG0rCpFfL2tos3OtyKA4NoZvjvWCf8hnnokTU2taZDe16sKguLltdhvGDWnklNjqOa7oalHo Z+uC++3k/CBXGlyOz1Qcz3tVXJ9t1iuB+aIKNDPNa+dv9u/ucSJM9DnHJe/PPCx6zGr6/0mn WTprdBLX5Fp1d1Dcok6b1tvLWzJq08hrwmQ86MFd553EE0NfWmnsNO/dfmbljc+acSXG2UXa eHuix1nrl6nkprJYL3jObbc78LkuTt3Dkju+ksvorkPLGjvt6J29vGghNvSUbpx8bR0z1jUp 1GC9oc1+Ysa1iXIWk2HsMcfrBj2CKYKZwPFhxtPOcWN3RreWjIkjysHKOPUOxUSuu4WfDS1f 06R9OK42kbTbvTaseQDVHt+TCDWBHAUTx2CcLWMRxqfMmBl2MsQs+MXZWAZ2Z7TF4Nk4deHg Vyd8YaSxUa5FmxzcE7f9g9wbJXj9Mr3tjOYULpzUMHgmKCb21nqnaCfoUDzx3VyrSm5XnFjF irhDFont0+qCtyMMJbtcjzu4LU7O1BHbTrTgcXdsA+uP5QHEe5Eris1TarkjKGxds96T40tx tJm4J+4PCkyt4ybBY3HqpoknvlFqAuJ9Yhv48BLtVcSvOTMOOHF12JPb3aJHEL+KJEz019Zy V3BgcdY0qTDnJJZIBPZeRw3HD7MZhRpvJ3o7yXP8NMpKvRzf785oS5QctXVcG6lzIVZF6bwU 45YG5XOtusY5VhzcXDQmSBScY8XGjL4Ztk4iA7tatE1wf6hg45Xa6ZTsEhdjXZN6DL4WKljk 5fGjqDlGojuj2z2PhYhIF10czOiRWNCd0e1R6iV+P9Cr4QbEvpJBYtDzaF53sSItdr7Pxlat BtYEBoo7c836c5wcI5HNqOuCDGcimkdjf6wZPThurp/I6d0Z5aLWT+WXmua22WLg1xjVwxIY A85jaTajtUlyNHZabU8vD2MUnRozkZ1ex6Wj+UtNjZ1WvbOfpeZzCT4LY79TIfqBzTI6ZsGq MJ2VkZtKiQUr7ZN5cQM+s81xHPAm8AdvArdmr9IbaeRo7DRvZy8tBp8HTpXPBN/xhmd0nAA/ T3Ii4mjZNcBsy3OROT5kBabLcZzBcfhMlaMPeMdgtzN2+0aP57FZ8OTkWp5b06Ty2lBVoUKF ChUqVKhQoUKFChWOCP4FQcADC00FAIoAAAAASUVORK5CYII= ------=_NextPart_000_0012_C657D2AC.1412365F-- From nobody Mon May 17 17:56:01 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 7F81085FAD3 for ; Mon, 17 May 2021 17:56:23 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkRdf26nfz4mLY for ; Mon, 17 May 2021 17:56:21 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 14HHu4IO066523 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 May 2021 10:56:04 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 14HHu1QL066522; Mon, 17 May 2021 10:56:01 -0700 (PDT) (envelope-from jmg) Date: Mon, 17 May 2021 10:56:01 -0700 From: John-Mark Gurney To: "Daniel O'Connor" Cc: Poul-Henning Kamp , "Bjoern A. Zeeb" , freebsd-arch@freebsd.org Subject: Re: New device wiring option Message-ID: <20210517175601.GG14975@funkthat.com> Mail-Followup-To: Daniel O'Connor , Poul-Henning Kamp , "Bjoern A. Zeeb" , freebsd-arch@freebsd.org References: <08A076D6-369B-4CE5-9DE6-012E2708F792@lists.zabbadoz.net> <96341.1618463832@critter.freebsd.dk> List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/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-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 17 May 2021 10:56:04 -0700 (PDT) X-Rspamd-Queue-Id: 4FkRdf26nfz4mLY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.48 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-0.68)[-0.676]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-arch] Daniel O'Connor via freebsd-arch wrote this message on Fri, Apr 16, 2021 at 21:05 +0930: > > On 15 Apr 2021, at 14:47, Poul-Henning Kamp wrote: > > > > -------- > > Bjoern A. Zeeb writes: > > > >> Probably USB as well? Having 10 serial consoles on USB Hubs and unplugging > >> one ???early??? one it is easy to end up re-numbering the entire chain after a > >> reboot. Not sure if this really fits into your problem/implementation domain. > > > > My solution to that specific problem is the following entry in /etc/devd: > > > > attach 500 { > > match "device-name" "uftdi[0-9]*"; > > match "vendor" "0x0403"; > > match "product" "(0x6001|0x6015)"; > > action "ln -fs /dev/cua$ttyname /dev/cua_$sernum"; > > }; > > > > notify 500 { > > match "system" "USB"; > > match "subsystem" "DEVICE"; > > match "type" "DETACH"; > > match "vendor" "0x0403"; > > match "product" "(0x6001|0x6015)"; > > action "rm -f /dev/cua_$sernum"; > > }; > > I wrote a more general version of this, although when I did testing the serial number was not available so I had to store it for deletion later. Yeah, and I did a slight improvement here: https://reviews.freebsd.org/D21886#554613 https://www.funkthat.com/~jmg/FreeBSD/usbserialsn Which supports devices that don't have serial numbers by addressing them via a path of hub port numbers which does not change... One issue is that it isn't atomic, so there's always a slight race between devd running and removing the link, and a new device appearing at the old one's name. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Mon May 17 18:21:09 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 7477B845A96 for ; Mon, 17 May 2021 18:21:21 +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 4FkSBT263Zz4rw1 for ; Mon, 17 May 2021 18:21:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [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 46CCB89290; Mon, 17 May 2021 18:21:13 +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 14HILCd6002437 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 17 May 2021 18:21:12 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 14HIL9Du002436; Mon, 17 May 2021 18:21:09 GMT (envelope-from phk) To: John-Mark Gurney cc: "Daniel O'Connor" , "Bjoern A. Zeeb" , freebsd-arch@freebsd.org Subject: Re: New device wiring option In-reply-to: <20210517175601.GG14975@funkthat.com> From: "Poul-Henning Kamp" References: <08A076D6-369B-4CE5-9DE6-012E2708F792@lists.zabbadoz.net> <96341.1618463832@critter.freebsd.dk> <20210517175601.GG14975@funkthat.com> List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/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: <2434.1621275669.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2021 18:21:09 +0000 Message-ID: <2435.1621275669@critter.freebsd.dk> X-Rspamd-Queue-Id: 4FkSBT263Zz4rw1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] -------- John-Mark Gurney writes: > Which supports devices that don't have serial numbers by addressing them > via a path of hub port numbers which does not change... Remember two decades ago, when Microsoft wanted all USB devices to have a = unique serial number and everybody freaked out ? :-) -- = 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 Tue May 18 16:48:15 2021 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 1089A550AA0 for ; Tue, 18 May 2021 16:48:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fl24l2VVcz3JKC; Tue, 18 May 2021 16:48:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 14IGmFcr028419 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 18 May 2021 19:48:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 14IGmFcr028419 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 14IGmFKk028418; Tue, 18 May 2021 19:48:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 May 2021 19:48:15 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: Mateusz Guzik , arch@freebsd.org Subject: Re: adaptive spinning: fall back to sleep / block? Message-ID: References: <202102251856.11PIuxwF020948@gitrepo.freebsd.org> <19884f0f-115d-a60c-2ef2-72400f96f8a7@uabsd.com> List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/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=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4Fl24l2VVcz3JKC X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; R_DKIM_NA(0.00)[]; MAILMAN_DEST(0.00)[arch]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-Spam: Yes On Mon, May 17, 2021 at 02:44:34PM +0300, Andriy Gapon wrote: > On 17/05/2021 13:23, Mateusz Guzik wrote: > > On 4/9/21, Andriy Gapon wrote: > > > > > > > > > Until I recently looked at the actual code I was under an impression that > > > the adaptive spinning is bounded and that after some time / number of spins > > > a > > > thread would go to a sleep queue or a turnstile. But it looks that the > > > spinning > > > is actually unbounded as long as its conditions hold (some other thread owns > > > the > > > lock and that thread is running, the owner could be changing too). > > > > > > In my opinion, it does not make sense to spin for "too long". > > > If there was not an opportunity to take a lock quickly, then it's better to > > > block waiting for it rather than keep occupying a processor. For instance, > > > the > > > spinning can prevent another runnable thread from running. > > > > > > I think that if a lock is heavily contended or its hold times are on the > > > longer > > > side (or both), then the adaptive spinning can make the system behavior > > > (performance, responsiveness) worse. > > > > > > Finally, I was under an impression that 'adaptive' meant some heuristic on > > > whether and when to do the spinning. _A lock owner is running_ seems to be > > > too > > > simple to qualify as 'adaptive'. > > > > > > As an example, this looks like a relatively sophisticated implementation of > > > the > > > "adaptiveness": > > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.cpp#l1919 > > > But, JIMHO, simply having a hard limit on the spin count would be better > > > than > > > what we have now. > > > > > > > There is no clear cut answer to this that I'm aware of. Ultimately all > > behavior in face of contention is about damage control. > > > > It's not hard to make a counter point to going off cpu after a timeout: > > 1. going off cpu is also a serializing operation, that is threads can > > content on doing so, albeit less than on the original lock > > 2. existence of blocked waiters makes it more expensive to release the > > lock, making contention worse and even then it is unclear what wake up > > policy you would like to enact (e.g., do you hand off the lock to the > > oldest sleeper? do you wake everyone and let them fight it out? all > > choices suffer problems) > > 3. consider a thread which holds foo_lock and now contends on bar_lock > > and decides to go off cpu. if there is a thread which waits on > > foo_lock, it will also go off cpu. This kind of behavior easily leads > > to dramatic collapse in throughput, even on top of whatever problems > > which are present due to contention to begin with. > > > > Now, locking primitives in the FreeBSD kernel are problematic in at > > least 3 ways: > > 1. there are no fairness guarantees, for example a constant stream of > > threads can end up excluding some threads for a long time > > 2. there is no support for locking under kvm (as in the kernel does > > not take advantage of it) > > 3. rw locking is using cas loops instead of add > > > > imo, if doing anything serious with locks, the 3 above problems needs > > to be solved, in that order. > > > > I can't stress enough the lack of fairness, which arbitrary going to > > sleep will only exacerbate. As noted earlier, I don't know if timeout > > sleep is an inherently good or bad idea, but I'm confident playing > > with it in the situation is on the bad side. > > I agree with you. And it looks like we do not disagree in general > . > I just want to make a clarification, maybe redundant, that you seem to be > mostly concerned about effects on threads that contend on same locks or > related lock chains. I am more concerned about effects on completely > unrelated threads. > > Yes, sleeping and waking introduces overhead (and not only) on threads doing > them and threads depending on those threads. But spinning, when it happens > on a large share of CPUs (e.g., ~ 100% of them), introduces a penalty on the > whole system. > > At work, where a substantial part of our application lives in kernel, I > regularly debug issues that seem to happen because of CPUs starvation. And > a common theme between them is that many CPUs are tied in the lock spinning. > FreeBSD as a general purpose OS does not seem to suffer from the same issues > (at least, that I know of), but we have quite a lot of additional kernel > threads and kernel locks. > > So, maybe instead of trying to experiment with FreeBSD I should try to > experiment with our derivative product first. > > Thank you for the feedback and additional information. BTW, the unfairness and scheduling randomness are quite fundamental for locking to work. Minor scheduling inconsistencies and timing drifts due to external events and internal machine operations allow to avoid lock convoys, which would otherwise plague us. The priorities mechanism is the partial compensation for lack of fairness. Critical sections give you the highest priority execution, factually. They will probably become more common as more lock-less algorithms start appear in the kernel. I saw some references that Windows tried to use the completely fair queued spinlocks, and either limited their use to very specific places, or get rid of them. They were never advertised as generic facility. Also, I know that Solaris experimented with stuff like direct transfer of the lock from unlocking thread to (some) lock contender. They were very much dissatisfied with the results. From nobody Fri May 21 13:19:57 2021 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 BF4DB8C68E2 for ; Fri, 21 May 2021 13:21:17 +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 4FmnLN59y7z4l6k for ; Fri, 21 May 2021 13:21:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (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 E4F7C260100 for ; Fri, 21 May 2021 15:21:14 +0200 (CEST) To: arch@freebsd.org From: Hans Petter Selasky Subject: Sleepable EPOCH(9) implementation for FreeBSD Message-ID: <9ecf28d8-5a53-3157-294e-dbaaf069f474@selasky.org> Date: Fri, 21 May 2021 15:19:57 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Discussion related to FreeBSD architecture List-Archive: http://lists.freebsd.org/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; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4FmnLN59y7z4l6k 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]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:4f8:c17:6c4b::2:from]; 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)[arch@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a01:4f8:c17:6c4b::2:from:127.0.2.255]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; 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]; MAILMAN_DEST(0.00)[arch] Hi, There is a proposal for sleepable EPOCH(9) up for review at: https://reviews.freebsd.org/D30376 Maybe someone here is interested in participating. --HPS From nobody Mon May 31 07:07:22 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 5CBE5D7DEE2; Mon, 31 May 2021 07:07:32 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtmZW0st0z3nkD; Mon, 31 May 2021 07:07:30 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 14V77Mj8084681 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 May 2021 00:07:22 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 14V77M4m084680; Mon, 31 May 2021 00:07:22 -0700 (PDT) (envelope-from jmg) Date: Mon, 31 May 2021 00:07:22 -0700 From: John-Mark Gurney To: Fernando =?iso-8859-1?Q?Apestegu=EDa?= Cc: Ian Lepore , FreeBSD Hackers , freebsd-arch@FreeBSD.org Subject: Re: Inclusion of all manual pages in all architecture releases Message-ID: <20210531070722.GR14975@funkthat.com> Mail-Followup-To: Fernando =?iso-8859-1?Q?Apestegu=EDa?= , Ian Lepore , FreeBSD Hackers , freebsd-arch@FreeBSD.org 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 31 May 2021 00:07:22 -0700 (PDT) X-Rspamd-Queue-Id: 4FtmZW0st0z3nkD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.65 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.85)[-0.847]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Fernando Apestegua wrote this message on Thu, May 27, 2021 at 08:40 +0200: > On Wed, May 26, 2021 at 5:23 PM Ian Lepore wrote: > > > > On Wed, 2021-05-26 at 17:04 +0200, Fernando Apestegua wrote: > > > I don't know what list this should be sent to, apologies if the > > > audience is too wide. > > > > > > For some time now, we have not included all manual pages in every > > > FreeBSD packaged release. For instance, i386 man pages are not > > > included in the FreeBSD amd64 distribution. > > > > > > This causes a number of problems: > > > > > > * The https://www.freebsd.org/cgi/man.cgi is incomplete. As an > > > example, it does not show results for pae(4). The reason for this is > > > that the cgi interface runs on FreeBSD amd64. > > > > > > * In FreeBSD amd64 some manual pages have broken X-refs. See hptrr(4) > > > for an example. > > > > > > * Also, we have broken links in our Release Notes. This is a > > > consequence of the first point. See > > > https://www.freebsd.org/releases/13.0R/hardware/#proc-i386. > > > > > > Is there a specific reason for this? > > > > > > Cheers. > > > > > > > I have tried multiple times to get the people who adminster > > freebsd.org's man.cgi to include all arches. I added the ability to > > generate and install all of them by setting MAN_ARCH=all (or to a list > > of arches) on the build command line years ago. But I haven't had any > > success in getting that used to install all the arches for the website > > and man.cgi updated to make the arch selection list on the webpage > > actually work. > > Hi Ian, > > Thanks for the explanation. That would fix the man.cgi and > consequently the Release Notes issues. > However, in order to fix the broken X-refs in the manual pages of the > release distributions, wouldn't we need to build them with > MAN_ARCH=all? > According to make.conf(5), MAN_ARCH defaults to MACHINE and > MACHINE_ARCH. Would it be possible to change the default value to > "all"? > > diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile > index f7626c80eeb1..583c4a4b9bb9 100644 > --- a/share/man/man4/Makefile > +++ b/share/man/man4/Makefile > @@ -897,9 +897,7 @@ _cgem.4= cgem.4 > MLINKS+=cgem.4 if_cgem.4 > .endif > > -.if empty(MAN_ARCH) > -__arches= ${MACHINE} ${MACHINE_ARCH} ${MACHINE_CPUARCH} > -.elif ${MAN_ARCH} == "all" > +.if empty(MAN_ARCH) || ${MAN_ARCH} == "all" > __arches= ${:!/bin/sh -c "/bin/ls -d ${.CURDIR}/man4.*"!:E} > .else > __arches= ${MAN_ARCH} > > This way, the released distributions will have all the man pages (we > have some PRs related to this) and would also fix man.cgi regardless > of the FreeBSD version the service runs on. > > I am assuming here that we do not explicitly set MAN_ARCH to a > specific architecture when building the releases but we take the > default value. I would like to see this change made myself. It'd nice to be able to use your amd64 build box to be able to get information on other systems by default. The extra space is minimal. I have cc'd -arch to get a wider audience. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Tue Jun 8 18:22:41 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 C2C7511CBA32 for ; Tue, 8 Jun 2021 18:23:15 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FzzBV4n3Lz4Tls for ; Tue, 8 Jun 2021 18:23:14 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.189] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 158IMfDo051930 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 8 Jun 2021 12:23:13 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be [192.168.2.189] From: John Nielsen Content-Type: text/plain; charset=utf-8 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 14.0 \(3654.60.0.2.21\)) Subject: The future of the isboot (iBFT / iSCSI boot) module Message-Id: <97C74347-2181-4B10-A97D-823D42AFEB11@jnielsen.net> Date: Tue, 8 Jun 2021 12:22:41 -0600 To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FzzBV4n3Lz4Tls X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-1.11 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_SPAM_SHORT(0.69)[0.691]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; R_SPF_ALLOW(-0.20)[+a:mailers.freebsdsolutions.net:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[jnielsen.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch] X-ThisMailContainsUnwantedMimeParts: N [re-posted with minor edits from -scsi] Hi all- TL;DR=E2=80=94do we want to bring iSCSI boot support in to the base = system and if so, what should that look like? I=E2=80=99ve been maintaining (badly, at least until recently) the = net/isboot-kmod port which contains Daisuke Aoyama=E2=80=99s isboot = module. The kernel module allows a system to be booted completely via = iSCSI (no switching root, etc) from systems or NICs with native iSCSI = BIOS support or via iPXE and friends. The BIOS (or iPXE) acts as an = initiator and connects to a previously-configured target volume. Boot = (legacy or UEFI) continues normally from there=E2=80=94FreeBSD=E2=80=99s = loader can load and start the kernel, etc. What=E2=80=99s missing in the = base system is something to re-establish the iSCSI session between when = the kernel starts execution and when it tries to mount the root = filesystem. That=E2=80=99s where isboot comes in. Assuming the module is loaded at = boot, it will interpret the data structures in the mostly-standard iSCSI = Boot Firmware Table (iBFT) and use that information to identify the = correct NIC, bring it up, assign an IP address and gateway (if = provided), and establish an iSCSI session with the target. Once that is = done the volume is presented as a SCSI device using the CAM subsystem = and boot proceeds normally. The module has been around for some time (I want to say since FreeBSD = 7). I believe it was developed in tandem or for use with the net/istgt = port. I don=E2=80=99t know if it pre-dates Danny Branniss=E2=80=99 = iscsi_initiator work in base but it definitely pre-dates the = iscsid/iscsictl and ctld in base now. Upstream development on isboot has = stopped from what I can tell and the port was broken for quite some = time. I created a GitHub repo for the project and recently (with help = from several others) I updated the port to 0.2.14, which should work = with FreeBSD 1[1234]. I=E2=80=99ve made a couple more improvements and a = 0.2.15 release isn=E2=80=99t far off. See the project here if = interested: https://github.com/jnielsendotnet/isboot . I=E2=80=99m happy to maintain the port out of tree for the foreseeable = future but I think ideally this functionality should be brought in to = the base system. =46rom what I can tell the port has its own complete = iSCSI initiator implementation, and does not use what is now in = sys/dev/iscsi. That should probably change (and is a longer-term goal of = mine, though I will likely need help), but for now what approach makes = the most sense? 1) Leave it out of tree as an independent port. Pros: easy in the short term (nothing more to do) Cons: less visible to potential users, likely to suffer from bit = rot, duplicate initiator code, foot-shooting is easier with an = out-of-tree module required to mount root 2) Bring it in base but keep it separate from sys/dev/iscsi. Pros: also very easy (I=E2=80=99ve done a proof of concept to = support modules/isboot and =E2=80=9Cdevice isboot=E2=80=9D in kernel), = higher visibility, easily updated with the rest of the system (or even = linked in to the kernel directly), some defense against bit rot Cons: duplicate initiator code 3) Bring it in base, but make it depend on the sys/dev/iscsi code. Pros: most of the above, no duplicate initiator code Cons: more effort, slightly out of my depth 4) Bring it in base and merge it with sys/dev/iscsi. Pros: just one module to configure / load / worry about. Could = easily control isboot functionality via loader tunable. Makes it more of = a first class citizen. Cons: more effort again, probably requires broader = ownership/buy-in. What does the list think? Any objections or considerations I=E2=80=99m = not aware of? Any sponsorship volunteers? Thanks, JN From nobody Tue Jun 8 19:09: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 A14FA11CDDEE for ; Tue, 8 Jun 2021 19:09:33 +0000 (UTC) (envelope-from lutz@iks-jena.de) Received: from annwfn.iks-jena.de (annwfn.iks-jena.de [IPv6:2001:4bd8::19]) (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 4G00Cx2j8Tz4XmZ for ; Tue, 8 Jun 2021 19:09:33 +0000 (UTC) (envelope-from lutz@iks-jena.de) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.15.2/8.15.2) with ESMTPS id 158J9Kx6020981 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Jun 2021 21:09:20 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id 158J9KYV032163; Tue, 8 Jun 2021 21:09:20 +0200 Date: Tue, 8 Jun 2021 21:09:19 +0200 From: Lutz Donnerhacke To: John Nielsen Cc: freebsd-arch@freebsd.org Subject: Re: The future of the isboot (iBFT / iSCSI boot) module Message-ID: <20210608190919.GA31862@belenus.iks-jena.de> References: <97C74347-2181-4B10-A97D-823D42AFEB11@jnielsen.net> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97C74347-2181-4B10-A97D-823D42AFEB11@jnielsen.net> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 4G00Cx2j8Tz4XmZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jun 08, 2021 at 12:22:41PM -0600, John Nielsen wrote: > 2) Bring it in base but keep it separate from sys/dev/iscsi. First step to bring it in. > 3) Bring it in base, but make it depend on the sys/dev/iscsi code. Second step, now with a background already in base. This way it's more likely to catch attention of other devs in the review. > 4) Bring it in base and merge it with sys/dev/iscsi. Third step, will take time and needs cooperation. Given the previous step will cause obvious integration requests, development from more than one person is possible. From nobody Thu Jun 10 12:18:32 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 071207EE33B; Thu, 10 Jun 2021 12:22:30 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G135K0bPxz4bqT; Thu, 10 Jun 2021 12:22:28 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-qt1-f182.google.com with SMTP id t17so20729423qta.11; Thu, 10 Jun 2021 05:22:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YAJHyjVE7xpubdcOos4pOSjOtPl4TjNlwsaxq+P01qE=; b=cmjbaa1VyC4oN4Rj0N/6fLuCJ66ZiWU6WEXukm9LltCRqevujUgBG36+OEMtjxOz5v hAtL+jPiIMCjRJUIDZdNqNaDVmWsHlAce66jwlIXi2WxYGxQC3rrm7Zn5WQMm9UvEi8E 0uarjslokA/+VaE8TLotUMqVyCxMAPDsfo+z8SRxt8W+TKppcyWzzok05+Owk/LiDyEc tgWTP4xxp+IsNGzIR6nWsRoFjvOpHvW9UQY6bOuV30eT+NjHQCJ8y0wcFQYUOlKGWxe0 C9QScF2nUoH321aA0KgoZ4mhKdtR3qVTErKrckkWJ5j+gbfHwZnA/3/5CfdF5jl2W8/x 7Hsg== X-Gm-Message-State: AOAM530kBShuB+wLZzFs3uz1lmBNYSEYaYSXCQvBhSzdaBn7qknQuEsW FVruRPsDUJUh2EXru/ZFKPVvr+TBeY8q4Q== X-Google-Smtp-Source: ABdhPJxx0vTOi3O2MS8sKiIpLvqjKmhePBPis12cvpNyghNXnkn4R7P6meiFAKsDlEuE0YUGAH85Lg== X-Received: by 2002:ac8:4803:: with SMTP id g3mr4887807qtq.176.1623327747960; Thu, 10 Jun 2021 05:22:27 -0700 (PDT) Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com. [209.85.219.181]) by smtp.gmail.com with ESMTPSA id t26sm2074648qtn.18.2021.06.10.05.22.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Jun 2021 05:22:27 -0700 (PDT) Received: by mail-yb1-f181.google.com with SMTP id m9so34011680ybo.5; Thu, 10 Jun 2021 05:22:27 -0700 (PDT) X-Received: by 2002:a25:cf08:: with SMTP id f8mr7163746ybg.249.1623327746843; Thu, 10 Jun 2021 05:22:26 -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: <20210531070722.GR14975@funkthat.com> In-Reply-To: From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Thu, 10 Jun 2021 14:18:32 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Inclusion of all manual pages in all architecture releases To: Ceri Davies Cc: Ian Lepore , FreeBSD Hackers , freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4G135K0bPxz4bqT X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fernandoapesteguia@gmail.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=fernandoapesteguia@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.182:from]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[fernape@freebsd.org,fernandoapesteguia@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[fernape@freebsd.org,fernandoapesteguia@gmail.com]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.160.182:from]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[209.85.160.182:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.182:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-arch] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 31, 2021 at 6:17 PM Ceri Davies wrote: > > On Mon, May 31, 2021 at 12:07:22AM -0700, John-Mark Gurney wrote: > > Fernando Apestegua wrote this message on Thu, May 27, 2021 at 08:40 +0200: > > > > > > Hi Ian, > > > > > > Thanks for the explanation. That would fix the man.cgi and > > > consequently the Release Notes issues. > > > However, in order to fix the broken X-refs in the manual pages of the > > > release distributions, wouldn't we need to build them with > > > MAN_ARCH=all? > > > According to make.conf(5), MAN_ARCH defaults to MACHINE and > > > MACHINE_ARCH. Would it be possible to change the default value to > > > "all"? > > > > > > diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile > > > index f7626c80eeb1..583c4a4b9bb9 100644 > > > --- a/share/man/man4/Makefile > > > +++ b/share/man/man4/Makefile > > > @@ -897,9 +897,7 @@ _cgem.4= cgem.4 > > > MLINKS+=cgem.4 if_cgem.4 > > > .endif > > > > > > -.if empty(MAN_ARCH) > > > -__arches= ${MACHINE} ${MACHINE_ARCH} ${MACHINE_CPUARCH} > > > -.elif ${MAN_ARCH} == "all" > > > +.if empty(MAN_ARCH) || ${MAN_ARCH} == "all" > > > __arches= ${:!/bin/sh -c "/bin/ls -d ${.CURDIR}/man4.*"!:E} > > > .else > > > __arches= ${MAN_ARCH} > > > > > > This way, the released distributions will have all the man pages (we > > > have some PRs related to this) and would also fix man.cgi regardless > > > of the FreeBSD version the service runs on. > > > > > > I am assuming here that we do not explicitly set MAN_ARCH to a > > > specific architecture when building the releases but we take the > > > default value. > > > > I would like to see this change made myself. It'd nice to be able to > > use your amd64 build box to be able to get information on other systems > > by default. The extra space is minimal. > > Agreed. I would prefer if architecture specific pages went into their > own section, and were then hardlinked into the existing architecture's > standard sections (this would preserve current behaviour, and allow each > architecture its own namespace if needed). I created https://reviews.freebsd.org/D30715 and took the liberty of adding some of you who provided feedback, to the review. Thanks! > > Ceri > -- > That must be wonderful! I don't understand it at all. > -- Moliere From nobody Sun Jun 13 22:50:33 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 F2AEEF7B689 for ; Sun, 13 Jun 2021 22:51:24 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G38vb702yz3HZK for ; Sun, 13 Jun 2021 22:51:23 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.191] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 15DMoXG7037038 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Jun 2021 16:51:07 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be [192.168.2.191] 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 14.0 \(3654.60.0.2.21\)) Subject: Re: The future of the isboot (iBFT / iSCSI boot) module From: John Nielsen In-Reply-To: <20210608190919.GA31862@belenus.iks-jena.de> Date: Sun, 13 Jun 2021 16:50:33 -0600 Cc: freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <67358F33-A435-40BE-8DD7-8020BD85E3FF@jnielsen.net> References: <97C74347-2181-4B10-A97D-823D42AFEB11@jnielsen.net> <20210608190919.GA31862@belenus.iks-jena.de> To: Lutz Donnerhacke X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4G38vb702yz3HZK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; DMARC_NA(0.00)[jnielsen.net]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.999]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch] X-ThisMailContainsUnwantedMimeParts: N > On Jun 8, 2021, at 1:09 PM, Lutz Donnerhacke = wrote: >=20 > On Tue, Jun 08, 2021 at 12:22:41PM -0600, John Nielsen wrote: >> 2) Bring it in base but keep it separate from sys/dev/iscsi. >=20 > First step to bring it in. >=20 >> 3) Bring it in base, but make it depend on the sys/dev/iscsi code. >=20 > Second step, now with a background already in base. This way it's more > likely to catch attention of other devs in the review. >=20 >> 4) Bring it in base and merge it with sys/dev/iscsi. >=20 > Third step, will take time and needs cooperation. Given the previous = step > will cause obvious integration requests, development from more than = one > person is possible. That all sounds reasonable. Where do I go from here? Put the code on = Phabricator?= From nobody Sun Jun 13 23:12:54 2021 X-Original-To: freebsd-arch@freebsd.org Received: from mlmmj.nyi.freebsd.org (unknown [127.0.1.24]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D6C3DF7DD0B for ; Sun, 13 Jun 2021 23:12:54 +0000 (UTC) (envelope-from freebsd-arch+bounces-help@FreeBSD.org) Subject: =?utf-8?q?Unable_to_unsubscribe_from_freebsd-arch=40FreeBSD.org?= From: freebsd-arch+help@FreeBSD.org To: freebsd-arch@freebsd.org Message-ID: <1623625974-11483-mlmmj-13ddb03e@FreeBSD.org> Date: Sun, 13 Jun 2021 23:12:54 +0000 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: 8bit X-ThisMailContainsUnwantedMimeParts: N Hi, this is the Mlmmj program managing the mailing list. You were unable to be unsubscribed from the list because you are not subscribed. If you are receiving messages, perhaps a different email address is subscribed. To find out which address you are subscribed with, refer to the message welcoming you to the list, or look at the envelope "Return-Path" header of a message you receive from the list. From nobody Mon Jun 14 15:38: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 2119111DA4A6 for ; Mon, 14 Jun 2021 15:38:39 +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 4G3bFq0SdSz3PHg; Mon, 14 Jun 2021 15:38:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (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 A57F9E544; Mon, 14 Jun 2021 15:38:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: John Nielsen , freebsd-arch@freebsd.org References: <97C74347-2181-4B10-A97D-823D42AFEB11@jnielsen.net> From: John Baldwin Subject: Re: The future of the isboot (iBFT / iSCSI boot) module Message-ID: <3f821392-d6bc-126a-8ccb-b492e09995e9@FreeBSD.org> Date: Mon, 14 Jun 2021 08:38:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.10.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 In-Reply-To: <97C74347-2181-4B10-A97D-823D42AFEB11@jnielsen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 6/8/21 11:22 AM, John Nielsen wrote: > [re-posted with minor edits from -scsi] > > Hi all- > > TL;DR—do we want to bring iSCSI boot support in to the base system and if so, what should that look like? > > I’ve been maintaining (badly, at least until recently) the net/isboot-kmod port which contains Daisuke Aoyama’s isboot module. The kernel module allows a system to be booted completely via iSCSI (no switching root, etc) from systems or NICs with native iSCSI BIOS support or via iPXE and friends. The BIOS (or iPXE) acts as an initiator and connects to a previously-configured target volume. Boot (legacy or UEFI) continues normally from there—FreeBSD’s loader can load and start the kernel, etc. What’s missing in the base system is something to re-establish the iSCSI session between when the kernel starts execution and when it tries to mount the root filesystem. > > That’s where isboot comes in. Assuming the module is loaded at boot, it will interpret the data structures in the mostly-standard iSCSI Boot Firmware Table (iBFT) and use that information to identify the correct NIC, bring it up, assign an IP address and gateway (if provided), and establish an iSCSI session with the target. Once that is done the volume is presented as a SCSI device using the CAM subsystem and boot proceeds normally. > > The module has been around for some time (I want to say since FreeBSD 7). I believe it was developed in tandem or for use with the net/istgt port. I don’t know if it pre-dates Danny Branniss’ iscsi_initiator work in base but it definitely pre-dates the iscsid/iscsictl and ctld in base now. Upstream development on isboot has stopped from what I can tell and the port was broken for quite some time. I created a GitHub repo for the project and recently (with help from several others) I updated the port to 0.2.14, which should work with FreeBSD 1[1234]. I’ve made a couple more improvements and a 0.2.15 release isn’t far off. See the project here if interested: https://github.com/jnielsendotnet/isboot . > > I’m happy to maintain the port out of tree for the foreseeable future but I think ideally this functionality should be brought in to the base system. From what I can tell the port has its own complete iSCSI initiator implementation, and does not use what is now in sys/dev/iscsi. That should probably change (and is a longer-term goal of mine, though I will likely need help), but for now what approach makes the most sense? > > 1) Leave it out of tree as an independent port. > Pros: easy in the short term (nothing more to do) > Cons: less visible to potential users, likely to suffer from bit rot, duplicate initiator code, foot-shooting is easier with an out-of-tree module required to mount root > 2) Bring it in base but keep it separate from sys/dev/iscsi. > Pros: also very easy (I’ve done a proof of concept to support modules/isboot and “device isboot” in kernel), higher visibility, easily updated with the rest of the system (or even linked in to the kernel directly), some defense against bit rot > Cons: duplicate initiator code > 3) Bring it in base, but make it depend on the sys/dev/iscsi code. > Pros: most of the above, no duplicate initiator code > Cons: more effort, slightly out of my depth > 4) Bring it in base and merge it with sys/dev/iscsi. > Pros: just one module to configure / load / worry about. Could easily control isboot functionality via loader tunable. Makes it more of a first class citizen. > Cons: more effort again, probably requires broader ownership/buy-in. > > What does the list think? Any objections or considerations I’m not aware of? Any sponsorship volunteers? I'd be a bit nervous about just going with 2) unless there's a person lined up to do the work of 3). The iscsi initiator and target already don't really share a ton of code (and possibly duplicate some things as a result). It's also probably going to be hard to get review for a 3rd iscsi initiator vs something smaller that reuses sys/dev/iscsi. -- John Baldwin From nobody Fri Jun 18 07:36:33 2021 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 476B911DF54E for ; Fri, 18 Jun 2021 07:36:49 +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 4G5rN00WKcz4vf1 for ; Fri, 18 Jun 2021 07:36:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [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 9BE4989294 for ; Fri, 18 Jun 2021 07:36:39 +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 15I7aYCY068065 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 18 Jun 2021 07:36:34 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 15I7aYmk068064; Fri, 18 Jun 2021 07:36:34 GMT (envelope-from phk) Message-Id: <202106180736.15I7aYmk068064@critter.freebsd.dk> To: arch@freebsd.org Subject: It's time to kill statistical profiling From: Poul-Henning Kamp 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: <68062.1624001793.1@critter.freebsd.dk> Date: Fri, 18 Jun 2021 07:36:33 +0000 X-Rspamd-Queue-Id: 4G5rN00WKcz4vf1 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]; RCVD_TLS_ALL(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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]; MAILMAN_DEST(0.00)[arch] X-ThisMailContainsUnwantedMimeParts: N Warners work to document the kernel timers in D30802 brought stathz up again. To give a representative result, statistical profiling needs to sample no less than approx 0.1% of instructions. On a VAX that meant running the statistical profiling at O(1kHz). On my 4 CPU, two thread, 2GHz laptop that means statistical profiling needs to run at O(10 MHz), which is barely doable. But it is worse: The samples must be unbiased with respect to the system activity, which was already a problem on the VAX and which is totally impossible on modern hardware, with message based interrupts, deep pipelines and telegraphic distance memory[1]. Therefore statistical profiling is worse than useless: it is downright misleading, which is why modern CPUs have hardware performance counters. Instead of documenting stathz, I suggest we retire statistical profiling and convert the profiled libraries to code-coverage profiling (-fprofile-arcs and -ftest-coverage) Poul-Henning [1] One could *possibly* approch unbiased samples, by locking the stathz code path in L1 cache and disable L1 updates, but then the results would be from an entirely different system. -- 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 Fri Jun 18 13:35:44 2021 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 9FBDE7E8353 for ; Fri, 18 Jun 2021 13:35:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G60LP40Y8z4Tkw for ; Fri, 18 Jun 2021 13:35:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72e.google.com with SMTP id f70so10893964qke.13 for ; Fri, 18 Jun 2021 06:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s8yyBCsaUp8R0lcdVPnKK3oRtq+82l8vomPz5cOAyQY=; b=wy5TfojC4lzGFnEZjotq0o5W9Ga0ZakkmBBBEqJbnL0IaIy+GFdiVdCtp3ErqOOyrU ZD7Zbeg1Mk7qV0hTTiyo2zGs/OGMXEjxrWKV4enVuXxKjnG/pxW554Ezmm4ASBvJlVuw BgQb0HriaMYzYvG9fERIUDTIJqHuCpJxR/dhHEUYgOebUxgiSwuHOWjqpon2Xeqhq3D8 aYy2WzRgz4O1Q854ij16jhzo7+IUVxNOD3NVF8AaF+QmeN3KVEPP6nzg711daR0WENs1 3hO+2Osb7uPnxpwEX0SFCJOuorJNv1/tQDSFxGubqj7Ox/+nLZ9kpNKsBPtEfxbBcGDQ GdNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s8yyBCsaUp8R0lcdVPnKK3oRtq+82l8vomPz5cOAyQY=; b=rj2L0eHQjYD05c0O8CnUgdaTdlfhxLTU/QQ5Fa2bBXtUgbu2fMThEpEDnF1LSqiQec IMuP3wga/t6p1FRPjO4m2VXIQXchTQqTORpzhnhVboeETMjMYxKtG4xH7Ir1Njynpop5 YToekNE/LAK5LnYie8WCTTHXML7Sk21J5SBxNkzgh3f9eJOE/orpkWzcD3s8TZqOjTp+ qWbH6bO3pJ/GqmtuLe/BCmYyotGFg5a1ZWAXczIAS6gp40nXIvHOrKwZCZ5dRhfLRgZ5 Xivdy8H2pbQN2sfJutdoaFZk02HEFfkDu7dAeP/QT42GrN91AJ3vWtaV4dUWFKi/Zvbh POfA== X-Gm-Message-State: AOAM531BEmgbQMAGzLtOHPTSFeGXT7X/+4bWwHTO2kLcXgnMSkQgSw+B Z3pLN3GRoAG6RAmEYKIr9y7AoCsmZ2mR4oj77+o94DVaFI3xzg== X-Google-Smtp-Source: ABdhPJz0VIVDJcBs9iSWq07crxVISo/hQxq9aGwBGQXi224cnpO+aAOI2HV3tZ6+Jfx/JeN+nqMZAgEDF4yFPEK3RPM= X-Received: by 2002:a37:a20f:: with SMTP id l15mr9293519qke.44.1624023355266; Fri, 18 Jun 2021 06:35: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: <202106180736.15I7aYmk068064@critter.freebsd.dk> In-Reply-To: <202106180736.15I7aYmk068064@critter.freebsd.dk> From: Warner Losh Date: Fri, 18 Jun 2021 07:35:44 -0600 Message-ID: Subject: Re: It's time to kill statistical profiling To: Poul-Henning Kamp Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000032b14b05c50a673b" X-Rspamd-Queue-Id: 4G60LP40Y8z4Tkw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000032b14b05c50a673b Content-Type: text/plain; charset="UTF-8" On Fri, Jun 18, 2021 at 1:37 AM Poul-Henning Kamp wrote: > Warners work to document the kernel timers in D30802 brought stathz up > again. > > To give a representative result, statistical profiling needs to > sample no less than approx 0.1% of instructions. > > On a VAX that meant running the statistical profiling at O(1kHz). > > On my 4 CPU, two thread, 2GHz laptop that means statistical profiling > needs to run at O(10 MHz), which is barely doable. > > But it is worse: > > The samples must be unbiased with respect to the system activity, > which was already a problem on the VAX and which is totally impossible > on modern hardware, with message based interrupts, deep pipelines > and telegraphic distance memory[1]. > > Therefore statistical profiling is worse than useless: it is downright > misleading, which is why modern CPUs have hardware performance counters. > > Instead of documenting stathz, I suggest we retire statistical > profiling and convert the profiled libraries to code-coverage > profiling (-fprofile-arcs and -ftest-coverage) > > Poul-Henning > > [1] One could *possibly* approch unbiased samples, by locking the > stathz code path in L1 cache and disable L1 updates, but then > the results would be from an entirely different system. > I've documented them as obsolete in favor of hwpmc (though I know that's not quite the whole story). I'll remove that when we remove the feature, since it also documents the clockinfo sysctl a bit. stathz and profhz drive the setitimer ITIMER_PROF functionality. While this was in POSIX.1-2001, it was marked deprecated in POSIX.1-2008. There's sysctls that return these values to userland as well, but those could return bogus values. Our current docs for this are vague enough to give some cover :) Deleting the code from the kernel is the easy bit, I guess. I generally support this notion, but don't have the time to hunt down all the stuff in base and ports that uses these and make appropriate changes (up to and including git rm). Warner --00000000000032b14b05c50a673b-- From nobody Fri Jun 18 13:43:13 2021 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 E729A7EA027 for ; Fri, 18 Jun 2021 13:43:16 +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 4G60Vr5V3gz4WdH for ; Fri, 18 Jun 2021 13:43:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [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 DC66689296; Fri, 18 Jun 2021 13:43:13 +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 15IDhD3Y098530 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Jun 2021 13:43:13 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 15IDhDNt098529; Fri, 18 Jun 2021 13:43:13 GMT (envelope-from phk) Message-Id: <202106181343.15IDhDNt098529@critter.freebsd.dk> To: Warner Losh cc: "freebsd-arch@freebsd.org" Subject: Re: It's time to kill statistical profiling In-reply-to: From: "Poul-Henning Kamp" References: <202106180736.15I7aYmk068064@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; charset="us-ascii" Content-ID: <98527.1624023792.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Jun 2021 13:43:13 +0000 X-Rspamd-Queue-Id: 4G60Vr5V3gz4WdH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- Warner Losh writes: > Deleting the code from the kernel is the easy bit, I guess. I generally = support > this notion, but don't have the time to hunt down all the stuff in base = and > ports that uses these and make appropriate changes (up to and including = git > rm). It's no rush, we've had this obsolete facility for 20-25 years already, we can sweep the corners as we get to them. I think the main decision is that we want to do it, and if we want to keep profiled libararies for gcov or if we want to ditch profiled libraries. The main reason I prefer to change to gcov libraries is that it keeps the .mk infrastructure for having systematic variant librararies in place, over the years people have abused that for a lot of interesting experiments and hacks. I also suspect that s/-p/-fprofile-arcs -ftest-coverage/ is a LOT easier than removing that infrastructure :-) -- = 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 Fri Jun 18 13:57:51 2021 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 AB5237EC5AA for ; Fri, 18 Jun 2021 13:58:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G60qs1Z5vz4ZFh for ; Fri, 18 Jun 2021 13:58:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 15IDvpNc027075 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Jun 2021 16:57:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 15IDvpNc027075 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 15IDvp1o027074; Fri, 18 Jun 2021 16:57:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Jun 2021 16:57:51 +0300 From: Konstantin Belousov To: Warner Losh Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" Subject: Re: It's time to kill statistical profiling Message-ID: References: <202106180736.15I7aYmk068064@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; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4G60qs1Z5vz4ZFh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jun 18, 2021 at 07:35:44AM -0600, Warner Losh wrote: > On Fri, Jun 18, 2021 at 1:37 AM Poul-Henning Kamp > wrote: > > > Warners work to document the kernel timers in D30802 brought stathz up > > again. > > > > To give a representative result, statistical profiling needs to > > sample no less than approx 0.1% of instructions. > > > > On a VAX that meant running the statistical profiling at O(1kHz). > > > > On my 4 CPU, two thread, 2GHz laptop that means statistical profiling > > needs to run at O(10 MHz), which is barely doable. > > > > But it is worse: > > > > The samples must be unbiased with respect to the system activity, > > which was already a problem on the VAX and which is totally impossible > > on modern hardware, with message based interrupts, deep pipelines > > and telegraphic distance memory[1]. > > > > Therefore statistical profiling is worse than useless: it is downright > > misleading, which is why modern CPUs have hardware performance counters. > > > > Instead of documenting stathz, I suggest we retire statistical > > profiling and convert the profiled libraries to code-coverage > > profiling (-fprofile-arcs and -ftest-coverage) > > > > Poul-Henning > > > > [1] One could *possibly* approch unbiased samples, by locking the > > stathz code path in L1 cache and disable L1 updates, but then > > the results would be from an entirely different system. > > > > I've documented them as obsolete in favor of hwpmc (though I know that's not > quite the whole story). I'll remove that when we remove the feature, since > it > also documents the clockinfo sysctl a bit. > > stathz and profhz drive the setitimer ITIMER_PROF functionality. While this > was in POSIX.1-2001, it was marked deprecated in POSIX.1-2008. There's > sysctls > that return these values to userland as well, but those could return bogus > values. > Our current docs for this are vague enough to give some cover :) > > Deleting the code from the kernel is the easy bit, I guess. I generally > support > this notion, but don't have the time to hunt down all the stuff in base and > ports that uses these and make appropriate changes (up to and including git > rm). You cannot remove a kernel feature without breaking ABI. I do not see why do we need to remove it. The userspace bits, specifically build system glue to build _p.a libraries, is different, of course. We already have profiling static libraries build disabled. I also killed (as removed from the kernel build and config(8)) the support for -pg profiling). But for userspace, instead of removing, it could be quite useful to generalize it, instead of removing. In particular, to allow user to build some 'flavor' of system libraries, with intent to support either code coverage analysis, or PGO, or whatever toolchains authors implement. User would specify which additional toolchain options to pass instead of -pg, and probably should be able to provide his own crt1.o flavor. From nobody Fri Jun 18 13:59:53 2021 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 E4B407ED431 for ; Fri, 18 Jun 2021 13:59:55 +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 4G60t35C3wz4bNt for ; Fri, 18 Jun 2021 13:59:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [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 291E889294; Fri, 18 Jun 2021 13:59:54 +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 15IDxrJ6098658 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Jun 2021 13:59:53 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 15IDxrbL098657; Fri, 18 Jun 2021 13:59:53 GMT (envelope-from phk) Message-Id: <202106181359.15IDxrbL098657@critter.freebsd.dk> To: Konstantin Belousov cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: It's time to kill statistical profiling In-reply-to: From: "Poul-Henning Kamp" References: <202106180736.15I7aYmk068064@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; charset="us-ascii" Content-ID: <98655.1624024793.1@critter.freebsd.dk> Date: Fri, 18 Jun 2021 13:59:53 +0000 X-Rspamd-Queue-Id: 4G60t35C3wz4bNt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- Konstantin Belousov writes: > You cannot remove a kernel feature without breaking ABI. > I do not see why do we need to remove it. Which ABI would that be ? -- 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 Fri Jun 18 15:12:53 2021 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 9262811CB815 for ; Fri, 18 Jun 2021 15:12:55 +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 4G62VH3hzwz4l2W; Fri, 18 Jun 2021 15:12:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (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 22B142D006; Fri, 18 Jun 2021 15:12:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Poul-Henning Kamp , arch@freebsd.org References: <202106180736.15I7aYmk068064@critter.freebsd.dk> From: John Baldwin Subject: Re: It's time to kill statistical profiling Message-ID: Date: Fri, 18 Jun 2021 08:12:53 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.10.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 In-Reply-To: <202106180736.15I7aYmk068064@critter.freebsd.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 6/18/21 12:36 AM, Poul-Henning Kamp wrote: > Warners work to document the kernel timers in D30802 brought stathz up again. > > To give a representative result, statistical profiling needs to > sample no less than approx 0.1% of instructions. > > On a VAX that meant running the statistical profiling at O(1kHz). > > On my 4 CPU, two thread, 2GHz laptop that means statistical profiling > needs to run at O(10 MHz), which is barely doable. > > But it is worse: > > The samples must be unbiased with respect to the system activity, > which was already a problem on the VAX and which is totally impossible > on modern hardware, with message based interrupts, deep pipelines > and telegraphic distance memory[1]. > > Therefore statistical profiling is worse than useless: it is downright > misleading, which is why modern CPUs have hardware performance counters. > > Instead of documenting stathz, I suggest we retire statistical > profiling and convert the profiled libraries to code-coverage > profiling (-fprofile-arcs and -ftest-coverage) > > Poul-Henning > > [1] One could *possibly* approch unbiased samples, by locking the > stathz code path in L1 cache and disable L1 updates, but then > the results would be from an entirely different system. Note that only profhz is what you could kill. stathz is used for statclock to compute rusage and the %CPU for ps(1) as well as the cp_time stats for system-wide (and per-CPU) time stats. What I would like to do for rusage is to have an option to split up rux_runtime into separate "raw" iruntime, sruntime, and uruntime and switch between them on kernel entry/exit similar to what we do now in mi_switch(). This would remove the need for iticks/uticks/sticks and the need for calcru() to try to do subdividing and then playing games to prevent individual times going backwards. Instead, it would just do a straightforward conversion of the component runtime to the value getrusage() wants. I've just never gotten around to doing that. However, even with that, you are still stuck with providing whatever events the schedule wants to set %CPU for ps(1). You also still need something to provide the kern.cp_time arrays used for CPU usage. statclock might still be the simplest way to provide those. I agree that hwpmc is what one should use for real profiling, but there's actually not much that you get to axe in the kernel when removing the kernel-side support for the old profiling. As Konstantin has noted, we already no longer build or ship -pg libraries by default. I'd be fine with removing the build glue for that outright, or with generalizing it as Konstantin suggests, though I would probably not even want to keep -pg as one of the variants for the generalization. To that end, I would be fine with just removing all the -pg support and if someone wants to add a a new variant they can deal with making it more general at that time. I'd much rather someone spend time on adding support for PGO and LTO to our build infrastructure than trying to keep -pg alive. -- John Baldwin From nobody Fri Jun 18 16:13:52 2021 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 29F795D1924 for ; Fri, 18 Jun 2021 16:14:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G63rv5zTbz4v9b for ; Fri, 18 Jun 2021 16:14:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 15IGDq9f059813 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 18 Jun 2021 19:13:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 15IGDq9f059813 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 15IGDquU059812; Fri, 18 Jun 2021 19:13:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Jun 2021 19:13:52 +0300 From: Konstantin Belousov To: Poul-Henning Kamp Cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: It's time to kill statistical profiling Message-ID: References: <202106180736.15I7aYmk068064@critter.freebsd.dk> <202106181359.15IDxrbL098657@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; charset=us-ascii Content-Disposition: inline In-Reply-To: <202106181359.15IDxrbL098657@critter.freebsd.dk> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4G63rv5zTbz4v9b X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jun 18, 2021 at 01:59:53PM +0000, Poul-Henning Kamp wrote: > -------- > Konstantin Belousov writes: > > > You cannot remove a kernel feature without breaking ABI. > > I do not see why do we need to remove it. > > Which ABI would that be ? ITIMER_PROF of course. It is consumed by several language runtimes for whatever reasons, see debian source code search. I am less concerned about profil(2). From nobody Sat Jun 19 09:12:01 2021 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 45A6811CFABD for ; Sat, 19 Jun 2021 09:12:04 +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 4G6VRS1Q0Rz4sdN; Sat, 19 Jun 2021 09:12:04 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f1016003c538a6963dc4dc4.dip0.t-ipconnect.de [IPv6:2003:cd:5f10:1600:3c53:8a69:63dc:4dc4]) (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 935785C8E; Sat, 19 Jun 2021 09:12:03 +0000 (UTC) (envelope-from se@freebsd.org) To: arch@freebsd.org References: <202106180736.15I7aYmk068064@critter.freebsd.dk> From: Stefan Esser Cc: Poul-Henning Kamp , John Baldwin Subject: Re: It's time to kill statistical profiling Message-ID: <0eca3abd-7ddf-9de3-51a0-3e273d3fb979@freebsd.org> Date: Sat, 19 Jun 2021 11:12:01 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZYBAv5ENBTynEeLgVdEQxyxMCUKlyUQQE" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZYBAv5ENBTynEeLgVdEQxyxMCUKlyUQQE Content-Type: multipart/mixed; boundary="KdS1fuyagTIQVIFUMQEx8pAF0qbcCwyOV"; protected-headers="v1" From: Stefan Esser To: arch@freebsd.org Cc: Poul-Henning Kamp , John Baldwin Message-ID: <0eca3abd-7ddf-9de3-51a0-3e273d3fb979@freebsd.org> Subject: Re: It's time to kill statistical profiling References: <202106180736.15I7aYmk068064@critter.freebsd.dk> In-Reply-To: --KdS1fuyagTIQVIFUMQEx8pAF0qbcCwyOV Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Am 18.06.21 um 17:12 schrieb John Baldwin: > Note that only profhz is what you could kill.=C2=A0 stathz is used for > statclock to compute rusage and the %CPU for ps(1) as well as the > cp_time stats for system-wide (and per-CPU) time stats. >=20 > What I would like to do for rusage is to have an option to split > up rux_runtime into separate "raw" iruntime, sruntime, and > uruntime and switch between them on kernel entry/exit similar to > what we do now in mi_switch().=C2=A0 This would remove the need for > iticks/uticks/sticks and the need for calcru() to try to do > subdividing and then playing games to prevent individual times > going backwards.=C2=A0 Instead, it would just do a straightforward > conversion of the component runtime to the value getrusage() > wants.=C2=A0 I've just never gotten around to doing that. >=20 > However, even with that, you are still stuck with providing > whatever events the schedule wants to set %CPU for ps(1).=C2=A0 You > also still need something to provide the kern.cp_time arrays > used for CPU usage.=C2=A0 statclock might still be the simplest way > to provide those. If any major changes are considered in this area, I'd really want to see our CPU statistics become SMT aware: If one thread is executing on a SMT capable CPU per core, it does consume 100% of the cycles (which are also shown in top for that process), but the total CPU% value shown is 50% since it seems that half of the CPUs (the alternate thread supported by each one) is idle. The correct way to deal with SMT would be to assume that a CPU that is executing a single thread does so at 100% nominal clock (which is not constant, to make matters worse), while with two threads we get two "virtual" CPUs executing at 60% (or whatever) of the nominal clock rate, delivering 120% combined throughput. We do collect topology information that describes the system in sufficient detail, but do not account for the reduced throughput of each thread of a SMT thread pair. And I'm not sure that the scheduler will prefer allocating CPUs in such a way that only one thread is executing on each CPU until the load goes above the number of cores and it becomes preferable to actually use more than one thread per CPU. This does also mess up statistics used by the scheduler, which assumes that all cores run at the same speed all the time. Due to frequency variations depending on load and other factors, this is not true, anyway, but the difference between the single core maximum clock rate and the all cores loaded clock rate is not that large. And since the scheduler has to make correct decisions under high load - low load situations do not suffer as much under bad scheduling) it can be assumed that the CPU is running at the base frequency, anyway. One possibility could be to count actual cycles in the different execution contexts (user, system, interrupt) and store them with information about the relative CPU performance (whether running as one thread of an SMT thread pair or not). For a start it would suffice to assume a CPU executing 2 threads would spend half its cycles on each one (i.e. as if it was 2 cores at half the clock, ignoring the actual combined throughput of 130% that I see on my Ryzen based system). The fraction of time that two threads were assigned to that CPU needs to be known, too. Or have one counter that get updated if there is only one thread on a core, and 2 more for the two "halves" of that core when executing 2 threads. I do not suppose to modify the cycle accounting in such a direction, now. But any change that is made could as well take SMT into consideration and at least make it possible to go into that direction. Regards, STefan --KdS1fuyagTIQVIFUMQEx8pAF0qbcCwyOV-- --ZYBAv5ENBTynEeLgVdEQxyxMCUKlyUQQE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmDNtOEFAwAAAAAACgkQR+u171r99UQa 4ggAni0/viw8iQPlZUFHKH5+wtRN653zgaO7M43bBzjECFBXzK7H4KPfgNTG1FcEZc0A9f/OJDbG e1g0F25AFDyTR+aA+ddUg1zVxxr1BU3J6/oJ+D5+mrxESR6t2kQXfSj+WqTXcTrt3EPBWRYOgDDp RJyycnria+FicZ/47qbhLOZTpNVZW1xiA0hHpFRbDG/ZEKdU2hih7EOIqlln4uA2aQdvIt3WJckV 9RfuonyT3KYaufgCeZqk53r3iGXkVj19SWzWf9zP6AgguWLhxI4djHrjcusRTDBUAeop40+TjL0h hk5MAWUb4w2Ocs1nDCKZ0sOonpfC/E4M88N2DZA1Dw== =Z8gS -----END PGP SIGNATURE----- --ZYBAv5ENBTynEeLgVdEQxyxMCUKlyUQQE-- From nobody Sun Jun 20 16:17:33 2021 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 7866B11D026C for ; Sun, 20 Jun 2021 16:17:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G7HrG26yLz3qG9 for ; Sun, 20 Jun 2021 16:17:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f50.google.com with SMTP id h2so1193154iob.11 for ; Sun, 20 Jun 2021 09:17:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TjrigoTu5fRTMKCy0E0altkXg+AGYrj31B7apd/Zaug=; b=sv5ZaaEoACWh8i6Z5fA+OoW/6MY5iXb8Dv6FfgB76Y2hx5sMpF4nkRR6zgyYKdKZQ7 hmnA6R3LO1/WXtvHBXJu7sEX2nYPVWQE43/RQ6GUo6jl4TEejftScO5arPwsej9jydr+ DRixk8iF5nKx6xPj4Hk9p2R44G0vSoON3oXph7LvEI50o5NgS89r0SpbUbva54Hlacrc QQVa5cXgsCryJUX2hSf51DfXE3IldzTJvaCwTykLDUtFthAR07RCD0J6gtljBvTMXMRi fJJ4qrEs1pzorAl5l+IC1hyKkULKF4YTfkdORxwfD9vm9m8GIZKznnspb0nfXeaytlhQ Ivcg== X-Gm-Message-State: AOAM533Pzake791jG5fO14/NZy7FkvDoxfOjZKI/dudZQNmWlNk3qSj6 weTq+lTbC9oHYuRC2ZymINsGLV8gwIOippMhSvNWIfmFLgs= X-Google-Smtp-Source: ABdhPJzrdq9x5ktoytw4tXfdIQ0kqhL5Ar1Jfa/S8OLxOlGH2aEKXmyCMlL6GsOmG3lWVuR0pza3AyGkxSQWyqPh1js= X-Received: by 2002:a5d:9b0b:: with SMTP id y11mr15175284ion.102.1624205868994; Sun, 20 Jun 2021 09:17:48 -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: <202106180736.15I7aYmk068064@critter.freebsd.dk> In-Reply-To: <202106180736.15I7aYmk068064@critter.freebsd.dk> From: Ed Maste Date: Sun, 20 Jun 2021 12:17:33 -0400 Message-ID: Subject: Re: It's time to kill statistical profiling To: Poul-Henning Kamp Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4G7HrG26yLz3qG9 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.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.50:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.166.50:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.50:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.50:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[arch] X-ThisMailContainsUnwantedMimeParts: N On Fri, 18 Jun 2021 at 03:36, Poul-Henning Kamp wrote: > > Instead of documenting stathz, I suggest we retire statistical > profiling and convert the profiled libraries to code-coverage > profiling (-fprofile-arcs and -ftest-coverage) I brought up retiring the PROFILE option to build _p libraries last year: https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.html There were a couple of objections in that thread, but if it doesn't produce accurate data there's little value in keeping it. > Instead of documenting stathz, I suggest we retire statistical > profiling and convert the profiled libraries to code-coverage > profiling (-fprofile-arcs and -ftest-coverage) Having built-in support for code coverage would be great, but IMO not done by just swapping the current libraries / build infrastructure / options over. From nobody Sun Jun 20 19:18:31 2021 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 4442711DB7AF for ; Sun, 20 Jun 2021 19:19:16 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G7Msb3J0kz4dDh; Sun, 20 Jun 2021 19:19:14 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f173.google.com with SMTP id i12so13285913ila.13; Sun, 20 Jun 2021 12:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qd+9p9pVKMYi6398VA1r4ROMgUVyE5CEm5lWFeLysAU=; b=oHXP+ysTaeWclgAX20sz5jGtmFa4BXDFX7+2qU0bMwmZYT0+cCpkLN14JiQzsq++4D 0E0UdUNdlaONk+2NI56y0pGweQSGfDU9VJBuy7Yd3GC/mX4FDEHeLyB/nnPppQbWMHC5 oHTYcN8cC9ZJbJmV+pQ1FagiYNCiRWtjIhlDxbxDgKK++eNaxw28srZw4k64ZxuMz4YV HLmJt/edc+HSgJurCjtSBtb3jNERH1koAXOnddlv/rGgpW5uskguOdEt/htn22CKBhJ3 u2x9byF6SfyO/r5YWneTuifA5DYzfbv0QvzGzcr0dlAF29K2CZoApbCIaB1dcz4qZO4K zHig== X-Gm-Message-State: AOAM531rqJeKW5TSSx00EF+j3N5OmDf+pzd47gtzWFCVMZaPoxdherTw nQq0McbFEQ4mugqjBKhc9N4oli8HcVGCoDc2wDHSEsnu X-Google-Smtp-Source: ABdhPJxysT7MWZPkq/9/KmdtH0TU8eNX+zOft1r8UsgL3jJAiv6wH3ehkKhnvknoeqDQxNqr8nwhZQ+b4bfVYZD1N68= X-Received: by 2002:a92:7b01:: with SMTP id w1mr15669009ilc.100.1624216753232; Sun, 20 Jun 2021 12:19:13 -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: <202106180736.15I7aYmk068064@critter.freebsd.dk> In-Reply-To: From: Ed Maste Date: Sun, 20 Jun 2021 15:18:31 -0400 Message-ID: Subject: Re: It's time to kill statistical profiling To: John Baldwin Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4G7Msb3J0kz4dDh 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.173 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.94 / 15.00]; RCVD_TLS_ALL(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]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[209.85.166.173:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.981]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.173:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.173:from]; NEURAL_HAM_MEDIUM(-0.96)[-0.957]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.173:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[arch]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 18 Jun 2021 at 11:13, John Baldwin wrote: > > As Konstantin has noted, we already no longer build or ship > -pg libraries by default. Kostik was talking about only kernel -pg support I believe; we still build _p.a libraries by default. I floated the idea of disabling them by default but there was some opposition and I didn't proceed. It seems like it is in fact past time to disable them by default, and I've now put the change in review at https://reviews.freebsd.org/D30833. From nobody Sun Jun 20 21:08:25 2021 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 1491F11E4E32 for ; Sun, 20 Jun 2021 21:08:35 +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 4G7QHk64Lcz4sw5; Sun, 20 Jun 2021 21:08:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) 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 15KL8PxP045164 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 20 Jun 2021 14:08:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 15KL8PAO045163; Sun, 20 Jun 2021 14:08:25 -0700 (PDT) (envelope-from sgk) Date: Sun, 20 Jun 2021 14:08:25 -0700 From: Steve Kargl To: Ed Maste Cc: John Baldwin , Poul-Henning Kamp , "freebsd-arch@freebsd.org" Subject: Re: It's time to kill statistical profiling Message-ID: <20210620210825.GA45154@troutmask.apl.washington.edu> References: <202106180736.15I7aYmk068064@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; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4G7QHk64Lcz4sw5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jun 20, 2021 at 03:18:31PM -0400, Ed Maste wrote: > On Fri, 18 Jun 2021 at 11:13, John Baldwin wrote: > > > > As Konstantin has noted, we already no longer build or ship > > -pg libraries by default. > > Kostik was talking about only kernel -pg support I believe; we still > build _p.a libraries by default. I floated the idea of disabling them > by default but there was some opposition and I didn't proceed. > > It seems like it is in fact past time to disable them by default, and > I've now put the change in review at > https://reviews.freebsd.org/D30833. Are there plans to replace the _p.a with something that allows profiling code? If not, are you upstreaming patches to GCC to disable -pg? AFAIK, 'gcc10 -pg ... -lm' causes gcc to look for at least libc_p.a and libm_p.a. -- Steve From nobody Mon Jun 21 15:25:29 2021 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 795D511D507E for ; Mon, 21 Jun 2021 15:25:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G7tdp2w7hz3q7S; Mon, 21 Jun 2021 15:25:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f175.google.com with SMTP id q12so4764737ilv.5; Mon, 21 Jun 2021 08:25:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l5oGyY7QkOwr5C25VSHuc++Gex6xy3SrxgC/ykbYHfI=; b=Fa+m8YQUwvfMAygNQ5buYlZFYMjHkHetNx8F7ftrx+i22OJAQ/noFPqq2AO1cZ3pXS 2wYjCYSFA0tRek+Spt2KMs5Z/czd5mQapFlqtiXCzkYCgjX0s1N2hja9BbLbs7fBSVBf KI36CfMyBLi2B3tvPxaV8uos9xUanW1+jSD/DOXkbruOO3H/YOfyvtENnbHc9irNv/Qa iEP/9yTAuIootPdqWlgOqPfBrgeb9kN/UjYx5livZvZb+wdWI6LHX+9sYqmcRyKOUIF1 KJDJYMAwXjqEla4Qe10LvLCEgXoHj/k9DdQSCnUGr2I+NvWtUdqeBAIvYapfui9jpFR1 uvZg== X-Gm-Message-State: AOAM532Qy+m62RAchp08h/a22a0Co8QcSsLH+F1lneeOFJmUMoyD/iyb 1t7xIaBa1sOumGh19lperE3o39KorK9Tgby6gtyjunvVO9k= X-Google-Smtp-Source: ABdhPJzPn/odWLhNiT45nEbhxfiqAVfMdDbntmp+anavmvbqRGG01eTQ4U9yci4hZEDCReieTF3n2YDUgJVSSDJNc1c= X-Received: by 2002:a92:a002:: with SMTP id e2mr6813647ili.98.1624289149195; Mon, 21 Jun 2021 08:25:49 -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: <202106180736.15I7aYmk068064@critter.freebsd.dk> <20210620210825.GA45154@troutmask.apl.washington.edu> In-Reply-To: <20210620210825.GA45154@troutmask.apl.washington.edu> From: Ed Maste Date: Mon, 21 Jun 2021 11:25:29 -0400 Message-ID: Subject: Re: It's time to kill statistical profiling To: Steve Kargl Cc: John Baldwin , Poul-Henning Kamp , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4G7tdp2w7hz3q7S X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 20 Jun 2021 at 17:08, Steve Kargl wrote: > > Are there plans to replace the _p.a with something > that allows profiling code? If not, are you upstreaming > patches to GCC to disable -pg? AFAIK, 'gcc10 -pg ... -lm' > causes gcc to look for at least libc_p.a and libm_p.a. I believe this is how GCC operates indeed, but I'm not aware of the implementation or specific details. Clang behaves as you describe -- here is all behaviour change based on OPT_pg, from lib/Driver/ToolChains/FreeBSD.cpp: if (!Args.hasArg(options::OPT_shared)) { if (Args.hasArg(options::OPT_pg)) crt1 = "gcrt1.o"; else if (IsPIE) crt1 = "Scrt1.o"; else crt1 = "crt1.o"; } ... if (Args.hasArg(options::OPT_pg)) CmdArgs.push_back("-lm_p"); else CmdArgs.push_back("-lm"); and similar for -lgcc_p, -lgcc_eh_p, -lpthread_p, -lc_p, -lc++_p, -lstdc++_p. This support was initially introduced upstream in: commit 66f2276aee67738d116d26494d8a78fc6528586b Author: Roman Divacky Date: Thu Feb 10 16:59:40 2011 +0000 Adjust the object files to be linked in when mcount profiling is specified in the FreeBSD linker driver. llvm-svn: 125285 and was implemented for OpenBSD later that year, but no other OS does this. I'm not sure exactly what happens elsewhere - my guess is that the runtime support exists in libc but it is built without -pg so coverage will not include libc itself. From nobody Tue Jun 22 00:57:01 2021 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 2573111D9CF4 for ; Tue, 22 Jun 2021 00:57:09 +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 4G87K06h6Jz3hvt; Tue, 22 Jun 2021 00:57:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) 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 15M0v1HY049047 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 21 Jun 2021 17:57:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 15M0v1F8049046; Mon, 21 Jun 2021 17:57:01 -0700 (PDT) (envelope-from sgk) Date: Mon, 21 Jun 2021 17:57:01 -0700 From: Steve Kargl To: Ed Maste Cc: John Baldwin , Poul-Henning Kamp , "freebsd-arch@freebsd.org" Subject: Re: It's time to kill statistical profiling Message-ID: <20210622005701.GA48991@troutmask.apl.washington.edu> References: <202106180736.15I7aYmk068064@critter.freebsd.dk> <20210620210825.GA45154@troutmask.apl.washington.edu> 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: 4G87K06h6Jz3hvt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jun 21, 2021 at 11:25:29AM -0400, Ed Maste wrote: > On Sun, 20 Jun 2021 at 17:08, Steve Kargl > wrote: > > > > Are there plans to replace the _p.a with something > > that allows profiling code? If not, are you upstreaming > > patches to GCC to disable -pg? AFAIK, 'gcc10 -pg ... -lm' > > causes gcc to look for at least libc_p.a and libm_p.a. > > I believe this is how GCC operates indeed, but I'm not aware of the > implementation or specific details. For part of the answer, one is looking for gcc/gcc/config/freebsd-spec.h. This is where -pg maps libc.a to libc_p.a. I can't easily track down libm.a to libm_p.a until later this week. A bigger problem for FreeBSD and GCC is that there appears to be no active FreeBSD GCC maintainer(s). I submitted a GCC patch for the C language that fixes a few hundred C language testsuite failures, and a C++ patch that fixes complex arithmetic. Both are languishing in GCC bugzilla. -- Steve From nobody Sat Jun 26 23:01: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 D5A2111F6DBD for ; Sat, 26 Jun 2021 23:02:27 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GC8XM0G8jz3vLN; Sat, 26 Jun 2021 23:02:26 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.191] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 15QN1ksA049838 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Jun 2021 17:02:18 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be [192.168.2.191] 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 14.0 \(3654.60.0.2.21\)) Subject: Re: The future of the isboot (iBFT / iSCSI boot) module From: John Nielsen In-Reply-To: <3f821392-d6bc-126a-8ccb-b492e09995e9@FreeBSD.org> Date: Sat, 26 Jun 2021 17:01:45 -0600 Cc: John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: <1C9525AB-C353-41B4-9E73-587A030CCDDA@jnielsen.net> References: <97C74347-2181-4B10-A97D-823D42AFEB11@jnielsen.net> <3f821392-d6bc-126a-8ccb-b492e09995e9@FreeBSD.org> To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4GC8XM0G8jz3vLN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mailers.freebsdsolutions.net]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; DMARC_NA(0.00)[jnielsen.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N > On Jun 14, 2021, at 9:38 AM, John Baldwin wrote: >=20 > On 6/8/21 11:22 AM, John Nielsen wrote: >> [re-posted with minor edits from -scsi] >> Hi all- >> TL;DR=E2=80=94do we want to bring iSCSI boot support in to the base = system and if so, what should that look like? >> I=E2=80=99ve been maintaining (badly, at least until recently) the = net/isboot-kmod port which contains Daisuke Aoyama=E2=80=99s isboot = module. The kernel module allows a system to be booted completely via = iSCSI (no switching root, etc) from systems or NICs with native iSCSI = BIOS support or via iPXE and friends. The BIOS (or iPXE) acts as an = initiator and connects to a previously-configured target volume. Boot = (legacy or UEFI) continues normally from there=E2=80=94FreeBSD=E2=80=99s = loader can load and start the kernel, etc. What=E2=80=99s missing in the = base system is something to re-establish the iSCSI session between when = the kernel starts execution and when it tries to mount the root = filesystem. >> That=E2=80=99s where isboot comes in. Assuming the module is loaded = at boot, it will interpret the data structures in the mostly-standard = iSCSI Boot Firmware Table (iBFT) and use that information to identify = the correct NIC, bring it up, assign an IP address and gateway (if = provided), and establish an iSCSI session with the target. Once that is = done the volume is presented as a SCSI device using the CAM subsystem = and boot proceeds normally. >> The module has been around for some time (I want to say since FreeBSD = 7). I believe it was developed in tandem or for use with the net/istgt = port. I don=E2=80=99t know if it pre-dates Danny Branniss=E2=80=99 = iscsi_initiator work in base but it definitely pre-dates the = iscsid/iscsictl and ctld in base now. Upstream development on isboot has = stopped from what I can tell and the port was broken for quite some = time. I created a GitHub repo for the project and recently (with help = from several others) I updated the port to 0.2.14, which should work = with FreeBSD 1[1234]. I=E2=80=99ve made a couple more improvements and a = 0.2.15 release isn=E2=80=99t far off. See the project here if = interested: https://github.com/jnielsendotnet/isboot . >> I=E2=80=99m happy to maintain the port out of tree for the = foreseeable future but I think ideally this functionality should be = brought in to the base system. =46rom what I can tell the port has its = own complete iSCSI initiator implementation, and does not use what is = now in sys/dev/iscsi. That should probably change (and is a longer-term = goal of mine, though I will likely need help), but for now what approach = makes the most sense? >> 1) Leave it out of tree as an independent port. >> Pros: easy in the short term (nothing more to do) >> Cons: less visible to potential users, likely to suffer from bit = rot, duplicate initiator code, foot-shooting is easier with an = out-of-tree module required to mount root >> 2) Bring it in base but keep it separate from sys/dev/iscsi. >> Pros: also very easy (I=E2=80=99ve done a proof of concept to = support modules/isboot and =E2=80=9Cdevice isboot=E2=80=9D in kernel), = higher visibility, easily updated with the rest of the system (or even = linked in to the kernel directly), some defense against bit rot >> Cons: duplicate initiator code >> 3) Bring it in base, but make it depend on the sys/dev/iscsi code. >> Pros: most of the above, no duplicate initiator code >> Cons: more effort, slightly out of my depth >> 4) Bring it in base and merge it with sys/dev/iscsi. >> Pros: just one module to configure / load / worry about. Could = easily control isboot functionality via loader tunable. Makes it more of = a first class citizen. >> Cons: more effort again, probably requires broader = ownership/buy-in. >> What does the list think? Any objections or considerations I=E2=80=99m = not aware of? Any sponsorship volunteers? >=20 > I'd be a bit nervous about just going with 2) unless there's a person = lined up > to do the work of 3). The iscsi initiator and target already don't = really share > a ton of code (and possibly duplicate some things as a result). >=20 > It's also probably going to be hard to get review for a 3rd iscsi = initiator vs > something smaller that reuses sys/dev/iscsi. Good feedback, thank you. Does anyone on this list (or BCC=E2=80=99ed) = have time/interest in helping me merge the isboot initiator code with = what=E2=80=99s in sys/dev/iscsi (option 3 above)? Surely NetApp or iX want to simplify booting FreeBSD from iSCSI. :) Thanks, JN From nobody Fri Jul 9 08:27:48 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 5DB9E11E1626 for ; Fri, 9 Jul 2021 08:28:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLmWN3l3Kz3qTD for ; Fri, 9 Jul 2021 08:28:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x734.google.com with SMTP id a6so8578749qka.4 for ; Fri, 09 Jul 2021 01:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=V4EZf2slcQL1d16PIb8xMdFXO3ordvYLRPgAmIya/v8=; b=NJWl4fXJY8c53peoP9u398AE46lp+MPXot9IRIRXrm4CLPfAlZG6FXI2uj6x0bTB3R MbsR2Zqd8cMzGtYByOdRt/AJvKlrC+lWio5XxY5AJTeBF23n74hpkhPkJfVvWfN86vdB y0F3P2XMW6qHxkaLNs2e3CZZIMjt8KwRsgvOAtp0qQl0pYkRHVBM5SK2bshOq+Oi8eX2 U0D1tc1IZyrqQEkDuLy7FGX0ZbvgQ3EF3LgInMkW0JpVKRyFS1vnj3hHKiAECRJ5NHMM LeNVOtpGI+05dFjgLec9mRNp6XBk/LC+Luuvj+jSP9BJgQfwUb+3dDBTk1E25QprDCk9 ptfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=V4EZf2slcQL1d16PIb8xMdFXO3ordvYLRPgAmIya/v8=; b=plPjl+QVXQuUnORIpARx1GtvuhZ8gJlnYbZcPX1uIn1chsTVPP70fcJ59ZMqOspK3A 1X/8IvqY8BOfYjVbTikk2MIu+WHI0NWdtOcM52QyisR+8c8VTBqaFYTTTjCv7ZcigHzq aW9wNPPpoMScXVn88LI+1VftvaqD2pfjvwaqdWWAwFIcFgV1YxpAl9hrGA0kJHOak96w dlgL7GJ6wF0/I/nuhgSfywDl53A0u2zFyxOsrqBftakq080WvlyRLyy+LJ8HZGtDd8OH mfkBIJ9Trtd2h8jbnBDu6EogEbb894bPakPDKc71jTDGG82GbNsR1V6T7lYLgfhleQZt Zi1Q== X-Gm-Message-State: AOAM53104naBwA3js9oz799gvqJOANW6RPiagsBc6haTtSPxngsODn/+ aeY+wzTV6S3kls+zWipAXerrC0zgkx2eDzSh1BjpOcPNO2Zy6XE/ X-Google-Smtp-Source: ABdhPJzO9AGKMFZIrd99W9JJGpJeFkqXGCmCegNr3q9GYqubyrFCACLYMMUpmnPDP7sIZCeKoARxlGlE3yA5sZ3hfKc= X-Received: by 2002:a05:620a:12b6:: with SMTP id x22mr10071186qki.195.1625819279283; Fri, 09 Jul 2021 01:27: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 From: Warner Losh Date: Fri, 9 Jul 2021 02:27:48 -0600 Message-ID: Subject: FreeBSD awk behavior change proposal To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000009c68a405c6ac8ca7" X-Rspamd-Queue-Id: 4GLmWN3l3Kz3qTD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=NJWl4fXJ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::734) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [0.95 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::734:from:127.0.2.255]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_SPAM_LONG(0.95)[0.947]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::734: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:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::734:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-arch] X-ThisMailContainsUnwantedMimeParts: Y --0000000000009c68a405c6ac8ca7 Content-Type: text/plain; charset="UTF-8" Greetings, I've posted https://reviews.freebsd.org/D31114 which eliminates the last delta we have from upstream one-true-awk. This delta has basically been rejected by upstream as being a really bad idea. Let me give some background. In 2005, FreeBSD changed one-true-awk to honor the locale's collating order. https://svnweb.freebsd.org/base/head/usr.bin/awk/b.c.diff?annotate=146322&pathrev=201988 This was billed as a temporary patch. It was also compatible with the then-current behavior of gawk. That temporary patch has lasted 16 years now. However, IEEE Std 1003.1-2008 changed the behaivor of ranges in regular expressions outside of the "C" and "POSIX" locales to be undefined. Starting in 2011, gawk 4.0 stopped using the locale for the range regular expressions and used the traditional behavior only. The maintainer had grown weary of answering why '[A-Z]' would sometimes match lower-case expressions. The details about are explained here: https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html To restore compatibility with other implementaitons of awk, revert this patch. FreeBSD is the odd-system out. It also has the nice side effect of eliminating the last of our differences with upstream one-true-awk. I'd like to commit the change at least to -current. Ideally, I'd like to MFC the change. I believe better compatibility with gawk and other awk implementations justifies this change in behavior because the current behavior is outside the mainstream enough to be considered a bug. I'd like to solicit input before I do this, however. Warner --0000000000009c68a405c6ac8ca7-- From nobody Fri Jul 9 08:34:33 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 3F1E211E2883 for ; Fri, 9 Jul 2021 08:34:55 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (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 4GLmgL69z7z3rkw; Fri, 9 Jul 2021 08:34:54 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id ba5e3a29; Fri, 9 Jul 2021 08:34:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=20180501; bh=7VKvGo1jj2O0UI y7fmK9FImtSvQ=; b=Up0NNvFGL8O0vxhV+y5IBVA0CvQXYmI03VmFcdMhPnQFH3 owt+wm0Yma4JrPR+2ldgrQ3dkIZQa8jQJJprozeB87W4g1FBVMRv9VFFc1opgUFF 6ui7yKnuEcuhP2EoZlWllgCGBru/JMXNvExMK3bn0GVsAfjYCZ24FoRtfIfHunNA gFc6ULuQEssxc01e8WUiREHufedUcT+gbKuwq4tykmAEmAzRARym21qSPeMbfa92 rQYR+/Mif8yCyM0AYuf4sZxTE+NhDhwZXLO6atpoRiT7YugBFpfHvviLjc1J/KfN WIn8f/9w5AUXxR/j8iUVpmrTVEx55XJ43p0AMf5g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; q=dns; s=20180501; b=O66+f7CQ +KIy1DFQrx6wAHRzCXHTUb3JXzidL3Yg12G9yUrSK9X32AeCcjyNkLN4nYh/7S/e q2yb67EDP/lKI/qtAt6UhzlJKxns7xdhE98DPrZJ8n2SETuHUcvd5+MV1Ir7k5DQ HbbSVSCtrencGKNyHF85b6KtB/mGpYnJkA41IoYS9e2pMHU+yuEgfzoK4XGYXxtc j98i3kLvZNconnKL5nAfeCtIZFjfTUQE8Gr8J/imRX5uUyBDs7S8PdprJ5/TYB1s MqPnd7wSi4qztPmpXc/uT6YMY+baaBly9mvLOmZJIxluMb/NSOvpGicFgtyydxKU qBgSKLnVYaRvRw== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 906919eb (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Fri, 9 Jul 2021 08:34:35 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 (1.0) Subject: Re: FreeBSD awk behavior change proposal From: Michael Gmelin In-Reply-To: Date: Fri, 9 Jul 2021 10:34:33 +0200 Cc: freebsd-arch@freebsd.org Message-Id: <6B660498-9EBD-4A5A-B08C-CC9F3B6C4617@grem.de> References: To: Warner Losh X-Mailer: iPhone Mail (18F72) X-Rspamd-Queue-Id: 4GLmgL69z7z3rkw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N > On 9. Jul 2021, at 10:28, Warner Losh wrote: >=20 > =EF=BB=BFGreetings, >=20 > I've posted https://reviews.freebsd.org/D31114 which eliminates the last > delta we have from upstream one-true-awk. This delta has basically been > rejected by upstream as being a really bad idea. Let me give some > background. >=20 > In 2005, FreeBSD changed one-true-awk to honor the locale's collating orde= r. > https://svnweb.freebsd.org/base/head/usr.bin/awk/b.c.diff?annotate=3D14632= 2&pathrev=3D201988 > This was billed as a temporary patch. It was also compatible with > the then-current behavior of gawk. That temporary patch has lasted 16 > years now. >=20 > However, IEEE Std 1003.1-2008 changed the behaivor of ranges in regular > expressions outside of the "C" and "POSIX" locales to be undefined. >=20 > Starting in 2011, gawk 4.0 stopped using the locale for the range > regular expressions and used the traditional behavior only. The > maintainer had grown weary of answering why '[A-Z]' would sometimes > match lower-case expressions. The details about are explained here: > https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html= >=20 > To restore compatibility with other implementaitons of awk, revert this > patch. FreeBSD is the odd-system out. It also has the nice side effect > of eliminating the last of our differences with upstream one-true-awk. >=20 > I'd like to commit the change at least to -current. Ideally, I'd like to M= FC > the change. I believe better compatibility with gawk and other awk > implementations justifies this change in behavior because the current > behavior is outside the mainstream enough to be considered a bug. +1 From nobody Fri Jul 9 11:44:35 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 D5C0D1279D88 for ; Fri, 9 Jul 2021 11:44:44 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4GLrtN4flSz4kSW for ; Fri, 9 Jul 2021 11:44:43 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 169BiZ1D038497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2021 12:44:35 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 169BiZ4V038496; Fri, 9 Jul 2021 12:44:35 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202107091144.169BiZ4V038496@donotpassgo.dyslexicfish.net> Date: Fri, 09 Jul 2021 12:44:35 +0100 Organization: Dyslexic Fish To: imp@bsdimp.com, freebsd-arch@FreeBSD.org Subject: Re: FreeBSD awk behavior change proposal References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 09 Jul 2021 12:44:35 +0100 (BST) X-Rspamd-Queue-Id: 4GLrtN4flSz4kSW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > In 2005, FreeBSD changed one-true-awk to honor the locale's collating order. > https://svnweb.freebsd.org/base/head/usr.bin/awk/b.c.diff?annotate=146322&pathrev=201988 > This was billed as a temporary patch. It was also compatible with > the then-current behavior of gawk. That temporary patch has lasted 16 > years now. [ ... ] ` > To restore compatibility with other implementaitons of awk, revert this > patch. FreeBSD is the odd-system out. It also has the nice side effect > of eliminating the last of our differences with upstream one-true-awk. Yes! Definitely! For a few years, I've already been building locally with the following patch, so official parity would be useful! Cheers, Jamie --- contrib/one-true-awk/main.c.orig 2014-09-19 19:24:02.083097000 +0100 +++ contrib/one-true-awk/main.c 2018-05-24 14:53:38.539477000 +0100 @@ -62,7 +62,13 @@ const char *fs = NULL; setlocale(LC_CTYPE, ""); - setlocale(LC_COLLATE, ""); + /* As per more recent POSIX, collation for anything other than the 'C' */ + /* locale is undefined. As it messes up with expected results with */ + /* exotic locales, we force it to 'C' here to restore expected */ + /* behaviour + /* setlocale(LC_COLLATE, ""); */ + setlocale(LC_COLLATE, "C"); + setlocale(LC_NUMERIC, "C"); /* for parsing cmdline & prog */ cmdname = argv[0]; if (argc == 1) { From nobody Fri Jul 9 13:21: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 7090E7EA25D for ; Fri, 9 Jul 2021 13:21:40 +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 4GLv2D0z4Xz3J1p for ; Fri, 9 Jul 2021 13:21:39 +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 169DLTsl041685; Fri, 9 Jul 2021 06:21:29 -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 169DLTZY041684; Fri, 9 Jul 2021 06:21:29 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202107091321.169DLTZY041684@gndrsh.dnsmgr.net> Subject: Re: FreeBSD awk behavior change proposal In-Reply-To: To: Warner Losh Date: Fri, 9 Jul 2021 06:21:29 -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: 4GLv2D0z4Xz3J1p X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > Greetings, > > I've posted https://reviews.freebsd.org/D31114 which eliminates the last > delta we have from upstream one-true-awk. This delta has basically been > rejected by upstream as being a really bad idea. Let me give some > background. > > In 2005, FreeBSD changed one-true-awk to honor the locale's collating order. > https://svnweb.freebsd.org/base/head/usr.bin/awk/b.c.diff?annotate=146322&pathrev=201988 > This was billed as a temporary patch. It was also compatible with > the then-current behavior of gawk. That temporary patch has lasted 16 > years now. > > However, IEEE Std 1003.1-2008 changed the behaivor of ranges in regular > expressions outside of the "C" and "POSIX" locales to be undefined. > > Starting in 2011, gawk 4.0 stopped using the locale for the range > regular expressions and used the traditional behavior only. The > maintainer had grown weary of answering why '[A-Z]' would sometimes > match lower-case expressions. The details about are explained here: > https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html > > To restore compatibility with other implementaitons of awk, revert this > patch. FreeBSD is the odd-system out. It also has the nice side effect > of eliminating the last of our differences with upstream one-true-awk. > > I'd like to commit the change at least to -current. Ideally, I'd like to MFC > the change. I believe better compatibility with gawk and other awk > implementations justifies this change in behavior because the current > behavior is outside the mainstream enough to be considered a bug. > > I'd like to solicit input before I do this, however. My only concern on this is does anything in the ports system get tickled by this change, I know its a pita, but maybe have an exp run done? I reviewed and accepted the differential, and by examination I do not see how this could cause an issue now, so Meh give it a long back in -current and things should be ok. > Warner -- Rod Grimes rgrimes@freebsd.org From nobody Fri Jul 9 14:28:30 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 057C38D4216 for ; Fri, 9 Jul 2021 14:28:32 +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 4GLwWM6pQ0z3jch; Fri, 9 Jul 2021 14:28:31 +0000 (UTC) (envelope-from bapt@FreeBSD.org) 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 B8F57B570; Fri, 9 Jul 2021 14:28:31 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 2ABF2432DF; Fri, 9 Jul 2021 16:28:30 +0200 (CEST) Date: Fri, 9 Jul 2021 16:28:30 +0200 From: Baptiste Daroussin To: "Rodney W. Grimes" Cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: FreeBSD awk behavior change proposal Message-ID: <20210709142830.h7hqpuhhedtla5wr@aniel.nours.eu> References: <202107091321.169DLTZY041684@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-Disposition: inline In-Reply-To: <202107091321.169DLTZY041684@gndrsh.dnsmgr.net> X-ThisMailContainsUnwantedMimeParts: N On Fri, Jul 09, 2021 at 06:21:29AM -0700, Rodney W. Grimes wrote: > > Greetings, > > > > I've posted https://reviews.freebsd.org/D31114 which eliminates the last > > delta we have from upstream one-true-awk. This delta has basically been > > rejected by upstream as being a really bad idea. Let me give some > > background. > > > > In 2005, FreeBSD changed one-true-awk to honor the locale's collating order. > > https://svnweb.freebsd.org/base/head/usr.bin/awk/b.c.diff?annotate=146322&pathrev=201988 > > This was billed as a temporary patch. It was also compatible with > > the then-current behavior of gawk. That temporary patch has lasted 16 > > years now. > > > > However, IEEE Std 1003.1-2008 changed the behaivor of ranges in regular > > expressions outside of the "C" and "POSIX" locales to be undefined. > > > > Starting in 2011, gawk 4.0 stopped using the locale for the range > > regular expressions and used the traditional behavior only. The > > maintainer had grown weary of answering why '[A-Z]' would sometimes > > match lower-case expressions. The details about are explained here: > > https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html > > > > To restore compatibility with other implementaitons of awk, revert this > > patch. FreeBSD is the odd-system out. It also has the nice side effect > > of eliminating the last of our differences with upstream one-true-awk. > > > > I'd like to commit the change at least to -current. Ideally, I'd like to MFC > > the change. I believe better compatibility with gawk and other awk > > implementations justifies this change in behavior because the current > > behavior is outside the mainstream enough to be considered a bug. > > > > I'd like to solicit input before I do this, however. > > My only concern on this is does anything in the ports system get > tickled by this change, I know its a pita, but maybe have an exp > run done? I reviewed and accepted the differential, and by examination > I do not see how this could cause an issue now, so Meh give it a long > back in -current and things should be ok. > It would require an exp-run, but I really doubt anything use it, we have real collation support for not that long and actually bringing that collation support did break script expecting the behaviour warner is bringing in. Best regards, Bapt From nobody Fri Jul 9 14:36:40 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 BB6368D56F1 for ; Fri, 9 Jul 2021 14:36:42 +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 4GLwhp4jnGz3lJx; Fri, 9 Jul 2021 14:36:42 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f09870068fde36880f7c2a5.dip0.t-ipconnect.de [IPv6:2003:cd:5f09:8700:68fd:e368:80f7:c2a5]) (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 0E34FB574; Fri, 9 Jul 2021 14:36:41 +0000 (UTC) (envelope-from se@freebsd.org) To: "Rodney W. Grimes" , Warner Losh Cc: "freebsd-arch@freebsd.org" References: <202107091321.169DLTZY041684@gndrsh.dnsmgr.net> From: Stefan Esser Subject: Re: FreeBSD awk behavior change proposal Message-ID: <621331d0-b7bb-0365-23f7-999dd7155c19@freebsd.org> Date: Fri, 9 Jul 2021 16:36:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 In-Reply-To: <202107091321.169DLTZY041684@gndrsh.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dJDvvnd1LRP4KQ30mox9kZQ3vvK1popsX" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dJDvvnd1LRP4KQ30mox9kZQ3vvK1popsX Content-Type: multipart/mixed; boundary="aK93F3nj3f2dNOZVfqt9IvaPwTuUOH2EG"; protected-headers="v1" From: Stefan Esser To: "Rodney W. Grimes" , Warner Losh Cc: "freebsd-arch@freebsd.org" Message-ID: <621331d0-b7bb-0365-23f7-999dd7155c19@freebsd.org> Subject: Re: FreeBSD awk behavior change proposal References: <202107091321.169DLTZY041684@gndrsh.dnsmgr.net> In-Reply-To: <202107091321.169DLTZY041684@gndrsh.dnsmgr.net> --aK93F3nj3f2dNOZVfqt9IvaPwTuUOH2EG Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Am 09.07.21 um 15:21 schrieb Rodney W. Grimes: >> Greetings, >> >> I've posted https://reviews.freebsd.org/D31114 which eliminates the l= ast >> delta we have from upstream one-true-awk. This delta has basically bee= n >> rejected by upstream as being a really bad idea. Let me give some >> background. >> >> In 2005, FreeBSD changed one-true-awk to honor the locale's collating = order. >> https://svnweb.freebsd.org/base/head/usr.bin/awk/b.c.diff?annotate=3D1= 46322&pathrev=3D201988 >> This was billed as a temporary patch. It was also compatible with >> the then-current behavior of gawk. That temporary patch has lasted 16 >> years now. >> >> However, IEEE Std 1003.1-2008 changed the behaivor of ranges in regula= r >> expressions outside of the "C" and "POSIX" locales to be undefined. >> >> Starting in 2011, gawk 4.0 stopped using the locale for the range >> regular expressions and used the traditional behavior only. The >> maintainer had grown weary of answering why '[A-Z]' would sometimes >> match lower-case expressions. The details about are explained here: >> https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.= html >> >> To restore compatibility with other implementaitons of awk, revert thi= s >> patch. FreeBSD is the odd-system out. It also has the nice side effect= >> of eliminating the last of our differences with upstream one-true-awk.= >> >> I'd like to commit the change at least to -current. Ideally, I'd like = to MFC >> the change. I believe better compatibility with gawk and other awk >> implementations justifies this change in behavior because the current >> behavior is outside the mainstream enough to be considered a bug. >> >> I'd like to solicit input before I do this, however. >=20 > My only concern on this is does anything in the ports system get > tickled by this change, I know its a pita, but maybe have an exp > run done? I reviewed and accepted the differential, and by examination= > I do not see how this could cause an issue now, so Meh give it a long > back in -current and things should be ok. While possible in theory, I do not see how the ports system could be affected in practice. Ports are built in a C/POSIX locale on the official builders, and thus using a different locale and collating sequence on a user's system could break the port, but should never be a requirement. I have checked the port Makefiles for occurrences of LANG or LC_* outside specific command invocations (e.g. to set the locale for a sort command). These are the results: - ${USE_LOCALE} is used in bsd.port.mk, but the only case where a locale other than C or en_US.UTF-8 is specified is shells/fd which has USE_LOCALE=3Dja (i.e. does not specify an encoding). - ${ELIXIR_LOCALE} is used to set LANG and LC_ALL for USES=3Delixir. But ELIXIR_LOCALE is only ever set to en_US.UTF-8, AFAICT. - print/libpaper explicitly requests LANG=3DC LC_ALL=3DC for AWK. - The only port that requests a locale that is not en_US.UTF-8, en_US.ISO8859-1, or C is textproc/te-hunspell, which uses LANG=3Dte_IN.utf8 LC_ALL=3Dte_IN.utf8 to execute wordlist2hunspell, but only for this single shell script that does not invoke AWK and which does internally use LC_ALL=3DC for sort and uniq to make those not depend on an externally set locale. All other cases where LC_* or LANG are used in port Makefiles are in e.g. EXTRACT_CMD, TEST_ENV or in patch files, but those do enforce a C or C.UTF-8 locale (or en_US.*) and thus have no effect on the proposed change to AWK (besides often only setting the locale for a TAR file extraction). If an exp-run is planned for other reasons, using the modified AWK could be thrown in as a little risk modification. But I do not see any possible effect on the ports system, after performing a grep for LANG and LC_* on the Makefiles and patch files. Regards, STefan --aK93F3nj3f2dNOZVfqt9IvaPwTuUOH2EG-- --dJDvvnd1LRP4KQ30mox9kZQ3vvK1popsX Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmDoXvgFAwAAAAAACgkQR+u171r99UQ9 5wf/Uht4XKAbMIUdEx677UWmpFlICGwHfi9KZFVn3oAHFdRi8QeeziLcLjyPIFiuqUdRTD8gPRft 1h9HyIAAJIBSrbr1Hf5KlERGtY0TgIOLWEvvpc5JviD6yFkcYkluW4dC4mdWzqYxUJlHIcXBFxDL 29WmXXNMUUvNL9MzPuXZxaLd7zCbskPv6zVj91yr4oQ1n8bPEb3/zIrWmEciI7nRTCm01mpEtZ76 2VXmYWM8TNk1K95oe71bZ5W2zauob3SgYNNE6Xqs66vVkRB6ul/9IeMDZ4DEsUyaeZtbJrmZl0kB POw9T098FqqWgEmd85kRa/hZe+2tqrCKA+lk+pTMQg== =Ph1M -----END PGP SIGNATURE----- --dJDvvnd1LRP4KQ30mox9kZQ3vvK1popsX-- From nobody Sat Jul 10 12:22:05 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 F2E5A8D155B for ; Sat, 10 Jul 2021 12:22: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 4GMTg74QS3z4qZ9; Sat, 10 Jul 2021 12:22:11 +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 16ACM6UN045676; Sat, 10 Jul 2021 05:22:06 -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 16ACM5Sb045675; Sat, 10 Jul 2021 05:22:05 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202107101222.16ACM5Sb045675@gndrsh.dnsmgr.net> Subject: Re: FreeBSD awk behavior change proposal In-Reply-To: <621331d0-b7bb-0365-23f7-999dd7155c19@freebsd.org> To: Stefan Esser Date: Sat, 10 Jul 2021 05:22:05 -0700 (PDT) CC: "Rodney W. Grimes" , 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: 4GMTg74QS3z4qZ9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > Am 09.07.21 um 15:21 schrieb Rodney W. Grimes: > >> Greetings, > >> > >> I've posted https://reviews.freebsd.org/D31114 which eliminates the last > >> delta we have from upstream one-true-awk. This delta has basically been > >> rejected by upstream as being a really bad idea. Let me give some > >> background. > >> > >> In 2005, FreeBSD changed one-true-awk to honor the locale's collating order. > >> https://svnweb.freebsd.org/base/head/usr.bin/awk/b.c.diff?annotate=146322&pathrev=201988 > >> This was billed as a temporary patch. It was also compatible with > >> the then-current behavior of gawk. That temporary patch has lasted 16 > >> years now. > >> > >> However, IEEE Std 1003.1-2008 changed the behaivor of ranges in regular > >> expressions outside of the "C" and "POSIX" locales to be undefined. > >> > >> Starting in 2011, gawk 4.0 stopped using the locale for the range > >> regular expressions and used the traditional behavior only. The > >> maintainer had grown weary of answering why '[A-Z]' would sometimes > >> match lower-case expressions. The details about are explained here: > >> https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html > >> > >> To restore compatibility with other implementaitons of awk, revert this > >> patch. FreeBSD is the odd-system out. It also has the nice side effect > >> of eliminating the last of our differences with upstream one-true-awk. > >> > >> I'd like to commit the change at least to -current. Ideally, I'd like to MFC > >> the change. I believe better compatibility with gawk and other awk > >> implementations justifies this change in behavior because the current > >> behavior is outside the mainstream enough to be considered a bug. > >> > >> I'd like to solicit input before I do this, however. > > > > My only concern on this is does anything in the ports system get > > tickled by this change, I know its a pita, but maybe have an exp > > run done? I reviewed and accepted the differential, and by examination > > I do not see how this could cause an issue now, so Meh give it a long > > back in -current and things should be ok. > > While possible in theory, I do not see how the ports system could > be affected in practice. > > Ports are built in a C/POSIX locale on the official builders, and > thus using a different locale and collating sequence on a user's > system could break the port, but should never be a requirement. > > I have checked the port Makefiles for occurrences of LANG or LC_* > outside specific command invocations (e.g. to set the locale for > a sort command). These are the results: > > - ${USE_LOCALE} is used in bsd.port.mk, but the only case where > a locale other than C or en_US.UTF-8 is specified is shells/fd > which has USE_LOCALE=ja (i.e. does not specify an encoding). > > - ${ELIXIR_LOCALE} is used to set LANG and LC_ALL for USES=elixir. > But ELIXIR_LOCALE is only ever set to en_US.UTF-8, AFAICT. > > - print/libpaper explicitly requests LANG=C LC_ALL=C for AWK. > > - The only port that requests a locale that is not en_US.UTF-8, > en_US.ISO8859-1, or C is textproc/te-hunspell, which uses > LANG=te_IN.utf8 LC_ALL=te_IN.utf8 to execute wordlist2hunspell, > but only for this single shell script that does not invoke AWK > and which does internally use LC_ALL=C for sort and uniq to > make those not depend on an externally set locale. > > All other cases where LC_* or LANG are used in port Makefiles are > in e.g. EXTRACT_CMD, TEST_ENV or in patch files, but those do > enforce a C or C.UTF-8 locale (or en_US.*) and thus have no effect > on the proposed change to AWK (besides often only setting the locale > for a TAR file extraction). > > If an exp-run is planned for other reasons, using the modified > AWK could be thrown in as a little risk modification. > > But I do not see any possible effect on the ports system, after > performing a grep for LANG and LC_* on the Makefiles and patch > files. > > Regards, STefan > My concers are/were along the lines that awk was explicitly setting or actually ignoring the users LC, what happens if some user WANTS to build a port using some other locale, could that lead to bad awk results, and a failed build. Though it is true this would not effect the production FreeBSD build infustructure, my concerns are more along the lines of users that DO build for other locales that this change MAY effect. An exp run would not catch this, so is rather pointless, but we should keep our eyes out for this other failure mechanism. Regards, -- Rod Grimes rgrimes@freebsd.org From nobody Sat Jul 10 14:24:56 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 463EE1245557 for ; Sat, 10 Jul 2021 14:24:58 +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 4GMXNp1TGQz3QvT; Sat, 10 Jul 2021 14:24:58 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f098700245c8f2f918b8ed8.dip0.t-ipconnect.de [IPv6:2003:cd:5f09:8700:245c:8f2f:918b:8ed8]) (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 96B3B270E6; Sat, 10 Jul 2021 14:24:57 +0000 (UTC) (envelope-from se@freebsd.org) To: "Rodney W. Grimes" Cc: Warner Losh , "freebsd-arch@freebsd.org" References: <202107101222.16ACM5Sb045675@gndrsh.dnsmgr.net> From: Stefan Esser Subject: Re: FreeBSD awk behavior change proposal Message-ID: <673249fc-5505-f2a4-956b-48b450793f29@freebsd.org> Date: Sat, 10 Jul 2021 16:24:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 In-Reply-To: <202107101222.16ACM5Sb045675@gndrsh.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IZa9e4BHglrfzcliEQWjWaLqji2U6n5CI" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IZa9e4BHglrfzcliEQWjWaLqji2U6n5CI Content-Type: multipart/mixed; boundary="KVPb0NtaugowGaCNJpcemepB7ufzZKHCi"; protected-headers="v1" From: Stefan Esser To: "Rodney W. Grimes" Cc: Warner Losh , "freebsd-arch@freebsd.org" Message-ID: <673249fc-5505-f2a4-956b-48b450793f29@freebsd.org> Subject: Re: FreeBSD awk behavior change proposal References: <202107101222.16ACM5Sb045675@gndrsh.dnsmgr.net> In-Reply-To: <202107101222.16ACM5Sb045675@gndrsh.dnsmgr.net> --KVPb0NtaugowGaCNJpcemepB7ufzZKHCi Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: quoted-printable Am 10.07.21 um 14:22 schrieb Rodney W. Grimes: >> Am 09.07.21 um 15:21 schrieb Rodney W. Grimes: >>>> Greetings, >>>> >>>> I've posted https://reviews.freebsd.org/D31114 which eliminates the= last >>>> delta we have from upstream one-true-awk. This delta has basically b= een >>>> rejected by upstream as being a really bad idea. Let me give some >>>> background. >>>> >>>> In 2005, FreeBSD changed one-true-awk to honor the locale's collatin= g order. >>>> https://svnweb.freebsd.org/base/head/usr.bin/awk/b.c.diff?annotate=3D= 146322&pathrev=3D201988 >>>> This was billed as a temporary patch. It was also compatible with >>>> the then-current behavior of gawk. That temporary patch has lasted 1= 6 >>>> years now. >>>> >>>> However, IEEE Std 1003.1-2008 changed the behaivor of ranges in regu= lar >>>> expressions outside of the "C" and "POSIX" locales to be undefined. >>>> >>>> Starting in 2011, gawk 4.0 stopped using the locale for the range >>>> regular expressions and used the traditional behavior only. The >>>> maintainer had grown weary of answering why '[A-Z]' would sometimes >>>> match lower-case expressions. The details about are explained here: >>>> https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locale= s.html >>>> >>>> To restore compatibility with other implementaitons of awk, revert t= his >>>> patch. FreeBSD is the odd-system out. It also has the nice side effe= ct >>>> of eliminating the last of our differences with upstream one-true-aw= k. >>>> >>>> I'd like to commit the change at least to -current. Ideally, I'd lik= e to MFC >>>> the change. I believe better compatibility with gawk and other awk >>>> implementations justifies this change in behavior because the curren= t >>>> behavior is outside the mainstream enough to be considered a bug. >>>> >>>> I'd like to solicit input before I do this, however. >>> >>> My only concern on this is does anything in the ports system get >>> tickled by this change, I know its a pita, but maybe have an exp >>> run done? I reviewed and accepted the differential, and by examinati= on >>> I do not see how this could cause an issue now, so Meh give it a long= >>> back in -current and things should be ok. >> >> While possible in theory, I do not see how the ports system could >> be affected in practice. >> >> Ports are built in a C/POSIX locale on the official builders, and >> thus using a different locale and collating sequence on a user's >> system could break the port, but should never be a requirement. >> >> I have checked the port Makefiles for occurrences of LANG or LC_* >> outside specific command invocations (e.g. to set the locale for >> a sort command). These are the results: >> >> - ${USE_LOCALE} is used in bsd.port.mk, but the only case where >> a locale other than C or en_US.UTF-8 is specified is shells/fd >> which has USE_LOCALE=3Dja (i.e. does not specify an encoding). >> >> - ${ELIXIR_LOCALE} is used to set LANG and LC_ALL for USES=3Delixir. >> But ELIXIR_LOCALE is only ever set to en_US.UTF-8, AFAICT. >> >> - print/libpaper explicitly requests LANG=3DC LC_ALL=3DC for AWK. >> >> - The only port that requests a locale that is not en_US.UTF-8, >> en_US.ISO8859-1, or C is textproc/te-hunspell, which uses >> LANG=3Dte_IN.utf8 LC_ALL=3Dte_IN.utf8 to execute wordlist2hunspell, >> but only for this single shell script that does not invoke AWK >> and which does internally use LC_ALL=3DC for sort and uniq to >> make those not depend on an externally set locale. >> >> All other cases where LC_* or LANG are used in port Makefiles are >> in e.g. EXTRACT_CMD, TEST_ENV or in patch files, but those do >> enforce a C or C.UTF-8 locale (or en_US.*) and thus have no effect >> on the proposed change to AWK (besides often only setting the locale >> for a TAR file extraction). >> >> If an exp-run is planned for other reasons, using the modified >> AWK could be thrown in as a little risk modification. >> >> But I do not see any possible effect on the ports system, after >> performing a grep for LANG and LC_* on the Makefiles and patch >> files. >> >> Regards, STefan >> >=20 > My concers are/were along the lines that awk was explicitly > setting or actually ignoring the users LC, what happens if > some user WANTS to build a port using some other locale, could > that lead to bad awk results, and a failed build. I understand your concern, but since the collating sequence is different for different encodings even for the same location (e.g. *.UTF-8 vs *.ISO8859-1) the result would be unpredictable, even for a port that addresses a spefific country. The same applies to the different collating sequences of cyrillic or japanese encodings that exist. Yes, in theory that is possible, but it would lead to a program that is bound not only to some language but also the specific encoding it has been built with - and that would be a paradox situation for a locale aware program. And considering the fact, that all other operating systems are already in line with the proposed change, these sources could not be built on them. If some software is meant to be built on Linux, then the new AWK behavior will already have been assumed. I have looked for locales passed by our ports system, not in any port's sources, for that reason. It would not build on Linux. We do only have to check out that the ports system does not in any way depend on the current behavior of AWK, and that's what I have looked for without finding a single case where it might. > Though it is true this would not effect the production FreeBSD > build infustructure, my concerns are more along the lines of > users that DO build for other locales that this change MAY > effect. The most obvious effect of the proposed change is that [A-Z] will definitely not include lower case letters, while it does in a number of UTF-8 locales (but not ISO8859-x) now. > An exp run would not catch this, so is rather pointless, > but we should keep our eyes out for this other failure > mechanism. >=20 > Regards, I'm supporting the proposed change, and in the unlikely case that there is a port that stops working due to this change, I'd be willing to fix the underlying issue, just assign the PR to me ... Regards, STefan --KVPb0NtaugowGaCNJpcemepB7ufzZKHCi-- --IZa9e4BHglrfzcliEQWjWaLqji2U6n5CI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmDprbgFAwAAAAAACgkQR+u171r99UR1 8Af/V6CoIhiwwlM7QlaRGZcYxzbmiOckNcanljzmSk8Thvtp43Y0Xu5RFXrhBuC0Rhgqq44144zI 0SOiDwEVjsKgTo3eqXY+L9s3Pc8FmUQrfVTKyW9H8CNScJsbNA9+l38zlm45xyCoZd6V4INbtVLE AF8dGRJt4vKAnluENxfJtgYTKlfGllyJBuLIcg+8tSza6Zng7gqpKcK3XhZHHQcCthuKxxah7fi/ 3o63zrMN4c/QAmim0LZeIenTS1l535vbMRyfQfjIITrIDyQ3SeaHKdqtnLxlCn4YWMbYACFaSrzc Zdthy4wfqTp4fKxGZk+uOSQkYRWXEdvUspPQmCv7/A== =fuuW -----END PGP SIGNATURE----- --IZa9e4BHglrfzcliEQWjWaLqji2U6n5CI-- From nobody Tue Jul 13 15:13:08 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 E08748D41E8 for ; Tue, 13 Jul 2021 15:13:18 +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 4GPPKB0rDMz3PDm for ; Tue, 13 Jul 2021 15:13:17 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (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)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 973042602CC; Tue, 13 Jul 2021 17:13:15 +0200 (CEST) Subject: Re: Killing Giant for 13 To: gljennjohn@gmail.com, Warner Losh Cc: "Rodney W. Grimes" , Michael Gmelin , "freebsd-arch@freebsd.org" References: <201911260917.xAQ9Hcf1001914@gndrsh.dnsmgr.net> <20191126193555.047a63cf@bsd64.grem.de> <20191126194750.3ff939c3@ernst.home> <20191127082615.7c59857c@ernst.home> From: Hans Petter Selasky Message-ID: Date: Tue, 13 Jul 2021 17:13:08 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.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 In-Reply-To: <20191127082615.7c59857c@ernst.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GPPKB0rDMz3PDm 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 [0.49 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.998]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; SPAMHAUS_ZRD(0.00)[2a01:4f8:c17:6c4b::2:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:4f8:c17:6c4b::2:from]; NEURAL_SPAM_LONG(0.56)[0.558]; NEURAL_HAM_MEDIUM(-0.77)[-0.767]; FREEMAIL_TO(0.00)[gmail.com,bsdimp.com]; 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]; MAILMAN_DEST(0.00)[freebsd-arch] X-ThisMailContainsUnwantedMimeParts: N Hi, I've been pondering with some ideas around Giant removal too. First of all, I think the first step getting rid of Giant, is to move all Giant usage related to newbus into two own global functions, so we can start working on what and how the device tree should be protected separately. Personally I would prefer a sleepable EPOCH (See https://reviews.freebsd.org/D30376), because that would interact nicely with freeing the device softc and other internal structures. void device_tree_lock() { mtx_lock(&Giant); } void device_tree_unlock() { mtx_unlock(&Giant); } Secondly I think that if we can remove all code sleeping with Giant, so to speak, either by using msleep(&Giant) or by using M_NOWAIT, we can get rid of the DROP and PICKUP Giant macros, and get Giant out of the fast path in all of the kernel. Then if Giant i still around as a mutex, it won't have that much impact! Warner, what is the status of your Giant work? --HPS From nobody Tue Jul 13 20:27:46 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 B6268127B28B for ; Tue, 13 Jul 2021 20:27:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GPXJG4YxLz3J8b for ; Tue, 13 Jul 2021 20:27:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x733.google.com with SMTP id p202so6570874qka.12 for ; Tue, 13 Jul 2021 13:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kC3LyvcTOoexJeM5DNdm0WaSdTt4Gir9Q3eczkefzFE=; b=SLuRZHyzq25yGBnA7jtLNxsrVz4Wv02Py/h0MRl9pQepVmzHOoJ/ARnvxfNVnQS7EJ xcdo4rZ8bVlNSjxH96ivwUIbAy7TWBMh9JpZqI6jGYC0u1By4XBfQseFwAMBj+TSPfDK tN5WjykcjMbMHMD5wqyjaFjtK3RnhrUKCAeGPVikZPClnHiARu3PRHxy49kz9Dlb5GrL RNIMqefyrCGIA7aZfi2WK+nyZ4c81164bjrDuw4sxrG8UmkUB7TFOyE6icDpNcf9Nqox O92rGBR5dpNf8W24qPsK4g1+MjzVIfuoiCi+CRKwba6rN9cTye3TmaPRq0vHzTlrtxOr QhXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kC3LyvcTOoexJeM5DNdm0WaSdTt4Gir9Q3eczkefzFE=; b=diqEfqvKKMs/WM61T6+LtsUkWJcvMx96VjRnhigMxCO5NTXvbFb2+zsJngAVX5EXIN loLNIZy3hEVw/sbX8VoCHgxLGochW/04lPzhpeSGTQt5kWminWIX8G8zv7kCkBO4PVyP ThMLpx3Z5I+RQeQrGcIVcwb8nbR4G8gsH3LL3Szh8ZCEkhLkmSlrOgLCcA0zl5WM/Dx0 eL0f8Dab0Fnrs7QQhtZ6gNY8DgIGBV/wVvnarig+6o+UWBaq7NQeuqpN/0qPqWoab6j+ V5kuH+HEHZkGtn5Yz9IK+y3flYnMpDPbmaVVR5tjq2flysfTSpQ1pNHa1TN4cMG2oKm0 cYSw== X-Gm-Message-State: AOAM532ULXHDj2RJUZeKgmTrwXrrC5RKT11iC569rMxvYYeIkfZZ3Odv XPdTkpzSY15Mkjf+P4KJl+6l1hGELOCIy7pfUopOqg== X-Google-Smtp-Source: ABdhPJxVWkPDWqUVyBjj6rDqhd4PvtowqI3FeJ6Z482CImr7Cmig0+xSIngG8rbxQX9Cp81JVApvH/Cx31DGdgQ1evg= X-Received: by 2002:a37:e10e:: with SMTP id c14mr5941690qkm.206.1626208077530; Tue, 13 Jul 2021 13:27:57 -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: <201911260917.xAQ9Hcf1001914@gndrsh.dnsmgr.net> <20191126193555.047a63cf@bsd64.grem.de> <20191126194750.3ff939c3@ernst.home> <20191127082615.7c59857c@ernst.home> In-Reply-To: From: Warner Losh Date: Tue, 13 Jul 2021 14:27:46 -0600 Message-ID: Subject: Re: Killing Giant for 13 To: Hans Petter Selasky Cc: Gary Jennejohn , "Rodney W. Grimes" , Michael Gmelin , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000cad85405c70712e3" X-Rspamd-Queue-Id: 4GPXJG4YxLz3J8b X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000cad85405c70712e3 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 13, 2021 at 9:13 AM Hans Petter Selasky wrote: > Hi, > > I've been pondering with some ideas around Giant removal too. > > First of all, I think the first step getting rid of Giant, is to move > all Giant usage related to newbus into two own global functions, so we > can start working on what and how the device tree should be protected > separately. Personally I would prefer a sleepable EPOCH (See > https://reviews.freebsd.org/D30376), because that would interact nicely > with freeing the device softc and other internal structures. > Yea, I'm unsure of epoch or smr is the right path forward here, but at a high level, I'm thinking along the same lines as you are. > void > device_tree_lock() > { > mtx_lock(&Giant); > } > > void > device_tree_unlock() > { > mtx_unlock(&Giant); > } > I have a tree with this change worked through already, though with a different name. I've also pushed Giant down a bit in a few places too in that tree. > Secondly I think that if we can remove all code sleeping with Giant, so > to speak, either by using msleep(&Giant) or by using M_NOWAIT, we can > get rid of the DROP and PICKUP Giant macros, and get Giant out of the > fast path in all of the kernel. Then if Giant i still around as a mutex, > it won't have that much impact! > > Warner, what is the status of your Giant work? > Stalled a bit for want of time, and waiting on the big ball of goo that's the x86 keyboard / console driver to reach some kind of resolution. I posted https://reviews.freebsd.org/D23388 a while back, but got bogged down removing the Giant requirement from device_busy because there's a few infrequently used drivers that are tricky to test that are using it. https://reviews.freebsd.org/D26284 has the code to do that, but I think I got distracted by the quiesce discussion which is a better way to cope, but again, involves a number of infrequently used drivers. Both of these reviews likely needs to be rebased, if I don't happen to have them in a local git branch (they date from the dawn of my git svn usage, so maybe got dropped along the way by mistake). Warner --000000000000cad85405c70712e3-- From nobody Fri Jul 16 20:28:20 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 F3AB512A48C2 for ; Fri, 16 Jul 2021 20:28:30 +0000 (UTC) (envelope-from yzhong@freebsdfoundation.org) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GRN9V0xP4z4p9m for ; Fri, 16 Jul 2021 20:28:29 +0000 (UTC) (envelope-from yzhong@freebsdfoundation.org) Received: by mail-lf1-x131.google.com with SMTP id y42so18029631lfa.3 for ; Fri, 16 Jul 2021 13:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsdfoundation.org; s=gfnp-20170908; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=/HdI7kVDzAWI9Itx1d+tz4thOEvlGBdecI3mF8LEnng=; b=gKVAQYzrbDXa1M7N6VknxHdNkBgnScaWhIFw6dzin1PIWJRQglw7EtJ8fYgYpEhk8z ed4sa3U8wILWEb9d/TOzBCd3C7Pa1yZjLhPd6FT1h1XFCKui7PE6u+FcbH/vYPwDD5J8 F+piRy6WqMzlzXNmbw0mwN2v5skmLaKmJdH7S0Yfd/WLhd5fXgMxIR9Xl8LhcEJzkfjQ tMb9fu8dYSpVDe9l9Jlxs/OO1uK/WjjhEszZjmTYaXVM43R3fnKEsAlhbATK85XyOS6z 60nu/cl59rBxW63LENNyVzEUUSYIsPYO+ib6qTiozaSyvJdEB84sEBwGygjlw+oDzDmH rNsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=/HdI7kVDzAWI9Itx1d+tz4thOEvlGBdecI3mF8LEnng=; b=Q8Ny9JxPuAYXGB+iBmOuiJJkNXDEnpn0FQ5k4eNqgrQwr+Xk0dDGF6L5lNOOaO+7dB 8BtiBJMAP7xaRni8Vs8UIv4ve5ar83pP4pHOw5FBlKVPWluHU6BEYCKwcHMHAIgF2Z8U I1YgItwCKiJiMArBZp8BcUIwDyNk86pp2x7j0UNFZVS6Ft/vhR4diMr9aZeqJVxweT5o Iz/UrzCtK4PlWFxIN4ih+9sKjAZCWM8oE1Tma6EdL7q46GdjbnWk2JhdVo9As113j2ZJ GtPUCr0mh2jbfjCLhinFO/CqnuXewtHU7sdQsYnLZ9ExzZn88TMGQlZy4ipwgAkKYrAG w5gw== X-Gm-Message-State: AOAM530wczQH7luaPE3einqJMe0iIfdOQrPE6WL0q9QTCWN3ycCRuY4D GquHNQo/sLNFj60qAefzvP/ie5hmRdRfMQN09vk6hFvtmBh6RQd3q00= X-Google-Smtp-Source: ABdhPJwxZdIaHwmsTQVC6HJkx3PA37m0Z5ewwSTNj1fkGMar21e9+djm+dOhhHQvIC7/Rrwe+PtvJBhGVBEvlZD35IA= X-Received: by 2002:a05:6512:4004:: with SMTP id br4mr9017519lfb.2.1626467308166; Fri, 16 Jul 2021 13:28:28 -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 Date: Fri, 16 Jul 2021 13:28:20 -0700 Message-ID: Subject: Experimental FreeBSD installer work To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4GRN9V0xP4z4p9m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=freebsdfoundation.org header.s=gfnp-20170908 header.b=gKVAQYzr; dmarc=pass (policy=quarantine) header.from=freebsdfoundation.org; spf=pass (mx1.freebsd.org: domain of yzhong@freebsdfoundation.org designates 2a00:1450:4864:20::131 as permitted sender) smtp.mailfrom=yzhong@freebsdfoundation.org 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)[freebsdfoundation.org:s=gfnp-20170908]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::131:from:127.0.2.255]; DKIM_TRACE(0.00)[freebsdfoundation.org:+]; DMARC_POLICY_ALLOW(-0.50)[freebsdfoundation.org,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::131:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::131:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] Reply-To: yzhong@freebsdfoundation.org From: Yang Zhong via freebsd-arch X-Original-From: Yang Zhong X-ThisMailContainsUnwantedMimeParts: N For the past several weeks as part of my internship at the FreeBSD Foundation, I've been working on an experimental FreeBSD installer. It's intended to test out several different ideas. Here is a repository for the installer itself, with screenshots: https://github.com/yangzhong-freebsd/lua-httpd, and a repository for a live ISO containing the installer: https://yangzhong-freebsd/ISO. Right now, the installer is very rough, but can handle installs with basic configuration options. It would be very helpful for me if you try using the installer and give feedback on the process. The most prominent feature of this installer is that it uses a graphical, web interface. It works by running a server from the installation medium; you configure and execute the install through a browser on localhost. This work was started by Ryan Moeller: https://gitlab.com/freqlabs/lua-httpd/-/tree/freebsd-install, and my installer work adds on to it. Another possible benefit of this interface is that it could support a 'remote install' option where the server runs on the target machine, but you configure the install over a network from some other computer. I haven=E2=80=99t done much work or research on this idea, so I don=E2=80= =99t have many concrete things to say here. The remote-install version of the installer would be different in several ways: for instance, the keymap configuration would no longer be changing the keymap in the actual install interface. There are some other problems that I=E2=80=99ve noted bu= t not explored, such as the problem of sending passwords over the internet. An installation in this installer proceeds as follows: The user completes a configuration form in the browser and the backend writes the configuration to a text file. When the user clicks the final install button, the installer runs a program that converts that config file into one that bsdinstall accepts, and then runs bsdinstall with that script. I'm also thinking about improvements that can be made to the user-friendliness of the installer. From what I've read and discussed with others about, more automatic configuration would make a big improvement to the installation process. There are several ways this could be achieved: Ed Maste suggested a choice of 'pre-set' configurations, designed for different use cases. This page explores this idea, calling them 'profiles': www.wonkity.com/~wblock/docs/html/installers.html. As for future work, here are some problems I have with this installer's current design: 1. bsdinstall offers many different ways to configure partitions, one way being to open a terminal and manually do it. This works because bsdinstall does the partitioning immediately after partitions have been configured. In the experimental installer, the partitioning options get written to the configuration file, and everything is done at the end, all at once. It doesn't seem possible to offer the manual partitioning option while keeping this property of the experimental installer. 2. Because the keymap configurator in the installer sets keymap on demand, it sets the X keymap but not the console one. I intend to add the option to install a graphical environment in the installer, but haven't done that work yet. So, if you change the layout, it'll be set for the rest of the installation process, but not in the final installed system which boots to the console. There does not seem to be a straightforward way to map X keymap/variant options to console keymap layouts. While this is not an enormous problem, I'd like to come up with a good way to configure both layouts at the same time, especially because I use a non-standard layout myself. 3. This is less of a concrete issue, but I feel is a problem with operating system installers in general. I'm a fairly new FreeBSD user, and I've experienced this situation several times: I would want to configure some setting on my machine and I'd recall that this setting was an option in bsdinstall, so it must be possible, but I don't know how bsdinstall does it. It feels like the installer does a lot of convenient things that then have to be 're-discovered' once you start using the operating system post-install. To help with this, I'd like the installer to have a 'teaching' component to it, where each option has some text describing how the installer actually does the configuration. I think something like that would help new users understand that the installer isn't magic, it's just running simple commands for most configuration options. Something like that would certainly have helped me. 4. Things like setting the date and time could also benefit from a more automatic process. Selecting a timezone is one of the more convoluted parts of the current installer, as it first asks you the cryptic "Is your hardware clock set to UTC?" question, and then makes you go down some deeply nested menus. There are several web-based timezone selection interfaces where you simply pick your location on a world map, though the ones I've tried have not been very good. The installer could also geolocate your timezone using your IP address. --- As you can see, the installer is nowhere near ready for serious use, and is currently more of a testing ground for a bunch of interesting ideas. I said this earlier, but I'd appreciate any testing of the installer as it is, as I have not tested it myself very comprehensively. I'd also like to hear any of your thoughts on the direction of this work, or any ideas on installer design/implementation in general. Finally, the installer doesn't yet have a name, so let me know if you can think of a fitting name for it. From nobody Fri Jul 16 22:25:57 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 0FA2812764A1 for ; Fri, 16 Jul 2021 22:26:37 +0000 (UTC) (envelope-from m.e.sanliturk@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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GRQnm62HFz3h7d for ; Fri, 16 Jul 2021 22:26:36 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id f9so13677597wrq.11 for ; Fri, 16 Jul 2021 15:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o/dsRx1GVuJwDH2kiczy9j1zykiv36zKV5wMHP1U+ss=; b=WnXANx4Cjzfsq8BIXW6RM1ig1J1Y/Zoe+xuOCg1dyUeb73hM8X9b1RzcK/uqTzVbMW uoJAdplzz05rT3rEsQhypYl3qEabAju1kcV8W6uhbLifTWa3+KjwzOuyvdw9ND1tsoUO FCpdKJ6nqj0BrXBfORIbpLmtZh+Zq+q9qV/ayLgs+McaV+xBdMpCrvDheTc9pT8Ji895 Ebh4/sL67Tqlk1iLFaZmrBQyQJ863pmU27obs09USoWpa7Snm8NYQxF4oxnjMoSyH3yj o1gkaE4TCMvUvla/6RiLqalSrC7WPAY3UTypTDHO7C92xqb6yde1sQTArF0ac3qrbKod ISFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o/dsRx1GVuJwDH2kiczy9j1zykiv36zKV5wMHP1U+ss=; b=cT15/4Xl3kzAsDACj7xfwc47OF1g3ySQc5PjurR56BH2fHzKIVYvMzd6siBB6gY82s cNpOFdNXjpS3GFeMWm90gYDU1oIG8miD/ht861G60qFcZi8gDOSDCRHNheSCO0lbH4YG /horNIrPrNdWmNOE6fCPJ/ctWartjBqBoG0SzONoMFcE7DEkd/+rYF2pak7I01URSEIn gWxjLHAVkKGbA5ae8VTt3VQ9XO6BYkeXUFY/xHKn67sCYdrlFOsuCEi1gAcitW+tBacn g/uHJdDUpw3qEVdt1dIMT6d/6VTF8TfS1hkNCd85Me+nAewNUCAxc5tNb4P26uoj23Dx G1mg== X-Gm-Message-State: AOAM532TF3MdfN4wfODiaa1Exn+1d588Cl9a6dyOun4+gwpQ76tAyTvR Ngps1hehEihHC7Sogt/e3fHaqf1aSaDHtI2CiLM= X-Google-Smtp-Source: ABdhPJx870d8stzm4rdk+RLoHUZJGZf+3kq43EExSF2pXh9tF1U+LwHd0vUxrcx0Fx4YmmMFgf4nlI+LxXuSKnVZDzE= X-Received: by 2002:adf:a1c2:: with SMTP id v2mr15068322wrv.155.1626474395417; Fri, 16 Jul 2021 15:26: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 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Sat, 17 Jul 2021 01:25:57 +0300 Message-ID: Subject: Re: Experimental FreeBSD installer work To: yzhong@freebsdfoundation.org Cc: FreeBSD Arch Content-Type: multipart/alternative; boundary="00000000000093408905c745141f" X-Rspamd-Queue-Id: 4GRQnm62HFz3h7d 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: Y --00000000000093408905c745141f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 16, 2021 at 11:29 PM Yang Zhong via freebsd-arch < freebsd-arch@freebsd.org> wrote: > For the past several weeks as part of my internship at the FreeBSD > Foundation, I've been working on an experimental FreeBSD installer. > It's intended to test out several different ideas. Here is a > repository for the installer itself, with screenshots: > https://github.com/yangzhong-freebsd/lua-httpd, and a repository for a > live ISO containing the installer: https://yangzhong-freebsd/ISO. > Right now, the installer is very rough, but can handle installs with > basic configuration options. It would be very helpful for me if you > try using the installer and give feedback on the process. > > The most prominent feature of this installer is that it uses a > graphical, web interface. It works by running a server from the > installation medium; you configure and execute the install through a > browser on localhost. This work was started by Ryan Moeller: > https://gitlab.com/freqlabs/lua-httpd/-/tree/freebsd-install, and my > installer work adds on to it. > > Another possible benefit of this interface is that it could support a > 'remote install' option where the server runs on the target machine, > but you configure the install over a network from some other computer. > I haven=E2=80=99t done much work or research on this idea, so I don=E2=80= =99t have > many concrete things to say here. The remote-install version of the > installer would be different in several ways: for instance, the keymap > configuration would no longer be changing the keymap in the actual > install interface. There are some other problems that I=E2=80=99ve noted = but > not explored, such as the problem of sending passwords over the > internet. > > An installation in this installer proceeds as follows: The user > completes a configuration form in the browser and the backend writes > the configuration to a text file. When the user clicks the final > install button, the installer runs a program that converts that config > file into one that bsdinstall accepts, and then runs bsdinstall with > that script. > > I'm also thinking about improvements that can be made to the > user-friendliness of the installer. From what I've read and discussed > with others about, more automatic configuration would make a big > improvement to the installation process. There are several ways this > could be achieved: Ed Maste suggested a choice of 'pre-set' > configurations, designed for different use cases. This page explores > this idea, calling them 'profiles': > www.wonkity.com/~wblock/docs/html/installers.html. > > As for future work, here are some problems I have with this > installer's current design: > > 1. bsdinstall offers many different ways to configure partitions, one > way being to open a terminal and manually do it. This works because > bsdinstall does the partitioning immediately after partitions have > been configured. In the experimental installer, the partitioning > options get written to the configuration file, and everything is done > at the end, all at once. It doesn't seem possible to offer the manual > partitioning option while keeping this property of the experimental > installer. > > 2. Because the keymap configurator in the installer sets keymap on > demand, it sets the X keymap but not the console one. I intend to add > the option to install a graphical environment in the installer, but > haven't done that work yet. So, if you change the layout, it'll be set > for the rest of the installation process, but not in the final > installed system which boots to the console. There does not seem to be > a straightforward way to map X keymap/variant options to console > keymap layouts. While this is not an enormous problem, I'd like to > come up with a good way to configure both layouts at the same time, > especially because I use a non-standard layout myself. > > 3. This is less of a concrete issue, but I feel is a problem with > operating system installers in general. I'm a fairly new FreeBSD user, > and I've experienced this situation several times: I would want to > configure some setting on my machine and I'd recall that this setting > was an option in bsdinstall, so it must be possible, but I don't know > how bsdinstall does it. It feels like the installer does a lot of > convenient things that then have to be 're-discovered' once you start > using the operating system post-install. > > To help with this, I'd like the installer to have a 'teaching' > component to it, where each option has some text describing how the > installer actually does the configuration. I think something like that > would help new users understand that the installer isn't magic, it's > just running simple commands for most configuration options. Something > like that would certainly have helped me. > > 4. Things like setting the date and time could also benefit from a > more automatic process. Selecting a timezone is one of the more > convoluted parts of the current installer, as it first asks you the > cryptic "Is your hardware clock set to UTC?" question, and then makes > you go down some deeply nested menus. There are several web-based > timezone selection interfaces where you simply pick your location on a > world map, though the ones I've tried have not been very good. The > installer could also geolocate your timezone using your IP address. > > --- > > As you can see, the installer is nowhere near ready for serious use, > and is currently more of a testing ground for a bunch of interesting > ideas. I said this earlier, but I'd appreciate any testing of the > installer as it is, as I have not tested it myself very > comprehensively. I'd also like to hear any of your thoughts on the > direction of this work, or any ideas on installer > design/implementation in general. > > Finally, the installer doesn't yet have a name, so let me know if you > can think of a fitting name for it. > > Many years ago I started to write an installer based on the "Expert System" methodology. Then I abandoned it . Presently I am using Fedora exclusively . In Fedora installs , only necessary information is supplied . Installation is very fairly simple . Despite this , forgetting marking the boot requirement is generation an unbootable system which is not very appealing . Before Fedora I was using Mandriva . In Mandriva , there were options : () Load install options from a diskette () Store install options into a diskette These options were making repeated installs very easy . My opinion is that , in a similar manner , an XML file may be designed to define FreeBSD installation options . During install , this XML options file may be supplied in a USB stick , etc. to carry out the install . Personally I do not like JSON files , and I never use such an option . Such an install requires to load a FULLY usable initial loader able to use computer peripherals without fancy mount nightmare statements , etc. , just as in Mandriva simplicity . This will allow repeatable install on the same and/or similar computers . It will be easy to modify the XML file by copying it as a new file and using it for a new install . Personally I would prefer such an approach , because it will be much simpler than re-enter the same install parameters for the same or similar installs every time . Around 1990 , I was developing a set of statistical analysis programs , from previous parameter card driven programs , to interactive parameter entering programs . Later on , I have deleted all of the interactive parameter entering parts by converting all of the parameter entering statements to NAMELIST ( in Fortran ) data entry statements . This approach was much and much easier than interactive parameter entries . It was possible to copy and modify for a different set of data . It was possible rerun the same data data after corrections on some parts of data , etc. Mehmet Erol Sanliturk --00000000000093408905c745141f-- From nobody Sun Jul 18 23:04:24 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 C601C12A8457 for ; Sun, 18 Jul 2021 23:04:33 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GSgXc4rc8z3hlB; Sun, 18 Jul 2021 23:04:32 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16IN4Vuu032597; Sun, 18 Jul 2021 16:04:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=+9DgaJrJzc1x7EAXX3eHD8qaruY5SGcuQzUbnvv2zog=; b=s2+RMe1HsEBbqx2XkraklKwMjvkFzZjaS5vzdl6GqFTCbOWS3NTGPF4dWg5W4sPv9A2a dpoaWpjrywIcyWsecXK7/NDZWKBo2nfQXtdJkHcYk1DhVJxVWVe8W9L52XVqg8hbJgmX VK47MtO3MgVVnOZR6+ZCwPXgsNUh1e/6X359xHnWY7n8ShsP9H7wGDu2sIH01MSn+4VB SMvVrJKpmsNLogdH4jXf+Knelllhgn9vtfWjFAt0tLKTpoDlaIGD7irhMh1UGIB3eqmQ hhQ2+q4XCprT8lXmucjB9NXw0SVmZSqLq5tA6QEixM50XDKFhHyEcoUlkqweAmN4qD5K kw== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) by mx0b-00273201.pphosted.com with ESMTP id 39vm010ngq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Jul 2021 16:04:31 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gf+1pRF2grkppEvqhxMG8INmtyAz0r+m+CWTmGx1VroWhMVQvv37ke1pPsWbqr5qFO7C8lowU4Z+I4/7LMdLYCyd4ShNq0V8RYJCaJmsfeeRd3wf5hDhjkyKS9OO9FK41mNFCWBQb6oVC1Q8fosc6AjZFIOdXncdDx10X0xcksGknv9z3HPL7N2RZJKaiQq2M0bs+awPBCcOQnpkdPZJLMwulffjYRnrIbH433gzIvZDiOrnswN7N+ZI3jpBxB9d1oP+S7fAPMiePM3sM53bB7WoKhXnFPDA9V5FuNXNEr/NdJW+S295UPchRhFGlmw37wCYplF3ViX2CjKzyh6Fmg== 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-SenderADCheck; bh=+9DgaJrJzc1x7EAXX3eHD8qaruY5SGcuQzUbnvv2zog=; b=lE0+lnzuVDWU3y8Lxg7fpyEcNBSOz6JY//Brxe7v4pCXo3rScnKZs35LrlqsXLPyu+dikpI1bD2g12CCAYIyTIikwYiRypDAH6+mkNhwNg6Cid9QSuN+LmMl9K3rFf6LKkcIyhqlicX+3m5gB3w4j2xhNm6A6BFjYlaw6gcUFIek0hNpgq4qadYJHrxBHbskQRd1hHIIbxT34jrcxTLVZkS5PrjspL8Tjxl5ZFLaQTWyvovLke2PBESA/+bRGijAnIofs9ntIlFVe0JeWPAAQFBvIKZwAB5YBPsBHGOHJ8ntLTb+Be/ZsgTGUfAMcMzmToAonZzDN4C6q2wU0+5TrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.12) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+9DgaJrJzc1x7EAXX3eHD8qaruY5SGcuQzUbnvv2zog=; b=GjQhc1OMCqfl+EN2Q//tr7eAN3QDcUNrR+JGAkN8MJ7Y4ax2DlsWMI3k5eEl+OUBhBmkRVecAwTalfOcMT+VAYfp7W8EYUqNX9Y8HeyFsFwdwNZ9w7/4c6gI8hWYhKiVTgdIx4l9bvAuQESrrkIn9bb2GVUm8LlS7q1FsYmBQxQ= Received: from DM5PR18CA0092.namprd18.prod.outlook.com (2603:10b6:3:3::30) by SN4PR0501MB3887.namprd05.prod.outlook.com (2603:10b6:803:4a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.8; Sun, 18 Jul 2021 23:04:26 +0000 Received: from DM6NAM12FT044.eop-nam12.prod.protection.outlook.com (2603:10b6:3:3:cafe::80) by DM5PR18CA0092.outlook.office365.com (2603:10b6:3:3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.22 via Frontend Transport; Sun, 18 Jul 2021 23:04:26 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from P-EXFEND-EQX-01.jnpr.net (66.129.239.12) by DM6NAM12FT044.mail.protection.outlook.com (10.13.178.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4352.9 via Frontend Transport; Sun, 18 Jul 2021 23:04:26 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Sun, 18 Jul 2021 16:04:25 -0700 Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.922.13; Sun, 18 Jul 2021 18:04:25 -0500 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1497.23 via Frontend Transport; Sun, 18 Jul 2021 16:04:24 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 16IN4O0O009751; Sun, 18 Jul 2021 16:04:24 -0700 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 0949F564ED; Sun, 18 Jul 2021 16:04:24 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 0707A564EC; Sun, 18 Jul 2021 16:04:24 -0700 (PDT) To: "Rodney W. Grimes" CC: Stefan Esser , Warner Losh , "freebsd-arch@freebsd.org" , Subject: Re: FreeBSD awk behavior change proposal In-Reply-To: <202107101222.16ACM5Sb045675@gndrsh.dnsmgr.net> References: <202107101222.16ACM5Sb045675@gndrsh.dnsmgr.net> Comments: In-reply-to: "Rodney W. Grimes" message dated "Sat, 10 Jul 2021 05:22:05 -0700." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.2 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: <55026.1626649464.1@kaos.jnpr.net> Date: Sun, 18 Jul 2021 16:04:24 -0700 Message-ID: <56161.1626649464@kaos.jnpr.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3d86e68a-5790-4f1d-76cd-08d94a4063ca X-MS-TrafficTypeDiagnostic: SN4PR0501MB3887: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3pEFGD+UBgncn+xEEm1cP2S4qwxpzUPEAnIPxYLoTotCez7hOyOk+KWHWQJcO473MzFVpCn9et2IlkVMvR0iiYw8lQzk8MjzeJy5+HSGVZxJ7RdEyH8mxtoh5LHNGLrgJgg4QJvhvYFb8IZUllmNM9duXIJOo0RdD61yjbem4AaTQ7F8BDnC563gg35bJ4uIiO9JOPSebO1lYtF4vzU/Ot+4SKELMwTnKCchpxFrw4FPnuAoFO0J7BTwTCCKrQ/ax6aEImS4sJ2gAbhmzePIAnd79yTpukqK8jjPDWP/pXAndYxipKktxIkLaSkNsjcK2B9fnO8hyD+qEfkUbrJBoSdOTswOGBqNRgi4ib3wAy1qmZFR2EK2M7ngF4Sd/1k9WU2+Lz9ZR9efT7xCNaPp9qlwNjRC1CU4G8kFjyUNMe64VrVe3bI1lq9FKZ2AqV6N4tjRj08NfVrusLbXJXMwHEgK5+7dMwPyzv223qtfy6++iWvJZ4Z6X3mID7L6C08uncF0UBfyJHbil1QXnIA+o66Es62Gdr3Tam0i8+RQpPjR5QzSxdgXRCw21kHQ0ENlncJT6CdC5gY4lf5oylyHnX5kuVutDguxYuYSa37t79DOC1DFnhCvtaJyb6fyQrUWzCa9yYgzNF6FdTChyLmA+70wkRa2DqgxuGymr6K2oOjlg43ATHWBA6z5vyavcriXaaiuRrVXcgv8K+wPb/P9E51qBKbVBx3JhIlKPBslfOI= X-Forefront-Antispam-Report: CIP:66.129.239.12;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:P-EXFEND-EQX-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(4636009)(46966006)(36840700001)(47076005)(508600001)(9686003)(81166007)(4744005)(86362001)(6266002)(316002)(2906002)(186003)(54906003)(82310400003)(36860700001)(7126003)(356005)(107886003)(8936002)(5660300002)(8676002)(7696005)(6916009)(4326008)(336012)(26005)(55016002)(70206006)(70586007)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2021 23:04:26.1261 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3d86e68a-5790-4f1d-76cd-08d94a4063ca X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.12];Helo=[P-EXFEND-EQX-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT044.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0501MB3887 X-Proofpoint-GUID: saYEeMfjMM1LP8457SqeoqDOaQBqTlhJ X-Proofpoint-ORIG-GUID: saYEeMfjMM1LP8457SqeoqDOaQBqTlhJ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-07-18_11:2021-07-16,2021-07-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 mlxscore=0 phishscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 mlxlogscore=634 spamscore=0 impostorscore=0 clxscore=1011 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107180157 X-Rspamd-Queue-Id: 4GSgXc4rc8z3hlB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=s2+RMe1H; dkim=pass header.d=juniper.net header.s=selector1 header.b=GjQhc1OM; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=reject) header.from=juniper.net; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net X-Spamd-Result: default: False [-3.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; FREEFALL_USER(0.00)[sjg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_FIVE(0.00)[5]; RWL_MAILSPIKE_EXCELLENT(0.00)[67.231.152.164:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; RCVD_COUNT_SEVEN(0.00)[11]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from] Reply-To: sjg@juniper.net From: Simon J. Gerraty via freebsd-arch X-Original-From: Simon J. Gerraty X-ThisMailContainsUnwantedMimeParts: N Rodney W. Grimes wrote: > My concers are/were along the lines that awk was explicitly > setting or actually ignoring the users LC, what happens if > some user WANTS to build a port using some other locale, could > that lead to bad awk results, and a failed build. In practical terms a port which behaves differently based on LOCALE would be considered broken no? My experience is when tools start honoring LOCALE etc, the only path to retain consistent behavior is to override. eg. want to know if a pid is valid in a shell script? case "`LANG=C LC_ALL=C kill -0 $pid`" in *:*such*p*) return 1;; # not valid *) return 0;; # valid esac avoids portability headaches. --sjg From nobody Mon Jul 19 08:36:29 2021 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 E38FE12735F5 for ; Mon, 19 Jul 2021 08:36:32 +0000 (UTC) (envelope-from avg@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 4GSwDc5rkyz3HF5 for ; Mon, 19 Jul 2021 08:36:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 77E622DE9E for ; Mon, 19 Jul 2021 08:36:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) To: arch@FreeBSD.org From: Andriy Gapon Subject: led(9) blinking using dedicated thread Message-ID: Date: Mon, 19 Jul 2021 11:36:29 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.12.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=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N I would like to change led(9) so that it invokes LED control methods from a thread rather rather than from a callout. This is to support LEDs behind USB and I2C where (common) implementations use sleeping waits. I have created a review request for the proposed change: https://reviews.freebsd.org/D31215 In the current version the thread is created at init time and is kept around forever. That could be changed to create the thread when a first blinking LED is configured. Also, the thread could be destroyed when a last "blinker" is removed. Alternatively, I am considering whether static (no blinking) LED state changes should also be done asynchronously via the thread. -- Andriy Gapon From nobody Thu Jul 29 14:58:18 2021 X-Original-To: freebsd-arch@FreeBSD.org Received: from mlmmj.nyi.freebsd.org (unknown [127.0.1.24]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BB96512D0BFB for ; Thu, 29 Jul 2021 14:58:18 +0000 (UTC) (envelope-from freebsd-arch+bounces-help@FreeBSD.org) Subject: =?utf-8?q?Information_for_freebsd-arch=40FreeBSD.org?= From: freebsd-arch+owner@FreeBSD.org To: freebsd-arch@FreeBSD.org Message-ID: <1627570698-9722-mlmmj-3fac8bad@FreeBSD.org> Date: Thu, 29 Jul 2021 14:58:18 +0000 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: 8bit X-ThisMailContainsUnwantedMimeParts: N Hi, this is the Mlmmj program managing the mailing list. Here is some information about the list. You can subscribe to the following versions: - The normal version: Every time a post is sent to the list, subscribers receive a copy of it. Subscribe by emailing . - The digest version: Subscribers receive multiple posts in a single mail message, at regular intervals, or when a lot of posts have accumulated. Subscribe by emailing . - The no-mail version: Subscribers do not receive any posts to the list. This means, though, they are able to post to a list which only subscribers may post to, while they follow the list using a web archive or another subscribed email address. Subscribe by emailing . Unsubscribe by emailing . Posts are made by emailing . However, only subscribers may post to the list. The list also has access rules which may affect who can post and which posts are moderated. Subscribers can retrieve message number N from the list's archive by sending a message to (change the N to the number of the desired message). You can retrieve the frequently asked questions document for the list by sending a message to . To contact the list owner, send a message to . From nobody Mon Aug 2 14:30:25 2021 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 92DEC134209E for ; Mon, 2 Aug 2021 14:30:29 +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 4GdgQY3lHvz4WKQ; Mon, 2 Aug 2021 14:30:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (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 2646E2D8E0; Mon, 2 Aug 2021 14:30:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: led(9) blinking using dedicated thread To: Andriy Gapon , arch@FreeBSD.org References: From: John Baldwin Message-ID: <10897070-834c-c1eb-b152-94295f197946@FreeBSD.org> Date: Mon, 2 Aug 2021 07:30:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.10.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 7/19/21 1:36 AM, Andriy Gapon wrote: > > I would like to change led(9) so that it invokes LED control methods from a > thread rather rather than from a callout. This is to support LEDs behind USB > and I2C where (common) implementations use sleeping waits. > > I have created a review request for the proposed change: > https://reviews.freebsd.org/D31215 > > In the current version the thread is created at init time and is kept around > forever. That could be changed to create the thread when a first blinking LED > is configured. Also, the thread could be destroyed when a last "blinker" is > removed. I would vote for creating the thread on first need. I would like to cleanup some of our existing kthreads (soaiod* which is my fault and for which the fix is simple, and KTLS for which the fix is slightly less simple) so that we only create kthreads that are needed. kthreads don't necessarily eat up a lot of resources (wired memory for kstacks and the various data structures), but I think only creating the ones we need is ideal, especially for things enabled by default in GENERIC. -- John Baldwin From nobody Wed Aug 18 09:43:14 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 6AB4B175FC4D for ; Wed, 18 Aug 2021 09:43:23 +0000 (UTC) (envelope-from akamit91@hotmail.com) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11olkn2053.outbound.protection.outlook.com [40.92.19.53]) (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 4GqNHt3scvz3lT8 for ; Wed, 18 Aug 2021 09:43:22 +0000 (UTC) (envelope-from akamit91@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K8KJzypeAqTOXBNzDg2leM/GD+yAPrG8CxMYSDiMhyKdYMn54yK3GRxAEpy6lgpCc5kPSs4nNfFQIUg4/fjDfdjs6slQALrYcZrLYmSI0ztZzUNkiKKlKUWS5MYclCaTtdp0IkFsSiV8jxqW2EK0ZCKzFvXJAhEHTy86yAYLCqBb4SPEWQh/0pLTKDoPNLThtDXt5MIuNxeLe8Q9cd/eJmeKiOg+vhN7WFGXlsfXMaBE0Y/vxX9xXaGKLA2hftifLL5zwGydcykyHV3i1AGM4vxR07OQs1/W3usAAejA7oZsTb5DymmupXyrmjQPIO0x/qc+gpHgLCfMgKv22q2C7Q== 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-SenderADCheck; bh=jCUbV0pkpql5kpxzqUwUQMdM7Fb1udO30D3euoLslSw=; b=cjAzjt6yaQ/6+hzoCVxM4W+Il4rY8X7qO57RVxrcW9YHwU8htb8B10OkOQYykQrNi6JejOI0RINoxAS5hpQyGX1o1zUlmLpT4RFF6mzOnIUsjUPQoHFtWYTApW/gPVVAqlhWgdiOOolaRsYQTWX3un9L6zNhqJAK8kpxnnmt+5ikzvSB+LCTI6erN4pKUHJoO7LjBQ6KkMrT3/hxIcQI8GZy900n9vlx90uFAfkjYDzpaYkseSOxFOGu1fmrJO5gm9YnxS464oHCPuBFv01SEN3jcfn6FYtT3TLCOSAFjEhSfjV+sHh/37Qd7QyKps29nFatalTg4TErYedeTk3Bcg== 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=jCUbV0pkpql5kpxzqUwUQMdM7Fb1udO30D3euoLslSw=; b=KNegKkj+VaaMgAPayTEIq4AvgN/SaTU/2njlbNZ4fUe0qL/1j72djs+gZKcNWDm9GvBWjlCP5a4owaQv9VHQTLvUdcmzupNo2pkcLBA7OigTmZtSK+ea5TsCHp6XbyKjWEaJz42ksshqTbHpMbhKDbjdSby8MSzsTGgxUi3dV2Lk+8qUYX7SlB4hetFdWosGvhPxCdpmFwJjMzzBenuiY9u6uZOWVY713fN12Wg+I8Cpxrc6XTZ1+GpBluyKxog1ArvgdijsgKOZIS7CJBT7TTbPyV3AJf+D05zMIiizntHBFxdvBussfMDjv2U/gNh3iqujewifBUMdIb/nQNIUZQ== Received: from DM4PR11MB5519.namprd11.prod.outlook.com (2603:10b6:5:39e::7) by DM6PR11MB3563.namprd11.prod.outlook.com (2603:10b6:5:13e::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Wed, 18 Aug 2021 09:43:14 +0000 Received: from DM4PR11MB5519.namprd11.prod.outlook.com ([fe80::e4e5:5648:e6c1:eece]) by DM4PR11MB5519.namprd11.prod.outlook.com ([fe80::e4e5:5648:e6c1:eece%7]) with mapi id 15.20.4436.019; Wed, 18 Aug 2021 09:43:14 +0000 From: Amit kumar To: "freebsd-arch@freebsd.org" Subject: How to compute the amount of time a thread has been running on cpu Thread-Topic: How to compute the amount of time a thread has been running on cpu Thread-Index: AQHXlBHEMTMvm5J4jEidnBzQVDv1eg== Date: Wed, 18 Aug 2021 09:43:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [LzP/2dHi3qe9mYhXAEiuRvjbbhdkeL3P] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3af7e608-4b42-4017-746f-08d9622c99d6 x-ms-traffictypediagnostic: DM6PR11MB3563: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BqTCPI1NcucFwBithw14UjoupsYXAaOR42SR9AlE21FSmjsXbf8+81TCHYI3Gv/Hck68K0l+I4hq424eOxSFTM/ITSAH7jF2FFVAGGGn6HHiqcky/sMgw/Xz0/ljZrTecgAMZH/5EQSuCv7PsK/a9e7LivNT3bmbVYWaztJl64vwpAdaIXrUYgdviAoW2NpeCAFasob8zCi2DUxWeKXpfUP3eEURuwRlB1y1QRtaT5r+XRLP9YCRj1Xb2mTDC5erlyMiPyyrscNa9lJC9F3pEjZ1A3iV7jmUtFoUfI70hnyNTaXAs4t4x1wrNeIZ1n5AGxn3KGfM7/ohK8k5+zMSnjf70eolNyxWhNk1ruIvppRauJOxMTbqIogAH7xlQ3s7dMDoT0r2P4LB+V+wLhPkUIqho+45j9AsObjdaVW035HrgO8GjPA6Ty/a0lwWJX6t x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: bhVgvZqTBE6g9FV6ft2Z/Rarb1lwj+QUryMvWSV6wYnml8w81HLUj8RzgLZxWTfLc5V//N7bkno5kbHSqKyF8K/ZZV/Sy2iMo1ZJWhpwap8ns2hlrFG+e9gfoDs0tmCoEhap/g54AUDztLdVZnZPWA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM4PR11MB55194EC3EA40B394DA8EF4E3DCFF9DM4PR11MB5519namp_" 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-3174-20-msonline-outlook-169dc.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5519.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 3af7e608-4b42-4017-746f-08d9622c99d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2021 09:43:14.7353 (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: DM6PR11MB3563 X-Rspamd-Queue-Id: 4GqNHt3scvz3lT8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hotmail.com header.s=selector1 header.b=KNegKkj+; 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.53 as permitted sender) smtp.mailfrom=akamit91@hotmail.com X-Spamd-Result: default: False [-5.00 / 15.00]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.19.53:from]; FROM_HAS_DN(0.00)[]; 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]; RCPT_COUNT_ONE(0.00)[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.53:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-ThisMailContainsUnwantedMimeParts: Y --_000_DM4PR11MB55194EC3EA40B394DA8EF4E3DCFF9DM4PR11MB5519namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to figure out how long a thread(sitting on a particular CPU's r= eal-time RUNQ) has been running on the CPU, (might help if I can collect th= e runtime stats of the tread across the CPUs in the case it did run on othe= r CPUs too). I came across td_runtime and ts_runtime. ts_slptime =3D 18008, ts_runtime =3D 414196, td_slptick =3D 0, td_blktick =3D 0, td_incruntime =3D 36984047370, td_runtime =3D 55246215882, td_lastcpu =3D 0, td_oncpu =3D -1, looking at the code it seems ts_runtime is a decayed sum, but I dint find t= he same for td_runtime. Can someone help me find out how long this thread has been running and whic= h paramere is more reliable? Another question I see db_show_thread, converts ticks to ms, using the calculation listed be= low, is this correct or just an approximation? delta =3D (u_int)ticks - (u_int)td->td_swinvoltick; db_printf(" last involuntary switch: %d ms ago\n", 1000 * delta / hz); -AK --_000_DM4PR11MB55194EC3EA40B394DA8EF4E3DCFF9DM4PR11MB5519namp_-- From nobody Fri Sep 10 14:24:22 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 B307A17B771D for ; Fri, 10 Sep 2021 14:24:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x941.google.com (mail-ua1-x941.google.com [IPv6:2607:f8b0:4864:20::941]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H5dRj6Txbz4Wsn for ; Fri, 10 Sep 2021 14:24:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x941.google.com with SMTP id l24so1315480uai.1 for ; Fri, 10 Sep 2021 07:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+CiLYzi2dny4AZn/QmztI9p8SUMFEx0Q5IoLsFXj0OQ=; b=qdKeh/Jkwk1xDsEmmLOgjuyxz8rcXAYnhANnlNMsCRF76h1xabyIsJE5FtQ7haxdAM YT8aLfGbk6aoNpz21Qz/LPya4KNcHhP91ovVhNBJKMKIAk4vb4tpgnZzVhY8eHcK7jDY jZ58XwbEaax/5/DF/dlDLnNIyXQuNzUhghiT8TJT9DnZrA6Nu4WvcYMIPaovkPamNciM ut8EVHISinbu1T0jtfhit3WHf3+8ZbGS1yfl1kCqawzFLjEHxmv1s3gt4RwN1/Qtwdfz U4W6STXQy74JReE2Adk8RssSdOFM8qqC/NOE7JpK+oYDwyfT/jXWJsPeikgwpcpzfVQT BLow== 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=+CiLYzi2dny4AZn/QmztI9p8SUMFEx0Q5IoLsFXj0OQ=; b=R259jSQSlkjVahue3uZdEbLY7H0oPpGnac8SVBQFtlLghwueMPp9LjsN8urOXnABEQ vgL875hcUm6i/QO/Sm1/aotyniW1M8CWjWkk4ytcx4FCEcBdc1vZBB0ajfVoz/OUC03v s6mU1OuccCyjENYiEKO38M04sHH1ULIlvIWzvjueR6m0xgt/rwVSSWwXv2QwrG2y5ID2 zHhOnkNCQ8O9D9GyH6tddp4+eKrlb5RbxXzMnZd6tMvQm+NH57YU4PKSK++itKDwIQt5 zgQmX19wc08PRfHVoBFrW7gJA+ex9HiUeickgZt5Qm3YdVUqlceTJUJUID7LweXXouJl WREw== X-Gm-Message-State: AOAM5326NiDTMj4n8pNaI5WXE2u24WPqmzeUR2j9vH6FSNzbiBhKX3Bw uEQDu1L4yPn0qaTYIlq35CLPCPgUMNWZto7Cdz2IXd7ySZ+QSdcRBp4= X-Google-Smtp-Source: ABdhPJxeYOpuWJ/Tix9JH7lJDC1NSYkvyT2hEN8rN/uvC6etPjZdzqfg2xWJsgARcyPHugBPt0MyaCI24/tFV5VxvF8= X-Received: by 2002:a9f:23d0:: with SMTP id 74mr5800750uao.69.1631283873062; Fri, 10 Sep 2021 07:24: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: Warner Losh Date: Fri, 10 Sep 2021 08:24:22 -0600 Message-ID: Subject: Draft License Policy Changes for SPDX To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000c831df05cba4dfdf" X-Rspamd-Queue-Id: 4H5dRj6Txbz4Wsn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b="qdKeh/Jk"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::941) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; 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]; NEURAL_SPAM_SHORT(0.93)[0.926]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::941: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 --000000000000c831df05cba4dfdf Content-Type: text/plain; charset="UTF-8" Greetings, I've been circulating a draft project policy expanding SPDX license marking in the base system. Most projects in the open source world have moved to having a copyright and SPDX-License-Identifier in the source files (aka SPDX-only files) with the license understood from context, policy and industry practice. The goal of my draft is to allow SPDX-only files, while coping with our long legacy. I'm also trying to consolidate multiple policy-like statements in our documentation into one place. Originally, we had a license in every file and there was a fair amount of variation between them. A few years ago we started marking some files with SPDX-License-Identifier lines to assist automated tools discovering licenses. In addition, the ports license infrastructure uses these identifiers for third party software that we install there. Even without a formal policy, several SPDX-only files exist in base imported from other projects. The draft policy formalizes our current practices. It updates the project's policy to explicitly allow SPDX-only files. It documents industry and FreeBSD project practice. Hundreds of other open source projects have been using it for years. The FreeBSD project has had SPDX-only files for many years. A formal policy for how to interpret SPDX-only markings will provide clarity and improve certainty about their meaning. I've consulted with many people that have experience integrating software into FreeBSD with some knowledge of licenses. I've also talked to the SPDX lawyers for their justification for SDPX-only as well as what we do for our mixed situation. I've chatted informally with an IP lawyer not connected with SPDX for their views. I've surveyed other projects for what they do. All of this has informed the draft. The summary of the changes are actually rather simple: 1. If a file has both a SPDX-License-Identifier and the full text of a license, the full text takes precedence. 2. If a file has only SDPX-only, then the license text is from the SPDX database with details on how to fill in the blanks if needed. 3. Do not move any full-text or mixed files in the tree to SPDX-only unless you are the copyright holder or acting on their behalf. I've created a review for the policy. https://reviews.freebsd.org/D29543 has the changes for the new policy. As we'll want to check copies of the text of the licenses into the tree for compliance with SPDX and adjacent standards, I'll prepare a diff for that too once things are a bit more along. I'm calling for feedback before I give this to the lawyers to approve. I'd thought I had a lawyer lined up to review this over the summer, but that seems to have fallen through. I'm lining up someone new in parallel. There's an outstanding issue around slight wording differences between our license and the SPDX database that I need to resolve with the lawyer, as well as having them review the policy so that it's unambiguous how one discovers the license for an SPDX-only file. Information about the SPDX project can be found at https://spdx.org. The specification can be found at https://spdx.github.io/spdx-spec/. Thanks! Warner P.S. SDPX is now an ISO standard! It was approved yesterday: https://www.linuxfoundation.org/press-release/spdx-becomes-internationally-recognized-standard-for-software-bill-of-materials has more information. --000000000000c831df05cba4dfdf-- From nobody Sat Sep 11 15:31:26 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 792CB17A0DC3 for ; Sat, 11 Sep 2021 15:31:37 +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 4H6Gtc3k1hz3vFJ for ; Sat, 11 Sep 2021 15:31:36 +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 18BFVQcH005772; Sat, 11 Sep 2021 08:31:26 -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 18BFVQ80005771; Sat, 11 Sep 2021 08:31:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202109111531.18BFVQ80005771@gndrsh.dnsmgr.net> Subject: Re: Draft License Policy Changes for SPDX In-Reply-To: To: Warner Losh Date: Sat, 11 Sep 2021 08:31:26 -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: 4H6Gtc3k1hz3vFJ 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 [-0.24 / 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_SPAM_SHORT(0.86)[0.856]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > Greetings, > > I've been circulating a draft project policy expanding SPDX license marking > in the base system. Most projects in the open source world have moved to > having a copyright and SPDX-License-Identifier in the source files (aka > SPDX-only files) with the license understood from context, policy and > industry practice. The goal of my draft is to allow SPDX-only files, while > coping with our long legacy. I'm also trying to consolidate multiple > policy-like statements in our documentation into one place. > > Originally, we had a license in every file and there was a fair amount of > variation between them. A few years ago we started marking some files with > SPDX-License-Identifier lines to assist automated tools discovering > licenses. In addition, the ports license infrastructure uses these > identifiers for third party software that we install there. Even without a > formal policy, several SPDX-only files exist in base imported from other > projects. > > The draft policy formalizes our current practices. It updates the project's > policy to explicitly allow SPDX-only files. It documents industry and > FreeBSD project practice. Hundreds of other open source projects have been > using it for years. The FreeBSD project has had SPDX-only files for many > years. A formal policy for how to interpret SPDX-only markings will provide > clarity and improve certainty about their meaning. > > I've consulted with many people that have experience integrating software > into FreeBSD with some knowledge of licenses. I've also talked to the SPDX > lawyers for their justification for SDPX-only as well as what we do for our > mixed situation. I've chatted informally with an IP lawyer not connected > with SPDX for their views. I've surveyed other projects for what they do. > All of this has informed the draft. > > The summary of the changes are actually rather simple: > 1. If a file has both a SPDX-License-Identifier and the full text of a > license, the full text takes precedence. > 2. If a file has only SDPX-only, then the license text is from the SPDX > database with details on how to fill in the blanks if needed. > 3. Do not move any full-text or mixed files in the tree to SPDX-only > unless you are the copyright holder or acting on their behalf. ^^^ There remains a slippery slope here, there can be an un-named but valid copyright holder in any file in our system. Do to the fact that Berne does not require someone to declair a copyright on work to infact hold a valid copyright. I believe that the FreeBSD src code has a vary large quantity of such code in the base system. I doubt very much there are very many files that could hold muster to the claim of singular copyright holder as in "the copyright holder" above. > > I've created a review for the policy. https://reviews.freebsd.org/D29543 > has the changes for the new policy. As we'll want to check copies of the > text of the licenses into the tree for compliance with SPDX and adjacent > standards, I'll prepare a diff for that too once things are a bit more > along. > > I'm calling for feedback before I give this to the lawyers to approve. I'd > thought I had a lawyer lined up to review this over the summer, but that > seems to have fallen through. I'm lining up someone new in parallel. > There's an outstanding issue around slight wording differences between our > license and the SPDX database that I need to resolve with the lawyer, as > well as having them review the policy so that it's unambiguous how one > discovers the license for an SPDX-only file. I ask that you pose 1 question to any consulted lawyer, "What is the 'safest' thing that the project/foundation could do here". One should never pose the question in the form "is this legal", as almost anything is legal until it isnt in the IP arena. Ie, you can get away with a lot, that does not make whst your doing legal. Also you might mention the term "seperable" in the context that the copyright and spdx tags and the license text itself all become seperate items only attached by reference. > > Information about the SPDX project can be found at https://spdx.org. The > specification can be found at https://spdx.github.io/spdx-spec/. > > Thanks! > > Warner > > P.S. SDPX is now an ISO standard! It was approved yesterday: > https://www.linuxfoundation.org/press-release/spdx-becomes-internationally-recognized-standard-for-software-bill-of-materials > has more information. This is about using the tags to provide Meta data, something I am all fore, it is NOT about using a SPDX tag to replace a license in a file. I would also suggest one pair particularly close attention to this wording and think about why GNU has this things on its "How to use the GPL page": https://www.gnu.org/licenses/gpl-howto.en.html In the brief summary section bullet 5: Put a license notice in each file. Then later when they expand what that means: The license notices Each file's copying permission statement (also called the license notice) should come right after its copyright notices. For a one-file program, the statement (for the GPL) should look like this, to use GPL version 3 or later: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . That text is significantly MORE than a SPDX tag, or a simple "SEE COPYING". Regards, -- Rod Grimes rgrimes@freebsd.org From nobody Sat Sep 11 15:57:34 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 C76C017AE172 for ; Sat, 11 Sep 2021 15:57:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6HSv55GBz4Wtx for ; Sat, 11 Sep 2021 15:57:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa33.google.com with SMTP id s125so401152vkd.4 for ; Sat, 11 Sep 2021 08:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YuJt3Bk3GeMhk23ycj613VYBza6ukqX1R1AKO9b7Vzs=; b=X0mrh5kl+U89RGXNl37v7aA/EWZXQ73AJAKAaSr0AhbE1fLiZBlZV+GHg35tG6YF3q Msr6UOJTqB1exkYniPWf91Rhon72/ON5yVL+gwHNkjDVJ0xMs1fqAUNwG0glX6/uWoUN LBdo+p/xs9pYkPob5k0pS1LdzLDwfA0LTZ5zW6wGqknIaITFT82KVGEnvfaWpwerhLlJ 8YK9QUW3dzTfQL9GMYJGK7HfZ9Q1cK5kEVFc8Xv1ZMEadcmoRw+hixR6RBt9ozD/Swfb AxRPvoas5egU4KA30MfD+hulDdMsPGj1XHt4N+AQQK1tdRUSAOoTtVFuum9k+zPSajWa G3HA== 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=YuJt3Bk3GeMhk23ycj613VYBza6ukqX1R1AKO9b7Vzs=; b=n6+3X6+pOgn3ZXDtpqIf9qivedH+tbv9KTrOiq/tI8ykViTdKHw43JBVYFjPKSPvba /o/GPKO087+yFF/kpFMjJ6CkjGCPJbuN0YFsjAF4RD/0Deb/Ou5lIeaYtxQi/U9iBhwM vTmNpMKJn/WWgOKx+q8qyntyHKe0dYTVxo9LZ512+i6qDRZTLPk44jHDoEBr+puYVIfR 7D0snVcSDFm8ixfEpW5Ekn/ZzOMYzZnUGEHaK3w50Fc/DSOL2rXz5+kLgKDFmc40L0l5 SoPuiLZ7Gu1ngvqn1K7NDQN/kJHoVAqgBIRPqPcQc/9724TOWW9NYgQiAq7TljwEm+h2 t8WQ== X-Gm-Message-State: AOAM530bkRnSCSN+TXvJvdDNQpzuc7SvEt+3lJsvLudwqMJoLyY+itRs IP5pfdGENN4qTewXwJivvrgMk9aP5tvCqT5UB3P/cobqOYEawQICGNk= X-Google-Smtp-Source: ABdhPJzSRNaMWg7G2rORsngsfOeTqZmsjff7yxsNullc1fppdHAMRZDduBGDGOgMAz8kkDCqROx4oc3ELymg0kACgng= X-Received: by 2002:a05:6122:d95:: with SMTP id bc21mr1154768vkb.23.1631375865224; Sat, 11 Sep 2021 08:57: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: <202109111531.18BFVQ80005771@gndrsh.dnsmgr.net> In-Reply-To: <202109111531.18BFVQ80005771@gndrsh.dnsmgr.net> From: Warner Losh Date: Sat, 11 Sep 2021 09:57:34 -0600 Message-ID: Subject: Re: Draft License Policy Changes for SPDX To: "Rodney W. Grimes" Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000f1346005cbba4a77" X-Rspamd-Queue-Id: 4H6HSv55GBz4Wtx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000f1346005cbba4a77 Content-Type: text/plain; charset="UTF-8" On Sat, Sep 11, 2021 at 9:31 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > Greetings, > > > > I've been circulating a draft project policy expanding SPDX license > marking > > in the base system. Most projects in the open source world have moved to > > having a copyright and SPDX-License-Identifier in the source files (aka > > SPDX-only files) with the license understood from context, policy and > > industry practice. The goal of my draft is to allow SPDX-only files, > while > > coping with our long legacy. I'm also trying to consolidate multiple > > policy-like statements in our documentation into one place. > > > > Originally, we had a license in every file and there was a fair amount of > > variation between them. A few years ago we started marking some files > with > > SPDX-License-Identifier lines to assist automated tools discovering > > licenses. In addition, the ports license infrastructure uses these > > identifiers for third party software that we install there. Even without > a > > formal policy, several SPDX-only files exist in base imported from other > > projects. > > > > The draft policy formalizes our current practices. It updates the > project's > > policy to explicitly allow SPDX-only files. It documents industry and > > FreeBSD project practice. Hundreds of other open source projects have > been > > using it for years. The FreeBSD project has had SPDX-only files for many > > years. A formal policy for how to interpret SPDX-only markings will > provide > > clarity and improve certainty about their meaning. > > > > I've consulted with many people that have experience integrating software > > into FreeBSD with some knowledge of licenses. I've also talked to the > SPDX > > lawyers for their justification for SDPX-only as well as what we do for > our > > mixed situation. I've chatted informally with an IP lawyer not connected > > with SPDX for their views. I've surveyed other projects for what they do. > > All of this has informed the draft. > > > > The summary of the changes are actually rather simple: > > 1. If a file has both a SPDX-License-Identifier and the full text of a > > license, the full text takes precedence. > > 2. If a file has only SDPX-only, then the license text is from the SPDX > > database with details on how to fill in the blanks if needed. > > 3. Do not move any full-text or mixed files in the tree to SPDX-only > > unless you are the copyright holder or acting on their behalf. > ^^^ > > There remains a slippery slope here, there can be an un-named but > valid copyright holder in any file in our system. Do to the fact > that Berne does not require someone to declair a copyright on work > to infact hold a valid copyright. I believe that the FreeBSD src > code has a vary large quantity of such code in the base system. > > I doubt very much there are very many files that could hold muster > to the claim of singular copyright holder as in "the copyright holder" > above. > > > > > I've created a review for the policy. https://reviews.freebsd.org/D29543 > > has the changes for the new policy. As we'll want to check copies of the > > text of the licenses into the tree for compliance with SPDX and adjacent > > standards, I'll prepare a diff for that too once things are a bit more > > along. > > > > I'm calling for feedback before I give this to the lawyers to approve. > I'd > > thought I had a lawyer lined up to review this over the summer, but that > > seems to have fallen through. I'm lining up someone new in parallel. > > There's an outstanding issue around slight wording differences between > our > > license and the SPDX database that I need to resolve with the lawyer, as > > well as having them review the policy so that it's unambiguous how one > > discovers the license for an SPDX-only file. > > I ask that you pose 1 question to any consulted lawyer, "What is the > 'safest' thing that the project/foundation could do here". One should > never pose the question in the form "is this legal", as almost anything > is legal until it isnt in the IP arena. Ie, you can get away with a > lot, that does not make whst your doing legal. Also you might mention > the term "seperable" in the context that the copyright and spdx tags > and the license text itself all become seperate items only attached > by reference. > The important question to ask here is that were there to be a dispute, would it be clear to a trial judge or arbiter what license was controlling? And would that answer be the same world wide? Is it clear what the license is? That's been the thrust of the informal discussions I've had. > Information about the SPDX project can be found at https://spdx.org. The > > specification can be found at https://spdx.github.io/spdx-spec/. > > > > Thanks! > > > > Warner > > > > P.S. SDPX is now an ISO standard! It was approved yesterday: > > > https://www.linuxfoundation.org/press-release/spdx-becomes-internationally-recognized-standard-for-software-bill-of-materials > > has more information. > > This is about using the tags to provide Meta data, something I am all > fore, it is NOT about using a SPDX tag to replace a license in a file. > The earlier two links talk about it. This is indeed the metadata part of the standard that SPDX publishes. > I would also suggest one pair particularly close attention to this > wording and think about why GNU has this things on its "How to use > the GPL page": > https://www.gnu.org/licenses/gpl-howto.en.html The Linux kernel has thousands of files marked only with SPDX-License-Identifiers. It does this by having the following (and more text) in their 'proccess/license-rules.rst' file. This proposal is similar: ... BEGIN QUOTE Linux kernel licensing rules ============================ The Linux Kernel is provided under the terms of the GNU General Public License version 2 only (GPL-2.0), as provided in LICENSES/preferred/GPL-2.0, with an explicit syscall exception described in LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file. This documentation file provides a description of how each source file should be annotated to make its license clear and unambiguous. It doesn't replace the Kernel's license. ... END QUOTE The vast majority of files no longer have the boilerplate you quoted. And in fact, even that suggested boilerplate varies significantly from file to file and project to project if you look at the whole body of open source. It's one of the reasons the rest of the industry is standardizing on simple tags: to prevent this proliferation. > > In the brief summary section bullet 5: > Put a license notice in each file. > > Then later when they expand what that means: > The license notices > > Each file's copying permission statement (also called the license > notice) should come right after its copyright notices. For a one-file > program, the statement (for the GPL) should look like this, to use GPL > version 3 or later: > > This program is free software: you can redistribute it and/or > modify > it under the terms of the GNU General Public License as > published by > the Free Software Foundation, either version 3 of the License, > or > (at your option) any later version. > > This program is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > GNU General Public License for more details. > > You should have received a copy of the GNU General Public > License > along with this program. If not, see < > https://www.gnu.org/licenses/>. > > > > That text is significantly MORE than a SPDX tag, or a simple "SEE COPYING". > Correct. This isn't about that, but rather following an industry standard. Warner > Regards, > -- > Rod Grimes > rgrimes@freebsd.org > --000000000000f1346005cbba4a77-- From nobody Sat Sep 11 16:39:59 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 8894817C7873 for ; Sat, 11 Sep 2021 16:40:42 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6JQL36gCz4k1K for ; Sat, 11 Sep 2021 16:40:42 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-vs1-xe33.google.com with SMTP id s25so4447829vsa.9 for ; Sat, 11 Sep 2021 09:40:42 -0700 (PDT) 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=4cRZHXWFQTZ9fcYwPg09CengFWfnZOdYu1q5kzPx7+U=; b=qmY5UrPjKbCHjQfPJPw2iOMIWJKsxVwpijog5/+fpVZFK6gYhHQzSNgtVqjjYsdjLQ N16Ui8xw8yoKaqg2hbVI+f4+BzwQb/F4Nz0pEpJ/uechRx2Y81NA4RZhUbBRuqPbJG/C bdZbfxDDwWjYJXTHv/iAzt6zn7uNlNUoCc1U4SZIiXmBSEnribD+i1CYeR3AqGADwa52 0nYjd3ezWmnh+doPxTF1OJ/UlfmHQkU2xnD1gd7bs5nC49UqaCI7dnypxqmfTNBHNzuo DLwdRGRtuWnPKx7N/awQMLTcdWW4CVOGzyQ8YgSejUel+KntclKGELGQawDqh5jFJGBU POTg== 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=4cRZHXWFQTZ9fcYwPg09CengFWfnZOdYu1q5kzPx7+U=; b=f/rWyQVeJjwe5r1Wqi74rGwUY3bPEGSK/v17KwyRdlhASyiZg5Sl/iOGdwx+FNh/M1 Fbk5mC4G/jzDNy1WD5ylhNGBBdSPBvscfZAFLcpN1E2j+uKYtdCnOUhBvnxNIzuJJ908 vVqlT6IKvWGGtliA/hw/Gv/S22uQ7fbif/TmC5yZOlLLrMpQMFQMrM7MIWMloyXO02UW apb0txYyCrNFKazYZ0v5ZBrqMoX26+lXAoRdjodYwihHwKfi+r970QzKtjFZbYUzIdpb BGrOiyawX5yFRe47CyTFIKGAvzGZMoXQk5xGwE+HiAxWvC53BzrbHN4WW7nAHzDohjt0 eMDw== X-Gm-Message-State: AOAM5323Wa8NmGySbB77sibXvON4AFIS+Z80YvoSk9nCYrJybB/BCUln gSuVD0XpEwcb41ugag2grCO2Ld03vDgkyu54DtRnRtwN X-Google-Smtp-Source: ABdhPJxhyuo7BwZy5TV62tkXmjWWrXTwHAd6AF1mk3D+v/iTj2IwLjI50nyFH6LH3cQtlYR9xTHXkaKnAGPgaROpzyc= X-Received: by 2002:a67:ee9a:: with SMTP id n26mr1292949vsp.14.1631378436549; Sat, 11 Sep 2021 09:40:36 -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: <202109111531.18BFVQ80005771@gndrsh.dnsmgr.net> In-Reply-To: From: Mehmet Erol Sanliturk Date: Sat, 11 Sep 2021 19:39:59 +0300 Message-ID: Subject: Re: Draft License Policy Changes for SPDX To: Warner Losh Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000003474bc05cbbae46d" X-Rspamd-Queue-Id: 4H6JQL36gCz4k1K 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-ThisMailContainsUnwantedMimeParts: Y --0000000000003474bc05cbbae46d Content-Type: text/plain; charset="UTF-8" I am sorry that I am writing my message at the top . The reason is the longevity of the message . Many years ago I have suggested that in the messages , link of the message in the FreeBSD archives placed into the message before releasing the massage into the mailing list . In that case , we can use link of the message before our message and write our message . This may shorten our messages considerable and allows readers not to waste their time to reach the end of the previous message to read the new message . In a large project like FreeBSD , trying to determine the copyright holder requires perhaps centuries without coming to a usable result . I am not a person who has contributed anything to FreeBSD sources . For that reason I do not any right to say anything about copyrights of other people . My belief is that contributors will not care very much about their personal copyrights as much as they are suitable for themselves if copyright of sources remain in the name of FreeBSD Project with their current license as the dominant license . They were and are sufficiently bold persons to specify their copyrights . Since they did not do it , again , my opinion is that wasting unnecessary time on such "Unsolvable" problems will not make any contribution to the FreeBSD Project but waste of its resources which can be used to improve the FreeBSD Project as much as possible . Mehmet Erol Sanliturk On Sat, Sep 11, 2021 at 6:58 PM Warner Losh wrote: > On Sat, Sep 11, 2021 at 9:31 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > Greetings, > > > > > > I've been circulating a draft project policy expanding SPDX license > > marking > > > in the base system. Most projects in the open source world have moved > to > > > having a copyright and SPDX-License-Identifier in the source files (aka > > > SPDX-only files) with the license understood from context, policy and > > > industry practice. The goal of my draft is to allow SPDX-only files, > > while > > > coping with our long legacy. I'm also trying to consolidate multiple > > > policy-like statements in our documentation into one place. > > > > > > Originally, we had a license in every file and there was a fair amount > of > > > variation between them. A few years ago we started marking some files > > with > > > SPDX-License-Identifier lines to assist automated tools discovering > > > licenses. In addition, the ports license infrastructure uses these > > > identifiers for third party software that we install there. Even > without > > a > > > formal policy, several SPDX-only files exist in base imported from > other > > > projects. > > > > > > The draft policy formalizes our current practices. It updates the > > project's > > > policy to explicitly allow SPDX-only files. It documents industry and > > > FreeBSD project practice. Hundreds of other open source projects have > > been > > > using it for years. The FreeBSD project has had SPDX-only files for > many > > > years. A formal policy for how to interpret SPDX-only markings will > > provide > > > clarity and improve certainty about their meaning. > > > > > > I've consulted with many people that have experience integrating > software > > > into FreeBSD with some knowledge of licenses. I've also talked to the > > SPDX > > > lawyers for their justification for SDPX-only as well as what we do for > > our > > > mixed situation. I've chatted informally with an IP lawyer not > connected > > > with SPDX for their views. I've surveyed other projects for what they > do. > > > All of this has informed the draft. > > > > > > The summary of the changes are actually rather simple: > > > 1. If a file has both a SPDX-License-Identifier and the full text of a > > > license, the full text takes precedence. > > > 2. If a file has only SDPX-only, then the license text is from the > SPDX > > > database with details on how to fill in the blanks if needed. > > > 3. Do not move any full-text or mixed files in the tree to SPDX-only > > > unless you are the copyright holder or acting on their behalf. > > ^^^ > > > > There remains a slippery slope here, there can be an un-named but > > valid copyright holder in any file in our system. Do to the fact > > that Berne does not require someone to declair a copyright on work > > to infact hold a valid copyright. I believe that the FreeBSD src > > code has a vary large quantity of such code in the base system. > > > > I doubt very much there are very many files that could hold muster > > to the claim of singular copyright holder as in "the copyright holder" > > above. > > > > > > > > I've created a review for the policy. > https://reviews.freebsd.org/D29543 > > > has the changes for the new policy. As we'll want to check copies of > the > > > text of the licenses into the tree for compliance with SPDX and > adjacent > > > standards, I'll prepare a diff for that too once things are a bit more > > > along. > > > > > > I'm calling for feedback before I give this to the lawyers to approve. > > I'd > > > thought I had a lawyer lined up to review this over the summer, but > that > > > seems to have fallen through. I'm lining up someone new in parallel. > > > There's an outstanding issue around slight wording differences between > > our > > > license and the SPDX database that I need to resolve with the lawyer, > as > > > well as having them review the policy so that it's unambiguous how one > > > discovers the license for an SPDX-only file. > > > > I ask that you pose 1 question to any consulted lawyer, "What is the > > 'safest' thing that the project/foundation could do here". One should > > never pose the question in the form "is this legal", as almost anything > > is legal until it isnt in the IP arena. Ie, you can get away with a > > lot, that does not make whst your doing legal. Also you might mention > > the term "seperable" in the context that the copyright and spdx tags > > and the license text itself all become seperate items only attached > > by reference. > > > > The important question to ask here is that were there to be a dispute, > would it be clear to a trial judge or arbiter what license was > controlling? And would that answer be the same world wide? Is it clear > what the license is? That's been the thrust of the informal discussions > I've had. > > > Information about the SPDX project can be found at https://spdx.org. The > > > specification can be found at https://spdx.github.io/spdx-spec/. > > > > > > Thanks! > > > > > > Warner > > > > > > P.S. SDPX is now an ISO standard! It was approved yesterday: > > > > > > https://www.linuxfoundation.org/press-release/spdx-becomes-internationally-recognized-standard-for-software-bill-of-materials > > > has more information. > > > > This is about using the tags to provide Meta data, something I am all > > fore, it is NOT about using a SPDX tag to replace a license in a file. > > > > The earlier two links talk about it. This is indeed the metadata part of > the standard that SPDX publishes. > > > > I would also suggest one pair particularly close attention to this > > wording and think about why GNU has this things on its "How to use > > the GPL page": > > https://www.gnu.org/licenses/gpl-howto.en.html > > > The Linux kernel has thousands of files marked only with > SPDX-License-Identifiers. > It does this by having the following (and more text) in their > 'proccess/license-rules.rst' > file. This proposal is similar: > > ... BEGIN QUOTE > > Linux kernel licensing rules > ============================ > > The Linux Kernel is provided under the terms of the GNU General Public > License version 2 only (GPL-2.0), as provided in > LICENSES/preferred/GPL-2.0, > with an explicit syscall exception described in > LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file. > > This documentation file provides a description of how each source file > should be annotated to make its license clear and unambiguous. > It doesn't replace the Kernel's license. > > ... END QUOTE > > The vast majority of files no longer have the boilerplate you quoted. > And in fact, even that suggested boilerplate varies significantly from > file to file and project to project if you look at the whole body of open > source. It's one of the reasons the rest of the industry is standardizing > on simple tags: to prevent this proliferation. > > > > > > > In the brief summary section bullet 5: > > Put a license notice in each file. > > > > Then later when they expand what that means: > > The license notices > > > > Each file's copying permission statement (also called the license > > notice) should come right after its copyright notices. For a one-file > > program, the statement (for the GPL) should look like this, to use GPL > > version 3 or later: > > > > This program is free software: you can redistribute it and/or > > modify > > it under the terms of the GNU General Public License as > > published by > > the Free Software Foundation, either version 3 of the > License, > > or > > (at your option) any later version. > > > > This program is distributed in the hope that it will be > useful, > > but WITHOUT ANY WARRANTY; without even the implied warranty > of > > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > GNU General Public License for more details. > > > > You should have received a copy of the GNU General Public > > License > > along with this program. If not, see < > > https://www.gnu.org/licenses/>. > > > > > > > > That text is significantly MORE than a SPDX tag, or a simple "SEE > COPYING". > > > > Correct. This isn't about that, but rather following an industry standard. > > Warner > > > > Regards, > > -- > > Rod Grimes > > rgrimes@freebsd.org > > > --0000000000003474bc05cbbae46d-- From nobody Wed Sep 22 08:36:45 2021 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 B23A317D71CA; Wed, 22 Sep 2021 08:36:48 +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 4HDs8w4Pf2z4bn5; Wed, 22 Sep 2021 08:36:48 +0000 (UTC) (envelope-from bapt@FreeBSD.org) 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 5E55F4E7C; Wed, 22 Sep 2021 08:36:48 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 9A8F7B2C04; Wed, 22 Sep 2021 10:36:45 +0200 (CEST) Date: Wed, 22 Sep 2021 10:36:45 +0200 From: Baptiste Daroussin To: current@freebsd.org, arch@FreeBSD.org Subject: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20210922083645.4vnoajyvwq6wfhdf@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, TL;DR: this is not a proposal to deorbit csh from base!!! For years now, csh is the default root shell for FreeBSD, csh can be confusing as a default shell for many as all other unix like settled on a bourne shell compatible interactive shell: zsh, bash, or variant of ksh. Recently our sh(1) has receive update to make it more user friendly in interactive mode: * command completion (thanks pstef@) * improvement in the emacs mode, to make it behave by default like other shells * improvement in the vi mode (in particular the vi edit to respect $EDITOR) * support for history as described by POSIX. This makes it a usable shell by default, which is why I would like to propose to make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) If no strong arguments has been raised until October 15th, I will make this proposal happen. Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! Best regards, Baptiste From nobody Wed Sep 22 11:03:54 2021 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 3DE6617C409E; Wed, 22 Sep 2021 11:03:10 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HDwPp0xPYz4wns; Wed, 22 Sep 2021 11:03:10 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: by mail-lf1-f42.google.com with SMTP id e15so10159613lfr.10; Wed, 22 Sep 2021 04:03:10 -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; bh=C1+J0HQ2XQV0w4PjyK97IHnUJXA1+0nZp/tQLF80gjA=; b=sHCiF+fIhHLudtLcd2s05TqqWDtxY01FbrGHEyfdzWT49wV5uj8r74DTFv8un7/cYg 0TKjdPTMkPXcKwIm0XIxZ0CRh2vC12gk+uhZpCyh68rcIHdU49QkyxFr4vzwFXdMTC6n 3tEy5Z9RM0RoaOAX4ULJiTgZwbloCuwaJQfx6Kde7cmFepFfWOXw6yoKiCgkr2F9gWqi IZyVL8pJflcy7OR/hwdyNFS1cwAWaevWcSNurpHiduLFhCtjm1AjnVYViSmNYjwaMcI8 tLsi2eAzK1dO5ENz+MbGd+tiZXx+w4+rbfxy+LRiXwal8cyGPK1VoCnfs06vXY6rCWGq en7Q== X-Gm-Message-State: AOAM530INK8YtRBL1eRvYMvCgEx0Kdz5JjdXfwyYFcvW4OfcAeZhqOtz xkJ5jSE0MOCS2DH8ziJ7/w7y5Evo8FNHzXVQZ0IlAws2Lj4= X-Google-Smtp-Source: ABdhPJwuHsPz9jOanAebeMKoTi15z/ztVR5MFbBkzqGVUroMN2PbZYUnpao07Uu8klez4KcheBYFjuSVUnYxRh9ucgY= X-Received: by 2002:a05:651c:1408:: with SMTP id u8mr9320903lje.253.1632308582575; Wed, 22 Sep 2021 04:03:02 -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: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> In-Reply-To: From: Mariusz Zaborski Date: Wed, 22 Sep 2021 13:03:54 +0200 Message-ID: Subject: Re: [HEADSUP] making /bin/sh the default shell for root To: Chris Stephan Cc: Baptiste Daroussin , "current@freebsd.org" , "arch@FreeBSD.org" Content-Type: multipart/alternative; boundary="0000000000003a720005cc9375cf" X-Rspamd-Queue-Id: 4HDwPp0xPYz4wns 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-ThisMailContainsUnwantedMimeParts: Y --0000000000003a720005cc9375cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 from me. On Wed, 22 Sept 2021 at 12:31, Chris Stephan wrote= : > I completely agree. It will save me the =E2=80=98/bin/sh=E2=80=99 at the = beginning of each > =E2=80=98su -=E2=80=98 session. Also, it will simplify building extra sma= ll FreeBSD images, > allowing an easier removal of =E2=80=98csh=E2=80=99. > > I use csh from time to time, but I do wish it would take a much more > explicit action so my brain has switched over to =E2=80=98csh mode=E2=80= =99. I won=E2=80=99t lie > that I=E2=80=99ve pasted script into my terminal and spent time troublesh= ooting why > the commands didn=E2=80=99t work only to realize I forgot to change to /b= in/sh > first. > > Chris Stephan > > Sent from FreeBSD > ________________________________ > From: owner-freebsd-current@freebsd.org > on behalf of Baptiste Daroussin > Sent: Wednesday, September 22, 2021 3:36:45 AM > To: current@freebsd.org ; arch@FreeBSD.org > > Subject: [HEADSUP] making /bin/sh the default shell for root > > Hello, > > TL;DR: this is not a proposal to deorbit csh from base!!! > > For years now, csh is the default root shell for FreeBSD, csh can be > confusing > as a default shell for many as all other unix like settled on a bourne > shell > compatible interactive shell: zsh, bash, or variant of ksh. > > Recently our sh(1) has receive update to make it more user friendly in > interactive mode: > * command completion (thanks pstef@) > * improvement in the emacs mode, to make it behave by default like other > shells > * improvement in the vi mode (in particular the vi edit to respect $EDITO= R) > * support for history as described by POSIX. > > This makes it a usable shell by default, which is why I would like to > propose to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not > MFCed) > > If no strong arguments has been raised until October 15th, I will make th= is > proposal happen. > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > Best regards, > Baptiste > > --0000000000003a720005cc9375cf-- From nobody Wed Sep 22 12:59:23 2021 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 8B1E417D1D5D; Wed, 22 Sep 2021 12:59:23 +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 4HDyzv3Zq9z58cT; Wed, 22 Sep 2021 12:59:23 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1632315563; 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=kdJF+c4kWHe78CyiXZwcvlBi03+FrPqs0JGTCsflGhs=; b=N9VyPEBhVV4yt+hSjlHtP6qLdLzeATLnukJh/SYy2afGv1ZQI0bjo9EtehJRNMkX93x3Br YocHOyizTOPWl9b3gUBxbQIXOsTDi0YC9o2xfhfdTp5XactHRV5o84pcsG91RKF+F9zfIq v0O+NFxYQKHwo/q5pZvhDmAZwksZAS0aE7ePsjcc6QkBnOfBho4VpWP0C3fn+LrWcCPQYm X0IOhPZOHh6orWTn0e6oSM6FNe3bIfFscPQukAsVI4oAXppDhW1v9AgjV7BPxjXRjdouJD 1nFW/oNvXewjl4tUktXF2f7ST6hw1drvbxM81QdOcLNhBZVuI010AmH1jXE40Q== Received: by freefall.freebsd.org (Postfix, from userid 1403) id 67309116A1; Wed, 22 Sep 2021 12:59:23 +0000 (UTC) Date: Wed, 22 Sep 2021 12:59:23 +0000 From: "Piotr P. Stefaniak" To: Baptiste Daroussin Cc: current@freebsd.org, arch@freebsd.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: References: <20210922083645.4vnoajyvwq6wfhdf@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; format=flowed Content-Disposition: inline In-Reply-To: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1632315563; 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=kdJF+c4kWHe78CyiXZwcvlBi03+FrPqs0JGTCsflGhs=; b=eyuBy+mSUEHNUx0sHRQpbc0+inPWPaBn4H2bbzDNqfRCL+ID73jLWQUQs5pnVG+QMelyEI WXJkgGwPzP4scIqDKQMmAiuBYLKob4JpsgiyxB0m454Ljms5XEYO1N6YLmUFMEa1BWHDKE wQbtWC/quUQhyVFn//O+pcsXZV11sqFmWSMXKhp/81tbqG5KI+Z8/vuWVdnBOeJZPmLlVo MfGy2Lppn1pSX0b15Ka27OHUKNRIdvv25y2U9vkpcegTWRdYdLy49ndEoIP9kMjmgMp7at Rfneno/WGSwTIU1HzI79JTB1W2Zw4RsKPvNzxSFUW6uRVlCvoqL0gDTd7DWeZQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1632315563; a=rsa-sha256; cv=none; b=ScxBRaE8tW6bo7ljGB3W5hMzDrbla6FauEvkE3mG2RlTjXOzEZdcAnV9w4HqZ8wZ6LfXo6 8BfXVf35ffmBgTddGZ+Jcu0tu2Yt60vgT63gRDePl9Rx+szmaTIciFlEZ8RaGs2Zb0drEo BykYAymJACa3hhSuQEmlgWHjsOf6TA9IIxAdJPt9YkKVmRR9qjLEDGcuLYrHTiLoy2Mpyb WdknW6LE//sRcMhfkZWdsjwGHhDHpywxgYRREQxehjU18kYUPPKAqD3ebjQrghvNI4XaJW YL3VfIkFW/WqgPJOa4qycncqHFrIMPrpUyyYzrmEZyQ78MvrqASVb6B3SRwU3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2021-09-22 10:36:45, Baptiste Daroussin wrote: >Recently our sh(1) has receive update to make it more user friendly in >interactive mode: >* command completion (thanks pstef@) >* improvement in the emacs mode, to make it behave by default like other shells >* improvement in the vi mode (in particular the vi edit to respect $EDITOR) >* support for history as described by POSIX. There are also prompt-related commits done by trasz: r342577 Make sh(1) collapse $HOME into "~" in PS1 r342576 Simplify the way we set the default sh(1) PS1 r342645 Add current working directory to the default sh prompt r342812 Give sh(1) a proper default prompt instead of just "$". r342881 Make sh(1) recognize the default $HOME r343231 Don't mess with BLOCKSIZE in shell startup files r343399 Make sh(1) support \u in PS1 r343416 Install .shrc for root, and set PS1 for the toor account. and this commit by me: r363621 sh(1): print a newline when ^D quits sh What I would like to see by default are these ctrl-arrow bindings in emacs mode and an alias for "history": bind "\\e[1;5C" em-next-word bind "\\e[1;5D" ed-prev-word alias history='fc -l' Piotr From nobody Wed Sep 22 13:28:15 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 5803C17D6FCA; Wed, 22 Sep 2021 13:28:17 +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 4HDzdF23WLz3Hg0; Wed, 22 Sep 2021 13:28:17 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1632317297; 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=VFYhEwdcWBoNk8TuKobMOlmag7b6GSt2qUrL9E6XPV8=; b=NjCyeaJSLKNCPXcXwteju5kKlw1ZIE2NAH4emmy3XGp/MmiGUFXKr/kgCtHd1LavX5Q8pR Pza1XBPzuNvn3OhMNpNZME5ITc6GGNNmC4sjGd5iB43OPklvAawH3A1/3NtghWL41slN+P svFvqedCRKMMxtL8CBD0LwphekMhamR/rBvukURpBzwG2y+Royx2pfsWMcNXwo/xA0TjNG weOUtpfj9+9B/UCjs0HwqqSz7hpnGOJzWApOvlz/gUqYxcZEEv42RXhlBcWY3O84HK4UJt bEpdf+sOE6M1O5S0qQiPS/0RuotytXtnvIIhqWjF5fXRIhd73wyRd72uKgGnxA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 3C023119B5; Wed, 22 Sep 2021 13:28:17 +0000 (UTC) Date: Wed, 22 Sep 2021 15:28:15 +0200 From: Daniel Ebdrup Jensen To: freebsd-arch@freebsd.org, "arch@FreeBSD.org" Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20210922132815.ngag32vrwqr73gjn@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-arch@freebsd.org, "arch@FreeBSD.org" References: <20210922083645.4vnoajyvwq6wfhdf@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="xgscufkufjsautop" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1632317297; 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=VFYhEwdcWBoNk8TuKobMOlmag7b6GSt2qUrL9E6XPV8=; b=yxJhoH2ktjDlQNN6IRydtkTR5GhznIk1sbQ6xsYsRwW4tphoVW1UkAHiu8NzAiX4cpIlnC RC8zB7/eRMbeeY41fnRnL3r0Dz87xzvRQ/e8RKLRFJIEy4eBvrCyAM+id1Dl8YRc8+34jv 75OBGqlUqlMwv2ZyXv4FZGqdcRGIPiVQ56BNaxOWk5LFX5w/beCYiBejd+fFmctiMdjd8R Qhtdv4Btx79ouCQ2lRvt2HDBvrTPN7mStT7tejw0HmLay3PE66c1RVv/XOP0MTUVdJtOZt qK10mf7QxUv0sOJZ96HbGRSR4lGoAJfAYX+eH9X0sqRRJ8NGDQXubYCp2eNq8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1632317297; a=rsa-sha256; cv=none; b=tMYgK/hTGME7kPSLWg9qwZRqzMbMpcNuo+X/7i/arS61DZi5lTQZbBiyvEjM13IioEynPD Z3kJgmqy+6PNJFDm4FqfNIRdZDgaIHkiB8PMujHfhPH4ZNCQPSYYbyNKWGorptY/ZOUpBw jBDPQk4wDuhKcYWCJedsORLwFXMH6sGBKYdwLV1Pq9m2ya4rK322I0AyagAwhOP1kGIGiq tKQwHqgjly/dxQ7Xs2kAxBGkQjAnkN/ranAE6bAeGaB82GSbwJ53aG1MzHYu2dpQz6UBbs yLbzpw/VGOCQ+M+oK5h37MjTQ6QFLudAwVFpg/NFq0EQiwp+Z1Un5Yf3oWJiRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --xgscufkufjsautop Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2021 at 01:03:54PM +0200, Mariusz Zaborski wrote: >+1 from me. > >On Wed, 22 Sept 2021 at 12:31, Chris Stephan wrot= e: > >> I completely agree. It will save me the =E2=80=98/bin/sh=E2=80=99 at the= beginning of each >> =E2=80=98su -=E2=80=98 session. Also, it will simplify building extra sm= all FreeBSD images, >> allowing an easier removal of =E2=80=98csh=E2=80=99. >> >> I use csh from time to time, but I do wish it would take a much more >> explicit action so my brain has switched over to =E2=80=98csh mode=E2=80= =99. I won=E2=80=99t lie >> that I=E2=80=99ve pasted script into my terminal and spent time troubles= hooting why >> the commands didn=E2=80=99t work only to realize I forgot to change to /= bin/sh >> first. >> >> Chris Stephan >> >> Sent from FreeBSD >> ________________________________ >> From: owner-freebsd-current@freebsd.org >> on behalf of Baptiste Daroussin >> Sent: Wednesday, September 22, 2021 3:36:45 AM >> To: current@freebsd.org ; arch@FreeBSD.org >> >> Subject: [HEADSUP] making /bin/sh the default shell for root >> >> Hello, >> >> TL;DR: this is not a proposal to deorbit csh from base!!! >> >> For years now, csh is the default root shell for FreeBSD, csh can be >> confusing >> as a default shell for many as all other unix like settled on a bourne >> shell >> compatible interactive shell: zsh, bash, or variant of ksh. >> >> Recently our sh(1) has receive update to make it more user friendly in >> interactive mode: >> * command completion (thanks pstef@) >> * improvement in the emacs mode, to make it behave by default like other >> shells >> * improvement in the vi mode (in particular the vi edit to respect $EDIT= OR) >> * support for history as described by POSIX. >> >> This makes it a usable shell by default, which is why I would like to >> propose to >> make it the default shell for root starting FreeBSD 14.0-RELEASE (not >> MFCed) >> >> If no strong arguments has been raised until October 15th, I will make t= his >> proposal happen. >> >> Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! >> >> Best regards, >> Baptiste >> >> Hi folks, I generally speaking don't mind making the Almquist shell into the default shell for root in FreeBSD, especially after the many commits that have gone into the tree in the last while, which helps to make it into a shell that can be used interactively. :) As a tcsh user, however, I do feel like I have to point out that the way to tell csh apart from other shells is that its default unprivileged prompt is % rather than $ - though I see how that's not immediately obvious if you don't interact with it except when you're root. ;) (The reason I'm responding to this mesasge instead of the one that oshogbo@ responded to is that that one doesn't appear to have been received by my MUA, nor - as far as I can tell - has it been received by mlmmj, so I can't even grab the raw file and tell my MUA to use it as an mbox, for me to respond to.) Yours, Daniel Ebdrup Jensen --xgscufkufjsautop Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmFLL25fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87pu7gf/Vw9oK33rTBt87DIu56dcGW0UQ+sQTN99tJK2CkBw54lIgCjh9wgeio3u 19hvx6mQUok9cA0YHNSBcLQrvrCvapaH7brX6NChflIUgDR9d9MwW1VKfXiTr3Y8 TMRs3sEsQx9kBBF7FVMoqygfiL7SsjHFbqrzQ7NJCHDUxeayiPKNuSHEL0bx193D LfwQoJfbgiOMeC8ZiMz8cj/DZ/h8ydp/6sACAdM0INQZBNU39MmixETgnoO48g51 hN63lLUzexVwx0+daiOApIbukSA7wauKWTBvyDvj+ooA7f9/Ig+2Uof79cOyHnbW 4QvukR//PQEbg2cFWgNZRCMTwpKWlQ== =TvQx -----END PGP SIGNATURE----- --xgscufkufjsautop-- From nobody Wed Sep 22 13:28:15 2021 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 5803C17D6FCA; Wed, 22 Sep 2021 13:28:17 +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 4HDzdF23WLz3Hg0; Wed, 22 Sep 2021 13:28:17 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1632317297; 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=VFYhEwdcWBoNk8TuKobMOlmag7b6GSt2qUrL9E6XPV8=; b=NjCyeaJSLKNCPXcXwteju5kKlw1ZIE2NAH4emmy3XGp/MmiGUFXKr/kgCtHd1LavX5Q8pR Pza1XBPzuNvn3OhMNpNZME5ITc6GGNNmC4sjGd5iB43OPklvAawH3A1/3NtghWL41slN+P svFvqedCRKMMxtL8CBD0LwphekMhamR/rBvukURpBzwG2y+Royx2pfsWMcNXwo/xA0TjNG weOUtpfj9+9B/UCjs0HwqqSz7hpnGOJzWApOvlz/gUqYxcZEEv42RXhlBcWY3O84HK4UJt bEpdf+sOE6M1O5S0qQiPS/0RuotytXtnvIIhqWjF5fXRIhd73wyRd72uKgGnxA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 3C023119B5; Wed, 22 Sep 2021 13:28:17 +0000 (UTC) Date: Wed, 22 Sep 2021 15:28:15 +0200 From: Daniel Ebdrup Jensen To: freebsd-arch@freebsd.org, "arch@FreeBSD.org" Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20210922132815.ngag32vrwqr73gjn@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-arch@freebsd.org, "arch@FreeBSD.org" References: <20210922083645.4vnoajyvwq6wfhdf@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="xgscufkufjsautop" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1632317297; 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=VFYhEwdcWBoNk8TuKobMOlmag7b6GSt2qUrL9E6XPV8=; b=yxJhoH2ktjDlQNN6IRydtkTR5GhznIk1sbQ6xsYsRwW4tphoVW1UkAHiu8NzAiX4cpIlnC RC8zB7/eRMbeeY41fnRnL3r0Dz87xzvRQ/e8RKLRFJIEy4eBvrCyAM+id1Dl8YRc8+34jv 75OBGqlUqlMwv2ZyXv4FZGqdcRGIPiVQ56BNaxOWk5LFX5w/beCYiBejd+fFmctiMdjd8R Qhtdv4Btx79ouCQ2lRvt2HDBvrTPN7mStT7tejw0HmLay3PE66c1RVv/XOP0MTUVdJtOZt qK10mf7QxUv0sOJZ96HbGRSR4lGoAJfAYX+eH9X0sqRRJ8NGDQXubYCp2eNq8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1632317297; a=rsa-sha256; cv=none; b=tMYgK/hTGME7kPSLWg9qwZRqzMbMpcNuo+X/7i/arS61DZi5lTQZbBiyvEjM13IioEynPD Z3kJgmqy+6PNJFDm4FqfNIRdZDgaIHkiB8PMujHfhPH4ZNCQPSYYbyNKWGorptY/ZOUpBw jBDPQk4wDuhKcYWCJedsORLwFXMH6sGBKYdwLV1Pq9m2ya4rK322I0AyagAwhOP1kGIGiq tKQwHqgjly/dxQ7Xs2kAxBGkQjAnkN/ranAE6bAeGaB82GSbwJ53aG1MzHYu2dpQz6UBbs yLbzpw/VGOCQ+M+oK5h37MjTQ6QFLudAwVFpg/NFq0EQiwp+Z1Un5Yf3oWJiRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --xgscufkufjsautop Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2021 at 01:03:54PM +0200, Mariusz Zaborski wrote: >+1 from me. > >On Wed, 22 Sept 2021 at 12:31, Chris Stephan wrot= e: > >> I completely agree. It will save me the =E2=80=98/bin/sh=E2=80=99 at the= beginning of each >> =E2=80=98su -=E2=80=98 session. Also, it will simplify building extra sm= all FreeBSD images, >> allowing an easier removal of =E2=80=98csh=E2=80=99. >> >> I use csh from time to time, but I do wish it would take a much more >> explicit action so my brain has switched over to =E2=80=98csh mode=E2=80= =99. I won=E2=80=99t lie >> that I=E2=80=99ve pasted script into my terminal and spent time troubles= hooting why >> the commands didn=E2=80=99t work only to realize I forgot to change to /= bin/sh >> first. >> >> Chris Stephan >> >> Sent from FreeBSD >> ________________________________ >> From: owner-freebsd-current@freebsd.org >> on behalf of Baptiste Daroussin >> Sent: Wednesday, September 22, 2021 3:36:45 AM >> To: current@freebsd.org ; arch@FreeBSD.org >> >> Subject: [HEADSUP] making /bin/sh the default shell for root >> >> Hello, >> >> TL;DR: this is not a proposal to deorbit csh from base!!! >> >> For years now, csh is the default root shell for FreeBSD, csh can be >> confusing >> as a default shell for many as all other unix like settled on a bourne >> shell >> compatible interactive shell: zsh, bash, or variant of ksh. >> >> Recently our sh(1) has receive update to make it more user friendly in >> interactive mode: >> * command completion (thanks pstef@) >> * improvement in the emacs mode, to make it behave by default like other >> shells >> * improvement in the vi mode (in particular the vi edit to respect $EDIT= OR) >> * support for history as described by POSIX. >> >> This makes it a usable shell by default, which is why I would like to >> propose to >> make it the default shell for root starting FreeBSD 14.0-RELEASE (not >> MFCed) >> >> If no strong arguments has been raised until October 15th, I will make t= his >> proposal happen. >> >> Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! >> >> Best regards, >> Baptiste >> >> Hi folks, I generally speaking don't mind making the Almquist shell into the default shell for root in FreeBSD, especially after the many commits that have gone into the tree in the last while, which helps to make it into a shell that can be used interactively. :) As a tcsh user, however, I do feel like I have to point out that the way to tell csh apart from other shells is that its default unprivileged prompt is % rather than $ - though I see how that's not immediately obvious if you don't interact with it except when you're root. ;) (The reason I'm responding to this mesasge instead of the one that oshogbo@ responded to is that that one doesn't appear to have been received by my MUA, nor - as far as I can tell - has it been received by mlmmj, so I can't even grab the raw file and tell my MUA to use it as an mbox, for me to respond to.) Yours, Daniel Ebdrup Jensen --xgscufkufjsautop Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmFLL25fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87pu7gf/Vw9oK33rTBt87DIu56dcGW0UQ+sQTN99tJK2CkBw54lIgCjh9wgeio3u 19hvx6mQUok9cA0YHNSBcLQrvrCvapaH7brX6NChflIUgDR9d9MwW1VKfXiTr3Y8 TMRs3sEsQx9kBBF7FVMoqygfiL7SsjHFbqrzQ7NJCHDUxeayiPKNuSHEL0bx193D LfwQoJfbgiOMeC8ZiMz8cj/DZ/h8ydp/6sACAdM0INQZBNU39MmixETgnoO48g51 hN63lLUzexVwx0+daiOApIbukSA7wauKWTBvyDvj+ooA7f9/Ig+2Uof79cOyHnbW 4QvukR//PQEbg2cFWgNZRCMTwpKWlQ== =TvQx -----END PGP SIGNATURE----- --xgscufkufjsautop-- From nobody Wed Sep 22 15:34:58 2021 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 916A517C9336; Wed, 22 Sep 2021 15:35:00 +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 4HF2RS3hQkz3qpm; Wed, 22 Sep 2021 15:35:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (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 01FB08C97; Wed, 22 Sep 2021 15:34:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [HEADSUP] making /bin/sh the default shell for root To: Baptiste Daroussin , current@freebsd.org, arch@FreeBSD.org References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> From: John Baldwin Message-ID: <82d7f4d1-5ce9-c7ed-d993-b16b3ddac6e3@FreeBSD.org> Date: Wed, 22 Sep 2021 08:34:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 In-Reply-To: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > Hello, > > TL;DR: this is not a proposal to deorbit csh from base!!! > > For years now, csh is the default root shell for FreeBSD, csh can be confusing > as a default shell for many as all other unix like settled on a bourne shell > compatible interactive shell: zsh, bash, or variant of ksh. > > Recently our sh(1) has receive update to make it more user friendly in > interactive mode: > * command completion (thanks pstef@) > * improvement in the emacs mode, to make it behave by default like other shells > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > * support for history as described by POSIX. > > This makes it a usable shell by default, which is why I would like to propose to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > If no strong arguments has been raised until October 15th, I will make this > proposal happen. > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! I think this is fine. I would also be fine with either removing 'toor' from the default password file or just leaving it as-is for POLA. (I would probably prefer removing it outright.) -- John Baldwin From nobody Wed Sep 22 15:42:22 2021 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 1E66917CB534 for ; Wed, 22 Sep 2021 15:42:24 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HF2bz75Z5z3tFh for ; Wed, 22 Sep 2021 15:42:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x72c.google.com with SMTP id t4so10907867qkb.9 for ; Wed, 22 Sep 2021 08:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Nu88Hanoju2Ds5idQe+MepmMZNG/+7QjpoJts4HOqGc=; b=ZJPzJACx7iBfp1S0uh9PRJhbfhcAd3Tn3JQEbLFHkwErJzzyOU3Pdbin7OSv/Tyu0f EVgPjwlomhFdTEVdcIPSCj4ve0qzUuo8TlxawrDJeSiBG+QG6ZNtwIZWsg9VOgq0+DKK FomqSEXNRXNvXa/i0B3a2KBsUInr5QhCT1XQF7s32Qh95eZCn6lyn6Zj0kI5OdR36DQs WDTOoVJuEMHphKbGw7b3c7vLAKW9VOIih4EQPnmxJh5BWTIgZtRDvOyG6i95z1tZBbQV nIskZcSXaIUdP05kEiWrC6ftyR1u5luL9jKkbo5UAVHs/wyyjXSKPqgb44yuLbZRwmSV dBtA== 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:references :mime-version:content-disposition:in-reply-to; bh=Nu88Hanoju2Ds5idQe+MepmMZNG/+7QjpoJts4HOqGc=; b=HMCPkNf0fN4OZRV/7wffjJwh/4TPL1IEMxzcOo0pX0k93i7DzMzdFS+Zm9dIna+Ur3 AXAYsq5w8mqWsefPWURMqVmeqUFT6UnHachNTSNgsmOUA1XCv1GqH9sQAh5BtO1pcvlP EOEaBY76znQd7BTYQ7qQS7/10WMuw2o45ftkPi4OeNWXlK4SmNw8d6VMkdrUmnCZkDo6 myaPEYpCSxWoWR5xmZxO8nD41SHLLM7/TWAiU1eqLTZUBeuidp7Vb4oF/UG/Q1RUVW6I CwWVaz6xkrcTv7cqvlHh5yihWeMHu3sJlxgkAQsSxe44sAQvZCAJjyAdWD42lLTAwN5r TTlA== X-Gm-Message-State: AOAM530mBFPGT8+PIUo4c3sIYhq8SKjmeD1hYbsmhQJmxww1UB1aafzd ZJQlVd/o29FQlm79jIfnPIGFSQ== X-Google-Smtp-Source: ABdhPJwXKZEE1xnxE+CHm6avhj+PlUtEI2BDtOr9Bm/iXfxklgZ+OB659WtlNKNmDCnozVQtjyzO3A== X-Received: by 2002:a37:ab15:: with SMTP id u21mr501302qke.394.1632325343579; Wed, 22 Sep 2021 08:42:23 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id a9sm2048117qko.27.2021.09.22.08.42.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 08:42:23 -0700 (PDT) Date: Wed, 22 Sep 2021 11:42:22 -0400 From: Shawn Webb To: John Baldwin Cc: Baptiste Daroussin , current@freebsd.org, arch@FreeBSD.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20210922154222.6bvnqk4kjjxewy6n@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: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <82d7f4d1-5ce9-c7ed-d993-b16b3ddac6e3@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-sha256; protocol="application/pgp-signature"; boundary="ynlrt7so32gayaew" Content-Disposition: inline In-Reply-To: <82d7f4d1-5ce9-c7ed-d993-b16b3ddac6e3@FreeBSD.org> X-Rspamd-Queue-Id: 4HF2bz75Z5z3tFh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --ynlrt7so32gayaew Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > Hello, > >=20 > > TL;DR: this is not a proposal to deorbit csh from base!!! > >=20 > > For years now, csh is the default root shell for FreeBSD, csh can be co= nfusing > > as a default shell for many as all other unix like settled on a bourne = shell > > compatible interactive shell: zsh, bash, or variant of ksh. > >=20 > > Recently our sh(1) has receive update to make it more user friendly in > > interactive mode: > > * command completion (thanks pstef@) > > * improvement in the emacs mode, to make it behave by default like othe= r shells > > * improvement in the vi mode (in particular the vi edit to respect $EDI= TOR) > > * support for history as described by POSIX. > >=20 > > This makes it a usable shell by default, which is why I would like to p= ropose to > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not M= FCed) > >=20 > > If no strong arguments has been raised until October 15th, I will make = this > > proposal happen. > >=20 > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! >=20 > I think this is fine. I would also be fine with either removing 'toor' f= rom the > default password file or just leaving it as-is for POLA. (I would probab= ly > prefer removing it outright.) HardenedBSD recently removed toor. No one has complained (yet?). A small Twitter poll[0] showed that 85% of people who responded do not use toor. [0]: https://twitter.com/HardenedBSD/status/1415781911063056389 Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --ynlrt7so32gayaew Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmFLTtsACgkQ/y5nonf4 4frLMQ//TWQDSx8vgbQt375Ujn9eP+uldHH69sY+4Cb0XdkgoJSm5t4UubeHjhr4 dVFoSmWTDoUW+mxdbLoAOKgSgYLrFbPqzgaZXOc7Oz0IBixQSNu2oFnba+JiDT9D gIkvupczjQziFELf44+Mkhp8awEchNjiwU76Nr3fIk0ZzOeWmzDyDbyVGs46+Uw0 QtH4nFvH/zSu2pMdq/r2vvhMKugUExHoczSQNV3tpL0IUaa4yAno8FnXTyvmbGag OBXLpu8tMrlwBOxVtLT7na1G94ZIqay+ECAs7PJuJdxqrvZiBOrzIMnIKRUy5Lnh 4A2s6fD/IX4zYd0RLBUnBx7+oTKi6OBVwYbBfHMywhbaOAfHrgNH4mnpVBx5re1b 7PfE2qUK65NXZEbqQZVGXWTSOolLE0SOUZSgEw1Mqa4ldktzUJm7JK7/lQRZx/Jr jy202LgpUXuv6usqN5GjjUGKbewFNkbwkXhadkqsnXV9fPdKbKRXg01KqmHeiU6A bUAal3IHv+mwx/JL8+c/dSmD/iZhDIho8uKFokKaIsINU+ESjFyNvUf4C1qLlfe4 v5hFCGVhRnLbfVRHGjyoDbW5ay7La2GKhcEUB+CQHtIt2HYZ1vFwl4hOtGv6WWT4 zmws1euGBi1vn8U9HhdT2HcTP/KljmE6QNwj4v/bXsM2zOy2Q+Y= =GJ7+ -----END PGP SIGNATURE----- --ynlrt7so32gayaew-- From nobody Wed Sep 22 15:52:53 2021 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 0FFE517CD783; Wed, 22 Sep 2021 15:52:57 +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 4HF2r8464xz3w7D; Wed, 22 Sep 2021 15:52:56 +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 18MFqsil050410; Wed, 22 Sep 2021 08:52:54 -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 18MFqsTS050409; Wed, 22 Sep 2021 08:52:54 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202109221552.18MFqsTS050409@gndrsh.dnsmgr.net> Subject: Re: [HEADSUP] making /bin/sh the default shell for root In-Reply-To: <20210922154222.6bvnqk4kjjxewy6n@mutt-hbsd> To: Shawn Webb Date: Wed, 22 Sep 2021 08:52:53 -0700 (PDT) CC: John Baldwin , Baptiste Daroussin , current@FreeBSD.org, 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: 4HF2r8464xz3w7D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > > Hello, > > > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > > > For years now, csh is the default root shell for FreeBSD, csh can be confusing > > > as a default shell for many as all other unix like settled on a bourne shell > > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > > > Recently our sh(1) has receive update to make it more user friendly in > > > interactive mode: > > > * command completion (thanks pstef@) > > > * improvement in the emacs mode, to make it behave by default like other shells > > > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > > > * support for history as described by POSIX. > > > > > > This makes it a usable shell by default, which is why I would like to propose to > > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > > > > > If no strong arguments has been raised until October 15th, I will make this > > > proposal happen. > > > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > > > I think this is fine. I would also be fine with either removing 'toor' from the > > default password file or just leaving it as-is for POLA. (I would probably > > prefer removing it outright.) > > HardenedBSD recently removed toor. No one has complained (yet?). A > small Twitter poll[0] showed that 85% of people who responded do not > use toor. A truely disastisified customer does not complain, they simply go some place else for there products. Be carefull in what you believe silence to be saying. > > [0]: https://twitter.com/HardenedBSD/status/1415781911063056389 > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc -- Rod Grimes rgrimes@freebsd.org From nobody Wed Sep 22 17:46:28 2021 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 669C717DAD81 for ; Wed, 22 Sep 2021 17:46:40 +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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HF5MM6qh8z4fsW for ; Wed, 22 Sep 2021 17:46:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id h30so3861942vsq.3 for ; Wed, 22 Sep 2021 10:46:39 -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=hVFe9Vs9k93QiGM5r6yNBX+TA0sm5iT7dSOSqyAFBeQ=; b=piG5X2EfSzxFJzRBtwnOHS4P1AAZIQOCkwwbQ2AfBGyPuaxyVV5o3JKLjBQZvkLmPc lJr5pMaST97btBs3AzKWQ9pvQtd2scBXXHtoKdPlU6XPrEzDuLZboAnCBDLCEYGOxik2 BQYZUMhFuCi3O2qUZD0OVXNlim/Ott/gQ1cMcO3tAbN2o24zt4dAYjoHOYJy0P1YQKRf rpETxhLs+O4g0VaTEIgkIALPD+JzkWX6igmWV8nd9ITFdNQjLRoMfcS+faKIP67F03aT wDB+PKRPgDWsXFI4SSwfncIH5HpI5awCnvnrjH32EGuFJN+x90PYpqXPTZnXCIhG+iUO mIbg== 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=hVFe9Vs9k93QiGM5r6yNBX+TA0sm5iT7dSOSqyAFBeQ=; b=TYWRaE0nH5jsdjURBcEDnIc4KVzJEeOP8yf94IE3ruROgLDVWafKZu2zGy3s9tMhjT 31rdO0tg57DhDHSpy+w+JwWY0SBAM36RsDtVlGktewJFfna1fjw/3at+WWJtADixTQyn KEhQsAQxbsN9tgaShPDONhwoG6E3AWK8CdnfCGR5N2qhD9d5clZj/19AxlwZrqYFcwED Ot9GjUqhpM6E90a2CLD2Rcrj4PmPbLMZKWctw+op5j9lF/gDtybaR4CVgKefJd2sJxKj WkpRhp7PMGAMArnypbu3TVAGehAq6GPyj4zZssa83Wz2RAUiSeWtnF8xsmgAoLWU13xH qzLg== X-Gm-Message-State: AOAM533rIQs85HoP2gujP/WjRDda5UqRcTOjDde3XNPLi5XL2mtv42F0 tej0gg/LPzYNE14E5gHcUDiE+2z6xkVBtPdcNyh92Q== X-Google-Smtp-Source: ABdhPJyEeeWumhygUVEoqG6D1N2ysuJy5p4b0RTNSQ8AX6pjrcELXr9ZfY9qoN0WCv7JvGUkF7IRq4Hz++o+rqLu9h4= X-Received: by 2002:a67:d589:: with SMTP id m9mr476310vsj.30.1632332799237; Wed, 22 Sep 2021 10:46: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: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <82d7f4d1-5ce9-c7ed-d993-b16b3ddac6e3@FreeBSD.org> In-Reply-To: <82d7f4d1-5ce9-c7ed-d993-b16b3ddac6e3@FreeBSD.org> From: Warner Losh Date: Wed, 22 Sep 2021 11:46:28 -0600 Message-ID: Subject: Re: [HEADSUP] making /bin/sh the default shell for root To: John Baldwin Cc: Baptiste Daroussin , FreeBSD Current , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000a7719305cc99182c" X-Rspamd-Queue-Id: 4HF5MM6qh8z4fsW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000a7719305cc99182c Content-Type: text/plain; charset="UTF-8" On Wed, Sep 22, 2021 at 9:35 AM John Baldwin wrote: > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > Hello, > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > For years now, csh is the default root shell for FreeBSD, csh can be > confusing > > as a default shell for many as all other unix like settled on a bourne > shell > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > Recently our sh(1) has receive update to make it more user friendly in > > interactive mode: > > * command completion (thanks pstef@) > > * improvement in the emacs mode, to make it behave by default like other > shells > > * improvement in the vi mode (in particular the vi edit to respect > $EDITOR) > > * support for history as described by POSIX. > > > > This makes it a usable shell by default, which is why I would like to > propose to > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not > MFCed) > > > > If no strong arguments has been raised until October 15th, I will make > this > > proposal happen. > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > I think this is fine. I would also be fine with either removing 'toor' > from the > default password file or just leaving it as-is for POLA. (I would probably > prefer removing it outright.) > I think this is also fine. I also think we should remove toor from the default password file for one fewer attack surfaces. I strongly prefer this. Users that want toor can add it to their system and/or provisioning scripts. Warner --000000000000a7719305cc99182c-- From nobody Wed Sep 22 17:47:50 2021 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 5614717DB7CB; Wed, 22 Sep 2021 17:47:56 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HF5Nq3ZgZz4fw3; Wed, 22 Sep 2021 17:47:55 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-ed1-x52f.google.com with SMTP id h17so13075334edj.6; Wed, 22 Sep 2021 10:47:55 -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=8mBK2FQNSLLfvSC3ksODtFdE81pweAsdiue9j031yp0=; b=MFh4aXB9HWgmUi+ha7lrWuk66Ao5j7T1D8Av0O9eBR0TkApyzgBS2znVxI1ZnUBODs a7zZH5Pq8POlbyiBhhZCRzJbMnUZmddFdhx4xd7j5YbjC7SBbWTV9fG2X4CmY6usJUaz u0htdn9WIrPYfg+4G/VxshAxzddM8CokQq/pOszeRmlneznbo1lIJkVrQeV1y9bryjuO 4T7TvvXJ76Ee8DYJ9lC4HcWUeNcMxMbAPT8elFzjNczkixKEDE+AD66hASPt9zNDGeIC trc/ooKVn4dVGsdX8OjzWFVlqLJW4ibk/ZyZK768DM00duygi8tnKRKPDTbiVjc5i+Q2 0M4w== 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=8mBK2FQNSLLfvSC3ksODtFdE81pweAsdiue9j031yp0=; b=YwS7wDe1pKMYihC892TbMTlRpARpiT7VBMAkXsevR4sOmkbn7d2jkCaiFCMSd2WuIb tyb+K70MJVZfBEsjGsT4OvtW3+xfU9YQ/rqQ0XvORAG5q/f6kWlZevr9ImmH3ZLc0a5n Dr4sqiPOLuqbtJDpmKR0JkkniYjlY/oPyergLQkDsFT/4NM5i2pnUTny3FtRiaEuHUcI zmM8YV63TYaDgIi5ZCRVMQuN+4ECwr3dgebC8+pRXmKiiqZD0lUY/F6E8ouh0zhIVYBk 6kD9tFUyp874DBTHZiuT6opeyxvrh2olF7iZf44EgBUjuYXABRwq2HSdY58fzoMXSqXI KygQ== X-Gm-Message-State: AOAM5314pnjfzcGh/DT+VYdqM3EXrhyT2BzZiODrzyPgTsLe86RBI8u2 rHva2Ifcnaax9Q8gUqjNPMvQ7l0tYtE= X-Google-Smtp-Source: ABdhPJz+jIepKCCsTWOYYCnY6L+V52pbpJtz0lDHgCSr9QOEiNP872Vmm/wwWtg/9r3OvQF/TtqCPA== X-Received: by 2002:a17:906:6448:: with SMTP id l8mr433708ejn.301.1632332874515; Wed, 22 Sep 2021 10:47:54 -0700 (PDT) Received: from ernst.home (p5b023517.dip0.t-ipconnect.de. [91.2.53.23]) by smtp.gmail.com with ESMTPSA id q10sm1335628ejt.121.2021.09.22.10.47.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 10:47:53 -0700 (PDT) Date: Wed, 22 Sep 2021 19:47:50 +0200 From: Gary Jennejohn To: "Rodney W. Grimes" Cc: Shawn Webb , John Baldwin , Baptiste Daroussin , current@FreeBSD.org, arch@FreeBSD.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20210922194750.55af63d5@ernst.home> In-Reply-To: <202109221552.18MFqsTS050409@gndrsh.dnsmgr.net> References: <20210922154222.6bvnqk4kjjxewy6n@mutt-hbsd> <202109221552.18MFqsTS050409@gndrsh.dnsmgr.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.8 (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: 4HF5Nq3ZgZz4fw3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 22 Sep 2021 08:52:53 -0700 (PDT) "Rodney W. Grimes" wrote: > > On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > > > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > > > Hello, > > > > > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > > > > > For years now, csh is the default root shell for FreeBSD, csh can be confusing > > > > as a default shell for many as all other unix like settled on a bourne shell > > > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > > > > > Recently our sh(1) has receive update to make it more user friendly in > > > > interactive mode: > > > > * command completion (thanks pstef@) > > > > * improvement in the emacs mode, to make it behave by default like other shells > > > > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > > > > * support for history as described by POSIX. > > > > > > > > This makes it a usable shell by default, which is why I would like to propose to > > > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > > > > > > > If no strong arguments has been raised until October 15th, I will make this > > > > proposal happen. > > > > > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > > > > > I think this is fine. I would also be fine with either removing 'toor' from the > > > default password file or just leaving it as-is for POLA. (I would probably > > > prefer removing it outright.) > > > > HardenedBSD recently removed toor. No one has complained (yet?). A > > small Twitter poll[0] showed that 85% of people who responded do not > > use toor. > > A truely disastisified customer does not complain, they simply > go some place else for there products. Be carefull in what you > believe silence to be saying. > I use toor on every FreeBSD machine as the root login using bash. I never log in as root. But removing it wouldn't be a deal breaker for me. I'd just put it back into /etc/passwd. > > > > [0]: https://twitter.com/HardenedBSD/status/1415781911063056389 > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > -- > Rod Grimes rgrimes@freebsd.org > -- Gary Jennejohn From nobody Wed Sep 22 17:54:39 2021 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 3A71F17DD4A7; Wed, 22 Sep 2021 17:50:45 +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 4HF5S43lGPz4hsQ; Wed, 22 Sep 2021 17:50:44 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1CC1F32009DF; Wed, 22 Sep 2021 13:50:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 22 Sep 2021 13:50:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+Z6vyI Zk1P1+31ZVgw2vuv5Mtf6Y+i5fTkUe5x4P/XU=; b=YOJVv2rrALXgCVV12+YCCX eF7v6kZf1gIAxEeEl8Lqut+44ZSF0eO3ighhzTH5yllwsyi2HOI/mImgaV+loAlb xKNqe/FpEZgWVuHuhlvGmgUEyDmVV5eimT4JBBf3E0Ky96T57VCnaI1DZ+NshqUr R0hnpVTmRLZQTP5k45G53MEHIfP8KnrQQSKUL0zulXN+GhcSsiuXCOA59P3p9FQa Zilh3iHyXzAzOk/SkLrzCstXz844WNlEmMCheLCWvgmuZ0Nhyh5DkqeMaFOnF4Fx 0i3Nyo4i59x9+v88tr6frqomsEgpoPVrH/0R1GDk5OPLZ3Tch7oPjzikrGmhoMUg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudeijedguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvfhomhcu lfhonhgvshcuoehthhhjsehfrhgvvggsshgurdhorhhgqeenucggtffrrghtthgvrhhnpe etgfejgfekueetuddvgfdtgeeijeehudekgeffgfevtefflefgteeufeffkeeuheenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhjsehfrh gvvggsshgurdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 22 Sep 2021 13:50:35 -0400 (EDT) Date: Wed, 22 Sep 2021 18:54:39 +0100 From: Tom Jones To: John Baldwin Cc: Baptiste Daroussin , current@freebsd.org, arch@freebsd.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20210922175439.GD16760@tom-desk.erg.abdn.ac.uk> References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <82d7f4d1-5ce9-c7ed-d993-b16b3ddac6e3@FreeBSD.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82d7f4d1-5ce9-c7ed-d993-b16b3ddac6e3@FreeBSD.org> X-Rspamd-Queue-Id: 4HF5S43lGPz4hsQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > Hello, > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > For years now, csh is the default root shell for FreeBSD, csh can be confusing > > as a default shell for many as all other unix like settled on a bourne shell > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > Recently our sh(1) has receive update to make it more user friendly in > > interactive mode: > > * command completion (thanks pstef@) > > * improvement in the emacs mode, to make it behave by default like other shells > > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > > * support for history as described by POSIX. > > > > This makes it a usable shell by default, which is why I would like to propose to > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > > > If no strong arguments has been raised until October 15th, I will make this > > proposal happen. > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > I think this is fine. I would also be fine with either removing 'toor' from the > default password file or just leaving it as-is for POLA. (I would probably > prefer removing it outright.) I support both of these suggestions, when I first installed FreeBSD ~2006 toor already felt like a strange an anachronism. - Tom From nobody Thu Sep 23 02:56:25 2021 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 0CAE217D0716; Thu, 23 Sep 2021 02:56:27 +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 4HFKYk6whGz4bGL; Thu, 23 Sep 2021 02:56:26 +0000 (UTC) (envelope-from bapt@freebsd.org) 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 B5D40E56C; Thu, 23 Sep 2021 02:56:26 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 243FFB4449; Thu, 23 Sep 2021 04:56:25 +0200 (CEST) Date: Thu, 23 Sep 2021 04:56:25 +0200 From: Baptiste Daroussin To: Alban Hertroys Cc: current@freebsd.org, "arch@freebsd.org" Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20210923025625.wtufdwbmq47qsxbv@aniel.nours.eu> References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <9A7E9AB0-1A59-4E8C-86EC-EFD8A3147112@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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9A7E9AB0-1A59-4E8C-86EC-EFD8A3147112@gmail.com> X-ThisMailContainsUnwantedMimeParts: N On Wed, Sep 22, 2021 at 10:03:40PM +0200, Alban Hertroys wrote: > > > On 22 Sep 2021, at 10:36, Baptiste Daroussin wrote: > > > > Hello, > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > (…) > > > Recently our sh(1) has receive update to make it more user friendly in > > interactive mode: > > * command completion (thanks pstef@) > > * improvement in the emacs mode, to make it behave by default like other shells > > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > > * support for history as described by POSIX. > > > > This makes it a usable shell by default, which is why I would like to propose to > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > My one concern is this: what is the impact of these usability improvements to sh on its usage in scripts? None, those are in a code path with doesn't get executed when in non interactive mode. Best regards, Bapt From nobody Thu Sep 23 07:46:53 2021 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 409C717C77C9; Thu, 23 Sep 2021 07:47:03 +0000 (UTC) (envelope-from SRS0=x/NU=ON=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4HFS130gxqz3KpF; Thu, 23 Sep 2021 07:47:02 +0000 (UTC) (envelope-from SRS0=x/NU=ON=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E78A428416; Thu, 23 Sep 2021 09:46:54 +0200 (CEST) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id DE38528411; Thu, 23 Sep 2021 09:46:53 +0200 (CEST) Subject: Re: [HEADSUP] making /bin/sh the default shell for root To: grarpamp , current@freebsd.org Cc: arch@freebsd.org References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <3f7d159b-9f32-e88c-360e-35f8c4b12e23@quip.cz> Date: Thu, 23 Sep 2021 09:46:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HFS130gxqz3KpF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 22/09/2021 22:50, grarpamp wrote: >> propose to make it the default shell for root starting FreeBSD 14.0-RELEASE > > Make it so. > > The whole rest of rc, pkg, base scripts and subsystems use a lot of sh, not csh. > So this is a good compatibility, consistancy, and gotcha-removing update, > needed for decades. > > Even "bash" is a majority spoken shell in Linux/world, helping > make crossovers if BSD becomes a bit more bash-like. More bashism and linuxism in BSD world, you are waking the devil. > The bsd sh feature updates are filling useful/needed capability gaps. Moving to sh without maintain the same history search behavior (start of the command and Up & Down arrows) are like cutting one leg. The (t)csh is what I really like on every FreeBSD machine. Never seen good configured bash (prompt + history search) on any other OS I ever visited. Not saying it is not possible but if FreeBSD will switch default shell to something else I expect to do it the way that it is more user friendly and powerful than on other OSes where everything is leaved to "users can customize it". Current state of sh behavior is really that "bad" way. If you want to catch users on sh, do it better, please! > "csh considered harmful" > > toor needs to go as part of simple cruft removal for a cleaner base, > else you would have to add zoor, koor, boor, toor, etc. No no no no! > > Nobody leave FreeBSD just to get run csh on their windows command prompt ;) > > Users are always free to customize local installs as desired. It cuts both ways. If users are free to customize they can switch from current default csh to sh and no change in base is needed. Miroslav Lachman From nobody Thu Sep 23 07:55:37 2021 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 9A7FE17C9627; Thu, 23 Sep 2021 07:55:57 +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 4HFSCK2ZCGz3MST; Thu, 23 Sep 2021 07:55:57 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (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)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 70421260361; Thu, 23 Sep 2021 09:55:50 +0200 (CEST) Subject: Re: [HEADSUP] making /bin/sh the default shell for root To: Miroslav Lachman <000.fbsd@quip.cz>, grarpamp , current@freebsd.org Cc: arch@freebsd.org References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <3f7d159b-9f32-e88c-360e-35f8c4b12e23@quip.cz> From: Hans Petter Selasky Message-ID: <3bde04d9-4479-c89e-7005-775832bd2334@selasky.org> Date: Thu, 23 Sep 2021 09:55:37 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.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 In-Reply-To: <3f7d159b-9f32-e88c-360e-35f8c4b12e23@quip.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HFSCK2ZCGz3MST X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Hi, I've always used "tcsh" for root. The little help you get on the command line to search and repeat commands is very useful compared to plain "sh". Sorry for top-posting. --HPS From nobody Thu Sep 23 08:04:26 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 3AE2B17CACD1 for ; Thu, 23 Sep 2021 08:03:50 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HFSNP3y0lz3Pk5 for ; Thu, 23 Sep 2021 08:03:49 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id q11so14547383wrr.9 for ; Thu, 23 Sep 2021 01:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=JOpAG/HjSCA7VbSJ2qJZA+wFqwbXJXomoGCygHVMTEs=; b=LlztNy/7QRCcFuVjOGKX5A+1Wb5yL8jAnNyZ6tVGqzkvIildMKlV3lzDdLC5ekY0m/ e6CxffR+173cWYZfz1GfTZKBaiFRf6d3ESgxwzhGlyzcFS7vSz2YFFDhDMi0wrqRIG1Y F8wjDD3EMRxcv91zQMmfWjxEk/in2j4SIVPAfZ99eLjDVZj8d3pWxPKC6PWyo1RH9U5j 1DYrCAF50t7J2xK0RDKGvnYl7ILyWBsSyvaCP8DzGZEXxUgo5t/O1qmnhockM8mN9bF8 WQAYYpZqOPp8a3RuzsZYa/b6tF6iPI+o4P/OC7cjmFVLkO74b3UY3ofo0ZaRXSG1soZ1 nWFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JOpAG/HjSCA7VbSJ2qJZA+wFqwbXJXomoGCygHVMTEs=; b=yaQgpBorUYJp4dIFnZnb22vhgnjpo55cAx8JSkicVTCWPuWEzlBzOGlF8fK7kgrlp5 DGGrPmOsOUr7+pNmanTRNU9id8oHED2R+1oNQfEGMm3xV0CIBvM5dDMy1qUTSlF6Ix/c a3hy5vlwuLDsMho3s/G3clV08J9ACigcOt6FIa85z+yp122U1pKVOCvHigEcNM32bD0l LkapDt97J2VB/Wn+hbDKqQmmfe5rW1TvqO5us/OSMAgjqHyhgsUjnFFeT76BL51PrZhZ Mcd3zeTb3FEfoOmKICTt2RrZu4+0lRXwSIv43CRffPtEBC7/N86YTA2JohkKnuCBsXS1 iz/w== X-Gm-Message-State: AOAM531F5WcgOrmdQG7YUtDBi3s72dMEUs8T9/fdqWmHhhFCc62gxveb bkuXE9EcWS5+d4WwQznZZOFYx3eZuG4wsQ== X-Google-Smtp-Source: ABdhPJwpXdM/yRUkHSZFJ4bInd4ROo5aYOw+0SFzHkry870/g/0erj0bF5YyFv9GIwpxC7RRpl+zbw== X-Received: by 2002:a7b:c191:: with SMTP id y17mr3015294wmi.122.1632384228602; Thu, 23 Sep 2021 01:03:48 -0700 (PDT) Received: from [147.171.68.35] (desktop-016.gipsa-lab.grenoble-inp.fr. [147.171.68.35]) by smtp.gmail.com with ESMTPSA id g131sm4246849wme.22.2021.09.23.01.03.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Sep 2021 01:03:48 -0700 (PDT) Subject: Re: [HEADSUP] making /bin/sh the default shell for root To: freebsd-arch@freebsd.org References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <3f7d159b-9f32-e88c-360e-35f8c4b12e23@quip.cz> <3bde04d9-4479-c89e-7005-775832bd2334@selasky.org> From: =?UTF-8?Q?Mika=c3=abl_Urankar?= Message-ID: Date: Thu, 23 Sep 2021 10:04:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: <3bde04d9-4479-c89e-7005-775832bd2334@selasky.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4HFSNP3y0lz3Pk5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="LlztNy/7"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mikaelurankar@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=mikaelurankar@gmail.com X-Spamd-Result: default: False [-4.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(-1.00)[-1.000]; 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)[]; TAGGED_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::432:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 23/09/2021 09:55, Hans Petter Selasky wrote: > Hi, > > I've always used "tcsh" for root. The little help you get on the > command line to search and repeat commands is very useful compared to > plain "sh". > > Sorry for top-posting. > > --HPS > +1 From nobody Thu Sep 23 08:55:57 2021 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 5748617D2058; Thu, 23 Sep 2021 08:56:08 +0000 (UTC) (envelope-from hans@beastielabs.net) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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.xs4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HFTXl2fPPz3lsy; Thu, 23 Sep 2021 08:56:07 +0000 (UTC) (envelope-from hans@beastielabs.net) Received: from cust-b45927b3 ([IPv6:fc0c:c11f:1a16:eab0:99de:cb24:256:b84d]) by smtp-cloud7.xs4all.net with ESMTPSA id TKWLm0iHlISvdTKWNmtAOb; Thu, 23 Sep 2021 10:56:00 +0200 Subject: Re: [HEADSUP] making /bin/sh the default shell for root To: Baptiste Daroussin , current@freebsd.org, arch@FreeBSD.org References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> From: Hans Ottevanger Message-ID: <97ebc390-a19e-3203-7016-ce541796eb18@beastielabs.net> Date: Thu, 23 Sep 2021 10:55:57 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfDwXLTV9EBextqRsgc6zTg3xU4SeWBb+rxdrztD40abPcpz80t79S7d4qh5d2eQMrir+1AcSMzTdiZap4stpGCb58UdApQXQdbobIoNuB5lSdJbT2cbq 0suw3ORdNWIch+Ys3YEZO6SBG4TbXQQ/0hIOlpRAFD10B6Jcnr0EzcyDU+IiiykQPo0//zNm6sVtLAj+iUXswe/iL8D6Fo3HWJ7Rtg8eHg8TjYMDcR1e8y9J FEEwlO3eJuo8y+r3AhlquAbfhVX+NwJPwwRXYzFUypc= X-Rspamd-Queue-Id: 4HFTXl2fPPz3lsy X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of hans@beastielabs.net has no SPF policy when checking 194.109.24.28) smtp.mailfrom=hans@beastielabs.net X-Spamd-Result: default: False [-2.20 / 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]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[beastielabs.net]; AUTH_NA(1.00)[]; RWL_MAILSPIKE_GOOD(0.00)[194.109.24.28:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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:3265, ipnet:194.109.0.0/16, country:NL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[194.109.24.28:from] X-ThisMailContainsUnwantedMimeParts: N On 9/22/21 10:36 AM, Baptiste Daroussin wrote: > Hello, > > TL;DR: this is not a proposal to deorbit csh from base!!! > > For years now, csh is the default root shell for FreeBSD, csh can be confusing > as a default shell for many as all other unix like settled on a bourne shell > compatible interactive shell: zsh, bash, or variant of ksh. > > Recently our sh(1) has receive update to make it more user friendly in > interactive mode: > * command completion (thanks pstef@) > * improvement in the emacs mode, to make it behave by default like other shells > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > * support for history as described by POSIX. > > This makes it a usable shell by default, which is why I would like to propose to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > If no strong arguments has been raised until October 15th, I will make this > proposal happen. > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > Best regards, > Baptiste > Hello, I applaud the proposal to change the default login shell of root to /bin/sh. As you mention the rest of the Unix(-like) world has used a Bourne-like root login shell forever. It is one of the first things I change on a new FreeBSD install anyway. While there, you could change "Charlie &" in the gecos field to something more sensible, e.g. just "Superuser". I know Charlie is there since 4.2BSD, but the reference to a long forgotten baseball player is probably lost by now. Also, a lot of explanation is often needed when users receive (automated) emails from Charlie Root. Once the login shell of root has changed to /bin/sh, I do not see any reason to keep toor around. It is there since 4.3BSD, but I don't know anybody who uses it in the long term. Many will just change the login shell of root to a Bourne-like shell right away. I have experimented a bit with the new usability features of sh in 14.0 and I must say that it was quite a positive experience. I could easily suppress the urge to install and use bash instead of sh. I wonder if the changes (but not the ones to /etc/passwd) could be MFC'd in a few months, once they have matured a bit, so they would land in 13.1. As you mention elsewhere in this thread, usage in scripts is not affected by these changes. And for interactive use it could be a POLA violation, but the astonishment would be a positive one. -- Kind regards, Hans Ottevanger Eindhoven, Netherlands. hans@beastielabs.net www.beastielabs.net From nobody Thu Sep 23 13:16:09 2021 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 C0E7517C34C9; Thu, 23 Sep 2021 13:16:23 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) by mx1.freebsd.org (Postfix) with ESMTP id 4HFbK25Kjtz4dws; Thu, 23 Sep 2021 13:16:22 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fc4cd5f.dip0.t-ipconnect.de [79.196.205.95]) (authenticated bits=128) by land.berklix.org (8.15.2/8.15.2) with ESMTPA id 18NDGFre000806; Thu, 23 Sep 2021 13:16:15 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 18NDG9ZX003737; Thu, 23 Sep 2021 15:16:09 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.16.1/8.16.1) with ESMTP id 18NDG9jN004992; Thu, 23 Sep 2021 15:16:09 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202109231316.18NDG9jN004992@fire.js.berklix.net> To: gljennjohn@gmail.com cc: "Rodney W. Grimes" , Shawn Webb , John Baldwin , Baptiste Daroussin , current@FreeBSD.org, arch@FreeBSD.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root 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 "Wed, 22 Sep 2021 19:47:50 +0200." <20210922194750.55af63d5@ernst.home> 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: <4990.1632402969.1@fire.js.berklix.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Sep 2021 15:16:09 +0200 X-Rspamd-Queue-Id: 4HFbK25Kjtz4dws 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 [-0.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_SEVEN(0.00)[7]; FREEMAIL_TO(0.00)[gmail.com]; 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:24940, ipnet:144.76.0.0/16, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[79.196.205.95:received]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.966]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-ThisMailContainsUnwantedMimeParts: N Gary Jennejohn wrote: > On Wed, 22 Sep 2021 08:52:53 -0700 (PDT) > "Rodney W. Grimes" wrote: > > > > On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: = > > > > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: = > > > > > Hello, > > > > > = > > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > > = > > > > > For years now, csh is the default root shell for FreeBSD, csh ca= n be confusing > > > > > as a default shell for many as all other unix like settled on a = bourne shell > > > > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > > = > > > > > Recently our sh(1) has receive update to make it more user frien= dly in > > > > > interactive mode: > > > > > * command completion (thanks pstef@) > > > > > * improvement in the emacs mode, to make it behave by default li= ke other shells > > > > > * improvement in the vi mode (in particular the vi edit to respe= ct $EDITOR) > > > > > * support for history as described by POSIX. > > > > > = > > > > > This makes it a usable shell by default, which is why I would li= ke to propose to > > > > > make it the default shell for root starting FreeBSD 14.0-RELEASE= (not MFCed) > > > > > = > > > > > If no strong arguments has been raised until October 15th, I wil= l make this > > > > > proposal happen. > > > > > = > > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BA= SE! = > > > > = > > > > I think this is fine. I would also be fine with either removing '= toor' from the > > > > default password file or just leaving it as-is for POLA. (I would= probably > > > > prefer removing it outright.) = > > > = > > > HardenedBSD recently removed toor. No one has complained (yet?). A > > > small Twitter poll[0] showed that 85% of people who responded do not > > > use toor. = > > = > > A truely disastisified customer does not complain, they simply > > go some place else for there products. Be carefull in what you > > believe silence to be saying. > > = > > I use toor on every FreeBSD machine as the root login using bash. > I never log in as root. Toor has been an occasional lifeline during re-build dissters. Need root & toor to have different executables, & home directories & passwords, & no environment vars on one etc. > But removing it wouldn't be a deal breaker for me. I'd just put it > back into /etc/passwd. Ditto. `One Best Tool' debates can consume time. Best keep time for other things, ( eg I've an interesting regression to ch= ase: 12.2-RELEASE OK, but 12.2-STABLE & 13.0-RELEASE Generic kernels panic on boot & wont produce a /var/crash/vmcore.2 & won't drop into DDB ). Cheers, -- = Julian Stacey http://berklix.com/jhs/ http://stolenvotes.uk From nobody Thu Sep 23 16:47:51 2021 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 C0C75175940A; Thu, 23 Sep 2021 16:47:57 +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 4HFh193Qq7z3HfK; Thu, 23 Sep 2021 16:47:57 +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 18NGlqBA054761; Thu, 23 Sep 2021 09:47:52 -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 18NGlpxQ054760; Thu, 23 Sep 2021 09:47:51 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202109231647.18NGlpxQ054760@gndrsh.dnsmgr.net> Subject: Re: [HEADSUP] making /bin/sh the default shell for root In-Reply-To: <97ebc390-a19e-3203-7016-ce541796eb18@beastielabs.net> To: Hans Ottevanger Date: Thu, 23 Sep 2021 09:47:51 -0700 (PDT) CC: Baptiste Daroussin , current@FreeBSD.org, 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: 4HFh193Qq7z3HfK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 9/22/21 10:36 AM, Baptiste Daroussin wrote: > > Hello, > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > For years now, csh is the default root shell for FreeBSD, csh can be confusing > > as a default shell for many as all other unix like settled on a bourne shell > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > Recently our sh(1) has receive update to make it more user friendly in > > interactive mode: > > * command completion (thanks pstef@) > > * improvement in the emacs mode, to make it behave by default like other shells > > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > > * support for history as described by POSIX. > > > > This makes it a usable shell by default, which is why I would like to propose to > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > > > If no strong arguments has been raised until October 15th, I will make this > > proposal happen. > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > > > Best regards, > > Baptiste > > > > Hello, > > I applaud the proposal to change the default login shell of root to > /bin/sh. As you mention the rest of the Unix(-like) world has used a > Bourne-like root login shell forever. It is one of the first things I > change on a new FreeBSD install anyway. So now you stop changing it, something you have grown use to doing, and all of us who want the old behavior have to add a change item to our list of post install stuff. We BOTH end up with version conditional tweaks to the base system. Is that a good idea? > While there, you could change "Charlie &" in the gecos field to > something more sensible, e.g. just "Superuser". I know Charlie is there > since 4.2BSD, but the reference to a long forgotten baseball player is > probably lost by now. Also, a lot of explanation is often needed when > users receive (automated) emails from Charlie Root. > > Once the login shell of root has changed to /bin/sh, I do not see any > reason to keep toor around. It is there since 4.3BSD, but I don't know > anybody who uses it in the long term. Many will just change the login > shell of root to a Bourne-like shell right away. Your lack of knowing anyone who uses it, does not indicate lack of use. If I want a /bin/sh root user I type: su - toor So now you know someone who uses it! > > I have experimented a bit with the new usability features of sh in 14.0 > and I must say that it was quite a positive experience. I could easily > suppress the urge to install and use bash instead of sh. I wonder if the > changes (but not the ones to /etc/passwd) could be MFC'd in a few > months, once they have matured a bit, so they would land in 13.1. As you > mention elsewhere in this thread, usage in scripts is not affected by > these changes. And for interactive use it could be a POLA violation, but > the astonishment would be a positive one. > > -- > Kind regards, > > Hans Ottevanger > > Eindhoven, Netherlands. > hans@beastielabs.net > www.beastielabs.net > > -- Rod Grimes rgrimes@freebsd.org From nobody Thu Sep 23 20:01:21 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 9934A17D1A47 for ; Thu, 23 Sep 2021 20:01:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HFmJg3ndKz4TYx for ; Thu, 23 Sep 2021 20:01:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92b.google.com with SMTP id d4so5048898uak.2 for ; Thu, 23 Sep 2021 13:01:39 -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=TC8ZIuZCftF4OK47q3RyEZaQel1529WLLLpdufCCqRw=; b=Xf5OzZjNAjXSwBKdcu+NfTWFFrRyasVNfHeGlKw4CZMz4ROEuFbvO4sFAqZo/r93uw Y7atslGYZtEtnxggI+0F7coa14yADn2YCd3VnIaZ5gFmhodZlnEFKhi1BgyxC5kHl+Sf ArJGLoyHxJdLw1mNARe0W+hnY5CCugkJa9J7d6DFBKayTrXEuvdWpgu4F19Jr13NcSYk ZfR8uLM1fqsAEB/gbIZIIKizTSM0B/ZAPfuzp1LCmMdWCQbUlRvrSbWmnF4Ee3CVFv7B EBSY4FRjigfP7FcwbHpbsoJ6GMo8wg2MFBuFQr3VBZOmt3GNAw19Imr4A56l2gc/KBpJ Ff9w== 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=TC8ZIuZCftF4OK47q3RyEZaQel1529WLLLpdufCCqRw=; b=xTVPNdcS90r/AeyAJuGYce7G6riXoFTU7VH0PR9ouRnWOVGNTEbleI5taH2o0djNBZ fObvEvrVBs8lANeo8c1BM5X790biLVAKlIU5X3/IZe8FmFJtASdHzklXGU+y6XkRoOpq 2OxgpfBvxmLD5OIwDda8kF2qc1QohDX4mnBR1vfIP1CC7V47dchCR1jHrOXQ+5XKvpbe ibSY+dZHy3+uAqdaemLBICkFrMxrrPvW5iDCo7TfDR76g7nddgNeCzADMJTECcVzWYdB pQg029gcQW1cC/plUKPEAvkq/8LqdoeGefA/dTO6/qAQxDrt12ehnl0eM9VMfH5GyXoc pCoQ== X-Gm-Message-State: AOAM532av6ZGDbsar1LjZL3t+zS2tepzYBo3e7wCTj2RQzHYYaIwmNdQ ua9mVbmBK8RZ0o+1JuEqYN8abY5det9+snOvho1tNqbx8o/VoA0L X-Google-Smtp-Source: ABdhPJy0axpFDv0ZlXzqTmFKgzzrHmY8OvkSSC4fD800EN/DVtad+s3fxwSkLOCcQQRH9dQGB7w0kphMkZXZK9+n3f8= X-Received: by 2002:ab0:5fc7:: with SMTP id g7mr6277253uaj.85.1632427292594; Thu, 23 Sep 2021 13:01:32 -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, 23 Sep 2021 14:01:21 -0600 Message-ID: Subject: FreeBSD mips support To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000e5a33205ccaf18dc" X-Rspamd-Queue-Id: 4HFmJg3ndKz4TYx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Xf5OzZjN; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92b) 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::92b: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 --000000000000e5a33205ccaf18dc Content-Type: text/plain; charset="UTF-8" Greetings, I think it may be about time to remove MIPS support from the tree. The last major users have moved on, and the port suffers from a number of problems on modern systems with modern workloads. We have a number of workarounds in the tree for different aspects of the mips port that we could retire as well... I'd like to propose removal of mips from -current soon, say by the end of the year. Comments? Warner --000000000000e5a33205ccaf18dc-- From nobody Thu Sep 23 20:20:27 2021 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 E64D117D4211; Thu, 23 Sep 2021 20:25:35 +0000 (UTC) (envelope-from dirk.meyer@dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (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 "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HFmrG5Z9Lz4WSn; Thu, 23 Sep 2021 20:25:34 +0000 (UTC) (envelope-from dirk.meyer@dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 18NKP0Kx017067 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Sep 2021 22:25:00 +0200 (CEST) (envelope-from dirk.meyer@dinoex.sub.org) X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: from bamd12.dinoex.sub.de (dinoex@localhost) by uucp.dinoex.sub.de (8.17.1/8.17.1/Submit) with BSMTP id 18NKP0G0017059; Thu, 23 Sep 2021 22:25:00 +0200 (CEST) (envelope-from dirk.meyer@dinoex.sub.org) To: current@freebsd.org, arch@FreeBSD.org Message-ID: From: dirk.meyer@dinoex.sub.org (Dirk Meyer) Organization: privat Subject: Re: [HEADSUP] making /bin/sh the default shell for root Date: Thu, 23 Sep 2021 22:20:27 +0200 X-Mailer: Dinoex 1.79 References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> X-Gateway: ZCONNECT bamd12.dinoex.sub.de [UNIX/Connect 0.94] X-Accept-Language: de,en X-No-Archive: yes X-ZC-VIA: 20210923000000S+2@dinoex.sub.org X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [185.220.148.12]); Thu, 23 Sep 2021 22:25:02 +0200 (CEST) X-Rspamd-Queue-Id: 4HFmrG5Z9Lz4WSn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=dinoex.sub.org; spf=pass (mx1.freebsd.org: domain of dirk.meyer@dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=dirk.meyer@dinoex.sub.org X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[dinoex.sub.org,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; RCVD_TLS_LAST(0.00)[] 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 Baptiste Daroussin schrieb:, > For years now, csh is the default root shell for FreeBSD > [...] > This makes it a usable shell by default, which is why I would like to propose to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > If no strong arguments has been raised until October 15th, I will make this > proposal happen. We have already "toor" for sh. I disgree on the "user friendly" part of sh. History search in sh and bash can't hold a candle angainst csh. Migration of aliase will be painful as ">&" and "|&" is not supoported. I vote strongly against it. kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org] From nobody Thu Sep 23 20:28:37 2021 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 7E1A017D50C4; Thu, 23 Sep 2021 20:28:44 +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 4HFmvv5ltWz4YYy; Thu, 23 Sep 2021 20:28:43 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B0E053C0199; Thu, 23 Sep 2021 20:28:37 +0000 (UTC) Date: Thu, 23 Sep 2021 20:28:37 +0000 From: Brooks Davis To: Baptiste Daroussin Cc: current@freebsd.org, arch@FreeBSD.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20210923202837.GC63086@spindle.one-eyed-alien.net> References: <20210922083645.4vnoajyvwq6wfhdf@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-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4HFmvv5ltWz4YYy 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.86 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.958]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; R_SPF_NA(0.00)[no SPF record]; 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 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2021 at 10:36:45AM +0200, Baptiste Daroussin wrote: > Hello, >=20 > TL;DR: this is not a proposal to deorbit csh from base!!! >=20 > For years now, csh is the default root shell for FreeBSD, csh can be conf= using > as a default shell for many as all other unix like settled on a bourne sh= ell > compatible interactive shell: zsh, bash, or variant of ksh. Think we should switch in 14+. My main argument is that shell one-liners in documentation are almost always written in Bourne syntax. I believe the fact that we're an outlier is confusing the sort of new users we hope to attract with thinks like Raspberry-pi and cloud images. As a long-time user, it even trips me up when I do some work on a FreeBSD box after spending most of my time on other systems. -- Brooks --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJhTON1AAoJEKzQXbSebgfAt+cH/A/z3/FT7hMIMFbumlo8sbML 9xqGsGC3nsh7oUbtqUn9tRlD1zfh5NnSZ1WyNF6f+L8s01gDBRAm1kndwAajB3Kb K2Zga+B0kVHNACDUAKcZsMJgoQY6TRF4JlhX77dAp9NPb7HWQAQ4c0IKwgVLyy7O 77vPXQXhQeJE4HasF6EY8QrUZJhKePh6SZ1d67dBQpkyfOta2R4oKM7ez8rMZ3OE aUJ/1KhxYzeELJsepP6st60jxzE5hZ6MX/vOIQ2JftF5paTCqPKkP0xi8nGOrHBF MF8iblgMiGLHCtS9CofFQknIwp1uNz7y7YWPy6NjcfNgySwl8+F4nBNnJ7zRBks= =0fIT -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From nobody Thu Sep 23 21:00:09 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 3481717D8B3E for ; Thu, 23 Sep 2021 21:00:11 +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 4HFncC0nN2z4cv4; Thu, 23 Sep 2021 21:00:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (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 AEBCA26F35; Thu, 23 Sep 2021 21:00:10 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Warner Losh , "freebsd-arch@freebsd.org" References: From: John Baldwin Subject: Re: FreeBSD mips support Message-ID: Date: Thu, 23 Sep 2021 14:00:09 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 9/23/21 1:01 PM, Warner Losh wrote: > Greetings, > > I think it may be about time to remove MIPS support from the tree. The last > major users have moved on, and the port suffers from a number of problems > on modern systems with modern workloads. We have a number of workarounds in > the tree for different aspects of the mips port that we could retire as > well... > > I'd like to propose removal of mips from -current soon, say by the end of > the year. > > Comments? I can confirm that the CHERI folks at Cambridge have moved all of their work off of MIPS and onto RISC-V and Morello (aarch64). I don't foresee anyone from the CHERI team providing future support for either FreeBSD/mips or the LLVM MIPS backend. I can say that based on my recent experience, the MIPS kernel port is a bit hackish relative to some of our other architecture ports. The pmap is missing proper support for resolving virtual aliases which prevents the use of unmapped I/O. The n32 kernel support is rather odd and should probably be axed. n32 support should really only be as a user ABI via a COMPAT_FREEBSDN32 or the like, but I don't foresee anyone working on that. The kernel stack is rather tight (and not easily changed in size). -- John Baldwin From nobody Thu Sep 23 21:25:52 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 4E58517DB282 for ; Thu, 23 Sep 2021 21:25:53 +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 4HFp9s1mFBz4fbr for ; Thu, 23 Sep 2021 21:25:53 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id E0F2A3C0199; Thu, 23 Sep 2021 21:25:52 +0000 (UTC) Date: Thu, 23 Sep 2021 21:25:52 +0000 From: Brooks Davis To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: FreeBSD mips support Message-ID: <20210923212552.GD63086@spindle.one-eyed-alien.net> 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="3siQDZowHQqNOShm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4HFp9s1mFBz4fbr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 23, 2021 at 02:01:21PM -0600, Warner Losh wrote: > Greetings, >=20 > I think it may be about time to remove MIPS support from the tree. The la= st > major users have moved on, and the port suffers from a number of problems > on modern systems with modern workloads. We have a number of workarounds = in > the tree for different aspects of the mips port that we could retire as > well... >=20 > I'd like to propose removal of mips from -current soon, say by the end of > the year. It's time for MIPS to go. It's never been broadly maintained and the codebase has always been a bit odd contributing to the maintenance burden of the project as a whole. Over the last decade, most mips64 maintenance has been by the CHERI project at SRI International and the University of Cambridge. We published some well-cited papers and it has had major impacts on Arm's Morello prototype architecture. However, over the past three-ish years we've moved our work to RISC-V and Morello. At this point we have no active projects that depend on MIPS and we'll likely respond to future significant merge conflicts in the sys/mips tree by removing our local changes. -- Brooks --3siQDZowHQqNOShm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJhTPDgAAoJEKzQXbSebgfAZicH/2rBuIBkV3uyjxfNoOh3hUM0 yh6NN9peQ1LJsEnyjy5JC7GHbc6rcTvdK8LlA4CIXdboSpItcs0g28A02OR3ktNV +8wgEbZuglbUYHt9rVBIEIn+ClLX9/hRffdZBqVqcU7Klx3eh1Fc3LnSfrQ4aAm/ XRx9r3DC6AfD6fnFE8WtD2raBrIlShANnkeBY3Y8qJNHOw8urUN+VUBFVZ8ZSSDF hrGAi+glh7Y8wtMbeHdCyAQKnC6ep08+ca2JzX4SR/RMECVidUfSs4cPk0pJP88U tKrOBHMBd97E9nCVuwMv7+Aa5IrmrXAJRogfKdkYu1xDUPAGpHWBSMK5zYmIQaE= =2zBc -----END PGP SIGNATURE----- --3siQDZowHQqNOShm-- From nobody Thu Sep 23 23:51:30 2021 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 46595175FC24; Thu, 23 Sep 2021 23:51:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660060.outbound.protection.outlook.com [40.107.66.60]) (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 4HFsQ90NQKz4r6k; Thu, 23 Sep 2021 23:51:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UbgjTVReVYaEoi81Lu6pGhntERQdl9K8HOUujBXu0fMBqxMZ30kjVVBPJoZn3W/kNcdRYDZuVt945KyoXHxx3FyOX+ZOuGz6zPViNW4lUjXdVNYqUCwfep6gamJc21+4Wx9AZLFvV9J0k1MS8pZBFYRpQjnYqicVWirIh/tX8p3PNWqPOLxDesguP8BXSGI6+i48lzhSGqOsCvIRwZFTt4okfqLDL5sWhPj660pTwXYf2JAF7OVxmkcgIRS7mXrT308FLl40sXniDH2IULSpokOn6FB+68YTDjLL6y/Bo9PJ/c1vdVzOvurBbC1oe4GklYca+CjuQl3502umeymF/g== 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; bh=nAgwcU7wjxMmFh/i3EWPM58+HFMITNdHHXNH9K9WqOU=; b=oTQQkfdrTfLyQSAmCOW8l/aHinKYEuCPjp6fe1NF9iZAVrPuVcr1K3XleFpVCzoyWCVTn+Ewb/fXiL5bWYqE94CHnjZouC1XymRVLDp6FnCDSRWNAZrrGWLd8db7NZoY8b76HLvEJU+ZlEXl2LSeeKHzl1gG9weYrJUPgxQnDRK6AHEpt3OcBoTWCGi8ZUlXdhgpv6HbOjrG7ORv48HbQhf6LhnxsdcAQfga8F2rLiN2ZqEIPBJW7EL0ZSSu6RXp/B7U0VTcAgY6dz+58rb5jwA0c5YFwTj1u7naoE4mOY72DQ3NmLf/5rmLXIhkEs2o4JaEPAbtDE+4dNYb6S4I2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nAgwcU7wjxMmFh/i3EWPM58+HFMITNdHHXNH9K9WqOU=; b=QnBAjVJuq7ZecdPCh+GSLFdmVZ0wchdb2rMzqHCRgM/LVDPkW0iX0J2+M0ShIzLExQYTRpnyTsTnf1o7Og8wBSo4YhrXDvE1HsKIR82cHCUQkwwnf4fE8uH7vfdl1yt7QLXpH9Jd+sZDnNuXOP0jYhaAoBQi26D/UKhMv62XkOrKftqCx0VjYRAWNmFRASZkD+No3gcYc3OifR9FrWfLt1PTp+Tz3OG1F6Fm5h8DQSF14Cfb1bKSP3A+8Gn8FH0YoZMX5gZXaViJ6s48K3nGXjiq6jnpeYzvE+UqpkhKdm+629vb392OcOyW7eKhshd2R0fpHRGJy84cPPOv7vAVvA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB2274.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:2::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.15; Thu, 23 Sep 2021 23:51:36 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::55aa:8e71:343f:dc14]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::55aa:8e71:343f:dc14%7]) with mapi id 15.20.4544.015; Thu, 23 Sep 2021 23:51:31 +0000 From: Rick Macklem To: Dirk Meyer , "current@freebsd.org" , "arch@freebsd.org" Subject: Re: [HEADSUP] making /bin/sh the default shell for root Thread-Topic: [HEADSUP] making /bin/sh the default shell for root Thread-Index: AQHXsLhyrrac4yk4rUGNQqSt2zTCpquySUkV Date: Thu, 23 Sep 2021 23:51:30 +0000 Message-ID: References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 49a3c575-c12b-cfae-c33f-f8372e68b6b7 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7ed4a7f-aed4-45b1-d39c-08d97eed1132 x-ms-traffictypediagnostic: YQBPR0101MB2274: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qXK77pwSIXyVvQjxzc1Jg8cS050oS+9tbjrv6UFVd7FQG9nDPZMB1XbSTvXf4fdrvZOfBYFAQHqTMebr6qJKeBtNJ7JfYGNDSNizeEII56JlkzADk3WI3JD9/4J3s6OIQRK6TUziOOFRwfd72f7/ha6wBjUO6Ph8HnHzpiuBzx8pm/3xpDz+S3+22dqeO+mCuj1rU0A31nklLIsug/ynqxtycv/M89D7FcE9KbQtBxDCLt5E188CXvqF5/MYwSlBf5dQMWn+bOKwFciGjofJjXYVX8FQptjwptZwvuq6m2zryPKLw+1V8o3ck/PqlzZ2AMSVGfs+WlDqTVVqCpkPLcKo3dKrgOe9bH1pH8xJHKgJIlppl6HTEwnsTXp3TSNfpvDs2oNtjyh6I4CGp5L/eJE1xVg99RQO9QEZjJGcDTbC3m8Uf/QCg5L1g6VeMxsUppPQP7FiaDFgsiKp9LQ37/Bw7ExLblUxmnE/AdOgT7G8wUQk2Ih7m22ixq922rqIYjIi8hZMiSih37U53b+WaA8AEC6lXvx77+nqK4y67/NlHiDioOYk7fQcBSQbijhnII6E27+v342xFeMpoLZG5ktDzs4NHX1rMEbYMPjuXiqCHbs9y6O0NOrfGsOCb+PgNLLrwkBpeyAY3YCJJZ1861/sf8bJgXxSdeQJdlFYf43g/5qHtaRE8wxk+dAptmY+ x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(7696005)(186003)(38070700005)(86362001)(508600001)(38100700002)(33656002)(6506007)(9686003)(66476007)(8936002)(66946007)(91956017)(55016002)(110136005)(76116006)(2906002)(5660300002)(66556008)(8676002)(316002)(4744005)(122000001)(66446008)(52536014)(64756008)(71200400001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?KVQlpzq2r2N6K035tHGrL8GGAbcMpYuBeIiGxNv6o69+jdhRv/x0X2BTtR?= =?iso-8859-1?Q?IBIUSOIipdrYEqjRxPYcpKwAfs3kVWuPGlDDbsDjQk6sSdoKPGHOQWL0/0?= =?iso-8859-1?Q?MliZrxNpG3bZamgup5yqFOiZhIcwys7xpPqF+2llpnDC9e4HVUg47lCbfP?= =?iso-8859-1?Q?lVmvhpVWftGHhonUJUTneNuk3TInmtVmqq/ms2qzpbJE4fzqzpOO2B0a0Y?= =?iso-8859-1?Q?K649b0RqmejWRUdFPF5GXx69dgy6LzPW/As0O7TzRVUYq+p/KmIU6B63ow?= =?iso-8859-1?Q?WJau6vOAsiUrvCitfaMVLjPntkHoFZQtLfjqn9kUmI2a6xdb3rD/azGefU?= =?iso-8859-1?Q?CZK5xYeRflEx4CY4okK+iUZWwJfU6M8LKjKBDhimBjY2O8iRJdZDBEc04Q?= =?iso-8859-1?Q?NjCfKO0ANL5VujsN52tI5kOGWI8EIJF+Gj7vf1l60nE8rWyoHUJpvJ/9PE?= =?iso-8859-1?Q?d+hk57Hrlalr0eIQPH4/BONIjOB//EZkbMst1UY7fdVeIN1ccxDfGZcBdi?= =?iso-8859-1?Q?L3e8xAepXT3vCuSNynXWwQbZTq1NlTceoNG4F671dM/ValtXIRIt1UJ1Vu?= =?iso-8859-1?Q?7REpCCp4l9hf6kW0canvRr8vgZl3FUm4ytVKck7IQPmnAX6tZwbQrN4uqi?= =?iso-8859-1?Q?TS8FPxSGtJdhXxt4dHKoj29ZNFF48md46nHj6hx7Uvr1YZFKyUKk83QNre?= =?iso-8859-1?Q?80PhDVR83QPMEXsmUGX+CMhZQkgskKyg91HQVcJ8Qc9K+4YapWgRomORYU?= =?iso-8859-1?Q?OUU4FDH28tdDhv/uLgJYdeumwTiynu/WXlrGDmP3/leZBAvAfFca+5V9sb?= =?iso-8859-1?Q?lVyg0f9XUS6nlrQAIhZuK+Hk/AdxGQRLvM0SgjHgl0DaNbOTDkMrGzSWwi?= =?iso-8859-1?Q?J+DeT2n4d9/MC1o1SB0hz3FfJUxUcs06nZW4Ez+7ZqvoFugotapWyMInly?= =?iso-8859-1?Q?46CW54JjpznL0CX0UAsmWHDv6i3HmGBZziw/3TZMzZQF1db8QjWsaWFGiA?= =?iso-8859-1?Q?cT8Tk11dkJoui04tI0WSzxBs2h1O1wi8coOJL7S6Ji/ka9kvFrL2DtnmVc?= =?iso-8859-1?Q?LoVoB7VzSCZ23LZb75Peth/8glPWO5mLnp34HrPvWSpd7lvntHN+Sq6SiC?= =?iso-8859-1?Q?YJSI5JaQoaaqyXckT2UzBBO+auEnlK8f0s1drIDu7mo0TnfQqLgG7EFgXU?= =?iso-8859-1?Q?7anxeyHQB8UpcEvA+l//ZaFcC+C8VAw92iFVb7WQ0i0Ip669hd1FLs39yz?= =?iso-8859-1?Q?wu31y4GebItp0/+wKL3I4/agHflKJIURvJA06BIdNBSzIC3l0/7jQ30ZD0?= =?iso-8859-1?Q?2ytabGvunLgyE/BgnsjB3AaA2rkec+6uhDkPfCNUevUuFKrdSR8KupZL8P?= =?iso-8859-1?Q?w+r9XY0rMkf3y7xR/bmpYd2ttMnTpR4ggA7mXbIRa6qefXGSA78uM=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a7ed4a7f-aed4-45b1-d39c-08d97eed1132 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2021 23:51:30.9159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: v9qdxyD+5oBVs3TcdfUxl0cPTFSfHYh8kzNG1W+655+OVzZJIXO7lUvdY4Xed42KQuOAtzI7fppNmfzOtUwqzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB2274 X-Rspamd-Queue-Id: 4HFsQ90NQKz4r6k X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Dirk Meyer wrote:=0A= >Baptiste Daroussin schrieb:,=0A= [stuff snipped]=0A= >=0A= >We have already "toor" for sh.=0A= As an aside, I will note that having multiple passwd entries for the same u= id somewhat=0A= breaks the mapping done by nfsuserd(8), since it will map the uid to one of= the names.=0A= =0A= It is not a big issue, but in my perfect world, there would not be "toor".= =0A= =0A= I don't have an opinion on what shell root should use.=0A= =0A= rick=0A= =0A= I disgree on the "user friendly" part of sh.=0A= History search in sh and bash can't hold a candle angainst csh.=0A= =0A= Migration of aliase will be painful as ">&" and "|&" is not supoported.=0A= =0A= I vote strongly against it.=0A= =0A= kind regards Dirk=0A= =0A= - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany=0A= - [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org]=0A= =0A= =0A= From nobody Fri Sep 24 21:06:52 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 A48E517DCF49 for ; Fri, 24 Sep 2021 21:07:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HGPjq6bZ9z3t3J for ; Fri, 24 Sep 2021 21:07:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qv1-f41.google.com with SMTP id a12so7142257qvz.4 for ; Fri, 24 Sep 2021 14:07:11 -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; bh=/O9dgo3gl3g5zzKnd6C5s4XYqNbkr++97GbVdY07ZCE=; b=knDgcO9fe+0QDYtknd+lOOAluakdhgrBucW1EztsYoQhVVIPP6CKOVJUW6uDOIcQUe TIdtVkpF7v3/Adb9Ksc7+njlvb6WghraaKf+Wnm1WUwJE2lhdoSeM3sCDyfp/AEhKGY0 6qZiALuQPjOPS5GnRbkI2N7nLJEqFwDHq6adzAuThmVxWK5ln+xaeuAJT07rbbjxWtRT rfhm+tb/UC3ksd0kqoFNDrLw9hriQPDwAVj24sr1P3Dj+1H6QG5/sbHkhYJ9Ed/Y8zWo WwylEKnX9NZzL4o2caDRJzp7m9IxAk3/M9Me9KPYUJcReUD8zlW7HDDTEBMTq8nz1rln KiCQ== X-Gm-Message-State: AOAM5335qMruZfe4T+b8BGXncgUQFJTalOOZob93C3rL/syMZcw0RhCd iFDr81OgdQC7Yym7m+rxgZf8am05t1VZuJ9pfhJ7fFT5 X-Google-Smtp-Source: ABdhPJxuKaNU6ww6xJs9hK+04Z04xDZhGkKdQey7q6wOLIOCnIpNuEpA4tyBZ821XoAP/xRVwx5keCXy8NFryJQkmYs= X-Received: by 2002:a05:6214:151:: with SMTP id x17mr12472087qvs.38.1632517625151; Fri, 24 Sep 2021 14:07:05 -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: Adrian Chadd Date: Fri, 24 Sep 2021 14:06:52 -0700 Message-ID: Subject: Re: FreeBSD mips support To: Warner Losh Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HGPjq6bZ9z3t3J X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of adrianchadd@gmail.com designates 209.85.219.41 as permitted sender) smtp.mailfrom=adrianchadd@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; 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]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.41:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.41:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 23 Sept 2021 at 13:01, Warner Losh wrote: > > Greetings, > > I think it may be about time to remove MIPS support from the tree. The last > major users have moved on, and the port suffers from a number of problems > on modern systems with modern workloads. We have a number of workarounds in > the tree for different aspects of the mips port that we could retire as > well... > > I'd like to propose removal of mips from -current soon, say by the end of > the year. > > Comments? I mean, I wish I had the time to look after it some more. It works well enough right now for me poking at the wifi stack to try and find and fix weird corner case bugs, but I agree it's time to move on. MIPS is also not getting any further love from the IP owner; they're moving to RISC-V too. (The only thing I'd like to poke at is addressing some unaligned access stuff that apparently is also problematic on some RISC-V silicon as well as MIPS hardware.) So yeah, unless I magically get extra time to update the MIPS pmap support, I'm happy deorbiting it and sticking with FreeBSD-13 as a MIPS base for what I'm doing until things can get migrated to ARM platforms. -adrian From nobody Tue Sep 28 13:47:09 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 211C117D12E1 for ; Tue, 28 Sep 2021 13:47:20 +0000 (UTC) (envelope-from tech-lists@zyxst.net) 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 4HJgmR0tdwz3Hxl for ; Tue, 28 Sep 2021 13:47:19 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 276643200786 for ; Tue, 28 Sep 2021 09:47:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 28 Sep 2021 09:47:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=r8jOCMl3H5IY1RSxAA06j7TzjZW 2VFf4TCz0DWeAc1k=; b=5PMxXz8aaH17+fpb4k8mxrqo0w30ujWjTviy8iR6tBO tAO/isTpOdZDGE6X+DVd807g245qrRybaSyiIWzqdT+kt6LwHKJuLJoYQ4Odky2d AAM8TiihmqYHyaCPcvQtZZDM4SR1KGiDblBtnPq3jsXe1YQynDRBpEL8sdwFOHvw 4mnvz4EWkVSB7IgfGXxbelqF3ydM0jO73bfk5RtgtXHxKn51CrspcMBpqihx6HJS 36Xb2j8hqXfmbqZaXBSNDXhc1UKodzUDmSsMErG246VQFF6R6vj/p4RT1sIci4AW 85LasbC60RcRdOVEf14/VLu6194BNKLb4TPBemRHRLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=r8jOCM l3H5IY1RSxAA06j7TzjZW2VFf4TCz0DWeAc1k=; b=IHBJS77TSJPS0Eq9ut39UQ PrPXAdCwMwBI7MwfQFtfYD/m7RlGfyjHdmiYxvwgGvkznxw49CIlpYKkHoS1V5tc iINm4/l3Fo4OvQce6geYA7GmqZYG0EhxrDSltLJutv1K8uiWZw7hsADfv0D5L++h +zG3+0QWNj8Yu3icB8FzHhnifrx7JwS/o6eSWWfHmUWXmxPM53zjGnzTR1hJIsGL 2C7l9paOHbRPlKMXGboFl56NwYXlEEYi45CqR6NWp6GpsGgF6blS0UUQMl4ct9ac z8HZsJxxpvg+jvicYQwj8/htYsLbUFBNzuS2Nmtk7SoKpHlFJ9FS2edg+m0WSdqA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudektddgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvte dttdekuddvgeevlefftdekffdujedvhfduteenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 28 Sep 2021 09:47:11 -0400 (EDT) Date: Tue, 28 Sep 2021 14:47:09 +0100 From: tech-lists To: freebsd-arch@freebsd.org Subject: Re: FreeBSD mips 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jfFMrTECjnyOcOuK" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4HJgmR0tdwz3Hxl X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=5PMxXz8a; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=IHBJS77T; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 64.147.123.19) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.19:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,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]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from] X-ThisMailContainsUnwantedMimeParts: N --jfFMrTECjnyOcOuK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 23, 2021 at 02:01:21PM -0600, Warner Losh wrote: >Greetings, > >I think it may be about time to remove MIPS support from the tree. The last Do you mean just mips (mips32 I suppose) or do you also mean mips64? --=20 J. --jfFMrTECjnyOcOuK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmFTHNQACgkQs8o7QhFz NAVuqQ//fstqo8M23BRos3u5osnTHRIRD2xe5OrrLN4juabIBqmL3x3MNnkdjrHh OB+mfZ5s4HXda0H5DpOMidEjr9uKWsrum8dZeM2t0YsHhJCfKArfGqZyeU9QtCdp E5b7nhLwV1HulnljZCIFQqNhClbg5tKo9ky7yMU+joYCjCT9RF4prbdPEPi1Mvti G3oNfOVVoWYHtDu5QmE7/db3vzvkSsXvSIEu0mjCT6+vo7IBnJiYz37LeAik7QLz Ytzl9VOk4cPL3rxxP00n9z2JgzXFdVOIun7SU/lD6JmdOCdsuF9bB0bpoeRX7nKb bqQ77ubE9GHRDpd0ITf+uO9Dz9lcyF0tzMqDH+4A/e5LDiiWy7fVznkqOw5E0nzz s27XbhUq6dU4otK7AGs+Sv3Rvjxactrj+U+4w0bvu3DejDoDoCFnx7s9epjV5lwu KdJI3kgjBjTvvT0Tx3kb+N/NNaJnY/a5zyNff/0iyAclHsrRYbzKMZxjgM0SDW1c sthjy9rptnssWpMZbJ4m8MXxucqPTvswAh/FdJLzcztPH1OdQ8jpuhLUwNT5sLC7 +N1phvqCSh1LA6HC3IyrQvoVN+tWaeKSyiYLGdsqFB09WOVXNM3oTapzAlU76/VM CegAcyBoc1x2kT6Vtwb4+EsMBKO3YU6+x+OY/nUBqNQyD9MDJ+c= =nPUn -----END PGP SIGNATURE----- --jfFMrTECjnyOcOuK-- From nobody Tue Sep 28 14:24:09 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 EA7E217D4F01 for ; Tue, 28 Sep 2021 14:24:19 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (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 4HJhb65WdVz3LgF for ; Tue, 28 Sep 2021 14:24:18 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E0C593201F17 for ; Tue, 28 Sep 2021 10:24:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 28 Sep 2021 10:24:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=tcFrTj5PBfkFLapJC8XQOCGT5B+ ajKKC8j7Lh0+yhEw=; b=qMcpzlgfGbXMus0j9cHQ87x0fyN+dNNJFvCDhoYapKe Cl/PTGa7bJzmY2DYXObNdzTUOE1JwlDlfo/g5QX5EiFGmy2ziWQUJSxNF5etzcRA e/k10LMdGnJpei5qXG84lLZEtsZQvlCIHzES70/jf1Rz1f7RiDIWgREJtCvDRFGl K6gWr6phAckODeBWlKGYj7QgJB/+66sQStI+Mc27CNozurkqQDYFTKRTGrismUQk IMErw4mTQU4DYihkUVrin8DhLOlxQl814kl+FMgXHRhHyd+a5hfn/KE7lyxYPNYh ZCZKeYcDCZib81US2OmAy0B8e8xTs89jgOwTBSUA2aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tcFrTj 5PBfkFLapJC8XQOCGT5B+ajKKC8j7Lh0+yhEw=; b=Gw3xJJ5c9sHGvn+ESfznqI THtaMKIzOaflLO1I6BYiHgXZ1mF+i+E0dNt56OFkVEFhzT2XPXD9uVNzgYwV40qK JVTuvWdE5iZGNRklxywIzZlAz3RvMa9R+iw3eyNGLyYHM0Zo0dHqtlBPxmLkoHh7 OzRPfP0hghhEReunJdKgeBe3oDOGtUGO+2jsfynb4RMy/lnSNtCUPPxRqI23Pvt7 Ltq4E0gaf7M33B+GTxVw2rT2lPNvGZnFmDUTA/PV5BsusnekmQiyEdN6wQ0cIrge eIkrk2KSbPRlsNkyaruEPDteOH9q/d+xLaoRm6wlIFj9y+Vx660uuSJgLAemMksA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudektddgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvte dttdekuddvgeevlefftdekffdujedvhfduteenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 28 Sep 2021 10:24:11 -0400 (EDT) Date: Tue, 28 Sep 2021 15:24:09 +0100 From: tech-lists To: freebsd-arch@freebsd.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <82d7f4d1-5ce9-c7ed-d993-b16b3ddac6e3@FreeBSD.org> <20210922154222.6bvnqk4kjjxewy6n@mutt-hbsd> 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="K9OVYB68SIxcMBmH" Content-Disposition: inline In-Reply-To: <20210922154222.6bvnqk4kjjxewy6n@mutt-hbsd> X-Rspamd-Queue-Id: 4HJhb65WdVz3LgF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=qMcpzlgf; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=Gw3xJJ5c; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 64.147.123.24) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N --K9OVYB68SIxcMBmH Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Sep 22, 2021 at 11:42:22AM -0400, Shawn Webb wrote: > >HardenedBSD recently removed toor. No one has complained (yet?). A >small Twitter poll[0] showed that 85% of people who responded do not >use toor. I think that before removing functionality you need to examine the issue for conformation bias. I bet that many who answered your question were unaware of toor and of those even aware, it's not like there are loads of examples in documentation discussing the versatility of root+toor over just root. I'd vote to retain toor unless there were compelling reasons not to. And even if there were reasons, I'd vote to disable-by-default before removing it completely. --=20 J. --K9OVYB68SIxcMBmH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmFTJYEACgkQs8o7QhFz NAVtWQ/+JphK1uI+H4Cz4O7e31nW/X1sm1gL3Q32Z4rERuOkgY8aYAGtXuV7mQ/x JbeTgZ2heoOy+ZYlY0tkKJEZHOixj8FFB55mY4EbgidKH2CdsZB9d9gifJ89TsO7 HSjaZQdt3coTC//9h6LCVZm2gY+3yWvJI/jjDKE6jI+z2+fp5FRvmrIOgYBRudYt QOk3H0IRneT+lgw2+15kkpkfMjMVxJaHZaPHJe6+9Xt+HZY26iadyBEv876F1Kjk GVW8TwCSEt7/InwICfw7I/Z5hbk5eZkPdyicn06QpVrze1tBmT3jFZw08SBcmvAS bNPEfSHQuVOVHm1SNQDFmeEWRs3gbS0YGZSdmOuye04jhsrHaTjUB6fuu3JC9uQa EkY+tkpch0h5TNsAP9S7/or28bQk5Rn5vgd6g/c0ffIdR1Sx4Vy7zRZugfqhqWFL 3PHhHeBr5kKq6c1FXjJQO1o2XP8Ivbeh0mQFJb2Z/E066R2xwEBxk4K8xrRqTD6g 9/T8sH3L9eZr6pJSvh6jRmfXusTd317iWVM/tqOHvKj0AL/IrsxkmEsjmw2i6utZ +qyBOAeX+n+QkJhXz/YWrQZGz3drYTcBNBpre97sqZf7rl80chnG3PY+ZShw/0TF YFIxZOVM8BNLbAJEJQtKzjjKSTRxIKVFsYU+hDnc1i6Io8NgMsk= =m2UQ -----END PGP SIGNATURE----- --K9OVYB68SIxcMBmH-- From nobody Tue Sep 28 14:46: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 AAB7917D7316 for ; Tue, 28 Sep 2021 14:46:45 +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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HJj513wR8z3P0N for ; Tue, 28 Sep 2021 14:46:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2e.google.com with SMTP id 66so18353478vsd.11 for ; Tue, 28 Sep 2021 07:46:45 -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=TjiyVS6/MpXSsxAa5eAjEOSmkq7+Kbmk700ogUoApk0=; b=Pns5WWSA7VaptxYmOhT0hVnnWs+mPF0J6bvygWIuoOl/7bcf37HaOpNO0BnV0o73bR tpsqBZnZjlxJqD9yJ18lM4+NcKBOnwW+Q64P1FZd90Wd0LersJz68rzvrUoOp1ksfYpz R3w7tu75ckvbI7mMNGk0oPFYZTlSENr6d3bx8GK3E0X8S9dX/loen7FV0m4YWHtX2+xQ ITah7FU5caPhvsTPJUaJTs86k6Pzaasu47Pl2hr+PSHwx77SiHyBYCmcvJbyo6R7nzJd HKIBnclSfKdBt1K6Qo5OyWRMaDDynkvfIe57bMEuDFW/ccrNas9ypI4CCYNSvzeblgng bmpg== 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=TjiyVS6/MpXSsxAa5eAjEOSmkq7+Kbmk700ogUoApk0=; b=UQmAIvknlwMYzd2hWa1kYv9MdceM3puWSlWk1QBhnCHJRQOrXcmEYkD9jD0slEP+dm eKLQAEVcHJnuSlmuWS3iflKvABqLVc8+082KsM8bIu7gFXC8mnEEqAYQYY1szQZxKALM sHWzlQjZWLGIx8SkvoAy5ntdPFU0Amqrb2bJ4lcj3sWwv6Ri3wKXq+QQ34/Aabro24o4 Rqgvfp8s1cmiS8PcCkxIbvS6XBTj+223u9dD6mjIyzLdhGg4E1X/N5qgFzYz3Alac3gz hD3xBCgqMlcgbMcpur675PG4XkLichguunnoui01VHFv+knNCa6RN9pd7F9lUtu1EhQM xBlw== X-Gm-Message-State: AOAM533qwbnvm6HWX9TfMZRKg2B7Y4jsWJxkRpe/ZZKAWpEiytNeIvZX Q2i0HhlryL0TURudeKDeCx3tuje0hBvIub3DYmE6k4KG1M5ECfnh X-Google-Smtp-Source: ABdhPJwtXEkOPBxL+NkFoLXeuvzMClMUWfH+6kguVVLrX6Xv7E7ajEz8HdPUmkqcsw0omyb3id4fAAFW3DmzqTAKhO4= X-Received: by 2002:a05:6102:317a:: with SMTP id l26mr5572287vsm.6.1632840398748; Tue, 28 Sep 2021 07:46:38 -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, 28 Sep 2021 08:46:29 -0600 Message-ID: Subject: Re: FreeBSD mips support To: tech-lists Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000f1506205cd0f4785" X-Rspamd-Queue-Id: 4HJj513wR8z3P0N X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000f1506205cd0f4785 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 28, 2021 at 7:47 AM tech-lists wrote: > On Thu, Sep 23, 2021 at 02:01:21PM -0600, Warner Losh wrote: > >Greetings, > > > >I think it may be about time to remove MIPS support from the tree. The > last > > Do you mean just mips (mips32 I suppose) or do you also mean mips64? > All mips. mips64 is in no better shape than mips32 these days. Warner --000000000000f1506205cd0f4785-- From nobody Tue Sep 28 15:42:39 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 B588D17DCD37 for ; Tue, 28 Sep 2021 15:42:43 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (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 4HJkKZ6tT4z3k96 for ; Tue, 28 Sep 2021 15:42:42 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 057B8320091B for ; Tue, 28 Sep 2021 11:42:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 28 Sep 2021 11:42:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=bnzSbqR4jfX6tH1nHOMGml6BWdi TOK/ZG/Doks7e1eU=; b=nuocg5hIDX0HmTQ5tS46c/GCo0y8i1di+CeEvV0TIuz Gs8DpGjlaij9Tj5nAgbycUPlTlZjjc6ggcYKh8GJvjyR1BIEqcPRn4OMHRipRgL2 LNJeOsLxjqqu65GHLDpfu8bO7yUac+RAvQkh86k7JaeuPXnpoENPnlVUGXTlgXru yaHB2bOeT9VKaOKqCOyxoCLkWHnGsdxlzlbVRV6ep2nngs8Z6/Dphuz9/z1uNTpR /lxi7qGzYMSoQTRssXPnzUaai4MYxtLMCQXDSTqPrtVSqBCX6zkFgBFon8AHiOpc 82g9BOt+F+b5pSmA3eriIwSSwJTB656//s/8O6c5IlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=bnzSbq R4jfX6tH1nHOMGml6BWdiTOK/ZG/Doks7e1eU=; b=EXFU6zK5AyC++EZcq0U123 EHoQIfzQD9gvCDwMEjNHx76kxOX9AdpIxzd5ALvxKRC7gHqqbzonI7sOnCbLHBbk JRkDjKB6jrAEHuyQcm5ytk6h5XqxjMOodm+F2pUBAA2Z462kpE6tiJb2fRzleG48 iubYn+xGnNQXzpRfn4nSSGkeUeheafriiB9Q59CCVDUMsUAQa0He6p3ByG0OZglr jfUaiN9pAsxQfXa4nVSSOBrp+UBesUtiiSpWQaW+Z8v0AhWuBoU4ipPonjAbx07o 2S7U1s73dZ712MJpx0hjY5nv/ZFP/plSoxgUsXIs4+uMMsxvJan7ThR+9IjA89Sw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudektddgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvte dttdekuddvgeevlefftdekffdujedvhfduteenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 28 Sep 2021 11:42:41 -0400 (EDT) Date: Tue, 28 Sep 2021 16:42:39 +0100 From: tech-lists To: freebsd-arch@freebsd.org Subject: Re: FreeBSD mips 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PyT0NbPimL5WYp+z" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4HJkKZ6tT4z3k96 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=nuocg5hI; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=EXFU6zK5; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 64.147.123.24) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,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]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N --PyT0NbPimL5WYp+z Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 28, 2021 at 08:46:29AM -0600, Warner Losh wrote: >All mips. mips64 is in no better shape than mips32 these days. OK. I understand.=20 I tried a few years ago to get an edgerouter lite 3 working with freebsd but failed. I'm using openbsd on it now. I think it might be all a bit chicken-and-egg wrt mips. There's a lot of mips64 hardware out there that's still working; the edgerouter is not especially old. I had to carefully search at the time to discover=20 whether *any* bsd worked with this hardware *at all*. ah well. OpenBSD is still BSD ;) and the last time I looked it was fully supported for this particular octeon mips64 device. (by that I mean binary upgrades btwn OS versions).=20 --=20 J. --PyT0NbPimL5WYp+z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmFTN+YACgkQs8o7QhFz NAXMlBAAsHhugYdbHwzNp5crQqBR8mPst0+7Q3kccfq/2f/9FiR2/THhM7E1w0RL hJbghpTg+WQ6kwB7M2wBj63eH535fNEc2dAATMZ3zDCoxXHoJDGiNhL1Au+RUIu/ bhC0FWqoUyMqtd6cFY0U52s3AcmBd5FYPbnUBxsWnRMBa5GLV87GeH/XftnuAeJ4 53HK0YkZJ2NV/gNitZV1vVY3qrLaKa51seIfpRTnGeEHM0PPDrIL0FA8eqZfZiPJ +S74cG6QmP27UzCDbX6CaSTunu6RBa1o0RvoFtecw1KsTKlw0T7vrxFJWl0eq8fn A1IWt2HeEO0Itbq1wWTNW8EKEYmjFl3UrZFFyQ0Twh7tvu0KnhE59N8U9D1fV/wq jk7yoldKl+flPYXJyibKU1EjPLb+u46M7rFG9tIKXdEHOYDKgLPipsgh1cNrlAlX d3/S/Ujr3WIId9vJksCC90oIZZbob4mWgljeYD997jOMVu3MzmRIE68SaXI8xh2q 3SUuOmFKSSA2OKX/rgwa6YavT1LR1IuRfN1wCCqN6SCk3X5l0VTlDRb136fHkYDz 4S/2+zZq4oG8QKFCOAQST4hsN8Fsm/VsQHqGvEAVqlB/BYsSDHOf6eXYcFj1WMmL VZm49U9EvyUeG6gVcqw8rK/FDjPZu76auB3aubeKvMQSfU1urHA= =hxGn -----END PGP SIGNATURE----- --PyT0NbPimL5WYp+z-- From nobody Tue Sep 28 15:56:26 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 73D4817DEC61 for ; Tue, 28 Sep 2021 15:56:28 +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 4HJkdS1bl1z3mwG for ; Tue, 28 Sep 2021 15:56:27 +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 18SFuQeh075768; Tue, 28 Sep 2021 08:56:26 -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 18SFuQ10075767; Tue, 28 Sep 2021 08:56:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202109281556.18SFuQ10075767@gndrsh.dnsmgr.net> Subject: Re: [HEADSUP] making /bin/sh the default shell for root In-Reply-To: To: tech-lists Date: Tue, 28 Sep 2021 08:56:26 -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: 4HJkdS1bl1z3mwG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > Hi, > > On Wed, Sep 22, 2021 at 11:42:22AM -0400, Shawn Webb wrote: > > > >HardenedBSD recently removed toor. No one has complained (yet?). A > >small Twitter poll[0] showed that 85% of people who responded do not > >use toor. > > I think that before removing functionality you need to examine the issue > for conformation bias. I bet that many who answered your question were > unaware of toor and of those even aware, it's not like there are loads > of examples in documentation discussing the versatility of root+toor > over just root. I'd vote to retain toor unless there were compelling > reasons not to. And even if there were reasons, I'd vote to > disable-by-default before removing it completely. I agree with the statements above, just wanted to add a detail that the toor account is disabled from login by default as it has a password value of *. As far as I am aware the only default way to the toor acount is via su(8). > -- > J. -- Rod Grimes rgrimes@freebsd.org From nobody Wed Sep 29 23:35:06 2021 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 0B03E17D1B82; Wed, 29 Sep 2021 23:35:12 +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 4HKXmG2k2Zz3JdM; Wed, 29 Sep 2021 23:35:10 +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 VifcmmNVJczbLVj6TmkCIo; Wed, 29 Sep 2021 23:35:09 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id Vj6SmppZycHSBVj6TmtBD5; Wed, 29 Sep 2021 23:35:09 +0000 X-Authority-Analysis: v=2.4 cv=I4EG+Psg c=1 sm=1 tr=0 ts=6154f82d a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=7QKq2e-ADPsA:10 a=w16vAm4-AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=ZIg2hF9TDmgWk9H5LNoA:9 a=CjuIK1q_8ugA:10 a=eWus_ag6ds_90y4h1ov8: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 ESMTPS id 1717E13D; Wed, 29 Sep 2021 16:35:07 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 18TNZ6cc006285; Wed, 29 Sep 2021 16:35:06 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202109292335.18TNZ6cc006285@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 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: current@freebsd.org, arch@FreeBSD.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root In-reply-to: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> Comments: In-reply-to Baptiste Daroussin message dated "Wed, 22 Sep 2021 10:36:45 +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: Wed, 29 Sep 2021 16:35:06 -0700 X-CMAE-Envelope: MS4xfBtAys6I7cbW0UMERcztIE/xLuLIthrlO0BFLjdG//OcKpQ69SOChQnmb3trdK0ajR5RbOi7ajlztu/kFVHiG8Dv8ytFYfLd+O57B9N3jLgX2V0KCufb /BIJXoHge4TaUWHEPO62K+gWzOf781UcJg9d5wq/LjOhwLMrezNHOpo6rqlQHN6WB/GePNeXCGDLU0pbg8ZmHBm2P5R7+p/hVIrH6qZBOd0S/z1oIbs1U1Db dzfYk9LbeWD25cGaj4cZyw== X-Rspamd-Queue-Id: 4HKXmG2k2Zz3JdM 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 [0.19 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.79)[0.793]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[3.97.99.32:from]; 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:16509, ipnet:3.96.0.0/15, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[3.97.99.32:from]; RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received] X-ThisMailContainsUnwantedMimeParts: N In message <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu>, Baptiste Daroussin writes: > Hello, > > TL;DR: this is not a proposal to deorbit csh from base!!! > > For years now, csh is the default root shell for FreeBSD, csh can be confusin > g > as a default shell for many as all other unix like settled on a bourne shell > compatible interactive shell: zsh, bash, or variant of ksh. > > Recently our sh(1) has receive update to make it more user friendly in > interactive mode: > * command completion (thanks pstef@) > * improvement in the emacs mode, to make it behave by default like other shel > ls > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > * support for history as described by POSIX. > > This makes it a usable shell by default, which is why I would like to propose > to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > If no strong arguments has been raised until October 15th, I will make this > proposal happen. > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! Having used /bin/sh as my root shell on all my FreeBSD machines, here and at $JOB, except for only one, I feel this is perfectly reasonable. -- 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 Sat Oct 2 10:04:05 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 1FC7A17EDAC1 for ; Sat, 2 Oct 2021 10:04:16 +0000 (UTC) (envelope-from marc@blackend.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (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 4HM2dC0p1Sz3MPQ for ; Sat, 2 Oct 2021 10:04:14 +0000 (UTC) (envelope-from marc@blackend.org) Received: from emphyrio.blackend.org (unknown [82.64.86.146]) by smtp1-g21.free.fr (Postfix) with ESMTPS id 5B43BB00515; Sat, 2 Oct 2021 12:04:07 +0200 (CEST) Received: from emphyrio.blackend.org (localhost [127.0.0.1]) by emphyrio.blackend.org (8.16.1/8.16.1) with ESMTPS id 192A46S2001630 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Oct 2021 12:04:06 +0200 (CEST) (envelope-from marc@emphyrio.blackend.org) Received: (from marc@localhost) by emphyrio.blackend.org (8.16.1/8.16.1/Submit) id 192A45nn001629; Sat, 2 Oct 2021 12:04:05 +0200 (CEST) (envelope-from marc) Date: Sat, 2 Oct 2021 12:04:05 +0200 From: Marc Fonvieille To: tech-lists Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD mips 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6JmKjhwMeBKTxxE/" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4HM2dC0p1Sz3MPQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of marc@blackend.org has no SPF policy when checking 2a01:e0c:1:1599::10) smtp.mailfrom=marc@blackend.org X-Spamd-Result: default: False [-1.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[marc]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[0.999]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[blackend@freebsd.org,marc@blackend.org]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[blackend@freebsd.org,marc@blackend.org]; RECEIVED_SPAMHAUS_PBL(0.00)[82.64.86.146:received] X-ThisMailContainsUnwantedMimeParts: N --6JmKjhwMeBKTxxE/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le 28.09.2021 16:42, tech-lists a =E9crit : > On Tue, Sep 28, 2021 at 08:46:29AM -0600, Warner Losh wrote: >=20 > >All mips. mips64 is in no better shape than mips32 these days. >=20 > OK. I understand.=20 >=20 > I tried a few years ago to get an edgerouter lite 3 working with > freebsd but failed. I'm using openbsd on it now. >=20 > I think it might be all a bit chicken-and-egg wrt mips. There's a > lot of mips64 hardware out there that's still working; the edgerouter is > not especially old. I had to carefully search at the time to discover=20 > whether *any* bsd worked with this hardware *at all*. >=20 > ah well. OpenBSD is still BSD ;) and the last time I looked it was fully > supported for this particular octeon mips64 device. (by that I mean > binary upgrades btwn OS versions).=20 Hi, MIPS arch is still present in education (e.g. Computer Organization and Design 6th edition from 2020 is available in both MIPS and RISC-V version) because it's easy to use it to describe things (well, RISC-V could be used for the same purpose but hold habits...). As you said many 3-4 years old routers, Wi-Fi AP, etc. uses MIPS hardware. Loongson still provides MIPS64 based hardware (with some changes). So it's a shame FreeBSD stops MIPS support, but if it's in bad shape and no one has the energy and time to fix it, it's difficult to raise an objection. I also wonder if someone really use FreeBSD on MIPS hardware, each time I had to use an OS on this hardware family, I used Linux (Openwrt for example). --=20 Marc --6JmKjhwMeBKTxxE/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQRV00iDSgSCiqE5pc/ND1HAT4506AUCYVgukAAKCRDND1HAT450 6KwtAKC06f2O/ZoPnMieWv8U4av8MIvsegCePqfJd1xaxLwKTA7G0UI5qOFGQZ0= =HPZY -----END PGP SIGNATURE----- --6JmKjhwMeBKTxxE/-- From nobody Tue Oct 5 04:01: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 68AB012D4F7F for ; Tue, 5 Oct 2021 04:01:48 +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 4HNkRc1gWDz3NjY for ; Tue, 5 Oct 2021 04:01:48 +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 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 155E52C177 for ; Tue, 5 Oct 2021 04:01:48 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f170.google.com with SMTP id x9so7805151qtv.0 for ; Mon, 04 Oct 2021 21:01:48 -0700 (PDT) X-Gm-Message-State: AOAM530yciLMqyv6nBcG+5kL62a3Dy7l4eKiAZraXcgM81KXYfOYk2nP 9Y5Eu0Ey5BLIJXRSUYkQgwoK8cz8e3M2wiFYCjI= X-Google-Smtp-Source: ABdhPJzE7EdJzUZI4UvawkHF+Uf+2KWWcRK07kXZy7b3i3dnFH7aCCBN4xlm3ymjuZqBqEzxQM0uReg2LVnOZiM6EQI= X-Received: by 2002:ac8:7384:: with SMTP id t4mr17303045qtp.83.1633406507747; Mon, 04 Oct 2021 21:01: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 From: Kyle Evans Date: Mon, 4 Oct 2021 23:01:37 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: _FORTIFY_SOURCE Implementation To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-ThisMailContainsUnwantedMimeParts: N 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. Thanks, Kyle Evans From nobody Sat Oct 9 12:13:33 2021 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 B893512B44E0; Sat, 9 Oct 2021 12:13:43 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (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 4HRP9L1dqXz4jpk; Sat, 9 Oct 2021 12:13:42 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id 199CDXOP012649; Sat, 9 Oct 2021 15:13:33 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sat, 9 Oct 2021 15:13:33 +0300 (MSK) From: Dmitry Morozovsky To: Hans Ottevanger cc: Baptiste Daroussin , current@FreeBSD.org, arch@FreeBSD.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root In-Reply-To: <97ebc390-a19e-3203-7016-ce541796eb18@beastielabs.net> Message-ID: References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <97ebc390-a19e-3203-7016-ce541796eb18@beastielabs.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sat, 09 Oct 2021 15:13:33 +0300 (MSK) X-Rspamd-Queue-Id: 4HRP9L1dqXz4jpk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=rinet.ru; spf=pass (mx1.freebsd.org: domain of marck@rinet.ru designates 195.54.192.68 as permitted sender) smtp.mailfrom=marck@rinet.ru X-Spamd-Result: default: False [-2.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[marck]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.54.192.68]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.08)[-0.077]; DMARC_POLICY_ALLOW(-0.50)[rinet.ru,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8331, ipnet:195.54.192.0/19, country:RU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 23 Sep 2021, Hans Ottevanger wrote: [snip] > While there, you could change "Charlie &" in the gecos field to something more > sensible, e.g. just "Superuser". I know Charlie is there since 4.2BSD, but the > reference to a long forgotten baseball player is probably lost by now. Also, a > lot of explanation is often needed when users receive (automated) emails from > Charlie Root. FWIW, my deployment route includes changind this to "`hostname-s` &" which helps much when digging into root-robots mail folder RE: history, "!cmd" and "!?param" would be great if implemented @sh [snip] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] --------------------------------------------------------------------------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle@woozle.net *** --------------------------------------------------------------------------- From nobody Sun Oct 10 18:38: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 ABBA317ECFA1 for ; Sun, 10 Oct 2021 18:38:50 +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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HS9gF45tFz3q0J for ; Sun, 10 Oct 2021 18:38:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe31.google.com with SMTP id j22so1421843vsl.5 for ; Sun, 10 Oct 2021 11:38:49 -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=fmTERphRUI9KDLeet5xBjtVUkLxgsuodpu/MUlHUA9k=; b=P65xmW9z8BZLQBdsw9/UyJfPsiyNea2jqUNwH9ep+a26/3xf5YAumceV1FWF9yZ37n +ETflUL/apW+Doav3Smsnxz77vYGzGT0S9ql9TwIdgoQImJnxPJO/U9dGy/7aN0f8v5y S8NU4sAqPBDf9R9PSLDNgpSxQ2NDtxByaCn8Pk3/94Pr3fvG2tqx9++1MgIVFZBWw8N4 KXwm9IZOXh+oDj3eS0ghGcCaqw+yFH9SMxsBaksTyhckf1p3Xlzy5tEsIig1dusxmOwX CH+/79oygyxOaj1M/BcYWdfnVXQYONmAE24eUCy3b02rRser+7yEq0cYZgiUvxB60YZS znhw== 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=fmTERphRUI9KDLeet5xBjtVUkLxgsuodpu/MUlHUA9k=; b=y7ft2LGJOXZ8CXzGgucPMc9FyHBjCp7U251rXWS6lCnQtqWakz0JBFXudjDyvGTDmN eZkqoVordQMJigYxrvW5OC5dFSzl0KiMfo6TkzYNhPnEoAAti+kupmVTO0ogCyHnvku+ rfT+BGfeL/53SZYUIVqU/LFsCgJiyMjkkiA6qAL9kCagf7/z1fYRJt5XnLf/eVfdTmwf XvzjD/2IjwUh10ySq8CPuOpCceR7cNSxY0JrAPYRk1FjLsoOYmZRLgghNh5q/wrY95jH Zq/clsvuyT0GEzHKIYsvV6YN/SKCyzOL8h5bTixTDTX1mFDbD6giwgWAhhr32dsShZBm nu9w== X-Gm-Message-State: AOAM532OaSD4UkcKuHrvdmpipMr/k7VHfupXvFHYhJq7lTzSqbdTmEOt jfce0vVT/X67esQoHYcQet12pi78HbRPLGm6d+Np/AZ0nl+bsg== X-Google-Smtp-Source: ABdhPJzSMZhhJzc1QMIJtJGICMQpFsvl1LBpSfg7gYBSwDC4rZsoHcFgVPUYakUn7WNiEgcBdZv+dcpgsB12ba32/4s= X-Received: by 2002:a67:d28f:: with SMTP id z15mr20254061vsi.44.1633891128672; Sun, 10 Oct 2021 11:38:48 -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, 10 Oct 2021 12:38:37 -0600 Message-ID: Subject: Minimum supported version for -current To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000539f8305ce03ecd1" X-Rspamd-Queue-Id: 4HS9gF45tFz3q0J X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=P65xmW9z; 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]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; 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)[-0.999]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31: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 --000000000000539f8305ce03ecd1 Content-Type: text/plain; charset="UTF-8" Greetings, I've created https://reviews.freebsd.org/D32444 to bump the minimum supported version of FreeBSD to build current up to 11.3R. This will allow me to remove a number of old workarounds from Makefile.inc1 that are starting to get in the way due to their sheer number. Do people have a need to build FreeBSD -current from 10.x systems anymore? Warner P.S. I selected 11.3R because it's the most recent release to go unsupported. I plan on testing this release, but if there's issues, I'll post to this thread. --000000000000539f8305ce03ecd1-- From nobody Mon Oct 11 09:15: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 C2B4917F90C7 for ; Mon, 11 Oct 2021 09:15:41 +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 4HSY7070MXz3Mtq; Mon, 11 Oct 2021 09:15:40 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (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 E4BE1260483; Mon, 11 Oct 2021 11:15:31 +0200 (CEST) To: "freebsd-arch@freebsd.org" , John Baldwin From: Hans Petter Selasky Subject: ifp->if_capabilities needs to grow Message-ID: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> Date: Mon, 11 Oct 2021 11:15:19 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HSY7070MXz3Mtq 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]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; 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-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Hi, As part of ongoing TLS RX work, it has become apparent that if_capabilities and if_capenable needs to grow to 64-bits at least. Right now those fields are 32-bits, and are fully utilized. The question is how this can be implemented so that a MFC to 13-stable is possible. The most simple solution is to substitute "int" by "uint64_t", but that will break the ABI. Another solution is to use an array of "int" variables. A third solution is to abandon the two fields when MFC-ing, and adding two new 64-bit fields in the end of the ifnet. Also the user-space API for ifconfig is subject to change. --HPS From nobody Mon Oct 11 17:10:27 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 23FE617E0587 for ; Mon, 11 Oct 2021 17:10:31 +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 4HSlft37Qzz4ZQs; Mon, 11 Oct 2021 17:10:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (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 A9F371321; Mon, 11 Oct 2021 17:10:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Hans Petter Selasky , "freebsd-arch@freebsd.org" References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> From: John Baldwin Subject: Re: ifp->if_capabilities needs to grow Message-ID: <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> Date: Mon, 11 Oct 2021 10:10:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 10/11/21 2:15 AM, Hans Petter Selasky wrote: > Hi, > > As part of ongoing TLS RX work, it has become apparent that > if_capabilities and if_capenable needs to grow to 64-bits at least. > > Right now those fields are 32-bits, and are fully utilized. > > The question is how this can be implemented so that a MFC to 13-stable > is possible. > > The most simple solution is to substitute "int" by "uint64_t", but that > will break the ABI. It breaks the kernel and userland ABIs, and for ifreq it is not easy to notice as the size of ifreq wouldn't change. > Another solution is to use an array of "int" variables. > > A third solution is to abandon the two fields when MFC-ing, and adding > two new 64-bit fields in the end of the ifnet. > > Also the user-space API for ifconfig is subject to change. One option is to perhaps add 'if_cap*2' with IFCAP2_* bits. It would be MFC'able (just add the new words at the end in the MFC), it's just a bit ugly compared to having an array. The other question is how to manage the ioctl. Right now the ioctl is an ifreq which takes a pair of ints (if_reqcap and if_curcap). If we use 'if_cap*2' then we can just add SIOCGIFCAP2 and SIOCSIFCAP2 to get/set the second words. We have done this with other fields (e.g. p_flag2). My only worry is that we are adding new bits at an increasing rate and that the need for IFCAP3_* might not be that far off. If we add new ioctls that use ifr_buffer then it's easier to support adding new words in the future. It would also allow fetching all of the capabilities in one ioctl. For these ioctls I would suggest using ifr_buffer where 'buffer' points to an array of integers. SIOCSIFCAPARRAY would point 'buffer' at the array of new capabiltiies. SIOGSIFCAPARRAY would point 'buffer' at an array of 2x the number of integers. (So it would be an error for 'length' to not be a multiple of 2 * sizeof(int).) The first half of the array would return if_capabilities bits (equivalent to if_reqcap today), the second half would return the if_capenable bits (equivalent to if_curcap today). The existing ioctls would just return the first words. If we were to use arrays for the ioctls, the kernel could either switch to arrays in struct ifnet (harder to MFC), or just add the new if_cap*2 fields and populate the arrays for the userland buffer based on those. -- John Baldwin From nobody Mon Oct 11 17:14:26 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 6A20317E13E1 for ; Mon, 11 Oct 2021 17:14:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSllY1MX2z4bfb; Mon, 11 Oct 2021 17:14:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19BHEQ7Q007959 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 11 Oct 2021 20:14:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19BHEQ7Q007959 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19BHEQRn007958; Mon, 11 Oct 2021 20:14:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Oct 2021 20:14:26 +0300 From: Konstantin Belousov To: John Baldwin Cc: Hans Petter Selasky , "freebsd-arch@freebsd.org" Subject: Re: ifp->if_capabilities needs to grow Message-ID: References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HSllY1MX2z4bfb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Oct 11, 2021 at 10:10:27AM -0700, John Baldwin wrote: > On 10/11/21 2:15 AM, Hans Petter Selasky wrote: > > Hi, > > > > As part of ongoing TLS RX work, it has become apparent that > > if_capabilities and if_capenable needs to grow to 64-bits at least. > > > > Right now those fields are 32-bits, and are fully utilized. > > > > The question is how this can be implemented so that a MFC to 13-stable > > is possible. > > > > The most simple solution is to substitute "int" by "uint64_t", but that > > will break the ABI. > > It breaks the kernel and userland ABIs, and for ifreq it is not easy to > notice as the size of ifreq wouldn't change. > > > Another solution is to use an array of "int" variables. > > > > A third solution is to abandon the two fields when MFC-ing, and adding > > two new 64-bit fields in the end of the ifnet. > > > > Also the user-space API for ifconfig is subject to change. > > One option is to perhaps add 'if_cap*2' with IFCAP2_* bits. It would > be MFC'able (just add the new words at the end in the MFC), it's just a > bit ugly compared to having an array. The other question is how to manage > the ioctl. Right now the ioctl is an ifreq which takes a pair of ints > (if_reqcap and if_curcap). If we use 'if_cap*2' then we can just add > SIOCGIFCAP2 and SIOCSIFCAP2 to get/set the second words. We have done > this with other fields (e.g. p_flag2). > > My only worry is that we are adding new bits at an increasing rate and > that the need for IFCAP3_* might not be that far off. If we add new > ioctls that use ifr_buffer then it's easier to support adding new words > in the future. It would also allow fetching all of the capabilities in > one ioctl. For these ioctls I would suggest using ifr_buffer where > 'buffer' points to an array of integers. SIOCSIFCAPARRAY would point > 'buffer' at the array of new capabiltiies. SIOGSIFCAPARRAY would point > 'buffer' at an array of 2x the number of integers. (So it would be an > error for 'length' to not be a multiple of 2 * sizeof(int).) The first > half of the array would return if_capabilities bits (equivalent to > if_reqcap today), the second half would return the if_capenable bits > (equivalent to if_curcap today). The existing ioctls would just return > the first words. > > If we were to use arrays for the ioctls, the kernel could either switch > to arrays in struct ifnet (harder to MFC), or just add the new if_cap*2 > fields and populate the arrays for the userland buffer based on those. Might be it is time to switch to TLV/nvlists there? From nobody Mon Oct 11 17:48:54 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 2B18317FB8B7 for ; Mon, 11 Oct 2021 17:49:03 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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 "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSmWL6LxLz4qBw; Mon, 11 Oct 2021 17:49:02 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 19BHmsco030524 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 11 Oct 2021 10:48:54 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 19BHmsgo030523; Mon, 11 Oct 2021 10:48:54 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 11 Oct 2021 10:48:54 -0700 From: Gleb Smirnoff To: Hans Petter Selasky Cc: "freebsd-arch@freebsd.org" , John Baldwin Subject: Re: ifp->if_capabilities needs to grow Message-ID: References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> X-Rspamd-Queue-Id: 4HSmWL6LxLz4qBw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hans, On Mon, Oct 11, 2021 at 11:15:19AM +0200, Hans Petter Selasky wrote: H> As part of ongoing TLS RX work, it has become apparent that H> if_capabilities and if_capenable needs to grow to 64-bits at least. H> H> Right now those fields are 32-bits, and are fully utilized. H> H> The question is how this can be implemented so that a MFC to 13-stable H> is possible. H> H> The most simple solution is to substitute "int" by "uint64_t", but that H> will break the ABI. H> H> Another solution is to use an array of "int" variables. H> H> A third solution is to abandon the two fields when MFC-ing, and adding H> two new 64-bit fields in the end of the ifnet. H> H> Also the user-space API for ifconfig is subject to change. Is there any way to shrink the current list? 1) Is there any NIC that does IFCAP_RXCSUM but can't do IFCAP_TXCSUM? 2) Is there any NIC that IFCAP_TXTLS4 but can't do IFCAP_TXTLS6? 3) All three of IFCAP_WOL_* should belong to 'struct ieee80211com' not to 'struct ifnet'. 4) There are some features that can't be controlled with ifconfig, so don't need to be exported to userland, thus can move to a different field, e.g. "if_capabilities_internal". These include: IFCAP_NETMAP, IFCAP_HWSTATS. It should include IFCAP_MEXTPG but for some reason it is user-controlled. I believe this can be dropped since we already consider mextpgs a seasoned stable feature. I think this list can be made longer. So at least utilizing 4) will give you 3 bits that can be MFCed. -- Gleb Smirnoff From nobody Tue Oct 12 09:20:11 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 8F88618076AF for ; Tue, 12 Oct 2021 09:20:29 +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 4HT9B53BVGz3rGy; Tue, 12 Oct 2021 09:20:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (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)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8478C260245; Tue, 12 Oct 2021 11:20:22 +0200 (CEST) Subject: Re: ifp->if_capabilities needs to grow To: John Baldwin , "freebsd-arch@freebsd.org" References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> From: Hans Petter Selasky Message-ID: <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.org> Date: Tue, 12 Oct 2021 11:20:11 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HT9B53BVGz3rGy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Hi John, Konstantin and Gleb, There are basically three ways to solve the problem with adding TLSRX4 and TLSRX6 capability bits. 1) Konstantin proposes to merge the API to nvlists. 2) John proposes to duplicate XXXCAP into XXXCAP2 to handle the new capabilities. 3) Gleb proposes to free up existing bits. Looking at the different proposals I think John has the best one with regards to MFC'ing. Then we don't change the meaning of any bits, and the old ifconfig still works as expected. It's trivial to add a XXXCAP2 to ifconfig from what I can see. It already modifying bit by bit, so no optimisations in there anyways. Do we have consensus? --HPS On 10/11/21 7:10 PM, John Baldwin wrote: > One option is to perhaps add 'if_cap*2' with IFCAP2_* bits.  It would > be MFC'able (just add the new words at the end in the MFC), it's just a > bit ugly compared to having an array.  The other question is how to manage > the ioctl.  Right now the ioctl is an ifreq which takes a pair of ints > (if_reqcap and if_curcap).  If we use 'if_cap*2' then we can just add > SIOCGIFCAP2 and SIOCSIFCAP2 to get/set the second words.  We have done > this with other fields (e.g. p_flag2). From nobody Tue Oct 12 10:43:41 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 A565A17F6046 for ; Tue, 12 Oct 2021 10:43:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTC2D2SVlz4kKM; Tue, 12 Oct 2021 10:43:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19CAhf0f070746 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Oct 2021 13:43:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19CAhf0f070746 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19CAhf1g070745; Tue, 12 Oct 2021 13:43:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Oct 2021 13:43:41 +0300 From: Konstantin Belousov To: Hans Petter Selasky Cc: John Baldwin , "freebsd-arch@freebsd.org" Subject: Re: ifp->if_capabilities needs to grow Message-ID: References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.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: <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HTC2D2SVlz4kKM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 12, 2021 at 11:20:11AM +0200, Hans Petter Selasky wrote: > Hi John, Konstantin and Gleb, > > There are basically three ways to solve the problem with adding TLSRX4 and > TLSRX6 capability bits. > > 1) Konstantin proposes to merge the API to nvlists. To make it clear. I do not propose to remove old ioctls. Just that in parallel to old way, a new nvlist-based ioctl would be added that has no limitation on the number of supported capabilities, by design. Old ifconfig continues to work, same as in scheme with XXXCAP2, but it kind of guarantees that we would not need XXXCAP3 ever. > > 2) John proposes to duplicate XXXCAP into XXXCAP2 to handle the new > capabilities. > > 3) Gleb proposes to free up existing bits. > > Looking at the different proposals I think John has the best one with > regards to MFC'ing. Then we don't change the meaning of any bits, and the > old ifconfig still works as expected. > > It's trivial to add a XXXCAP2 to ifconfig from what I can see. It already > modifying bit by bit, so no optimisations in there anyways. > > Do we have consensus? > > --HPS > > On 10/11/21 7:10 PM, John Baldwin wrote: > > One option is to perhaps add 'if_cap*2' with IFCAP2_* bits.  It would > > be MFC'able (just add the new words at the end in the MFC), it's just a > > bit ugly compared to having an array.  The other question is how to manage > > the ioctl.  Right now the ioctl is an ifreq which takes a pair of ints > > (if_reqcap and if_curcap).  If we use 'if_cap*2' then we can just add > > SIOCGIFCAP2 and SIOCSIFCAP2 to get/set the second words.  We have done > > this with other fields (e.g. p_flag2). > From nobody Tue Oct 12 11:14:06 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 9634017ED988 for ; Tue, 12 Oct 2021 11:14:20 +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 4HTCjS3GTTz4t0v; Tue, 12 Oct 2021 11:14:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (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)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8E15A260245; Tue, 12 Oct 2021 13:14:18 +0200 (CEST) Subject: Re: ifp->if_capabilities needs to grow To: Konstantin Belousov Cc: John Baldwin , "freebsd-arch@freebsd.org" References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.org> From: Hans Petter Selasky Message-ID: <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.org> Date: Tue, 12 Oct 2021 13:14:06 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HTCjS3GTTz4t0v X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Hi Konstantin, It took 20 years to reach ifcap2 . Can we assume that it will take another 20 years to reach ifcap3 ? --HPS On 10/12/21 12:43 PM, Konstantin Belousov wrote: > On Tue, Oct 12, 2021 at 11:20:11AM +0200, Hans Petter Selasky wrote: >> Hi John, Konstantin and Gleb, >> >> There are basically three ways to solve the problem with adding TLSRX4 and >> TLSRX6 capability bits. >> >> 1) Konstantin proposes to merge the API to nvlists. > To make it clear. I do not propose to remove old ioctls. > Just that in parallel to old way, a new nvlist-based ioctl would be added > that has no limitation on the number of supported capabilities, by design. > Old ifconfig continues to work, same as in scheme with XXXCAP2, but it > kind of guarantees that we would not need XXXCAP3 ever. > >> >> 2) John proposes to duplicate XXXCAP into XXXCAP2 to handle the new >> capabilities. >> >> 3) Gleb proposes to free up existing bits. >> >> Looking at the different proposals I think John has the best one with >> regards to MFC'ing. Then we don't change the meaning of any bits, and the >> old ifconfig still works as expected. >> >> It's trivial to add a XXXCAP2 to ifconfig from what I can see. It already >> modifying bit by bit, so no optimisations in there anyways. >> >> Do we have consensus? >> >> --HPS >> >> On 10/11/21 7:10 PM, John Baldwin wrote: >>> One option is to perhaps add 'if_cap*2' with IFCAP2_* bits.  It would >>> be MFC'able (just add the new words at the end in the MFC), it's just a >>> bit ugly compared to having an array.  The other question is how to manage >>> the ioctl.  Right now the ioctl is an ifreq which takes a pair of ints >>> (if_reqcap and if_curcap).  If we use 'if_cap*2' then we can just add >>> SIOCGIFCAP2 and SIOCSIFCAP2 to get/set the second words.  We have done >>> this with other fields (e.g. p_flag2). >> > From nobody Tue Oct 12 11:18:35 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 9013F17EF1C4 for ; Tue, 12 Oct 2021 11:18:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTCpW13b1z4tmv; Tue, 12 Oct 2021 11:18:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19CBIZjO079528 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Oct 2021 14:18:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19CBIZjO079528 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19CBIZQt079527; Tue, 12 Oct 2021 14:18:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Oct 2021 14:18:35 +0300 From: Konstantin Belousov To: Hans Petter Selasky Cc: John Baldwin , "freebsd-arch@freebsd.org" Subject: Re: ifp->if_capabilities needs to grow Message-ID: References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.org> <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.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: <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HTCpW13b1z4tmv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 12, 2021 at 01:14:06PM +0200, Hans Petter Selasky wrote: > Hi Konstantin, > > It took 20 years to reach ifcap2 . Can we assume that it will take another > 20 years to reach ifcap3 ? As John noted, we are accelerating the process. Besides TLS RX, we might have something like IPSEC_INLINE soon. As for inline IPSEC, we need to communicate the set of supported algorithms, which would require additional ioctl unless we switch (add advanced version of) CAP to use something more flexible. > > --HPS > > On 10/12/21 12:43 PM, Konstantin Belousov wrote: > > On Tue, Oct 12, 2021 at 11:20:11AM +0200, Hans Petter Selasky wrote: > > > Hi John, Konstantin and Gleb, > > > > > > There are basically three ways to solve the problem with adding TLSRX4 and > > > TLSRX6 capability bits. > > > > > > 1) Konstantin proposes to merge the API to nvlists. > > To make it clear. I do not propose to remove old ioctls. > > Just that in parallel to old way, a new nvlist-based ioctl would be added > > that has no limitation on the number of supported capabilities, by design. > > Old ifconfig continues to work, same as in scheme with XXXCAP2, but it > > kind of guarantees that we would not need XXXCAP3 ever. > > > > > > > > 2) John proposes to duplicate XXXCAP into XXXCAP2 to handle the new > > > capabilities. > > > > > > 3) Gleb proposes to free up existing bits. > > > > > > Looking at the different proposals I think John has the best one with > > > regards to MFC'ing. Then we don't change the meaning of any bits, and the > > > old ifconfig still works as expected. > > > > > > It's trivial to add a XXXCAP2 to ifconfig from what I can see. It already > > > modifying bit by bit, so no optimisations in there anyways. > > > > > > Do we have consensus? > > > > > > --HPS > > > > > > On 10/11/21 7:10 PM, John Baldwin wrote: > > > > One option is to perhaps add 'if_cap*2' with IFCAP2_* bits.  It would > > > > be MFC'able (just add the new words at the end in the MFC), it's just a > > > > bit ugly compared to having an array.  The other question is how to manage > > > > the ioctl.  Right now the ioctl is an ifreq which takes a pair of ints > > > > (if_reqcap and if_curcap).  If we use 'if_cap*2' then we can just add > > > > SIOCGIFCAP2 and SIOCSIFCAP2 to get/set the second words.  We have done > > > > this with other fields (e.g. p_flag2). > > > > > From nobody Sat Oct 23 04:13:35 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 63E7518124C1 for ; Sat, 23 Oct 2021 04:13:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 4Hbns65Kwpz3QZM for ; Sat, 23 Oct 2021 04:13:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x929.google.com with SMTP id h4so11506236uaw.1 for ; Fri, 22 Oct 2021 21:13:46 -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=3DNVaeZufSgjQcYSoMGHHjUm+ApnKMU25EK3ML4VFu4=; b=iz3OVBFiNTbFpd1h4xz48dhko3LTUnUkWJn0PNXjgmQMYqqwAE836JRhNeSJ7jDK8G VyPBU27vlFYiNqP20aG/2VC6YgLCYCxJWpTcTHSLsr2t3ZvcTomOlaEx8dcHkYQIFfNx Hnn2TNL+gRF2DP5Huy/VyQu0lPKr171pdViBmrlXWrCv66VonSt3hRccoc8+cZWURYvD cl3AaLOTcWhdhejIVZpWb0CPZSjCNU7dMMN67M3n9UZ2It7bu2Ga7ozcqFbx42KreilZ HcivISNGl0D/sngAh6cOJfO1qKmZoGBmr/CKxF8TLQhpthbaNFATq/hOx2TbaM4XXUtz EuIw== 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=3DNVaeZufSgjQcYSoMGHHjUm+ApnKMU25EK3ML4VFu4=; b=eayNAJU43NxSMRlG4NZf9/de+yKLN2YMaaTtslADoUisRfFc604GiJ6mSeYbziI+8f EGUEu/qNS6lSmxcvEd0ujHRPoxIU4tz/Ti2ygVPDH6iXubuwDiL+6IqBeqN7r3HS7e2i B1tRucFk9tb+PQj3/oCVKZ74uXzcS8RAWP1C4pXUSFyYissCiPKFzuf+AP4UNvrwplAE Qlr7WbWjzEco3HK0Q+L6jPkIrk8OpZLEK54M3aU3+EIGSsM2Gu5TAoJTgleID1FuhMDm XzRzQUp182CKqzJde+Oq1y8KS1vgqJ5sGnLLnP/kUKC8j8hMYVOzE/C9iowDu13vjMN/ TWdQ== X-Gm-Message-State: AOAM532Z+BwPiPxjz2ugsBE6aaC/Z1PjHnmRwOHkrRFtEiSK8FH6LU3w anqEGCi1QzC1awO2xTqOAOjyomUfa5hqF3Qd5xQpWDoi9Qk= X-Google-Smtp-Source: ABdhPJxn8/88kriEgr9vuRiqjpjRREhwKj2Zm1czVd94OHBGM9rfvCAb3k5B6DS8anQYMowKCz58/ZD5rb7m+Ou8FQo= X-Received: by 2002:a67:fc8b:: with SMTP id x11mr4691460vsp.12.1634962425910; Fri, 22 Oct 2021 21:13: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: Warner Losh Date: Fri, 22 Oct 2021 22:13:35 -0600 Message-ID: Subject: Re: Draft License Policy Changes for SPDX To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000009e2cfa05cefd5aea" X-Rspamd-Queue-Id: 4Hbns65Kwpz3QZM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=iz3OVBFi; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::929) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.31 / 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(-0.99)[-0.989]; 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.32)[-0.324]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::929: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 --0000000000009e2cfa05cefd5aea Content-Type: text/plain; charset="UTF-8" Hello, I plan on moving forward with this and will find competent legal review in appropriate locations. I will be back once that's complete with a summary of any changes required. Warner On Fri, Sep 10, 2021 at 8:24 AM Warner Losh wrote: > Greetings, > > I've been circulating a draft project policy expanding SPDX license > marking in the base system. Most projects in the open source world have > moved to having a copyright and SPDX-License-Identifier in the source files > (aka SPDX-only files) with the license understood from context, policy and > industry practice. The goal of my draft is to allow SPDX-only files, while > coping with our long legacy. I'm also trying to consolidate multiple > policy-like statements in our documentation into one place. > > Originally, we had a license in every file and there was a fair amount of > variation between them. A few years ago we started marking some files with > SPDX-License-Identifier lines to assist automated tools discovering > licenses. In addition, the ports license infrastructure uses these > identifiers for third party software that we install there. Even without a > formal policy, several SPDX-only files exist in base imported from other > projects. > > The draft policy formalizes our current practices. It updates the > project's policy to explicitly allow SPDX-only files. It documents industry > and FreeBSD project practice. Hundreds of other open source projects have > been using it for years. The FreeBSD project has had SPDX-only files for > many years. A formal policy for how to interpret SPDX-only markings will > provide clarity and improve certainty about their meaning. > > I've consulted with many people that have experience integrating software > into FreeBSD with some knowledge of licenses. I've also talked to the SPDX > lawyers for their justification for SDPX-only as well as what we do for our > mixed situation. I've chatted informally with an IP lawyer not connected > with SPDX for their views. I've surveyed other projects for what they do. > All of this has informed the draft. > > The summary of the changes are actually rather simple: > 1. If a file has both a SPDX-License-Identifier and the full text of a > license, the full text takes precedence. > 2. If a file has only SDPX-only, then the license text is from the SPDX > database with details on how to fill in the blanks if needed. > 3. Do not move any full-text or mixed files in the tree to SPDX-only > unless you are the copyright holder or acting on their behalf. > > I've created a review for the policy. https://reviews.freebsd.org/D29543 > has the changes for the new policy. As we'll want to check copies of the > text of the licenses into the tree for compliance with SPDX and adjacent > standards, I'll prepare a diff for that too once things are a bit more > along. > > I'm calling for feedback before I give this to the lawyers to approve. I'd > thought I had a lawyer lined up to review this over the summer, but that > seems to have fallen through. I'm lining up someone new in parallel. > There's an outstanding issue around slight wording differences between our > license and the SPDX database that I need to resolve with the lawyer, as > well as having them review the policy so that it's unambiguous how one > discovers the license for an SPDX-only file. > > Information about the SPDX project can be found at https://spdx.org. The > specification can be found at https://spdx.github.io/spdx-spec/. > > Thanks! > > Warner > > P.S. SDPX is now an ISO standard! It was approved yesterday: > https://www.linuxfoundation.org/press-release/spdx-becomes-internationally-recognized-standard-for-software-bill-of-materials > has more information. > --0000000000009e2cfa05cefd5aea-- From nobody Tue Oct 26 03:00:22 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 20460181C595; Tue, 26 Oct 2021 03:00:24 +0000 (UTC) (envelope-from jrm@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 4Hdc54080sz3qPs; Tue, 26 Oct 2021 03:00:24 +0000 (UTC) (envelope-from jrm@freebsd.org) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-187-65.dhcp-dynamic.fibreop.ns.bellaliant.net [156.34.187.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jrm/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id AA3ACAFDD; Tue, 26 Oct 2021 03:00:23 +0000 (UTC) (envelope-from jrm@freebsd.org) From: Joseph Mingrone To: freebsd-advocacy@freebsd.org, freebsd-arch@freebsd.org Subject: RISC-V Mentorship Program Date: Tue, 26 Oct 2021 00:00:22 -0300 Message-ID: <86mtmwv6bd.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) 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; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain Hello FreeBSD community, As a RISC-V member organization, we are eligible to submit an application to the upcoming RISC-V mentorship program. You can read about the program at https://riscv.org/risc-v-mentorship-program/. We are looking for people interested in mentoring and project ideas. The November 19 deadline is fast approaching, so if this interests you, please reply soon. We have benefited from Google Summer of Code, especially by attracting new developers, so hopefully this can also be another successful program for us. Joe --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKkBAEBCgCOFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAmF3b0ZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUQHGpybUBmcmVl YnNkLm9yZwAKCRA2pAyDsNbvnrHkD/9Qf0XTN15ix3mGXLRixb6y2XFlJJPd9dJl XQG2sTnBOnynRVeieYv6Na6MiI3RC+fOeOOCAft7MhuF5au9IRWG/zdpNjXK58tE dvUrMSbRdjmnmtSswvMVYGkxj+rntJfDonM71WCqKXvHxa8CczVkdWCe3p/ahTVT SZgFppETq+hEEZGUntSHSWlSqrFg73bHBVTHdTRqnlByKCO1i9b3PLafjhG0TXpI F5IlhMwMql3WdLxJH2Yc1wokKBvjQZuf8wH4slrC3PRFXfyFyA4WkbR3/2Mo9+6n ZL5sQ0suimAXabx53cFCajWd0gDYKtVv67luADj2D9kkh5KgTJ9hh+6jdik0p/AC CUNBcaqNxavSD4Jcv8UwjiQmyEkJBrIU8s2p+5+ZaB9+rd7uqITOPMa0iNYvaSdi pK5rbo3WfzhuFhXAAq3PYhz/BJHGrf3oghxt8jTRpNIYIj1fvll+jASjZ/WVA2LH bKzY4GwE0j7ygamaTBUXLIUcWnuoTvu2e1svsh0bR06Du6dmwojU7XY6MJ0Z/7gl XFvPBowae3HkJX9t9jKQsuoZrLdErIEPrMp3dYwLqm92OqdsFzR128RSdihCN5Ek Xh0FJdIEijD+mEqKyJZI33kcqsVN2J4fn7ntG3D9WzRNwwx9QQjaWD2W4UxEhzyV G6C1zoZCnA== =hUO0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 27 01:52:21 2021 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 5FDE91834CE8 for ; Wed, 27 Oct 2021 01:52:24 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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 "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfBX762kWz4bZg; Wed, 27 Oct 2021 01:52:23 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 19R1qLdU012607 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Oct 2021 18:52:22 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 19R1qLhn012606; Tue, 26 Oct 2021 18:52:21 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 26 Oct 2021 18:52:21 -0700 From: Gleb Smirnoff To: kib@freebsd.org, mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org Cc: arch@freebsd.org Subject: rwlock(9) and mutex(9) definitions 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: 4HfBX762kWz4bZg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US] X-ThisMailContainsUnwantedMimeParts: N Hi, [To: list constructed with help of git blame] despite manual pages describe locking functions as voids in reality some of them (not all) are preprocessor defines wrapped in "do {} while (0)". Such wraps don't really behave as a true void. For example you can not tail call them: void smartass_lock(lock, clue) { if (clue) return (rw_rlock(lock)); else return (rw_wlock(lock)); } This will fail on rw_wlock, but not on rw_rlock. However, if you have WITNESS it will compile correctly :) So, we need either make these function "static inline void" in mtx.h and rwlock.h, or wrap them in __extension__ ({ }). Btw, the latter is already done for mtx_trylock_spin() by kib in 90b581f2cc327. Of course for try-lock functions inability of tail call is a bigger issue then for voids. However, voids should be fixed as well, I believe. Your call? "static inline" or "__extension__ ({ })"? -- Gleb Smirnoff From nobody Wed Oct 27 02:03:50 2021 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 94B4918109D2 for ; Wed, 27 Oct 2021 02:03:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfBnW1xqXz4dtc; Wed, 27 Oct 2021 02:03:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19R23oAQ014574 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Oct 2021 05:03:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19R23oAQ014574 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19R23o8X014573; Wed, 27 Oct 2021 05:03:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Oct 2021 05:03:50 +0300 From: Konstantin Belousov To: Gleb Smirnoff Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HfBnW1xqXz4dtc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 26, 2021 at 06:52:21PM -0700, Gleb Smirnoff wrote: > Hi, > > [To: list constructed with help of git blame] > > despite manual pages describe locking functions as voids in > reality some of them (not all) are preprocessor defines wrapped > in "do {} while (0)". > > Such wraps don't really behave as a true void. For example you > can not tail call them: > > void > smartass_lock(lock, clue) > { > if (clue) > return (rw_rlock(lock)); > else > return (rw_wlock(lock)); > } > > This will fail on rw_wlock, but not on rw_rlock. However, if you > have WITNESS it will compile correctly :) > > So, we need either make these function "static inline void" in > mtx.h and rwlock.h, or wrap them in __extension__ ({ }). Btw, the > latter is already done for mtx_trylock_spin() by kib in 90b581f2cc327. > Of course for try-lock functions inability of tail call is a bigger > issue then for voids. However, voids should be fixed as well, I believe. > > Your call? "static inline" or "__extension__ ({ })"? Usually defines are easier. For static inline functions, compiler parses and validates the definition regardless of its use. So for instance if the header is included into userspace compilation consumers, static inlines break. If not that, providing real parseable definitions are better on all other counters. From nobody Wed Oct 27 02:06:52 2021 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 5BC0F1812799 for ; Wed, 27 Oct 2021 02:07:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfBrz3b14z4fyX; Wed, 27 Oct 2021 02:06:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19R26qeh015756 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Oct 2021 05:06:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19R26qeh015756 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19R26qeK015755; Wed, 27 Oct 2021 05:06:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Oct 2021 05:06:52 +0300 From: Konstantin Belousov To: Gleb Smirnoff Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HfBrz3b14z4fyX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-0.09 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_LONG(-0.48)[-0.477]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_SPAM_MEDIUM(0.26)[0.260]; NEURAL_SPAM_SHORT(0.13)[0.130]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Wed, Oct 27, 2021 at 05:03:56AM +0300, Konstantin Belousov wrote: > On Tue, Oct 26, 2021 at 06:52:21PM -0700, Gleb Smirnoff wrote: > > Hi, > > > > [To: list constructed with help of git blame] > > > > despite manual pages describe locking functions as voids in > > reality some of them (not all) are preprocessor defines wrapped > > in "do {} while (0)". > > > > Such wraps don't really behave as a true void. For example you > > can not tail call them: > > > > void > > smartass_lock(lock, clue) > > { > > if (clue) > > return (rw_rlock(lock)); > > else > > return (rw_wlock(lock)); > > } > > > > This will fail on rw_wlock, but not on rw_rlock. However, if you > > have WITNESS it will compile correctly :) > > > > So, we need either make these function "static inline void" in > > mtx.h and rwlock.h, or wrap them in __extension__ ({ }). Btw, the > > latter is already done for mtx_trylock_spin() by kib in 90b581f2cc327. > > Of course for try-lock functions inability of tail call is a bigger > > issue then for voids. However, voids should be fixed as well, I believe. > > > > Your call? "static inline" or "__extension__ ({ })"? > > Usually defines are easier. For static inline functions, compiler parses > and validates the definition regardless of its use. So for instance if > the header is included into userspace compilation consumers, static inlines > break. > > If not that, providing real parseable definitions are better on all other > counters. That said, you seems to use wrong syntax for your example. Might be, it is enough to fix that, and not change the definition? void something(bool clue) { if (clue) { rw_rlock(lock); else rw_wlock(lock); } Both rw_rlock and rw_wlock are in tail context. You cannot _return_ void. From nobody Wed Oct 27 04:17:27 2021 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 9399D182644E for ; Wed, 27 Oct 2021 04:17:29 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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 "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfFlY15SGz3DH1; Wed, 27 Oct 2021 04:17:29 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 19R4HRm7013172 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Oct 2021 21:17:27 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 19R4HRii013171; Tue, 26 Oct 2021 21:17:27 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 26 Oct 2021 21:17:27 -0700 From: Gleb Smirnoff To: Konstantin Belousov Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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: 4HfFlY15SGz3DH1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Oct 27, 2021 at 05:06:52AM +0300, Konstantin Belousov wrote: K> > counters. K> K> That said, you seems to use wrong syntax for your example. Might be, it K> is enough to fix that, and not change the definition? K> K> void K> something(bool clue) K> { K> if (clue) { K> rw_rlock(lock); K> else K> rw_wlock(lock); K> } K> Both rw_rlock and rw_wlock are in tail context. You cannot _return_ void. You actually can return void to hint compiler for a tail call optimization. It is not a wrong syntax. Other code that is working with true void functions (e.g. with WITNESS) and doesn't work with "do {} while" is: void something(bool clue) { return (clue ? rw_rlock(lock) : rw_wlock(lock)); } This is explicitly allowed in 6.5.15 of the C11 standard. Of course all this code can be written in some other way, so constraint of KPI not being true functions can be worked around, but I believe better it be fixed. -- Gleb Smirnoff From nobody Wed Oct 27 04:39:38 2021 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 43530182F28B for ; Wed, 27 Oct 2021 04:39:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfGFH3xP2z3Jlm; Wed, 27 Oct 2021 04:39:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19R4dclQ052998 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Oct 2021 07:39:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19R4dclQ052998 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19R4dc0M052997; Wed, 27 Oct 2021 07:39:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Oct 2021 07:39:38 +0300 From: Konstantin Belousov To: Gleb Smirnoff Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HfGFH3xP2z3Jlm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 26, 2021 at 09:17:27PM -0700, Gleb Smirnoff wrote: > On Wed, Oct 27, 2021 at 05:06:52AM +0300, Konstantin Belousov wrote: > K> > counters. > K> > K> That said, you seems to use wrong syntax for your example. Might be, it > K> is enough to fix that, and not change the definition? > K> > K> void > K> something(bool clue) > K> { > K> if (clue) { > K> rw_rlock(lock); > K> else > K> rw_wlock(lock); > K> } > K> Both rw_rlock and rw_wlock are in tail context. You cannot _return_ void. > > You actually can return void to hint compiler for a tail call optimization. > It is not a wrong syntax. > > Other code that is working with true void functions (e.g. with WITNESS) and > doesn't work with "do {} while" is: > > void > something(bool clue) > { > return (clue ? rw_rlock(lock) : rw_wlock(lock)); > } > > This is explicitly allowed in 6.5.15 of the C11 standard. > > Of course all this code can be written in some other way, so constraint > of KPI not being true functions can be worked around, but I believe better > it be fixed. Hum. I know about ternary operator allowing void-typed expressions on both sides of ':'. What I replied to is the following, from C17 6.8.6.4 The return statement Constraints 1 A return statement with an expression shall not appear in a function whose return type is void. A return statement without an expression shall only appear in a function whose return type is void. So syntax above is explicitly prohibited by the standard. I was quite surprised that both gcc and clang silently accept this, unless -pedantic is specified. There is no mention of this extension in gcc manual. Compiler explorer demonstrates that compilers like msvc do warn about the construct, and some even error out (tendra): https://godbolt.org/z/xqcPssTcY Another part of the confusion, perhaps, is that return ; is explicitly allowed by the C++ standard (I looked at 2020 version), unlike C. From nobody Wed Oct 27 04:49:58 2021 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 6CE971833293 for ; Wed, 27 Oct 2021 04:50:00 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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 "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfGT40YC3z3Mg8; Wed, 27 Oct 2021 04:49:59 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 19R4nwWC013322 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Oct 2021 21:49:58 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 19R4nwNj013321; Tue, 26 Oct 2021 21:49:58 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 26 Oct 2021 21:49:58 -0700 From: Gleb Smirnoff To: Konstantin Belousov Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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: 4HfGT40YC3z3Mg8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Oct 27, 2021 at 07:39:38AM +0300, Konstantin Belousov wrote: K> > K> Both rw_rlock and rw_wlock are in tail context. You cannot _return_ void. K> > K> > You actually can return void to hint compiler for a tail call optimization. K> > It is not a wrong syntax. K> > K> > Other code that is working with true void functions (e.g. with WITNESS) and K> > doesn't work with "do {} while" is: K> > K> > void K> > something(bool clue) K> > { K> > return (clue ? rw_rlock(lock) : rw_wlock(lock)); K> > } K> > K> > This is explicitly allowed in 6.5.15 of the C11 standard. K> > K> > Of course all this code can be written in some other way, so constraint K> > of KPI not being true functions can be worked around, but I believe better K> > it be fixed. K> K> Hum. I know about ternary operator allowing void-typed expressions on both K> sides of ':'. What I replied to is the following, from C17 K> K> 6.8.6.4 The return statement K> Constraints K> 1 A return statement with an expression shall not appear in a function K> whose return type is void. A return statement without an expression K> shall only appear in a function whose return type is void. K> K> So syntax above is explicitly prohibited by the standard. I was quite K> surprised that both gcc and clang silently accept this, unless -pedantic K> is specified. There is no mention of this extension in gcc manual. K> Compiler explorer demonstrates that compilers like msvc do warn about K> the construct, and some even error out (tendra): K> https://godbolt.org/z/xqcPssTcY K> K> Another part of the confusion, perhaps, is that K> return ; K> is explicitly allowed by the C++ standard (I looked at 2020 version), K> unlike C. Hmm, so I mistakenly transferred my knowledge about the tail call optimization hint from C++ to C. Okay, let's put return aside. This would compile with true functions (e.g. WITNESS), otherwise not: void something(bool clue) { clue ? rw_rlock(lock) : rw_wlock(lock); } And this is correct code per 6.5.15. -- Gleb Smirnoff From nobody Wed Oct 27 05:11:13 2021 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 DABB51812CE6 for ; Wed, 27 Oct 2021 05:11:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfGxj3wn3z3hTf; Wed, 27 Oct 2021 05:11:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19R5BDoC061587 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Oct 2021 08:11:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19R5BDoC061587 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19R5BDFX061586; Wed, 27 Oct 2021 08:11:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Oct 2021 08:11:13 +0300 From: Konstantin Belousov To: Gleb Smirnoff Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HfGxj3wn3z3hTf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 26, 2021 at 09:49:58PM -0700, Gleb Smirnoff wrote: > On Wed, Oct 27, 2021 at 07:39:38AM +0300, Konstantin Belousov wrote: > K> > K> Both rw_rlock and rw_wlock are in tail context. You cannot _return_ void. > K> > > K> > You actually can return void to hint compiler for a tail call optimization. > K> > It is not a wrong syntax. > K> > > K> > Other code that is working with true void functions (e.g. with WITNESS) and > K> > doesn't work with "do {} while" is: > K> > > K> > void > K> > something(bool clue) > K> > { > K> > return (clue ? rw_rlock(lock) : rw_wlock(lock)); > K> > } > K> > > K> > This is explicitly allowed in 6.5.15 of the C11 standard. > K> > > K> > Of course all this code can be written in some other way, so constraint > K> > of KPI not being true functions can be worked around, but I believe better > K> > it be fixed. > K> > K> Hum. I know about ternary operator allowing void-typed expressions on both > K> sides of ':'. What I replied to is the following, from C17 > K> > K> 6.8.6.4 The return statement > K> Constraints > K> 1 A return statement with an expression shall not appear in a function > K> whose return type is void. A return statement without an expression > K> shall only appear in a function whose return type is void. > K> > K> So syntax above is explicitly prohibited by the standard. I was quite > K> surprised that both gcc and clang silently accept this, unless -pedantic > K> is specified. There is no mention of this extension in gcc manual. > K> Compiler explorer demonstrates that compilers like msvc do warn about > K> the construct, and some even error out (tendra): > K> https://godbolt.org/z/xqcPssTcY > K> > K> Another part of the confusion, perhaps, is that > K> return ; > K> is explicitly allowed by the C++ standard (I looked at 2020 version), > K> unlike C. > > Hmm, so I mistakenly transferred my knowledge about the tail call > optimization hint from C++ to C. > > Okay, let's put return aside. This would compile with true > functions (e.g. WITNESS), otherwise not: > > void > something(bool clue) > { > clue ? rw_rlock(lock) : rw_wlock(lock); > } > > And this is correct code per 6.5.15. So why cannot you write it as ... if (clue) rw_rlock(lock); else rw_wlock(lock); From nobody Wed Oct 27 05:24:42 2021 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 2FC84181923B for ; Wed, 27 Oct 2021 05:24:45 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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 "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfHF85Qc5z3lk6; Wed, 27 Oct 2021 05:24:44 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 19R5Og0k013538 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Oct 2021 22:24:43 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 19R5OgCB013537; Tue, 26 Oct 2021 22:24:42 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 26 Oct 2021 22:24:42 -0700 From: Gleb Smirnoff To: Konstantin Belousov Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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: 4HfHF85Qc5z3lk6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Oct 27, 2021 at 08:11:13AM +0300, Konstantin Belousov wrote: K> > Okay, let's put return aside. This would compile with true K> > functions (e.g. WITNESS), otherwise not: K> > K> > void K> > something(bool clue) K> > { K> > clue ? rw_rlock(lock) : rw_wlock(lock); K> > } K> > K> > And this is correct code per 6.5.15. K> K> So why cannot you write it as K> ... K> if (clue) K> rw_rlock(lock); K> else K> rw_wlock(lock); Of course I can. But manual page rwlock(9) says I can treat them as functions, thus use in conditional operator. My point is that the fact that I can work around this, doesn't justify the problem not being fixed. What is a downside of wrapping them in "__extension__ ({ })"? -- Gleb Smirnoff From nobody Wed Oct 27 05:32:51 2021 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 269C2181C188 for ; Wed, 27 Oct 2021 05:32:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HfHQf3pxvz3nWq; Wed, 27 Oct 2021 05:32:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19R5WpbV067344 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Oct 2021 08:32:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19R5WpbV067344 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19R5WpPX067343; Wed, 27 Oct 2021 08:32:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Oct 2021 08:32:51 +0300 From: Konstantin Belousov To: Gleb Smirnoff Cc: mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HfHQf3pxvz3nWq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 26, 2021 at 10:24:42PM -0700, Gleb Smirnoff wrote: > On Wed, Oct 27, 2021 at 08:11:13AM +0300, Konstantin Belousov wrote: > K> > Okay, let's put return aside. This would compile with true > K> > functions (e.g. WITNESS), otherwise not: > K> > > K> > void > K> > something(bool clue) > K> > { > K> > clue ? rw_rlock(lock) : rw_wlock(lock); > K> > } > K> > > K> > And this is correct code per 6.5.15. > K> > K> So why cannot you write it as > K> ... > K> if (clue) > K> rw_rlock(lock); > K> else > K> rw_wlock(lock); > > Of course I can. But manual page rwlock(9) says I can treat them as functions, thus > use in conditional operator. > > My point is that the fact that I can work around this, doesn't justify the > problem not being fixed. > > What is a downside of wrapping them in "__extension__ ({ })"? I do not object against __extension__, I was interested in real situation where you cannot work-around it. I am fine with making *lock() correct expressions. From nobody Wed Oct 27 08:11:05 2021 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 CB6181813E4A for ; Wed, 27 Oct 2021 08:11:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0: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 4HfLxD5DWLz3G58; Wed, 27 Oct 2021 08:11:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-ot1-x334.google.com with SMTP id x27-20020a9d459b000000b0055303520cc4so2425761ote.13; Wed, 27 Oct 2021 01:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GTD3Mfc4fGjLoEt3Qe6wUFBIlRJ9Tk9Sylbuu3uasQA=; b=hcJuszez3D+HPPth4gBrVLufpu+wvwxkZQoovIlVhYEchu1Nu/vZIAaG6qYiVqkZRK meVN819VTbmDYo1X9d8l+86WNQ8koMoLNuBT27gfGjECrtzt7enD4NNDilY0ux2eUg4b fMQMMR7piUKhwOPUbbMHDPxgTIdBwqHkwzKD63VmZGGYPxXx5HhZ04IGqCODXSwlbwAT TFe4PXBmVQrNKzkjcMBQk9Sc5L0xh4yuf7XWvPF1sG+L7A60ZB5rupH/04nGsniFtk16 2MmQ281xNgj2eeYwMaE2GHqy7e0f/ZGnVKokM1azwD5QIBN0xZQALOkoJmHTedUyKHZV vWHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GTD3Mfc4fGjLoEt3Qe6wUFBIlRJ9Tk9Sylbuu3uasQA=; b=IeUy6gBHu3Cs6pnlM9Uocyj9uLTKNzAvYfjUF3Et0zKmFEcjNMwBkP+5Qvon2Jnf/i Ek+dVBiD1eQYaYq/cr55QRTjx0Uhljppl4UyykGmRywC2j5HE1i1G10IKtjkYLm7Nlas Z8DKuO4ND3+rD0k9m8/wfkVUvtJV7ME3EAzLZ65+bRCy4a6DCJkMzcCNv7ARJqnq5tKP 14bs4u2AWLKj68AjQ4a7MXV+168QIe02FpStaj7WAnD/5Ha+Fau3bKTJiRDeISC7RvXe fOc54hBpz9s5mTZnGN4EU/qWjMfyP/7W59ec4S3uPu9VGkUktE+9nrWnt9RMZtX2uoG7 eYQQ== X-Gm-Message-State: AOAM531IgxtL5LKRbyULiXGUNFGq3yyFWYOoUdMRtGH9gt/8WWaSFAT4 2CstzRmfTyJ12+AlUI+tl06t+ubuzapwCD534vpzhGb2 X-Google-Smtp-Source: ABdhPJxi01F91xemhSo/DdMS1zLb+aKgavlhed6DK47yPeCx663JqcD9LweFaxLgxDATqbkIGSQcSzcnuvfB64SZGRI= X-Received: by 2002:a9d:4d0f:: with SMTP id n15mr6140094otf.294.1635322265761; Wed, 27 Oct 2021 01:11:05 -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 Received: by 2002:ac9:126d:0:b0:3b4:5824:6a18 with HTTP; Wed, 27 Oct 2021 01:11:05 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Wed, 27 Oct 2021 10:11:05 +0200 Message-ID: Subject: Re: rwlock(9) and mutex(9) definitions To: Gleb Smirnoff Cc: kib@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HfLxD5DWLz3G58 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 10/27/21, Gleb Smirnoff wrote: > Hi, > > [To: list constructed with help of git blame] > > despite manual pages describe locking functions as voids in > reality some of them (not all) are preprocessor defines wrapped > in "do {} while (0)". > > Such wraps don't really behave as a true void. For example you > can not tail call them: > > void > smartass_lock(lock, clue) > { > if (clue) > return (rw_rlock(lock)); > else > return (rw_wlock(lock)); > } > > This will fail on rw_wlock, but not on rw_rlock. However, if you > have WITNESS it will compile correctly :) > > So, we need either make these function "static inline void" in > mtx.h and rwlock.h, or wrap them in __extension__ ({ }). Btw, the > latter is already done for mtx_trylock_spin() by kib in 90b581f2cc327. > Of course for try-lock functions inability of tail call is a bigger > issue then for voids. However, voids should be fixed as well, I believe. > > Your call? "static inline" or "__extension__ ({ })"? > I don't have an opinion which way to go here, but will have to note that the inlines should probably get retired in favor of asm funcs, but it wont happen anytime soon. -- Mateusz Guzik From nobody Wed Oct 27 08:24:50 2021 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 3FB4F181A7D1 for ; Wed, 27 Oct 2021 08:24: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 4HfMF60PYYz3LV4; Wed, 27 Oct 2021 08:24:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [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 83E5D8929E; Wed, 27 Oct 2021 08:24:50 +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 19R8OosT096367 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Oct 2021 08:24:50 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 19R8OoXX096366; Wed, 27 Oct 2021 08:24:50 GMT (envelope-from phk) Message-Id: <202110270824.19R8OoXX096366@critter.freebsd.dk> To: Gleb Smirnoff cc: kib@freebsd.org, mjg@freebsd.org, jhb@freebsd.org, jeff@freebsd.org, arch@freebsd.org Subject: Re: rwlock(9) and mutex(9) definitions 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: <96364.1635323090.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2021 08:24:50 +0000 X-Rspamd-Queue-Id: 4HfMF60PYYz3LV4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N -------- Gleb Smirnoff writes: > Such wraps don't really behave as a true void. For example you > can not tail call them: > > void > smartass_lock(lock, clue) > { > if (clue) > return (rw_rlock(lock)); > else > return (rw_wlock(lock)); > } > > This will fail on rw_wlock, but not on rw_rlock. However, if you > have WITNESS it will compile correctly :) I'm not going to go full Bruce on you here, but... In your example above, at the very least the "else" is surplus to requirem= ents. The "return" around rw_wlock also doesnt do nothing for its keep. That leaves us with: void smartass_lock(lock, clue) { if (clue) return (rw_rlock(lock)); rw_wlock(lock); } That has pretty low aesthetic qualities, which is why I myself would have written it as: void smartass_lock(lock, clue) { if (clue) rw_rlock(lock); else rw_wlock(lock); } Finally "return(something_void)" is bad style in my book, because "void" literally means there is no return value to begin with. So all in all, I fail to see a problem that needs fixing ? I realize that the above may be a simplified example of the real problem you're trying to solve, but if so, it is too simplified to carry your argument. -- = 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 Oct 28 03:08:47 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 2C442181D954 for ; Thu, 28 Oct 2021 03:08:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 4HfrB24LDnz4RB0 for ; Thu, 28 Oct 2021 03:08:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x932.google.com with SMTP id u9so8853922uac.8 for ; Wed, 27 Oct 2021 20:08:58 -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=b1g34hSAyAXZ5YJ/78vhFu71sxuIQ9TOj/E4G9quYEY=; b=r0HXrN8oIVO+EKqt2cMbaKJ7MeynGB1mUtgdANrc0Ea6CRP/q8FgC7Yb3W2Qb37NGy oZhyl8sIJ+fFaqG8LhWCuiiuCaZpXWrfLWoSSMZkzPjFkY1yXi654n2Ez0Q2WNa70XkX b1ltP1Umu4st2PBv7wrBtMMRCZNdDH7QKbEtF0WfxpOBL0H3XeLbiN7+4qL2UQJJlN5D k6wmWtS4ZGdqExvYuI25pIQ4RUKZDvzlxNIuNDIRBOG404Ft5KWi1Tm5cvfxiYD9/pS/ +T2cylVmF0qwDVmXY9Q0uSYGNhOaUnpA0usRV9t+4tEPuc/zfc1EZ7vQhcfn1pTZ4UNQ pI+A== 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=b1g34hSAyAXZ5YJ/78vhFu71sxuIQ9TOj/E4G9quYEY=; b=NaQTrjd23Ukm2AUTlnmJmgFJ67XmZDb/UYdyvUGjSVde/lIJtcayxfQa3UfsCzClMN K8Rvu1lAx49oywVNq2gLghIZDCDGBILdzpN2Su0RerT+JFkAeSxZ5tQc9ZAuXDHkhAIm j23SXolzZmfkXtcORrtKVZoSu/scWkggvZlwFd9s2WocC5pj3QShYYKnZ6OE3rLmUkN8 IIFWPcCvrsYBAksBGT19wd25rzgTvvaOfGOn+rlnJaK9HjvPO1Q16uHx8S83wIRbLlW4 R1Nzeh0BWxQa8kwXkQ94GukxwegM5v+T2MDhxuaEFt/ZA6rnoA0owFtTBJEloLxQ2i8j GG9g== X-Gm-Message-State: AOAM530f0uXcrWTe1UAKmB1zlW15Yv1Ns9Emyl6OAcYYJaqkGDmLSkr7 VhtKosZDsbcVnW1ywl7JuDwxhgpnDnpWIjWxO90ehyZ2f7I= X-Google-Smtp-Source: ABdhPJznLrYhZBEfGT0KjCsq/PXIsplXfb2S11XSIFeazVR7fC2wvc+bKg8Vfh4ZteE5chTyI+K98q5lwO91sDydFzg= X-Received: by 2002:a05:6102:5494:: with SMTP id bk20mr2160212vsb.6.1635390537766; Wed, 27 Oct 2021 20:08:57 -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, 27 Oct 2021 21:08:47 -0600 Message-ID: Subject: Firm Timeline for MIPS removal from FreeBSD To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000012ad4905cf6108f9" X-Rspamd-Queue-Id: 4HfrB24LDnz4RB0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=r0HXrN8o; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::932) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.97 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.971]; 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]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::932: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 --00000000000012ad4905cf6108f9 Content-Type: text/plain; charset="UTF-8" Greetings, Please find enclosed my proposed firm timeline for the removal of mips from FreeBSD, as previously discussed. There was no opposition to the plan when I posted before. The major users of FreeBSD/mips in the past have mostly moved on and they indicated no objections to the plan. And Adrian has committed his first arm port as well... So, I propose the following rather quick timeline: November 1: disconnect from tinderbox / universe. Add notices to appropriate manuals and MFC them. November 5: Post a review for its removal November 15: commit the removal, assuming the review goes well. Comments? Warner --00000000000012ad4905cf6108f9-- From nobody Thu Oct 28 05:49:04 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 E845F1815E7F for ; Thu, 28 Oct 2021 05:49:10 +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 4Hfvkt5wGBz3PdC; Thu, 28 Oct 2021 05:49:10 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A3DDB4B1B; Thu, 28 Oct 2021 05:49:10 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 6CCAB27C0054; Thu, 28 Oct 2021 01:49:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 28 Oct 2021 01:49:10 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdeguddgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffokfgjfhggtgesthdtmh dtredttdenucfhrhhomheprfhhihhlihhpucfrrggvphhsuceophhhihhlihhpsehfrhgv vggsshgurdhorhhgqeenucggtffrrghtthgvrhhnpedvgfdtledvgfeggeehfefgvedtke fhjeeludfgvdeftefgudduleegtdeludekudenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehphhhilhhiphdomhgvshhmthhprghuthhhphgvrh hsohhnrghlihhthidqudduieeivdeivdegkedqvdefhedukedttdekqdhphhhilhhiphep pehfrhgvvggsshgurdhorhhgsehtrhhouhgslhgvrdhish X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 28 Oct 2021 01:49:09 -0400 (EDT) From: Philip Paeps To: Warner Losh Cc: freebsd-arch@freebsd.org Subject: Re: Firm Timeline for MIPS removal from FreeBSD Date: Thu, 28 Oct 2021 13:49:04 +0800 X-Mailer: MailMate (1.14r5842) Message-ID: In-Reply-To: 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; format=flowed X-ThisMailContainsUnwantedMimeParts: N On 2021-10-28 11:08:47 (+0800), Warner Losh wrote: > Please find enclosed my proposed firm timeline for the removal of mips > from > FreeBSD, as previously discussed. There was no opposition to the plan > when > I posted before. The major > users of FreeBSD/mips in the past have mostly moved on and they > indicated > no objections > to the plan. And Adrian has committed his first arm port as well... > > So, I propose the following rather quick timeline: > > November 1: disconnect from tinderbox / universe. Add notices to > appropriate manuals and MFC them. > November 5: Post a review for its removal > November 15: commit the removal, assuming the review goes well. > > Comments? Do you have a suggestion for when we can remove the mips packages from the pkg mirrors? Since you mention MFCing this change, I assume we should stop building and distributing packages for 12 and 13 too. How long should we keep the last package set around for (if at all?) I ask because I'd rather use the disk space on the mirrors for more better supported architectures. While the footprint of mips packages is trivial in comparison to most others, it's not zero. And syncing them across the mirrors takes time too. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From nobody Thu Oct 28 15:37:03 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 163BE1831EBA for ; Thu, 28 Oct 2021 15:37:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 4Hg8nR0Tvmz4bq7 for ; Thu, 28 Oct 2021 15:37:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa33.google.com with SMTP id 20so3183124vkc.8 for ; Thu, 28 Oct 2021 08:37:15 -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=EYeGg+bsvD07e6z6AQMmcu8fVytgMxzEumiPpvd+5lA=; b=S4eMY6PtI2PX93pRD4dUpsMcFuZKNResrhqhcerrfTC6aPS+njdWZi3uqhAjs+b1TW gScC0fQi0rnN/liAXH69XbsK+KVw5xRTpp188+DNBg1jo7aLT+UQhgmfUcu5mRGzTzNY SzaR9k/p11aKxP/UyynYELXC8s+kcHEOUNlAx3Wg6MMS3d24bJ16V+5Svbjx69Xe8GXA 07Ird7x8WIBxpiEekMyeJfq5BUmGEgW7+odN8rcbkJFka7QrSkZV78lrve/ZoUsiEwIg MX6x6uAL+7CyB1JmXPMBgLi1n+tIGpOb8jFHLG+JkOGqhzk7d7B77LuxL30UG6fBHzHH MYeg== 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=EYeGg+bsvD07e6z6AQMmcu8fVytgMxzEumiPpvd+5lA=; b=LQV2r4/e1RRRvrWbeAFrH8XLJ/d3HELjQokt2eYNJvtaqmwoQKFl6qwj+hwmAky5ix v0aggI8eENWt6Jhy7Ak+W+5oKxocVo3Z9ISyzAs4Y2U1mC+iKt0oiSD49hFpPRcwmEMm Xn17T3oIqC+Lfq0SLvHYLgTOOoPGM35CI4Vrpl5rxR4HPCtZhFkqNtZN9R7PY6UzbYIP m57IWBegvLAcjbHqyBRjip+1B0X5fVYhVOUrJqLHBkhTjQcammtR/MLzyrhvBNai5Ojz bF8h+ToKq2MVtmo3pcVHepVWZlqOebaVdYb9lx6061TDToEbAuIcaNGDPG5X0VLWy95+ AOkg== X-Gm-Message-State: AOAM533XCObHd7h66in94Sv6IABOjRbxUKqWkd/aEY3izweli03dBE2x c7GqhXLFLV60Rh9dtlP21FndpSae5rEW9BBk5PSn8pRBjmA= X-Google-Smtp-Source: ABdhPJyHQ0FmIKz/g3gGxwmKt2oZ12PpQFW4gPrChsLp8w7K8H/th9bJ+6hm9uyCLZsf6jzJsQyn8uvgbQzrwRbATyc= X-Received: by 2002:a05:6122:730:: with SMTP id 48mr5144279vki.22.1635435434262; Thu, 28 Oct 2021 08:37:14 -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, 28 Oct 2021 09:37:03 -0600 Message-ID: Subject: FreeBSD 14: Poll armv6 deprecated or removed To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000001cdc5e05cf6b7cf1" X-Rspamd-Queue-Id: 4Hg8nR0Tvmz4bq7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=S4eMY6Pt; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a33) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; 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(-0.99)[-0.990]; 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::a33: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 --0000000000001cdc5e05cf6b7cf1 Content-Type: text/plain; charset="UTF-8" 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. Warner --0000000000001cdc5e05cf6b7cf1-- From nobody Thu Oct 28 15:45:31 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 E6C911836F4C for ; Thu, 28 Oct 2021 15:45:40 +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 "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hg8z64Z6Rz4hh6 for ; Thu, 28 Oct 2021 15:45:38 +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 19SFjV2Z041607 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 28 Oct 2021 17:45:31 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 19SFjVaH041606 for freebsd-arch@freebsd.org; Thu, 28 Oct 2021 17:45:31 +0200 (CEST) (envelope-from fuz) Date: Thu, 28 Oct 2021 17:45:31 +0200 From: Robert Clausecker To: freebsd-arch@freebsd.org Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed 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: 4Hg8z64Z6Rz4hh6 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 [-2.83 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.61)[-0.611]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[fuz.su]; NEURAL_HAM_SHORT(-0.92)[-0.917]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I have just bought an armv6 board a few days ago to improve package support for this platform. But alas apart from maintaining an assembly code base with specific support for armv6 FreeBSD [1], that's really the only thing I'm doing with it. So not really important for me either way, but if you ask I'm in favour of keeping armv6 support. Yours, Robert Clausecker [1]: https://mecrisp.sourceforge.net Am Thu, Oct 28, 2021 at 09:37:03AM -0600 schrieb Warner Losh: > 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. > > Warner -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Thu Oct 28 15:46:17 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 7C6571837BCE for ; Thu, 28 Oct 2021 15:46:29 +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 4Hg9046lJVz4jWF for ; Thu, 28 Oct 2021 15:46:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x935.google.com with SMTP id f4so12396081uad.4 for ; Thu, 28 Oct 2021 08:46:28 -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=aPlM6tAOcfcKOPIoB9eF4wHckxYRJGo+4NLjYCH1um0=; b=rWEwWaHEEub8k1lL6L2aUs2eftFAa58YWYmzcwqEHn64q+kD8+ob7WyRTLCQT3xOV2 ku+zPZz9euC2fFVewGHYQYtLJoqdyDAm1i5QsKlaep36ohvcYZy6Bbbm/JzxE6CdsLt6 ZXxTMnbBlcNd707hdiq48QlJ9aq69Lr1vEw0pBSetoWML0PZzwd03625vbIk5TJRcdEK S55ZWN08tX/5Sq+ayORAFM2QyGPQfNsG5EcX75VbQv0z5D/VSjf5VrfvlYB5YbRF2tIC Iy9Y9PDQaFdTR7VB5PTjUidQMYz+EiHxIYYKXY4bQwcPYzT25thcxtYAnDRKE/z/YMdt qrYA== 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=aPlM6tAOcfcKOPIoB9eF4wHckxYRJGo+4NLjYCH1um0=; b=bVEE5I2nYJa3u/YsUGgP5p4YTunpPDO19uocXggirJdPsXjIY8+DWEje40Z1Zk9h+N YNaHwaP0gBIV+50gHkIPvaVGdIU7QHU6uWYJ6/qsARKyjIP1Zhg4EjiYKxJaTdXBMuRK YqK5yTprUlOYy97rk+RdEapf683bS/pB90/GOIES+ayRPxXuuJ968Y/JULeW8apYDNQD 3WV3Sj75hIXinsXJaa9KrU6gSkDwr75Zj59i5kx4XPblr6OgMdil5i8ChzNl6sww/5md dbURFOb4ykw5MPtnlU1psVlZLwthBgauFj5qyDI4jv2njGwfQz8t3kCE9vS9Kq/thR/j i+CA== X-Gm-Message-State: AOAM533qr2kPpvgTjk7Qyqsy/GNlHfUTsMUiPM1i6Y3A+K3UY7ijq59w wsKkr99QzyQqrLE1BJpJlBN4M4/KastoLymQowRGs2znz7Q= X-Google-Smtp-Source: ABdhPJxk9h66za2z+v0hXLollHd6ykzlxwSrGOND0jLj/7NaltFc8mX6XYv9RTxWoQc6Xp9G++7An/UZe9azClvCi0U= X-Received: by 2002:a05:6102:3232:: with SMTP id x18mr5223585vsf.42.1635435988228; Thu, 28 Oct 2021 08:46:28 -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: Thu, 28 Oct 2021 09:46:17 -0600 Message-ID: Subject: Re: Firm Timeline for MIPS removal from FreeBSD To: Philip Paeps Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000021aea205cf6b9db3" X-Rspamd-Queue-Id: 4Hg9046lJVz4jWF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000021aea205cf6b9db3 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 27, 2021 at 11:49 PM Philip Paeps wrote: > On 2021-10-28 11:08:47 (+0800), Warner Losh wrote: > > Please find enclosed my proposed firm timeline for the removal of mips > > from > > FreeBSD, as previously discussed. There was no opposition to the plan > > when > > I posted before. The major > > users of FreeBSD/mips in the past have mostly moved on and they > > indicated > > no objections > > to the plan. And Adrian has committed his first arm port as well... > > > > So, I propose the following rather quick timeline: > > > > November 1: disconnect from tinderbox / universe. Add notices to > > appropriate manuals and MFC them. > > November 5: Post a review for its removal > > November 15: commit the removal, assuming the review goes well. > > > > Comments? > > Do you have a suggestion for when we can remove the mips packages from > the pkg mirrors? Since you mention MFCing this change, I assume we > should stop building and distributing packages for 12 and 13 too. How > long should we keep the last package set around for (if at all?) > For 14.x we can stop today. I'm torn on 12.x and 13.x and would like to know of people are using those packages. Do we have numbers? That will tell us how quickly we can transition to 0. > I ask because I'd rather use the disk space on the mirrors for more > better supported architectures. While the footprint of mips packages is > trivial in comparison to most others, it's not zero. And syncing them > across the mirrors takes time too. > What about armv6 packages? Do we have numbers there? Warner --00000000000021aea205cf6b9db3-- From nobody Thu Oct 28 15:47:57 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 A459B18184B8 for ; Thu, 28 Oct 2021 15:48:09 +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 4Hg9213jT4z4kMc for ; Thu, 28 Oct 2021 15:48:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id f126so3217237vke.3 for ; Thu, 28 Oct 2021 08:48:09 -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=Gwq8kb16p/XQpui+z5Hc+ADUm30xoErPSPmLacnLaI8=; b=rhgXbj/4cTerjYdmBR9OSVVazNyB6SygAGNtWymUNuK/dQfaU3PifOB4iH+vmcRO2D kHIYeQKpuQRIorWCUHtaWkTlNG4yTk/B9GAysx6nYJKbM5uFoV7mtzAsfWZkwug5RC8O es8wszgKi+DBgYJM2QioqkyMhory5W4fImKSI2JwLsSdNZDy1AEC1k/z2sSyQRAGHZjI T4vnIhqfgmWAr6Z5SRewdYEfvyXSArGfAbOVS34WCMZsbRx2OZRJVCa5WZFbzHjtf4j5 RmOUWJ8KPLbC3icwpktrZgqzixJi6PZq0EYVSRmvX9HhFP71kYXq2KhIlTqaV2zw1mSC ioTw== 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=Gwq8kb16p/XQpui+z5Hc+ADUm30xoErPSPmLacnLaI8=; b=NS2zkmLKwig9QAM3jNGB/XuETezqd70tj+d0qGruO4THNp0UvvhB5ryfY6WlWmJHsx RHQwhFPn2Gk0TXPey0vSPK5W7Pp8nd7o5hAIu+/RKSFCkGR/Na+A3GnRHJEkeAZ7V6Bp 7OZrZnOLzyE/do4c1xtHTJjMcggNG+Lbf+n5P0P1FSfxWdXR354IAtm1LyhB91mBYlUY rVnCyvmZwH2Gx/GLS6PIInezmbbIjJd+vFbk3gnt3zOfewmayBASzPkir6+I0iqNLvKL PnHBdZ5Iq9VIiy5aqdr5qnJ4XMi+12jqmxwzcHxZn+x3jmfYXCOmHS4y9plFQV4Y2k55 smJQ== X-Gm-Message-State: AOAM532Jc8iPaTuyBwn4WJSAiIQ6tMnajJv70P9l7EG/rAS+Af+NKknb bfQ6LPLGUORaZsrKWhArGNFOHS9DopdzuRhNiGtBg+ki1SE= X-Google-Smtp-Source: ABdhPJxMmuNEgA5PiS/B3XGp7m/MkxIF1AQu2p0X9bU30M1ekMU7RwwCFVq4kMfShUJYIErTxK1IFypkqDpbjB41tL8= X-Received: by 2002:a1f:6416:: with SMTP id y22mr4906871vkb.18.1635436088802; Thu, 28 Oct 2021 08:48: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: In-Reply-To: From: Warner Losh Date: Thu, 28 Oct 2021 09:47:57 -0600 Message-ID: Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed To: Robert Clausecker Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000020547d05cf6ba393" X-Rspamd-Queue-Id: 4Hg9213jT4z4kMc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000020547d05cf6ba393 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 28, 2021 at 9:46 AM Robert Clausecker wrote: > Hi, > > I have just bought an armv6 board a few days ago to improve package support > for this platform. Which armv6 board? Warner > But alas apart from maintaining an assembly code base > with specific support for armv6 FreeBSD [1], that's really the only thing > I'm doing with it. > > So not really important for me either way, but if you ask I'm in favour of > keeping armv6 support. > > Yours, > Robert Clausecker > > [1]: https://mecrisp.sourceforge.net > > Am Thu, Oct 28, 2021 at 09:37:03AM -0600 schrieb Warner Losh: > > 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. > > > > Warner > > -- > () ascii ribbon campaign - for an 8-bit clean world > /\ - against html email - against proprietary attachments > > --00000000000020547d05cf6ba393-- From nobody Thu Oct 28 15:50:41 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 088B118189AD for ; Thu, 28 Oct 2021 15:50:43 +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 "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hg94y32p9z4ktW for ; Thu, 28 Oct 2021 15:50:42 +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 19SFofmE041935 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 28 Oct 2021 17:50:41 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 19SFof3e041934 for freebsd-arch@freebsd.org; Thu, 28 Oct 2021 17:50:41 +0200 (CEST) (envelope-from fuz) Date: Thu, 28 Oct 2021 17:50:41 +0200 From: Robert Clausecker To: freebsd-arch@freebsd.org Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed 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: 4Hg94y32p9z4ktW 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 [-2.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.854]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[fuz.su]; NEURAL_HAM_SHORT(-0.83)[-0.830]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N A Raspberry Pi 1B+. Yours, Robert Clausecker Am Thu, Oct 28, 2021 at 09:47:57AM -0600 schrieb Warner Losh: > On Thu, Oct 28, 2021 at 9:46 AM Robert Clausecker wrote: > > > Hi, > > > > I have just bought an armv6 board a few days ago to improve package support > > for this platform. > > > Which armv6 board? > > Warner > > > > But alas apart from maintaining an assembly code base > > with specific support for armv6 FreeBSD [1], that's really the only thing > > I'm doing with it. > > > > So not really important for me either way, but if you ask I'm in favour of > > keeping armv6 support. > > > > Yours, > > Robert Clausecker > > > > [1]: https://mecrisp.sourceforge.net > > > > Am Thu, Oct 28, 2021 at 09:37:03AM -0600 schrieb Warner Losh: > > > 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. > > > > > > Warner > > > > -- > > () ascii ribbon campaign - for an 8-bit clean world > > /\ - against html email - against proprietary attachments > > > > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Thu Oct 28 16:19:22 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 ABB6A182687F for ; Thu, 28 Oct 2021 16:19:24 +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 4Hg9k44T97z4tfx; Thu, 28 Oct 2021 16:19:24 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (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 217D89C18; Thu, 28 Oct 2021 16:19:24 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Firm Timeline for MIPS removal from FreeBSD To: Philip Paeps , Warner Losh Cc: freebsd-arch@freebsd.org References: From: John Baldwin Message-ID: <3d389f86-34aa-bf64-2ba1-563f73c6ca5e@FreeBSD.org> Date: Thu, 28 Oct 2021 09:19:22 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 10/27/21 10:49 PM, Philip Paeps wrote: > On 2021-10-28 11:08:47 (+0800), Warner Losh wrote: >> Please find enclosed my proposed firm timeline for the removal of mips >> from >> FreeBSD, as previously discussed. There was no opposition to the plan >> when >> I posted before. The major >> users of FreeBSD/mips in the past have mostly moved on and they >> indicated >> no objections >> to the plan. And Adrian has committed his first arm port as well... >> >> So, I propose the following rather quick timeline: >> >> November 1: disconnect from tinderbox / universe. Add notices to >> appropriate manuals and MFC them. >> November 5: Post a review for its removal >> November 15: commit the removal, assuming the review goes well. >> >> Comments? > > Do you have a suggestion for when we can remove the mips packages from > the pkg mirrors? Since you mention MFCing this change, I assume we > should stop building and distributing packages for 12 and 13 too. How > long should we keep the last package set around for (if at all?) > > I ask because I'd rather use the disk space on the mirrors for more > better supported architectures. While the footprint of mips packages is > trivial in comparison to most others, it's not zero. And syncing them > across the mirrors takes time too. Note that Warner is only proposing to MFC the deprecation notices, not the removal. That said, I think if you are trying to prioritize which package sets to carry on mirrors you should use any data you have (stats on how often packages for different arches are fetched, etc.) to inform your priorities there. To be clear though, MIPS is going to stay in 12.x and 13.x, it is only being removed in 14+. -- John Baldwin From nobody Sun Oct 31 03:34:59 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 BB9D21838680; Sun, 31 Oct 2021 03:35:04 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 4Hhhcm0BFFz4md5; Sun, 31 Oct 2021 03:35:03 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B30C95C0057; Sat, 30 Oct 2021 23:35:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 30 Oct 2021 23:35:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=l/4HVt3upD1GfsBQetDQmHwpmrc rSSg/+PJjg23OKHY=; b=KpsDcd103rjij4fLKI2G1UhUARDC6ddR3h61d2gIW7b h691a5tM1ThdBuh7hsDaaus62kW4rQFv2dhmjq6HFBHEDq5jiqOkCzSxrZpAVxJR nJQFb/8Wjv0u/BLWXkfOg6nQ9Wq747v9OBkKiKj0z+eU3miDoaCJOdNIxtV0hsq2 ziauQnGd5SZXgUQHwSpYrI0QOV2zO5jiaoOJmkRiYRIeYqRLj66L6Tri9yCq6Vr2 O7GOwZgG89MXFkln5oA4/Dq6bRMouNQrZycP3cjDgfAe9mZcQtEcC1b09y68l5wa 7xsZjsqAsECkP6i33gUutjOI4mo4Oz+YNfXTk3X9P7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=l/4HVt 3upD1GfsBQetDQmHwpmrcrSSg/+PJjg23OKHY=; b=nc7NIKAxVF8s/3VFXpw3gE TVTzpdM/HkEFFqIikWCrzl51/eZ22EDVQ/H670ZmNMgrar/VPBh3jIQu4Eiowqj8 c5YC90Vx/iKrsb53/HF+YNNa+CtB6GeT2Y/uJxWLx1SlxUk8W8vBb1QNlA37hg3x FgHZtKc7UBICKsLg57sHbiQo1tJvjlE2Nqps9rCU65BdtQfE73Nf+YXI/OnMueU0 o15Q5Rc5FPmMzC6F+mbCB/oC2NyrNGG7Al0q1BuevazvBysl++rLX8tGhuXsF3ML lbzMz0Q4SzPVIMzVNXQpR6WxTjxa7qd0c4wcqW5QUamGvEt+Ldc4t1r3+QTL4qiQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdegkedgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpefhveekffdtveeigedtvdeuteegtd elkefhvddufeeuhfekvdfhueeijeevveffueenucffohhmrghinhepfihikhhiphgvughi rgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 30 Oct 2021 23:35:02 -0400 (EDT) Date: Sun, 31 Oct 2021 03:34:59 +0000 From: tech-lists To: freebsd-arch@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed Message-ID: Mail-Followup-To: freebsd-arch@freebsd.org, freebsd-arm@freebsd.org 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="pBLyJKq5Pl2TceHt" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Hhhcm0BFFz4md5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=KpsDcd10; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=nc7NIKAx; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 66.111.4.29) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-4.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.111.4.29:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; NEURAL_SPAM_SHORT(1.00)[1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N --pBLyJKq5Pl2TceHt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Oct 28, 2021 at 09:37:03AM -0600, 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. I'm still using freebsd with armv6. It's [rpib+] presently a console server= to the router, connected via a ttl cable. As to useful, it's useful to me ;) b= ut=20 i'd imagine theres still lots of uses for armv6 boards, particularly in a l= ow-power=20 or battery-operated situation. The hardware is durable. They can still be b= ought=20 new, albeit on back order. According to https://en.wikipedia.org/wiki/Raspberry_Pi#Series_and_generations they [rpib+] aren't discontinued >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). How do you estimate the number of users? Millions of these (armv6) boards were sold. >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. Would it be easier to build a much limited number of packages? Stuff that's console-only? no xorg, browsers etc for -releng.=20 But I agree with 2a for -stable, for any arch.. >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. mine would be for 2a only for -stable. I think you might be wrong with "very small number of users" though. If you do decide to go ahead with it, if arm6 users still want *BSD, on netbsd it's a tier1 arch. --=20 J. --pBLyJKq5Pl2TceHt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmF+Ds4ACgkQs8o7QhFz NAVqZQ/9GF10QzOYJXYYFsVkDtD6nzlLvvChmDaXe/CNz7KGM5BHzLD87MVGfmXd xt9JZFpr892RDjX9r0gkUt0v3r3WFbjpGEFRWNkmujo5pm2CJYS5YsLvt1a6drwb Y4EUNZg9QsX6TnXN17HVx1RAocWudCcmfRHNvI/74CzFIVV2SAWFBB0LiY4nJG25 ScYlqREldXV1V9gVYkMFsKT4dCOM6rNGZt6FhHpPgcBwLHKbEL7raXJpGk7iz10M SXMhFS4Olcp1r2sfqYu7+pLaRvetD7JFnuZ07I4x/6IyCqCFhMBG2nfAKfsqJOE2 wTKrpj8ezlylZyy2WAlTrl5h41a5zw+ol3HN81nCyYqLeieS60f+wFHzpDdNpA/M GrdlYZmYlMr2Otp8O41lxaLItU6oPVaztRcWLSehKYTXsxM9hD0UI07WR+2bgqMU FEs9c12arJWiCgDnp5+iDBP+9QUdhwupDn2KcMNXK4mYLsvtPaqesLl7n+7SfbsB 0i1AhE3TLzEch6QTcQC81qHKuaY7d6lQ9F3KnOsS21PKVf28CYcGUb8pJ54Lf/mJ RbbzjngBRwKMVbKAkZRz48CYjZwq+G0MdY9+ovVPGhh3PEzn8K44kK014uVOgM2M UU3Nd2sEEAmyXA4rp1ERoQYA9UaiD7bkBf03GegrS3qN1klyEig= =5K1z -----END PGP SIGNATURE----- --pBLyJKq5Pl2TceHt-- From nobody Sun Oct 31 04:45:39 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 C0F7D182A354 for ; Sun, 31 Oct 2021 04:46:09 +0000 (UTC) (envelope-from jhay@meraka.org.za) Received: from marge.meraka.csir.co.za (marge.meraka.csir.co.za [IPv6:2001:4200:7000:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4HhkBm1rNRz3KCJ for ; Sun, 31 Oct 2021 04:46:07 +0000 (UTC) (envelope-from jhay@meraka.org.za) Received: from marge.meraka.csir.co.za (localhost [127.0.0.1]) by marge.meraka.csir.co.za (Postfix) with ESMTP id 1C0482AEFC for ; Sun, 31 Oct 2021 06:45:56 +0200 (SAST) X-Virus-Scanned: amavisd-new at meraka.org.za Received: from marge.meraka.csir.co.za ([127.0.0.1]) by marge.meraka.csir.co.za (marge.meraka.csir.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_kPXXqk97-Q for ; Sun, 31 Oct 2021 06:45:54 +0200 (SAST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by marge.meraka.csir.co.za (Postfix) with ESMTPSA for ; Sun, 31 Oct 2021 06:45:54 +0200 (SAST) Received: by mail-pj1-f41.google.com with SMTP id o6-20020a17090a0a0600b001a64b9a11aeso2910098pjo.3 for ; Sat, 30 Oct 2021 21:45:53 -0700 (PDT) X-Gm-Message-State: AOAM530LeEnlRf8w85mq5rYTYmaEInP3VJVPUse+06XXIE2gDsF+yopk k2CaWOX0wu/pRjGw4Pv/AvrIWMxu/bCByjrn+3okNQ== X-Google-Smtp-Source: ABdhPJydG4qr/BNRWxKa4YyBaLipTjBdxTVY0ZzH2auOMPNuT1peWTpI2iKFEd8FCopzdCxRpyG0GBBhpWE2TOCwajg= X-Received: by 2002:a17:903:228c:b0:141:ab58:ab56 with SMTP id b12-20020a170903228c00b00141ab58ab56mr12010130plh.75.1635655550299; Sat, 30 Oct 2021 21:45: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: In-Reply-To: From: John Hay Date: Sun, 31 Oct 2021 06:45:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000000d08d505cf9ebc16" X-Rspamd-Queue-Id: 4HhkBm1rNRz3KCJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jhay@meraka.org.za designates 2001:4200:7000:3::1 as permitted sender) smtp.mailfrom=jhay@meraka.org.za X-Spamd-Result: default: False [-1.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[jhay]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4200:7000:3::1]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[meraka.org.za]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.216.41:received]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:2018, ipnet:2001:4200:7000::/48, country:ZA] X-ThisMailContainsUnwantedMimeParts: Y --0000000000000d08d505cf9ebc16 Content-Type: text/plain; charset="UTF-8" Hi, On Thu, 28 Oct 2021 at 17:38, 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. > I'm using a RPI-B+ running 13.0-RELEASE. It is running permanently reading my electricity meter and sending it back via WIFI and IPv6 to my main computer. I normally upgrade to the next release when it is out. Normally by popping out the SD card and dd-ing a new image on it. I do not use any packages on that one. So my preference would be to have releases built and I am not too worried about packages. Regards John > Warner > --0000000000000d08d505cf9ebc16-- From nobody Wed Nov 3 09:31:54 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 EF5C41830436; Wed, 3 Nov 2021 09:32:22 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (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 "vtr.rulingia.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HkhPd5N0Kz3s0Y; Wed, 3 Nov 2021 09:32:21 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (2001-44b8-31fc-0d00-4c2a-0fcd-57f9-83b1.static.ipv6.internode.on.net [IPv6:2001:44b8:31fc:d00:4c2a:fcd:57f9:83b1]) by vtr.rulingia.com (8.16.1/8.16.1) with ESMTPS id 1A39W0jB094411 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Wed, 3 Nov 2021 20:32:07 +1100 (AEDT) (envelope-from peter@rulingia.com) DKIM-Filter: OpenDKIM Filter v2.10.3 vtr.rulingia.com 1A39W0jB094411 X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.16.1/8.16.1) with ESMTPS id 1A39VsVs045646 (version=TLSv1.3 cipher=AEAD-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Nov 2021 20:31:54 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.16.1/8.16.1/Submit) id 1A39Vsvf045645; Wed, 3 Nov 2021 20:31:54 +1100 (AEDT) (envelope-from peter) Date: Wed, 3 Nov 2021 20:31:54 +1100 From: Peter Jeremy To: Warner Losh Cc: "freebsd-arch@freebsd.org" , freebsd-arm@freebsd.org Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rXZ1f9vA0uE8OmOA" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 4HkhPd5N0Kz3s0Y X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=quarantine) header.from=rulingia.com; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-5.87 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[peter]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.969]; DMARC_POLICY_ALLOW(-0.50)[rulingia.com,quarantine]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --rXZ1f9vA0uE8OmOA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-Oct-28 09:37:03 -0600, Warner Losh wrote: >Given that the number of available and useful armv6 boards has fallen to >almost zero, the time has come to look hard at armv6. So far as I can tell, the only supported armv6 boards are the RPi variants using the BCM2835. According to Wikipedia, most of these boards are still available but when I look at the Element14 and RS websites, the only board I can find is the Compute Module (though it's on backorder). What is the direct benefit of removing the armv6 code? When 80386 removal was proposed, it included an explanation of the benefits of getting rid of all the support code in the VM subsystem. Another point that may be relevant is that when GCC introduced support for the ARMv6KZ architecture, it misspelt it as ARMv6ZK. Whilst the typo was corrected in GCC and never existed in Clang, the misspelling has leaked into a variety of FOSS - including contrib code in FreeBSD. Such code will either be missing relevant optimisations or, at worst, fail to compile on/for the RPi. >1. Keep it as is. >2. Stop building packages. >2a. We should likely do this anyway for all stable branches >3. Disconnect it from universe: >4. Remove support for armv6 in base entirely. > >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. Since FreeBSD-13 will be supported until early 2026, by which time the supported RPi hardware will be 10 years old, it would seem reasonable to remove armv6 prior to FreeBSD-14. --=20 Peter Jeremy --rXZ1f9vA0uE8OmOA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmGCVv9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzQjlg//R9wIc9+3Sv3ySbiHyVGcfANQlK+g2fP3HzuP1jJZA26UOETIxpSzzmL4 JFbXBYzDiGZNiYvU4kYD57yDEfI1bCaXWMy6EKH9thFL5I8cecsC4z+JQWUmA3gU w5Zk1yrXcicyYzt1fbUUo2hWnzIILqYuVj9KAgkvpeXSSVOMpKFT3r5p9+YvkbqG Hu5F7ShgHdi0K+ghqyuugPY8vLaP761PSRRbrCU8vOnYjqH4lQmW+sf6FRCb77ku ZxaZbBtsyYjhjhTQTtO9tdX/DnlD4CX1R2OqidWrYNUlegLm4Q59yFHDP20qGAPu 5DyihmVQzTe1UvWwonYTxaUOZOc3SBsVd/CYWtvuC6AUQctBEK0nMK8CWJnJ3Ygh 2/0j69gEdBFX4Am+9eg6ZK5jBttfvIYXI4Nkg+Zx3XxoYjp6ArFH5VxukJLU3wSO 1UiL1IdBMwmQFh54UNuBhDIl+iZGuRce+69pqa04IipZQ6i1KUBrQaQxLW3him+g KUcJO5/AhqjrmdRIzK80ZUBrcD2xcXH15vmubod4E8v/0l/Gcsxm2tDOMk8MoRED k8AEn8Gur2JHeCDL5XkecgIuD+S+StJ8K2tzzXBXZVc000jZETQcG4Pv1T5OFc6v G+kKDgZWxlsA1fQI468nvYQ0yzOYlNNI3Y3fufsCQ6HLkQWQbR4= =efy2 -----END PGP SIGNATURE----- --rXZ1f9vA0uE8OmOA-- From nobody Wed Nov 3 10:37:09 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 2BCDD182DE76; Wed, 3 Nov 2021 10:37:19 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.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 4HkjrZ2VgMz4jKD; Wed, 3 Nov 2021 10:37:18 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 48D8E5C00E8; Wed, 3 Nov 2021 06:37:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 03 Nov 2021 06:37:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=5EvnzNWKaPNvL0dY0kch+7LQ606 QYe/xX6K6dllq5kY=; b=obHZT9DW4yRPHJKOc6KTzqONAaJbISLayhXRMvUFQcj uu3OfnyOvmmRSwIjniSW/pBoV4zF2Im+e2IwKPXHxeZqdyGkWMVGJ/epAa8z5BYL de/oSUAD27Zby5c/ZqApfYgAZq2v2rRFGKmr6eLJJO+xla8ftogPk8Xd0Hzyhdyz Rj0efbP+HkS1yv27y0D5IyCxTDpunIIIVgO/2Iu2ZJGjVBKb/VEvZQTssjvRixmC 68v6DZclTC/+lt5tTBGmu7HlBsE69A/XPwmcoEG4tgZeMPdInZC1TSWRo0oLy59r I1bqLTjKJsVUNG8hYfzM5IrpJT/pG20YhBtNkVtX28g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=5EvnzN WKaPNvL0dY0kch+7LQ606QYe/xX6K6dllq5kY=; b=ODop5SCr1p/MUtFg6e1K4b qgRvvxUe7sATEnpx3fkX+D6zLoLYnXLLVRb00XfoXSevmegH86F/9P1JfjCKjOfk JEcn6RFOTqEQmAcelQjTOHStnVVD8BQREDNgjTOdnRFNyDdHIjAi+7xGF7spZ2ll +xEBh7NDQAgHmzWR8dOa86KG52ark4yptjvhrL0M1UydJRsnR0EPd6DLCdafSmoG BpUd7gyM0pqY3Zi0dwgxu5aEpH8+HIISIlyFaO/cnL0NIBQV1fEWKyT7+ykbHjEc zZz7Fe3j8RSGN6n38WfMK4ZOOxocCW8vVs8LT63SKfOi6dFAL2SvBLQow18BpK0g == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtddvgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Nov 2021 06:37:11 -0400 (EDT) Date: Wed, 3 Nov 2021 10:37:09 +0000 From: tech-lists To: freebsd-arch@freebsd.org, freebsd-arm@freebsd.org Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed Message-ID: Mail-Followup-To: freebsd-arch@freebsd.org, freebsd-arm@freebsd.org 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="8vbwP0lb2NosTSWu" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4HkjrZ2VgMz4jKD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=obHZT9DW; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=ODop5SCr; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 66.111.4.25) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.981]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N --8vbwP0lb2NosTSWu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 03, 2021 at 08:31:54PM +1100, Peter Jeremy wrote: >Since FreeBSD-13 will be supported until early 2026, by which time the >supported RPi hardware will be 10 years old, it would seem reasonable >to remove armv6 prior to FreeBSD-14. I'd say if the criterion was "old" then there are other candidates with far fewer units in circulation with hardware almost (over?) a decade older, like powerpc and powerpcspe. Literally *millions* of the rpi1b+ and its analogues were sold. They are durable boards, and they'll belong mainly to hobbyists. And as you say, they are still being made. Does FreeBSD *really* want to remove themselves from this audience? --=20 J. --8vbwP0lb2NosTSWu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmGCZkoACgkQs8o7QhFz NAViuhAAjfYSWmk2aI07jMVEj5vd0xwH1bqcNs3LF5xmfwtpO4WQq8B6cHkgEqrS KpcGqjCxh2TLWmPQV0i4acDbMQ0uP7V+tE2QeIR7FWVIooqSK95yYeR4sD5rUOgO L3glFEoYQQpphyP5C45imcvvhmnKN4ZXeFT4oQoRNtKsPHFZ+2+uF4wigu+edLOQ 2w3QGC3r6iEHRwWRg/O6LEN0TqSslvO6lcp+xirND0wEzADI8VAWK+daMqf8qlhf X6HFpf5/CZYNWWA5kLry0KGbbSnuEO/aRB7HQ0/d4wipVzDXn+2tJDtHk1y7WIbK kFOWch1BHUz75sYvm8uK/JpUyScDwHsPuaIA65hn2ff1PxWgk4LCUZ2OvlhYOdsM J9SYpUA4I90SsF/FgEhoNR/e7SVI0vXsfZe+KiIMpy6CZUcqnjkL9nbzbep+wkOJ EDRvfrWZDXbgxlh9Z0KemcBCo41mMVUgAccJ6K0f+9xUTDQ8T6HczBkSILFr5JlC 2WuHgFlzks2RPGntETbKsyvtIuOtAtAnyvMsSn5uGr+kG7KEre9gAP7hXDC97x20 Qv89FSW6crL9ofxIxY0RzNybUB1ZpBDbq+Y9Q7tWyMvvXi7S2Vvqh1FzYnhaDkDu rZhmeXQiXw9eV7+MGlyXQuQgj758Q6bxbRKoUiu4FtgYuOW3yS8= =Efni -----END PGP SIGNATURE----- --8vbwP0lb2NosTSWu-- From nobody Wed Nov 3 16:52: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 031021838022 for ; Wed, 3 Nov 2021 16:52:35 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 4Hkt9Z05bDz3Fxp for ; Wed, 3 Nov 2021 16:52:33 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-lf1-x12a.google.com with SMTP id bu18so6567512lfb.0 for ; Wed, 03 Nov 2021 09:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4mUpsQFflPR8+PfL66BGNop66oXmQzsTwDSYktEEAX8=; b=T3p14DXYPPteuNlt8EcF8XxUs0SrAJinwnVVi4y0lNqQo01HfgfZQPGF7hlC1C80F1 Emwr/gEALW5CX3bJrCaYL+GbjHxv4O2nhx0qEzinkKfFHs5CorkayKkrQtcYsl60npue IhUTa6zRyJkUvv0SVoFIgxuz5d8VqmIS2uNzA= 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=4mUpsQFflPR8+PfL66BGNop66oXmQzsTwDSYktEEAX8=; b=Bd3ZsAf4tK3jlugf19nRn4Cl/HKMlRPoGfazVm+UbMVb67jjBpfjdrWw+YkGGVkZlk N/gztPJRVO0jqVB7Z+ilpnlSX8CHM8e/1cOjfpQk+wD+e9BVbPBlfPQGC5aexbOeHeKv v1SGWEJ9XGulUthO903VJuDQdljAsti2CxpS+zXXNb24Mq79UTnEMJcl5fUOue5wlmY2 eELZyjKajYw0ZC5o1MJvSyq7yNda5X/4r49zJmQkBOfbMURQRYbfpgFyE23QQEr8OxwI dBw/ozPSlxjd00riusd8F2aiYSpjL+Hp7kmWItOFIt9y/l7aLlP7faz7EBWTVtIGBSJt rqFQ== X-Gm-Message-State: AOAM533Uzsz6qaR9/s5WQeM/KzhextAOUPaI16Ofu7MW49TNJlqWnYRX y6FGS7YmWp35cbpaczpdbFQb6hyNPfhkL3jaV6Jxbh12ZSM= X-Google-Smtp-Source: ABdhPJwRXrJmF06vsn2kQratmLQYpKY1YzUn4zDqCP/mkNuxX+P0ex2Vdzczj6mwGVAuB33p5rF6SmF/hO2/nI0rjXs= X-Received: by 2002:a05:6512:3987:: with SMTP id j7mr42570279lfu.637.1635958351929; Wed, 03 Nov 2021 09:52:31 -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: Kevin Bowling Date: Wed, 3 Nov 2021 09:52:19 -0700 Message-ID: Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed To: freebsd-arch@freebsd.org, freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006f3ba705cfe53c68" X-Rspamd-Queue-Id: 4Hkt9Z05bDz3Fxp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=kev009.com header.s=google header.b=T3p14DXY; dmarc=none; spf=pass (mx1.freebsd.org: domain of kevin.bowling@kev009.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=kevin.bowling@kev009.com X-Spamd-Result: default: False [-1.71 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.55)[-0.551]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-0.88)[-0.884]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[kev009.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.03)[0.026]; DKIM_TRACE(0.00)[kev009.com:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from]; R_DKIM_PERMFAIL(0.00)[kev009.com:s=google]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000006f3ba705cfe53c68 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 3, 2021 at 4:37 AM tech-lists wrote: > On Wed, Nov 03, 2021 at 08:31:54PM +1100, Peter Jeremy wrote: > > >Since FreeBSD-13 will be supported until early 2026, by which time the > >supported RPi hardware will be 10 years old, it would seem reasonable > >to remove armv6 prior to FreeBSD-14. > > I'd say if the criterion was "old" then there are other candidates with > far fewer units in circulation with hardware almost (over?) a decade > older, like powerpc and powerpcspe. > > Literally *millions* of the rpi1b+ and its analogues were sold. They > are durable boards, and they'll belong mainly to hobbyists. And as > you say, they are still being made. Does FreeBSD *really* want to remove > themselves from this audience? > FreeBSD wants any audience to help support the features they demand. Since this particular audience has not, what may cause it to in the future? Not a rhetorical question nor a vote for removing, this is a perennial problem in open source and I am curious how you think this works so I can incorporate it into my opinion. > -- > J. > --0000000000006f3ba705cfe53c68-- From nobody Thu Nov 4 14:50:53 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 03B3718388E4; Thu, 4 Nov 2021 14:51:05 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (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 4HlRQw0jJMz4Vqd; Thu, 4 Nov 2021 14:51:04 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B9BC53201C3B; Thu, 4 Nov 2021 10:50:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 04 Nov 2021 10:50:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=jSTSUWYcRvhIqLDFFXk7+wNZiu7 YbR4KcQqW+FKxc4s=; b=i3T/weuT6//U48qOEuq1BroEfp0WM8HuUvMavqTvalK wCkBB/YwLbNcnUiH77CpMwCK4fMEVmGVK0XSnkoK77n8oyY/QpzthG47pceYSfOl 8cHGPJkMBv273UhX6PB/mT4cJ1MwGhq84OFepm49bR7BoAYUJehvJQ84LeCxhzG2 Ic41fLauHGUg2drQ+W4Ans+HFqRcJK9s5CZCeRXNI/0nJYo4idLi2jn1HZ0du0d0 hDmzu4i8gYWoUcEVLcgzAwZP7H1Bz/VdNe40UvOK35bNqQo/0/Bx2+WraH2gr3zw G8QcIbtjDY7wH2IT47lIb/0OE3KxjdoWBaAJaAlJlJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jSTSUW YcRvhIqLDFFXk7+wNZiu7YbR4KcQqW+FKxc4s=; b=FhiYt56RaJtvg/Xxzy9UZL FYb5P57+r2/2eVSnwtsPIV6/LTqa7SvLNps/FfV+EzbXvkDwaxXYRnarYUL/0yGR Wszv/kmvX3DLEeZoGHjhhS0QMz1b/oRJc6lzDyOoFUHBINhHZcgXOVVT7cXIjmid nUkf4pXyXyjgJ6gu8PQlhVS5L3w4VGqJkGeHWhX+7SbeAdbftmAHmulg+LEG4s9o pMquplp6Ju+34CX33RSPBTbAzfv9wf6s5PLgsraJhsw901WvMyWRUJb93CX8rynJ rm77YGGgQ0ZanSuffLM2HrVZ95PIzCvNm76YQkscnob18EHjM+d2ckqFYm7Hhc4g == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtdeggdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 4 Nov 2021 10:50:55 -0400 (EDT) Date: Thu, 4 Nov 2021 14:50:53 +0000 From: tech-lists To: freebsd-arch@freebsd.org, freebsd-arm@freebsd.org Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed Message-ID: Mail-Followup-To: freebsd-arch@freebsd.org, freebsd-arm@freebsd.org 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="VNmVAG70LQrkNslD" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4HlRQw0jJMz4Vqd X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b="i3T/weuT"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=FhiYt56R; dmarc=none; spf=none (mx1.freebsd.org: domain of tech-lists@zyxst.net has no SPF policy when checking 64.147.123.24) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N --VNmVAG70LQrkNslD Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 03, 2021 at 09:52:19AM -0700, Kevin Bowling wrote: >FreeBSD wants any audience to help support the features they demand. Since >this particular audience has not, what may cause it to in the future? Not a >rhetorical question nor a vote for removing, this is a perennial problem in >open source and I am curious how you think this works so I can incorporate >it into my opinion. Maybe the audience isn't demanding? It doesn't mean the audience isn't there. perl and python and shell scripting work fine on these boards.=20 Issues with these things would I guess be taken up with those maintainers.= =20 The hardware is very stable. I'd expect that a lot more users might pipe=20 up if their freebsd os needed updating for some newer python only to find= =20 it couldn't be updated anymore. The first of those to pipe up i'd guess=20 be those with boards that have an internet-facing connection, as the=20 pressure to keep fully updated is a lot less within a firewalled LAN. OpenBSD immediately after install has an email on the system giving a method to send in a dmesg. I don't know if it gives them a handle on the number of users and what their hardware is, but it's better than nothing at all, which is where FreeBSD is. Although there is a port called sysutils/hw-probe, one needs to know about it first. It's not in base. For armv6 in particular though, I've not heard of any reason justifying *why* getting rid of it. At least if it's in base we can compile ports for it ourselves. mips/mips64 stopped because the working group stopped working with it, fair enough. This isn't the case with armv6. It might be helpful looking from another viewpoint - why is armv6 a tier1 architecture on NetBSD? --=20 J. --VNmVAG70LQrkNslD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmGD80QACgkQs8o7QhFz NAXvtRAAlGjqCo2PZ5AO1zAbguY5HvD3Cwf3X1tDVztTkwOtrslKgLJHS156q1To UMYw2lCwuSJAXiyD97Kgdns+fUGcVBuMjBEWD4xin5UBqvoNzLCrk9zLJgwv2nAB /Jgdazfelln3Nx4L15da1XUwtUKelB/LjyIpbprK6TTcRekJwLPSUby6rXgtWI50 zHaJbB3xCu2ZT/jQu/ADjCvVv9LehXeVVh6Z76WQNkpNcv14LRV6iP6a2OBpzKDa cR6Z9EsSPqQY8/Dg9fSIl13/Fkv8y+Ot9cHU+W5XOIGgMYr8ZikSWp6S/PcbskI0 4FC6wHQpO/mEqVSJkDTTPhCTjrucDu7s5F08D81bi4wN8D6kblxFq6i37kq72tF2 NtVGmy4VfZ2oOvW2LhpF/bKBLeozDBdTh8YddRnuztReGhNcuCEcjqjNDmn3wa1s eK7p+ssGmFzaJfl1QyPWY0KAHjf/gWyUxcZeij2yPOVpFe8EOiOHcnQdibVZ+Rsu 2tmW4zxDgrZeHBP+k/RkMJqLVuIRT5OH8oXUl4whyVrJoMU2Yt6iMIx+udSyWy4y j1lfYT2pint5zjj3xAEdr857ypzlQ8frI/85SufQUDidUMMP885ZeidMGIdwvYia oR0oJxXri3Px1QgA2hxKBbiu4SYAMQOpdX/m9tYgcN5H36KYCI4= =UvTI -----END PGP SIGNATURE----- --VNmVAG70LQrkNslD-- From nobody Thu Nov 4 18:53:18 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 9FD061830181 for ; Thu, 4 Nov 2021 18:53:30 +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.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 4HlXpf2SJGz3jb5 for ; Thu, 4 Nov 2021 18:53:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636052002; bh=79Rsj8q4jeie8U9bpP2QEGkifeRmW1HNC24JtT31XEo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Q+LCraAG2vxro1hgbgL66xvkQjGCfkcZpMAiHrINPW4yjwnTb7gsXOf6rpPveDvronU/nnCrDjTrRuYfIMoUydg+79uo6yFxibFX7lP0Tr2OA1ZjKFr9tiIQqAj0sLTg5xPBbdkOSug+6rBvMOjNW7RJ2VOjYxx2egmjPvKY/z3VxqcsEFYOrOh+mi++EcwHc7oIZBat1Vog/XO2ZVoFEArO8X5EFIPe3EF5xpNw5rekgeIydNldbl8F016rklPH/xiC+H1fBmfVLpWUD4y4x/M3Spv6gVHPOqv/H5ds7wUEpn2dR7eN8/8NnRhSYvK15MMKTrLrGmiFMKn4Oi6yZw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636052002; bh=/bexrCr6hlsTvPH8gwqX6grdpQGuSR/MNhc8Wjp8T2O=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DzYpgX7dczD5OYYKBGg5DXiPNUZINLz/PazwlS7/tuLS03rnweZ1W31AHpVbdBInpay9wtYZS+KTQw4janMA4qXXTHoPR1ZwjBUsxUn6oDs2PBKvO+NJFYN0dH9FZmMxzrb5D+1qVMuPOTS4yEHup6jQK1+qSqBqnDdqWNOgxqWMoxIEq6nbCGsjPkjJ+l2mghK/BSQOYu3IR7G3Rsm6PSMJuX8VN1Zq8hrlDxqzeSzywe+fWUxEnSnA/tkhKMnDqSgYhDNxdNoSFBtXVGBfK+X3HA74+Ttf0AZb1foLep8RuuANrfqUgrzZCIHDci2+FCSt54XrcyfJjxsyj05O9w== X-YMail-OSG: DkBg0voVM1nuu92XWfd6TeCxu2THXhhDT9VbWmSitd6JFZLAppEQ.589qyNpNNi rzAsBsbaeGmxknEf7dK5K7v8zk2um1W9rQyD9vcAZ0Yx5W_qtNwd.BeZ86a2U93RvrHAS_grTMpb Pdu5ZyWlp2Kl3kNjSTS2uQdsDBm1PDgXdJ2EZHxxT2HotzabrvCTZXg.gnJNhKJXWSqn6NMA_ac3 XIeAmDTsWY12RH8Lrs38K7bIQ.kJ7ng99dEibB7h5WQ3Ptf5BoDqG7J8KMs0bPVFl3DO8MWAS8dA 4RHV1mcoMFp23mDVj.NJfCSVpUt8MRVAuBgtsCxginjen0fl0aERvu9Ue.oNqDVivyI2p10AQK0G i6U4_igKZwCAUIkTlGvq9PBFd2J2LeeiW8jezE7aZQ1fXFHMSibtdIIjT_vNUC1HN0n8Pg2PboxB uewPuFdmca9JnWPHlihbkd.LGekpfdYd3wyNjR23iXZwrknjSsSCnllHJxbUXtAAXF7QlS8HNVIK AYXA5E44iTC3.n2Su_1XqrPfDdx6opcs7dLA502E3jkIgjjE1JkmwJQMeWz.InkluLiu8p.hYqjv yQpu64ky7Ub0ctMyGgXVKmuy2C0ifq7tZ6PBFi6nMEtJ9IrqddvGCWm6AUPPGOhOCehiAUzfMCNI 4j.ye3KJVgiroxe8eRXVqn72VIySp3wQ8GQc5fufXgKY0ybEiRVFluf4PNGgg969F_XR6FjHPX9i sw8aE6dT0wOXYovyPo_7uZ41UZg7C8lqPilJWiVykHZeIV_xiRFP928HPqqXc788INfyhLFZx6F2 LOTnVm8rSjnrjD0Fst.fper7dYgoCmVR0ceXvLzf3stmk8oKGC2_ENXvCzUNL5l6_hWud0ISYc4X Ot6MaxVs91E9ApDQCpITCTGHldhD8ZyqqiIaePyVLyXP7WeBShV5XZ8PbtW1yrVp5J138hcFDhPs DmV.Bys.NiBG.D_nk8NCaPIluKN0ra3CtgdRvVxZNHxBASSbXPfRNtcBqAm95kXpYw7fZ1nvXuTI AXyWRWrxuH48mpDGIUZq4udvScgEYyX2lt8M3dRw._JPU8y_XwRVMwZFXWBNpSmF1c5_EQ.t5Inc Vfq2VjC0qbf0eZA1dIK4q59.baxvWy.YG.IvPGZFf35Uz8jDuR0NgLqzovzQ203lpLQ6MbyatYxM _u53qm9w69tv4Dezkdd.nVPvrvgmrkzlfsGtiRYFP2jwkuGTCgVaJAUWT8H2S94FYcmGouea8fio NkCzU7bNy9Rj7.IbJ1egQaEp01dvR_7nVWWjiNOI8fn8mIZ1PXrVLlLkJdW673azi.8DQ6UjfogX LiWxbQpfopWYgd1TAwG4tbkgNK2vxrUEYjiH4BN9vY1Y4Lxx9SD2RTQBfGHq5woZ6wlL.lwzFPVK D_aWoJE_K7ehEQ49D_osDbBfpm0htuGlArMR5Mm5aKORwQf1UHjXzKSXfgc08ZeCoX6937hruP1l CEi07vHJCw2ZjeZawXaL..XAi7j.HT8L.tMLzB_4NR89plhBgoqrBWbPNM3FgCPQ7T67Gcxu0AWL dK1h2qVbb9IBwtLgmOHBOWlkKySYy8hq19nfC1BeEBFMLUDKyrpn_1BLCq7roaocSvApnVwqhOJa caHpsfXZNBQURiz6l01grpmgMx5dckUuifwmicXaOgVw1xnqJjl_RNZJcjVTxcNMX06xAgprjd0Y qB97Tp5JMDeylH8Cr0h.YntajmzOcq4RBLLUxsKwTNYi0dxdkUWFHDUOaWIE8A3x1d6o496TSLDz jM31e218sI1lq9oKDBA0cys_mhf5nLAL1RBSpHeNqMi39kBEN2.7N4lMuyiAdN6FSshoYSSe0jr. fw7IxQSjB7_AlFWIcwAP3r5._FtT6gJcZ0AHLTgzB3wtbRIADxD0BQhkIH79ubr48bPCApFrd2Bo lHVsupZn3B2StJN3zq6FLmwAClOh0JZsuIwa1idcIMS_nPZrGUpnuFDKq699GN1R3B_asgNYBQfC p0ak7DqlCjU9q1ni14loKjJEeJUMeeo5SNx5A95cvmVSkn4RLQppadHp8bvrfNB1ROPnLIc3px.n E5IyoyVnQhTtGpTZwZRqt5LTym6VpOLzCaOzW0OgC_pghcfh4LLifQdTAAig6aQ7OFqASQmh5yJ4 cUmcQq7RQIh2G5AUTeGe0EBPP5j6ZryGvJwtI4HjDxeZnPn.g_jUO6EIxozEiONbWBcUn..kwnX. cBNdbDlLGV9CMjQrBa.0fMF63rmoKm4s_SpCqnwpxFQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 4 Nov 2021 18:53:22 +0000 Received: by kubenode524.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 02270d59caa3878011c357f4f3b0b06d; Thu, 04 Nov 2021 18:53:20 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed In-Reply-To: Date: Thu, 4 Nov 2021 11:53:18 -0700 Cc: freebsd-arch@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: tech-lists X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HlXpf2SJGz3jb5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arch X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-4, at 07:50, tech-lists wrote: > On Wed, Nov 03, 2021 at 09:52:19AM -0700, Kevin Bowling wrote: >=20 >> FreeBSD wants any audience to help support the features they demand. = Since >> this particular audience has not, what may cause it to in the future? = Not a >> rhetorical question nor a vote for removing, this is a perennial = problem in >> open source and I am curious how you think this works so I can = incorporate >> it into my opinion. >=20 > Maybe the audience isn't demanding? It doesn't mean the audience isn't > there. perl and python and shell scripting work fine on these boards. = Issues with these things would I guess be taken up with those = maintainers. The hardware is very stable. I'd expect that a lot more = users might pipe up if their freebsd os needed updating for some newer = python only to find it couldn't be updated anymore. The first of those = to pipe up i'd guess be those with boards that have an internet-facing = connection, as the pressure to keep fully updated is a lot less within a = firewalled LAN. >=20 > OpenBSD immediately after install has an email on the system giving a > method to send in a dmesg. I don't know if it gives them a handle on = the > number of users and what their hardware is, but it's better than = nothing > at all, which is where FreeBSD is. Although there is a port called > sysutils/hw-probe, one needs to know about it first. It's not in base. >=20 > For armv6 in particular though, I've not heard of any reason = justifying > *why* getting rid of it. At least if it's in base we can compile ports > for it ourselves. mips/mips64 stopped because the working group = stopped > working with it, fair enough. This isn't the case with armv6. [This note is in part because a prior note oof mine did not make it to freebsd-arch.] Without one or more developers willing to keep ARM11 based RPi* FreeBSD working as FreeBSD updates, the code will break. Other architectures have been removed for such. Folks that do not want to work on such code do not want to have to work on it to keep FreeBSD building and operating for other architectures that have active developmers/maintainers. If there were active FreeBSD developers for ARM11 RPi*'s, the removal would have been unlikely to be proposed at all, even if the use was minor. FreeBSD is driven by the developer context directly, not the usage context directly. The usage context only drives things when the that context pays for developers to support the usage. (Think companies that use FreeBSD in a way that involves being sure supporting development and/or maintenance is done for the variant(s) they use.) [FreeBSD for aarch64 RPi*'s seems likely to suffer the same fate at some point because RPi* specifics are involved: generic aarch64 code is not sufficient. The aarch64 tier 1 status does not imply a requirement to support aarch64 RPi*'s.] > It might be helpful looking from another viewpoint - why is armv6 a > tier1 architecture on NetBSD? Something like, say, aarch64 being tier 1 on FreeBSD does not imply support for all existing and future aarch64 systems. The same goes for armv6. The same is true of NetBSD. NetBSD supports a lot of systems that FreeBSD does not. That fact has never justified having support for those systems in FreeBSD. FreeBSD has previously removed support for things NetBSD still supports. Different developers, different criteria. NetBSD will always be likely to support far more systems than FreeBSD. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Nov 5 16:31:34 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 A83B2182CF7E for ; Fri, 5 Nov 2021 16:31:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 4Hm5cg6F5Rz3lp3 for ; Fri, 5 Nov 2021 16:31:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92c.google.com with SMTP id s13so2604608uaj.11 for ; Fri, 05 Nov 2021 09:31:47 -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=XWpovILwkkT/FdYar/r3tqFINp6a731i2WShn5XSSLE=; b=pUs6u/ypszz3JBaAL3ibTQgTCEUJVamTTqBhYMuyDKX+Ag//ENIjj0T4piop+xwk6Q a4OMFQfkMJOQWSvWpMqdHNWmlARp/NzpXbRr3Bx2WHTsAG9Z77WnVZSCfJINllWMRmpO yu4NP7ABDZ5PDBfmLdBlZO6BRsZkZ3spx5fDZsk6kR41DQ10HI3dR1QABSnlZAhTj4NK Mf/igBbZNzyIH8JqXaFbCbAvXt1j4itM2oTIDqvaDfyxy17t8DMpkoaXZMpBvlK8pk86 dQNG3aiXnKkuMsx+RBBfScQn0KUTaQBsbaveeXG6+AwhR9PiGYTfVX2OoczyYQYjs6qZ fWGQ== 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=XWpovILwkkT/FdYar/r3tqFINp6a731i2WShn5XSSLE=; b=zuei6MDtvzM4jQa2ZRT4oBHugWwC4hvsttWXlnct21i5ytT0JSWW2PkmBM+6+ZjtLc r6GkPBXR3Mx1rRm1vqAVljxhm/GBurj/hrVCeG4xVn1+lAfBnfJcE9VNW6uJOtJnCHJz cpnaYg2PorIcuRUqftbVRXZ1nzB+d6YQQ21k9HYrbTbO3vSBLjQPULFKPxLjebW7U79r CW41OI8YGT937lT7PZtIPrZiuCIwIGfpCRTrrk5WOS+rRu6LKCK1kExv3oH+GstX4Kcv LhKBe5r5AaEJZyNbE4Ou1DXToGkCcxuRVyH1lMmrmDCPE+PDJdMgrZCBXxUZwcwkmC4x AODw== X-Gm-Message-State: AOAM533ZaI4i3X789gCPoBbPTej54HkxRoGGIXYlDeEWdYbGa0gEAtCA 9+S1A5xy0zaWs4hyyVwIh92MR5htHfsnXL0eLkOsIYwFjPRU/Q== X-Google-Smtp-Source: ABdhPJyKfw0nNvKmeoKrPgp8SP27y6MCOQ3f7d3AQSN6feHTCn+V8TJKUjHzChOrCzoiz4ZYqBIh90lPFdMjzHSYpus= X-Received: by 2002:a05:6102:3a0b:: with SMTP id b11mr73609866vsu.12.1636129906173; Fri, 05 Nov 2021 09:31: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: In-Reply-To: From: Warner Losh Date: Fri, 5 Nov 2021 10:31:34 -0600 Message-ID: Subject: Re: Firm Timeline for MIPS removal from FreeBSD To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000dd51f905d00d2d19" X-Rspamd-Queue-Id: 4Hm5cg6F5Rz3lp3 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="pUs6u/yp"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [2.99 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(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]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_SPAM_LONG(0.99)[0.990]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92c: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 --000000000000dd51f905d00d2d19 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 27, 2021 at 9:08 PM Warner Losh wrote: > Greetings, > > Please find enclosed my proposed firm timeline for the removal of mips > from FreeBSD, as previously discussed. There was no opposition to the plan > when I posted before. The major > users of FreeBSD/mips in the past have mostly moved on and they indicated > no objections > to the plan. And Adrian has committed his first arm port as well... > > So, I propose the following rather quick timeline: > > November 1: disconnect from tinderbox / universe. Add notices to > appropriate manuals and MFC them. > November 5: Post a review for its removal > November 15: commit the removal, assuming the review goes well. > > Comments? > I'm a few days behind. Here's some reviews: https://reviews.freebsd.org/D32851 Remove from universe https://reviews.freebsd.org/D32852 Document that 13.x is the last mips release https://reviews.freebsd.org/D32853 Add warning to mips buildworlds that it's being removed Please take a look and let me know what you think. Warner --000000000000dd51f905d00d2d19-- From nobody Wed Nov 10 16:26:50 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 616941843460; Wed, 10 Nov 2021 16:26:54 +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 4Hq9Gk2KfCz3Hrv; Wed, 10 Nov 2021 16:26:54 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from [192.168.1.106] (host-173-212-69-198.public.eastlink.ca [173.212.69.198]) (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 4F6AB3328B; Wed, 10 Nov 2021 16:26:52 +0000 (UTC) (envelope-from mhorne@freebsd.org) Content-Type: multipart/mixed; boundary="------------0qyuvJ5PYJ0S4nke6C1u0B1C" Message-ID: Date: Wed, 10 Nov 2021 12:26:50 -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.3.0 Content-Language: en-CA From: Mitchell Horne To: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Cc: cperciva@freebsd.org Subject: A new boot-time trace framework X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------0qyuvJ5PYJ0S4nke6C1u0B1C Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, For some time I have been working towards upstreaming the 'boottrace' feature, which captures boot-time and shutdown-time information as trace entries. This feature was developed by NetApp, and they have been using it internally to great success for several years. Its purpose is to aid in logging and identifying slow portions of boot or shutdown, spanning from kernel initialization through execution of rc scripts. It is driven by a simple sysctl interface, described in the main review (D30184). Boottrace has some functional overlap with the existing TSLOG framework, in that it captures timestamped entries of notable boot events in a buffer, for later inspection. This overlap has grown somewhat recently, as cperciva@'s work on reducing the overall system boot time extended TSLOG to capture trace data from userspace (see commit 46dd801acb23). Boottrace differs from TSLOG in the following ways: - Separate trace buffers for collecting run-time (post multiuser) and shutdown-time events - Does not cover the bootloader or early kernel initialization (tracing begins at SI_SUB_CPU) - Output log is human-readable, but not as suitable for generating flamegraphs (see the attached sample log) - Trace entries also record some resource usage of the invoking process (total CPU time, # of blocks in/out from disk) Given these differences, I believe the two can peacefully coexist. I would roughly characterize them as follows: boottrace may be most useful to a sysadmin/QA team, whereas TSLOG is a tool more suited to the needs of a developer and will provide more fine-grained and machine-readable information. 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. The changes span several areas, including the following: - Core boottrace module - Kernel initialization and shutdown paths - init(8), shutdown(8), and reboot(8) utilities - addition of a new boottrace(1) wrapper utility - RC framework (rc.subr) If you have an interest in any of the above areas, please add yourself to the review. If you have other feedback, I would be interested in hearing it here. The reviews: - https://reviews.freebsd.org/D30184 - https://reviews.freebsd.org/D30187 - https://reviews.freebsd.org/D31928 - https://reviews.freebsd.org/D31929 - https://reviews.freebsd.org/D31930 If you are interested in trying this feature, I have made it available on the following git branch: https://github.com/mhorne/freebsd/tree/netapp_boottrace Finally, I've attached a sample output from `sysctl kern.boottrace.log`, for a small bhyve VM. Cheers, Mitchell --------------0qyuvJ5PYJ0S4nke6C1u0B1C Content-Type: text/plain; charset=UTF-8; name="boottrace_log.txt" Content-Disposition: attachment; filename="boottrace_log.txt" Content-Transfer-Encoding: base64 a2Vybi5ib290dHJhY2UubG9nOiAKCkNQVSAgICAgIG1zZWNzICAgICAgZGVsdGEgcHJvY2Vz cyAgICAgICAgICAgICAgICAgIGV2ZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBQSUQgQ1BVdGltZSBJQmxrcyBPQmxrcwogIDAgICA0NDg3MjgxMSAgICAgICAg ICAwIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4MjEwMDAwMSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzI4 MTIgICAgICAgICAgMSBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweDIxMTAw MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAg MCAgIDQ0ODcyODEyICAgICAgICAgIDAga2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2lu aXQgMHgyMTQwMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAg MCAgICAgMAogIDAgICA0NDg3MjgxMiAgICAgICAgICAwIGtlcm5lbCAgICAgICAgICAgICAg ICAgICBzeXNpbml0IDB4MjE2MDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAg IDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzI4MTMgICAgICAgICAgMSBrZXJuZWwgICAg ICAgICAgICAgICAgICAgc3lzaW5pdCAweDIxODAwMDAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODcyODEzICAgICAgICAgIDAg a2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHgyMWQwMDAwICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3MjgxMyAg ICAgICAgICAwIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4MjFlMDAwMCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAg NDQ4NzI4MTMgICAgICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAw eDIyMDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAg ICAwCiAgMCAgIDQ0ODcyODE0ICAgICAgICAgIDEga2VybmVsICAgICAgICAgICAgICAgICAg IHN5c2luaXQgMHgyMzAwMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4w MCAgICAgMCAgICAgMAogIDAgICA0NDg3MjgxNyAgICAgICAgICAzIGtlcm5lbCAgICAgICAg ICAgICAgICAgICBzeXNpbml0IDB4MjM4MDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzI4MTcgICAgICAgICAgMCBrZXJu ZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweDI0MDAwMDAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODcyODE3ICAgICAg ICAgIDAga2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHgyNDgwMDAwICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3 MjgxNyAgICAgICAgICAwIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4MjRj MDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAK ICAwICAgNDQ4NzI4MTcgICAgICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lz aW5pdCAweDI1MDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAg ICAwICAgICAwCiAgMCAgIDQ0ODcyODE3ICAgICAgICAgIDAga2VybmVsICAgICAgICAgICAg ICAgICAgIHN5c2luaXQgMHgyNjAwMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAg ICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3MjgxNyAgICAgICAgICAwIGtlcm5lbCAg ICAgICAgICAgICAgICAgICBzeXNpbml0IDB4MjcwMDAwMCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzI4MTcgICAgICAgICAg MCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweDI4MDAwMDAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODczODIw ICAgICAgIDEwMDMga2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHgyODgwMDAw ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDAg ICA0NDg3MzgyMCAgICAgICAgICAwIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0 IDB4Mjg4ODAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAg ICAgIDAKICAwICAgNDQ4NzM4MjAgICAgICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAg ICAgc3lzaW5pdCAweDI5MDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAw LjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODczODUyICAgICAgICAgMzIga2VybmVsICAgICAg ICAgICAgICAgICAgIHN5c2luaXQgMHgyOTAwMDAxICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3Mzg1MiAgICAgICAgICAwIGtl cm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4MmEwMDAwMCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzM4NTIgICAg ICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweDJmMDAwMDAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0 ODczODUyICAgICAgICAgIDAga2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHgz MDAwMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAg MAogIDEgICA0NDg3Mzg1MiAgICAgICAgICAwIGtlcm5lbCAgICAgICAgICAgICAgICAgICBz eXNpbml0IDB4MzEwMDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAg ICAgIDAgICAgIDAKICAxICAgNDQ4NzM4NTUgICAgICAgICAgMyBrZXJuZWwgICAgICAgICAg ICAgICAgICAgc3lzaW5pdCAweDM4MDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc1NzIzICAgICAgIDE4Njgga2VybmVs ICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHg0MDAwMDAwICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NTcyNCAgICAgICAg ICAxIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4NDgwMDAwMCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzU3 MjYgICAgICAgICAgMiBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweDY0MDAw MDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAg MSAgIDQ0ODc1NzI2ICAgICAgICAgIDAga2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2lu aXQgMHg2ODAwMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg3NTcyNiAgICAgICAgICAwIGtlcm5lbCAgICAgICAgICAgICAg ICAgICBzeXNpbml0IDB4NmMwMDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAg IDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzU3MjYgICAgICAgICAgMCBrZXJuZWwgICAg ICAgICAgICAgICAgICAgc3lzaW5pdCAweDZlMDAwMDAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc1NzI2ICAgICAgICAgIDAg a2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHg3MDAwMDAwICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NTcyNyAg ICAgICAgICAxIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4NzQwMDAwMCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAg NDQ4NzU3MjcgICAgICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAw eDgxMDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAg ICAwCiAgMSAgIDQ0ODc1NzI3ICAgICAgICAgIDAga2VybmVsICAgICAgICAgICAgICAgICAg IHN5c2luaXQgMHg4NDAwMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4w MCAgICAgMCAgICAgMAogIDEgICA0NDg3NTcyNyAgICAgICAgICAwIGtlcm5lbCAgICAgICAg ICAgICAgICAgICBzeXNpbml0IDB4ODYwMDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzU3MjcgICAgICAgICAgMCBrZXJu ZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweDg3MDAwMDAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc1NzI3ICAgICAg ICAgIDAga2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHg4ODAwMDAwICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3 NTcyOCAgICAgICAgICAxIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4ODgw ODAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAK ICAxICAgNDQ4NzU3MjggICAgICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lz aW5pdCAweGEwMDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAg ICAwICAgICAwCiAgMSAgIDQ0ODc1NzMwICAgICAgICAgIDIga2VybmVsICAgICAgICAgICAg ICAgICAgIHN5c2luaXQgMHhhODAwMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAg ICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NTczMiAgICAgICAgICAyIGtlcm5lbCAg ICAgICAgICAgICAgICAgICBzeXNpbml0IDB4YWZmZmZmZiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzU3MzIgICAgICAgICAg MCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweGIwMDAwMDAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc1NzMy ICAgICAgICAgIDAga2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHhkMDAwMDAw ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDEg ICA0NDg3NTczMiAgICAgICAgICAwIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0 IDB4ZDgwMDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAg ICAgIDAKICAxICAgNDQ4NzU3MzIgICAgICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAg ICAgc3lzaW5pdCAweGRjMDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAw LjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc1NzMyICAgICAgICAgIDAga2VybmVsICAgICAg ICAgICAgICAgICAgIHN5c2luaXQgMHhkZmZmZjljICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NTczMiAgICAgICAgICAwIGtl cm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4ZTAwMDAwMCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzU3MzIgICAg ICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweGU0MDAwMDAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0 ODc1NzMyICAgICAgICAgIDAga2VybmVsICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHhl ODAwMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAg MAogIDEgICA0NDg3NTczMiAgICAgICAgICAwIGtlcm5lbCAgICAgICAgICAgICAgICAgICBz eXNpbml0IDB4ZWEwMDAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAg ICAgIDAgICAgIDAKICAxICAgNDQ4NzU3MzUgICAgICAgICAgMyBrZXJuZWwgICAgICAgICAg ICAgICAgICAgc3lzaW5pdCAweGVjMDAwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc1NzM1ICAgICAgICAgIDAga2VybmVs ICAgICAgICAgICAgICAgICAgIHN5c2luaXQgMHhlZTAwMDAwICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDAgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NTczNSAgICAgICAg ICAwIGtlcm5lbCAgICAgICAgICAgICAgICAgICBzeXNpbml0IDB4ZjEwMDAwMCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzU3 MzUgICAgICAgICAgMCBrZXJuZWwgICAgICAgICAgICAgICAgICAgc3lzaW5pdCAweGZmZmZm ZmYgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAwLjAwICAgICAwICAgICAwCiAg MSAgIDQ0ODc1NzM1ICAgICAgICAgIDAgc3dhcHBlciAgICAgICAgICAgICAgICAgIG1pX3N0 YXJ0dXAgZG9uZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgMC4wMCAgICAg MCAgICAgMAogIDAgICA0NDg3NTc1MCAgICAgICAgIDE1IGluaXQgICAgICAgICAgICAgICAg ICAgICBpbml0KDgpIHN0YXJ0aW5nLi4uICAgICAgICAgICAgICAgICAgICAgICAgICAxICAg IDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzU3NTEgICAgICAgICAgMSBpbml0ICAgICAg ICAgICAgICAgICAgICAgL2V0Yy9yYyBzdGFydGluZy4uLiAgICAgICAgICAgICAgICAgICAg ICAgICAgMSAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc1ODMxICAgICAgICAgODAg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9yY3RsIHN0YXJ0ICAgICAgICAg ICAgICAgICAgICAgICAgMjYgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NTgzOSAg ICAgICAgICA4IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvcmN0bCBkb25l ICAgICAgICAgICAgICAgICAgICAgICAgIDI2ICAgIDAuMDAgICAgIDIgICAgIDAKICAxICAg NDQ4NzU4MzkgICAgICAgICAgMCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L2R1bXBvbiBzdGFydCAgICAgICAgICAgICAgICAgICAgICAzMSAgICAwLjAwICAgICAwICAg ICAwCiAgMCAgIDQ0ODc1ODYxICAgICAgICAgMjIgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9kdW1wb24gZG9uZSAgICAgICAgICAgICAgICAgICAgICAgMzEgICAgMC4w MSAgICAzNyAgICAgMAogIDAgICA0NDg3NTg2MSAgICAgICAgICAwIGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvc3lzY3RsIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAg IDQwICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzU4NzggICAgICAgICAxNyBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3N5c2N0bCBkb25lICAgICAgICAgICAg ICAgICAgICAgICA0MCAgICAwLjAxICAgIDE3ICAgICAwCiAgMCAgIDQ0ODc1ODc4ICAgICAg ICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9ob3N0aWQgc3RhcnQg ICAgICAgICAgICAgICAgICAgICAgNDkgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3 NTg5MiAgICAgICAgIDE0IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaG9z dGlkIGRvbmUgICAgICAgICAgICAgICAgICAgICAgIDQ5ICAgIDAuMDEgICAgMTIgICAgIDAK ICAxICAgNDQ4NzU4OTMgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL2RkYiBzdGFydCAgICAgICAgICAgICAgICAgICAgICAgICA2MCAgICAwLjAwICAg ICAwICAgICAwCiAgMCAgIDQ0ODc1OTA3ICAgICAgICAgMTQgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9kZGIgZG9uZSAgICAgICAgICAgICAgICAgICAgICAgICAgNjAg ICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg3NTkwOCAgICAgICAgICAxIGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvZ2JkZSBzdGFydCAgICAgICAgICAgICAgICAg ICAgICAgIDY4ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzU5MTQgICAgICAgICAg NiBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2diZGUgZG9uZSAgICAgICAg ICAgICAgICAgICAgICAgICA2OCAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc1OTE0 ICAgICAgICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9jY2Qgc3Rh cnQgICAgICAgICAgICAgICAgICAgICAgICAgNzQgICAgMC4wMCAgICAgMCAgICAgMAogIDAg ICA0NDg3NTkxOSAgICAgICAgICA1IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvY2NkIGRvbmUgICAgICAgICAgICAgICAgICAgICAgICAgIDc0ICAgIDAuMDAgICAgIDAg ICAgIDAKICAwICAgNDQ4NzU5MjAgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2dlbGkgc3RhcnQgICAgICAgICAgICAgICAgICAgICAgICA3OSAgICAw LjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc1OTI2ICAgICAgICAgIDYgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9nZWxpIGRvbmUgICAgICAgICAgICAgICAgICAgICAg ICAgNzkgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3NTkyNiAgICAgICAgICAwIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvenBvb2wgc3RhcnQgICAgICAgICAg ICAgICAgICAgICAgIDg1ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzU5MzEgICAg ICAgICAgNSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3pwb29sIGRvbmUg ICAgICAgICAgICAgICAgICAgICAgICA4NSAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0 ODc1OTMyICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9z d2FwIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgICAgOTAgICAgMC4wMCAgICAgMCAgICAg MAogIDAgICA0NDg3NTkzOSAgICAgICAgICA3IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvc3dhcCBkb25lICAgICAgICAgICAgICAgICAgICAgICAgIDkwICAgIDAuMDAg ICAgIDEgICAgIDAKICAwICAgNDQ4NzU5MzkgICAgICAgICAgMCBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL2ZzY2sgc3RhcnQgICAgICAgICAgICAgICAgICAgICAgICA5 NiAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc1OTQ0ICAgICAgICAgIDUgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9mc2NrIGRvbmUgICAgICAgICAgICAgICAg ICAgICAgICAgOTYgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3NTk0NSAgICAgICAg ICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvenZvbCBzdGFydCAgICAg ICAgICAgICAgICAgICAgICAgMTAxICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzU5 NTAgICAgICAgICAgNSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3p2b2wg ZG9uZSAgICAgICAgICAgICAgICAgICAgICAgIDEwMSAgICAwLjAwICAgICAwICAgICAwCiAg MCAgIDQ0ODc1OTUxICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9yb290IHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgICAxMDYgICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg3NTk2NCAgICAgICAgIDEzIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvcm9vdCBkb25lICAgICAgICAgICAgICAgICAgICAgICAgMTA2ICAg IDAuMDEgICAgIDcgICAgIDIKICAxICAgNDQ4NzU5NjUgICAgICAgICAgMSBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3NwcHAgc3RhcnQgICAgICAgICAgICAgICAgICAg ICAgIDExNSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc1OTczICAgICAgICAgIDgg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9zcHBwIGRvbmUgICAgICAgICAg ICAgICAgICAgICAgICAxMTUgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NTk3NCAg ICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbWRjb25maWcg c3RhcnQgICAgICAgICAgICAgICAgICAgMTIwICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAg NDQ4NzU5ODUgICAgICAgICAxMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L21kY29uZmlnIGRvbmUgICAgICAgICAgICAgICAgICAgIDEyMCAgICAwLjAxICAgICAwICAg ICAwCiAgMCAgIDQ0ODc1OTg2ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9ob3N0aWRfc2F2ZSBzdGFydCAgICAgICAgICAgICAgICAxMjggICAgMC4w MCAgICAgMCAgICAgMAogIDEgICA0NDg3NTk5MiAgICAgICAgICA2IGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvaG9zdGlkX3NhdmUgZG9uZSAgICAgICAgICAgICAgICAg MTI4ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzU5OTMgICAgICAgICAgMSBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3NlcmlhbCBzdGFydCAgICAgICAgICAg ICAgICAgICAgIDEzNCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc1OTk0ICAgICAg ICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9zZXJpYWwgZG9uZSAg ICAgICAgICAgICAgICAgICAgICAxMzQgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3 NTk5NSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbW91 bnRjcml0bG9jYWwgc3RhcnQgICAgICAgICAgICAgMTM2ICAgIDAuMDAgICAgIDAgICAgIDAK ICAxICAgNDQ4NzYwMDggICAgICAgICAxMyBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL21vdW50Y3JpdGxvY2FsIGRvbmUgICAgICAgICAgICAgIDEzNiAgICAwLjAwICAg IDY3ICAgICAxCiAgMSAgIDQ0ODc2MDA5ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC96ZnNiZSBzdGFydCAgICAgICAgICAgICAgICAgICAgICAxNDMg ICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NjAxNCAgICAgICAgICA1IGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvemZzYmUgZG9uZSAgICAgICAgICAgICAgICAg ICAgICAgMTQzICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzYwMTUgICAgICAgICAg MSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3RtcCBzdGFydCAgICAgICAg ICAgICAgICAgICAgICAgIDE0OCAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc2MDI0 ICAgICAgICAgIDkgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC90bXAgZG9u ZSAgICAgICAgICAgICAgICAgICAgICAgICAxNDggICAgMC4wMCAgICAgNSAgICAgMAogIDAg ICA0NDg3NjAyNSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvZ3NzZCBzdGFydCAgICAgICAgICAgICAgICAgICAgICAgMTU4ICAgIDAuMDAgICAgIDAg ICAgIDAKICAxICAgNDQ4NzYwMzkgICAgICAgICAxNCBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2dzc2QgZG9uZSAgICAgICAgICAgICAgICAgICAgICAgIDE1OCAgICAw LjAxICAgICAwICAgICAwCiAgMSAgIDQ0ODc2MDQwICAgICAgICAgIDEgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9rbGR4cmVmIHN0YXJ0ICAgICAgICAgICAgICAgICAg ICAxNjYgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NjA0NyAgICAgICAgICA3IGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQva2xkeHJlZiBkb25lICAgICAgICAg ICAgICAgICAgICAgMTY2ICAgIDAuMDAgICAgIDUgICAgIDAKICAxICAgNDQ4NzYwNDggICAg ICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3pmcyBzdGFydCAg ICAgICAgICAgICAgICAgICAgICAgIDE3MiAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0 ODc2MDU0ICAgICAgICAgIDYgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC96 ZnMgZG9uZSAgICAgICAgICAgICAgICAgICAgICAgICAxNzIgICAgMC4wMCAgICAgMCAgICAg MAogIDEgICA0NDg3NjA1NCAgICAgICAgICAwIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQva2xkIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgICAgMTc3ICAgIDAuMDAg ICAgIDAgICAgIDAKICAxICAgNDQ4NzYwNjAgICAgICAgICAgNiBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL2tsZCBkb25lICAgICAgICAgICAgICAgICAgICAgICAgIDE3 NyAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc2MDYxICAgICAgICAgIDEgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9zeXN2aXBjIHN0YXJ0ICAgICAgICAgICAg ICAgICAgICAxODIgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NjA2NiAgICAgICAg ICA1IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvc3lzdmlwYyBkb25lICAg ICAgICAgICAgICAgICAgICAgMTgyICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzYw NjcgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2xpbnV4 IHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgIDE4NyAgICAwLjAwICAgICAwICAgICAwCiAg MSAgIDQ0ODc2MDcyICAgICAgICAgIDUgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9saW51eCBkb25lICAgICAgICAgICAgICAgICAgICAgICAxODcgICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg3NjA3MyAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvdmFyIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgICAgMTkyICAg IDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzYwODEgICAgICAgICAgOCBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3ZhciBkb25lICAgICAgICAgICAgICAgICAgICAg ICAgIDE5MiAgICAwLjAwICAgICAxICAgICAwCiAgMSAgIDQ0ODc2MDgxICAgICAgICAgIDAg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9kZXZtYXRjaCBzdGFydCAgICAg ICAgICAgICAgICAgICAxOTkgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3NjA5MSAg ICAgICAgIDEwIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvZGV2bWF0Y2gg ZG9uZSAgICAgICAgICAgICAgICAgICAgMTk5ICAgIDAuMDAgICAgIDkgICAgIDAKICAwICAg NDQ4NzYwOTIgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L2xvY2FscGtnIHN0YXJ0ICAgICAgICAgICAgICAgICAgIDIwNyAgICAwLjAwICAgICAwICAg ICAwCiAgMCAgIDQ0ODc2MTAzICAgICAgICAgMTEgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9sb2NhbHBrZyBkb25lICAgICAgICAgICAgICAgICAgICAyMDcgICAgMC4w MCAgICAgNyAgICAgMAogIDAgICA0NDg3NjEwNCAgICAgICAgICAxIGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvY2xlYW52YXIgc3RhcnQgICAgICAgICAgICAgICAgICAg MjE0ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzYxMTcgICAgICAgICAxMyBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2NsZWFudmFyIGRvbmUgICAgICAgICAg ICAgICAgICAgIDIxNCAgICAwLjAwICAgIDE1ICAgICAwCiAgMCAgIDQ0ODc2MTE4ICAgICAg ICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9jZnVtYXNzIHN0YXJ0 ICAgICAgICAgICAgICAgICAgICAyMjIgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3 NjEyNCAgICAgICAgICA2IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvY2Z1 bWFzcyBkb25lICAgICAgICAgICAgICAgICAgICAgMjIyICAgIDAuMDAgICAgIDAgICAgIDAK ICAwICAgNDQ4NzYxMjUgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL0ZJTEVTWVNURU1TIHN0YXJ0ICAgICAgICAgICAgICAgIDIyNyAgICAwLjAwICAg ICAwICAgICAwCiAgMCAgIDQ0ODc2MTI2ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9GSUxFU1lTVEVNUyBkb25lICAgICAgICAgICAgICAgICAyMjcg ICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3NjEzMyAgICAgICAgICA3IGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaXBwb29sIHN0YXJ0ICAgICAgICAgICAgICAg ICAgICAgMjMxICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzYxNDQgICAgICAgICAx MSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2lwcG9vbCBkb25lICAgICAg ICAgICAgICAgICAgICAgIDIzMSAgICAwLjAxICAgICAwICAgICAwCiAgMSAgIDQ0ODc2MTQ1 ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9sZGNvbmZp ZyBzdGFydCAgICAgICAgICAgICAgICAgICAyMzkgICAgMC4wMCAgICAgMCAgICAgMAogIDAg ICA0NDg3NjE2MyAgICAgICAgIDE4IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvbGRjb25maWcgZG9uZSAgICAgICAgICAgICAgICAgICAgMjM5ICAgIDAuMDEgICAgMTcg ICAgIDAKICAwICAgNDQ4NzYxNjMgICAgICAgICAgMCBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2Fkamtlcm50eiBzdGFydCAgICAgICAgICAgICAgICAgIDI1MSAgICAw LjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc2MTcwICAgICAgICAgIDcgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9hZGprZXJudHogZG9uZSAgICAgICAgICAgICAgICAg ICAyNTEgICAgMC4wMCAgICAgMSAgICAgMAogIDAgICA0NDg3NjE3MSAgICAgICAgICAxIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaG9zdG5hbWUgc3RhcnQgICAgICAg ICAgICAgICAgICAgMjU3ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzYxODMgICAg ICAgICAxMiBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2hvc3RuYW1lIGRv bmUgICAgICAgICAgICAgICAgICAgIDI1NyAgICAwLjAxICAgICAzICAgICAwCiAgMCAgIDQ0 ODc2MTg0ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9p cDZhZGRyY3RsIHN0YXJ0ICAgICAgICAgICAgICAgICAyNjUgICAgMC4wMCAgICAgMCAgICAg MAogIDAgICA0NDg3NjE5OSAgICAgICAgIDE1IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvaXA2YWRkcmN0bCBkb25lICAgICAgICAgICAgICAgICAgMjY1ICAgIDAuMDEg ICAgIDMgICAgIDAKICAwICAgNDQ4NzYyMDAgICAgICAgICAgMSBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL25ldG9wdGlvbnMgc3RhcnQgICAgICAgICAgICAgICAgIDI3 NSAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc2MjE2ICAgICAgICAgMTYgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9uZXRvcHRpb25zIGRvbmUgICAgICAgICAg ICAgICAgICAyNzUgICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg3NjIxNyAgICAgICAg ICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvb3BlbnNtIHN0YXJ0ICAg ICAgICAgICAgICAgICAgICAgMjkwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4NzYy MjggICAgICAgICAxMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL29wZW5z bSBkb25lICAgICAgICAgICAgICAgICAgICAgIDI5MCAgICAwLjAxICAgICAwICAgICAwCiAg MSAgIDQ0ODc2MjI4ICAgICAgICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9yYW5kb20gc3RhcnQgICAgICAgICAgICAgICAgICAgICAyOTggICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg3NjM1NiAgICAgICAgMTI4IGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvcmFuZG9tIGRvbmUgICAgICAgICAgICAgICAgICAgICAgMjk4ICAg IDAuMDIgICAgIDcgICAgIDkKICAxICAgNDQ4NzYzNTYgICAgICAgICAgMCBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2lvdmN0bCBzdGFydCAgICAgICAgICAgICAgICAg ICAgIDMxOSAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc2MzY2ICAgICAgICAgMTAg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9pb3ZjdGwgZG9uZSAgICAgICAg ICAgICAgICAgICAgICAzMTkgICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg3NjM2NyAg ICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaXBzZWMgc3Rh cnQgICAgICAgICAgICAgICAgICAgICAgMzI3ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAg NDQ4NzYzNzcgICAgICAgICAxMCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L2lwc2VjIGRvbmUgICAgICAgICAgICAgICAgICAgICAgIDMyNyAgICAwLjAxICAgICAwICAg ICAwCiAgMSAgIDQ0ODc2Mzc4ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9taXhlciBzdGFydCAgICAgICAgICAgICAgICAgICAgICAzMzUgICAgMC4w MCAgICAgMCAgICAgMAogIDAgICA0NDg3NjM4NSAgICAgICAgICA3IGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvbWl4ZXIgZG9uZSAgICAgICAgICAgICAgICAgICAgICAg MzM1ICAgIDAuMDAgICAgIDEgICAgIDAKICAwICAgNDQ4NzYzODYgICAgICAgICAgMSBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3VnaWRmdyBzdGFydCAgICAgICAgICAg ICAgICAgICAgIDM0MSAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODc2MzkxICAgICAg ICAgIDUgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC91Z2lkZncgZG9uZSAg ICAgICAgICAgICAgICAgICAgICAzNDEgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3 NjM5MiAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvZ2Vs aTIgc3RhcnQgICAgICAgICAgICAgICAgICAgICAgMzQ2ICAgIDAuMDAgICAgIDAgICAgIDAK ICAwICAgNDQ4NzYzOTcgICAgICAgICAgNSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL2dlbGkyIGRvbmUgICAgICAgICAgICAgICAgICAgICAgIDM0NiAgICAwLjAwICAg ICAwICAgICAwCiAgMCAgIDQ0ODc2Mzk4ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9hdXRvdW5tb3VudGQgc3RhcnQgICAgICAgICAgICAgICAzNTIg ICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg3NjQwNCAgICAgICAgICA2IGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvYXV0b3VubW91bnRkIGRvbmUgICAgICAgICAg ICAgICAgMzUyICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4NzY0MDQgICAgICAgICAg MCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2lwZmlsdGVyIHN0YXJ0ICAg ICAgICAgICAgICAgICAgIDM1OCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODc2NDE0 ICAgICAgICAgMTAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9pcGZpbHRl ciBkb25lICAgICAgICAgICAgICAgICAgICAzNTggICAgMC4wMSAgICAgMCAgICAgMAogIDEg ICA0NDg3NjQxNSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvaXBuYXQgc3RhcnQgICAgICAgICAgICAgICAgICAgICAgMzY2ICAgIDAuMDAgICAgIDAg ICAgIDAKICAwICAgNDQ4NzY0MjQgICAgICAgICAgOSBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2lwbmF0IGRvbmUgICAgICAgICAgICAgICAgICAgICAgIDM2NiAgICAw LjAxICAgICAwICAgICAwCiAgMCAgIDQ0ODc2NDI1ICAgICAgICAgIDEgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9pcG1vbiBzdGFydCAgICAgICAgICAgICAgICAgICAg ICAzNzQgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg3NjQzNSAgICAgICAgIDEwIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaXBtb24gZG9uZSAgICAgICAgICAg ICAgICAgICAgICAgMzc0ICAgIDAuMDEgICAgIDAgICAgIDAKICAxICAgNDQ4NzY0MzYgICAg ICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2lwZnMgc3RhcnQg ICAgICAgICAgICAgICAgICAgICAgIDM4MiAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0 ODc2NDQ2ICAgICAgICAgMTAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9p cGZzIGRvbmUgICAgICAgICAgICAgICAgICAgICAgICAzODIgICAgMC4wMSAgICAgMCAgICAg MAogIDAgICA0NDg3NjQ0NiAgICAgICAgICAwIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvbmV0aWYgc3RhcnQgICAgICAgICAgICAgICAgICAgICAgMzkwICAgIDAuMDAg ICAgIDAgICAgIDAKICAxICAgNDQ4ODExMTYgICAgICAgNDY3MCBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL25ldGlmIGRvbmUgICAgICAgICAgICAgICAgICAgICAgIDM5 MCAgICAwLjEyICAgIDM0ICAgICAwCiAgMSAgIDQ0ODgxMTE3ICAgICAgICAgIDEgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9wZmxvZyBzdGFydCAgICAgICAgICAgICAg ICAgICAgICA1NjQgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MTEyMyAgICAgICAg ICA2IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvcGZsb2cgZG9uZSAgICAg ICAgICAgICAgICAgICAgICAgNTY0ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODEx MjQgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3J0c29s ZCBzdGFydCAgICAgICAgICAgICAgICAgICAgIDU3MCAgICAwLjAwICAgICAwICAgICAwCiAg MSAgIDQ0ODgxMTMxICAgICAgICAgIDcgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9ydHNvbGQgZG9uZSAgICAgICAgICAgICAgICAgICAgICA1NzAgICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg4MTEzMyAgICAgICAgICAyIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvc3RhdGljX25kcCBzdGFydCAgICAgICAgICAgICAgICAgNTc2ICAg IDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODExNDAgICAgICAgICAgNyBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3N0YXRpY19uZHAgZG9uZSAgICAgICAgICAgICAg ICAgIDU3NiAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgxMTQxICAgICAgICAgIDEg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9zdGF0aWNfYXJwIHN0YXJ0ICAg ICAgICAgICAgICAgICA1ODEgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MTE0OCAg ICAgICAgICA3IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvc3RhdGljX2Fy cCBkb25lICAgICAgICAgICAgICAgICAgNTgxICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAg NDQ4ODExNDkgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L3N0ZiBzdGFydCAgICAgICAgICAgICAgICAgICAgICAgIDU4NiAgICAwLjAwICAgICAwICAg ICAwCiAgMSAgIDQ0ODgxMTU2ICAgICAgICAgIDcgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9zdGYgZG9uZSAgICAgICAgICAgICAgICAgICAgICAgICA1ODYgICAgMC4w MCAgICAgMCAgICAgMAogIDEgICA0NDg4MTE1NiAgICAgICAgICAwIGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvcmVzb2x2IHN0YXJ0ICAgICAgICAgICAgICAgICAgICAg NTkxICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODExNjMgICAgICAgICAgNyBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3Jlc29sdiBkb25lICAgICAgICAgICAg ICAgICAgICAgIDU5MSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgxMTY0ICAgICAg ICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9kZXZkIHN0YXJ0ICAg ICAgICAgICAgICAgICAgICAgICA1OTcgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4 MTUzOSAgICAgICAgMzc1IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvZGV2 ZCBkb25lICAgICAgICAgICAgICAgICAgICAgICAgNTk3ICAgIDAuMjIgICAgNjggICAgIDMK ICAxICAgNDQ4ODE1NDAgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL3BwcCBzdGFydCAgICAgICAgICAgICAgICAgICAgICAgIDgxMyAgICAwLjAwICAg ICAwICAgICAwCiAgMSAgIDQ0ODgxNTU0ICAgICAgICAgMTQgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9wcHAgZG9uZSAgICAgICAgICAgICAgICAgICAgICAgICA4MTMg ICAgMC4wMSAgICAgMSAgICAgMAogIDEgICA0NDg4MTU1NSAgICAgICAgICAxIGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvcGZzeW5jIHN0YXJ0ICAgICAgICAgICAgICAg ICAgICAgODIyICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODE1NjIgICAgICAgICAg NyBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3Bmc3luYyBkb25lICAgICAg ICAgICAgICAgICAgICAgIDgyMiAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgxNTYz ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9yb3V0aW5n IHN0YXJ0ICAgICAgICAgICAgICAgICAgICA4MjcgICAgMC4wMCAgICAgMCAgICAgMAogIDEg ICA0NDg4MTYwNiAgICAgICAgIDQzIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvcm91dGluZyBkb25lICAgICAgICAgICAgICAgICAgICAgODI3ICAgIDAuMDQgICAgIDEg ICAgIDAKICAxICAgNDQ4ODE2MDcgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2RlZmF1bHRyb3V0ZSBzdGFydCAgICAgICAgICAgICAgIDg2NyAgICAw LjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgxNjIxICAgICAgICAgMTQgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9kZWZhdWx0cm91dGUgZG9uZSAgICAgICAgICAgICAg ICA4NjcgICAgMC4wMSAgICAgMCAgICAgMAogIDEgICA0NDg4MTYyMSAgICAgICAgICAwIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaXBmdyBzdGFydCAgICAgICAgICAg ICAgICAgICAgICAgODgxICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODE2MzAgICAg ICAgICAgOSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2lwZncgZG9uZSAg ICAgICAgICAgICAgICAgICAgICAgIDg4MSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0 ODgxNjMwICAgICAgICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC96 ZnNkIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgICA4ODYgICAgMC4wMCAgICAgMCAgICAg MAogIDAgICA0NDg4MTY0MSAgICAgICAgIDExIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvemZzZCBkb25lICAgICAgICAgICAgICAgICAgICAgICAgODg2ICAgIDAuMDEg ICAgIDAgICAgIDAKICAwICAgNDQ4ODE2NDEgICAgICAgICAgMCBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL2JyaWRnZSBzdGFydCAgICAgICAgICAgICAgICAgICAgIDg5 NCAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgxNjQ5ICAgICAgICAgIDggYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9icmlkZ2UgZG9uZSAgICAgICAgICAgICAg ICAgICAgICA4OTQgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MTY0OSAgICAgICAg ICAwIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaXBmd19uZXRmbG93IHN0 YXJ0ICAgICAgICAgICAgICAgODk5ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODE2 NTYgICAgICAgICAgNyBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2lwZndf bmV0ZmxvdyBkb25lICAgICAgICAgICAgICAgIDg5OSAgICAwLjAwICAgICAwICAgICAwCiAg MCAgIDQ0ODgxNjU3ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9wZiBzdGFydCAgICAgICAgICAgICAgICAgICAgICAgICA5MDQgICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg4MTY3MCAgICAgICAgIDEzIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvcGYgZG9uZSAgICAgICAgICAgICAgICAgICAgICAgICAgOTA0ICAg IDAuMDEgICAgIDAgICAgIDAKICAxICAgNDQ4ODE2NzAgICAgICAgICAgMCBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3JvdXRlZCBzdGFydCAgICAgICAgICAgICAgICAg ICAgIDkxMiAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgxNjgyICAgICAgICAgMTIg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9yb3V0ZWQgZG9uZSAgICAgICAg ICAgICAgICAgICAgICA5MTIgICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg4MTY4MyAg ICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvcm91dGU2ZCBz dGFydCAgICAgICAgICAgICAgICAgICAgOTIwICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAg NDQ4ODE2OTUgICAgICAgICAxMiBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L3JvdXRlNmQgZG9uZSAgICAgICAgICAgICAgICAgICAgIDkyMCAgICAwLjAxICAgICAwICAg ICAwCiAgMSAgIDQ0ODgxNjk2ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9uZXR3YWl0IHN0YXJ0ICAgICAgICAgICAgICAgICAgICA5MjggICAgMC4w MCAgICAgMCAgICAgMAogIDEgICA0NDg4MTcwMiAgICAgICAgICA2IGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvbmV0d2FpdCBkb25lICAgICAgICAgICAgICAgICAgICAg OTI4ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODE3MDIgICAgICAgICAgMCBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2JsYWNrbGlzdGQgc3RhcnQgICAgICAg ICAgICAgICAgIDkzMyAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgxNzE4ICAgICAg ICAgMTYgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9ibGFja2xpc3RkIGRv bmUgICAgICAgICAgICAgICAgICA5MzMgICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg4 MTcxOSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbG9j YWxfdW5ib3VuZCBzdGFydCAgICAgICAgICAgICAgOTQxICAgIDAuMDAgICAgIDAgICAgIDAK ICAwICAgNDQ4ODE3MjUgICAgICAgICAgNiBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL2xvY2FsX3VuYm91bmQgZG9uZSAgICAgICAgICAgICAgIDk0MSAgICAwLjAwICAg ICAwICAgICAwCiAgMCAgIDQ0ODgxNzI2ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9ORVRXT1JLSU5HIHN0YXJ0ICAgICAgICAgICAgICAgICA5NDcg ICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MTcyNyAgICAgICAgICAxIGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvTkVUV09SS0lORyBkb25lICAgICAgICAgICAg ICAgICAgOTQ3ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODE3MjggICAgICAgICAg MSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL25mc3VzZXJkIHN0YXJ0ICAg ICAgICAgICAgICAgICAgIDk0OSAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgxNzM4 ICAgICAgICAgMTAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9uZnN1c2Vy ZCBkb25lICAgICAgICAgICAgICAgICAgICA5NDkgICAgMC4wMSAgICAgMCAgICAgMAogIDAg ICA0NDg4MTczOSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvdGxzY2xudGQgc3RhcnQgICAgICAgICAgICAgICAgICAgOTU3ICAgIDAuMDAgICAgIDAg ICAgIDAKICAwICAgNDQ4ODE3NDcgICAgICAgICAgOCBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL3Rsc2NsbnRkIGRvbmUgICAgICAgICAgICAgICAgICAgIDk1NyAgICAw LjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgxNzQ4ICAgICAgICAgIDEgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9rZGMgc3RhcnQgICAgICAgICAgICAgICAgICAgICAg ICA5NjMgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MTc1OCAgICAgICAgIDEwIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQva2RjIGRvbmUgICAgICAgICAgICAg ICAgICAgICAgICAgOTYzICAgIDAuMDEgICAgIDAgICAgIDAKICAxICAgNDQ4ODE3NTggICAg ICAgICAgMCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2N0bGQgc3RhcnQg ICAgICAgICAgICAgICAgICAgICAgIDk3MSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0 ODgxNzY0ICAgICAgICAgIDYgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9j dGxkIGRvbmUgICAgICAgICAgICAgICAgICAgICAgICA5NzEgICAgMC4wMCAgICAgMCAgICAg MAogIDEgICA0NDg4MTc2NSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvaXNjc2lkIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgOTc3ICAgIDAuMDAg ICAgIDAgICAgIDAKICAxICAgNDQ4ODE3NzEgICAgICAgICAgNiBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL2lzY3NpZCBkb25lICAgICAgICAgICAgICAgICAgICAgIDk3 NyAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgxNzcxICAgICAgICAgIDAgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC90bHNzZXJ2ZCBzdGFydCAgICAgICAgICAg ICAgICAgICA5ODMgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MTc3NyAgICAgICAg ICA2IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvdGxzc2VydmQgZG9uZSAg ICAgICAgICAgICAgICAgICAgOTgzICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODE3 NzggICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3BwcG9l ZCBzdGFydCAgICAgICAgICAgICAgICAgICAgIDk4OSAgICAwLjAwICAgICAwICAgICAwCiAg MCAgIDQ0ODgxNzgzICAgICAgICAgIDUgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9wcHBvZWQgZG9uZSAgICAgICAgICAgICAgICAgICAgICA5ODkgICAgMC4wMCAgICAg MCAgICAgMAogIDAgICA0NDg4MTc4NCAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQva2ZkIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgICAgOTk0ICAg IDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODE3OTMgICAgICAgICAgOSBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2tmZCBkb25lICAgICAgICAgICAgICAgICAgICAg ICAgIDk5NCAgICAwLjAxICAgICAwICAgICAwCiAgMSAgIDQ0ODgxNzk0ICAgICAgICAgIDEg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9rYWRtaW5kIHN0YXJ0ICAgICAg ICAgICAgICAgICAgIDEwMDIgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MTgwMyAg ICAgICAgICA5IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQva2FkbWluZCBk b25lICAgICAgICAgICAgICAgICAgICAxMDAyICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAg NDQ4ODE4MDQgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L2twYXNzd2RkIHN0YXJ0ICAgICAgICAgICAgICAgICAgMTAxMCAgICAwLjAwICAgICAwICAg ICAwCiAgMSAgIDQ0ODgxODE0ICAgICAgICAgMTAgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9rcGFzc3dkZCBkb25lICAgICAgICAgICAgICAgICAgIDEwMTAgICAgMC4w MCAgICAgMCAgICAgMAogIDEgICA0NDg4MTgxNCAgICAgICAgICAwIGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvaXNjc2ljdGwgc3RhcnQgICAgICAgICAgICAgICAgICAx MDE4ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODE4MjQgICAgICAgICAxMCBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2lzY3NpY3RsIGRvbmUgICAgICAgICAg ICAgICAgICAgMTAxOCAgICAwLjAxICAgICAwICAgICAwCiAgMCAgIDQ0ODgxODI0ICAgICAg ICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9uZnNjYmQgc3RhcnQg ICAgICAgICAgICAgICAgICAgIDEwMjYgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4 MTgzNCAgICAgICAgIDEwIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbmZz Y2JkIGRvbmUgICAgICAgICAgICAgICAgICAgICAxMDI2ICAgIDAuMDAgICAgIDAgICAgIDAK ICAxICAgNDQ4ODE4MzQgICAgICAgICAgMCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL2lwcm9wZF9tYXN0ZXIgc3RhcnQgICAgICAgICAgICAgMTAzNCAgICAwLjAwICAg ICAwICAgICAwCiAgMCAgIDQ0ODgxODQ0ICAgICAgICAgMTAgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9pcHJvcGRfbWFzdGVyIGRvbmUgICAgICAgICAgICAgIDEwMzQg ICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg4MTg0NCAgICAgICAgICAwIGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaXByb3BkX3NsYXZlIHN0YXJ0ICAgICAgICAg ICAgICAxMDQyICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODE4NTQgICAgICAgICAx MCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2lwcm9wZF9zbGF2ZSBkb25l ICAgICAgICAgICAgICAgMTA0MiAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgxODU0 ICAgICAgICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9tb3VudGNy aXRyZW1vdGUgc3RhcnQgICAgICAgICAgIDEwNTAgICAgMC4wMCAgICAgMCAgICAgMAogIDEg ICA0NDg4MTg2MiAgICAgICAgICA4IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvbW91bnRjcml0cmVtb3RlIGRvbmUgICAgICAgICAgICAxMDUwICAgIDAuMDAgICAgIDAg ICAgIDAKICAxICAgNDQ4ODE4NjMgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2FjY291bnRpbmcgc3RhcnQgICAgICAgICAgICAgICAgMTA1OCAgICAw LjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgxODY4ICAgICAgICAgIDUgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9hY2NvdW50aW5nIGRvbmUgICAgICAgICAgICAgICAg IDEwNTggICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MTg2OSAgICAgICAgICAxIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvdmlyZWNvdmVyIHN0YXJ0ICAgICAg ICAgICAgICAgICAxMDYzICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODE4NzcgICAg ICAgICAgOCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3ZpcmVjb3ZlciBk b25lICAgICAgICAgICAgICAgICAgMTA2MyAgICAwLjAwICAgICAyICAgICAwCiAgMCAgIDQ0 ODgxODc4ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9j bGVhcnRtcCBzdGFydCAgICAgICAgICAgICAgICAgIDEwNjkgICAgMC4wMCAgICAgMCAgICAg MAogIDAgICA0NDg4MTg4NiAgICAgICAgICA4IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvY2xlYXJ0bXAgZG9uZSAgICAgICAgICAgICAgICAgICAxMDY5ICAgIDAuMDAg ICAgIDQgICAgIDAKICAwICAgNDQ4ODE4ODYgICAgICAgICAgMCBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL2RtZXNnIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgMTA3 NiAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgxODk1ICAgICAgICAgIDkgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9kbWVzZyBkb25lICAgICAgICAgICAgICAg ICAgICAgIDEwNzYgICAgMC4wMCAgICAgMSAgICAgMAogIDAgICA0NDg4MTg5NiAgICAgICAg ICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvZGV2ZnMgc3RhcnQgICAg ICAgICAgICAgICAgICAgICAxMDgzICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODE5 NDcgICAgICAgICA1MSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2RldmZz IGRvbmUgICAgICAgICAgICAgICAgICAgICAgMTA4MyAgICAwLjA0ICAgICA1ICAgICAwCiAg MSAgIDQ0ODgxOTQ3ICAgICAgICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9vcy1yZWxlYXNlIHN0YXJ0ICAgICAgICAgICAgICAgIDExNTcgICAgMC4wMCAgICAg MCAgICAgMAogIDAgICA0NDg4MTk2MSAgICAgICAgIDE0IGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvb3MtcmVsZWFzZSBkb25lICAgICAgICAgICAgICAgICAxMTU3ICAg IDAuMDEgICAgIDIgICAgIDAKICAwICAgNDQ4ODE5NjIgICAgICAgICAgMSBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL21vdGQgc3RhcnQgICAgICAgICAgICAgICAgICAg ICAgMTE2NyAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgxOTc1ICAgICAgICAgMTMg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9tb3RkIGRvbmUgICAgICAgICAg ICAgICAgICAgICAgIDExNjcgICAgMC4wMSAgICAgMiAgICAgMAogIDAgICA0NDg4MTk3NSAg ICAgICAgICAwIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbmV3c3lzbG9n IHN0YXJ0ICAgICAgICAgICAgICAgICAxMTc4ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAg NDQ4ODE5OTYgICAgICAgICAyMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L25ld3N5c2xvZyBkb25lICAgICAgICAgICAgICAgICAgMTE3OCAgICAwLjAyICAgIDEyICAg ICAwCiAgMCAgIDQ0ODgxOTk3ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9ncHRib290IHN0YXJ0ICAgICAgICAgICAgICAgICAgIDExODcgICAgMC4w MCAgICAgMCAgICAgMAogIDAgICA0NDg4MjAxMiAgICAgICAgIDE1IGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvZ3B0Ym9vdCBkb25lICAgICAgICAgICAgICAgICAgICAx MTg3ICAgIDAuMDEgICAgIDcgICAgIDAKICAwICAgNDQ4ODIwMTIgICAgICAgICAgMCBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2hvc3RhcGQgc3RhcnQgICAgICAgICAg ICAgICAgICAgMTIwMSAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgyMDE4ICAgICAg ICAgIDYgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9ob3N0YXBkIGRvbmUg ICAgICAgICAgICAgICAgICAgIDEyMDEgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4 MjAxOSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbWRj b25maWcyIHN0YXJ0ICAgICAgICAgICAgICAgICAxMjA3ICAgIDAuMDAgICAgIDAgICAgIDAK ICAxICAgNDQ4ODIwMjcgICAgICAgICAgOCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL21kY29uZmlnMiBkb25lICAgICAgICAgICAgICAgICAgMTIwNyAgICAwLjAwICAg ICAwICAgICAwCiAgMSAgIDQ0ODgyMDI4ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9zeXNsb2dkIHN0YXJ0ICAgICAgICAgICAgICAgICAgIDEyMTUg ICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MjA1MyAgICAgICAgIDI1IGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvc3lzbG9nZCBkb25lICAgICAgICAgICAgICAg ICAgICAxMjE1ICAgIDAuMDEgICAgIDUgICAgIDAKICAwICAgNDQ4ODIwNTMgICAgICAgICAg MCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL250cGRhdGUgc3RhcnQgICAg ICAgICAgICAgICAgICAgMTIzMiAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMDY0 ICAgICAgICAgMTEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9udHBkYXRl IGRvbmUgICAgICAgICAgICAgICAgICAgIDEyMzIgICAgMC4wMSAgICAgMCAgICAgMAogIDEg ICA0NDg4MjA2NSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvYXVkaXRkIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAxMjQwICAgIDAuMDAgICAgIDAg ICAgIDAKICAxICAgNDQ4ODIwNzEgICAgICAgICAgNiBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2F1ZGl0ZCBkb25lICAgICAgICAgICAgICAgICAgICAgMTI0MCAgICAw LjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMDcxICAgICAgICAgIDAgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9ic25tcGQgc3RhcnQgICAgICAgICAgICAgICAgICAg IDEyNDYgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MjA3OSAgICAgICAgICA4IGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvYnNubXBkIGRvbmUgICAgICAgICAg ICAgICAgICAgICAxMjQ2ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODIwODAgICAg ICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3NhdmVjb3JlIHN0 YXJ0ICAgICAgICAgICAgICAgICAgMTI1MiAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0 ODgyMTAyICAgICAgICAgMjIgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9z YXZlY29yZSBkb25lICAgICAgICAgICAgICAgICAgIDEyNTIgICAgMC4wMSAgICAxNCAgICAg MAogIDEgICA0NDg4MjEwMyAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvd2F0Y2hkb2dkIHN0YXJ0ICAgICAgICAgICAgICAgICAxMjY2ICAgIDAuMDAg ICAgIDAgICAgIDAKICAxICAgNDQ4ODIxMTEgICAgICAgICAgOCBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL3dhdGNoZG9nZCBkb25lICAgICAgICAgICAgICAgICAgMTI2 NiAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMTEyICAgICAgICAgIDEgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9wd2NoZWNrIHN0YXJ0ICAgICAgICAgICAg ICAgICAgIDEyNzIgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MjExNyAgICAgICAg ICA1IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvcHdjaGVjayBkb25lICAg ICAgICAgICAgICAgICAgICAxMjcyICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODIx MTggICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL1NFUlZF UlMgc3RhcnQgICAgICAgICAgICAgICAgICAgMTI3NyAgICAwLjAwICAgICAwICAgICAwCiAg MSAgIDQ0ODgyMTE5ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9TRVJWRVJTIGRvbmUgICAgICAgICAgICAgICAgICAgIDEyNzcgICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg4MjEyMCAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvYXVkaXRkaXN0ZCBzdGFydCAgICAgICAgICAgICAgICAxMjc5ICAg IDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODIxMjYgICAgICAgICAgNiBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2F1ZGl0ZGlzdGQgZG9uZSAgICAgICAgICAgICAg ICAgMTI3OSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMTI2ICAgICAgICAgIDAg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9ycGNiaW5kIHN0YXJ0ICAgICAg ICAgICAgICAgICAgIDEyODUgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MjEzNyAg ICAgICAgIDExIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvcnBjYmluZCBk b25lICAgICAgICAgICAgICAgICAgICAxMjg1ICAgIDAuMDEgICAgIDAgICAgIDAKICAwICAg NDQ4ODIxMzggICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL3Vzci9sb2Nh bC9ldGMvcmMuZC90cG1kIHN0YXJ0ICAgICAgICAgICAgMTI5MyAgICAwLjAwICAgICAwICAg ICAwCiAgMSAgIDQ0ODgyMTQ3ICAgICAgICAgIDkgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC91c3IvbG9jYWwvZXRjL3JjLmQvdHBtZCBkb25lICAgICAgICAgICAgIDEyOTMgICAgMC4w MSAgICAgMCAgICAgMAogIDEgICA0NDg4MjE0OCAgICAgICAgICAxIGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvbmlzZG9tYWluIHN0YXJ0ICAgICAgICAgICAgICAgICAx MzAxICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODIxNTQgICAgICAgICAgNiBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL25pc2RvbWFpbiBkb25lICAgICAgICAg ICAgICAgICAgMTMwMSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMTU0ICAgICAg ICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9uZnNjbGllbnQgc3Rh cnQgICAgICAgICAgICAgICAgIDEzMDYgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4 MjE2MCAgICAgICAgICA2IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbmZz Y2xpZW50IGRvbmUgICAgICAgICAgICAgICAgICAxMzA2ICAgIDAuMDAgICAgIDAgICAgIDAK ICAxICAgNDQ4ODIxNjEgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL3lwc2VydiBzdGFydCAgICAgICAgICAgICAgICAgICAgMTMxMSAgICAwLjAwICAg ICAwICAgICAwCiAgMCAgIDQ0ODgyMTcwICAgICAgICAgIDkgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC95cHNlcnYgZG9uZSAgICAgICAgICAgICAgICAgICAgIDEzMTEg ICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg4MjE3MSAgICAgICAgICAxIGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9yYy5kL3Rjc2Qgc3RhcnQgICAgICAg ICAgICAxMzE5ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODIxODEgICAgICAgICAx MCBib290dHJhY2UgICAgICAgICAgICAgICAgL3Vzci9sb2NhbC9ldGMvcmMuZC90Y3NkIGRv bmUgICAgICAgICAgICAgMTMxOSAgICAwLjAxICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMTgy ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC95cHhmcmQg c3RhcnQgICAgICAgICAgICAgICAgICAgIDEzMjcgICAgMC4wMCAgICAgMCAgICAgMAogIDAg ICA0NDg4MjE5MSAgICAgICAgICA5IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQveXB4ZnJkIGRvbmUgICAgICAgICAgICAgICAgICAgICAxMzI3ICAgIDAuMDAgICAgIDAg ICAgIDAKICAwICAgNDQ4ODIxOTMgICAgICAgICAgMiBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL3lwbGRhcCBzdGFydCAgICAgICAgICAgICAgICAgICAgMTMzNSAgICAw LjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMjA3ICAgICAgICAgMTQgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC95cGxkYXAgZG9uZSAgICAgICAgICAgICAgICAgICAg IDEzMzUgICAgMC4wMSAgICAgMCAgICAgMAogIDEgICA0NDg4MjIwOCAgICAgICAgICAxIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQveXBiaW5kIHN0YXJ0ICAgICAgICAg ICAgICAgICAgICAxMzQzICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODIyMTggICAg ICAgICAxMCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3lwYmluZCBkb25l ICAgICAgICAgICAgICAgICAgICAgMTM0MyAgICAwLjAxICAgICAwICAgICAwCiAgMCAgIDQ0 ODgyMjE4ICAgICAgICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC95 cHVwZGF0ZWQgc3RhcnQgICAgICAgICAgICAgICAgIDEzNTEgICAgMC4wMCAgICAgMCAgICAg MAogIDEgICA0NDg4MjIyOCAgICAgICAgIDEwIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQveXB1cGRhdGVkIGRvbmUgICAgICAgICAgICAgICAgICAxMzUxICAgIDAuMDEg ICAgIDAgICAgIDAKICAxICAgNDQ4ODIyMjkgICAgICAgICAgMSBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL2hhc3RkIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgMTM1 OSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMjM1ICAgICAgICAgIDYgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9oYXN0ZCBkb25lICAgICAgICAgICAgICAg ICAgICAgIDEzNTkgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MjIzNiAgICAgICAg ICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQveXBzZXQgc3RhcnQgICAg ICAgICAgICAgICAgICAgICAxMzY1ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODIy NDUgICAgICAgICAgOSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3lwc2V0 IGRvbmUgICAgICAgICAgICAgICAgICAgICAgMTM2NSAgICAwLjAxICAgICAwICAgICAwCiAg MCAgIDQ0ODgyMjQ2ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC95cHBhc3N3ZGQgc3RhcnQgICAgICAgICAgICAgICAgIDEzNzMgICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg4MjI1OCAgICAgICAgIDEyIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQveXBwYXNzd2RkIGRvbmUgICAgICAgICAgICAgICAgICAxMzczICAg IDAuMDEgICAgIDAgICAgIDAKICAxICAgNDQ4ODIyNTggICAgICAgICAgMCBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3F1b3RhIHN0YXJ0ICAgICAgICAgICAgICAgICAg ICAgMTM4MSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMjY1ICAgICAgICAgIDcg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9xdW90YSBkb25lICAgICAgICAg ICAgICAgICAgICAgIDEzODEgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MjI2NiAg ICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQva2V5c2VydiBz dGFydCAgICAgICAgICAgICAgICAgICAxMzg2ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAg NDQ4ODIyNzYgICAgICAgICAxMCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L2tleXNlcnYgZG9uZSAgICAgICAgICAgICAgICAgICAgMTM4NiAgICAwLjAxICAgICAwICAg ICAwCiAgMCAgIDQ0ODgyMjc3ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9hdXRvbW91bnRkIHN0YXJ0ICAgICAgICAgICAgICAgIDEzOTQgICAgMC4w MCAgICAgMCAgICAgMAogIDEgICA0NDg4MjI4MyAgICAgICAgICA2IGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvYXV0b21vdW50ZCBkb25lICAgICAgICAgICAgICAgICAx Mzk0ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODIyODQgICAgICAgICAgMSBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2F1dG9tb3VudCBzdGFydCAgICAgICAg ICAgICAgICAgMTQwMCAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMjg5ICAgICAg ICAgIDUgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9hdXRvbW91bnQgZG9u ZSAgICAgICAgICAgICAgICAgIDE0MDAgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4 MjI5MCAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbW91 bnRkIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAxNDA1ICAgIDAuMDAgICAgIDAgICAgIDAK ICAxICAgNDQ4ODIyOTYgICAgICAgICAgNiBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL21vdW50ZCBkb25lICAgICAgICAgICAgICAgICAgICAgMTQwNSAgICAwLjAwICAg ICAwICAgICAwCiAgMSAgIDQ0ODgyMjk3ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9uZnNkIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAgIDE0MTEg ICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MjMwNyAgICAgICAgIDEwIGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbmZzZCBkb25lICAgICAgICAgICAgICAgICAg ICAgICAxNDExICAgIDAuMDEgICAgIDAgICAgIDAKICAwICAgNDQ4ODIzMDggICAgICAgICAg MSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3N0YXRkIHN0YXJ0ICAgICAg ICAgICAgICAgICAgICAgMTQxOSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyMzIx ICAgICAgICAgMTMgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9zdGF0ZCBk b25lICAgICAgICAgICAgICAgICAgICAgIDE0MTkgICAgMC4wMSAgICAgMCAgICAgMAogIDEg ICA0NDg4MjMyMiAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvbG9ja2Qgc3RhcnQgICAgICAgICAgICAgICAgICAgICAxNDI3ICAgIDAuMDAgICAgIDAg ICAgIDAKICAwICAgNDQ4ODIzMzYgICAgICAgICAxNCBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2xvY2tkIGRvbmUgICAgICAgICAgICAgICAgICAgICAgMTQyNyAgICAw LjAxICAgICAwICAgICAwCiAgMCAgIDQ0ODgyMzM3ICAgICAgICAgIDEgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9EQUVNT04gc3RhcnQgICAgICAgICAgICAgICAgICAg IDE0MzUgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MjMzOCAgICAgICAgICAxIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvREFFTU9OIGRvbmUgICAgICAgICAg ICAgICAgICAgICAxNDM1ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODIzMzkgICAg ICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3J0YWR2ZCBzdGFy dCAgICAgICAgICAgICAgICAgICAgMTQzNyAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0 ODgyMzU0ICAgICAgICAgMTUgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9y dGFkdmQgZG9uZSAgICAgICAgICAgICAgICAgICAgIDE0MzcgICAgMC4wMSAgICAgMCAgICAg MAogIDEgICA0NDg4MjM1NSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvcndobyBzdGFydCAgICAgICAgICAgICAgICAgICAgICAxNDQ1ICAgIDAuMDAg ICAgIDAgICAgIDAKICAwICAgNDQ4ODIzNjUgICAgICAgICAxMCBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL3J3aG8gZG9uZSAgICAgICAgICAgICAgICAgICAgICAgMTQ0 NSAgICAwLjAxICAgICAwICAgICAwCiAgMCAgIDQ0ODgyMzY2ICAgICAgICAgIDEgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9yYXJwZCBzdGFydCAgICAgICAgICAgICAg ICAgICAgIDE0NTMgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MjM3MiAgICAgICAg ICA2IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvcmFycGQgZG9uZSAgICAg ICAgICAgICAgICAgICAgICAxNDUzICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODIz NzMgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2FwbSBz dGFydCAgICAgICAgICAgICAgICAgICAgICAgMTQ1OSAgICAwLjAwICAgICAwICAgICAwCiAg MSAgIDQ0ODgyMzgzICAgICAgICAgMTAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9hcG0gZG9uZSAgICAgICAgICAgICAgICAgICAgICAgIDE0NTkgICAgMC4wMSAgICAg MCAgICAgMAogIDEgICA0NDg4MjM4NCAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvdWJ0aGlkaGNpIHN0YXJ0ICAgICAgICAgICAgICAgICAxNDY3ICAg IDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODIzOTQgICAgICAgICAxMCBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3VidGhpZGhjaSBkb25lICAgICAgICAgICAgICAg ICAgMTQ2NyAgICAwLjAxICAgICAwICAgICAwCiAgMCAgIDQ0ODgyMzk1ICAgICAgICAgIDEg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC91dHggc3RhcnQgICAgICAgICAg ICAgICAgICAgICAgIDE0NzUgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MjQwMiAg ICAgICAgICA3IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvdXR4IGRvbmUg ICAgICAgICAgICAgICAgICAgICAgICAxNDc1ICAgIDAuMDAgICAgIDIgICAgIDAKICAwICAg NDQ4ODI0MDMgICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L3NkcGQgc3RhcnQgICAgICAgICAgICAgICAgICAgICAgMTQ4MSAgICAwLjAwICAgICAwICAg ICAwCiAgMSAgIDQ0ODgyNDEzICAgICAgICAgMTAgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9zZHBkIGRvbmUgICAgICAgICAgICAgICAgICAgICAgIDE0ODEgICAgMC4w MSAgICAgMCAgICAgMAogIDEgICA0NDg4MjQxNCAgICAgICAgICAxIGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvbG9jYWwgc3RhcnQgICAgICAgICAgICAgICAgICAgICAx NDg5ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODI0MTkgICAgICAgICAgNSBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2xvY2FsIGRvbmUgICAgICAgICAgICAg ICAgICAgICAgMTQ4OSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyNDIwICAgICAg ICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9tb3VudGxhdGUgc3Rh cnQgICAgICAgICAgICAgICAgIDE0OTQgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4 MjQyOSAgICAgICAgICA5IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbW91 bnRsYXRlIGRvbmUgICAgICAgICAgICAgICAgICAxNDk0ICAgIDAuMDAgICAgIDAgICAgIDAK ICAwICAgNDQ4ODI0MjkgICAgICAgICAgMCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL25zY2Qgc3RhcnQgICAgICAgICAgICAgICAgICAgICAgMTUwMiAgICAwLjAwICAg ICAwICAgICAwCiAgMSAgIDQ0ODgyNDQyICAgICAgICAgMTMgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9uc2NkIGRvbmUgICAgICAgICAgICAgICAgICAgICAgIDE1MDIg ICAgMC4wMSAgICAgMCAgICAgMAogIDEgICA0NDg4MjQ0NCAgICAgICAgICAyIGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbnRwZCBzdGFydCAgICAgICAgICAgICAgICAg ICAgICAxNTE2ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODI0NTAgICAgICAgICAg NiBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL250cGQgZG9uZSAgICAgICAg ICAgICAgICAgICAgICAgMTUxNiAgICAwLjAwICAgICAxICAgICAwCiAgMCAgIDQ0ODgyNDUx ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9mdHAtcHJv eHkgc3RhcnQgICAgICAgICAgICAgICAgIDE1MjIgICAgMC4wMCAgICAgMCAgICAgMAogIDEg ICA0NDg4MjQ2MiAgICAgICAgIDExIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvZnRwLXByb3h5IGRvbmUgICAgICAgICAgICAgICAgICAxNTIyICAgIDAuMDEgICAgIDAg ICAgIDAKICAxICAgNDQ4ODI0NjIgICAgICAgICAgMCBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL2Jvb3RwYXJhbXMgc3RhcnQgICAgICAgICAgICAgICAgMTUzMCAgICAw LjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgyNDczICAgICAgICAgMTEgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9ib290cGFyYW1zIGRvbmUgICAgICAgICAgICAgICAg IDE1MzAgICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg4MjQ3MyAgICAgICAgICAwIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvaGNzZWNkIHN0YXJ0ICAgICAgICAg ICAgICAgICAgICAxNTM4ICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODI0ODAgICAg ICAgICAgNyBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2hjc2VjZCBkb25l ICAgICAgICAgICAgICAgICAgICAgMTUzOCAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0 ODgyNDgxICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9w b3dlcmQgc3RhcnQgICAgICAgICAgICAgICAgICAgIDE1NDQgICAgMC4wMCAgICAgMCAgICAg MAogIDEgICA0NDg4MjQ5MSAgICAgICAgIDEwIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvcG93ZXJkIGRvbmUgICAgICAgICAgICAgICAgICAgICAxNTQ0ICAgIDAuMDEg ICAgIDAgICAgIDAKICAxICAgNDQ4ODI0OTEgICAgICAgICAgMCBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL2xwZCBzdGFydCAgICAgICAgICAgICAgICAgICAgICAgMTU1 MiAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgyNTAxICAgICAgICAgMTAgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9scGQgZG9uZSAgICAgICAgICAgICAgICAg ICAgICAgIDE1NTIgICAgMC4wMSAgICAgMCAgICAgMAogIDAgICA0NDg4MjUwMiAgICAgICAg ICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvbW91c2VkIHN0YXJ0ICAg ICAgICAgICAgICAgICAgICAxNTYwICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODI1 MDggICAgICAgICAgNiBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL21vdXNl ZCBkb25lICAgICAgICAgICAgICAgICAgICAgMTU2MCAgICAwLjAwICAgICAwICAgICAwCiAg MCAgIDQ0ODgyNTA5ICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9idGhpZGQgc3RhcnQgICAgICAgICAgICAgICAgICAgIDE1NjYgICAgMC4wMCAgICAg MCAgICAgMAogIDAgICA0NDg4MjUxNiAgICAgICAgICA3IGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvYnRoaWRkIGRvbmUgICAgICAgICAgICAgICAgICAgICAxNTY2ICAg IDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODI1MTcgICAgICAgICAgMSBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3JmY29tbV9wcHBkX3NlcnZlciBzdGFydCAgICAg ICAgMTU3MyAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyNTI3ICAgICAgICAgMTAg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9yZmNvbW1fcHBwZF9zZXJ2ZXIg ZG9uZSAgICAgICAgIDE1NzMgICAgMC4wMSAgICAgMCAgICAgMAogIDEgICA0NDg4MjUyOCAg ICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvc3dhcGxhdGUg c3RhcnQgICAgICAgICAgICAgICAgICAxNTgxICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAg NDQ4ODI1MzUgICAgICAgICAgNyBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5k L3N3YXBsYXRlIGRvbmUgICAgICAgICAgICAgICAgICAgMTU4MSAgICAwLjAwICAgICAwICAg ICAwCiAgMSAgIDQ0ODgyNTM1ICAgICAgICAgIDAgYm9vdHRyYWNlICAgICAgICAgICAgICAg IC9ldGMvcmMuZC9MT0dJTiBzdGFydCAgICAgICAgICAgICAgICAgICAgIDE1ODcgICAgMC4w MCAgICAgMCAgICAgMAogIDEgICA0NDg4MjUzNyAgICAgICAgICAyIGJvb3R0cmFjZSAgICAg ICAgICAgICAgICAvZXRjL3JjLmQvTE9HSU4gZG9uZSAgICAgICAgICAgICAgICAgICAgICAx NTg3ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAgNDQ4ODI1MzcgICAgICAgICAgMCBib290 dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL21zZ3Mgc3RhcnQgICAgICAgICAgICAg ICAgICAgICAgMTU4OSAgICAwLjAwICAgICAwICAgICAwCiAgMSAgIDQ0ODgyNTQzICAgICAg ICAgIDYgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9tc2dzIGRvbmUgICAg ICAgICAgICAgICAgICAgICAgIDE1ODkgICAgMC4wMCAgICAgMSAgICAgMAogIDEgICA0NDg4 MjU0NCAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvc3lz Y3RsX2xhc3Rsb2FkIHN0YXJ0ICAgICAgICAgICAxNTk0ICAgIDAuMDAgICAgIDAgICAgIDAK ICAwICAgNDQ4ODI1NjIgICAgICAgICAxOCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0 Yy9yYy5kL3N5c2N0bF9sYXN0bG9hZCBkb25lICAgICAgICAgICAgMTU5NCAgICAwLjAyICAg ICAwICAgICAwCiAgMCAgIDQ0ODgyNTYzICAgICAgICAgIDEgYm9vdHRyYWNlICAgICAgICAg ICAgICAgIC9ldGMvcmMuZC9zeXNjb25zIHN0YXJ0ICAgICAgICAgICAgICAgICAgIDE2MDcg ICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MjU3MyAgICAgICAgIDEwIGJvb3R0cmFj ZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvc3lzY29ucyBkb25lICAgICAgICAgICAgICAg ICAgICAxNjA3ICAgIDAuMDAgICAgIDEgICAgIDAKICAwICAgNDQ4ODI1NzMgICAgICAgICAg MCBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL3NzaGQgc3RhcnQgICAgICAg ICAgICAgICAgICAgICAgMTYxNCAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgyNTgw ICAgICAgICAgIDcgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9zc2hkIGRv bmUgICAgICAgICAgICAgICAgICAgICAgIDE2MTQgICAgMC4wMCAgICAgMCAgICAgMAogIDAg ICA0NDg4MjU4MSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3Jj LmQvc2VuZG1haWwgc3RhcnQgICAgICAgICAgICAgICAgICAxNjIwICAgIDAuMDAgICAgIDAg ICAgIDAKICAwICAgNDQ4ODI4MDIgICAgICAgIDIyMSBib290dHJhY2UgICAgICAgICAgICAg ICAgL2V0Yy9yYy5kL3NlbmRtYWlsIGRvbmUgICAgICAgICAgICAgICAgICAgMTYyMCAgICAw LjAyICAgIDU2ICAgICAwCiAgMCAgIDQ0ODgyODAzICAgICAgICAgIDEgYm9vdHRyYWNlICAg ICAgICAgICAgICAgIC9ldGMvcmMuZC9jcm9uIHN0YXJ0ICAgICAgICAgICAgICAgICAgICAg IDE2MzQgICAgMC4wMCAgICAgMCAgICAgMAogIDEgICA0NDg4MjgxNiAgICAgICAgIDEzIGJv b3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvY3JvbiBkb25lICAgICAgICAgICAg ICAgICAgICAgICAxNjM0ICAgIDAuMDAgICAgIDYgICAgIDAKICAxICAgNDQ4ODI4MTcgICAg ICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL290aGVybXRhIHN0 YXJ0ICAgICAgICAgICAgICAgICAgMTY0MiAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0 ODgyODIyICAgICAgICAgIDUgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9v dGhlcm10YSBkb25lICAgICAgICAgICAgICAgICAgIDE2NDIgICAgMC4wMCAgICAgMCAgICAg MAogIDAgICA0NDg4MjgyMyAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAgICAgICAv ZXRjL3JjLmQvaW5ldGQgc3RhcnQgICAgICAgICAgICAgICAgICAgICAxNjQ3ICAgIDAuMDAg ICAgIDAgICAgIDAKICAwICAgNDQ4ODI4MzEgICAgICAgICAgOCBib290dHJhY2UgICAgICAg ICAgICAgICAgL2V0Yy9yYy5kL2luZXRkIGRvbmUgICAgICAgICAgICAgICAgICAgICAgMTY0 NyAgICAwLjAwICAgICAwICAgICAwCiAgMCAgIDQ0ODgyODMyICAgICAgICAgIDEgYm9vdHRy YWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9mdHBkIHN0YXJ0ICAgICAgICAgICAgICAg ICAgICAgIDE2NTMgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4MjgzNyAgICAgICAg ICA1IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvZnRwZCBkb25lICAgICAg ICAgICAgICAgICAgICAgICAxNjUzICAgIDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODI4 MzggICAgICAgICAgMSBib290dHJhY2UgICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2JnZnNj ayBzdGFydCAgICAgICAgICAgICAgICAgICAgMTY1OSAgICAwLjAwICAgICAwICAgICAwCiAg MCAgIDQ0ODgyODQ4ICAgICAgICAgMTAgYm9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMv cmMuZC9iZ2ZzY2sgZG9uZSAgICAgICAgICAgICAgICAgICAgIDE2NTkgICAgMC4wMCAgICAg MCAgICAgMAogIDEgICA0NDg4Mjg0OSAgICAgICAgICAxIGJvb3R0cmFjZSAgICAgICAgICAg ICAgICAvZXRjL3JjLmQvamFpbCBzdGFydCAgICAgICAgICAgICAgICAgICAgICAxNjY4ICAg IDAuMDAgICAgIDAgICAgIDAKICAwICAgNDQ4ODI4NjUgICAgICAgICAxNiBib290dHJhY2Ug ICAgICAgICAgICAgICAgL2V0Yy9yYy5kL2phaWwgZG9uZSAgICAgICAgICAgICAgICAgICAg ICAgMTY2OCAgICAwLjAxICAgICAwICAgICAwCiAgMCAgIDQ0ODgyODY2ICAgICAgICAgIDEg Ym9vdHRyYWNlICAgICAgICAgICAgICAgIC9ldGMvcmMuZC9zZWN1cmVsZXZlbCBzdGFydCAg ICAgICAgICAgICAgIDE2NzkgICAgMC4wMCAgICAgMCAgICAgMAogIDAgICA0NDg4Mjg3MiAg ICAgICAgICA2IGJvb3R0cmFjZSAgICAgICAgICAgICAgICAvZXRjL3JjLmQvc2VjdXJlbGV2 ZWwgZG9uZSAgICAgICAgICAgICAgICAxNjc5ICAgIDAuMDAgICAgIDAgICAgIDAKICAxICAg NDQ4ODI4NzkgICAgICAgICAgNyBpbml0ICAgICAgICAgICAgICAgICAgICAgL2V0Yy9yYyBm aW5pc2hlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAyLjIyICAgNzQzICAg IDE1ClRvdGFsIG1lYXN1cmVkIHRpbWU6IDEwMDY4IG1zZWNzCgoKQ1BVICAgICAgbXNlY3Mg ICAgICBkZWx0YSBwcm9jZXNzICAgICAgICAgICAgICAgICAgZXZlbnQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFBJRCBDUFV0aW1lIElCbGtzIE9CbGtzCiAgMSAg IDQ0ODgyODgwICAgICAgICAgIDAgaW5pdCAgICAgICAgICAgICAgICAgICAgIG11bHRpLXVz ZXIgc3RhcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgMi4yMiAgIDc0MyAg ICAxNQogIDAgICA0NDkxODIxNSAgICAgIDM1MzM1IGtsZGxvYWQgICAgICAgICAgICAgICAg ICBod3BtYy5rbzogc3lzaW5pdCAweGQ4MDAwMDAgICAgICAgICAgICAgICAxNjk4ICAgIDAu MDAgICAgIDAgICAgIDAKVG90YWwgbWVhc3VyZWQgdGltZTogMzUzMzUgbXNlY3MgCg== --------------0qyuvJ5PYJ0S4nke6C1u0B1C-- From nobody Wed Nov 10 17:39:04 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 087EE183A1CC; Wed, 10 Nov 2021 17:39:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HqBtB5h1Fz4VZX; Wed, 10 Nov 2021 17:39:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 607708D4A215; Wed, 10 Nov 2021 17:39:07 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9569BE7085A; Wed, 10 Nov 2021 17:39:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 1nLPHeTR9ZeT; Wed, 10 Nov 2021 17:39:05 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:147a:793a:fa30:961]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4E2E1E70814; Wed, 10 Nov 2021 17:39:05 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Mitchell Horne" Cc: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, cperciva@freebsd.org Subject: Re: A new boot-time trace framework Date: Wed, 10 Nov 2021 17:39:04 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <5E5F06E4-F0FA-45F9-B121-88C69CA15A25@lists.zabbadoz.net> In-Reply-To: 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="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HqBtB5h1Fz4VZX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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. 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. 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.. /bz From nobody Thu Nov 18 19:32:25 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 0AACE189592D for ; Thu, 18 Nov 2021 19:32:39 +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.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 4Hw91K4C1bz4RZy for ; Thu, 18 Nov 2021 19:32:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637263950; bh=d/RsYBSbT/durKvRCe8sqhVGNqZXxFAzedGkfKpcrqQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CH5lfUHP/C1Vp4Z/H7sAI8kFy9fUtc1mQUdKbXL07mL5FCsgPp7laJvUJJik6eOwgzhCYxfo9EWcFDfWQCKGNDBtiU4Aek8IfMent+4lWwa5x2/zEjGIc9vWZ6r/Lh46ySPJSYOs39dmpL8xUnqRxCWg2wujydnjyAuRNnNOSbeI5iR1LXXFtYNYmLcc528auee+Dn/N3DAh7mGBPJ3HDO465lkHeCcBKnxUggiCz0reIDkUn2SX7AsPwyEZ6AHDPOSeYirFpCkEnJJw4ieHZmfmc3tkKQ9TL9EAd9WgSUwskE1D9mUO0ZQfQTujTfjUcx1vYWfY44qA5bMv4j2Jjw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637263950; bh=j8Z57J/6nqae63DrGumaH5GkrtqW4c5/INpAVBzt0/J=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gZ1nh4SRQq2V6tKR/TRGPAiAcl517Vsn0gUV14KVmsmnMqWi0mGol2U0PTm7uF2C8CMdHd41kXxMbnC81BxhDM0XkKMxntwq2g7f6EL08cb+2wx06ziXS6rUL3qjSRjFvyJngyDccLUv5l9PLnRdaXTxBgOyFZmyAjk+em7zKh0oNiweNoJdOmW7SDYYIbzE7KSV1EFet53LHJ6Ml3k9+unUxus0WEgkOy4K99zJ5UD5nnZGpqv1A9GyzrnwEY4At/E8cgj4XHu9eBV4CKmCrCu2IBRg66xB5Ff4cYn+dWqCwC9M42qpBKhTB0xOvbK9pNKDPgamoz3QAELTNESdvA== X-YMail-OSG: tU7BZVMVM1n01Th6En2Tx2LDn_nzzPeT4kW9FwdyD.McSSD5tk29K5_fB.tffFl AGkKDxv5dev0vbqyBzb1dvhEyOZMduAu_85eQJaJX196r.d_nOQLhOgHB.iZFZcR4XxSal2kTjMf qzByTqk75U6VGYJ9ZT79.a5QnvqvtMdV4fDaGRAMPVMjuW3xP9YS5arBu_3m4JCX8Dnl3JxE8u1Z OVMJZisvZsTz7Ui2sdJ9CAn9YNuNFfmFPU0cgvcagg5OZcXLMpnWjm_CZ1kE2TdtJXTfE6aAV6L0 iyd8U12MJR88JieG5yUnerbipCUpcvEp8ZlMJgQwg7gNj2fVk5tJNk6iZ1hTOOSm7scZvUnNZxF3 V4vKRFBM6G7JPVBHtOwMUon1TXuB1WoS2NOtbuG04..gOWQWJ.1qKQGX9FT_cFPOcS3SZnLnQBTW NcwmaJBUk4C_Z1KxhzRJN91FoJPY19y1qyzAFA9f7Em1fVi8lq3kZXEpQY_QAozIeDLf6RAdBvLy mmkLC954Q_PBcOVD3sCanzxJW5w6IeA0nDjUsg4cH5x9zFCLq_v1nvod9uZStSz5N9982qLLf1j8 H5kTae15uvsPSleiOlDhP.2rLKrHr030fs0AMnb_WoW.3DMqDcMCSuaJFkUyL7DKH_BDOMB0wNZ1 O.F9zY8PM3PW5jDJ_1oteywGy1vQxmFICrVEjoYhXbqhc3fsrvvxw_baZVD_J7.JY5AYG1Q1_ABV J2agly9CpH4JALNBQy0ucaq_oE7eC4kXQt94Y._rluqbzCfcQrtEYKkUuBqIJbbUP4q2O_KLA.sE fquNVKDv16qxhX9W4.0qAoWHcMVwsb7fnLV5TdDAxzc1BMsOaRIvQd8ovnEjvVlvrsQ62EKug45e sEGxWNEFOPFE1bvAlsaNnTGAuWmsRqSxuPpEefAqQlx1G9LXmIIsEJNrstQi24btlDL0ZoO81GXG NyAbKIptJgog2QtlGYCnJ_PPtrUG8bCLI4YWTQL1MtXmdIlvsDCcJfPlRUWtuQ3ra_OeGmbUKap9 PH39aBFBq4PeKrMeGDaTpdvEuqsLY6Pc9HbeTYiQ6JN5t7p77noJx52_h7ZjfgbgGpv2_txpM814 h0M_aRc9sxh_2xDkbaq75DKKrdn1kh02l9pkUNU_lF4uxw6bCupcYttbgPkhbTgFQDt41thqBOne Pod5qIP6Z0jXXy8.DAAgtaH27NGIAe4231EDn5.1hBS5ex_RC.oLIsW969KaigVh.J._Q1W0F2nt vZOCDfJ1BtfYpnWY1u2doDYS59ay6.bT_40KhixLjpyUaElYOWihZaMpaApHtMYA9gXrJILnIIXc RQAn5kjz0KUkkxE4iqEHfkK1fra..R_1qaLbZ291A2vvidxPQ41aEw0LwrzJY_sAL7QnNdduoOIM RPy.IVbKbbmnjj0Ty9reVoGkBLMKqqsYlP6Y_2ye_rADJCMkKuV070he4puTTsKgp3yiap85U_wp slgNLc532390JYWH1.rfV1lcz8juhhypw8vNdd.UmeiEl9i8l8mbq9.h7LAXyYlv6PRS4P1R1Xxl h6zUuIqBhhfsgnqWJBn9q17IhjzCXJ9UBjFtd8oXRtT_pavszSF3oW5QiGTM0BVAZEG_obkDMLF0 ZDVa9szizyFhx6a85VKutvv3EE1xkwBgcyYyPcr09IH250awUi4vj9qEVZ7bAvEH4jHIzKcACg8G xTTzrx_orxqtRC64iobSKSq8amuDMLKpBuaZ8jDj6un.iCCd7Hp_FxkNafc6puTtrbuj1mXVci2H PTIwQjH3RhFw35C7VrFtkZYC8tEpUyXgzReVTdpnIjw6_EOmlAjikG_MFpFRoj8D9_z_vqg8qY0K bIQyOvOHLBfL1wQJL6KBEDI.Dwir0i2bWceoN3mcZq8dIdk16WaGovviQ3wIs4.Wc3n_pK8JQHG2 3vIlEnKeX8dtRjPcr9zQhPxx.Y0gUm1jPk3zFDTnA_E78XK8hGxomfwDisu.KJCq.2iX8H2ysLMb fHlEurjubyalGjnqZhK_rrm9JHWd8Qvbl4KFmEd8syVuQfa47ttRtqmJDsxQIsn.9Xq0eLPgn_Os yzOQ4rtJFFAV2iNsKq.vzA.cjH8B0RxH5.ZtPPUB_V9uW2hisLnWDyA_vbzRpQRdmw0Pq2kUS6vj vg19F2o8Fci.q6B_get._rzf.5w_UHpQJBNg477SY_0dtqypwbxFsgftBVB8jPLOxGlB7qICiOys Rca.WKwYXq4kUgoGWork9mjKqrwQ2fSsakXuMI41dUF_Ft2POb5nwvRiQysCmlpMaiOAc3IvicIj OZDFyfPz0Bog- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Nov 2021 19:32:30 +0000 Received: by kubenode528.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1c925c5342a5fbc652514950bb46c0fe; Thu, 18 Nov 2021 19:32:27 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed In-Reply-To: <341A49EC-241C-43E7-8380-D2EE2F8C59F4@yahoo.com> Date: Thu, 18 Nov 2021 11:32:25 -0800 Cc: Free BSD , freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: References: <341A49EC-241C-43E7-8380-D2EE2F8C59F4@yahoo.com> To: tech-lists X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hw91K4C1bz4RZy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CH5lfUHP; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-4, at 14:18, Mark Millard wrote: > On 2021-Nov-4, at 13:39, tech-lists wrote: >=20 >> On Thu, Nov 04, 2021 at 11:53:18AM -0700, Mark Millard via = freebsd-arch wrote: >>=20 >>> Without one or more developers willing to keep ARM11 based RPi* = FreeBSD >>> working as FreeBSD updates, the code will break. Other architectures >>> have been removed for such. Folks that do not want to work on such = code >>> do not want to have to work on it to keep FreeBSD building and = operating >>> for other architectures that have active developmers/maintainers. >>>=20 >>> If there were active FreeBSD developers for ARM11 RPi*'s, the = removal >>> would have been unlikely to be proposed at all, even if the use was >>> minor. FreeBSD is driven by the developer context directly, not the >>> usage context directly.=20 >>=20 >> OK. I can understand that. No developers want to work on it so no >> interest. That's straightforward, logical, bad for me but I can >> understand it and work around it. But that was not mentioned by the = OP. >>=20 >> On Thu, Oct 28, 2021 at 09:44:20AM -0600, Warner Losh wrote: >>=20 >>>> Given that the number of available and useful armv6 boards has = fallen >>>> to almost zero, the time has come to look hard at armv6. >>=20 >> I'm objecting to this because "available and useful" is impossible to = measure. "Available" is going to be a very large number, because of >> the number of sales and popularity of these boards, and that they are >> durable. So stuff made years ago can logically be presumed to be = still >> in working order. Even if 0.1% of rpi1b users used freebsd on their >> boards, it'll still be a big number. FreeBSD does not record anywhere = the context in which it is used. And "useful" depends on who is using it = for what and is an opinion. >>=20 >>> NetBSD supports a lot of systems that FreeBSD does not. That fact = has >>> never justified having support for those systems in FreeBSD.=20 >>=20 >> I'm not saying that. What I'm asking is the reasoning. >>=20 >> "we don't want to support it anymore" is a reason >> "no devs are interested" is a reason >>=20 >> "the number of available and useful armv6 boards has fallen to almost >> zero" is objectively false and so therefore is not a reason. And = because >> it is not a reason then justifications following it will also be >> incorrect. >=20 > I'll note that: >=20 > https://www.netbsd.org/releases/formal-9/NetBSD-9.2.html >=20 > indicates: ARMv6 (Raspberry Pi 1 only) >=20 > so NetBSD does not have general armv6 support, just support for > the RPi*'s that are ARM11 based. (Another page mentions RPi0 and > RPi0w examples as "expected to work", although needing FDT files. > See: https://wiki.netbsd.org/ports/evbarm/raspberry_pi/ and its > earmv6hf material.) >=20 > The lack of a variety of sources of armv6 or ARM11 that NetBSD > supports is likely a kind of property being referenced: even for > NetBSD no other ARM11's are targeted. >=20 > Basically, even for NetBSD, one has to be interested in supporting > (some) RPi*'s in order to be interested in supporting ARM11. There > is not much of any other ARM11 market for NetBSD (or FreeBSD). >=20 >>=20 >> I'm interested to know what NetBSD's reasons are in having tier-1 >> support for armv6, but I'll ask that on their lists. I'll also note that Fedora is at the proposal stage for removal of armv7 (yes: 7) in fc37. From: https://fedoraproject.org/wiki/Changes/RetireARMv7 is (in part): QUOTE Detailed Description The ARMv7 arm architecture was the second variant of the arm = architecture that Fedora has supported, the first was ARMv5, the third = is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37 = release. This will allow ARMv7/armhfp to be supported until the Fedora = 36 end of life in around June 2023. Overall arm32 is generally waning with generally few new ARMv7 devices = added to Fedora in recent releases. To add to that a number of newer = Fedora features designed to improve speed and security of the Fedora = release are causing 32 bit architectures in general primarily due to the = process memory limit when linking large applications. The ARMv7/armhfp = is the last fully supported 32 bit architecture, we still currently = build i686 packages, but it's not shipped as artefacts. Benefit to Fedora The primary benefit is to maintainers of the ARM architecture, the = various toolchain teams and package maintainers in general. END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)