From nobody Mon Nov 15 15:54:55 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 69037188C935 for ; Mon, 15 Nov 2021 15:54:59 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtDKZ5fgLz3mPT for ; Mon, 15 Nov 2021 15:54:58 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id u18so31657917wrg.5 for ; Mon, 15 Nov 2021 07:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=pqUW/Hbjin3gHX6QsOBnxBQRbsLx/NsPAhD5/yfHdvc=; b=N+jK+FTu7vsKf4B51hxFWfClks1aJY3E0C6ickxisUUAFfw6i1zRXUu2ORggnDJXnu /hla2c5WAXtTjW5CyKo83KARqCzMgOC3WFdpE8hAGL4b9dlXWXYOBScNDKp8RmFdKS5P HnCJrALC4G38fE3w5gitgCiYko90kfLpHHID3atggiT/GMOSSG8w712IvQlwbD1q13ca v6hTv9YeJPgsA34cyAabBCMm9PfnFwqeYnfCUD8gD8oeqn5fyyFRogf4DvLTKt1AvBgL PZMUhIuLz+ieh0iL6LGTHPmwDyhVYSMqUQHJhGr5IX6pi3bsgyOXVN4cFZ7m4MKF8apx pIHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=pqUW/Hbjin3gHX6QsOBnxBQRbsLx/NsPAhD5/yfHdvc=; b=mxGbSoj60j+Pgu8WUbTpg7jb2evXeEpdB7HsrEsPVBarEvJ2MWyV8qpzEBn7IPqvLO u6tuSoNfILYGDrxsoKId3rQGeUjFAtn7W/hhUCq60gMh7OC6ahmoU2HkrONc0L4TSZWu EPAyWzvJg/zlKZ/jsBsSupU4lhQUaQk1ivfh8s12RLMPYkapzmF9i8/F/pPcZKx04089 w5YnRG5fywCkrXxjBMsXjKiE/Ihxpzp4serhcsBL1SzQlqBmyZ0kpYJewHvNU+0R0tdd PoMLv9/vXt9pG7MzAWbidgQ1y4uq+FYMrWKLWlW+/3BPGiBn8jjt01UP061f82118g5a f/Dw== X-Gm-Message-State: AOAM531SOdeIPpyjzksEWrR/FnJm0VFO3Y8Zfo8rrSRhPcKnjtemYPId OW+cCb46LDqS4UzCoOKrf/ieSpHLIu4= X-Google-Smtp-Source: ABdhPJwjsSADS2dT4VRsNQD0UMPImQRlmwzjACfeaaPJs/Dl1cm5dle/an4EU8yTN9mIkrx8Y0JK0Q== X-Received: by 2002:a5d:460d:: with SMTP id t13mr60155wrq.44.1636991697842; Mon, 15 Nov 2021 07:54:57 -0800 (PST) Received: from rimwks.local ([2001:470:1f15:3d8:1d64:73e:5d57:ae06]) by smtp.gmail.com with ESMTPSA id z12sm14829048wrv.78.2021.11.15.07.54.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 07:54:57 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Mon, 15 Nov 2021 18:54:55 +0300 To: freebsd-hackers@FreeBSD.org Cc: Rozhuk Ivan Subject: What happen with disk space? Message-ID: <20211115185455.1cb9992a@rimwks.local> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HtDKZ5fgLz3mPT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=N+jK+FTu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; 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)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N # df -cHi Filesystem Size Used Avail Capacity iused ifree %iused Mounted on .... /dev/concat/16TB________.eli 16T 16T 9.0G 100% 22k 246M 0% /mnt/16TB________ /dev/mirror/10T________.eli 9.7T 8.8T 124G 99% 45k 1.2G 0% /mnt/10T________ /dev/gptid/87978976-10a9-11eb-ad6e-346346346346.eli 5.8T 4.1T 1.3T 76% 1.3M 732M 0% /mnt/backup /dev/ada3p1.eli 5.8T 4.1T 1.3T 76% 1.3M 732M 0% /mnt/tmp Why Size != Used + Avail? UFS2 in all cases. From nobody Mon Nov 15 16:35:56 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5D75C18881D0 for ; Mon, 15 Nov 2021 16:36:05 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (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 4HtFF11cpqz4VBX for ; Mon, 15 Nov 2021 16:36:02 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4HtFDw62wrz6fWD; Mon, 15 Nov 2021 17:36:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1636994158; x= 1638808559; bh=0OjJull/9vnM5l8/KnnEDBV62v+LYkpujoY0dZCJb6Q=; b=d 3IsSx4sxNub0qevTk9l/JNWLyh145qkXX2L4/0JSyoXewSGTky52UZS3HvyRY5Op m8fk7nTT37R2tud9B1l2aa25FYomYua2lx+bYMz5c7ud3FJ2FnIalgh2Rx7y9YUd unhjbhoOH0RoScc60rSANvhN6tHrNxvj4gq85mDbG5RXyKgeAm672OPBKIiv7Rbb gtiBweOE37Pd9w1Z5nML0AhCW70YH0m7GzhYipdPnpQ7ydFECE8VUp2iYyWTfEHb B1TqHqShPkMvgvEc8ru/TbkY0grjPb6ZsBQN22Q7sdhUJzgIV6dkfylMJua53gzB AhumyhYj5nfnfy/2tk0NQ== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id N_8SRXhRt2gv; Mon, 15 Nov 2021 17:35:58 +0100 (CET) Message-ID: Date: Mon, 15 Nov 2021 17:35:56 +0100 Subject: Re: What happen with disk space? Content-Language: en-US To: Rozhuk Ivan , freebsd-hackers@FreeBSD.org References: <20211115185455.1cb9992a@rimwks.local> In-Reply-To: <20211115185455.1cb9992a@rimwks.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HtFF11cpqz4VBX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] Reply-To: mad@madpilot.net From: Guido Falsi via freebsd-hackers X-Original-From: Guido Falsi X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 15/11/21 16:54, Rozhuk Ivan wrote: > > > # df -cHi > Filesystem Size Used Avail Capacity iused ifree %iused Mounted on > .... > /dev/concat/16TB________.eli 16T 16T 9.0G 100% 22k 246M 0% /mnt/16TB________ > /dev/mirror/10T________.eli 9.7T 8.8T 124G 99% 45k 1.2G 0% /mnt/10T________ > /dev/gptid/87978976-10a9-11eb-ad6e-346346346346.eli 5.8T 4.1T 1.3T 76% 1.3M 732M 0% /mnt/backup > /dev/ada3p1.eli 5.8T 4.1T 1.3T 76% 1.3M 732M 0% /mnt/tmp > > Why Size != Used + Avail? AFAIK in UNIX it has always been like this, I guess since 4BSD at least, maybe even in v6. explanation is in minfree, -m option tu tunefs(8). part of the disk space is reserved for system usage and is accessible only to root. df(1) calculates avail based on that, while size is the actual full size (if I remember correctly). ZFS too shows the same behaviour. -- Guido Falsi From nobody Mon Nov 15 16:47:44 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A7FDF188E0F4; Mon, 15 Nov 2021 16:47:46 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtFVV3y4vz4Zhw; Mon, 15 Nov 2021 16:47:46 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1636994866; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=m+iAUVB0VdGYXfnHCgBmER8qhWHmOpGg6tJMTEIf3jc=; b=arRU/kkFqnRjt9tH2y+Lch2OMfwK/Yv7qtiSIe8E7EUXWS8rUrJdT0Oi7BKhiKRq57LRuC BAviWpcpw6geH/i88Qq2AsJcVA209EvAAYrWlNH2cO0Bty1yw4K6OnJPXVtIWisKO/qV0J wMNrEhkebmtJIQPg+/li6FXVqDkhvEGJ0tUHinP3B0EnK1lX/x8Hq69k8oXrn9ejUoGxOU LdWYvQ4XAB03HcYir4A6ciJJUxLIfPEuXVOEcxF0MJsspANdDpdMNjCwXyokMJnb7iF2Ug NLW2+Qq5/tcNmHHRbpppFxjq9M3Pukr7XcXRjIdxwjcx++fCx0vAmiGihqGWXA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 702981BB1D; Mon, 15 Nov 2021 16:47:46 +0000 (UTC) Date: Mon, 15 Nov 2021 17:47:44 +0100 From: Daniel Ebdrup Jensen To: hackers@FreeBSD.org Cc: current@FreeBSD.org, stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2021 Message-ID: <20211115164744.chsesrxkz3bb4wct@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , hackers@FreeBSD.org, current@FreeBSD.org, stable@FreeBSD.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="66dsezfsnajsewcm" Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1636994866; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=m+iAUVB0VdGYXfnHCgBmER8qhWHmOpGg6tJMTEIf3jc=; b=qsbgdTuE4/drg/gfERD1lYv7/TTrdYPRAbv36xHF4Ptp1dxWEeSlAnzFSE4jlta+BK2pXj SXmn+JErgXWhOsM+dBtG8Zjza0XasueA0briFqa9/zh8MOyvOf/6gGCa+9WJQ8WlT3A+k4 Evo0MIHzCi7cnpeOJgbFQI7iFz1nGKkwf6fesSexjgRVvUuINz1WtO86bXkfIALNOChIb/ PFTUSRBUN3qYBifA/BaJcfOEAXx6G06yUBpmQw/Oh/v4gPIfBFMaJInt/+PBcGNmDC2ugD 8iqph3Xp+lnvIZRHOVPmRn8s86bIkEaQRwz4Z8CfPPQmEFGAahwrmDLlrOpWyA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1636994866; a=rsa-sha256; cv=none; b=jWTTTGm7W3kWvtsH+6WaC+NDd4uYReFSQyVxxVLhqWXvO2n3GFcwI8E7Yx7yyOKyl1M2Lc GCsMVKasxl2WruS2tcjeSUjU2VI2XsLjMIDG6iRslFZoyrSJtuE4K1P46gmDpWj3G1k7nJ 8CRtTOmLakqQrJByRcBfd05yGNWET3YJEOo/Rqw9moaaTl1C3rpzIzKBayg29TbdSr9VOY eK5A2Uycwtanztk8B056g7OtmmpeZcgyrDHaami0wkVk5+pByQHVaRI+hq10EE8MIMvMjV 2kURTJ4Bp0wL3Nd6eanRPTpZpYswHC3TsCmrKgJ2r7fhG+uzcixnuEKacYg0/A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --66dsezfsnajsewcm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Quarterly Status Report 3rd Quarter 2021 This report covers FreeBSD related projects for the period between July and September, and is the third of four planned reports for 2021, and contains = 42 entries. The third quarter of 2021 was quite active in lots of different areas, so t= he report covers a bunch of interesting work including but not limited to boot performance, compile-time analysis, hole-punching support, various drivers,= ZFS raidz expansion, an update to the sound mixer, and many more. Regrettably, the status report got a bit delayed, but we hope that the apho= rism better late than never can apply here. Yours, Daniel Ebdrup Jensen, with status hat on. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Table of Contents =E2=80=A2 FreeBSD Team Reports =E2=96=A1 FreeBSD Foundation =E2=96=A1 FreeBSD Release Engineering Team =E2=96=A1 Cluster Administration Team =E2=96=A1 Continuous Integration =E2=96=A1 Ports Collection =E2=96=A1 Documentation Engineering Team =E2=96=A1 FreeBSD Website Revamp - WebApps working group =E2=80=A2 Projects =E2=96=A1 Boot Performance Improvements =E2=96=A1 Git Migration Working Group =E2=96=A1 LLDB Debugger Improvements =E2=96=A1 Linux compatibility layer update =E2=96=A1 Sound mixer improvements =E2=96=A1 Base System OpenSSH Update =E2=80=A2 Kernel =E2=96=A1 Arm64 improvements =E2=96=A1 FreeBSD on Microsoft HyperV and Azure =E2=96=A1 Improved amd64 UEFI boot =E2=96=A1 ENA FreeBSD Driver Update =E2=96=A1 Hole-punching support on FreeBSD =E2=96=A1 Intel Networking on FreeBSD =E2=96=A1 Intel Wireless driver support =E2=96=A1 Microchip LAN743x mgb(4) Device Driver =E2=96=A1 Fixes for msdosfs_rename VOP =E2=96=A1 OpenZFS RAIDZ Expansion update =E2=96=A1 RFC1191 support in IPSEC tunnels =E2=96=A1 Realtek rtw88 support =E2=96=A1 Marvell SDHCI improvements and ACPI support =E2=96=A1 Stack gap handling improvements =E2=96=A1 syzkaller on FreeBSD =E2=96=A1 Using OCF in WireGuard =E2=96=A1 Intel Volume Management Device driver update =E2=80=A2 Ports =E2=96=A1 Improve CPE Data in the Ports Collection =E2=96=A1 Why do we need it? =E2=96=A1 How can I help? =E2=96=A1 Open Tasks =E2=96=A1 FreeBSD Erlang Ecosystem Ports update =E2=96=A1 KDE on FreeBSD =E2=96=A1 OpenSearch on FreeBSD =E2=96=A1 Valgrind - Official Support for FreeBSD has Landed =E2=96=A1 Wine on FreeBSD =E2=96=A1 Ztop =E2=80=A2 Miscellaneous =E2=96=A1 -CURRENT compilation time analysis =E2=80=A2 Third-Party Projects =E2=96=A1 Gitlab 14.3 available =E2=96=A1 helloSystem =E2=96=A1 Containers & FreeBSD: Pot, Potluck & Potman =E2=96=A1 WireGuard on FreeBSD Stabilizes, Eyes Upstreaming =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation Links: FreeBSD Foundation URL: https://www.FreeBSDfoundation.org Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadm= ap/ Donate URL: https://www.FreeBSDfoundation.org/donate/ Foundation Partnership Program URL: https://www.FreeBSDfoundation.org/ FreeBSD-foundation-partnership-program FreeBSD Journal URL: https://www.FreeBSDfoundation.org/journal/ Foundation News and Events URL: https://www.FreeBSDfoundation.org/ news-and-events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Donat= ions =66rom individuals and corporations are used to fund and manage software development projects, conferences, and developer summits. We also provide travel grants to FreeBSD contributors, purchase and support hardware to imp= rove and maintain FreeBSD infrastructure, and provide resources to improve secur= ity, quality assurance, and release engineering efforts. We publish marketing material to promote, educate, and advocate for the FreeBSD Project, facilit= ate collaboration between commercial vendors and FreeBSD developers, and finall= y, represent the FreeBSD Project in executing contracts, license agreements, a= nd other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Fundraising Efforts Fundraising last quarter wasn=E2=80=99t as spectacular as we were hoping. B= ut, then again, people tend to take vacations during the summer months, which makes = it that more difficult for our funding requests to go through the management c= hain for approvals. So far this year we=E2=80=99ve raised $180,000 towards our $2,000,000 spend= ing budget. Why do we need so much money? Well, last year we decided to make more significant software contributions to FreeBSD. In order to do that, we had = to grow our team. We developed a technology roadmap based on input we were receiving from commercial users as well as market trends. Based on the road= map, we identified positions we needed to fill. This year we=E2=80=99ve hired three full-time software developers, one full= -time ARM kernel developer, and one project manager. We also are funding wifi work full-time and some other projects to help with FreeBSD on the desktop. You = can read about this effort to attract new users and contributors to the Project= in individual entries elsewhere in this status report. Our growth wasn=E2=80=99t just in our technology team, but in our advocacy = team too. Here we hired a marketing coordinator and technical writer to provide more educational and informational content. You=E2=80=99ll see in the Advocacy a= nd Education section below all the work we did to promote FreeBSD, provide community engagement, education opportunities, and informative content to help pave t= he path to getting started with FreeBSD. You=E2=80=99ll find out how we used your donations here and in individual e= ntries throughout this status report. We=E2=80=99re passionate about supporting you, the FreeBSD community, but w= e can=E2=80=99t do it without your financial support. Please consider making a donation to help us continue and increase our supp= ort for FreeBSD in 2021: https://www.FreeBSDfoundation.org/donate/. We also have the Partnership Program, to provide more benefits for our larg= er commercial donors. Find out more information at https:// www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements During the third quarter, Foundation staff and grant recipients committed 4= 20 src tree changes, 24 ports tree changes, and 11 doc tree changes. This represents 38%, 48%, and 16% of src, port, and doc commits which identify a sponsor. You can read about Foundation-sponsored projects in individual quarterly re= port entries: =E2=80=A2 Base System OpenSSH Update =E2=80=A2 Fixes for msdosfs_rename VOP =E2=80=A2 Hole Punching =E2=80=A2 Improved amd64 UEFI boot =E2=80=A2 Intel Wireless driver support =E2=80=A2 LLDB Debugger Improvements =E2=80=A2 Microchip LAN743x mgb(4) Device Driver =E2=80=A2 OpenZFS RAIDZ Expansion update =E2=80=A2 Using OCF in WireGuard =E2=80=A2 syzkaller on FreeBSD Foundation-sponsored arm64 work: =E2=80=A2 Support for booting FreeBSD on the Arm Armv8-A AEM simulator =E2=80=A2 sha256 instruction support to libmd(4) on arm64 =E2=80=A2 Initial work to support RAS, PAC and BTI on arm64 Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects to impr= ove continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. See the separate Continuous Integration entry for details. Supporting FreeBSD Infrastructure The Foundation provides hardware and support for the Project. Last quarter,= we continued supporting the test cluster at Sentex, purchased a few needed dri= ves and spam filtering software for project email. We also set up a new and more efficient hardware request/purchase process for clusteradm to use. Partnerships and Commercial User Support We met virtually with corporate users and started travelling again in late = Q3 for some in-person meetings. The goals of the meetings are to facilitate collaboration between commercial users and FreeBSD developers. We also met = with companies to discuss their needs and share that information with the Projec= t. FreeBSD Advocacy and Education Much of our effort is dedicated to Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature, attending even= ts, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology even= ts geared towards underrepresented groups. We support the FreeBSD-focused even= ts to help provide a venue for sharing knowledge, working together on projects, and facilitating collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We finally made it back to our first in-person meeting with the Open Source Su= mmit in late September. We are also continuing to attend virtual events. In addi= tion to attending and planning virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilit= ate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: =E2=80=A2 Participated as an Industry Partner for USENIX ATC and OSD, Jul= y 14-16, 2021 =E2=80=A2 Participated as an Industry Partner for USENIX Security, August= 11-13, 2021 =E2=80=A2 Held a FreeBSD Friday: How to Track FreeBSD Using Git =E2=80=A2 Sponsored and gave a talk at OpenFest 2020 in Sofia, Bulgaria, = August 14-15, 2021 =E2=80=A2 Began planning for the November 2021 FreeBSD Vendor Summit to b= e held online, November 18-19 =E2=80=A2 Presented at APNIC on August 13-16, 2021 =E2=80=A2 Served as a Nonprofit In-Kind Sponsor of OSI=E2=80=99s POSI 202= 1, September 16, 2021 =E2=80=A2 Sponsored EuroBSDcon at the Silver Level. The event took place,= September 17-19, 2021 =E2=80=A2 Presented at Open Source Summit, in Seattle, WA, September 27-3= 0, 2021 =E2=80=A2 Committed to be a Bronze Sponsor for the OpenZFS Summit =E2=80=A2 New blog and video posts: =E2=96=A1 Status of Online Conference Software on FreeBSD =E2=96=A1 Meet the Summer 2021 Foundation Interns =E2=96=A1 A Look at Profiling: FreeBSD Sort =E2=96=A1 Meet the 2021 FreeBSD Google Summer of Code Students =E2=96=A1 A Co-op Term at the FreeBSD Foundation =E2=96=A1 Technology Roadmap =E2=80=A2 Devstyler Interview with Deb Goodkin =E2=80=A2 New Video How-to Guides on installing HelloSystem and installin= g GhostBSD =E2=80=A2 New Quick Start Guide on Printing on FreeBSD =E2=80=A2 Committed to be a Media Sponsor for All Things Open We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https= :// www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https= :// www.FreeBSDfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://www.FreeBSDfoundation.org to find more about how we support FreeBSD and how we can help you! =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD Release Engineering Team Links: FreeBSD 12.3-RELEASE schedule URL: https://www.freebsd.org/releases/12.3R/ schedule/ FreeBSD releases URL: https://download.freebsd.org/ftp/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapsho= ts/ ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publish= ing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. Throughout the third quarter, several development snapshots builds were released for the main, stable/13, and stable/12 branches. More work had been done on various release-related tooling following the conversion from Subversion to Git. Additionally, the team had drafted the proposed schedule= for the upcoming 12.3-RELEASE. Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administra= tion /#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronise its distributed work and communications. In this quarter, the team has worked on the following: =E2=80=A2 Fixed www.FreeBSD.org mirror sync source =E2=80=A2 Improvements to GeoDNS for {download,ftp,pkg}.FreeBSD.org =E2=80=A2 Added IPv6 support =E2=80=A2 More optimal mirror selection in Asia =E2=80=A2 Finished installing a new mirror site in Japan, sponsored by Br= oadband Tower, Inc. =E2=80=A2 Full mirror site (ftp, pkg, git, doc, dns,=E2=80=A6=E2=80=8B) =E2=80=A2 The network and machine resources for this mirror are generousl= y sponsored by the Cloud and SDN Laboratory at BroadBand Tower, Inc., one of the Internet data center service providers in Tokyo, Japan, with 300+ Gbps international IP transit bandwidth =E2=80=A2 Improved the retention script used for the artifact server of C= I cluster to offer a mix of the latest artifacts but also a selection of older artif= acts for comparison, space permitting =E2=80=A2 Ongoing day to day cluster administration =E2=80=A2 Replacing failed disks =E2=80=A2 Babysitting pkgsync Work in progress: =E2=80=A2 Move pkg-master.nyi to new hardware =E2=80=A2 Improve the package building infrastructure =E2=80=A2 Review the service jails and service administrators operation =E2=80=A2 Setup powerpc pkgbuilder/ref/universal machines =E2=80=A2 Search for more providers that can fit the requirements for a g= eneric mirrored layout or a tiny mirror =E2=80=A2 Upgrading public-facing cluster services from 12.2-STABLE to 13= =2E0-STABLE =E2=80=A2 Working with doceng@ to improve https://www.freebsd.org and htt= ps:// docs.freebsd.org =E2=80=A2 Improve the web service architecture =E2=80=A2 Improve the cluster backup plan =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maau= wg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci+ dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system of the Free= BSD project. The CI system checks the committed changes can be successfully bui= lt, then performs various tests and analysis over the newly built results. The artifacts from those builds are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds= and unstable tests and work with the experts in that area to fix the code or ad= just test infrastructure. During the third quarter of 2021, we continued working with the contributors and developers in the project to fulfil their testing needs and also keep collaborating with external projects and companies to improve their products and FreeBSD. Important changes: =E2=80=A2 The results of FreeBSD-main-amd64-build and FreeBSD-main-amd64-= test jobs are sent to the dev-ci mailing list New jobs: =E2=80=A2 Run tests with KASAN enabled for main on amd64 =E2=80=A2 Run tests with KMSAN enabled for main on amd64 Retired jobs: =E2=80=A2 The jobs for stable/11 branch were removed after September 30th= per FreeBSD 11.4 end-of-life Work in progress and open tasks: =E2=80=A2 Designing and implementing pre-commit CI building and testing (= to support the workflow working group) =E2=80=A2 Designing and implementing use of CI cluster to build release a= rtifacts as release engineering does =E2=80=A2 Collecting and sorting CI tasks and ideas here =E2=80=A2 Testing and merging pull requests in the FreeBSD-ci repo =E2=80=A2 Reducing the procedures of CI/test environment setting up for c= ontributors and developers =E2=80=A2 Setting up the CI stage environment and putting the experimenta= l jobs on it =E2=80=A2 Setting up public network access for the VM guest running tests =E2=80=A2 Implementing using bare metal hardware to run test suites =E2=80=A2 Adding drm ports building tests against -CURRENT =E2=80=A2 Planning to run ztest tests =E2=80=A2 Adding more external toolchain related jobs =E2=80=A2 Improving maturity of the hardware lab and adding more hardware= under test =E2=80=A2 Helping more software get FreeBSD support in its CI pipeline (W= iki pages: 3rdPartySoftwareCI, HostedCI) =E2=80=A2 Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and d= on=E2=80=99t hesitate to join the effort! Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Ports Collection Links: About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributin= g/ ports-contributing/ FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/ Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Ren=C3=A9 Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall directi= on of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. There are currently 46,500 ports in the Ports Tree according to FreshPorts.= The open PR count for ports is currently 2,588, of which 608 are unassigned. The last quarter saw 9,833 commits on the "main" branch by 148 committers and 7= 43 commits on the quarterly branch by 54 committers. Compared to 2021q2, activ= ity mostly remained the same, the PR counts increased a bit but there were also more commits to the quarterly branch. During 2021q3, we welcomed Daniel Engberg (diizzy@) and Yasuhiro Kimura (yasu@), and we said goodbye to culot@ and grog@ after their commit bits we= re taken in for safekeeping. Two new uses were introduced: angr to help with testing Python-related ports and mlt to help depending on mlt, a multimedia framework for TV broadcastin= g. Ruby saw minor updates for the 2.6, 2.7, and 3.0 series. The "big" packages were also updated: pkg to 1.17.2, Firefox to 93.0, and Chromium to 92.0.4515.159. As usual, exp-runs were performed by antoine@ but only those of July were recorded. There were 5 exp-runs to test adding CLOCK_\*_COARSE compatibility definitions for Linux and to test ports updates. Furthermore, rene@ gave a presentation "portmgr: behind the scenes" at EuroBSDCon 2021 about how portmgr came to be and its daily activities. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Documentation Engineering Team Links: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ FreeBSD Documentation Project Primer for New Contributors URL: link:https:// docs.freebsd.org/en/books/fdp-primer/ Documentation Engineering Team URL: https://www.freebsd.org/administration/# t-doceng Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associ= ated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. During the last quarter, Philip Paeps (philip@) and Li-Wen Hsu (lwhsu@), already src and ports committers, were granted documentation commit bits, b= oth now have all commit bit types. Ed Maste (emaste@) who is already a src committer was granted a documentation commit bit. We also said goodbye to Murray Stokely (murray@), G=C3=A1bor K=C3=B6vesd=C3=A1n (gabor@), Warren Bl= ock (wblock@), and Sevan Janiyan (sevan@). G=C3=A1bor K=C3=B6vesd=C3=A1n (gabor@) and Warren B= lock (wblock@) are now former members of the doceng@ team; we thank them for their years of service. Implicit (blanket) approvals were documented in the Committers Guide. That = does not cover all cases, but doceng@ encourages any FreeBSD committer from ports and src to contribute to the doc tree. All ports/packages misc/freebsd-doc-* were updated. They have the entire documentation set from the FreeBSD Documentation Project, like Handbook, FA= Q, articles, and more. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD Website Revamp - WebApps working group Contact: Sergio Carlavilla Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers= can follow and join the working group on the FreeBSD Slack channel #wg-www21. T= he work will be divided into four phases: 1. Redesign of the Documentation Portal Create a new design, responsive and with global search. (Work in progre= ss, almost complete) 2. Redesign of the Manual Pages on web Scripts to generate the HTML pages using mandoc. (Work in progress) 3. Redesign of the Ports page on web Ports scripts to create an applications portal. (Not started) 4. Redesign of the FreeBSD main website New design, responsive and dark theme. (Not started) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Boot Performance Improvements Links: Wiki page URL: https://wiki.freebsd.org/BootTime OS boot time comparison URL: https://www.daemonology.net/blog/ 2021-08-12-EC2-boot-time-benchmarking.html Contact: Colin Percival Colin Percival is coordinating an effort to speed up the FreeBSD boot proce= ss. For benchmarking purposes, he is using an EC2 c5.xlarge instance as a refer= ence platform and is measuring the time between when the virtual machine enters = the EC2 "running" state and when it is possible to SSH into the instance. This work started in 2017, leading to a conference presentation, "Profiling= the FreeBSD kernel boot", and quickly yielded roughly 4850 ms of improvements (starting from a baseline of about 30 seconds). Since June, another roughly 9790 ms of time has been shaved off the boot process, taking it down to approximately 15 seconds. There is still more wo= rk to be done; in particular, while the loader and kernel have been profiled, = the TSLOG system Colin is using does not currently support userland profiling. Issues are listed on the wiki page as they are identified; the wiki page al= so has instructions for performing profiling. Users are encouraged to profile = the boot process on their own systems, in case they experience delays which don= =E2=80=99t show up on the system Colin is using for testing. This work is supported by Colin=E2=80=99s FreeBSD/EC2 Patreon. Sponsor: https://www.patreon.com/cperciva =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Git Migration Working Group Links: Git for FreeBSD development wiki URL: https://wiki.freebsd.org/Git Git transition wiki URL: https://wiki.freebsd.org/GitTransition doc git repo web URL: https://cgit.FreeBSD.org/doc ports git repo web URL: https://cgit.FreeBSD.org/ports src (base system) git repo web URL: https://cgit.FreeBSD.org/src Committers guide Git primer URL: https://docs.freebsd.org/en/articles/ committers-guide/#git-primer Handbook Using Git appendix URL: https://docs.freebsd.org/en/books/handbook/ mirrors/#git Game of Trees URL: http://gameoftrees.org/ gitup URL: https://github.com/johnmehr/gitup Contact: Li-Wen Hsu Contact: Warner Losh Contact: Ed Maste Contact: FreeBSD-git mailing list Contact: #gitcvt channel on EFnet With the end of the third quarter of 2021, we are approaching the one-year anniversary of the transition of the doc and src repositories from Subversi= on to Git. The 2021Q4 branch of the ports tree has been created, the third quarterly branch created using Git. During 2021Q3, repository hooks have been refined as problems were discover= ed and a few lingering references to Subversion were updated in the Committer= =E2=80=99s Guide. The Working Group continues to track progress on two permissively-licensed Git-compatible tools: Gitup and Game of Trees. Gitup = is a small, dependency-free tool to clone and update git repositories. It is used only to keep a local tree up-to-date, and has no support for local commits. Game of Trees is a version control client that is compatible with Git repositories. It provides a user interface and workflow that is distinct fr= om that of Git. It is in no way intended to be a drop-in replacement for Git, = but can be used to develop software maintained in a Git repository. Gitup and Game of Trees are currently available as ports and packages. Futu= re work will evaluate them as candidates for the base system. Remaining work includes continuing with refinements to Git documentation in= the Handbook, committing new and updated repository hooks for managing branch content and commit mail, and surveying pre-commit hooks to use the CI clust= er to build release artifacts. Priorities have been set for the next working g= roup tasked with refining our Git workflow. The first meeting will be in mid-October. Sponsor: The FreeBSD Foundation (in part) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 LLDB Debugger Improvements Links: Moritz Systems Project Description URL: link:https://www.moritz.systems/blo= g/ freebsd-kgdb-support-in-lldb/ Progress Report 1 URL: https://www.moritz.systems/blog/ improving-gdb-protocol-compatibility-in-lldb/ Progress Report 2 URL: https://www.moritz.systems/blog/ improving-gdb-register-model-compatibility-in-lldb/ Git Repository URL: https://github.com/moritz-systems/llvm-project Contact: Kamil Rytarowski Contact: Micha=C5=82 G=C3=B3rny According to the upstream description, "LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler." FreeBSD includes LLDB in the base system. At present, it has some limitatio= ns compared to the GNU GDB debugger, and does not yet provide a complete replacement. This project spans from July 2021 to January 2022 and aims to = make LLDB suitable for debugging FreeBSD kernels. The work so far was focused on improving the compatibility between LLDB and other servers implementing the GDB Remote Protocol. Multiple bugs were fixed that limited LLDB=E2=80=99s functionality when interfacing with GNU GDB=E2= =80=99s gdbserver and QEMU=E2=80=99s gdbserver implementations. Support for debugging executables= running on gdbserver architectures other than amd64 was fixed, and was explicitly test= ed on arm64 and i386. This effort also resulted in adjusting lldb-server=E2=80=99s implementation= to conform better to the standard set by GDB. Thanks to these improvements, the LLDB client needs to provide less divergent code paths depending on the server u= sed, and the single code path used is tested more thoroughly. The work also involved improvements to the LLDB API and code deduplication, that result in reducing the maintenance effort and lowering the bar for fut= ure contributions. The test coverage was improved, increasing the likelihood th= at any future problems will be detected before they affect users. The introduced changes are expected to be shipped with LLDB 14.0. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Linux compatibility layer update Contact: Dmitry Chagin, Contact: Edward Tomasz Napierala, The goal of this project is to improve FreeBSD=E2=80=99s ability to execute= unmodified Linux binaries. The current support status of specific Linux applications is being tracked on the Linux app status Wiki page. The vdso(7) implementation was reworked. The futex(2) support was overhaule= d to make use of FreeBSD=E2=80=99s native umtx mechanism. It now supports priority-inheritance futexes, in addition to fixing several bugs. The rt_sigsuspend(2) and sigaltstack(2) syscalls are now supported on ARM64. The faccessat2(2), clone3(2) system calls are now implemented. The CLONE_CLEAR_RESETHAND option is now supported. The prctl(2) syscall now supports PR_SET_NO_NEW_PRIVS. The ptrace(2) syscall now supports PTRACE_GET_SYSCALL_INFO, which is a prerequisite to support newer strace(1) versions. There is ongoing work to make Linuxulator on arm64 on par with the amd64 on= e; right now it=E2=80=99s good enough for development work. Sponsor: EPSRC (Edward=E2=80=99s work) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Sound mixer improvements Links: GSoC 2021 project article URL: https://wiki.freebsd.org/ SummerOfCode2021Projects/SoundMixerImprovements Contact: Christos Margiolis Contact: Hans Petter Selasky This project is an attempt to improve the capabilities of the OSS sound mix= er on FreeBSD. This means a new mixer(3) library, a complete rewrite of mixer(= 8), and updates to sound(4). Development started during Google Summer of Code 2021, but will likely cont= inue independently. Applied changes: =E2=80=A2 Implement OSS mixer (un)muting ioctls in sound(4) (commit 0f8da= fb45859). =E2=80=A2 Implement playback/recording mode sysctl (commit ed2196e5df0c). =E2=80=A2 Implement mixer(3) and new version of mixer(8) (commit 903873ce= 1560). Patches, comments and discussion are all welcome. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Base System OpenSSH Update Links: OpenSSH URL: https://www.openssh.com/ Announcement to freebsd-security@ URL: https://lists.freebsd.org/pipermail/ freebsd-security/2021-September/010473.html Contact: Ed Maste OpenSSH, a suite of remote login and file transfer tools, was updated from version 7.9p1 to 8.7p1 in the FreeBSD base system. FreeBSD base OpenSSH includes a number of local bug fixes, configuration changes, and small features. As part of the work for this update, I submitt= ed some of these upstream and am preparing to do the same with the remaining changes. OpenSSH now supports FIDO/U2F devices, although additional work is required= to enable this in the FreeBSD base system. This includes importing a pair of dependencies: libcbor, and libfido2. Within the next couple of months I exp= ect to import these, enable FIDO/U2F support, and update to OpenSSH version 8.8= p1. NOTE: OpenSSH 8.8p1 will disable the ssh-rsa signature scheme by default, so some additional work is required for this next update. For more information please see the Important note for future FreeBSD base system OpenSSH update mailing list post. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Kernel Updates to kernel subsystems/features, driver support, filesystems, and mor= e. Arm64 improvements Links: Pointer Authentication Review URL: https://reviews.freebsd.org/D31261 Contact: Andrew Turner FreeBSD has been ported to the Arm Armv8-A Architecture Envelope Model (AEM= ), an Armv8 architecture simulator. AEM is useful for Armv8 development and testing, because it supports different configurations, including the abilit= y to enable or disable different extensions. As part of this work, the virtio le= gacy pci driver was fixed and ACPI resource parsing code was updated to work with the ACPI tables that the model provides. Libmd(4) has been updated to use the sha256 instructions when available. Th= is can lead to a large performance improvement when these instructions are available. For example, on the Apple M1 under a hypervisor, the time to calculate the sha256 of a 1GB file has decreased from a median of 3.46s to 0.5s. Using an ifunc (indirect function) in a static binary is now supported. This will allow different implementations of a function to be used depending on which hardware it is being run on. Using an ifunc in dynamic binaries was already supported. The arm64 ID register definitions have been updated to match the Armv8.5 specification and other special registers have been updated to the Armv8.7 spec. There have been numerous cleanups in decoding the arm64 ID registers in the kernel to ensure we provide a consistent view of the hardware to userspace = if it reads the emulated ID register directly, or uses an ELF HWCAP value. There has been early work on supporting the Arm Reliability, Availability, = and Serviceability (RAS) extension. The external aborts it may use are now hand= led in the kernel. Support for the Arm Pointer Authentication extension is under review. This extension allows programs to use new instructions that add a hash to unused bits in a code or data pointer. They can then later check the hash in a way that will either, depending on the CPU, create an invalid pointer or raise = an exception. This can be used to protect the function return address from bei= ng overwritten, making Return Oriented Programming (ROP) attacks difficult. The change supports both userspace and kernel pointer authentication. It is wai= ting on debugger changes to be sent upstream so lldb can clear the hash when nee= ded, e.g., in a stack trace. Work has started on supporting the Branch Target Identification extension. = This adds a flag to the page tables to disallow unintended targets from some bra= nch instructions. When a CPU branches to a new location from a register, the CPU will check if the instruction is correct. This will protect, e.g., against a function pointer being called when it points to the middle of a function. T= he kernel has been built with this feature enabled and tested in the Arm AEM. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/ MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/Hype= rV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Li-Wen Hsu The 13.0-RELEASE image on Azure Marketplace has been published. The changes for building official images on Azure Marketplace, which fulfill the requirements of Azure and FreeBSD cloud images like disk layout and UEFI for Gen2 VM, along with some minor improvements like configurations to spee= d up booting, have been imported. Above tasks are sponsored by The FreeBSD Foundation, with resources provide= d by Microsoft. Microsoft Azure Network Adapter (MANA) is the new network adapter from Microsoft which will be available in the Azure public cloud. It provides SR= -IOV NIC as a Virtual Function (VF) to guest OS running on Hyper-V. Wei has been working on its driver for a while and committed in this quarter. This task is sponsored by Microsoft. Work in progress tasks: =E2=80=A2 Build and publish gen2 vm image to Azure Marketplace =E2=80=A2 Build and publish ZFS-based image to Azure Marketplace =E2=80=A2 Upstream local modifications of Azure agent =E2=80=A2 Update Azure agent port to the latest version Open tasks: =E2=80=A2 Update FreeBSD related doc at https://docs.microsoft.com =E2=80=A2 Support FreeBSD in Azure Pipelines =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Improved amd64 UEFI boot Contact: Konstantin Belousov UEFI BIOS on PC provides a much richer and more streamlined environment for pre-OS programs, but also imposes some requirements on the programs that are executed there, OS loaders in particular. One such requirement is that the loader must coordinate its memory use with the BIOS, only using memory that= was allocated for it. Even after the loader handoff to the operating system ker= nel, there are still some memory regions that are reserved by the BIOS for diffe= rent reasons. Examples are runtime services code and data. On the other hand, legacy/CSM BIOS boot works with memory completely differently; there are known memory regions that hold BIOS data and must be avoided. Otherwise, the memory is considered free for loader and OS to use.= (Of course it is not that straightforward, the definition of known regions is u= p to the vendor and there are a lot of workarounds there.) The BIOS boot puts the kernel and preloaded data (like modules, memory disk, CPU microcode update etc) at the contigous physical memory block starting at 2M. This algorithm goes back to how the i386 kernel boots. Also, when preparing to pass control to the kernel, the loader creates very special temporary mappings, where the low 1G of physical address space is mapped 1:1 into virtual address space, and then repeated for each 1G until = the virtual memory end. The kernel knows about its physical location and the temporary mapping, and constructs kernel page tables assuming that the phys= ical address of the text is at 2M. This mechanism of loader to kernel handoff was left unchanged when the load= er gained support for the UEFI environment. The loader prepares kernel and auxiliary preload data in a so-called staging area while UEFI boot services= are active, and after EFI_BOOT_SERVICES.ExitBootServices(), the temporary mappi= ng is activated and the staging area is copied at 2M. An advantage at that time was that no changes to the kernel were needed. But there are issues; the biggest is that memory at 2M might be not free for re= use. For instance, BIOS runtime code or data might be located there. Or there mi= ght be no memory at 2M at all. Or trampoline page table or code, or even some p= arts of the staging area overlapping with the 2M region where staging area is copied. The outcome was a hard to diagnose boot time failure, typically a h= ard hang when the loader started the kernel. Another limitation is the 1G transient mapping, which due to copying means = that the total size of preloaded data cannot exceed around 400M for everything, including kernel, memory disks, and anything else. Also the code to grow the staging area on demand was quite unflexible, only able to grow the staging = area in place. The work described in this report allows the UEFI loader on amd64 to start = the kernel from the staging area without copying. Kernel assumptions about the hand-off were explicitly identified and documented. The kernel only requires the staging area to be located below 4G together with the trampoline page t= able (this is a consequence of CPU architecture requiring 32bit protected mode to enter long mode), be 2M aligned and the whole low 4G mapped 1:1 at hand-off. The kernel computes its physical address and builds kernel page tables accordingly. Making the kernel boot with staging area in-place required identifying all places where the amd64 kernel had a dependency on its physical location. The most complicated part was application processors startup, which required rewriting initialization code, which we were able to streamline as result. = In particular, when an AP enters paging mode, it does so straight into the cor= rect kernel page table, without loading intermediate trampoline page table. The updated loader automatically detects if the loaded kernel can handle in-place staging area ('non-copying mode'). If needed, this can be overridd= en with the loader=E2=80=99s copy_staging command. For instance, 'copy_staging= enable' tells the loader to unconditionally copy the staging area to 2M regardless = of kernel capabilities (default is 'copy_staging auto'). Also, the code to grow the staging area was made much more robust, allowing it to grow without hand-tuning and recompiling the loader. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 ENA FreeBSD Driver Update Links: ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbs= d/ ena/README Contact: Michal Krawczyk Contact: Artur Rojek Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffi= c, depending on the instance type on which it is used. Completed since the last update: =E2=80=A2 Update ENA driver to v2.4.1 =E2=80=A2 Introduce full kernel RSS API support =E2=80=A2 Allow reconfiguration of the RSS indirection table and hash key =E2=80=A2 Support netmap on the c6gn/m6i AWS instance types =E2=80=A2 Fix race between detach function and some of the procedural sys= ctl nodes =E2=80=A2 Add new statistics counters =E2=80=A2 Improve safety of the reset handling routine =E2=80=A2 Avoid mbuf collapse on Tx path for the LLQ condition Work in progress: =E2=80=A2 Prototype the driver port to the iflib framework =E2=80=A2 MFC the ENA v2.4.1 driver to the FreeBSD 11/12/13-STABLE branch= es =E2=80=A2 Add IPv6 L4 checksum offload support to the driver Sponsor: Amazon.com Inc =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Hole-punching support on FreeBSD Links: Commit 0dc332bff200 URL: https://cgit.freebsd.org/src/commit/?id=3D 0dc332bff200c940edc36c4715b629a2e1e9f9ae Commit 9e202d036dd6 URL: https://cgit.freebsd.org/src/commit/?id=3D 9e202d036dd6f38ce0f578aa2086ebc358315bab Commit 5ee2c35751ef URL: https://cgit.freebsd.org/src/commit/?id=3D 5ee2c35751ef5d131222423bf3e25073f997c337 OpenZFS Pull Request #12458 URL: https://github.com/openzfs/zfs/pull/12458 Contact: Ka Ho Ng Hole-punching functionality allows turning a contiguous range of bytes into= a hole for a given file. File systems supporting hole-punching may deallocate= the file system space from the given file. One use case for the functionality i= s to convert TRIM/UNMAP/DEALLOCATE requests from a virtual machine guest to hole-punching calls on the host=E2=80=99s side, thus allows reclamation of = file system space when unneeded by the guest. A set of APIs and KPIs are added that developers can call to invoke hole-punching on a given file, if the underlying file system exposes that functionality. For file systems not supporting hole-punching there is a fallback implementation in the kernel which does zero-filling instead. Besi= des the APIs and KPIs addition, the truncate(1) utility is expanded by adding a= -d flag to support invoking hole-punching as well. At the time of writing this report, OpenZFS and tmpfs are the file systems = that support hole-punching. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Intel Networking on FreeBSD Links: DPDK URL: https://github.com/DPDK/dpdk/tree/main/drivers/net Contact: Intel Contact: Kevin Bowling lem(4)/em(4)/igb(4) and ix(4) were updated with various common code improvements obtained from DPDK. There have also been several bug fixes from the community: =E2=80=A2 lem(4)/em(4)/igb(4) changes =E2=80=A2 ix(4) changes Intel has updated ixl(4) with various improvements: =E2=80=A2 ixl(4): Fix 2.5 and 5G speeds reporting and update shared code =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Intel Wireless driver support Links: iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Iwlwifi Contact: Bjoern A. Zeeb The Intel Wireless driver update project aims to bring support for newer chipsets along with mac80211 LinuxKPI compat code. The dual-licensed Intel driver code was ported in the past for the iwm(4) native driver; using the LinuxKPI compat framework allows us to use the driver directly, with only v= ery minor modificationsi that we hope will be incorporated into the original driver. After the initial snapshot at the end of June, another snapshot was release= d in early September. Thank you to everyone testing on CURRENT and reporting bac= k. While we keep updating the driver and all the compat code needed for that, = the focus now is on stability and adding support for newer 802.11 standards. The driver is currently set to 11a/b/g and 11n will be next before we look at 1= 1ac. We are currently trying to get as much into FreeBSD as is possible and makes sense. Full integration into FreeBSD main is waiting for a policy update. For the latest state of the development or code, please follow the referenc= ed wiki page or the freebsd-wireless mailing list. We expect to release another snapshot soon and hope to also support stable/13 again with that one. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Microchip LAN743x mgb(4) Device Driver Links: Commit adding mgb(4) driver URL: https://cgit.freebsd.org/src/commit/?id=3D 8890ab7758b8a03a68f3fe596f6a5446921631a5 Commit connecting mgb(4) module to the build URL: https://cgit.freebsd.org/= src/ commit/?id=3D543df609072fe49079c36d6bee510e1645edde3a Contact: Ed Maste Microchip=E2=80=99s LAN7430 and LAN7431 are PCIe Gigabit Ethernet interface= ICs, with an integrated PHY (LAN7430) or RGMII interface (LAN7431). In 2019 Gerald ND Aryeetey, a FreeBSD Foundation intern, developed the mgb(= 4) driver for these devices. It was added to the tree but not yet connected to= the build. Since it was committed a number of sweeping iflib changes were made, which included updates to mgb(4). I have addressed some outstanding issues in the driver, and have now added = the module to the build. It is available in -CURRENT snapshot images. The drive= r is functional, although some additional work is still needed. In particular, configuration of the Receive Filtering Engine, and VLAN and RX/TX checksum offload are required. Caveats and notes are described in the man page. I am very interested in feedback and test results. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Fixes for msdosfs_rename VOP Contact: Konstantin Belousov Contact: Peter Holm Our msdosfs(5) implementation is old code and has a relatively large legacy cost. In particular, even though it got fine-grained locking and miscellane= ous bugfixes over time, sometimes a serious issue is found in it. Recently trasz@ found that msdosfs rename can be easily deadlocked. Further examination of rename code revealed a lot of issues with locking, potential= use after free, and filesystem structure corruption. As part of the update, locking in the msdosfs rename code was reworked. We = need to lock up to four vnodes, and check one path to ensure that rename does not create circular parent relations between directories. For that, the locking procedure was copied from UFS rename, where all vnodes except the first are locked in try-mode. Lockless relockup was added to msdosfs and the directory path checker was changed to non-blocking mode. During this work, all known issues were fixed and msdosfs passes the enhanc= ed stress2 suite of tests. Sponsor: The FreeBSD Foundation (kib=E2=80=99s contributions) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 OpenZFS RAIDZ Expansion update Links: OpenZFS Pull Request URL: https://github.com/openzfs/zfs/pull/12225 video from 2021 FreeBSD Developer Summit URL: https://www.youtube.com/watch= ?v=3D yF2KgQGmUic slides from 2021 FreeBSD Developer Summit URL: https://docs.google.com/ presentation/d/1FeQgEwChrtNQBHfWSNsPK3Y53O5BnPh3Cz5nRa5GAQY/view news article from Ars Technica URL: https://arstechnica.com/gadgets/2021/06/ raidz-expansion-code-lands-in-openzfs-master/ Contact: Matthew Ahrens Project This feature allows disks to be added one at a time to a RAID-Z group, expanding its capacity incrementally. This feature is especially useful for small pools (typically with only one RAID-Z group), where there isn=E2=80= =99t sufficient hardware to add capacity by adding a whole new RAID-Z group (typically doubling the number of disks). FreeBSD=E2=80=99s ZFS implementation comes from the OpenZFS project. This w= ork will be integrated into the OpenZFS repo, with support for FreeBSD and Linux. Status The work is functionally complete, and a pull request has been opened. Remaining Work Remaining work includes some code cleanup, design documentation, addressing test failures. We also need to solicit code reviewers and respond to code review feedback. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 RFC1191 support in IPSEC tunnels Contact: Wojciech Macek The Semihalf team has been working on providing support for RFC1191 in IPSEC tunnels. This allows the PMTUD algorithm to dynamically discover the maximum path MTU the tunnel can handle and update tunnel parameters accordingly. As= a result, a better performance can be observed as there is no need for packet fragmentation. The newly introduced rework includes: =E2=80=A2 NEEDFRAG support for IPSEC commit d9d59bb1af1 =E2=80=A2 PMTUD for IPv4 IPSEC over IPv6 link commit 4f3376951d70 =E2=80=A2 Security fix as per RFC1191 specs commit b4220bf387e6 =E2=80=A2 PMTUD support for IPv6 tunnel commit 9dfc8606eb80 Sponsor: Stormshield =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Realtek rtw88 support Links: Rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw88 Contact: Bjoern A. Zeeb This project aims to bring in support for Realtek=E2=80=99s rtw88 chips. With the growing LinuxKPI compatibility code an initial port of the Realtek rtw88 driver was done. This gives us support for a second driver after Intel and helps to validate and grow the LinuxKPI code base. Changes and overall = time needed to get the driver compiling were very little. At the moment we are seeing DMA issues which prevent most people from loading firmware or using = the driver later on. Thanks to everyone who was brave enough to give this initial code drop a tr= y. While this is a leasure time project we would love to better support Realtek wireless devices and will keep working on this. For the latest state of the development or code, please follow the referenc= ed wiki page or the freebsd-wireless mailing list. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Marvell SDHCI improvements and ACPI support Contact: Bartlomiej Grzesik Contact: Marcin Wojtas The Semihalf team was working on the ACPI support for the Marvell Octeon TX2 CN913x and Armada 7k/8k SoCs' SD/MMC controller, as well as extending and improving the related generic parts of the FreeBSD OS. Applied changes: =E2=80=A2 Add ACPI_GET_PROPERTY to access Device Specific Data (DSD) comm= it b91fc6c43a81 =E2=80=A2 Introduce generic device_get_property/device_has_property, whic= h allow to obtain DT/ACPI properties with the same generic code commit 3f9a00e3b577 =E2=80=A2 Switch mmc_helper to device_* API, to access the controller des= cription from DT/ACPI in a unified way commit 8a8166e5bcfb =E2=80=A2 Add ACPI support for the sdhci_xenon driver commit d78e464d2330= and commit adbce5ff747b =E2=80=A2 Apply other minor improvements and fixes related to properties = parsing in core mmc code and sdhci_xenon driver. Sponsor: Semihalf =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Stack gap handling improvements Contact: Dawid Gorecki Contact: Marcin Wojtas Stack gap is a feature that randomizes the stack address by creating a rand= om sized gap between the top of stack and strings area. The current implementa= tion of this mitigation can cause issues for some applications e.g. Firefox ( PR239873). Until now the only workaround for this problem was disabling the stack gap for those programs, as is done for ntpd. Semihalf team has been working on fixing the root causes of stack gap relat= ed problems. One of the issues could be observed when setting the stack limit to a low v= alue with setrlimit(2). Since the stack gap size can be significant, and the pro= cess had no knowledge of how large the stack gap is, this caused programs to abo= rt immediately after returning from a syscall due to the stack extending past = the limit. The fix involves increasing the soft resource limit (rlim_cur) by the size of stack gap during the setrlimit(2) call. This fixes the issue with n= tpd without disabling the stack gap entirely. The patch is currently under revi= ew. The second identified problem is related to the way the thread stacks are handled. Thread stacks are calculated using the kern.usrstack sysctl, which should point to the beginning of the stack. This sysctl returned a constant value depending on the ABI and the presence of the stack gap was ignored. A= new sysctl was introduced, and the thread library was updated to use it accordingly. Patches D31897 and D31898 are currently under discussion. These fix the issues with Firefox and Thunderbird not starting with the stack gap feature enabled. Sponsor: Stormshield =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 syzkaller on FreeBSD Contact: Mark Johnston Contact: Michael Tuexen < tuexen@FreeBSD.org> syzkaller is a coverage-guided operating system kernel fuzzer. See the syzkaller entry in the 2019q1 quarterly report for an introduction to syzkaller. In the past quarter we made a concerted effort to shrink the backlog of rep= orts =66rom the public syzbot instance. A number of long-standing locking bugs i= n the socket subsystem have been fixed, and the SCTP protocol implementation has = seen many bug fixes as well. Beyond that, many bugs in various other kernel subsystems have been fixed and the backlog has become substantially smaller over the past quarter. As a direct result of this effort, we have been able= to identify regressions more easily and fix bugs closer to the time of introduction. Work is still ongoing to further shrink the backlog. KASAN (Kernel Address SANitizer) was enabled in the default kernel configuration used by syzbot, which has greatly enhanced our ability to root-cause and fix kernel bugs. See the kernel-sanitizers entry in the 2021= q2 quarterly report for an introduction to KASAN and KMSAN. KASAN helps ensure that memory safety bugs manifest more deterministically, improving syzkalle= r=E2=80=99s ability to find reproducers and simplifying debugging. A KMSAN (Kernel Memory SANitizer) port was committed to FreeBSD=E2=80=99s m= ain branch in August. Some initial work has been done to make it usable by syzkaller (mainly, kcov(4) required several small modifications to work in a KMSAN-enabled kernel), and a number of bugs were found and fixed using priv= ate syzkaller instances. Goals for the next several months include: =E2=80=A2 Addition of a KMSAN target in syzbot. =E2=80=A2 Further reduction in the syzbot backlog. =E2=80=A2 Upstreaming syzkaller patches to support fuzzing of the Linuxul= ator. =E2=80=A2 Fuzzing using ZFS-based VM images. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Using OCF in WireGuard Contact: John Baldwin I have looked at updating the data path crypto in the upstream WireGuard dr= iver to use the in-kernel OpenCrypto Framework for the data path. Data packets s= ent over a WireGuard tunnel are encrypted with the Chacha20-Poly1305 AEAD ciphe= r. Unlike TLS and IPsec, Wireguard uses an 8 byte nonce rather than a 12 byte nonce with this cipher. To date, most of the work has focused on updating OCF to better support multiple nonce (and tag/MAC) lengths for a given cipher. I resurrected an o= ld branch I had previously started on for this aimed at supporting all of the AES-CCM NIST KAT vectors many of which use non-default nonce and tag length= s. I have refined the approach to better fit the existing OCF model where nonce = and MAC lengths are properties of a session (similar to key lengths). (My earli= er branch had made the nonce length a property of individual operations instea= d.) Mostly this entailed extending the /dev/crypto interface to permit setting these parameters for a session. Existing tests for OCF run in userland and = use the /dev/crypto interface including both the cryptocheck utility and the NI= ST KAT vector tests. Building on these framework changes, I have extended the existing Chacha20-Poly1305 cipher in OCF to support both 8 and 12 byte nonces includ= ing in the accelerated ossl(4) driver. I also have a patch against the upstream WireGuard FreeBSD driver to make use of this for the dataplane and have verified that it interoperates with the stock WireGuard driver. Future work will focus on upstreaming the OCF changes as well as additional review of the upstream WireGuard driver. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Intel Volume Management Device driver update Links: main branch commit URL: https://cgit.freebsd.org/src/commit/?id=3D 7af4475a6e31202a865b1dd3727018659b44470f Contact: Alexander Motin Intel VMD is used by Intel=E2=80=99s VROC (Virtual RAID on chip) to isolate= parts of PCI tree, including NVMe devices, behind one or several VMD devices. Each V= MD device has 3 memory windows to access config space and memory of its child devices, plus some number (I saw 19 and 33) of MSI-X interrupt vectors to forward their MSI and MSI-X interrupts through. The vmd(4) driver was first introduced in FreeBSD 13.0, but was found to ha= ve a number of problems addressed in this update: - The VMD device was made to l= ook more like a regular PCI-to-PCI bridge, implementing the regular pcib(4) interface and using the standard pci(4) bus driver on top. - Memory and bus numbers resource management was rewritten to properly handle resource reque= sts using memory windows of the VMD device. - Interrupt handling was completely rewritten to distribute child interrupts among available VMD MSI-X vectors, setting them up to be handled via standard OS mechanisms with minimal overh= ead instead of custom dispatching via taskqueue. Due to the limited number of vectors and routing abilities of VMD, children are limited to only one MSI = or three MSI-X vectors per device to avoid sharing. The limits can be tuned, depending on the number of VMD vectors and children. To improve the flexibi= lity the nvme(4) driver was made to work with a limited number of vectors, start= ing =66rom just one MSI/MSI-X if needed. Sponsor: iXsystems, Inc. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Improve CPE Data in the Ports Collection Links: chkcpe URL: https://github.com/decke/chkcpe CPE on wiki.freebsd.org URL: https://wiki.freebsd.org/Ports/CPE CPE Dictionary URL: https://nvd.nist.gov/products/cpe Contact: Bernhard Froehlich Common Platform Enumeration (CPE) is an open standard for naming hardware a= nd software components. Originally developed by MITRE, it is now maintained by NIST under the aegis of the National Vulnerability Database. A CPE URI uniq= uely identifies a device or program by its vendor, product name, version, revisi= on, etc. NIST maintains the official CPE dictionary which lists CPE names for a= ll software versions that have ever been mentioned in an advisory. In the FreeBSD Ports Collection it has been possible to annotate CPE data w= ith USES=3Dcpe since 2014 but only around 1000 ports out of 30.000 did use it. = This is why a script called chkcpe was created to validate existing CPE data and find new possible matches automatically. Why do we need it? It allows comparing CPE URIs for installed packages against published vulnerability data and will give us a much better and more complete pkg aud= it. As a side effect we will also have a better overview of vulnerable ports in= the FreeBSD Ports Collection that need to be patched or updated. How can I help? In this phase there is no easy possibility for port maintainers to help. Creating separate PRs only to add CPE data does not make sense because the overhead is very high. This is why I did spend some time on chkcpe to impro= ve the review and commit workflow. Right now review and commit consumes around= 3 minutes per port. If you are a Ports Committer and want to help please get in touch! Open Tasks =E2=80=A2 Review remaining reports (~1800) and update ports when appropri= ate =E2=80=A2 Improve matching quality to find more possible matches =E2=80=A2 Support using CPE data in pkg audit =E2=80=A2 Scan for vulnerable ports in the Ports Collection =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD Erlang Ecosystem Ports update Links: FreeBSD Erlang wiki URL: https://wiki.freebsd.org/Erlang Erlang/OTP language URL: https://erlang.org/ Elixir language URL: https://elixir-lang.org/ Gleam language URL: https://gleam.run/ Contact: FreeBSD Erlang mailing list The Erlang runtime system, commonly known as the BEAM, provides a runtime t= hat is used by a number of programming languages and applications in the FreeBSD ports collection. Earlier this year, both Elixir and Erlang runtimes were brought up to date,= but as separate ports, to enable porters and users to test applications side by side. In Q3, the current runtimes have been brought across as defaults - this mea= ns that lang/elixir and lang/erlang are running as the latest releases of these superb programming languages and runtimes. Older releases of lang/erlang-runtime{21,22,23} are still available as port= s. The very old releases prior to OTP20 have been removed from the ports tree,= as they are no longer supported upstream either. Only newer OTP releases include the updated SSL application that will corre= ctly validate cross-signed certificates, as used in Let=E2=80=99s Encrypt=E2=80= =99s upcoming root certificate deprecations. Further details on these changes are well documented at Erlang/OTP impact of DST Root CA X3 expiration and DST Root CA X3 expiration update All of the NIF driver related ports that pull in other FreeBSD ports tree dependencies have been updated to match the newer lang/erlang release, and a number of ports that are not being updated in their upstream community, have therefore been marked as broken. The Erlang team is planning to: =E2=80=A2 remove the deprecated OTP20 and OTP21 runtimes in 2021Q4 =E2=80=A2 remove ports directly dependent on erlang- and elixir- language= s, where they are more commonly installed via mix and rebar3 tools, the standard community build tool chain. Additional testing and community contributions are welcome; please reach ou= t on the mailing list, especially if you are able to help testing of specific po= rt updates. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 KDE on FreeBSD Links: KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project aims to package almost all of the software from = the KDE Community for the FreeBSD ports tree. The software includes a full desk= top environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team (kde@) is part of desktop@ and x11@ as well, building the soft= ware stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. Q3 is summer in the northern hemisphere: bicycles were biked and mountains = were hiked and the team was psyched to chase the software we like. And there were plenty of things to chase: =E2=80=A2 Three CMake releases landed, ending up with CMake 3.21.3 and li= bpkg support that once again works with CPack to produce FreeBSD packages. =E2=80=A2 Monthly releases of KDE Frameworks, KDE Plasma, and KDE Gear ke= pt the exp-runs going. kde@ would like to thank Antoine for overseeing our many exp-run requests. =E2=80=A2 The KDE Plasma applications for monitoring the state of the system=E2=80=89=E2=80=94=E2=80=89ksysguard, Plasma system monitor, and = supporting libraries=E2=80=89=E2=80=94=E2=80=89received a number of updates. FreeB= SD support code has been merged upstream. =E2=80=A2 Across all of the Qt and KDE packages, an attempt was made to r= educe how "heavy" the dependencies are. In general this means removing developer-= only dependencies, avoiding the installation of test-code, etc. The underlyi= ng idea is to cut down the size of the installation when specific ports are installed, while preserving the "developer batteries included" characte= r of the meta-ports. =E2=80=A2 A runtime-incompatibility was introduced by MySQL 5.7.34, which= affected KDE=E2=80=99s personal-information-management applications and email. T= his was patched in the Qt ports. =E2=80=A2 The mixer application in KDE Plasma now defaults to using pulse= audio. =E2=80=A2 accountsservice was updated, and then patched with code from Op= enBSD. =E2=80=A2 kdiff3 was updated to 1.9.3, now with upstream patches for some= corner cases originally reported on FreeBSD. =E2=80=A2 kimageannotator and ksnip were updated, for nicer screenshots. =E2=80=A2 kraft, the small-business support application, was updated to v= ersion 0.97. =E2=80=A2 krita had an upstream release to address a performance issue, w= hich then landed in FreeBSD. =E2=80=A2 kstars, the interactive planetarium and sky-watching applicatio= n, was updated to 3.5.5. =E2=80=A2 latte-dock, used as an alternative launcher, updated to 0.10.2. =E2=80=A2 libphonenumber, Google=E2=80=99s library for dealing with all t= he ways phone numbers are represented around the world, received multiple updates. =E2=80=A2 maliit-framework, for on-screen keyboards, as added to the port= s tree. =E2=80=A2 pipewire was kept up-to-date. This is a next-generation video-h= andling framework, and is being increasingly used in Wayland environments for efficient passing of video data between applications. =E2=80=A2 poppler was updated to version 21.09, with significant speed im= provements. =E2=80=A2 sddm was made a little more robust when installed on its own, w= ith xinitrc support. =E2=80=A2 math/eigen2 was removed. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 OpenSearch on FreeBSD Links: OpenSearch website URL: https://opensearch.org/ OpenSearch Community (unofficial) on Discord URL: link:https://discord.gg/ NmtQGAWY Contact: OpenSearch Team OpenSearch is a community-driven, open-source search and analytics suite derived from Apache 2.0 licensed Elasticsearch 7.10.2 & Kibana 7.10.2. It consists of a search engine daemon, OpenSearch, and a visualization and user interface, OpenSearch Dashboards. OpenSearch enables people to easily inges= t, secure, search, aggregate, view, and analyze data. These capabilities are popular for use cases such as application search, log analytics, and more. = With OpenSearch people benefit from having an open-source product they can use, modify, extend, monetize, and resell how they want. After the release of OpenSearch 1.0.0, a FreeBSD OpenSearch team was create= d to coordinate the efforts for porting it to FreeBSD. Because ElasticSearch 7 a= nd Kibana 7 were already in the ports tree, we could rely on these ports to get started quickly (kudos to the elastic@ team) and could focus on the parts t= hat already changed between the previous codebase and the fork. The ports have = been committed to the FreeBSD ports tree as textproc/opensearch and textproc/ opensearch-dashboards, and currently provide the latest 1.0.1 version of OpenSearch. Contributing The ports have been thoroughly tested in our testing environments and on so= me production workloads, but we are actively looking for feedback from users. = Feel free to send us an email to report successes or failures. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Valgrind - Official Support for FreeBSD has Landed Links Valgrind Home Page URL: https://www.valgrind.org/ Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html Contact: Paul Floyd Valgrind is an instrumentation framework for building dynamic analysis tool= s. There are Valgrind tools that can automatically detect many memory manageme= nt and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools. With the release of version 3.18.0 of Valgrind, official FreeBSD support has landed upstream. The two supported architectures are amd64 and i386 (x86). The next step will be to update the FreeBSD port. This will involve switchi= ng =66rom code that was maintained out-of-tree for over 15 years to using the official upstream tarball. As Valgrind is closely tied to operating system details, obtaining official FreeBSD support was the result of significant effort from dozens of develop= ers. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Wine on FreeBSD Links Wine home page Contact: Gerald Pfeifer Contact: Damjan Jovanovic < damjan.jov@gmail.com> Wine allows running Windows programs on FreeBSD. This quarter we focused on the wine-devel port that tracks mainline development, followed half a dozen of version updates, simplified the port, removed three options (SDL, VKD3D, VULKAN) which are unconditionally active now, and fixed a number of portability issues. These changes will make their way into the primary Wine port over the coming weeks. After working on our Wine ports for more than 21 years, maintaining for more than 19 years, time has come to hand over the baton. Luckily Damjan has stepped up and is going to look after wine-devel and associated ports - thanks! Help with the following is still very welcome: =E2=80=A2 WineHQ bug 50257 =E2=80=A2 FreeBSD Bugzilla 257533 =E2=80=A2 Maintain daily (or at least regular) test builds of upstream Wi= ne. This quarter this triggered two dozen fixes in support of FreeBSD upstream, though usually it=E2=80=99s quite less effort. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Ztop Links: Repository Port Contact: Alan Somers ztop is a new utility that displays ZFS datasets' I/O in real time, like to= p, but for ZFS. Unlike the existing zpool iostat, which only displays traffic = at the level of a pool, ztop displays it at the level of individual datasets. Previously, there was no tool that could display this information. The Prometheus Node Exporter can export it into Prometheus, from which it can be viewed after the fact with various other tools, but that requires a large s= tack of software, and isn=E2=80=99t real-time. I started ztop this quarter, and it is now fully functional. However, it has revealed a performance problem within the kernel. In the presence of more t= han a few thousand datasets, the sysctl interface is too slow and ztop becomes sluggish. Future work, if I have the time, will address that problem. Sponsor: Axcient =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Miscellaneous Objects that defy categorization. -CURRENT compilation time analysis Links: Bug 257141 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257141 Discussion on freebsd-current URL: https://lists.freebsd.org/archives/ freebsd-current/2021-September/index.html#msg511 Visual chart of buildworld by stages URL: https://people.freebsd.org/wosch/ build-time/buildworld/ Contact: Wolfram Schneider Re-building FreeBSD from source takes a lot of CPU resources. Depending on = your machine it takes between 20min and several hours. At the end of `make buildworld' we log the real time and which parameters are used for parallel build. E.g. time make -j $(sysctl -n hw.ncpu) buildworld > buildworld.log 2>&1 tail buildworld.log >>> World build completed on Sat Sep 4 20:58:00 UTC 2021 >>> World built in 7235 seconds, ncpu: 3, make -j3 7235.61 real 20527.30 user 915.88 sys The build process runs in several steps. It would be great to know which st= ep takes most of the time, and what are the effects of special build parameter= s. With a small patch in Aug 2021 we get this information now: egrep '>>> stage| real ' buildworld.log >>> stage 1.1: legacy release compatibility shims 0.28 real 0.18 user 0.10 sys >>> stage 1.2: bootstrap tools 165.99 real 472.58 user 11.56 sys >>> stage 2.1: cleaning up the object tree 21.47 real 36.96 user 14.14 sys 15.87 real 29.14 user 11.87 sys >>> stage 2.3: build tools 2.42 real 3.79 user 0.62 sys >>> stage 3: cross tools 9.92 real 18.49 user 1.75 sys >>> stage 3.1: recording build metadata 0.07 real 0.01 user 0.06 sys >>> stage 4.1: building includes 16.62 real 36.46 user 9.48 sys >>> stage 4.2: building libraries 5440.89 real 15724.60 user 482.58 sys >>> stage 4.3: building lib32 shim libraries 615.91 real 1654.77 user 164.58 sys >>> stage 4.4: building everything 937.23 real 2540.06 user 205.47 sys In this example, we spent most of the time in "stage 4.2: building librarie= s", 77% of the CPU time and 75% of the real time. Now running the buildworld wi= th the parameter WITHOUT_TOOLCHAIN=3Dyes we get a 3.3x faster build. Instead o= f 2h it will be done in 36 minutes! time make -j $(sysctl -n hw.ncpu) WITHOUT_TOOLCHAIN=3Dyes buildworld > buil= dworld.log 2>&1 >>> World build completed on Fri Sep 17 12:31:41 UTC 2021 >>> World built in 2207 seconds, ncpu: 3, make -j3 2207.44 real 5710.83 user 676.16 sys egrep '>>> stage| real ' buildworld.log >>> stage 1.1: legacy release compatibility shims 0.35 real 0.20 user 0.16 sys >>> stage 1.2: bootstrap tools 20.47 real 51.98 user 5.12 sys >>> stage 2.1: cleaning up the object tree 20.92 real 34.45 user 13.57 sys 16.33 real 28.59 user 12.33 sys >>> stage 2.3: build tools 2.59 real 3.90 user 0.86 sys >>> stage 3: cross tools 10.46 real 18.62 user 2.35 sys >>> stage 3.1: recording build metadata 0.07 real 0.03 user 0.05 sys 0.08 real 0.03 user 0.05 sys >>> stage 4.1: building includes 15.50 real 33.03 user 9.29 sys >>> stage 4.2: building libraries 750.31 real 1962.43 user 218.60 sys >>> stage 4.3: building lib32 shim libraries 684.05 real 1780.35 user 213.22 sys >>> stage 4.4: building everything 677.87 real 1787.13 user 186.82 sys Using WITHOUT_TOOLCHAIN=3Dyes is fine as long as there are no major LLVM co= mpiler changes. If you dislike this feature or suspect it is causing trouble you can disabl= e it with the variable TIME_ENV=3D"" Next task: get more detailed timing information for the long-running stages (4.2, 4.3, 4.4) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Gitlab 14.3 available Links: Gitlab 14.3 New Features URL: https://about.gitlab.com/releases/2021/09/22/ gitlab-14-3-released/ Contact: Matthias Fechner GitLab is the DevOps Platform. Bring velocity with confidence, security wit= hout sacrifice, and visibility into DevOps success. Version 14.3 now available on FreeBSD. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 helloSystem Links: Documentation URL: https://hellosystem.github.io/ Contact: Simon Peter Contact: #helloSystem on irc.libera.chat, mirrored to #helloSystem:matrix.o= rg on Matrix What is helloSystem? helloSystem is FreeBSD preconfigured as a desktop operating system with a f= ocus on simplicity, elegance, and usability. Its design follows the =E2=80=9CLes= s, but better=E2=80=9D philosophy. Q3 2021 Status =E2=80=A2 Version 0.6.0 of helloSystem has been published including many = contributed features and bugfixes =E2=96=A1 Improved window management with KWin as the window manager =E2=96=A1 Simplified Filer file manager =E2=80=A2 Contributors have started to port the helloSystem desktop envir= onment, helloDesktop, to the FreeBSD Ports and Packages Collection (see changel= og at https://github.com/helloSystem/ISO/releases/tag/r0.6.0 for details) Installable Live ISO images and a full changelog are available at https:// github.com/helloSystem/ISO/releases/tag/r0.6.0 Contributing Help is wanted in a number of areas, especially in the areas of the FreeBSD core OS and kernel, and Qt/C++. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Containers & FreeBSD: Pot, Potluck & Potman Links: Pot on github URL: https://github.com/pizzamig/pot Potluck Repository & Project URL: https://potluck.honeyguide.net/ Potluck on github URL: https://github.com/hny-gd/potluck Potman on github URL: https://github.com/grembo/potman Contact: Luca Pizzamiglio (Pot) Contact: Stephan Lichtenauer (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Noma= d. In the last quarter, a new release 0.13.0 with a number of major new featur= es was made available. Layered images allow a split into a foundation image component that only changes seldom and that e.g. contains the basic jail and packages and a "le= af" image component on top with potentially small additions that might change m= ore frequently, like software built in a CI pipeline. Since it is not the compl= ete image that has to be rebuilt each time, image creation and distribution can= be sped up immensely. Also a copy-out command has been included where the container state that was initialised from within the container can be made persistent and reinjected into additional containers afterwards. Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker= : a repository of Pot flavours and complete container images for usage with Pot= and in many cases Nomad. Here we had a busy quarter. Not only did we commit a number of new images l= ike Nextcloud which can be deployed via Nomad, but the images used to build the foundation of a virtual data center (Nomad, Consul and Vault) themselves ha= ve received major updates. For these images, further improvements for even better security and reliabi= lity will likely be finished in the coming quarter. Also, we are aware that right now the advantages of the container approach = as it is described in Virtual DC Part I/Part II/Part III are not yet obvious a= nd transparent enough and also no longer completely up to date, so we plan to provide additional documentation as soon as we find the time to do so. Potman aims to simplify building Pot images with Vagrant and VirtualBox bas= ed on the Potluck approach, e.g. as part of a DevOps workflow for software development including testing and publishing them to a repository. Here, not too much has happened over the last quarter but the current idea = is to incorporate additional features in the medium to longer term to modulari= se and simplify the image build definitions and then utilise Potman in the Pot= luck library build process. As always, feedback and patches are welcome. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 WireGuard on FreeBSD Stabilizes, Eyes Upstreaming Links WireGuard URL:https://www.wireguard.com/ wireguard-freebsd codebase URL:https://git.zx2c4.com/wireguard-freebsd/ Contact: Jason A. Donenfeld WireGuard is a secure tunneling protocol that lives in the kernel. For the last quarter, the wireguard-freebsd codebase has been quite stable = and complete. For a while, there were rapid-fire releases fixing issues, and a = lot of effort was made to track down every bug report on bugs.freebsd.org, IRC,= the mailing list, or elsewhere. But by now, the reports have dried up, and most= ly users come to IRC with questions on usage and integration, the usual types = of things associated with a stabler project. We also have automated CI now for each commit, compiling and running a small smoke test on wireguard-freebsd= =E2=80=99s supported releases=E2=80=89=E2=80=94=E2=80=8912.1, 12.2, and 13.0. At some = point, hopefully that small smoke test will expand to include the larger battery of tests from Linux. The wireguard-freebsd repository has been geared around being an out-of-tree kmod, which is distributed in ports. But it is also organized to be eventua= lly upstreamed. To that end, the repository maintains two files: compat.h and support.h. compat.h contains polyfills of code that exists in FreeBSD=E2=80= =99s main branch but does not exist in various older releases, with ifdefs for each of the various releases we support. On the other hand, support.h contains code that is not yet in FreeBSD=E2=80=99s main branch. The goal is to eventually= move all the code from support.h into compat.h, at which point, the repository will = be ready for upstreaming. As of writing, there=E2=80=99s basically only one re= al function left=E2=80=89=E2=80=94=E2=80=89sogetsockaddr=E2=80=89=E2=80=94=E2=80=89and = then two convenience macros that need to be sent upstream for consideration by ConcurrencyKit. A significant aspect that isn=E2=80=99t in support.h, though, is the crypto= graphic primitives that the code uses. The files crypto.c and crypto.h contain bori= ng C "reference implementations" of ChaCha20Poly1305, XChaCha20Poly1305, Blake2s, and X25519 (which is formally verified via MIT=E2=80=99s fiat-crypto projec= t). These four algorithms are used by the handshake path on very small inputs for WireGuard=E2=80=99s key exchange, and will hopefully be making their way to= sys/crypto/ in the FreeBSD tree as just ordinary functions. On the flip side, the datap= ath uses an entry point of ChaCha20Poly1305 that works on mbufs (which might be rather large) and is performance critical. To that end, jhb@ has been impro= ving OCF for WireGuard=E2=80=99s particulars. The next step will then be moving = our current calls from chacha20poly1305_{en,de}crypt_mbuf in wg_noise.c to instead call= out to OCF, submitting crypto_buffer`s of type `CRYPTO_BUF_MBUF. This will automatically benefit from Andy Polyakov=E2=80=99s optimized ChaPoly implem= entations that OCF has long since imported from OpenSSL. When we make the move to OCF, it=E2=80=99s likely that the wireguard-freebs= d repo as-is will become "wireguard-freebsd-compat", which will be explicitly aimed at backports to earlier FreeBSD releases for ports, while a new wireguard-free= bsd repository will be a whole FreeBSD tree, where we can work directly on integration patches for upstream. That repository will also have an imported version of the wg(8) utility from wireguard-tools, which I=E2=80=99ll be re= licensing as MIT. I=E2=80=99m quite excited for the upcoming quarter and seeing how much of wireguard-freebsd we=E2=80=99re able to land upstream. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 --66dsezfsnajsewcm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmGSjzBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87rCJQf+L85vcCZetfg8jx9wmIkBX8z1Sy4P0k0JYAlDU64bdSorQfv9iehSapMd jGKLOhD5oQjFht/2u4uM9bBYMDBe53JSSo9NUSdcjPDsHcwLbZPKbxNlSZ6GOX6U UmAGftRiXLTIX2DNTeNQmtUzd/Os66/13RTaUlkAg2L9zHxX6ImXWk27EWpsR6Nn oY4gXT4/px750uBdYPv1HxGxLpHIMy4E46T7UOcrc3UmbhN+lAf6fj+yNIx04ur5 IYgPv8vAFffaTjvF/YzPbPj9L5UJhCzTQed8IE8Xbsl4r+NKKmFRCk0Tb+IIUiWA vCnZ8iOJWV9vWTOZgxMHWD/43oxwyQ== =n3Dy -----END PGP SIGNATURE----- --66dsezfsnajsewcm-- From nobody Tue Nov 16 06:35:34 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B0431834166 for ; Tue, 16 Nov 2021 06:35:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4Htbsq5GZGz3mkw for ; Tue, 16 Nov 2021 06:35:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=ZGqz281SHNdYovAVfvytKp8VPvVqsmvSJRH/rOQX9vM=; b=sPaw255v1Hd0vJRVXUR3Ekj//IRNfxK0oNAGDdAzEWoUvm5s3N93svy3m3WCGd89Ghr/+8XR4wEwtm8IwoLrxtZnkkuZH+IU8ksg5anIUWxotkbH2+vKmZlvsOz8TcT9Qjm9uD+ItLs0nbVEJwvWTWSkaEajHCLmvgGFS/2Lt8jH9rxQszokDY1d60/TJSAqlpqJ8RClRjg7Tdp/HJJ04CkvKINGMOscvq9kfAPqYpojLwJEGXQuSgNXIqqF120PiGVR8tYAZ9gMfI/pXB3qxOHRHXZPt8LWeiBFHS+V1Wo4rPd8UDcyVDfVaI+pxpcTAekhcBaWmsRPLhmMFQH3ng==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1mms46-0004s8-Ae for hackers@freebsd.org; Tue, 16 Nov 2021 08:35:34 +0200 From: Daniel Braniss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: 13.0 pxeboot stopped working Message-Id: <1D9485E3-3E8B-4044-B829-A5983E8B1651@cs.huji.ac.il> Date: Tue, 16 Nov 2021 08:35:34 +0200 To: "freebsd-hackers@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Htbsq5GZGz3mkw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=sPaw255v; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-1.25 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.95)[-0.949]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N hi, so far I have tried 3 different hosts, and they all fail: 0ne reports something like NBP too big another crashes the BTX a third just goes south/hangs. will continue testing, but insights are more than welcome, danny From nobody Tue Nov 16 12:11:19 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C6F9F1851935 for ; Tue, 16 Nov 2021 12:11:35 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (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 4HtlKL23M8z3N3K for ; Tue, 16 Nov 2021 12:11:33 +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 5DA9A8D4A212; Tue, 16 Nov 2021 12:11:22 +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 58675E707B4; Tue, 16 Nov 2021 12:11:21 +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 ODkaG59_p4ov; Tue, 16 Nov 2021 12:11:20 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:b199:16fd:c815:6f2f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 61982E707B0; Tue, 16 Nov 2021 12:11:20 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Daniel Braniss" Cc: freebsd- Subject: Re: 13.0 pxeboot stopped working Date: Tue, 16 Nov 2021 12:11:19 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: In-Reply-To: <1D9485E3-3E8B-4044-B829-A5983E8B1651@cs.huji.ac.il> References: <1D9485E3-3E8B-4044-B829-A5983E8B1651@cs.huji.ac.il> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Rspamd-Queue-Id: 4HtlKL23M8z3N3K 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 16 Nov 2021, at 6:35, Daniel Braniss wrote: > hi, > so far I have tried 3 different hosts, and they all fail: > 0ne reports something like NBP too big > another crashes the BTX > a third just goes south/hangs. > > will continue testing, but insights are more than welcome, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257018 Compile with 4th instead of lua or take an older binary for now (from FreeBSD 12 for example). /bz From nobody Tue Nov 16 13:04:29 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 97E54189C7E8 for ; Tue, 16 Nov 2021 13:04:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4HtmVS2wHYz4Sdn for ; Tue, 16 Nov 2021 13:04:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=U2t+zNLTnniDMiCuFTlnLHMtutnQk2c9yLOBS0h0PKs=; b=rjLNeXVjUdNmIa9YhSPOSHBsPiL6H6uVwPeJfQXS/WVXnFKsmoRomOr9M2doNI4ZJSLyuD8SUV1cG7FoeJSpXodB0WDebp+QxFUyvoxClYhlCdWEj9KTEHawqX/ijXYBy86jsWJglI5sEGI1I0NYnskqJF0sarLFuImUDTza65Ep48XtV/PMclH81ShUt9rL3HB9cEcSojWujjw7IBHQCa3w93pcMWzNXqKPo1/qpZMd/4zS9glfPx27MEgEvnrHFZHCsfVDAx3yQQXhMpDUUi3YKIHGvxqZ3+LipJO/g2hO6PMImS3oMJJ349ZX6pyDWNtVowbVwVKoQJpUmjHjPw==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1mmy8U-0004kP-3K; Tue, 16 Nov 2021 15:04:30 +0200 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: 13.0 pxeboot stopped working From: Daniel Braniss In-Reply-To: Date: Tue, 16 Nov 2021 15:04:29 +0200 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: <353BEFCE-7123-4B18-BAD7-2B182DA8A8F7@cs.huji.ac.il> References: <1D9485E3-3E8B-4044-B829-A5983E8B1651@cs.huji.ac.il> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Rspamd-Queue-Id: 4HtmVS2wHYz4Sdn 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 16 Nov 2021, at 14:11, Bjoern A. Zeeb = wrote: >=20 > On 16 Nov 2021, at 6:35, Daniel Braniss wrote: >=20 >> hi, >> so far I have tried 3 different hosts, and they all fail: >> 0ne reports something like NBP too big >> another crashes the BTX >> a third just goes south/hangs. >>=20 >> will continue testing, but insights are more than welcome, >=20 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257018 strange, google didn=E2=80=99t find this. >=20 >=20 > Compile with 4th instead of lua or take an older binary for now (from = FreeBSD 12 for example). i have older working versions, but with a new arrived server it is = causing some problems, so i tried=20 the latest pxeboot, and that=E2=80=99s when I found out that it=E2=80=99s = also failing on older hardware. how can I compile with 4th instead of lua? and another question, how can I pxe boot using uefi bios? thanks,=20 danny >=20 > /bz From nobody Thu Nov 18 07:29:32 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7D8681892712 for ; Thu, 18 Nov 2021 07:29:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4Hvrz92Xpwz4WP0 for ; Thu, 18 Nov 2021 07:29:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=wuB/6hPwgm9twmo48es3FdavwFHZ+DBVGEYpq2ptfCM=; b=v+bLeJqOup04tYnhh3uN/BwRWZM6ptVEh5jMi3Rs8C0Iqx4gl7uDO9O5xjxx6w58cLC/JmqwiEHu8UGIM0J473PwKmRhoiIrHqzgDvT4nqDmm6pIAzbgkUrKs8VBc9OkfUIE+yyxAjqiMRtZfGm5UOjwCs7YKgURNdMV/7D0Ce5kn5VW6m0Wxm6DxBioPVkrRhfQ+JXVwiz/h2njcxkTrbPrPFZgTT0qU6WvGNmIDiSHzaryY1GtVlHRD4W/i+zZoxSHVu1s7/jpVvYxLt3uf6fLogt/ftANi9b6uDTTrLkCoZQ/lhw+NHVwX54kuGCdag6FN/qOI1J5S4Qub16ceA==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1mnbrQ-000Im3-Fm; Thu, 18 Nov 2021 09:29:32 +0200 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: 13.0 pxeboot stopped working From: Daniel Braniss In-Reply-To: Date: Thu, 18 Nov 2021 09:29:32 +0200 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D9485E3-3E8B-4044-B829-A5983E8B1651@cs.huji.ac.il> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hvrz92Xpwz4WP0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=v+bLeJqO; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N using the loader.efi i get the same error: PXE-E79: NBP is too big to fit in free base memory > On 16 Nov 2021, at 14:11, Bjoern A. Zeeb = wrote: >=20 > On 16 Nov 2021, at 6:35, Daniel Braniss wrote: >=20 >> hi, >> so far I have tried 3 different hosts, and they all fail: >> 0ne reports something like NBP too big >> another crashes the BTX >> a third just goes south/hangs. >>=20 >> will continue testing, but insights are more than welcome, >=20 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257018 >=20 >=20 > Compile with 4th instead of lua or take an older binary for now (from = FreeBSD 12 for example). >=20 > /bz >=20 From nobody Thu Nov 18 08:07:54 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 961A01836A62 for ; Thu, 18 Nov 2021 08:07:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4HvsqH6qF8z4k5K for ; Thu, 18 Nov 2021 08:07:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=3nlZ8Kxt2xtczma8WH2UfG0bCzDDW7Gw1W3i5silexI=; b=fpcN/hPjORmN3sO6sFK0lDEBvcbBiKTEMbeoQNtz6zFPK4bgbnJDoygWl+AzBOAaBFztdtsT5skXLtg/PxjcbUd3bziNNfNVy6lkm3w8/ki9WGK3xQQAwXEKpP0zk+iZn0h2W9exCU6SujmsKXBK0Crqsv8PvXRMA0mS+OBPelVuPwG2HLU/3RzmZxGTRFB3NEjMbk3ldK0nQXEfAM+EawIx54ly7jNtM1SbQI+/6PpY7LmUp2tz8VYa3x7k1iIgbFN8Y1tkdpe41jUg80PfnEoutQvb/Z//Nzb3NVV3X3gOjASCFqbGmzOKYspMPH8bp9SXpj8sfJPFjzOCJ6rXIg==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1mncSY-000L0p-A0; Thu, 18 Nov 2021 10:07:54 +0200 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: 13.0 pxeboot stopped working From: Daniel Braniss In-Reply-To: Date: Thu, 18 Nov 2021 10:07:54 +0200 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: <8BB3887D-7A13-49A2-BA41-B55676CB2381@cs.huji.ac.il> References: <1D9485E3-3E8B-4044-B829-A5983E8B1651@cs.huji.ac.il> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HvsqH6qF8z4k5K X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b="fpcN/hPj"; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.97)[-0.967]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N solved, set bios to uefi and now it works! thanks, danny > On 16 Nov 2021, at 14:11, Bjoern A. Zeeb = wrote: >=20 > On 16 Nov 2021, at 6:35, Daniel Braniss wrote: >=20 >> hi, >> so far I have tried 3 different hosts, and they all fail: >> 0ne reports something like NBP too big >> another crashes the BTX >> a third just goes south/hangs. >>=20 >> will continue testing, but insights are more than welcome, >=20 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257018 >=20 >=20 > Compile with 4th instead of lua or take an older binary for now (from = FreeBSD 12 for example). >=20 > /bz >=20 From nobody Mon Nov 22 15:26:34 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 182C8188C622 for ; Mon, 22 Nov 2021 15:27:08 +0000 (UTC) (envelope-from carpeddiem@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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HyWNC1Zfhz4p1R; Mon, 22 Nov 2021 15:27:07 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-lf1-f42.google.com with SMTP id k37so82750819lfv.3; Mon, 22 Nov 2021 07:27:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JM1vVQx6u1nrTF8N8gLce8FkOhqaGyoKvAE1u0iPZc4=; b=h00rzpavxiwzFY6nsJvwSFMiolMnzlLXC14h5019zHD0LB0yKvh8F3NOzbFDl+Htws SkGPehMZeKar88zbS5gDQaJrPQI+sP8VfbobTuZS98d+KUeK1S1ylzuEvQS+IiN8brer RJZE1+RmFrzTWoS9PdTzPP6pJbhC95ORVCnIEs5ibxnEdzgSxWi2Nhz1vbz4ibWDJH85 sDdOt9kD/xEEC7ZF5Waff1Lm4DCktK13y08xI7npkR4/utNTath/RTVWs6+NPR75W8iH jmJliYLyZhVKLVssljX6p6R7x5Uu+SG2TQ+fkb13KqAyaSj8sPEfppblhptEjNPE+jf7 iEIw== X-Gm-Message-State: AOAM531lZNPqVtypZ37NRfkuJp89pvICtBnGmDZ7AefDLIccoJAzz/CO F8AgrMYHP8ZVy9tkIZt5lKUycpeAjNNQinCGcCQxBadlqZw= X-Google-Smtp-Source: ABdhPJzgCgYCC5R4l+b7opGyBOFZthhy8rJ0lKk3Er6MUr0NpQUSA59ureKilf8ikCpnfGLdFE+4i37WX91qQPPvhas= X-Received: by 2002:a05:651c:a12:: with SMTP id k18mr54979026ljq.251.1637594819890; Mon, 22 Nov 2021 07:26:59 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> In-Reply-To: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> From: Ed Maste Date: Mon, 22 Nov 2021 10:26:34 -0500 Message-ID: Subject: Re: Looking for rationale for the minidump format To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: FreeBSD Hackers , John Baldwin , Peter Wemm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4HyWNC1Zfhz4p1R 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.167.42 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.03 / 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)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(0.03)[0.033]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.42:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.42:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com] X-ThisMailContainsUnwantedMimeParts: N On Sun, 21 Nov 2021 at 09:42, Micha=C5=82 G=C3=B3rny wrote: > > Hi, everyone. > > As part of the work contracted by the FreeBSD Foundation, I'm working > on adding explicit minidump support to LLDB. When discussing > the options with upstream, I've been asked why FreeBSD created their own > minidump format. > > I did a bit of digging but TBH all the rationale I could get was to > create partial memory dumps. However, unless I'm mistaken the ELF > format is perfectly capable of that -- e.g. via creating an explicit > segment for every continuous active region. ELF can, indeed. One of my previous co-op students wrote a little tool to convert a minidump to ELF, see https://reviews.freebsd.org/D19253. That's what it does - creates a segment for each contiguous region. If we ended up going this way we could integrate D19253 into savecore. One issue is that originally ELF supported only a 16-bit segment count, the extension to support greater came later on. I think minidumps could also store userland pages, but without any tooling to access them it's not that useful IMO. Oh, I just found an old (2014!) thread where I discussed some of this with Greg Clayton: On Thu, 22 May 2014 at 13:43, Ed Maste wrote: > > Thanks for the insight Greg - a few comments: > > On 22 May 2014 12:39, Greg Clayton wrote: > > Core file kernel debugging: > > - You shouldn't have to do too much to the current ProcessELFCore excep= t help it to locate hint address for the list of shared libraries and the m= ain kernel file in memory. This is done in: > > Note that kernel core files on FreeBSD aren't (currently) ELF files, > and may be a different format on different architectures, so there's > some extra work here. Dumps are written in a contiguous blob > (typically to swap) at the time of a crash, and then copied to the > filesystem after the next reboot. > > The dump function for amd64/x86_64 is minidumpsys in > minidump_machdep.c[1], and consists of: > > 1. Dump header (stripped during copy to filesystem) > 2. Minidump header > 3. Copy of kernel message buffer > 4. Bitmap of pages present in the dump > 5. Page directory pages > 6. Pages themselves > 7. Trailer > > All of this is abstracted by the libkvm library, which provide > kvm_read and kvm_write functions which a VA address parameter. I > think this is the right way to introduce support for FreeBSD kernel > cores at first, as I'll explain below. > > > Live kernel debugging: > > - You will make a new process subclass like you were saying unless the = GDB remote protocol is used to talk to the kernel? > > We currently have separate ways of interacting with the kernel for > remote and local debugging. For remote debugging the kernel has a > built-in GDB protocol stub which is available over a serial or > firewire interface, and this should mostly work with the existing LLDB > support. We do local debugging (examining threads, global objects, > etc.) via /dev/mem, abstracted by the same kvm_read and kvm_write > functions in libkvm. Since local FreeBSD debugging will be done on a > FreeBSD host (by definition), using libkvm makes sense. And since > we'll have that, using it also for cores makes sense to get started. > > Of course we'll want to allow debugging a FreeBSD kernel core on OS X > or Linux too. I think the way forward for us there is to create a > utility in the FreeBSD base system that converts the minidump format > to ELF, rather than teaching LLDB about our core formats in a > cross-platform way. This utility could be built-in to savecore(8), > the tool which reads the dump out of a raw partition and writes to the > filesystem. There is also ongoing discussion about bringing a KDP > target to the kernel for live debugging. > > > Extra credit: > > - Get threads that are context switched in memory to show up. In the Ma= cOSX kernel debugger we have the notion of 1 core we can talk to through th= e KDP interface which is the code that runs the debugger. > > We have code[2] for this already in kgdb, our GDB 6.1 port with kernel > support, and we should be able to re-use most of it as is. The kernel > threads just appear as regular threads in kgdb: > > (kgdb) info threads > 827 Thread 102126 (PID=3D28738: kgdb) sched_switch > (td=3D0xfffffe021882b000, newtd=3D0xfffffe0008392920, flags=3D optimized out>) > at /tank/emaste/src/git-stable-9/sys/kern/sched_ule.c:1904 > 826 Thread 102334 (PID=3D28737: sudo) sched_switch > (td=3D0xfffffe02d2669920, newtd=3D0xfffffe0008392920, flags=3D optimized out>) > at /tank/emaste/src/git-stable-9/sys/kern/sched_ule.c:1904 > 825 Thread 104699 (PID=3D28715: more) sched_switch > (td=3D0xfffffe049cec7920, newtd=3D0xfffffe0008390000, flags=3D optimized out>) > at /tank/emaste/src/git-stable-9/sys/kern/sched_ule.c:1904 > ... > > -Ed > > [1] http://svnweb.freebsd.org/base/head/sys/amd64/amd64/minidump_machdep.= c?annotate=3D257216#l219 > [2] http://svnweb.freebsd.org/base/head/gnu/usr.bin/gdb/kgdb/kthr.c?annot= ate=3D246893 From nobody Mon Nov 22 17:04:40 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BD74C189B012 for ; Mon, 22 Nov 2021 17:04:45 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 4HyYXs4RcCz4SRH for ; Mon, 22 Nov 2021 17:04:45 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: by mail-lf1-x130.google.com with SMTP id n12so83916994lfe.1 for ; Mon, 22 Nov 2021 09:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moritz-systems.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=4raGIPJi99jL7v7LGb37pxgYK7vXlGBCH19HUoESHzM=; b=YrM6dthwFitIMPZhc5UZAFuWdEu9Wld0u0WyTMcj8l+LUJ5SHhdAaCHHmd0XwQmQ2n OFhQhhmUY8I3LjAQ/FT1UE35oYWfrODfWrWo5qxwxsu0SagZcRvQiWnXH7+8+QRkMxHo jTGuR9ySVmHRXKRWpeZJuPuezL63sJeM0tSLoD6b3wy+rLz0l8GKcNp59mlMPM3B22tP a0LuzwbAnYlAxPkAp6maxbxMHJ9ecdOm9U7vdd9MnfUl6Spq2XyyUKc0YfzcTN085X4A nV5Q2QwgbqOLFaFr++FBYK3QbTqCdYjbm3PiAXdAD4A33mSjZ7G7mPT1WWQTqsiGHXZ7 rdBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=4raGIPJi99jL7v7LGb37pxgYK7vXlGBCH19HUoESHzM=; b=1lmeLeF3W5aW6XvHm1yUeu3+K8xBb25oEBhAFMSRtGUFt5sFg10ayjKIpz2IEU/x3P 6DsPjxDIxumBiqrcyoEpB59YlOdLqvPOjZS1L8A6x23re3W2REPlhmbW34I7WNyQyA0a uckk/WqD96Ak+nXhHnnORHs0wUvk84QRkdkW4EcY1xoT2gY4gcXPGQ+486qtwtZqTN0L 6bj1vqZeKVH3cGRmJSdYGMOObyFct1NOIJtirWz/c1g0tTOOyC3dsCQa0EyjV03P13TD yw0bfSy5E/sQ+NVkgSGkrG7o147+xRBJaCZetaCK4okkA94w/DsyaN3Lq+ODEvIyq0/Q tslA== X-Gm-Message-State: AOAM5307PbN96vbWOBZ9qn4A5SqRjIcxA593QwOCt94zNSYspe+xtnlD R7Iqz/EZqJA79UbiMLiFiLRvvA== X-Google-Smtp-Source: ABdhPJw3CULPUH7OMl5Ua8EkMhtuNCMI857+1u/Lv9UVmX4HGBAhHh1hqVdaPlun/VhX927uIroIzA== X-Received: by 2002:a05:6512:39ca:: with SMTP id k10mr60538968lfu.426.1637600682565; Mon, 22 Nov 2021 09:04:42 -0800 (PST) Received: from [192.168.1.12] (c139-65.icpnet.pl. [85.221.139.65]) by smtp.gmail.com with ESMTPSA id k15sm968103ljh.102.2021.11.22.09.04.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Nov 2021 09:04:42 -0800 (PST) Message-ID: <1b140e6f5e3a44fe875820fd0a5a2d621ae23ae5.camel@moritz.systems> Subject: Re: Looking for rationale for the minidump format From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: Ed Maste Cc: FreeBSD Hackers , John Baldwin , Peter Wemm Date: Mon, 22 Nov 2021 18:04:40 +0100 In-Reply-To: References: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HyYXs4RcCz4SRH 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, 2021-11-22 at 10:26 -0500, Ed Maste wrote: > On Sun, 21 Nov 2021 at 09:42, Michał Górny wrote: > > > > Hi, everyone. > > > > As part of the work contracted by the FreeBSD Foundation, I'm working > > on adding explicit minidump support to LLDB. When discussing > > the options with upstream, I've been asked why FreeBSD created their own > > minidump format. > > > > I did a bit of digging but TBH all the rationale I could get was to > > create partial memory dumps. However, unless I'm mistaken the ELF > > format is perfectly capable of that -- e.g. via creating an explicit > > segment for every continuous active region. > > ELF can, indeed. One of my previous co-op students wrote a little tool > to convert a minidump to ELF, see https://reviews.freebsd.org/D19253. > That's what it does - creates a segment for each contiguous region. If > we ended up going this way we could integrate D19253 into savecore. Thank you for your reply. I think this approach makes sense. Do you want us to pursue updating D19253 to build again (it's failing due to libkvm API changes and -Werror) and moving it into savecore instead of adding FreeBSD minidump support in LLDB? -- Best regards, Michał Górny From nobody Mon Nov 22 17:47:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 66ACF188A5E2 for ; Mon, 22 Nov 2021 17:47:44 +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 4HyZVS2WS4z4l4G; Mon, 22 Nov 2021 17:47:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id B9A53973B; Mon, 22 Nov 2021 17:47:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 22 Nov 2021 09:47:42 -0800 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= , freebsd-hackers@FreeBSD.org Cc: emaste@FreeBSD.org, peter@FreeBSD.org References: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> From: John Baldwin Subject: Re: Looking for rationale for the minidump format In-Reply-To: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 11/21/21 6:42 AM, Michał Górny wrote: > Hi, everyone. > > As part of the work contracted by the FreeBSD Foundation, I'm working > on adding explicit minidump support to LLDB. When discussing > the options with upstream, I've been asked why FreeBSD created their own > minidump format. > > I did a bit of digging but TBH all the rationale I could get was to > create partial memory dumps. However, unless I'm mistaken the ELF > format is perfectly capable of that -- e.g. via creating an explicit > segment for every continuous active region. > > Does anyone happen to know what the original rationale for creating > a custom file format was, or know where to find one? Thanks in advance. The direct map aliases pages mapped via kmem. You'd be double dumping all the data mapped into kmem, once for the direct map and once for the non-direct mappings. You can think of minidumps as being a dump of physical memory, whereas an ELF core for a virtually-mapped kernel wants to dump virtual memory, and there is the disconnect. There are somewhat similar issues with talking to bare metal stubs that insist on always using physical addresses (e.g. openocd talking to RISC-V FPGA soft cores). For that I have theorized (but not implemented) adding a new qXfer (or the like) for physical memory and a way to negotiate that a target only supports physical addresses as part of qSupported and then having logic in the arch-dependent code (riscv-tdep.c in gdb, not sure what the equivalent layer would be in lldb) to handle translation of virtual addresses to physical before reading physical memory (e.g. on RISC-V it would be sufficient to expose the $satp register from the remote stub). You could perhaps imagine something similar where you had an ELF core with physical memory for PT_LOAD instead of virtual and a way to hint that so that the debugger would handle all the virtual -> PA translation, but you'd still need some home-grown notes for some of the other metadata we pass along (like the message buffer, etc.). Also, changing the format doesn't help with reading existing crash dumps. You could also perhaps depend on ELF register notes for thread state vs enumerating threads (which might be nice), but you'd still have to duplicate all of that logic to handle talking to remote baremetal stubs like QEMU / bhyve where the threads exposed via the remote protocol are vCPUs, not kernel threads, so that doesn't really save you any work in the debugger in the end. -- John Baldwin From nobody Tue Nov 23 09:11:03 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6087D1891954 for ; Tue, 23 Nov 2021 09:11:06 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 4Hyyzt200Bz4vcH for ; Tue, 23 Nov 2021 09:11:06 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: by mail-lf1-x133.google.com with SMTP id b40so89488503lfv.10 for ; Tue, 23 Nov 2021 01:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moritz-systems.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=2vQoPz6+uhjR4ljrW1qRvHTdFxLJ1a/GL9HNqkhbtQU=; b=CIl2FZs95CCEc82+cRAkkp/T5Fr7azcBBJ/G+oy0NDPUKfqjchEZ1ccco/of5cFpTm PJgzlwC09P807dZmc0tz2l8r7EpeHyYC9b0NZmN6pBctdj1nNHla55QmowaBkhNXAo0k cQLaFy+e0miuxrrjd/Kdo6jPojEZIEz/BwWHLrTnRt0J6E9ecbXQXGG5eRqC9I+RKbP9 RFeQKLWVNBySiJuP93ARyQQa9Bkmszud6gwVhAXrmarxjZ1kZ0tHB464vbrTxVABM8uZ ao6uKK8IYtbLUdSjORCocifhp5xvbyQV09TvBVu8GCAOt/u219GEmtwNvNdhJRfjOlb3 I/IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=2vQoPz6+uhjR4ljrW1qRvHTdFxLJ1a/GL9HNqkhbtQU=; b=gJiUtab4xsbVSDqlQIDlj625fGllybFCESjPaSdIvCRUMG7ia5vaIOHdXoA9wHnFhR RiM1/Ib+Ng8AvkdcYZN1yypnSZ5eU4H9cixRhVh0Cwl0lvKwCRuQF4jxxNhTGgeOL9uA +rpV5qaTsbCFYPBH5vAKdr64ZKIJ9AdedGOUb/3W2ztv31r0REiwO/fYdYz9B/lu0QR0 dNHUcvkNDWWKL/mF5Qo10caIZWa2N5C8Zrhjf5Cg1pGkrq5JDgh8yHYlCSAGzSqPesWe We1aXqWQqQyKCE+pxfLPBswrB+30MfIfn4LS4QrEOi29tbxwTwfGJJ1f59sr7obHAUGU 1mbg== X-Gm-Message-State: AOAM532eVrTbOCxbv5PIpIevvL75rTVjfr6RXIp9cwl+2bXepoiN1M6U rigHOiqQXKPXg3V6GAi6EDe094xdkyRDrw== X-Google-Smtp-Source: ABdhPJwL8762OWG3/vJRwNzsFVUEfEIfzelsFXMJs1amMlTUbR3oSJNl9BCs6ANSz2TMqhHzx1FfEw== X-Received: by 2002:a05:6512:70a:: with SMTP id b10mr3228132lfs.32.1637658664716; Tue, 23 Nov 2021 01:11:04 -0800 (PST) Received: from [192.168.1.12] (c139-65.icpnet.pl. [85.221.139.65]) by smtp.gmail.com with ESMTPSA id 27sm1226432lft.299.2021.11.23.01.11.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Nov 2021 01:11:04 -0800 (PST) Message-ID: <4b1b49da6c83165fbad3c4804c1394473e1b67da.camel@moritz.systems> Subject: Re: Looking for rationale for the minidump format From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: John Baldwin , freebsd-hackers@FreeBSD.org Cc: emaste@FreeBSD.org, peter@FreeBSD.org Date: Tue, 23 Nov 2021 10:11:03 +0100 In-Reply-To: References: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Hyyzt200Bz4vcH 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, 2021-11-22 at 09:47 -0800, John Baldwin wrote: > On 11/21/21 6:42 AM, Michał Górny wrote: > > Hi, everyone. > > > > As part of the work contracted by the FreeBSD Foundation, I'm working > > on adding explicit minidump support to LLDB. When discussing > > the options with upstream, I've been asked why FreeBSD created their own > > minidump format. > > > > I did a bit of digging but TBH all the rationale I could get was to > > create partial memory dumps. However, unless I'm mistaken the ELF > > format is perfectly capable of that -- e.g. via creating an explicit > > segment for every continuous active region. > > > > Does anyone happen to know what the original rationale for creating > > a custom file format was, or know where to find one? Thanks in advance. > > The direct map aliases pages mapped via kmem. You'd be double dumping > all the data mapped into kmem, once for the direct map and once for the > non-direct mappings. > > You can think of minidumps as being a dump of physical memory, whereas > an ELF core for a virtually-mapped kernel wants to dump virtual memory, > and there is the disconnect. > > [...] > > You could perhaps imagine something similar where you had an ELF core > with physical memory for PT_LOAD instead of virtual and a way to hint that > so that the debugger would handle all the virtual -> PA translation, but > you'd still need some home-grown notes for some of the other metadata we > pass along (like the message buffer, etc.). Also, changing the format > doesn't help with reading existing crash dumps. > Thank you for your reply. If I understand correctly, you're comparing minidump with a "proper" (i.e. virtual memory-based) ELF core. However, the "full memory dump" ELF core also uses physical memory map model, is that correct? Does that mean that using a different core format makes it clear that it's a physical memory dump and not virtual? That said, please correct me if I'm mistaken but I think we should be able to create a "virtual memory mapped" ELF core without too much duplication. We could creating multiple segments with different p_vaddr values but the same file p_offset, correct (and maybe p_paddr)? I'm not advocating for changing the format, just trying to improve my knowledge. -- Best regards, Michał Górny From nobody Tue Nov 23 16:31:02 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 14EA5188E709 for ; Tue, 23 Nov 2021 16:31:04 +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 4Hz8lW6BhNz3lpn; Tue, 23 Nov 2021 16:31:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4A01A23E3E; Tue, 23 Nov 2021 16:31:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <19c441de-69ee-7c49-60ad-60aa154efd82@FreeBSD.org> Date: Tue, 23 Nov 2021 08:31:02 -0800 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Looking for rationale for the minidump format Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= , freebsd-hackers@FreeBSD.org Cc: emaste@FreeBSD.org, peter@FreeBSD.org References: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> <4b1b49da6c83165fbad3c4804c1394473e1b67da.camel@moritz.systems> From: John Baldwin In-Reply-To: <4b1b49da6c83165fbad3c4804c1394473e1b67da.camel@moritz.systems> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637685063; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3xpa1GFb5A6dB121XT62zYX9uCpAuoUNcegsSZtxTPA=; b=tpVisKcOtaEoYjLp3A7keV+0qlmboxqZ+CpBYZ7b0+xNP7clMgPXtdAqP0F2zqAr8Qe+1s iHloGOpg3p4sKIo6GZ+uHyVfBH+mtEm3HQpCx2r5C1oXA47UjKi+lnJg2AddaC8NsarNJn y1w0PBlArgnw+XlCIhBTTj4eUD+b5LMClfHfAYBqCiwOumKpw+d6NAv5aLGe/NMEUp7vSo 5e/z7Mw5AdA+SO8shXOJjDP2jpHaZIfwASqYb0bHw+Rffj8jhA7oL6RDcYIaCNV58NGGO4 Ey3bnVzqTpZAvxKkadClZ5TrGh3WjsSfgwI4uoUo/EAsrPxGggFh7onK4Dy8Gg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637685063; a=rsa-sha256; cv=none; b=iuixROgm2uXnc15pCA4wxNfSnKqmjzSC45FSVqQvur0sRSRjZmPQwqXRqH9wbgBwZ1afDs EKdkaL1Ut/Mo6nABiS2RqSWr4tJXfZj/4YQ0kWgWeUkEhJQdBKQ/OenHY+Q2m3K8DWusGY z9wa8gkON61K9h8e9XOCox9cDOxDH4PUg7FmSUZy64u09hCBvp04pWZKHBQpktCCm7ESec ZGxJkKvOa9ggTKNdCe80u6CzVEdS8F2/gg566i/986XhAqbycCv+fg3ZYU21Jo4Vnnu7l9 P/ID/f9+347YiCpHbWhvWM9iup5/fF35A+HSNgBxjJoLMbGDgZP7pVdXMzCm1Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/23/21 1:11 AM, Michał Górny wrote: > On Mon, 2021-11-22 at 09:47 -0800, John Baldwin wrote: >> On 11/21/21 6:42 AM, Michał Górny wrote: >>> Hi, everyone. >>> >>> As part of the work contracted by the FreeBSD Foundation, I'm working >>> on adding explicit minidump support to LLDB. When discussing >>> the options with upstream, I've been asked why FreeBSD created their own >>> minidump format. >>> >>> I did a bit of digging but TBH all the rationale I could get was to >>> create partial memory dumps. However, unless I'm mistaken the ELF >>> format is perfectly capable of that -- e.g. via creating an explicit >>> segment for every continuous active region. >>> >>> Does anyone happen to know what the original rationale for creating >>> a custom file format was, or know where to find one? Thanks in advance. >> >> The direct map aliases pages mapped via kmem. You'd be double dumping >> all the data mapped into kmem, once for the direct map and once for the >> non-direct mappings. >> >> You can think of minidumps as being a dump of physical memory, whereas >> an ELF core for a virtually-mapped kernel wants to dump virtual memory, >> and there is the disconnect. >> >> [...] >> >> You could perhaps imagine something similar where you had an ELF core >> with physical memory for PT_LOAD instead of virtual and a way to hint that >> so that the debugger would handle all the virtual -> PA translation, but >> you'd still need some home-grown notes for some of the other metadata we >> pass along (like the message buffer, etc.). Also, changing the format >> doesn't help with reading existing crash dumps. >> > > Thank you for your reply. If I understand correctly, you're comparing > minidump with a "proper" (i.e. virtual memory-based) ELF core. However, > the "full memory dump" ELF core also uses physical memory map model, is > that correct? Does that mean that using a different core format makes > it clear that it's a physical memory dump and not virtual? I think so, yes. > That said, please correct me if I'm mistaken but I think we should be > able to create a "virtual memory mapped" ELF core without too much > duplication. We could creating multiple segments with different p_vaddr > values but the same file p_offset, correct (and maybe p_paddr)? I'm not > advocating for changing the format, just trying to improve my knowledge. Humm, we could perhaps do that to avoid duplicate data, but that would be a _lot_ of PT_LOAD's. Every physical discontinuity in kmem would generate another PT_LOAD. I fear you might have hundreds or thousands of those, but we wouldn't really know without mocking it up and trying I think. You could simulate it perhaps by just writing a tool to convert an existing vmcore to a "fat ELF" for now vs having to change the kernel. -- John Baldwin From nobody Tue Nov 23 22:41:01 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BC9501890BFF for ; Tue, 23 Nov 2021 22:41:02 +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 4HzJyQ2lVwz3kbV for ; Tue, 23 Nov 2021 22:41:02 +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 1B36D272A9 for ; Tue, 23 Nov 2021 22:41:02 +0000 (UTC) (envelope-from jrm@freebsd.org) From: Joseph Mingrone To: FreeBSD Hackers Subject: Call for Foundation-supported Project Ideas Date: Tue, 23 Nov 2021 18:41:01 -0400 Message-ID: <861r36xzpe.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637707262; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=V8ca2P3yjGkcpbswfoEXEWLezT8jmewV4SY0lTnSoUU=; b=D5g1CZlhSBbaOXFczcZeujj4s9W36XfxuQRx1sO1alyhHpGyoKvWEOMPYk9mdUPmtF7ml6 p5Iy+EoRBTTV+9tC9HRJW1WozSo9uYVdbLcI2AzIT9m2aYO+sCIRUVDhTJC7Nfq4gE0L97 4Or4JXUBM5RwqYBZr+NiaI+2cRkwysUtQ7F0T7DAqiFkXqS3FuIeOS+IHYnMZcybnBT5qL xzZ5zK50NOjZIxbgBnF4hQpuIaf3bNVnxDs1am1Udcb/T3QuXrDqh5KD73Sa1C61BVuaJj quX4uIF4uYV/PL6VefJ2XuRqm+eqhbvFNFz+Vcn+xp+OYiXeo4XbnLnVh4cV1w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637707262; a=rsa-sha256; cv=none; b=sLH2MNVvBYeGV8nZJsF+BjTqLqJf6V5YpxzaRRbDWY+SI3QujnoAw3nfK/DS3+vwz0G8cS HgXB4ongAu2H10Xg2T4tWat7JcZwkG0KGljDCtM1AIU6sEnzIsXJozp2mY7CF5TRAsdMjc FIj8x76hH/p5kpZIeIMWhIKNQN0u6HseRfoYuasly64Cb5ZH+TCWhORIoiqfbaiBfViyVn kYvkRvRFHrlCmmafRLvp1eNJbtFSQ341yCOIZiVZ4UmCShU0U463XCJ3CUwlDYaapGMjUg sGgzpaWxrtq29k3wpUOvxR6BT6MpIoXDx2c4W8+thxDRY3OBD2NoiNU8vn6jIA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello FreeBSD community, The Foundation is seeking suggestions for new projects to support. What gaps in the Project are not being addressed by the broader community? You can read about past Foundation-supported projects at https://freebsdfoundation.org/our-work/projects/ and the Foundation's four main areas of focus in the 'Technology Roadmap' article at https://freebsdfoundation.org/blog/technology-roadmap/. Right now we are gathering ideas. We will send out a call for project grant proposals soon. If you prefer to send your project ideas directly to the Foundation, we will be monitoring responses at techteam@freebsdfoundation.org. -- Joe (with Foundation hat on) From nobody Tue Nov 23 23:10:41 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 566F6189F67F for ; Tue, 23 Nov 2021 23:10:43 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 4HzKcg0gxpz3t4j; Tue, 23 Nov 2021 23:10:43 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lj1-x233.google.com with SMTP id k23so1372084lje.1; Tue, 23 Nov 2021 15:10:43 -0800 (PST) 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=olEVda5diLVNUxN6c8utlJBvn41IGUlqIuUMjXINp8E=; b=ke60utYMRkEFtk0ZEUdm0lx8egYIEDatNm4t+7aN1LDqjwEy8NsjjXe0fu3mApubd/ jO/waBQiElmsGstmR7lqbStaMvUJNOA+hgA4oU/eQNd/rKT1XnlKbARtlrkxVj5HOlDE 908L7UVS8YVdmDc2Y8Tk8zbgdyBBVxQpSz8GUXcYhEeFcJVw6FAyZ/8G3AjefpvCryLh /6GpAC+btrivufyEEMnbJ9HoD9aHIvGtP9N5pvJgQYmE6nexRjTmCZ/kaY+lP9E0etdP OWQmKzi4c+C5rBwyCRibyjxLcRL4dXA8tIfN1zwUcJEMYNyk0v86YHFXL6FgG1mAd3A2 w1Vg== 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=olEVda5diLVNUxN6c8utlJBvn41IGUlqIuUMjXINp8E=; b=p21cEA25pbhlKzZ/8UFDwbUrmVr2cr/9XFDRSYFGEhV9pv0OCBpLdENph8H3m5Hg9M F+vkKbPbUDSbzPYWx9kxWWr1f4XUIcAANE6Wvc3OAKIEAIGipCOyfU4TjDx3SNooRVM6 VM6+BlGOpuQPTY/iAAWeETyV0ztmfP8f4tewzzv07HivJbixNbkXdJ03NCEYbfukxdNx vmiBgOnbm7h1N7tVbhiY3kk7ZvIWWbeJYW1nc+XP/DJBelf0YEOY12Fiv0n2KNNFiUU+ Ryv1dbKKLbTbOze4XaryZURk8LlpffwT6kyQ/RfMNvgfM4DlGtDac9plYC/kR21ad5DZ bZlg== X-Gm-Message-State: AOAM531kVM5NL+xjlagtuBkQcDu81uRcA2yot3QCH4PPBL7fTix3DIrC 0JjKKF1WS1wZBJEgHyvzjWy8h26aAGcXOiSBMzPOVNLR X-Google-Smtp-Source: ABdhPJx7E6ksbW2d7LTY8B7srinD9ao07sEMhL4zEr0KTpuj/6vPKDDP1wjN46mJF1rn5ufOLmUmem18f4cs9gVlLrM= X-Received: by 2002:a05:651c:211c:: with SMTP id a28mr9947265ljq.323.1637709041754; Tue, 23 Nov 2021 15:10:41 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Tue, 23 Nov 2021 15:10:41 -0800 (PST) In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> References: <861r36xzpe.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 24 Nov 2021 00:10:41 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HzKcg0gxpz3t4j X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N After suspend to RAM (ACPI sleep state S3) has been successfully implemented as sponsored work by Kim Jung-uk, it would be logical to add suspend to disk (ACPI sleep state S4, respective hibernate). This would not only greatly enhance FreeBSD usability on laptops and desktops. It also would enable FreeBSD to be usable for number/data processing and server applications which are not designed for interruptability/restartability/resumability. Hibernation capability is not only useful for power cuts that last longer than the UPS can bridge, but also for maintenance, hardware repairs/replacements etc. On 11/23/21, Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) > > From nobody Tue Nov 23 23:28:14 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 64D6418AD7F8 for ; Tue, 23 Nov 2021 23:28:21 +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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzL1129xbz4fNl for ; Tue, 23 Nov 2021 23:28:21 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x72c.google.com with SMTP id b67so877683qkg.6 for ; Tue, 23 Nov 2021 15:28:21 -0800 (PST) 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=a0l0Xg/owRoP45jC5QT81vWPiK+KqD/ILiBXOOnFt10=; b=M9VT2L2sl1IkhKEYhOMynqiwsYGNBAEx80i7EUMdEx+ohjuSZPvuA6WG5LqEhRQ5Tg IHmpYeEeYFAPJcRjKLjQ57U3P46qkpvi/6y16bgdTjbLt/ZcMKJ+ILs+244G5u2j3lM+ 7a8XhechizFrhGfuIxQtNCZDchkT4dCYfbnLDdDL89hgNa3NEezA0FoQAj0bqSf3LAPi C8XNpOfmXAmDJlEz0jkJ6FYPHAX7ipDtMClCm5k/j+dv5pQV86S2l4wiL0ffWVLyNj5s WEx8wLzuNHxRd1H9kn1WEvJUTe9h2WY3UaOcPMMtqys8/sIvukkrwdsosY1XP7/yKUCk d1Nw== 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=a0l0Xg/owRoP45jC5QT81vWPiK+KqD/ILiBXOOnFt10=; b=52lmb0I/v6DI9GkjINsG5XzTFBoWbAHJx/VseSBUy26RKuzomOih6sRZ2EUkAKlERy TBuZhaygmkHi5CLGWmq5XY8t2AJ3ztVmWzwFGOWleM2vqWgV4OHUFvvPmeIQp52i2NW5 6L9wNfcr3lwpMLxH0tpu8h3miBXKr4sJyGmN965vi3Ea43eYuU5hAPoj9Yjb7nMKFeAQ 7CK3RymjN1cHrlmL2lKcNrMfw/LH2O/YFxgenJZBlvQ6lsijO7qewq5wkVEIy3AvdZ1b 4KwfQCVF0wS8MeKbvv/GpYRE2qM3AGqTnLTTT0yGyAmLg6TqfgAUpQ9omdaXVmNHwQu1 Fjug== X-Gm-Message-State: AOAM530RGjWWYvH2ySiKsZ3Jiqp7FDM2Qxfp4czteNmcbhlI5m/vwcmv RCTW4P2q6mrImd40W3oMr824eG/xiNxxwV8L X-Google-Smtp-Source: ABdhPJyp/AvcFJz9Nsmx+JmO6JTyIT+wdfqkO2xCPSCBCvl81bcp4BQ0YvPKPf0C0UefOjA8UrmvIw== X-Received: by 2002:a05:620a:25c9:: with SMTP id y9mr1267798qko.386.1637710095599; Tue, 23 Nov 2021 15:28:15 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id s22sm7583802qko.88.2021.11.23.15.28.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Nov 2021 15:28:15 -0800 (PST) Date: Tue, 23 Nov 2021 18:28:14 -0500 From: Shawn Webb To: Joseph Mingrone Cc: FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211123232814.6vx3sqnsdvc52oc3@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: <861r36xzpe.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nzn5kcrew7syf7vc" Content-Disposition: inline In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> X-Rspamd-Queue-Id: 4HzL1129xbz4fNl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --nzn5kcrew7syf7vc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 23, 2021 at 06:41:01PM -0400, Joseph Mingrone wrote: > Hello FreeBSD community, >=20 > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? >=20 > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. >=20 > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. Hey Joseph, Thanks for sending this out! Here's just a few things I'd love to see: 1. wireless mesh support. this would go _a long_ ways for supporting human rights efforts. 2. 100% llvm toolchain for base and ports. freebsd seems to already be going in this direction. 3. jail orchestration in base. it's great that we have all these disparate jail management ports, but we lack a fully coherent/integreated solution. I'd love to see jail orchestration get the same love as zfs in base. 4. tor browser bundle (port from openbsd?) That's at least what I can think of off the top of my head. Thanks again, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --nzn5kcrew7syf7vc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGdeQwACgkQ/y5nonf4 4fqoYRAAopN1whL4FDaU79YdrBMzA9iikO+TWvY6J5Z+jtfAXJJbUiLb6SFxVt77 +UOjZpdxpTqiCVfIjDS2Yh5zkZAV7kkfSOc6HtRyo3zPgxoULyInX3M0Co8B6pNx GJgNAZUBSAUoZMgS8JsqWC7CEId6MPjy5pufMLbagOSSylD9qIWDsfmGs+J5vWV9 d2CJ4ym0Ol9QMdY9lJcKeXLh8qcnmTWarGT/HCJR6V7dljX8f14Z+Xj/OwtHkewF KcgN4X94mmlb5y/lmPUwrGCNZMmJOBJxec8as1FSep8Cc1iW1uOfvdVXf+lh+G2f poFwurUYtvBd/ANb7dNneeV8OzBg+a8Cg50XyrpWsAcBdzqvKprsFruusHnLptSw iPWLyXStsrLGMBhwZcZFL7gOCJggMpo46Wi2rAiYj0LQf5vPxfBZV30mvEPdFHO7 0jr9PBJ5tH3kn5iGx8a4PV4tvC+wt6iVyhXJfbRLF6hqpvxZC7VFPJnygJj43+s8 6TQpZ1htQFrskbRj/5gmJfq/mXN9rXo8oKPwFGGWSnDIVC1YY1USG7EzlOqKJndC 6n0pcYo2u1e+vy1iCpUiSJBN40YwRwh/GrVDcr4uuwxl4kh1O+r9bTGW9M2ictcl IwBV/TPtwi1sRM+cijAX0wZNSIjvzyIzRNHVSI0svfQeg8NIZq4= =lM3l -----END PGP SIGNATURE----- --nzn5kcrew7syf7vc-- From nobody Tue Nov 23 23:32:33 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4824A1888A32 for ; Tue, 23 Nov 2021 23:32:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 4HzL6C55JXz4hdB; Tue, 23 Nov 2021 23:32:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f53.google.com with SMTP id n17-20020a9d64d1000000b00579cf677301so1296323otl.8; Tue, 23 Nov 2021 15:32:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uKSMbvU5UiRfOO2X69SH0nm2+N8fr2bY/9Cy0UkSSU0=; b=Oj9eltWqaMdN8qcXGf7to2XyBDp0rca77mVi6g6zUB+Ppp3Tp5BTOAzQ6TjpzeNaQk SoKZmaHRwu3yZ6I6h4XvF3AAZoHDmxjDgNkAqojAMcv+DWht2fmdOhd2ZHtit6QLpx8e vTuWxuW4mgbvEeUgtPDZrHePad9dSvz6SAsIbALgcKE33J+r9y8xQjNogA/Gw+ypBRNa YE51lADGIVHc289HMw1ijBhKMcc95B9LiwpwYtXABaPpARUXzasSD1ofRYnHMW/nk7hf fNunIOi0PP1NIrKidLPuKxRHHULIIVb+D76aE3mdWMuAO3380FLRdiIv04zgZW6c4uVK A9MA== X-Gm-Message-State: AOAM532l78Pf074rBiftrrbbtGGxJ9aNMgFebQFQM72Ls6o1Laqv2/AA wIyOiuTUz944ttbymZ27Dp1bmgTkT9mzCmqscMzQV5OZ X-Google-Smtp-Source: ABdhPJz3Ie7H6evysv8kidnUs5Vz3+cUmlT28p3+UnXYyGXMnaZgFA25Ql7azlo4YZw6XU7bOhAuhyRl2EMygQDhDp0= X-Received: by 2002:a9d:7cce:: with SMTP id r14mr8285681otn.114.1637710364783; Tue, 23 Nov 2021 15:32:44 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> From: Alan Somers Date: Tue, 23 Nov 2021 16:32:33 -0700 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HzL6C55JXz4hdB 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, Nov 23, 2021 at 3:41 PM Joseph Mingrone wrote: > > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) I vote for 802.11ac support. From nobody Wed Nov 24 00:27:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AB69818A4139 for ; Wed, 24 Nov 2021 00:27:22 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzMK6387Xz3FNs; Wed, 24 Nov 2021 00:27:22 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 1AO0RACS094605; Tue, 23 Nov 2021 16:27:16 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 23 Nov 2021 16:27:10 -0800 From: Chris To: Alan Somers Cc: Joseph Mingrone , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HzMK6387Xz3FNs 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 2021-11-23 15:32, Alan Somers wrote: > On Tue, Nov 23, 2021 at 3:41 PM Joseph Mingrone wrote: >> >> Hello FreeBSD community, >> >> The Foundation is seeking suggestions for new projects to support. What >> gaps in the Project are not being addressed by the broader community? >> >> You can read about past Foundation-supported projects at >> https://freebsdfoundation.org/our-work/projects/ and the Foundation's >> four main areas of focus in the 'Technology Roadmap' article at >> https://freebsdfoundation.org/blog/technology-roadmap/. >> >> Right now we are gathering ideas. We will send out a call for project >> grant proposals soon. If you prefer to send your project ideas directly >> to the Foundation, we will be monitoring responses at >> techteam@freebsdfoundation.org. >> >> -- >> Joe (with Foundation hat on) > > I vote for 802.11ac support. I vote +1 for the above. :-) From nobody Wed Nov 24 00:35:56 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AF55A18A9F58 for ; Wed, 24 Nov 2021 00:35:58 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 4HzMW20Q0Sz3Jmv; Wed, 24 Nov 2021 00:35:58 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x12b.google.com with SMTP id t26so2371871lfk.9; Tue, 23 Nov 2021 16:35:57 -0800 (PST) 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; bh=HLLxDlHJm/35zc7qhkX/IAEfIIf34Sb1phdPupBZ3Wo=; b=VZpsLPFO6S8lf2H2/9odzy9z1zY4uQiWNsD8pGcFkJnHJDsNOaQn8cxnad1p+0mSIn ypC7zX1YX7VljXgUp2QkY/F30bdZt44dGQb306QdMb6Gt7vx7aOuExSw87BLhm5t7OtK 5pAq01lyB1mA2QnpoGuqWhQ1upJr9aR+9jHZJrAE3t3kIiTglYvNdJ6lHbMGcMjhwYJZ idQmVhJY8qNA3AXzq+tP500NvM7dofboCPvUGBJ/kNvpwcLyUtyCzxz2D3sZZhHbXmJi hLVzpW3Ejd6auSN/GBIXWvELLho0BkPRk6+RNRJ09PuVo6T/B0cIVgHbyUBp06wUvsfg lmRQ== 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; bh=HLLxDlHJm/35zc7qhkX/IAEfIIf34Sb1phdPupBZ3Wo=; b=5yiCzjwMhTgkljKnjcM4rpr/wHdbFHD+O0/oriIHzCZvX9Bh25ZkSI6eGnLwgCHGGN yyXR7jBi+fb7snvowk+YwrWU8FEEOo5DNI1DNP9PrIp5x7rrti6+UHCgIJmjWb0F5WT1 l8IYDnkc39fxB3deI0lLN9d88LQ9hDKqgjN6+2HxNBBGaNTSwwvOyFUwr8WTX36Pg0qX Auvi8wDye8GxwCTuLJLvwQdSc0Zg9/o+OQl5lQUlhgV5kFh3so44mf+BkdKf2uDaE7x6 K3RNFxr74/JcGzTOa4uLSeJI4gunCuNILXDl/FuREnwawVprneQNbYPRiuIzg4GABscD tmLA== X-Gm-Message-State: AOAM532kln1L/uYyFCYeNlIPOpsU/39fd0oMjo+Kz04+75tV4swWTlJd VUj21n+36OVqbq43OTzVSjPz5pAwWu5zKmrNfezI5Bgw X-Google-Smtp-Source: ABdhPJwDXL6wJrF/0I0ztIo+YHBPdt5pWqVzojcV+QVZRDLpZYOY8GmOlcKVsi8P+mvqCT0ecotApBz7hye0jLDJl6c= X-Received: by 2002:a05:6512:234c:: with SMTP id p12mr9490169lfu.157.1637714156768; Tue, 23 Nov 2021 16:35:56 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Tue, 23 Nov 2021 16:35:56 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 24 Nov 2021 01:35:56 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Alan Somers , Joseph Mingrone , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HzMW20Q0Sz3Jmv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=VZpsLPFO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sblachmann@gmail.com designates 2a00:1450:4864:20::12b as permitted sender) smtp.mailfrom=sblachmann@gmail.com X-Spamd-Result: default: False [-2.05 / 15.00]; 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)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.95)[0.947]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12b:from]; 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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 11/24/21, Chris wrote: > I vote +1 for the above. :-) I'd suggest making a poll after ideas/suggestions have stopped pouring in. Such could give an overall impression which improvements are most wanted by many people. From nobody Wed Nov 24 00:40:34 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A5CD18AB855 for ; Wed, 24 Nov 2021 00:40:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 4HzMcg3jz2z3L7t; Wed, 24 Nov 2021 00:40:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-x22a.google.com with SMTP id bk14so1656932oib.7; Tue, 23 Nov 2021 16:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jvUaAy1vRXnzlnS1ENAgtSmVjl506c0OVdX00cP7GQk=; b=YCf5qgn6iGIK2GnZLdu9UXykcY/uRajC179ZgiFRSLPkj3iSFyZVUe6tX7DWBrj5Vg 6ewoB9Msgz0sYStSSqgoL0Fb4QSWjhPLUgv7qQPSWUwAuwx6FzO9fLCskCvZT1PSeQ6T gwjS02Ee6kPrwnzT8fkiOimQhCrbU0nEqRkk8z9GHl0dSKaPPkE3Lp7dlUT12kme29GW jHGJIyajU4KmttwtZ6F5UsTYC7L3o7puBmZjf5DfHPLXretkt4G80ap9gUDFjEcnx+KK 2olKjc8yj990x6ijx8BbQVUlgl56QjtVQs3cbuukE2ay4Y8/dhJUkI7KUeeUOiZ5vvmH rFNw== 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=jvUaAy1vRXnzlnS1ENAgtSmVjl506c0OVdX00cP7GQk=; b=VE3qcua8ohz7MA3psBOJKwgWZfyBVCSmuBpSDiHcBoU3w6mxlIVGKC2oh+jSjjMpYb Z6ANFeaGt+QxCCoZxF22C9pnyvJTtGLHtstmc+9XvwqqjgRt7IAxUWccbHyY2Vdze+F7 +n1QtXU52vTHRvOgP2ANe/CRWUL8dscbKe5huESvvbBVCR3R+YPkvVbEb55INiGOBFRW egLnZ6MnaTFHbZHednLiCIiTed3MW3D9JHzUsEOHkd1TEuTXg5KNrjRhXq1zrpOfm7Ih JqvXPTPlMTwj7TZwPqiNaIpMd4vp3ib7VMUtlfF0SXXggg+Lji5Pzntn05s/omu2rwKz ILNw== X-Gm-Message-State: AOAM5300Sdv2fkla9fEEk0RtxPCMgqHKmIZRK+W9tSBuNoTy9vg2YjpY NfWrnn50Jo62OVx8BlVsaQDcSm4zS4BBk0SBwCiaDNbt X-Google-Smtp-Source: ABdhPJx2+D5kYLGr1JHY02HezOBAwlYqgs79xAI+xDGzugilfqJpp3A4IXCMSVwYgUuSb9V0aC6ikl4A8Y6HUQhu81k= X-Received: by 2002:aca:1001:: with SMTP id 1mr1562279oiq.55.1637714445444; Tue, 23 Nov 2021 16:40:45 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: From: alan somers Date: Tue, 23 Nov 2021 17:40:34 -0700 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: Alan Somers , Joseph Mingrone , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HzMcg3jz2z3L7t 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, Nov 23, 2021 at 5:35 PM Stefan Blachmann wrote: > > On 11/24/21, Chris wrote: > > I vote +1 for the above. :-) > > I'd suggest making a poll after ideas/suggestions have stopped pouring in. > Such could give an overall impression which improvements are most > wanted by many people. Good idea. You can easily create a poll in Phabricator. From nobody Wed Nov 24 00:59:34 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6EECC188ED2C for ; Wed, 24 Nov 2021 00:59:41 +0000 (UTC) (envelope-from bz@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 4HzN2P15C3z3hwq; Wed, 24 Nov 2021 00:59:41 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id E068028C6A; Wed, 24 Nov 2021 00:59:40 +0000 (UTC) (envelope-from bz@FreeBSD.org) 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 48B5C8D4A179; Wed, 24 Nov 2021 00:59:38 +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 F1BDFE70847; Wed, 24 Nov 2021 00:59:37 +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 iDBHYsQxYo6x; Wed, 24 Nov 2021 00:59:36 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4EF75E70846; Wed, 24 Nov 2021 00:59:35 +0000 (UTC) Date: Wed, 24 Nov 2021 00:59:34 +0000 (UTC) From: "Bjoern A. Zeeb" To: Chris cc: Alan Somers , Joseph Mingrone , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas In-Reply-To: Message-ID: References: <861r36xzpe.fsf@phe.ftfl.ca> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637715581; 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=76orsCUZZ9KM/jhuZs1KJqtpNkQDaMaEhPKr4nRJmlM=; b=bmfTXOhHxZjjxLdbHy4oD5nsm9wY5oFvNG/pG/rC5SsI5/FSNy2ZgoKXjSA/wwPygxu3c7 5hVgASHd578IIoLJ1KK6GWH85ktVkrQdWiwRT8fV/SKGj5nTuTxKBB2sQiDQIetBpfeUIM 46bANB4ZGqfeIQZ/WPWKXbMKF/sPgEJ7dQhUfMJckAHvnOhHROldmMWW4qGTOA5zTPNaUq MJ+hunUWLV6AIUax9QDeqerR88zjMj08OyjW46Y+WGOBn1tkCpMGhq3/Wr1kXNPrIle0jb 1iKjoRVx7ARS16VGBfMvzDcsruf1pxAAIsvd8SYtXSKUZiCArgbjPU7ERcjK+w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637715581; a=rsa-sha256; cv=none; b=wYvBJPtlp92INZNNlODhJcElkWynxtl4KHDkVvV1gThKxPaLew8df14ziCfcCphSSRNyWh 6udvczwFzq9eDSIxbcYcGdseaJYHCPYZj84erdzWP3erRj0dr6YF2/xUjpmh8hvHVPmkKk X0/PEVYFQAnJrUOurZdYMKlx3XMk4DxZ8bq2RVWdf/cv4WMTdnr6Yhfbu1R2x6GjKKtpvd bMwbwRF2egtY898SPxAu0YUDh20JAWmNiF11k2ho6F7gzXErzOiXXWV7bWt8rDaJGqNzqp uoFqtyUBHkGeYF2Pyskb44t6d2nSG+IJzlucfOkni9byALOOapCA2AVM4hejiA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, 23 Nov 2021, Chris wrote: > On 2021-11-23 15:32, Alan Somers wrote: >> On Tue, Nov 23, 2021 at 3:41 PM Joseph Mingrone wrote: >>> >>> Hello FreeBSD community, >>> >>> The Foundation is seeking suggestions for new projects to support. What >>> gaps in the Project are not being addressed by the broader community? >>> >>> You can read about past Foundation-supported projects at >>> https://freebsdfoundation.org/our-work/projects/ and the Foundation's >>> four main areas of focus in the 'Technology Roadmap' article at >>> https://freebsdfoundation.org/blog/technology-roadmap/. >>> >>> Right now we are gathering ideas. We will send out a call for project >>> grant proposals soon. If you prefer to send your project ideas directly >>> to the Foundation, we will be monitoring responses at >>> techteam@freebsdfoundation.org. >>> >>> -- >>> Joe (with Foundation hat on) >> >> I vote for 802.11ac support. > I vote +1 for the above. :-) I'll stop this line of thread; I'll get there hopefully sooner than later. I'd be totally interested if asking for 11ac, are you using 11n currently? If so, with which card? Please reply to me directly and not to all! /bz -- Bjoern A. Zeeb r15:7 From nobody Wed Nov 24 01:22:29 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E47B6189A6A4 for ; Wed, 24 Nov 2021 01:22:29 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 4HzNXj0bTBz3pLc for ; Wed, 24 Nov 2021 01:22:29 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id t11so1121169qtw.3 for ; Tue, 23 Nov 2021 17:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=IhTKK0kXEk2i7ksC3TTZIDGJIkGB+pZ8QwVx1o2OQ28=; b=A9jaKBT7KySsXB8rzp7W0mUnYVQkfD9u1gjXkYQT/2l2oIXRE5f1x1dXuXnJl3SNqG Dt7KsxRUVIgND2UJpyJGea9wXVb1GC2VPvc+XIufMup6zd0aRmCqoKhH5eStOX4NPASJ Nfl/4F/gGOiZyAVEazaM5H8EkTzqKDW1YeX2bhMuPaT+UpmlCYLyU6fZ0xZbsZy6vPsR qHQKFM9Ttq2eePW5hcNLPMqXtdxEUfvvShQ4uMPS7MNcptO7yq7PWQaEtOAjP92i7kak woXLtxqNYy7PxnRWWKDTfW8o7eLDJ2r+y6opCTcy0D5Dl5pqPn0m0ewV1jNvzpjArNxd diXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=IhTKK0kXEk2i7ksC3TTZIDGJIkGB+pZ8QwVx1o2OQ28=; b=r86b7RDa1HEUg8lhURChsDx89IKy8Mc3H0HapOh5QG55TWXzK4rP2rqG1/cgbDonEe KNWy+au1lv/ch3AWYyQqRfrTPywpGm23wSTn76kjwZ0Z+zD1oXVIFB0pwXyNklxfH1le rSNB84w3VLttVTD/T/o51UqBqZogn8ZS4g8eYZn/kl+muvfS37iGd2j45FoCWRPGBDks f1L7U7FWvI8BqwBud6tK+pPEt34f4cybRarx+dfwmOetS3hba9fAfiGCme/YWLzbfAEU WApzSKAlpbfUMSCjL/AJFBLnkczHcYzZrshw6DgZuMQk1xOF4WnEAScKYIoLJy8QB2RL hnCA== X-Gm-Message-State: AOAM532YG4BPLwN464oa+Qa8UjmzrRfJyoZIUoDz29HybeUh8I8QFxIn r9ZcPb0FAAd3vu0aI9UMGRtnH3r9PFc= X-Google-Smtp-Source: ABdhPJwNrX9d4kw3T1n9jrBBo+VbHWj7JGU2YP7CjXWvmVg94kcaBPTjdA7IfRbMLg2cLvyyeix3DQ== X-Received: by 2002:a05:622a:1705:: with SMTP id h5mr2279208qtk.331.1637716948443; Tue, 23 Nov 2021 17:22:28 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:6e88:14ff:fea7:590c? (2603-6000-a401-3a00-6e88-14ff-fea7-590c.res6.spectrum.com. [2603:6000:a401:3a00:6e88:14ff:fea7:590c]) by smtp.gmail.com with ESMTPSA id f34sm7527577qtb.7.2021.11.23.17.22.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 17:22:28 -0800 (PST) Message-ID: Date: Tue, 23 Nov 2021 19:22:29 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> From: Jason Bacon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HzNXj0bTBz3pLc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=A9jaKBT7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::833 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::833:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Some of you may be aware that I maintain sysutils/desktop-installer to facilitate quickly configuring a stable and secure desktop system. https://github.com/outpaddling/desktop-installer One hurdle I've not yet been able to conquer is automatic GPU configuration. The best I've been able to do so far is an interactive script that requires some rather technical decisions from the users: https://github.com/outpaddling/auto-admin/blob/master/Scripts/auto-gpu-setup It would be really nice is we could replace this with a simple, maybe even automated tool to configure a working Xorg setup on most common hardware. Wouldn't matter to me if it falls back on scfb or vesa in many cases, as long as it's easy to use and produces a working desktop. Bonus points for not requiring a reboot to properly activate the DRM module. I wouldn't obsess about making it work on *all* hardware off-the-bat. I think it would be more fruitful to first develop a system that works *really* well on the most common hardware. Then we have a product that people will want, which will help recruit the people we'll need to work on expanding hardware support. Most other aspects of desktop configuration are handled automatically or with questions that an average user can more easily handle. In case we don't have the specific manpower for this at the moment, some other desktop related wish-list items are under the "Future" tab here: http://acadix.biz/desktop-installer.php Best, Jason -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From nobody Wed Nov 24 01:25:20 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9E7AD189DAEC for ; Wed, 24 Nov 2021 01:25:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 4HzNck3bQVz3rS1; Wed, 24 Nov 2021 01:25:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-vk1-xa2b.google.com with SMTP id b125so478145vkb.9; Tue, 23 Nov 2021 17:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hQItld5Lwwl4VZauWyAihOGkLrrnW6f438iCZEEm0fk=; b=icdj3snr6ll6pL+wjOEQXWmAFnpAH4UKU6GGlvPUslLpVuA/2kWXz2DW5W0Ta2pQaz sxUKX+SjGuQso5/maZVeBrN4RcRgRTz97bR1kw1dwKWsis5Q2GaWKZapLVhkIRovbsND LSatD1MkgH7oOeIBQlim9UBQOGRPlvXQ6CUoZfLJapSow+uvIyhgAd4vhE+zoPcU6Nwx iwYRPEnIISywlT9OLhBbTteCwSj/pIR9Zc8Dn58dXEDbuHU/eqClfhpe4PRunN34LYvc pgKJh1gJ86M1VyXAxccfyXfEz1juwxzuQQ2iQLbcO71155z/rqH+7uTN/jEOF6LKxeY9 PR4A== 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=hQItld5Lwwl4VZauWyAihOGkLrrnW6f438iCZEEm0fk=; b=3ZSzjhui4iimJWrD1qNqqyC8XL0XhhUISZDoMbFJEYa5DmjiWn7amRmbrgGtXQiTPn EOtS+4AsYu3cR/kAekCvry8Qf15lGktrwu1OFqrgcOyuPNj2vZeAoxPxWZ5AZZLmhZAF tG+HsbX2IWkA2JewoHMbMBUsZtoob+W0n84MCscNvy5HRzhpYOQ2+bmYU2yoM3mfQ+5l 72c6DUsVtcBNVTZ/UbndMmDHDRPqmw2uzohwf64sJEOugNy9+tQuiu9aRzWeaD4tBMzA Tf71QjlkVROkjuAheDgQ7o+p+PdFyOriMMPI3MfOAe5bbgFi5uCHgA1xW2hWZfz/RnUS 9IiQ== X-Gm-Message-State: AOAM531M9ka2VXXZczCTXWJBx1EG70syW8tb//huP8WZL8sL7NlkEp0y k4jx7ELC8r8eHbYuV0KMV8mC8a3w8Id/70NLTFQ26iS0tXzKOQ== X-Google-Smtp-Source: ABdhPJxghvPLflni4dzvNi34s7oztRUkqx507JLMBwLffXmfpYHpZc9oVq6YLP6sEbvL9IgcZB+7Wl/0Yifdz5ferl0= X-Received: by 2002:a1f:f24f:: with SMTP id q76mr18269859vkh.11.1637717157074; Tue, 23 Nov 2021 17:25:57 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> From: Mehmet Erol Sanliturk Date: Wed, 24 Nov 2021 04:25:20 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000064dcbd05d17ebd3a" X-Rspamd-Queue-Id: 4HzNck3bQVz3rS1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --00000000000064dcbd05d17ebd3a Content-Type: text/plain; charset="UTF-8" On Wed, Nov 24, 2021 at 1:42 AM Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) > > (1) Please see the following pages : https://getfedora.org/ https://spins.fedoraproject.org/ Fedora Spins : Alternative desktops for Fedora https://labs.fedoraproject.org/ Fedora Labs : Functional bundles for Fedora In FreeBSD , there is need to produce such releases ( including KDE , and frequently used other ones as many as possible to produce ) to be installed and usable easily to attract newcomers to the FreeBSD without requiring intricate ( and possibly very difficult ) parameter settings . (2) Separate Handbook sliding versions and make it Handbook per version , and make available for each version just like manual pages specific to versions . (3) Before releasing a message to the mailing list , get a link from the related archive and insert that link at the beginning or end of the message . In that way , it will be possible to omit the text and use the link of the message . In cell phones and for long messages , and persons tracking the mailing lists continuously this structure will be more convenient . This structure will be a little difficult for readers who rarely read messages . Please make positive discrimination toward the frequently readers . (4) To my knowledge , if a thread spans successive months , their links are not connected . This is causing unnecessary searches or missing messages of the previous month . Correct this situation by linking properly to messages covering successive months . (5) In the mailing list messages , there are a huge number of useful ideas . At present , these are nearly all lost . To find them , it is necessary to write a proper phrase in searches . When such a phrase is not written , it is not possible to find them . Generate a blog-like website with pages containing a manual text fetched from manual pages for display with proper links . Allow people to put comments into these pages . When a comment is entered , send it the respective mailing list and link mailing list responses to these messages . Time to time , transfer usable parts into manual pages as if they are a knowledge acquisition . In that way , over time , improve manual pages step by step . Inform the people at the beginning that their ideas will/may be transferred to manual pages with the FreeBSD license . (6) Apply a similar process described in (5) to the Handbook by using its parts as pages of the respective website . (7) Apply a similar process described in (5) to the configuration files by using them as pages of the respective website . (8) Include a list of files in a release with their hash codes usable for (i) Checking integrity of respective files over time ( including updated files by the system upgrades ) (ii) Usable during upgrading a new version with gaps larger than 1 as much as possible . (9) There is not any available "Compatible mainboards , webcams , video cards , ... , etc. " page containing especially current products available in many countries . Sticking to a special country is of no use world wide . Asus is maintaining a list for Linux , but not FreeBSD . An important point is to list currently available products . In some lists ( they may be related to other operating systems ) there are nearly all archaic products that it is not possible to find and buy them . To maintain such a list is only a waste of resources . (9) FreeBSD wiki contains an index but it is not an "organized properly" structure . Make the wiki like a different Handbook by defining a comprehensive "Contents" part and linking pages to these contents pages . In that way , it will be possible to read wiki pages in a consistent manner . It is possible to perform a search , if the reader knows the "perfect" keyword . Mostly an unlikely situation . The above ideas are coming to my mind at present . My main education is "Statistics and Operations Research" with continuation in "Computing Sciences and Engineering" . Since the historical times , I am always saying that "Solving a problem ALWAYS generates one or more problems to solve ." Life is centered on this structure . Over time , we will always l try to solve new problems . Personally I am not an expert to solve any one of the above problems . If I could do it , I would submit a possible solution instead of writing it as a possible problem . My aim is not implicitly to blame our very valuable developers of FreeBSD , but only express ideas about which parts can be improved more to attract new users for FreeBSD . With my best wishes , Mehmet Erol Sanliturk --00000000000064dcbd05d17ebd3a-- From nobody Wed Nov 24 01:31:27 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7C5D518A1E36 for ; Wed, 24 Nov 2021 01:32:09 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 4HzNls2z8Dz3twZ; Wed, 24 Nov 2021 01:32:09 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-vk1-xa36.google.com with SMTP id 70so496176vkx.7; Tue, 23 Nov 2021 17:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4pjT8ZD7P1orW5xPPNELC342lVSetxRp/zCBZa4zgu4=; b=d3/GvjWENx0+2jFsDsqGSP8qACBpZ1j8dGsgFfbjisQlq3HaB+NkC2KCd3sma3U+Y6 QxxG1KNP0KU2+AmGYGVwvXFhA7EGMYkfyjHSDDGzjf+PGpbZz8tH2dfBpxo45TDrmQ0N LIe+DQge6WqKrFWeF9uzeIA50f2r1y2K1O3vEcOV0/mcXF35aBdAjcLKc5E+kZudzsR8 jRoO5t4ncK0UyqscQ/FYDsKu4sgmrOw03XYEeqK7I0HZBZ6qbUiFh19hDOGgecRpBky2 oUhqaqrukJXKDArCsPrddXUKLDY5vF8AjnJnsIRMvJlqD55RZmG9qacUWQ6u9w9uiuOV NFyA== 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=4pjT8ZD7P1orW5xPPNELC342lVSetxRp/zCBZa4zgu4=; b=aEEauDs4dxce9msldcus7/b/F1i9REEuZGSe0YTIZ21/xEVUGH8niywn+lS7O33ZBc rf+Kk31vjWKEQUKF/5wTkjN8I8tcA1Fo24Y3nA2HEQS4eEcJznW4dM2sOX0XfGabXOYH sBzBGCcIEe16EuP35XCwS/7eB/rfA2PlKbJOimm/PLr7idEMlEtt7tLux+fe5JQ5WWX7 xVpgXAq/aW2OYwvR+PIBfaeb7IOXDf/1KiWX58iySGu1QvFRlLoUanmv3OXRtBq6BVYG cvUANHs0t/6jjMtkBTietBGtOkOOGgfPVJIMyuURKnBHOLN445Pj3r/OvbZCdRHytykh cF5g== X-Gm-Message-State: AOAM531rEhSCXSBViWxj/711Vy/U5pOr8Rf9jeTTy4303Ui6n7Gf9gYF vLJEg73PZpOXP8Pm3WD/NAAaV9yvO7Qg8VtQznBP7Ur1soI= X-Google-Smtp-Source: ABdhPJyrNAQ3YNiPyv8dnKXisy0jaRckZM0cSfp0dS0C+nSahAqmtzQZ/fd2RSmIzvQFUZYh0M15CXKkAAgQIKE0hSE= X-Received: by 2002:a1f:18cb:: with SMTP id 194mr18801229vky.16.1637717523109; Tue, 23 Nov 2021 17:32:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> From: Mehmet Erol Sanliturk Date: Wed, 24 Nov 2021 04:31:27 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000351b2405d17ed33c" X-Rspamd-Queue-Id: 4HzNls2z8Dz3twZ 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 --000000000000351b2405d17ed33c Content-Type: text/plain; charset="UTF-8" With the new cell phones , it is difficult to slide to the end of the displayed mailing list messages . Change policy about discouraging top posting and convert it to encouraging top posting and use of links of previous messages to save the time and bandwidth saving usage . Mehmet Erol Sanliturk On Wed, Nov 24, 2021 at 1:42 AM Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) > > --000000000000351b2405d17ed33c-- From nobody Wed Nov 24 02:01:21 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 92D7B18903B1 for ; Wed, 24 Nov 2021 02:01:33 +0000 (UTC) (envelope-from SRS0=a4lY=QL=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 4HzPPn3BZmz4XH1; Wed, 24 Nov 2021 02:01:33 +0000 (UTC) (envelope-from SRS0=a4lY=QL=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 DC98B2842B; Wed, 24 Nov 2021 03:01:24 +0100 (CET) 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 68EF128416; Wed, 24 Nov 2021 03:01:23 +0100 (CET) Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone , FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Wed, 24 Nov 2021 03:01:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HzPPn3BZmz4XH1 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 23/11/2021 23:41, Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. I would really like to see Foundation sponsored project to bring SMBv2 and SMBv3 support in to smbfs in base instead of deprecating smbfs / CIFS. FreeBSD is the only one widely used operating system lacking support for modern SMB / CIFS versions. SMB is still widely used in desktops and servers environment for mounting shares between different OSes. The latest thread from October with this discussion can be found in freebsd-current@ archive https://lists.freebsd.org/archives/freebsd-current/2021-October/000893.html And continuing in November https://lists.freebsd.org/archives/freebsd-current/2021-November/000915.html Kind regards Miroslav Lachman From nobody Wed Nov 24 03:17:19 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DFACE188FE16 for ; Wed, 24 Nov 2021 03:17:21 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from cameronkatri.com (cameronkatri.com [206.189.178.249]) (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 4HzR5D6XSXz4wyc for ; Wed, 24 Nov 2021 03:17:20 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from FreeBSDY540 (c-73-84-80-103.hsd1.fl.comcast.net [73.84.80.103]) by cameronkatri.com (Postfix) with ESMTPSA id 2A05741420 for ; Tue, 23 Nov 2021 22:17:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cameronkatri.com; s=20201109; t=1637723840; 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=893HLbMiTise2pJbeqTmvBjzlwaFPmPG/NuudBsaIJk=; b=VSuw3H8LHJTgR3xd1K1wS31nGTBJceQ67bu+rpZfaRym64T/uxBcbauIe5CS8Yb5obvJfw cNA9QTEDxZfoMmqbMB3rmHAvBnlBeP7uA0rFdPTBUMRsllc/YACCfw/+UcC9Ym45D+QWVX mYS6zGmbIEHqFl6T+WxanRf19jz9xqs= Date: Tue, 23 Nov 2021 22:17:19 -0500 To: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211124031719.bsczuybkf5yelfzz@FreeBSDY540> References: <861r36xzpe.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jqjdxluzqiwru2hz" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4HzR5D6XSXz4wyc X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cameronkatri.com header.s=20201109 header.b=VSuw3H8L; dmarc=pass (policy=reject) header.from=cameronkatri.com; spf=pass (mx1.freebsd.org: domain of me@cameronkatri.com designates 206.189.178.249 as permitted sender) smtp.mailfrom=me@cameronkatri.com X-Spamd-Result: default: False [-5.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cameronkatri.com:s=20201109]; FREEFALL_USER(0.00)[me]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[cameronkatri.com:+]; DMARC_POLICY_ALLOW(-0.50)[cameronkatri.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:14061, ipnet:206.189.176.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[73.84.80.103:received] Reply-To: me@cameronkatri.com From: Cameron Katri via freebsd-hackers X-Original-From: Cameron Katri X-ThisMailContainsUnwantedMimeParts: N --jqjdxluzqiwru2hz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2021 at 03:01:21AM +0100, Miroslav Lachman wrote: > On 23/11/2021 23:41, Joseph Mingrone wrote: > > Hello FreeBSD community, > >=20 > > The Foundation is seeking suggestions for new projects to support. What > > gaps in the Project are not being addressed by the broader community? > >=20 > > You can read about past Foundation-supported projects at > > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > > four main areas of focus in the 'Technology Roadmap' article at > > https://freebsdfoundation.org/blog/technology-roadmap/. > >=20 > > Right now we are gathering ideas. We will send out a call for project > > grant proposals soon. If you prefer to send your project ideas directly > > to the Foundation, we will be monitoring responses at > > techteam@freebsdfoundation.org. >=20 > I would really like to see Foundation sponsored project to bring SMBv2 and > SMBv3 support in to smbfs in base instead of deprecating smbfs / CIFS. >=20 > FreeBSD is the only one widely used operating system lacking support for > modern SMB / CIFS versions. SMB is still widely used in desktops and serv= ers > environment for mounting shares between different OSes. >=20 > The latest thread from October with this discussion can be found in > freebsd-current@ archive > https://lists.freebsd.org/archives/freebsd-current/2021-October/000893.ht= ml > And continuing in November > https://lists.freebsd.org/archives/freebsd-current/2021-November/000915.h= tml >=20 > Kind regards > Miroslav Lachman >=20 +1 I would really benefit from this. --=20 Cameron Katri Email: me@cameronkatri.com PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C --jqjdxluzqiwru2hz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEfTs2zqQPzCGB+23Nuv/ZeCZUDxwFAmGdrr8ACgkQuv/ZeCZU DxxRdAf/WT3Nqy/sxa+2CyktnkjpxO1m/pQ9YtcchPcPdm+wBk8QNyo+6ZyNzW1Z zwN9mdVAMW0ejKlvIDgnXduJdQZZhQPk3HFRac2uC51F6kGkPEU+DpXhw0OHeF8y u9TmkFs8kKw/KxP25V9UoYZIiyAo+1d2mLryk8B1btO5TY5fyUH5JTAG+mbiufb0 u1jqvZGXS9/Jl1ZT50UCY0mgwfqirzyQLe5NsNNUHU6scW6LN1pbEwlSlQ2fpGbC KcMBZ/lc/6R8/qH834jJvX2uOdWPMjvnXK/xK3VEo4SpnCtq61EBfB7VIMs0YKiH /1Y0CYNV1jf2U1N4/Nevx27x/olW+Q== =PpLh -----END PGP SIGNATURE----- --jqjdxluzqiwru2hz-- From nobody Wed Nov 24 06:00:03 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9CF1C1895A57 for ; Wed, 24 Nov 2021 06:00:38 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-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 4HzVjf1kJfz4WnY; Wed, 24 Nov 2021 06:00:38 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lj1-f176.google.com with SMTP id z8so3001442ljz.9; Tue, 23 Nov 2021 22:00:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bOE0MpmeLmbagFf1GcwCQ0q0BYM7MUwA3FNB5FnvXZg=; b=bu+9EAdLsWvaEeVlxxl0W1hQCYu5ldNtFuiAIuDCcgSlWPsVPqBnmgFosFASxy0pSy QNpJ5WI7KJTKqe6jApxE92/QEkotodkLeKQDT5/tYfQNlhDmK93S8APfaTsjmr8AmaSY erix+MfYFUDFvFxptMk4s9DyVP/90RHhFb2mgGw8vHTs4PRsd/AVevzy6huwWEuagdTU Z51AcT2ThkeB4hjvH+5K2+dnkJ2MGRSfVhL+PiCoiUCz5lWI0Pzy6Xv9HfWEAZYtDC8S /k1GrbfU2HieQ6fJd/7bwODBpikgerW6cvkJPOORot3pty5xit744dBSSFpG+fcXJ9Gf Rn/w== X-Gm-Message-State: AOAM533Akmk4PRXt2qE9VOwdGbAOv6hOIrLszjK0O+IVclKuqmLahtJi KX2ZJ6X+nWxBVxLT7wwnXwm/fex17ML2fQ== X-Google-Smtp-Source: ABdhPJw8VQHUizJ5nzBhDbz3Cu4PoewpOS8y+yV+DAose0nYFihFlvz1dEtOegqikMsScegDU4LDmA== X-Received: by 2002:a2e:9f0d:: with SMTP id u13mr12938517ljk.61.1637733630603; Tue, 23 Nov 2021 22:00:30 -0800 (PST) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com. [209.85.167.45]) by smtp.gmail.com with ESMTPSA id i24sm1719908ljm.135.2021.11.23.22.00.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 22:00:30 -0800 (PST) Received: by mail-lf1-f45.google.com with SMTP id b1so4101215lfs.13; Tue, 23 Nov 2021 22:00:30 -0800 (PST) X-Received: by 2002:a05:6512:10d3:: with SMTP id k19mr11574290lfg.448.1637733630029; Tue, 23 Nov 2021 22:00:30 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: From: Gleb Popov Date: Wed, 24 Nov 2021 09:00:03 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Joseph Mingrone , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000041335b05d18293e0" X-Rspamd-Queue-Id: 4HzVjf1kJfz4WnY 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: Y --00000000000041335b05d18293e0 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 24, 2021 at 5:02 AM Miroslav Lachman <000.fbsd@quip.cz> wrote: > On 23/11/2021 23:41, Joseph Mingrone wrote: > > Hello FreeBSD community, > > > > The Foundation is seeking suggestions for new projects to support. What > > gaps in the Project are not being addressed by the broader community? > > > > You can read about past Foundation-supported projects at > > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > > four main areas of focus in the 'Technology Roadmap' article at > > https://freebsdfoundation.org/blog/technology-roadmap/. > > > > Right now we are gathering ideas. We will send out a call for project > > grant proposals soon. If you prefer to send your project ideas directly > > to the Foundation, we will be monitoring responses at > > techteam@freebsdfoundation.org. > > I would really like to see Foundation sponsored project to bring SMBv2 > and SMBv3 support in to smbfs in base instead of deprecating smbfs / CIFS. > > FreeBSD is the only one widely used operating system lacking support for > modern SMB / CIFS versions. SMB is still widely used in desktops and > servers environment for mounting shares between different OSes. > > The latest thread from October with this discussion can be found in > freebsd-current@ archive > https://lists.freebsd.org/archives/freebsd-current/2021-October/000893.html > And continuing in November > > https://lists.freebsd.org/archives/freebsd-current/2021-November/000915.html > > Kind regards > Miroslav Lachman > > Another +1 for modern SMBFS. --00000000000041335b05d18293e0-- From nobody Wed Nov 24 07:22:14 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 708E5189D4A0 for ; Wed, 24 Nov 2021 07:22:45 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzXXP1frzz3Ktv; Wed, 24 Nov 2021 07:22:45 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165022.dip0.t-ipconnect.de [91.22.80.34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 6707B247A9; Wed, 24 Nov 2021 08:22:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1637738556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=Gd+fHkZA/TrjzKQuvC9fzBJqB6Pet8ySCb/lBZQsgl0=; b=1quIANIhZfBc+mTFWfIfBgAp4w6JJTsAtCSvEFTtOlaalY/rZyT/4PMhmqQ8fbR17kKixi ywRoPM0CVgJ1g/78kehKlv2U6Rq3NmL9ZWq3nlh3M8xpGQbCER8yrJqjrKxIHmzM0T7u8e 1ykETYYL5i5j/2H+b+wPmlLsXjw/J2Ggy13x+C0wGDX7JcsGErP1To4ww+mWDkZlRWuGMR 56dztHFMVUCsewam0qewaUaTJQQEa8HVaQGSm9hUatVsw2jCjEkp2pzxVkG4gwZHXA6jsC NrfIIulae55oW8VY3+tVXkw7pSBJ4wbnMxV8fi21QKMjaoiPFAN3aLNQGFF0yg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 3E6F95369; Wed, 24 Nov 2021 08:22:16 +0100 (CET) Date: Wed, 24 Nov 2021 08:22:14 +0100 Message-ID: <20211124082214.Horde.kxKSYbn4u3baOilQJ0iQa5j@webmail.leidinger.net> To: freebsd-hackers@freebsd.org, Joseph Mingrone Subject: Re: Call for Foundation-supported Project Ideas In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Queue-Id: 4HzXXP1frzz3Ktv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: Alexander@leidinger.net From: Alexander Leidinger via freebsd-hackers X-Original-From: Alexander Leidinger X-ThisMailContainsUnwantedMimeParts: N Quoting Joseph Mingrone (from Tue, 23 Nov 2021 18:41:01 -0400): > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? - MPTCP support (yes, there was a project in the past you sponsored, nothing is in the FreeBSD tree) - CPU/RAM hotplug support (VMs/cloud) Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Wed Nov 24 07:42:56 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 08FF118A890E for ; Wed, 24 Nov 2021 07:43:26 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 4HzY0F19hRz3hYD for ; Wed, 24 Nov 2021 07:43:24 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 59E825C00C4 for ; Wed, 24 Nov 2021 02:43:18 -0500 (EST) Received: from imap44 ([10.202.2.94]) by compute5.internal (MEProxy); Wed, 24 Nov 2021 02:43:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=WvdmQaBms0TSbedLcXYKaDpUuZTLveU oQTVVHfef9XM=; b=sgOvSz6xwv3GoFhYHfWcMTuGAX4xmR6649QWM5TlGFGvOV1 kV9AWyYnQnVImK55vHv5A8HL46Y9iShu66YMiYSMI/NsK76HvxKi/W4sL5RiAztu uel/dXiNfFtOCLKJ97BYtgcYx7LQZlx0EvCFAUmEvY9SYMXJcnFuRIeNmyUaOCSq 9EuVVVI4gSe9xGJOL2MJfHv7VSQCRoPGpdfxdOjHbLCNaXXZvsz0ti2w5K93tg9o J+2FMkLEbc/3UMjPOQLds/2yvgdn1aDmANF09DGHFuWJA58TwClAq2uKp+3y4+uL Mi819LBaF7v9hfZtxTUE6xFZnrzCQ7QUGVzuOOw== 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=WvdmQa Bms0TSbedLcXYKaDpUuZTLveUoQTVVHfef9XM=; b=MBsHX0K9azZfUfDIYwEOLA xRsnachbkW4i/u4yDppVdw9bH1b3fE2vjLj/9pz3bHZV9FoLCuke6/dZwxCRBbSE 0CfT2uODwfUeRXBi1o00iEY2iVYx0VJ0zWnqP+HIOaCDD2UZ1MpcCN/5DVvi6Z4E kE5WwDvavfzOaorEfZ+uhVxvrDedxJJLNtiTKpYtEZn7p54koxBTxia+y9Jr+Za4 H+rBaSRHiBdEOu2Tb1zvK7TTwYDfQre9HY0b+rB3CRlCxdVdtG7xnHJDE0qbwbRV GgldMdaYX5b1LrKwyT8QKF7OTmAZ8bau+RK0CgMiJgD4C21ZtxjzQcGXcmDCry9Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrgeejgdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdffrghv vgcuvehothhtlhgvhhhusggvrhdfuceouggthhesshhkuhhnkhifvghrkhhsrdgrtheqne cuggftrfgrthhtvghrnhepueehveeuvdfgtdeguddthfeufeduudeljeffffefhfegveel ffeifeekkeefheetnecuffhomhgrihhnpehfrhgvvggsshgufhhouhhnuggrthhiohhnrd horhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep uggthhesshhkuhhnkhifvghrkhhsrdgrth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EA593FA0AA6; Wed, 24 Nov 2021 02:43:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> References: <861r36xzpe.fsf@phe.ftfl.ca> Date: Wed, 24 Nov 2021 07:42:56 +0000 From: "Dave Cottlehuber" To: "FreeBSD Hackers" Subject: Re: Call for Foundation-supported Project Ideas Content-Type: text/plain X-Rspamd-Queue-Id: 4HzY0F19hRz3hYD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=sgOvSz6x; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=MBsHX0K9; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.27 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-1.69 / 15.00]; XM_UA_NO_VERSION(0.01)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; 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.27:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[dch]; 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-hackers@freebsd.org]; DMARC_NA(0.00)[skunkwerks.at]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_SPAM_SHORT(0.90)[0.897]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.111.4.27:from]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 23 Nov 2021, at 22:41, Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) Some new ideas. 1. updated kmod ports for point releases. we should be able to ship an x+1 RELEASE *and* have the appropriate kmod ports available at the same time. I know that unplanned API breakage is rare, but when it does happen, its absolutely brutal for end users. 2. a decent ports CI At least for committers, and for regular maintainers, we should be able to have some common-sense pre-commit build checks done at least on tier 1 architectures easily without human intervention. 3. jail creation and usage as non-root nuff said. 4. more programmable/scriptable configs I would love to see FreeBSD be the programmable server environment. - libxo all the things - more stuff like libifconfig libpf libzfs -- "lib-ify" all the things - UCL all the things A+ Dave From nobody Wed Nov 24 08:00:54 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0FA0818AFD5C for ; Wed, 24 Nov 2021 08:00:55 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzYNQ5w4Cz3nfc; Wed, 24 Nov 2021 08:00:54 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637740854; 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=7of1YqNxs8isRw3X7XPqnzh7CIpcrhmhG8rNdxgm2Co=; b=OBBRu+HA61SHM9pBkaZeIGSl48Wu90bayv3ez/KCUDVPF5STnwA16P6bNCI2iy2rJ4UCgw xYqusD7KIvndMrHpRBsMQ3YUb+akbx61HNYHyuP2pe3sQlxIvO3wfVTUtmcHaXCGAxb8Jo OMqBT9HLKE+fy1LBbC4ib8g9y7m2UBxicNlGCUU4nI50sWO3mZu8T9gAvOw6rGt/+kTb5B 2+SRyggsDJQf/mzZGSbHRSYVGl8r1TvbCGmWCp8cuN8oe4YbnNlMSzJnDTlzMdVVyMNCNh IBV4FCN3yEhqBNwnzEvY1UQ8HAukzkjvxE8DuWj9EaPa8EWeHhO4eaUXJfU8UQ== Received: by freefall.freebsd.org (Postfix, from userid 1403) id B04B766FB; Wed, 24 Nov 2021 08:00:54 +0000 (UTC) Date: Wed, 24 Nov 2021 08:00:54 +0000 From: "Piotr P. Stefaniak" To: Joseph Mingrone Cc: FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-ID: References: <861r36xzpe.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637740854; 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=7of1YqNxs8isRw3X7XPqnzh7CIpcrhmhG8rNdxgm2Co=; b=jQPkuPXTWkayymHIu+2YGOSmBkBCUobFChu4aIb1ZLtFYWalRSf5ojUPmrv4nmoKGv6Vgu qk5dMJvuhSGmKQ+st0+kSsPjs4lEXcC68IPHQCqTkd8prDYM+qRAGElhO6xlKPeZc0Jsx8 fX7U4hGU/mly87VJ17DDQNsKH0p3cdrH9mRpJqzoQBVCSkS5E+hRFMflfR1+QGiqlheQeT JLmqRjZHxPg53rlsJ8Ms5i5bpPSregqb4o2Y2i/kAjnd4YJqn9qILEEbxKTeJnqkGD9exu PASkRb5msNg2VGxuTi/Aeis/EoeFnnMM9W5uVOkrySUZSZPcV2MgWDcj4+6o8g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637740854; a=rsa-sha256; cv=none; b=IBXBtqAWtHF/G4ECHY7xWo2cWC/tk5eOF5/KTTg/EAlVtdzECzjODXxiNinW0iiFT4yzgh onrqaERB21HvHIKGMJGp3D4l/cKyg+u5/dq7QOjZWIRZlahoh8b4rnNMbsf2XbH8P6M+Df aln90vQoLBtgTgpdAhs3RkgYeRybv/3X1cTzUjzywOYJtP5zB08bc3EZ65FachgENlCajN N6KKQ9NlFKHIjCIYp+6qSyo+X1po9JMmPvBoT4DdDns+YzZ06BbtwVrgMrwDWKYSp4rLJM bP3I/6GzaT4cddkjf+4yTgP24OgtfxrjDLz9QZc1MC41vKTufehPQIR4AchYdg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2021-11-23 18:41:01, Joseph Mingrone wrote: >The Foundation is seeking suggestions for new projects to support. What >gaps in the Project are not being addressed by the broader community? > >You can read about past Foundation-supported projects at >https://freebsdfoundation.org/our-work/projects/ and the Foundation's >four main areas of focus in the 'Technology Roadmap' article at >https://freebsdfoundation.org/blog/technology-roadmap/. > >Right now we are gathering ideas. We will send out a call for project >grant proposals soon. If you prefer to send your project ideas directly >to the Foundation, we will be monitoring responses at >techteam@freebsdfoundation.org. Let me ask a question instead. There are two tracking bugs for FreeBSD-Foundation sponsored issues for FreeBSD: 203349 and 231027. Would it make sense to add all tracked bugs from 203349 to 231027 and close the former as a duplicate of the latter? Piotr From nobody Wed Nov 24 09:57:18 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4C32618A762C for ; Wed, 24 Nov 2021 09:57:27 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 4Hzbyv1Ksgz3C2k for ; Wed, 24 Nov 2021 09:57:27 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lj1-x231.google.com with SMTP id z8so4211381ljz.9 for ; Wed, 24 Nov 2021 01:57:27 -0800 (PST) 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=E88JtMbbH927VLZVUFt64g7ElheFLG+LLKRUEcDMSGE=; b=cGNePfmuIG8Km/9SkhE4pgiHqIBPR4nZPeRxA5pxBJ1UcBU9xLedzslUUrob/CGZUr bWFoz5VoGBuXsFk5VKEUk9Axuc7ssxBIImXMFhAW1xhnPVzhQ+26E9uklPcDQAIYbuov gwmO6HSXNRwJuNRBBi2IZl6hFGtS1EKa1i12PUUW0GH6MthUDB4OYusLSAUOBPYJ50F7 8nD2AAjvMp/m9xEFjFjRmwHsdMIXrifoCv2Q/WQdebJbsHF3UD4FPy5bhSW/3G+xkTja PnYWTLR4ae3aCjNHtql6F4IoRAPgvD+zbnY5svDYx9/BrgEaeBl3HVnYnBCwSgGBtwQm MC5g== 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=E88JtMbbH927VLZVUFt64g7ElheFLG+LLKRUEcDMSGE=; b=7vg2FKWq8xWgFRVrlU3ifT99hSwnGJwzIUfuBMCrSgRdf3nKMHE5UVN47poeudm2ht 8oYKoqVvkANzIbpFqE03pWCKCFEo43xBCEEDEPTsX8826F60ISgD46ginhXAhwgOBUsg +1Lt9dqu881GUMiWex2iawlDVuDLuY+fMH4u8J3uZD7OjfoKbEVp1O4kcrIIY0ppDAxa eLyairvuXhA/0SCFmes2ZZGG1nvtC12zFT/CDAXMRzdfQtkMQddmeqMW13LapJIdbVtG 05yUuhNljvBeDQoscdb7wvZmrYQxILzbi4ZTvgb0bGM4QFI/86AEbQvCZMG6QlMRIm0i lWxA== X-Gm-Message-State: AOAM531BbSCQ9dvdM8iK0fFg7n/urim0J3H51UtVONBUJk0MRNR46YQ5 B3TL7e5Oy1TMClxtIUfiQUOzPIlW/7IbM5u/7XzK5HXP X-Google-Smtp-Source: ABdhPJz10McF6OmHJL9ume+2YzvIhPHzOiW4LAzW/fjLgRF3yBUiE+6KTl2VvTeiJBpHFqU5WbXX/pkS7jlzQV9DDj0= X-Received: by 2002:a05:651c:b12:: with SMTP id b18mr14241696ljr.306.1637747839102; Wed, 24 Nov 2021 01:57:19 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Wed, 24 Nov 2021 01:57:18 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 24 Nov 2021 10:57:18 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Jason Bacon Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Hzbyv1Ksgz3C2k X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Proposal: Clean up the xorg graphics card/driver list and remove these ones that do no longer work. Explanation: On 11/24/21, Jason Bacon wrote: > One hurdle I've not yet been able to conquer is automatic GPU > configuration. The best I've been able to do so far is an interactive > script that requires some rather technical decisions from the users: > > It would be really nice is we could replace this with a simple, maybe > even automated tool to configure a working Xorg setup on most common > hardware. Wouldn't matter to me if it falls back on scfb or vesa in > many cases, as long as it's easy to use and produces a working desktop. > > Bonus points for not requiring a reboot to properly activate the DRM > module. > > I wouldn't obsess about making it work on *all* hardware off-the-bat. I > think it would be more fruitful to first develop a system that works > *really* well on the most common hardware. Then we have a product that > people will want, which will help recruit the people we'll need to work > on expanding hardware support. I have done this already. My script does autodetect and autoconfigure *all* graphics cards/chips for which are drivers available in FreeBSD. It also works with multiple graphics cards, autodetecting whether they can work together or not (when drivers cannot coexist). The script is not yet ready for release, as autoconfiguring multi-head configurations (eg multi-monitor configurations either with multiple GPU outputs and/or multiple graphics cards) is still WIP. (If you are interested in this topic anyway, please either mail me directly or open a separate discussion thread.) However, the problem is that some drivers can no longer work because libxaa.so (and maybe other xorg libs, too) has been removed upstream 10 years ago already. See this for more info: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257417 This is the background of my proposal: - Test all graphics drivers on real hardware whether they are still functional in currently-supported FreeBSD releases - Remove all those drivers that can no longer work because xorg upstream dropped support. - Feed back to xorg upstrean so they can obsolete/remove these now useless drivers. I'd certainly be more motivated to do this if it is being sponsored, as I have already collected most (except for a few very rare and expensive AGP graphics cards) of the hardware in question. Because, 1. it needs some money to obtain these lacking (past high-end, mainly workstation usage) cards, and 2. it takes some time to walk through them and test every and each of these. From nobody Wed Nov 24 10:05:59 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CAE6218AC72E for ; Wed, 24 Nov 2021 10:06:02 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 4Hzc8n47Trz3HZy for ; Wed, 24 Nov 2021 10:06:01 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x134.google.com with SMTP id u3so5816553lfl.2 for ; Wed, 24 Nov 2021 02:06:01 -0800 (PST) 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=R3YnfgG4GZ6ilEW2KxH21T1jo7FGd/xLhh5MhZgj8Ls=; b=grtuacTzdyfdg4B2YXfgUa6FLAsAoC0T2Xn+IaDCLNpZ8umQZlkv/KcY4bKaXbZ1UI U1nuibrMMD6Xw4F5XdwHHQU5TsXa+JQroR8Px+er0wHz4putuaPU2s1Qjv7UCwBS+vDV jQxHbgNSnH4mvSV+Bx76LIAucw8uI7bLtWNFLqnN21+mmd03SRk4hf9qARyYOUGU6t9e MF0oGFm2l6vpHFYo1w3gwjgs6pHfZlQabQJuZffmKo5/0bKRvXRnYmE2xOldPMP919CI D4c3wCMl0JRM8OJxsDo+6CN84ugvITdpGMb1xUjiEyUHaquG5NODN0R4xsVqgRWPUPzW EVCw== 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=R3YnfgG4GZ6ilEW2KxH21T1jo7FGd/xLhh5MhZgj8Ls=; b=kL4ZeLSgVjRYNikhULS028jlxrzclAxyIf3ToHZvLGSvtnmVlqYw35ncbJxG2PPAMO 70KuU0b+jQD3ZbUdQIzslxCxTCuVfTx17XtdVCXcQ16DK/jLDAtfYc0rmvpgLsY5BP4C puJE/71EkOqXnqnp/MeXWzb3Hs3x/eiXPmAmnInWpoMo6wPiFfJzsQ2qv/L/7XR1YBoO RzurMbdb67kO2te23JVZiOsG+4kFsaNDiXcCZWD9iA/vxOw6VMjQa2q0YCvMgvv8aAez Ol8R/1WWlklk7USMs2sppFu9UEQnQBoa1NEQKMgNB9bto6+lrs/mu5xCS1Jv7fIDxtDW kMxA== X-Gm-Message-State: AOAM530bjsdZbZQMYRM5D7yBhEtSUML9TeSgZnaM0TJlOiJL2D83iFTY UZE9kZg8T59FG+kUwr1+nR4skYs/OvGfJjBMfeM7nMcw X-Google-Smtp-Source: ABdhPJz1QOMmvX6OAzdWkyJRAJ11m0SxeZ5yaWWyPp3bwYN+2kP26zFbmh+l8faUUc7yapVjgDRnvwOwrlKRL3cxC78= X-Received: by 2002:a19:6717:: with SMTP id b23mr12874056lfc.659.1637748359893; Wed, 24 Nov 2021 02:05:59 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Wed, 24 Nov 2021 02:05:59 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 24 Nov 2021 11:05:59 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Jason Bacon Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Hzc8n47Trz3HZy X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=grtuacTz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sblachmann@gmail.com designates 2a00:1450:4864:20::134 as permitted sender) smtp.mailfrom=sblachmann@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; 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_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::134:from]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; 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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Port nouveau to FreeBSD. Reason: There are ongoing changes in the xorg API which break older proprietary Nvidia cards' legacy drivers. In addition, Nvidia plans to drop/discontinue support for their 390 driver in 2022. Nvidia already stopped support releases for their 340 and older drivers so that a lot of Nvidia graphics cards can no longer be used on FreeBSD already or will be unusable very soon. https://nvidia.custhelp.com/app/answers/detail/a_id/3142/~/support-timeframes-for-unix-legacy-gpu-releases On 11/24/21, Stefan Blachmann wrote: > Proposal: > Clean up the xorg graphics card/driver list and remove these ones that > do no longer work. > > Explanation: > > On 11/24/21, Jason Bacon wrote: >> One hurdle I've not yet been able to conquer is automatic GPU >> configuration. The best I've been able to do so far is an interactive >> script that requires some rather technical decisions from the users: >> >> It would be really nice is we could replace this with a simple, maybe >> even automated tool to configure a working Xorg setup on most common >> hardware. Wouldn't matter to me if it falls back on scfb or vesa in >> many cases, as long as it's easy to use and produces a working desktop. >> >> Bonus points for not requiring a reboot to properly activate the DRM >> module. >> >> I wouldn't obsess about making it work on *all* hardware off-the-bat. I >> think it would be more fruitful to first develop a system that works >> *really* well on the most common hardware. Then we have a product that >> people will want, which will help recruit the people we'll need to work >> on expanding hardware support. > > I have done this already. > My script does autodetect and autoconfigure *all* graphics cards/chips > for which are drivers available in FreeBSD. > It also works with multiple graphics cards, autodetecting whether they > can work together or not (when drivers cannot coexist). > The script is not yet ready for release, as autoconfiguring multi-head > configurations (eg multi-monitor configurations either with multiple > GPU outputs and/or multiple graphics cards) is still WIP. > (If you are interested in this topic anyway, please either mail me > directly or open a separate discussion thread.) > > However, the problem is that some drivers can no longer work because > libxaa.so (and maybe other xorg libs, too) has been removed upstream > 10 years ago already. > See this for more info: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257417 > > This is the background of my proposal: > - Test all graphics drivers on real hardware whether they are still > functional in currently-supported FreeBSD releases > - Remove all those drivers that can no longer work because xorg > upstream dropped support. > - Feed back to xorg upstrean so they can obsolete/remove these now > useless drivers. > > I'd certainly be more motivated to do this if it is being sponsored, > as I have already collected most (except for a few very rare and > expensive AGP graphics cards) of the hardware in question. > Because, 1. it needs some money to obtain these lacking (past > high-end, mainly workstation usage) cards, and 2. it takes some time > to walk through them and test every and each of these. > From nobody Wed Nov 24 11:09:45 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E0B3818A702F for ; Wed, 24 Nov 2021 11:10:22 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 4Hzdb25Zhrz3tf7; Wed, 24 Nov 2021 11:10:22 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ua1-x936.google.com with SMTP id p37so4201373uae.8; Wed, 24 Nov 2021 03:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DuKaD+3j4vnA850tzLtjLS3Iz3+0OXFB8Oyl9o6PQfw=; b=lt0nNatCG/0pZ3XS+/jUADG4rOoCsrQ/y82JJJHKX8QfPVWwvZBkAyTqdrqy5UJQ4q oBvkVjYFqA0atWNfLLWCcmygBWJR3pVr8SJEQdXOZw5UXQNZ2rvUaTCnXIVfaIfkRcvW JABa8ms3DbNuD7LMMVYT4YAp5Pi3uY5pZWeXghfmFVGpq4iIMJLJOhFeyKtBaBoa+8jF ZvMjRbeBklTvesh210hKpU0zq4HQKiwMAwti59KQRP5yTPlgiTrgUumejSE+o8zJ3sAC TBLXPxkapf6IWtw35LTr9bZUVYV4wlHXVmfVPImrjg4gr59lNtc6pa9WRG8U0qscWTmz dhbA== 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=DuKaD+3j4vnA850tzLtjLS3Iz3+0OXFB8Oyl9o6PQfw=; b=5FRakm60IodqSc0ajkvWtqTuckC4UKoZhIkhzQ2RUToj0jMk2C+eoKiQhhELmRmeup YzUrxXXp95By/YFDOtKHlGghkwWF+W1k16rxtRPTle/svGnb6qs6NlXbdoVJt3dCG7ds NyOf/al3J2uXLfJH9Ygpk4/SHvCTWiufYq76Xze2FbJdjZ053y+Oa0b/q4HcvxFnYay8 EhAlXtVoPofDTwvc/EPSlJvKDqyRBzALk7Z/YFnLjuxAWTc8XsKbjjaYfBqd+ubUKYw/ KV+AKnbG9R5Nafo2YQczrliEg74Jyt1Q+yqtdytgXdd40A2lSKnrE/30V8LjpvLo9nA5 k3yQ== X-Gm-Message-State: AOAM531uTRevC2K/DNxgGgawWPrhjSOJRXY7GuFc4fRSYAthRkegXxuE sr+lJ9c3gWPV3vJeYWDo/rTixgUJd6chFUSM2U1dJG/zX0k= X-Google-Smtp-Source: ABdhPJxHyj3UpCuhbGmDou1AoVTxQFIsFBfhvvSrs58M1K40ILWSozFHdTUCeQMmRrpViCgam9eI4MOo5mjXCGIU5ec= X-Received: by 2002:ab0:2508:: with SMTP id j8mr9020414uan.16.1637752221987; Wed, 24 Nov 2021 03:10:21 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> From: Mehmet Erol Sanliturk Date: Wed, 24 Nov 2021 14:09:45 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000006bf4e505d186e7d1" X-Rspamd-Queue-Id: 4Hzdb25Zhrz3tf7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --0000000000006bf4e505d186e7d1 Content-Type: text/plain; charset="UTF-8" (1) The device drivers are required to be "root" to implement them . Instead of ONLY this , the following steps may be performed : If the "user" ( being non-"root" ) attaches a device to the computer , the OS looks at a "user" space directory ( imitation of system-wise directory but in the "user" space ) if there is a driver for the device in that directory , it loads and uses it . If there is not any device driver for the device in "user" directory , it looks into the system directory . If there is one , it loads and uses it , else it gives an error message . To manage such "user" space devices , the OS needs to have the ability to look at the "user" space . This may be complemented by removing device drivers from the base system , and making them , let's say , ports or packages . The root loads the necessary ones from the system directories , but the "user" may have the ability to load them from her or his directories . Another important problem is mounting of hard disks connected through a USB port or a hot-pluggable port . Such connections ( excluding if DOS or NTFS ones are permitted implicitly ) require a "root" mount . There is an idea "Use sudo or other super user programs for "allowance" of "root" user" . In my life , I never could understand "How is it possible to manage to protect the security of a system by using such a facility from the "user" space ? " Is it not possible to allow the user to use a mount command for such non-DOS or non-NTFS devices ? Why is it necessary to have a fear about such mounting ? Please do NOT forget that the computer is available to the user PHYSICALLY . He ( let's assume he may use violence ) can destroy , crash , burn , ... , etc. , the computer PHYSICALLY . Such a possibility is not considered , but an innocent "user" space mount is assumed to be harmful . (2) Device definitions are stored as C program data or constant values . Make these as configuration files with ( names which can be generated from the recognized device parameters ) and loaded in run time when it is needed . In that way it will be possible to introduce new device definitions/descriptions/drivers only by copying its device description into the relevant directory whether it is "root" or "user" directory . Mehmet Erol Sanliturk On Wed, Nov 24, 2021 at 1:42 AM Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) > > --0000000000006bf4e505d186e7d1-- From nobody Wed Nov 24 11:59:54 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6EA21189A422 for ; Wed, 24 Nov 2021 12:00:22 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 4Hzfhk2NBxz4hkb for ; Wed, 24 Nov 2021 12:00:22 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lf1-f43.google.com with SMTP id l22so6555627lfg.7 for ; Wed, 24 Nov 2021 04:00:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+JKT7CPLjc4f8LHrF0Y7e5e2/cVSfgTyW3+QfL4PAlI=; b=N7NNua6MRrvA5f1BDiVLaPW5dH5E9HJiY7T50PuMOp5MklqbxNf26zd3rjMyBLnrPL kDvEbEpnCWLiZyZIE1Z2rd2m+BPKW53pDQCWzDiy5/S6KJ6yP1MdKjC2J8GtPTCGi/uQ UE0QktXt+//pDFvoM44J2UZeN9Sg7mdivoT+phMn5C2d7qctp79Mamf7RtIIBtFWNXc/ 7bwRg2rFf/7xyP3VjXsETB7RbUWlMZHwy8T06rOeiEGrJi+kQHo5fmVeNTwdifEODDRC ThoW/Qqyp5JV6gN4JNmmtr18kYDJZXnehmhcuMH0sTC2i98J6IH5dehpQKACJ4e0P+lQ uvgA== X-Gm-Message-State: AOAM531bBFcWfmeo750osnw8XshyRN+mB3Y84Tf8I62AykEUAzrQM91A b71ES7WeYjHNMfg4gbN9XtiRWpOVbaa8Ag== X-Google-Smtp-Source: ABdhPJwBD9M9UAYGqubHQ4EAQgNyb93LsmY02xbf8bZTMByfMTRrX5JaL8U7dV6lbTV2Q8jYGY2x1A== X-Received: by 2002:ac2:418f:: with SMTP id z15mr12615718lfh.213.1637755220759; Wed, 24 Nov 2021 04:00:20 -0800 (PST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id 76sm1498193ljj.69.2021.11.24.04.00.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 04:00:20 -0800 (PST) Received: by mail-lf1-f46.google.com with SMTP id l22so6555544lfg.7 for ; Wed, 24 Nov 2021 04:00:20 -0800 (PST) X-Received: by 2002:a19:4f59:: with SMTP id a25mr13568797lfk.22.1637755220442; Wed, 24 Nov 2021 04:00:20 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: From: Gleb Popov Date: Wed, 24 Nov 2021 14:59:54 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Mehmet Erol Sanliturk Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000024c70b05d1879a11" X-Rspamd-Queue-Id: 4Hzfhk2NBxz4hkb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000024c70b05d1879a11 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 24, 2021 at 2:11 PM Mehmet Erol Sanliturk < m.e.sanliturk@gmail.com> wrote: > Another important problem is mounting of hard disks connected through a > USB port or a hot-pluggable port . > Such connections ( excluding if DOS or NTFS ones are permitted implicitly > ) require a "root" mount . There is an idea > "Use sudo or other super user programs for "allowance" of "root" user" . In > my life , I never could understand > "How is it possible to manage to protect the security of a system by using > such a facility from the "user" space ? " > > Is it not possible to allow the user to use a mount command for such > non-DOS or non-NTFS devices ? > Why is it necessary to have a fear about such mounting ? > Please do NOT forget that the computer is available to the user PHYSICALLY > . He ( let's assume he may use violence ) > can destroy , crash , burn , ... , etc. , the computer PHYSICALLY . Such a > possibility is not considered , but an innocent > "user" space mount is assumed to be harmful . > This is usually solved by having a mounting daemon that runs as root and handles user requests for mounting volumes. Linux has udisks2 for this and we have sysutils/bsdisks --00000000000024c70b05d1879a11-- From nobody Wed Nov 24 12:11:56 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EDF3F18A27EF for ; Wed, 24 Nov 2021 12:12:32 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzfym6Gm0z4nKh; Wed, 24 Nov 2021 12:12:32 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ua1-x92e.google.com with SMTP id w23so4593417uao.5; Wed, 24 Nov 2021 04:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hLPRznAlrUVrclgBKcNy+ALAJCFrBlmOqBrrHd51fVQ=; b=mMqgXOctmwmCrepAlzS71kSrtg194s8qW1kcIANvBlc0hanLtTaD8F5Yr/egKCcUst pp60CbsyZjy7Rj1aDIZIQfBOJS//aBCr724rAexRvrbfC9aFshHwZmCVuzzMKX7bycax adet4NJeWawasjhM2emO3djdEhoqI3fitE0+qKcw8/u/c+O6Rv8s4/IdBeZNApyJjuvH AZWXpnIGD+Iy0BsJO2163R2R0of9JhWWYKqzgV5y/WIwuWRiQ6xW7aRvvsZYZU75IoSL +lOwfmos6vlkuvDUVYG3Szg07v9B7LJeddTVS3JJNem8wWa46fHSMP9aVKC/5WQjDNOS mCBg== 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=hLPRznAlrUVrclgBKcNy+ALAJCFrBlmOqBrrHd51fVQ=; b=azHelXv7z4BG6Plo/O2jRVsDBDBxSZT7QSYJ0tfJb3fGXSGvqJ/ta4i/KoasXJrtO4 KdFiR3dL/93B9sT0KooFRwieiAcvwwvKwHRCvNyjjF2ISC0B1ZA5DvxhWInM7DVcpjll 8qmVdCLEZX9Q7OqEwvrXJjns70zfc933zSgOaihHBAkzzwmXg+ag6oM4aImn/6iyov+K 0gd0JBHW7rElPrfFNsJFy/gShmOvIhWMg/08KISEOHT08Ys3a1MmrNKX2+F0RvAR+yEM Qfwaoq8YxG6BQvpb5+Qqtc4jQijHNUF9cjJviOq8dnxqHFSS0DproCVimiQM+grLQotb lMPw== X-Gm-Message-State: AOAM53129OYpzRUVs3KXh2lq06mquWyOdMReirgEWddAFD+J5lG0BqOw kKDLeArsvuTDrCCOMwRMxQzfWeecHGIyDaLNx5BrEj9oFLM= X-Google-Smtp-Source: ABdhPJz7632V2WwABb8TQJ3dTHhT9tLH/ksEGxftjm9OpOOkPHDN6DNoqGwhY1SU7kGqB/o9qOFAhO8bM12Fx5fP41c= X-Received: by 2002:ab0:4adc:: with SMTP id t28mr9872551uae.4.1637755952193; Wed, 24 Nov 2021 04:12:32 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: From: Mehmet Erol Sanliturk Date: Wed, 24 Nov 2021 15:11:56 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Gleb Popov Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000c268b405d187c55c" X-Rspamd-Queue-Id: 4Hzfym6Gm0z4nKh 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 --000000000000c268b405d187c55c Content-Type: text/plain; charset="UTF-8" Great, thanks! On Wed, Nov 24, 2021 at 3:00 PM Gleb Popov wrote: > > > On Wed, Nov 24, 2021 at 2:11 PM Mehmet Erol Sanliturk < > m.e.sanliturk@gmail.com> wrote: > >> Another important problem is mounting of hard disks connected through a >> USB port or a hot-pluggable port . >> Such connections ( excluding if DOS or NTFS ones are permitted implicitly >> ) require a "root" mount . There is an idea >> "Use sudo or other super user programs for "allowance" of "root" user" . >> In >> my life , I never could understand >> "How is it possible to manage to protect the security of a system by >> using >> such a facility from the "user" space ? " >> >> Is it not possible to allow the user to use a mount command for such >> non-DOS or non-NTFS devices ? >> Why is it necessary to have a fear about such mounting ? >> Please do NOT forget that the computer is available to the user >> PHYSICALLY >> . He ( let's assume he may use violence ) >> can destroy , crash , burn , ... , etc. , the computer PHYSICALLY . Such >> a >> possibility is not considered , but an innocent >> "user" space mount is assumed to be harmful . >> > > This is usually solved by having a mounting daemon that runs as root and > handles user requests for mounting volumes. > Linux has udisks2 for this and we have sysutils/bsdisks > --000000000000c268b405d187c55c-- From nobody Wed Nov 24 12:25:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BBA5E18A90CC for ; Wed, 24 Nov 2021 12:25:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzgG02wDVz4sJb for ; Wed, 24 Nov 2021 12:25:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1637756742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BTgwGA3uwRtV6PTtLbxc0XHX3hUZvxCWX8UJF/mTa88=; b=d9OaER80kLkZul1GXFYnPFgD5G/tS9Ic0LNuztj2hNS9+KfpXWJwRcHubiuRZWysoYxrLI GgdspvOLBWS0IvU0TrGwNvNr7bXp3dNI/sTlmlPc4zb7OnO3gHK3uOdO5PXHvQEMeIDcpg od1UHamdUwF3O8YaL5qHg78DzGGTTak= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id e65cf54d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 24 Nov 2021 12:25:42 +0000 (UTC) Date: Wed, 24 Nov 2021 13:25:42 +0100 From: Emmanuel Vadot To: Stefan Blachmann Cc: Jason Bacon , freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas Message-Id: <20211124132542.a6034874071af28bd1cac5fa@bidouilliste.com> In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HzgG02wDVz4sJb 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, 24 Nov 2021 10:57:18 +0100 Stefan Blachmann wrote: > Proposal: > Clean up the xorg graphics card/driver list and remove these ones that > do no longer work. > > Explanation: > > On 11/24/21, Jason Bacon wrote: > > One hurdle I've not yet been able to conquer is automatic GPU > > configuration. The best I've been able to do so far is an interactive > > script that requires some rather technical decisions from the users: > > > > It would be really nice is we could replace this with a simple, maybe > > even automated tool to configure a working Xorg setup on most common > > hardware. Wouldn't matter to me if it falls back on scfb or vesa in > > many cases, as long as it's easy to use and produces a working desktop. > > > > Bonus points for not requiring a reboot to properly activate the DRM > > module. > > > > I wouldn't obsess about making it work on *all* hardware off-the-bat. I > > think it would be more fruitful to first develop a system that works > > *really* well on the most common hardware. Then we have a product that > > people will want, which will help recruit the people we'll need to work > > on expanding hardware support. > > I have done this already. > My script does autodetect and autoconfigure *all* graphics cards/chips > for which are drivers available in FreeBSD. > It also works with multiple graphics cards, autodetecting whether they > can work together or not (when drivers cannot coexist). > The script is not yet ready for release, as autoconfiguring multi-head > configurations (eg multi-monitor configurations either with multiple > GPU outputs and/or multiple graphics cards) is still WIP. > (If you are interested in this topic anyway, please either mail me > directly or open a separate discussion thread.) > > However, the problem is that some drivers can no longer work because > libxaa.so (and maybe other xorg libs, too) has been removed upstream > 10 years ago already. > See this for more info: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257417 > > This is the background of my proposal: > - Test all graphics drivers on real hardware whether they are still > functional in currently-supported FreeBSD releases > - Remove all those drivers that can no longer work because xorg > upstream dropped support. > - Feed back to xorg upstrean so they can obsolete/remove these now > useless drivers. > > I'd certainly be more motivated to do this if it is being sponsored, > as I have already collected most (except for a few very rare and > expensive AGP graphics cards) of the hardware in question. > Because, 1. it needs some money to obtain these lacking (past > high-end, mainly workstation usage) cards, and 2. it takes some time > to walk through them and test every and each of these. > There isn't much to test, everything that isn't needed by radeonkms, amdgpu or i915kms should die. -- Emmanuel Vadot From nobody Wed Nov 24 13:48:34 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 522EA18B3962 for ; Wed, 24 Nov 2021 13:49:17 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 4Hzj6N4rK1z3r8M for ; Wed, 24 Nov 2021 13:49:16 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qk1-x736.google.com with SMTP id t6so2866943qkg.1 for ; Wed, 24 Nov 2021 05:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=unVYcP5HcjDqk6wbGF7Rc+0W1Y5jqIt6+v7rPy3p1Ow=; b=PvSdWB0lUQQCaUTyw7jgxU84le5Yd3vpTWWPT0PE5Y7/ikMxe37A1QFy4eRmSML7ER 38ZQuN9OcWZr1H1IBv1ClO0DC9MTSNqMcSEkQMP9cM/SVMKwwmDaroFblSFQn/rO7mKD xSniPw0MJ33z8EAUf7Qug2/7f+W9aCXt/7RBQvHUHEDGoLvjciHSbuEQ4avpIFeLbcXi 78xc3XOyYK2PFl4RGn7uV/XSMQMTWWEytSpYGRiWfA51bHQQntM2b3D3XG/JWXFGsv+k UM80e29L9n2qRVYA8jY1VN60RhKV9UloBUnfj3zVtWO4vW6WuunxlAffxCScuFByXR/9 4XIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=unVYcP5HcjDqk6wbGF7Rc+0W1Y5jqIt6+v7rPy3p1Ow=; b=bEztORnuOkzIKKYx7Kby4+TBqatSVgyIl4itcrFiaKS6VHxJFncskHb1D+q0rn4Vrg jUKYZhRrAiIpj2sntEPJ1PBXngdmnzpWV5MtpxJ121BKQPv7kOt+wQgMgjZFv3x3riyZ R8GV/Xt5fXuVsx54VFDjfa0rlZTR+kX15MAnmvX2KmS8ywOJejn0CC+GRayWf2KARFJu lg0MSZhARUaejh7b++4SCnskSCsoHP/qmIW3BGcVW7+FFKTQvq/IZZj1yny73M3b/qkm qWY9zjCI9JsJ6nGLP1gCoxqNQpHHRhT58vIUZHEL/3Ke2X3t3KLVy71ftdKWc0Yqk3VJ zMgw== X-Gm-Message-State: AOAM532IXUnYMa0dMlr+hZguzv6X6IpkWFHroN9B1ssyDtNqnDryR/P0 BBnqooCtKMr67d3Hccf4foUSn5Bgvpw= X-Google-Smtp-Source: ABdhPJxKzEkiqyiru1PuJ5qiPcpqf83mIzJoBE9va9FLJXWsm8a5PdnyS+cvy4mRg3kdcYJ0KEYSxg== X-Received: by 2002:a05:620a:306:: with SMTP id s6mr6083750qkm.368.1637761755936; Wed, 24 Nov 2021 05:49:15 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id d13sm8188280qkn.100.2021.11.24.05.49.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 05:49:15 -0800 (PST) Message-ID: Date: Wed, 24 Nov 2021 07:48:34 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> From: Jason Bacon In-Reply-To: <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Hzj6N4rK1z3r8M X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=PvSdWB0l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::736 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [1.08 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; NEURAL_SPAM_SHORT(0.99)[0.991]; NEURAL_SPAM_LONG(0.10)[0.099]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 11/24/21 01:42, Dave Cottlehuber wrote: > 1. updated kmod ports for point releases. > > we should be able to ship an x+1 RELEASE*and* have the appropriate kmod ports available at the same time. I know that unplanned API breakage is rare, but when it does happen, its absolutely brutal for end users. +1 The drm-kmod breakage with 12.x presented a big hurdle for desktop-installer. I added a temporary workaround to build the kmod from source during both initial setup and updates with auto-update-system. This was really ugly and slow and goes against my general policy of not covering up underlying bugs. But I had to make an exception in this case in order for desktop-installer to be useful at all. -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From nobody Wed Nov 24 13:57:37 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 60E4418B71B4 for ; Wed, 24 Nov 2021 13:58:19 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 4HzjJq1hZsz3tkP for ; Wed, 24 Nov 2021 13:58:19 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qt1-x82e.google.com with SMTP id f20so2664409qtb.4 for ; Wed, 24 Nov 2021 05:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=THoi22rykcfq9g+55LyXVA5kW5MsglZRz1xu4xSh7HA=; b=LzT5RxI4U4LYSnKF4VWZJM/lBeMpuTiCh/OghrU+TzQsoCSQfubFdoCaypz1XfeRZc ZhOhaUhZ8zya8BlWLzral5d7KXqvrZThIiJbgP2mkRuoCtHEupfvaIT2uemoRXX0VFbn N32adaTmT2UeZweuc2c5J9bkUz3GbwH0EYkkrJ03wIbGU/E8MVbFDE8T2DjOpaApFiOJ fwzTlZCYnNKfr08ehxdcmuUprzhEtrXQQyiHJWORA84+mmV2hmZUv2/M/UVHFb68AdKQ L8UN/1r3enGJkwwt/nCLg2owrk5C0QK9uH84fa8ZhsslvXn9znN1DBUoA2an1UAAaCMh yK2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=THoi22rykcfq9g+55LyXVA5kW5MsglZRz1xu4xSh7HA=; b=Am/G39/IgbURdFsNymli5gtbTOF/O5aiF87gnxmb1GNW0gC7J4np3Rt918YoMjxw00 ode1RXZ2Yglmma6g2Rnh0x2sf1vg6OV4JCi10SnBYYxEMJr4luyFmU4lMZdi70sjnpUd T8sPyVe0dY4mn3EYTO+3Bx5yi5n+B2Vpph++0+Z8M65c4J/Xc+PzFP1pH4v/oec77B5n Mx6aI44ZsO6WzO1nuavN43qwVn9Sc/i9As9FOQqPZewES+iLELGSkoL7WAgj+wjsCmGf cJ3ADy9MGQLPrkE44L0m5YVEyaPJJoMSf5r6vG/JqdyZD+kJ5qGaun94lurONwYhFQSx cpxg== X-Gm-Message-State: AOAM532oimnpAL3sa8jg2e6TQzo9RcFrOs2SM6a47inhJh5UOBF0FwZX d7Es0OQpNrs5a1acdIwbSNvb1dh+ZOk= X-Google-Smtp-Source: ABdhPJxMCeLyhvFMoXvYkJ3d/LsWGDzIHQKHDFd2XH0HB+EpnLrywW5+YxxjLLFyXQvQf5kWNn+FlQ== X-Received: by 2002:ac8:4159:: with SMTP id e25mr7560326qtm.69.1637762298901; Wed, 24 Nov 2021 05:58:18 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id q11sm7859166qtw.26.2021.11.24.05.58.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 05:58:18 -0800 (PST) Message-ID: Date: Wed, 24 Nov 2021 07:57:37 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: Stefan Blachmann Cc: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> From: Jason Bacon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HzjJq1hZsz3tkP 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 11/24/21 04:05, Stefan Blachmann wrote: > Port nouveau to FreeBSD. > > Reason: > There are ongoing changes in the xorg API which break older > proprietary Nvidia cards' legacy drivers. > In addition, Nvidia plans to drop/discontinue support for their 390 > driver in 2022. > Nvidia already stopped support releases for their 340 and older > drivers so that a lot of Nvidia graphics cards can no longer be used > on FreeBSD already or will be unusable very soon. > > https://nvidia.custhelp.com/app/answers/detail/a_id/3142/~/support-timeframes-for-unix-legacy-gpu-releases +1 -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From nobody Wed Nov 24 14:04:14 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AF126188B231 for ; Wed, 24 Nov 2021 14:04:57 +0000 (UTC) (envelope-from bacon4000@gmail.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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzjST4CJSz4RPR for ; Wed, 24 Nov 2021 14:04:57 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qk1-x734.google.com with SMTP id t6so2924110qkg.1 for ; Wed, 24 Nov 2021 06:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=QXtlYTm5xDOoeJURQEH8i4/ScvWwRNlqvGteIWm0loM=; b=g7jtfAId2oxhGsdoQSyVwYJWQlDpMY/+qcZh8VYW5O8mq8VknNWgN60+brF7RD2rvC HJGEcSByTsnSiWrkye6DJy+qyXGiCUPKdhBRHcpwtiE29sF7y9FrDktG/3XNq3VyDx5P CogfULQmDVhZFuFYoaukYqX7FKErVnVkEUUZOK0RR4fqdApXJ93VGq/nejNdk0Cf+fu+ NA2CfA9+V9XsVvsOPUcvFcGpCeMxFasV2z/bW3LBXFUKIpKDAKVFJX7CFLr2kaHyOvWx zYeje4f41BBR7Ddhh1cncK3QKfuY9lgFtnpN3ST9WOKIEyE/g/ghR9KTfctf6MOAJpT2 KI7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QXtlYTm5xDOoeJURQEH8i4/ScvWwRNlqvGteIWm0loM=; b=TaR0oB1vkwdoCdRcf8uepzUkcj1BN3Ku5pNYvhHqKZ23jlrYK22m2XJP4X7hzVrqZV GhUt0slr9CG1myRdx8ANnO0h75IDlWqg3+n64GcMxjwj3evpz4IjfgsPbvEbKBj/9r8R S77Xjk3lcUok+hajX4PZVyDAUkUZPYkqh5QhCgrUdB50V1mB3ZRZrU8wFdaeYkJAtdfI uTIdpsltlMAynSIbDrzs5mR2OTvIE94yq1LQFZLsc/aCMyYyjO6ch4/aHkOew/n9V7Gl EhS8mx3tUL+XguoF0s5Ts46COq7uRHAhNph+GF94NAAc8TTjyOGe4v9qjsJ+fPVqXpgg dnjQ== X-Gm-Message-State: AOAM533Pr7dZsJ8N1ItDPHZvaijfhed3nm95bC4aehI+SvFh0dteKrTG hTn/318o7JtxbvtGLsz4BaA= X-Google-Smtp-Source: ABdhPJx5HNkiJo/34pEAZ0585fUbh8ZqfAlRy4cIqYesxUYecYVfqYVbJXS50LzcqxPsHf9h95bxPA== X-Received: by 2002:a05:620a:ccc:: with SMTP id b12mr6237856qkj.147.1637762697214; Wed, 24 Nov 2021 06:04:57 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id r16sm8467446qkp.42.2021.11.24.06.04.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 06:04:56 -0800 (PST) Message-ID: <6b3c51f8-d913-34ed-b971-cf1a4c27cd33@gmail.com> Date: Wed, 24 Nov 2021 08:04:14 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: Stefan Blachmann Cc: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> From: Jason Bacon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HzjST4CJSz4RPR 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 11/24/21 03:57, Stefan Blachmann wrote: > Proposal: > Clean up the xorg graphics card/driver list and remove these ones that > do no longer work. > > Explanation: > > On 11/24/21, Jason Bacon wrote: >> One hurdle I've not yet been able to conquer is automatic GPU >> configuration. The best I've been able to do so far is an interactive >> script that requires some rather technical decisions from the users: >> >> It would be really nice is we could replace this with a simple, maybe >> even automated tool to configure a working Xorg setup on most common >> hardware. Wouldn't matter to me if it falls back on scfb or vesa in >> many cases, as long as it's easy to use and produces a working desktop. >> >> Bonus points for not requiring a reboot to properly activate the DRM >> module. >> >> I wouldn't obsess about making it work on *all* hardware off-the-bat. I >> think it would be more fruitful to first develop a system that works >> *really* well on the most common hardware. Then we have a product that >> people will want, which will help recruit the people we'll need to work >> on expanding hardware support. > > I have done this already. > My script does autodetect and autoconfigure *all* graphics cards/chips > for which are drivers available in FreeBSD. > It also works with multiple graphics cards, autodetecting whether they > can work together or not (when drivers cannot coexist). > The script is not yet ready for release, as autoconfiguring multi-head > configurations (eg multi-monitor configurations either with multiple > GPU outputs and/or multiple graphics cards) is still WIP. > (If you are interested in this topic anyway, please either mail me > directly or open a separate discussion thread.) > > However, the problem is that some drivers can no longer work because > libxaa.so (and maybe other xorg libs, too) has been removed upstream > 10 years ago already. > See this for more info: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257417 > > This is the background of my proposal: > - Test all graphics drivers on real hardware whether they are still > functional in currently-supported FreeBSD releases > - Remove all those drivers that can no longer work because xorg > upstream dropped support. > - Feed back to xorg upstrean so they can obsolete/remove these now > useless drivers. > > I'd certainly be more motivated to do this if it is being sponsored, > as I have already collected most (except for a few very rare and > expensive AGP graphics cards) of the hardware in question. > Because, 1. it needs some money to obtain these lacking (past > high-end, mainly workstation usage) cards, and 2. it takes some time > to walk through them and test every and each of these. I'd be VERY happy to test your script. Especially on my Intel+AMD iMac that's always been troublesome. It would be a big improvement over what I'm using even without multihead support. Let's discuss more in private. Cheers, JB -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From eugen@grosbein.net Wed Nov 24 16:27:38 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1DCFE189B3BE for ; Wed, 24 Nov 2021 16:27:58 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzmdS2JTzz3vkd for ; Wed, 24 Nov 2021 16:27:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AOGRlMh038812 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 24 Nov 2021 16:27:48 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AOGRkU1044267 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 24 Nov 2021 23:27:46 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Call for Foundation-supported Project Ideas To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> From: Eugene Grosbein Message-ID: Date: Wed, 24 Nov 2021 23:27:38 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4HzmdS2JTzz3vkd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.38 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.923]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_SHORT(0.64)[0.635]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; 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_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 24.11.2021 5:41, Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. FreeBSD admins had mostly positive experience and support from Quagga routing project in the past to get dynamic routing done (RIP/OSPF/BGP etc.) However, Quagga is not maintained for long time but replacements like FRRouting project lack proper testing for FreeBSD to such an extent that "dead" Quagga still runs better under FreeBSD than FRR in some configurations, f.e. FRR's ospfd is unusable under FreeBSD for interfaces with aliases (carp etc.) because Linux implements aliases differently and FRR developers run only Linux, https://lists.frrouting.org/pipermail/frog/2021-July/001117.html And this is just one of multiple issues with FRR under FreeBSD. It would be nice for someone (TM) to work with FRR team or find some other dynamic routing solution, collect problem reports, perform testing under FreeBSD, maybe develop and push needed changes to upstream (or our ports collection if upstream in not responsive enough), so FreeBSD would get at least same level of routing protocol support that it had with Quagga in the past. From nobody Wed Nov 24 20:55:54 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 330811896835 for ; Wed, 24 Nov 2021 20:56:06 +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 4HztZs5yptz3hB0; Wed, 24 Nov 2021 20:56:05 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id AD9D42736; Wed, 24 Nov 2021 20:56:05 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f45.google.com with SMTP id kl8so2631414qvb.3; Wed, 24 Nov 2021 12:56:05 -0800 (PST) X-Gm-Message-State: AOAM530JtKLiwo0d7RP6zHpVMROcs3IAZhzrQwole2cdae+CcY8fs+I+ 6jXUkRBqtGMk7ypaEjT9gvTPxmPrGSAF8CD0vi0= X-Google-Smtp-Source: ABdhPJzM/R+RRe2Z/arNXKULI/G3S6H+E+/6KpD5uvD8Yimp1OBQ6JmQrrzThq5/LAMr5CeYur5uaR7i8mHPtq8SgZs= X-Received: by 2002:ad4:41c3:: with SMTP id a3mr11014711qvq.51.1637787365292; Wed, 24 Nov 2021 12:56:05 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> In-Reply-To: <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> From: Kyle Evans Date: Wed, 24 Nov 2021 14:55:54 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Shawn Webb Cc: Joseph Mingrone , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637787365; 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=zNMJx2zZP6TvrEYIpn5eJtRCbyyxEC88whWqj4pWUuA=; b=FiWYvCPhzQBz9CIEmyC2P0TVqo4buVrK0Ixeb1Hq5b2HatOqSFzEjEblEbeVQiXnAVF2SZ OHSo5WSgkUu2pUdFPoiGkKjP7Rq18uqinmWKPE3Wf0Gi1Ri7vi25oXe8lLzju0JDOtrjV9 ay2G0E42BtcotXWMjhGHngRBocUjCl0wum2O90K43BHxgSk3Y+xey80WNZF658WhtxbbQn qVI3dnoGbMt6aRfFLJOFGG4BqPkWo68Nyrk3wjTnzD48zQ2THJM+b30uLhq5Axs3O/NF89 h3cZLCrjomujyn2NNAYjU12C7mSj/geMS6/d2+rq9VeuRVLwd/21iSy2FylQjg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637787365; a=rsa-sha256; cv=none; b=sBnBFtDyJWQpAl2iRTW2l01rP50JmKoZAqb5Qxz7tvXtErS+ZOIW+/0OsQL3C37aThHjXd 1SwkgBqpMeFW/2McQiPNzzAq5qY1q+4hA4p0qPykKIQOb7Z2lttr1o552fFiZjvaqJFhBO tAchT/439XQEWrzb4uSSI0PZiuvHzNqY+q7sH2yt3yNwL3KIJEPuRWRDLqF1oEFrc4Mjt9 sKn3UgCb25XcOG4xzvwX8w0y69z8FlYC6R073v3P3CrQiEmU3BYGVKCj4DNpAbZi+VhJkc KJ/3wH2qrkj5Ouf/Yv164lWlBK9cQ+8VCzj9yhTT5Jl11uHUM0zWzd5vGt78DQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 23, 2021 at 5:28 PM Shawn Webb wrote: > > On Tue, Nov 23, 2021 at 06:41:01PM -0400, Joseph Mingrone wrote: > > Hello FreeBSD community, > > > > The Foundation is seeking suggestions for new projects to support. What > > gaps in the Project are not being addressed by the broader community? > > > > You can read about past Foundation-supported projects at > > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > > four main areas of focus in the 'Technology Roadmap' article at > > https://freebsdfoundation.org/blog/technology-roadmap/. > > > > Right now we are gathering ideas. We will send out a call for project > > grant proposals soon. If you prefer to send your project ideas directly > > to the Foundation, we will be monitoring responses at > > techteam@freebsdfoundation.org. > > Hey Joseph, > > Thanks for sending this out! > > Here's just a few things I'd love to see: > > [...] > 3. jail orchestration in base. it's great that we have all these > disparate jail management ports, but we lack a fully > coherent/integreated solution. I'd love to see jail orchestration > get the same love as zfs in base. > [...] +1. I'd really like to see what one could do with the lua bindings we added for libjail. Writing a lua jail manager would be non-trivial, but IMO it wouldn't be an insurmountable task and opens up some interesting plugin capabilities with just the tooling we have in base. > Thanks again, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD From nobody Wed Nov 24 21:31:50 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 23DC618AB0F3 for ; Wed, 24 Nov 2021 21:31:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) 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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzvN82vCJz4QvL for ; Wed, 24 Nov 2021 21:31:52 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x733.google.com with SMTP id 193so5179326qkh.10 for ; Wed, 24 Nov 2021 13:31:52 -0800 (PST) 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=oZzeBIShq8zk2kPw8LnTx8hoDu7ZvpeUAYTSapGDlsQ=; b=TW6suIw4Jb8gnnxm0Rqdk6bO/jJjFeFU1wns7uuTrT2ydGcW5ZalEvJjo1jglZqKpV sKHXR6ZrQhj6LLG/DzM1A58qm/BWVNMJfwe/NveHquW3I5jVeB2S+yKdxFaB6wi9OCll t/qABgivY8u7rBHoir3zaEfyYWf+oFJug/ZGP47rlPHVF/N1CsukPHgiSCfORsdnfR7c ZjV4LGGj2evoscYiHghyLJHoPh3e0ok1hC7rPniKZNA+BIme5hY35Ksa7Vd/hrg5Ca0D PWGJKGSwTyi0xTvBdnWNa4dyEWFm7ykdz6mCyAcMBI75CdtROAwXS5GIkTS1b30zhqBg BnQQ== 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=oZzeBIShq8zk2kPw8LnTx8hoDu7ZvpeUAYTSapGDlsQ=; b=BMzYVyMgHVrQp1xGX2VhDhWS2rOLo0MATPUKTtk5/63ZPl2aj/wDu34qNDBw4UaMkA ljVbVVvTuevm1LuSCo5cK1eFxl2fMGQL1hqEYMPKhFqx+b7icMEVYyZIjp78561nm1II hRmpQr8U8IaNUn/mgfOibt2lu1LJ9QoiQOhwxjFU79jgPoVaaR8FqGbDYHT/VkMn3Fup NeiQcia2vPV+o3wo41of/PmklEky5xVY5Ni15Q/yhbi2k9R2jRjTxEjpBhq+N3z98EiT 4bNhY7burHxC1QfSQyw6W8h0Vg+ngeaYRANeF36ZKt+e1vYS4qR80hrCJQUyGALSxYzD yZHw== X-Gm-Message-State: AOAM532svn2j9HmrQqyvEIHOpExCtGxFjZZ/ehCIzYXZzaLa0S33RmHo 1idk67M03Ap0cOdAkWo7AVg0qg== X-Google-Smtp-Source: ABdhPJyhXfV53TAn3By5pEsBYUJCA6JareKq/ZdHKRiR6q3kUeTCpGLsHjt2pomuJ7JQZsQi0HZ7/g== X-Received: by 2002:a37:6745:: with SMTP id b66mr1618312qkc.715.1637789511984; Wed, 24 Nov 2021 13:31:51 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id a24sm431800qtp.95.2021.11.24.13.31.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 13:31:51 -0800 (PST) Date: Wed, 24 Nov 2021 16:31:50 -0500 From: Shawn Webb To: Joseph Mingrone Cc: FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211124213150.6lsyaqgwbkgfcgzi@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: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pk5z2zp5esjxce4d" Content-Disposition: inline In-Reply-To: <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> X-Rspamd-Queue-Id: 4HzvN82vCJz4QvL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=TW6suIw4; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-2.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-0.79)[-0.795]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; NEURAL_SPAM_SHORT(0.98)[0.977]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::733:from]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received] X-ThisMailContainsUnwantedMimeParts: N --pk5z2zp5esjxce4d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 23, 2021 at 06:28:14PM -0500, Shawn Webb wrote: > On Tue, Nov 23, 2021 at 06:41:01PM -0400, Joseph Mingrone wrote: > > Hello FreeBSD community, > >=20 > > The Foundation is seeking suggestions for new projects to support. What > > gaps in the Project are not being addressed by the broader community? > >=20 > > You can read about past Foundation-supported projects at > > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > > four main areas of focus in the 'Technology Roadmap' article at > > https://freebsdfoundation.org/blog/technology-roadmap/. > >=20 > > Right now we are gathering ideas. We will send out a call for project > > grant proposals soon. If you prefer to send your project ideas directly > > to the Foundation, we will be monitoring responses at > > techteam@freebsdfoundation.org. >=20 > Hey Joseph, >=20 > Thanks for sending this out! >=20 > Here's just a few things I'd love to see: >=20 > 1. wireless mesh support. this would go _a long_ ways for supporting > human rights efforts. > 2. 100% llvm toolchain for base and ports. freebsd seems to already be > going in this direction. > 3. jail orchestration in base. it's great that we have all these > disparate jail management ports, but we lack a fully > coherent/integreated solution. I'd love to see jail orchestration > get the same love as zfs in base. > 4. tor browser bundle (port from openbsd?) >=20 > That's at least what I can think of off the top of my head. Another idea: 5. Distributed Poudriere. I have a few systems that would benefit from such a feature. For example, two ThunderX1 systems. And once I resurrect our partially-dead ThunderX2 system, we'll have three arm64 appliances in which we can build packages. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --pk5z2zp5esjxce4d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGer0IACgkQ/y5nonf4 4frvqw//QrotsoswRAWfKi7eOTD7rFi7Pz4S6ML055SN7PYBMHNUbxLqVPDXFXch /UXWAmQF8DFKQ6j3OCnkEzdYO8mHPnH90QuaYNIy3JMH+x9SbXf0GDR1JiRPfUWS uAkoGucCJI3QACHS2o9J8hcTRSdshTdCLeGNci/O2XLlE0KSA3PlK/0BmzZZL3Ze yiST578N9flAds4C9g5lUm90aXcFs3Xuc78+nplfMxW4h/CG0UMWIRRlLikSrqWr 0V/jQYFIFcTScsDC0/Tx9+JtmhWi4LokSvCXkILlf25nNYdgMYnS/teiN1N6koaS wHyxTk/NTYRciSweRLoT6SK0cnmzOlbFU+LUHOV0dYkLNndLv9GuBU1JJ5b0boXu +5rogqZkxwh4VTd9UXMssboUFvxjPHX2o7FS+BuQoqhXf0VU/Z95/5Zfn3YHA7Ou +W9qgFcW8x9/OxqfX5LhQR93xqAC+ygSucEazAa7ZvBV0q9TnAtpwk3e6dNWZ1fI WRDg8ubFPn6enH82VQ7MbFx41OoesocPGozMIuEWdDi+FOfYbl03cVFuRWkikMtE je4HMCd1p7a3qDLeYyGgdNHGoAqSwq3yYU6ZXO1SNZi2q78rDbCV2Ts9MkzBoB6U 8iLF0nccqQjetIzEv5+i2uWwDHteesrDZJgnBBnJXuFXV4H/fRk= =CXhL -----END PGP SIGNATURE----- --pk5z2zp5esjxce4d-- From nobody Wed Nov 24 21:33:50 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A6A3418AC093 for ; Wed, 24 Nov 2021 21:33:50 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 4HzvQQ3qh8z4SFS; Wed, 24 Nov 2021 21:33:50 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id a18so6872636wrn.6; Wed, 24 Nov 2021 13:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=teEkwLSEf5kMv7h5XuDvqZ1bwNPIFiRMQXrmzajYfJM=; b=ElzdGcmd7Ym0avQWDvN7GUV0Jm9QShYb2QRXky2alAjmm17KaO3dxB/SsLewNdjBqq pYCRD8gDZCkqjfG3E5OuKZ3Rr6PUhCSQDYvVM/PE49rbLmW31MK4Lkr38B6ESw2s8CQd BYBN3eDIZWngIPdvHa4s6DRoWUBzg0KbWXezYiEdEV9ClSfiL6yJxdYapp5qgcH0MAM9 ObyVBakBIjcnqHuzFkVJssxA4XdE5WaAZd2gkMgY/IHBo9mhuuxYTnMsz420Yyld9sbT HE+m1XA2hE9tJQVtOJNY98sRoilGeunRn9bfrJuF1RzKp5JDHNRo+DeNCtQQKbremrK3 Oxtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=teEkwLSEf5kMv7h5XuDvqZ1bwNPIFiRMQXrmzajYfJM=; b=dMAc6jeUQpl5UGSH0GOljY8b4Ed+RwAEXcSRtduhpL5P2cKHSI+bxD6/GZgpvTSRqz 840DZLsrnCABY5tFb2OQzcFzy4QHcsAQn0bJXi7hyCW3/DU+cdS/umgM6PQjYDhLljG1 eFvSmxnjd6pBRphrUXaNDDSlKoHdYr/GDyoSNUfB+hvPJTYyGwAFcZeLQmT7Fr48kV1z 7DY8VC+zDS2yS2BLyKI53qZZ2TIoKjkigNVmrsQ2C6NsyIIc8YRvSmtL5guMXP3OTd6M Bpp2twT4npZleZtHydI3T1PTQbaz8w+uHGdq1VysfN8NLZ/Kf3kxtOtTjATEPgKjOitj Qy9w== X-Gm-Message-State: AOAM5335vMAZOk/79L9EsG77iTWzQmjhW0H4OC+2tRVjdDDO7XE6YsMr 6mQFt/kUS2RvFqjlDyfrSvoA2XeeSAKW6Q== X-Google-Smtp-Source: ABdhPJzvhG2uSW9admCSmCtzWycrNtA/y7e76YGE8GzjRdEkQf1RfzFXvNx/TbQenuNd04FK155Ofg== X-Received: by 2002:adf:b35d:: with SMTP id k29mr228899wrd.466.1637789628416; Wed, 24 Nov 2021 13:33:48 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id l2sm6931826wmq.42.2021.11.24.13.33.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 13:33:47 -0800 (PST) Message-ID: <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> Date: Wed, 24 Nov 2021 21:33:50 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Top posting (was: Call for Foundation-supported Project Ideas) Content-Language: en-GB To: FreeBSD Hackers Cc: Joseph Mingrone , Mehmet Erol Sanliturk References: <861r36xzpe.fsf@phe.ftfl.ca> From: Graham Perrin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HzvQQ3qh8z4SFS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: > Change policy about discouraging top posting and convert it to encouraging > top posting Please, don't. From nobody Wed Nov 24 21:44:16 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8C6F01893B73 for ; Wed, 24 Nov 2021 21:44:36 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzvfr3P66z4XhR; Wed, 24 Nov 2021 21:44:36 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-qt1-f169.google.com with SMTP id t11so4185619qtw.3; Wed, 24 Nov 2021 13:44:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0AAXRP0Rfu731wbKnAN/ZA4nXtV8bP3d+PWFyW5XXpc=; b=vcMIIa6rGNOcfoNFwPlxTFpdsJoeEXX0xn/kOxKaDqHL9QpFDRdVhnwpezQQG4g1vs l0Ar77uJ7PhAtPstJux4BF1mCMGjFcUkF2c7FmXqaadB6D7nEN542PSDt9qf8KvaPdX2 /V5EI24pWN65fW0u7VFCGuHmzO6o3TTuXT4HxvJ5ds2huwqM1B8waU+Ue6QblVpSeqoY DmKiGJgwiIFIQr5lTQzK/w4NF/HqF/SRtlPRYoLReA6O+ahuwzLLKbuJ87E1GhohsXb7 ftXksvCqPr5wRnZiZPZKOjYNSjCoaB+XhA7SKu8z1thxGl3/mJb8FbYeQE3+PBgmnOtf +LqA== X-Gm-Message-State: AOAM533zbNIBGLGOTUjH//XFXqra4lWo9rTmWxA4g0xmWzH45ka+xnZ7 dSL7/KNQAo7ZCPwbpncnSTpVBHab3n8= X-Google-Smtp-Source: ABdhPJzaQDQY39WesNSuGnORD8qyEhKK1gJEP8uJdTMCu4bMgUjlmOFJ1+IClCQo38HygdNaaM0lnw== X-Received: by 2002:ac8:7044:: with SMTP id y4mr11300111qtm.64.1637790270214; Wed, 24 Nov 2021 13:44:30 -0800 (PST) Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com. [209.85.222.178]) by smtp.gmail.com with ESMTPSA id w9sm479890qko.71.2021.11.24.13.44.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 13:44:29 -0800 (PST) Received: by mail-qk1-f178.google.com with SMTP id d2so5263248qki.12; Wed, 24 Nov 2021 13:44:29 -0800 (PST) X-Received: by 2002:a5b:d41:: with SMTP id f1mr218711ybr.447.1637790269562; Wed, 24 Nov 2021 13:44:29 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> <20211124213150.6lsyaqgwbkgfcgzi@mutt-hbsd> In-Reply-To: <20211124213150.6lsyaqgwbkgfcgzi@mutt-hbsd> From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Wed, 24 Nov 2021 22:44:16 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Shawn Webb Cc: Joseph Mingrone , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000003be5e605d18fc388" X-Rspamd-Queue-Id: 4Hzvfr3P66z4XhR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --0000000000003be5e605d18fc388 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El mi=C3=A9., 24 nov. 2021 22:32, Shawn Webb escribi=C3=B3: > On Tue, Nov 23, 2021 at 06:28:14PM -0500, Shawn Webb wrote: > > On Tue, Nov 23, 2021 at 06:41:01PM -0400, Joseph Mingrone wrote: > > > Hello FreeBSD community, > > > > > > The Foundation is seeking suggestions for new projects to support. > What > > > gaps in the Project are not being addressed by the broader community? > > > > > > You can read about past Foundation-supported projects at > > > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > > > four main areas of focus in the 'Technology Roadmap' article at > > > https://freebsdfoundation.org/blog/technology-roadmap/. > > > > > > Right now we are gathering ideas. We will send out a call for projec= t > > > grant proposals soon. If you prefer to send your project ideas > directly > > > to the Foundation, we will be monitoring responses at > > > techteam@freebsdfoundation.org. > > > > Hey Joseph, > > > > Thanks for sending this out! > > > > Here's just a few things I'd love to see: > > > > 1. wireless mesh support. this would go _a long_ ways for supporting > > human rights efforts. > > 2. 100% llvm toolchain for base and ports. freebsd seems to already be > > going in this direction. > > 3. jail orchestration in base. it's great that we have all these > > disparate jail management ports, but we lack a fully > > coherent/integreated solution. I'd love to see jail orchestration > > get the same love as zfs in base. > > 4. tor browser bundle (port from openbsd?) > > > > That's at least what I can think of off the top of my head. > > Another idea: > > 5. Distributed Poudriere. I have a few systems that would benefit from > such a feature. For example, two ThunderX1 systems. And once I > resurrect our partially-dead ThunderX2 system, we'll have three > arm64 appliances in which we can build packages. > Package seeding in poudriere > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > --0000000000003be5e605d18fc388-- From nobody Wed Nov 24 21:44:55 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6A1571893E37 for ; Wed, 24 Nov 2021 21:45:05 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.6]) (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 4HzvgN3T34z4YYL for ; Wed, 24 Nov 2021 21:45:04 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 08F6A2FD2D for ; Wed, 24 Nov 2021 21:44:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 08F6A2FD2D Message-ID: Date: Wed, 24 Nov 2021 16:44:55 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> From: Allan Jude In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HzvgN3T34z4YYL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.51.186.6 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-1.96 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.14)[0.143]; 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:6939, ipnet:209.51.160.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/23/2021 9:01 PM, Miroslav Lachman wrote: > On 23/11/2021 23:41, Joseph Mingrone wrote: >> Hello FreeBSD community, >> >> The Foundation is seeking suggestions for new projects to support.  What >> gaps in the Project are not being addressed by the broader community? >> >> You can read about past Foundation-supported projects at >> https://freebsdfoundation.org/our-work/projects/ and the Foundation's >> four main areas of focus in the 'Technology Roadmap' article at >> https://freebsdfoundation.org/blog/technology-roadmap/. >> >> Right now we are gathering ideas.  We will send out a call for project >> grant proposals soon.  If you prefer to send your project ideas directly >> to the Foundation, we will be monitoring responses at >> techteam@freebsdfoundation.org. > > I would really like to see Foundation sponsored project to bring SMBv2 > and SMBv3 support in to smbfs in base instead of deprecating smbfs / CIFS. > > FreeBSD is the only one widely used operating system lacking support for > modern SMB / CIFS versions. SMB is still widely used in desktops and > servers environment for mounting shares between different OSes. > > The latest thread from October with this discussion can be found in > freebsd-current@ archive > https://lists.freebsd.org/archives/freebsd-current/2021-October/000893.html > And continuing in November > https://lists.freebsd.org/archives/freebsd-current/2021-November/000915.html > > > Kind regards > Miroslav Lachman > Ed Maste and I looked at this a bit a few weeks ago, and it seems there is a version in IllumOS that is based on the old smbfs that is in FreeBSD, and it might be an "relatively" easy path forward. Just need someone with the interest, time, and background knowledge to actually work on it. -- Allan Jude From nobody Wed Nov 24 21:46:26 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B02AD1894B42 for ; Wed, 24 Nov 2021 21:46:28 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.6]) (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 4Hzvj00Whqz4ZY4 for ; Wed, 24 Nov 2021 21:46:28 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id D6BB52FB47 for ; Wed, 24 Nov 2021 21:46:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net D6BB52FB47 Message-ID: <246adde5-6a7a-4102-abb4-16c766ea78d1@freebsd.org> Date: Wed, 24 Nov 2021 16:46:26 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> From: Allan Jude In-Reply-To: <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Hzvj00Whqz4ZY4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.51.186.6 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-1.89 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.21)[0.208]; 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:6939, ipnet:209.51.160.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/24/2021 2:42 AM, Dave Cottlehuber wrote: > On Tue, 23 Nov 2021, at 22:41, Joseph Mingrone wrote: >> Hello FreeBSD community, >> >> The Foundation is seeking suggestions for new projects to support. What >> gaps in the Project are not being addressed by the broader community? >> >> You can read about past Foundation-supported projects at >> https://freebsdfoundation.org/our-work/projects/ and the Foundation's >> four main areas of focus in the 'Technology Roadmap' article at >> https://freebsdfoundation.org/blog/technology-roadmap/. >> >> Right now we are gathering ideas. We will send out a call for project >> grant proposals soon. If you prefer to send your project ideas directly >> to the Foundation, we will be monitoring responses at >> techteam@freebsdfoundation.org. >> >> -- >> Joe (with Foundation hat on) > > Some new ideas. > > 1. updated kmod ports for point releases. > > we should be able to ship an x+1 RELEASE *and* have the appropriate kmod ports available at the same time. I know that unplanned API breakage is rare, but when it does happen, its absolutely brutal for end users. > > 2. a decent ports CI > > At least for committers, and for regular maintainers, we should be able to have some common-sense pre-commit build checks done at least on tier 1 architectures easily without human intervention. > > 3. jail creation and usage as non-root > > nuff said. > > 4. more programmable/scriptable configs > > I would love to see FreeBSD be the programmable server environment. > > - libxo all the things > - more stuff like libifconfig libpf libzfs -- "lib-ify" all the things > - UCL all the things > > A+ > Dave > I was discussing the idea of 'user jails' with a few people around EuroBSDcon. Do you have some specific user cases, and/or ideas of what would be allowed and not allowed? -- Allan Jude From nobody Wed Nov 24 22:21:28 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AC9F918A93CE for ; Wed, 24 Nov 2021 22:22:05 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzwV53lQNz4mPR; Wed, 24 Nov 2021 22:22:05 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ua1-x930.google.com with SMTP id o1so8262451uap.4; Wed, 24 Nov 2021 14:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eOni+WxGAjmgxjfAYGkkik6bEyp6z5i8bVkSgkp+v98=; b=J+FfkUS31mEKgmLUMK6+qI/1GXYUct3Lcjj9qjZxskMgzgIH7LVPCtIZ5/iOGZnoSG PhwL3jh9DDZ49m8odRloOkgk62DcYWzCqq3PEGxnsxygpVRUUlmfPdzGZ/ysOyFuDBBD Yc1Qgltm8QWGKNbfz9t+nRD33CAJcmTpMrH61ukzZYqrziVhwbFv7A5wdxTP5g4/+FBn 1JWYMYf+b9RdD6Wn0Je2LUi7VWwmfSNz5bTkqQ9SHiy+kp7Oeth8TniFRMAdIsjtLRi6 KLqeav8YBueqp7uQgGC7NKxnjIytRUoxSkUTIJZjdVfnSw/xCswBqMSvXNakST5IiAc3 Jetw== 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=eOni+WxGAjmgxjfAYGkkik6bEyp6z5i8bVkSgkp+v98=; b=HZly7HoR30E+5+mVuLnaFDq031p0sXvDDks4ujaoDNY6+57qOT7+ZXzjPK7qlHfzdR 8geDzYsEmAzcSua1BypKqtX04LF5VN+qmDSMYFEtJY4Z301EZ+u4gl3kCY/s1j441yFl 3VqIXBK1VWQdeJGRoOzOCqTGfOpGESzcpqQCHznMAoMS5XKzXOIwdKR36nqFlBVjIGW+ dQrFDpPAbfVdZGc0IRC9lF07C0I+RdbCz22K3mgSC703UGUZzMr8th87jfqMAPYHSP84 Rlo+MuDcV3+Dadxa7dxHJkJWLmmaUMAKVtu8o+EAEClTw0DmPlFedovsyoTtQ2Sr9SU9 YSpg== X-Gm-Message-State: AOAM533Z9eZ8OGU4/KLMqcMZeCuiJ6iEgZzc8kqNamdgAB/2OZYTVMBJ qrqWhp9mm0oGze4qiJi2QXWqk3kwWUV58kN8oo05bkychho= X-Google-Smtp-Source: ABdhPJyqvs/w8cpNjXmAjEnoHhNqZqJiXDiN7VS9b/CxkRRnNn7fdj5rihFxfuXs6QYnNmpx2MOeoHRqCxdgZ52g4YY= X-Received: by 2002:a05:6102:e46:: with SMTP id p6mr958522vst.33.1637792525142; Wed, 24 Nov 2021 14:22:05 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> In-Reply-To: <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> From: Mehmet Erol Sanliturk Date: Thu, 25 Nov 2021 01:21:28 +0300 Message-ID: Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) To: Graham Perrin Cc: FreeBSD Hackers , Joseph Mingrone Content-Type: multipart/alternative; boundary="000000000000ad4e8b05d1904989" X-Rspamd-Queue-Id: 4HzwV53lQNz4mPR 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 --000000000000ad4e8b05d1904989 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 25, 2021 at 12:33 AM Graham Perrin wrote: > On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: > > Change policy about discouraging top posting and convert it to > encouraging > > top posting > > Please, don't. > > As I said , (1) persons tracking messages continuously do not need to read the same texts many times (2) persons tracking messages continuously are forced to move the cursor at the end of long messages . This is taking unnecessarily long times which is a waste of time and difficult in cell phones (3) if links to the previous messages are used , it is not important to place of the current message (4) I am a subscriber of many mailing lists . Most of them are using top posting . FreeBSD convention is only an annoyance for persons continuously reading messages ( some may think in a different way , obviously we will welcome their ideas ) . Bottom posting is a reward to the persons occasionally reading the messages , a punishment to the persons continuously reading messages . This is not a fair behavior toward the interested persons to FreeBSD issues (5) My proposal is not only allowing a change of policy , but including links of the messages into messages , allowing use of these links and then changing message posting policy . This does not make a significant change , because readers will be able to see previous messages by only clicking its link when it is supplied by the neww message . Therefore , insisting on historically used conventions which are not useful in these days will not supply any benefit to the FreeBSD other than lowering the number of interested users , causing not participating in its components such as mailing lists . Thank you very much . Mehmet Erol Sanliturk --000000000000ad4e8b05d1904989-- From nobody Wed Nov 24 22:28:24 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 240B718AB56D for ; Wed, 24 Nov 2021 22:28:23 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 4HzwdM0Dlzz4pFs; Wed, 24 Nov 2021 22:28:23 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x332.google.com with SMTP id 133so3893915wme.0; Wed, 24 Nov 2021 14:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=V0zf0DX8+vh9zk59EPYLlDjHRgATfWgnPLsx6jq6uII=; b=ITg2z4xfxAx2L/r5VmZdoadsQ1xyjrskm72ROkTWeG9D3iaNIFRgnjH1fzi407WBD8 T0ncYk+qyUBmq9R5Ny/TF/nNoCAfgLaXS+zytrhug54Bfd2ZGDI9BsZ8txURAr1m+RAR trseILocjROpZ4JRfgidKtUSUkMdI4knb+FbRpj4f1vcN9TTNNNUOLIYL1Nrxg2FkIEW 5Cho0NqSwmBbpPon4wBE5GkGnL1mWB9GUTgg2EiQ5XE/CBPX1Ap7FBKZTP5Y6D2KuRAy 56hiwKujiXX0COrgHdKJsK74WSsawJm9CbbqN6TFZ7cLmA+j6bvwFtTRE3q/DlYyFstd CT/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=V0zf0DX8+vh9zk59EPYLlDjHRgATfWgnPLsx6jq6uII=; b=nvJ0OnTvP+IdpjDE2YgA0ZvfZSe5/Tza9w991MQyFz2cx4/1Vf9foFONGqBaZAnB5H ObzuSvh360ou8NEs1vrMk2yep8ScrlksOTWE6UupUDmA/elqWq5zAPbc36kc4XF+ne8U 1pnZTRe3sP4eqwvayH9vrD8gFh67EFC8TDUW/dn8WhWZaGmMxaOBXFYUXBuA+msku2Ex j7KCwsdZ7xTmQmv2G6y7rOxt76Fc37dDOyuiHsY6RAlZdDIuOB/2seMrgMPde1UGSo3y hWO6Aabh5g8JscENnz8pz7EJaiv/i/tu05WnmXADN0OOHkEzcGegOVnENrHHzxeU8lLU tFLg== X-Gm-Message-State: AOAM533FmNkst6Q6q7p/HFcSe7yDjrrXJZcCEWDR/4DfIMX/2wjc0YJ+ Qd9d8snl0xE0VBwLQlvCqjQ= X-Google-Smtp-Source: ABdhPJyo/kRGAiFkWCtbfG4RB+kVVgzUWCVxpuFZeX8PnH8D+ckF5qgLTDILGY/eySs5l0xI2D0dvQ== X-Received: by 2002:a7b:ca4c:: with SMTP id m12mr567175wml.119.1637792902119; Wed, 24 Nov 2021 14:28:22 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id d7sm969373wrw.87.2021.11.24.14.28.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 14:28:21 -0800 (PST) Message-ID: Date: Wed, 24 Nov 2021 22:28:24 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Top posting Content-Language: en-GB To: Mehmet Erol Sanliturk Cc: FreeBSD Hackers , Joseph Mingrone References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> From: Graham Perrin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HzwdM0Dlzz4pFs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 24/11/2021 22:21, Mehmet Erol Sanliturk wrote: > not useful in these days I respectfully disagree. Bottom posting is preferable for a variety of reasons, not least: order. I find things unnecessarily difficult to digest when they're disorderly/jagged. From nobody Wed Nov 24 22:45:36 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A9CA18B529E for ; Wed, 24 Nov 2021 22:46:12 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzx1w3XP1z3C7g; Wed, 24 Nov 2021 22:46:12 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ua1-x92f.google.com with SMTP id n6so8419364uak.1; Wed, 24 Nov 2021 14:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C4UDnhft4gdqfrsmyJiVBuj48+V/YSw/s8gSA7F26D0=; b=og3mtB9whxKJE1VhOi15JtEJu1V450lgzsF9nhquWIjk6O8DSBxMhsWF3c1ljRKINe jAQG5EWBESgGny9+Esrt0FToE4mHwoo9YqVyGtULHKNUWptukHZgQG9YQfWfKG5RQcvE r5t1KVDSjbJ2au3SI69I4PawYw7/OKEGhg9xZtqM1xuFwldiNwOH4/MdwP5qr4FGILBQ zydOzaM6exZTdXBAMjdDvra/KfTutpY3VnCpa0L2YabCd61L29SY7RXX6ybK6hz2QC11 Fn9FFsLP7abIUCnfjff7mYOo7kUk9KZPKzfUBVOZhLxZCH4w9vLV4XPID0CYQb6LpV7U D2UQ== 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=C4UDnhft4gdqfrsmyJiVBuj48+V/YSw/s8gSA7F26D0=; b=QR5UXZX8CK1CsbLRPB/vR/CCOj8vPBLimQkh6nweu1AUNBEFJ8H3VaSGNdHalO93Rt vkChgTQ5BiiMl11KshhTxXB70KzcaVMivizN/n1X/hKamEc0oQXYV9sxXLiZhMaliwO3 YA4OCBydDXEwjRi97o6gPmxv31yBjpAQ+aeZG2tk6PZgCXdkkPcupX69FzO52NtAgNhQ QbNCZOKYbtgAOONzkRsMQQLPqKPlUG/9IX/F4pfwqcbftmK5pVN08YsRxbL1y6pn5eL8 CilSvmXdt6ZNNjRGdlqp7QziDSHkNQGRnPGWP7s9pajxicn4Mywx9/sZw2KEGz4Et0Ut LO0A== X-Gm-Message-State: AOAM531wWZ5R4ksIyDSUPJa3DlCzGzdkM6A+dIw4AM7zOq9qtQEllsxz M43vCB8stUZ+UT9yxAk3z+pY/CVZL5BAUmH6MK8= X-Google-Smtp-Source: ABdhPJzmZcsXhxxbmLO18ah3Ero1iFPKdFcmYjg2C20a/si27LveYGEB7LHXEZKuaN6qCuKPtEN5xsXE0bnMFXvxZjg= X-Received: by 2002:a67:c79a:: with SMTP id t26mr1261063vsk.37.1637793972069; Wed, 24 Nov 2021 14:46:12 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> In-Reply-To: From: Mehmet Erol Sanliturk Date: Thu, 25 Nov 2021 01:45:36 +0300 Message-ID: Subject: Re: Top posting To: Graham Perrin Cc: FreeBSD Hackers , Joseph Mingrone Content-Type: multipart/alternative; boundary="000000000000ebab2d05d1909f7d" X-Rspamd-Queue-Id: 4Hzx1w3XP1z3C7g X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --000000000000ebab2d05d1909f7d Content-Type: text/plain; charset="UTF-8" https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000404.html https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000423.html https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000427.html https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000428.html My suggestion is this . On Thu, Nov 25, 2021 at 1:28 AM Graham Perrin wrote: > On 24/11/2021 22:21, Mehmet Erol Sanliturk wrote: > > not useful in these days > > I respectfully disagree. > > Bottom posting is preferable for a variety of reasons, not least: order. > > I find things unnecessarily difficult to digest when they're > disorderly/jagged. > > --000000000000ebab2d05d1909f7d-- From nobody Wed Nov 24 22:46:16 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A4AD718B53C7 for ; Wed, 24 Nov 2021 22:46:28 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 4Hzx2D3vK2z3CC5; Wed, 24 Nov 2021 22:46:28 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd29.google.com with SMTP id x6so5120180iol.13; Wed, 24 Nov 2021 14:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uUVmztGxF655ZWuiM14kdq/Idf/RcTn+vyYcZiriD4s=; b=nzLXN04M4X6i+gBJ7eyQwS2iNODHGpkFxxq+PTrCkvHwJns8/WTvdWG2E0mPpNXazc 7GGqfxEiYBr3plTSERLO1GoaW92jZR0yJFTzseG4CA1pvueGzf/9oHFgNcZj9c1SK/ee CXMLl2p4WypvJY96eRrWT5x6IpjDjGq6FgldeWJ2oAnM/vYdWpvGymAPXywAAzgRl2vE yOkghQTFqeU1x73OQZ///ppXWj7ZdW3wx/S1fqqrGPUuB020nny8O8fxY1CNyPr1Ag9/ W02iPzcSMcLBhWTtAQ3lCNda/eWUPAp9AD4V7paxJwOMVm7UXJzupTAODzNC92MB0Z5u nICg== 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=uUVmztGxF655ZWuiM14kdq/Idf/RcTn+vyYcZiriD4s=; b=3VyQq5KhE9wK190jkp1kKeL46uZbxbWnDekMkq6FWbGEjuJjzmIbuEwOs5WCG8aOi1 4JuU1wGDJMiC8mcr6ou1yE7VQgw6BugsyH0bv9QjUFrWHRnHuIeUDYPmeUCMbh5whcbm xJ4ZBTUtSBYc82RrVROuXw6Nx3AOAn6m3BnRe5VtrlP2NKrswvkq8WxQFQDNS6mszk3E GTlFvGL3jzZQdHQm1INr5ELF+CpKxYGrOUTA+TCN1HC26P/bdi8l5/z26P7YFmQqlEvo m/D+mMXLgZSla9f/9eopAtXXIH5uuOd0cdyhYRnbUg6k7qFZNdRQuIs70YgJnlTjVE7G 365Q== X-Gm-Message-State: AOAM532I/YG96LHbF5pLD0cNejtSbAbXqS5EygjpUwXG9Onmg8a79v0/ r1HekNOI/DwEy/6xPYefYRNMHHPtKnkhgw10ZOydVTP7SfVMrQ== X-Google-Smtp-Source: ABdhPJwevs5KnclSL3umCbATmpNR5PT5EzwMWHLx6kL+Req+YV+ZCHO/bdbduVqyP8JrZ8AoO9sDuA/hIFVmg3k1EjU= X-Received: by 2002:a05:6638:300a:: with SMTP id r10mr3303902jak.91.1637793987770; Wed, 24 Nov 2021 14:46:27 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> In-Reply-To: From: Michael Schuster Date: Wed, 24 Nov 2021 23:46:16 +0100 Message-ID: Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) To: Mehmet Erol Sanliturk Cc: Graham Perrin , FreeBSD Hackers , Joseph Mingrone Content-Type: multipart/alternative; boundary="000000000000db3cc605d190a0a9" X-Rspamd-Queue-Id: 4Hzx2D3vK2z3CC5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000db3cc605d190a0a9 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 24, 2021, 23:23 Mehmet Erol Sanliturk wrote: > On Thu, Nov 25, 2021 at 12:33 AM Graham Perrin > wrote: > > > On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: > > > Change policy about discouraging top posting and convert it to > > encouraging > > > top posting > > > > Please, don't. > > > > > As I said , > > (1) persons tracking messages continuously do not need to read the same > texts many times > [ plus more explanation....] One part you're forgetting is trimming what you're quoting to avoid exactly what you're pointing out. (4) I am a subscriber of many mailing lists . This is precisely where in my opinion bottom posting shines: if done properly, I have context immediately without having to first scroll past the new message and then back up. I find it much more natural than top posting. Regards Michael > > --000000000000db3cc605d190a0a9-- From nobody Wed Nov 24 23:02:56 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D1542188E9D7 for ; Wed, 24 Nov 2021 23:02:56 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzxPC4cywz3KLc for ; Wed, 24 Nov 2021 23:02:55 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id d24so7361280wra.0 for ; Wed, 24 Nov 2021 15:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=T3oPZPQq8GGeKlMIZ4eis9H0DDSVSdDGHFpKJsnwCUk=; b=PsDV0aszVtDgERbG4yrGsqQ/CoC+BvbfABB0WiSAVlWDtVK+lx+g5suAr2aZQTI0aU bA92/vQ7k54atPhPw8IATjwUVf+fG/NGQk85ZL43MAusGK33vxSpTh4pbL62gfCUBKZH r544DoQ7041jg2/psE8ATlCU53TmrQlRma53v573tmas+jKyuDi8C6iaeftndTUmqmbh oVJUCOiNEqnneVoYzBet/+OLEfQTTrPhLvPE9JGEPJom2eNEEMWhhezj3qxRz0IDx37c aditRPOwJ2W6Nn853sZ+ScM+HW3jByHO5siOGe8LNstYCML7VmwXF4GKfLASmijbKUwd dUDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=T3oPZPQq8GGeKlMIZ4eis9H0DDSVSdDGHFpKJsnwCUk=; b=g0aNcoRQzK2oiS5DuYBNJW2cZgZNP+h1TamF4Ecgvt4VVh26IZAypgwWuM8HBq4nTz yThsvWWGa0be7gNZ69Jahb98NZ9Mcrm4vBegGBJznHrwRPQyx2UA7jHqruUlFOebrQlG lG/r8rg9BNxJkygmNuB/YZHpLyqKmAo5QbV551Fcab0468QWIynidZRUL/yVeLzUWQYN YUOXkBPEMZ97ImRjcu2W+HTtHZ4J7AKtoLckJxGGqbR/6DSQOnatPEl5kogLIygNeQyd y5SJxpt9G3uuXqFoFilZo12jiIJaSUXnvZguV+S0vcqiBO4K9vWuOM0ROn9lT6OXG5q8 HBRQ== X-Gm-Message-State: AOAM530/p5bh5ZhWsbUbwXB0L1gaEeovQvIMjheHXrRH2N8T9D0INoMb 96U2oVjv1kCvyqJkIHVdX43j3wEWJEaxFw== X-Google-Smtp-Source: ABdhPJz1XGShvyfnslfI26gjKCVrofgmMsWjq8dJikizxXsANHFbRJZCmgOtzyAvKqIXwKoFgViDFQ== X-Received: by 2002:a5d:58fb:: with SMTP id f27mr1054776wrd.10.1637794974023; Wed, 24 Nov 2021 15:02:54 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id o4sm7291824wmq.31.2021.11.24.15.02.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 15:02:53 -0800 (PST) Content-Type: multipart/alternative; boundary="------------esqywocPf0B1nsjyVpZsYyYM" Message-ID: <7159a539-d578-aebf-504c-a9741900196f@gmail.com> Date: Wed, 24 Nov 2021 23:02:56 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Top posting Content-Language: en-GB To: FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> From: Graham Perrin In-Reply-To: X-Rspamd-Queue-Id: 4HzxPC4cywz3KLc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=PsDV0asz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::436 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::436:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --------------esqywocPf0B1nsjyVpZsYyYM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 24/11/2021 22:46, Michael Schuster wrote: > … trimming what you're quoting … +1 Trim/abbreviate (…), but not so much that there's _no_ at-a-glance context. > > (4) I am a subscriber of many mailing lists . > > > This is precisely where in my opinion bottom posting shines: if done > properly, I have context immediately without having to first scroll > past the new message and then back up. I find it much more natural > than top posting. I, too, subscribe to many lists. The bottom posting convention is always greatly appreciated. --------------esqywocPf0B1nsjyVpZsYyYM-- From nobody Wed Nov 24 23:05:05 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 741EE189135A for ; Wed, 24 Nov 2021 23:05:04 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4HzxRg59Rvz3MD8 for ; Wed, 24 Nov 2021 23:05:03 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id u18so7286965wrg.5 for ; Wed, 24 Nov 2021 15:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=cUCP6V81ye5gyb2WAUMForLYK39LvK3xGyOpoEbu4c4=; b=W9ZLEX9/DhnlbMptaSfdQqS2UmHKvlBbghEwEiYtFu3pF0enNLeOoAOVTs7PROFO7m tDi3q91elurBhCLoZcLkodK576gIOg07wEtKejY/o3qFlGCqdlcRdaU+ItVQ3sc1PsUL qVZ9kbwa3uK4GVPYhQ6Dmhq/8tSyiLrMn+amNi3OnQG+prlQVfLpXROMDVFsTWHiDKgx Ea9xDiOgBfbZ/42FJvsbhLFiYiZGXPer9p1AfX1lDRJPsb+BhwRkOlfv3KfNVevyNLU1 D05EoWssXBVTlgPB4Kcv1lFKPcsSRbR5r0kmnhJFGqqWjQtnZlKI8iwvMOHfE9H/wV9m FzrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=cUCP6V81ye5gyb2WAUMForLYK39LvK3xGyOpoEbu4c4=; b=N8o3ZdcziB2w8QXgPBy33imiEXOeta/pvtQD/hPDd4dVrnY7DeDuYfem9HrhmqmnpR apyRdiZ9zgbFaL6X3J9WW4+smpKeoUb1YB+E20G4To0f0ta/GrBT1jnNV2zIAEJNLp+k ZRmZT96Tp8zeWPWqwcECJacXhqQQ/mp8nFNU+sz/JgCbeZcS1fA8yHANVY4eBPlori+F 0Pv16vtymGHyTYP5kGNLR9aJ3ARa9ZlfuWoSDPbwgxSmYVqCkIYC0Op05ShnmBhRAiPG 9p1HbI6SbCkSh32+K8kyQnKYhPvtkRplDIqxJYKbNxPtYQ233AeG7EHuONCwU5LaAQfh saLg== X-Gm-Message-State: AOAM5335FNVISsGxtKmaju/adLljEXdrf4dRv8EnWlvp99gt+CkkAtTE 69pXPFl1rhQg1pY1519V9QY1MiZGQX6UZA== X-Google-Smtp-Source: ABdhPJw71/WfnXdOEIXOasTXRKS8ZtxKUSwDSLDNONLnQS4BU9pGyJdJeLykRbNgFKuI2bnNj71CwQ== X-Received: by 2002:adf:f209:: with SMTP id p9mr921789wro.191.1637795102551; Wed, 24 Nov 2021 15:05:02 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id a1sm1465866wri.89.2021.11.24.15.05.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 15:05:02 -0800 (PST) Content-Type: multipart/alternative; boundary="------------JtOXMbwbRvWMOl3yoqH216Z3" Message-ID: Date: Wed, 24 Nov 2021 23:05:05 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Top posting and linking Content-Language: en-GB To: FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> From: Graham Perrin In-Reply-To: X-Rspamd-Queue-Id: 4HzxRg59Rvz3MD8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --------------JtOXMbwbRvWMOl3yoqH216Z3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 24/11/2021 22:45, Mehmet Erol Sanliturk wrote: > > > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000404.html > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000423.html > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000427.html > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000428.html > > > My suggestion is this . Too terse. There's _no_ at-a-glance context; it's necessary to step _away_ from what's currently on screen, to discover the linked content. > On Thu, Nov 25, 2021 at 1:28 AM Graham Perrin > wrote: > > On 24/11/2021 22:21, Mehmet Erol Sanliturk wrote: > > not useful in these days > > I respectfully disagree. > > Bottom posting is preferable for a variety of reasons, not least: > order. > > I find things unnecessarily difficult to digest when they're > disorderly/jagged. > --------------JtOXMbwbRvWMOl3yoqH216Z3-- From nobody Wed Nov 24 23:33:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3FC8218A221C for ; Wed, 24 Nov 2021 23:33:19 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from cameronkatri.com (cameronkatri.com [206.189.178.249]) (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 4Hzy4H10scz3nWD for ; Wed, 24 Nov 2021 23:33:19 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from FreeBSDY540 (c-73-84-80-103.hsd1.fl.comcast.net [73.84.80.103]) by cameronkatri.com (Postfix) with ESMTPSA id 340A0414B5 for ; Wed, 24 Nov 2021 18:33:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cameronkatri.com; s=20201109; t=1637796798; 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=VM2ICBhq/Ye25lsz4GqSz4A8yvLTzmLQ1fhbUmC63Rc=; b=SIiTVgUiEtIb+Wlr/X4NpRCreWwDzJviYc9k+MfkWAExUQHCmgoLOKK2IBY0aGrYQcKRWB ktFTv6cQNJQHnRNUNRORd8uTcLL7FTrJpuSKgEulNlOaLpgufNTZVO0qzWxyUhiRo+YZCb YynoTx6ghyimO5FQAkQ73X5gmRrRr+0= Date: Wed, 24 Nov 2021 18:33:17 -0500 To: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211124233317.auv5zyymefujmwxz@FreeBSDY540> References: <861r36xzpe.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e4pjaohho3vuc4bm" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Hzy4H10scz3nWD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: me@cameronkatri.com From: Cameron Katri via freebsd-hackers X-Original-From: Cameron Katri X-ThisMailContainsUnwantedMimeParts: N --e4pjaohho3vuc4bm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2021 at 04:31:27AM +0300, Mehmet Erol Sanliturk wrote: > With the new cell phones , it is difficult to slide to the end of the > displayed mailing list messages . I follow the mailing lists on my iPhone and bottom posting is much better. Being able to see what they are responding too right away is so useful when I start reading the the middle of a thread. You should also be trimming out parts that you aren't replying to, so that the entire email is shorter and not just repeating the original message. --=20 Cameron Katri Email: me@cameronkatri.com PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C --e4pjaohho3vuc4bm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEfTs2zqQPzCGB+23Nuv/ZeCZUDxwFAmGey7wACgkQuv/ZeCZU Dxz8Wgf/dgtbDV6bnNXmvsM5/xYUNY8gipAM+nwbS5kYdw4LTpK/QqHamy23yhxp CQ6PcK9O4y6wnM3IxCyu+6t8j2aHrGxcU5dHV3C2fST41aEFRKwhg2z7yv+nKKWw k0wrx5JGXDiSqdPk9C2Uk/irfEMaRSDTMqAE2QJB2UJ/AUGxV97DRq/C1TQhYVFJ oqfOSR+vEljTF3mGrFSTJXjvHAPwT9GcHlrDBANidSITOwr6UnnrU4a+s4rVZo43 B/VjW9IKvp3tWdH04Veax19nnJi4thzV5xWXVh3QB7Z92+NO88+NjHn2UGVW7JpC ZSw5fe329wWXubpOh07rWRAPUkcKJg== =zfkx -----END PGP SIGNATURE----- --e4pjaohho3vuc4bm-- From nobody Wed Nov 24 23:37:43 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E921518A31AF for ; Wed, 24 Nov 2021 23:37:24 +0000 (UTC) (envelope-from khng300@gmail.com) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 4Hzy905k0Hz3pg6; Wed, 24 Nov 2021 23:37:24 +0000 (UTC) (envelope-from khng300@gmail.com) Received: by mail-lf1-x132.google.com with SMTP id m27so11371439lfj.12; Wed, 24 Nov 2021 15:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sdInMn91IQdFXidnZO42fXE82b4grhhdQMGyR8g5TZw=; b=gtAPF/Cgdxnz080fJzvoUcHMhdd6DARdX/Rwb/OZpJPDoQLhkCspyyGpisUWTyxXZD +BLxhEj/Z9rH+tPOD8hX4y4ruM20UhtZQpkqg0q3eJRYwfyirbvs9cE6vuZnOOf8zs2j TYmaZMu/nq1BlZ2ElIa6J/Vy2+R8zkQyzgi+leRmz3P6hzqKoFj5eDz3gB5SgT/vtYMs WFUXWnsxZO94U0D8sBYZrlJRY7Co8cgE33qUo0VflM1r4XcBMjCu+9JwkVi8K+gyQtKN FNAr4FCH3GjuuMvu9e2Zptchsm1LPgj9DAUc0sMAyrctTQNI560rRLOo0+Fbm8hkHWYq PdnA== 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=sdInMn91IQdFXidnZO42fXE82b4grhhdQMGyR8g5TZw=; b=HYow+alTnh0fNSvu/i2BbxY4YsD9ORmhvXIXVpgOG0nho5aeEA0KI59bfYgC2nmejd Q7jlQvG0ezkKpgx1+ga5elvTgYOUrLimawGgVHP0YhTDCgPDaeoaF/OhsJU678mQKgHC cyOYKutbfxkniuomJLoZvd5uYnmxcuR4jLIWRGBLsjSdXxKfozm3lMZHo8Zzq2LwP7qx SOPlMYYXw7d6Fk39ugIPzqdusnrhQkwZ+CrUrxnp+dRXHlCXyHNAkNx36jR6BjyCHWyP Eue65WgbBfNfG4SgbqQrJ7BJPy2KASe4Z13JtyZo8/RjR1uA3PSq2PODegLf7X2dkkch 3h5Q== X-Gm-Message-State: AOAM532Os63q52hL1e989uZ0ltE6xYXzxaNEQhIzEUlrYEWwJE8JIlzO lRFfCv8dI4LACDuZ/10rCwCBmAed/21CJSQrsfYoPHQ8 X-Google-Smtp-Source: ABdhPJxboW9f34tqTB3b1Ypav1B4WWgpCPa50KCTXrd/PmYBhGrHkJD6mIEhiKC9km9URrETsjz8nazYQfYGXZr2Uxc= X-Received: by 2002:ac2:4564:: with SMTP id k4mr19291335lfm.380.1637797043178; Wed, 24 Nov 2021 15:37:23 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> In-Reply-To: From: Ka Ho Ng Date: Wed, 24 Nov 2021 18:37:43 -0500 Message-ID: Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) To: Michael Schuster Cc: Mehmet Erol Sanliturk , Graham Perrin , FreeBSD Hackers , Joseph Mingrone Content-Type: multipart/alternative; boundary="000000000000f912d405d1915606" X-Rspamd-Queue-Id: 4Hzy905k0Hz3pg6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000f912d405d1915606 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 24, 2021, 17:46 Michael Schuster wrote: > On Wed, Nov 24, 2021, 23:23 Mehmet Erol Sanliturk > > wrote: > > > On Thu, Nov 25, 2021 at 12:33 AM Graham Perrin > > wrote: > > > > > On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: > > > > Change policy about discouraging top posting and convert it to > > > encouraging > > > > top posting > > > > > > Please, don't. > > > > > > > > As I said , > > > > (1) persons tracking messages continuously do not need to read the same > > texts many times > > > > [ plus more explanation....] > > One part you're forgetting is trimming what you're quoting to avoid exactly > what you're pointing out. > > > (4) I am a subscriber of many mailing lists . > > > This is precisely where in my opinion bottom posting shines: if done > properly, I have context immediately without having to first scroll past > the new message and then back up. I find it much more natural than top > posting. > > Regards > Michael > > > > > > To be honest, the policies regarding top-posting or bottom-posting in the mailing list is not much relevant to the Foundation. Ka Ho > --000000000000f912d405d1915606-- From nobody Wed Nov 24 23:37:38 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6A33F18A334A for ; Wed, 24 Nov 2021 23:37:39 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from cameronkatri.com (cameronkatri.com [206.189.178.249]) (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 4Hzy9H2H6wz3pg8 for ; Wed, 24 Nov 2021 23:37:39 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from FreeBSDY540 (c-73-84-80-103.hsd1.fl.comcast.net [73.84.80.103]) by cameronkatri.com (Postfix) with ESMTPSA id CCE54414A2 for ; Wed, 24 Nov 2021 18:37:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cameronkatri.com; s=20201109; t=1637797059; 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=YFf3+WgHeldKOOux1e+VfHs7mXJK32XGmTltwy5ZSqE=; b=T5+jHBhM+/rXBDXifKJCIeLYmzMtOKTXJMpWhqw5yuIfBsxLQDbTf2ev1oot6bbJ8dC9fT PF4r3btS3mV2TaKK+u1Y68jjZnX04d4lxd49XHnaY92a/uOLWHoYHfLRcnQBOzfI1lLaqF m5mIV5CUyf73z6TKFYoJ6Y9Ip+Xit8U= Date: Wed, 24 Nov 2021 18:37:38 -0500 To: freebsd-hackers@freebsd.org Subject: Re: Top posting Message-ID: <20211124233738.aabl4ymsnkffofwa@FreeBSDY540> References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rftxiurqk56fiq2o" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Hzy9H2H6wz3pg8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: me@cameronkatri.com From: Cameron Katri via freebsd-hackers X-Original-From: Cameron Katri X-ThisMailContainsUnwantedMimeParts: N --rftxiurqk56fiq2o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 25, 2021 at 01:45:36AM +0300, Mehmet Erol Sanliturk wrote: > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000404.h= tml > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000423.h= tml > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000427.h= tml > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000428.h= tml >=20 >=20 > My suggestion is this . Or, you could bottom post so that we can see what you are responding to by looking up one line. This also makes it harder for me to read on my phone because I have to scroll to the actual message and don't get any context at a glance, I have to click on each link to get any context at all. --=20 Cameron Katri Email: me@cameronkatri.com PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C --rftxiurqk56fiq2o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEfTs2zqQPzCGB+23Nuv/ZeCZUDxwFAmGezMEACgkQuv/ZeCZU Dxz+Kgf/T54aUTPXlKQ6OzBs69/5Z1Lh8AupVBaPaVKKqqCmqq0ZiIHdrXjDFG2T dzd2pvLSwiGp5cEcSv7qXKdPnywkS+o7hUF2GYs/13go+ntARfRajcYrFaZTvdbu ebpB0FxqYSi6uCN0NLmSMB/S0xQIK0XDisEAUPeHdECcBItb9Fkrt4LUub0WUzZ4 AE+ZHCOqp5UU7uNspHH7lHw1i7CpOV7f1s/jI0+k8UTZBOYht99PSUr0fPkzqlER pt7RJ6dDMjOYvLYdS5pG9YqJl1rVcIX5yvoiWt/awGuvw69kQuqqs/x2v/oW1IH6 3nbiAsLEvDy5xGIJkBv3tjmZL0CaNw== =HweA -----END PGP SIGNATURE----- --rftxiurqk56fiq2o-- From nobody Thu Nov 25 00:01:45 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3358F18917FE for ; Thu, 25 Nov 2021 00:01:51 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzyjC0P2Tz4VVZ; Thu, 25 Nov 2021 00:01:51 +0000 (UTC) (envelope-from ler@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dkK7kCT0h4atIBsodfPMpr+NmEqS2gREJJ6Pda0rjlY=; b=HGiz4fR4e0eIadP5VLuQNskYvq xrrCibOSwAfGLQBrLn01SI3i+c1DoeOXOQeXpOHucvrnknv7+kkHQTumajIIaDWyU8Tp8JzvjqSw4 oFHdHFYmTSrdLhe8Azp7KZq/SK8Q0Ni7BgN7SSxnZ3f/H5I6yfEGacBnkABOiTGkhgaa+yBswpIC5 lDs9mrEJosrZaTc+acagR9i4htSHqW5KWqNNM3YFHF0xtBhvYv0fzHEve8OBvUdV37hBs8Je+5YWv TUpX5SPAidXZNfrbUYmCe84jddhFNfGFcu5qA4wUsEt7+lWq9pp9YA+BFY5A7T893dF1a6r0d7Myg fGWN0S0Q==; Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:25788 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mq2D0-0006G5-83; Wed, 24 Nov 2021 18:01:50 -0600 Received: from 2607:fb90:2b76:5b28:6420:1d37:61:de79 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 24 Nov 2021 18:01:45 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Wed, 24 Nov 2021 19:01:45 -0500 From: Larry Rosenman To: Allan Jude Cc: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas In-Reply-To: <246adde5-6a7a-4102-abb4-16c766ea78d1@freebsd.org> References: <861r36xzpe.fsf@phe.ftfl.ca> <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> <246adde5-6a7a-4102-abb4-16c766ea78d1@freebsd.org> Message-ID: <39d7dec472c4d937404aabba91a5ead6@FreeBSD.org> X-Sender: ler@FreeBSD.org Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_8dd0cffa7efb31d55063887bc75e5b63"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4HzyjC0P2Tz4VVZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_8dd0cffa7efb31d55063887bc75e5b63 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 11/24/2021 4:46 pm, Allan Jude wrote: > On 11/24/2021 2:42 AM, Dave Cottlehuber wrote: >> On Tue, 23 Nov 2021, at 22:41, Joseph Mingrone wrote: >>> Hello FreeBSD community, >>> >>> The Foundation is seeking suggestions for new projects to support. >>> What >>> gaps in the Project are not being addressed by the broader community? >>> >>> You can read about past Foundation-supported projects at >>> https://freebsdfoundation.org/our-work/projects/ and the Foundation's >>> four main areas of focus in the 'Technology Roadmap' article at >>> https://freebsdfoundation.org/blog/technology-roadmap/. >>> >>> Right now we are gathering ideas. We will send out a call for >>> project >>> grant proposals soon. If you prefer to send your project ideas >>> directly >>> to the Foundation, we will be monitoring responses at >>> techteam@freebsdfoundation.org. >>> >>> -- >>> Joe (with Foundation hat on) >> >> Some new ideas. >> >> 1. updated kmod ports for point releases. >> >> we should be able to ship an x+1 RELEASE *and* have the appropriate >> kmod ports available at the same time. I know that unplanned API >> breakage is rare, but when it does happen, its absolutely brutal for >> end users. >> >> 2. a decent ports CI >> >> At least for committers, and for regular maintainers, we should be >> able to have some common-sense pre-commit build checks done at least >> on tier 1 architectures easily without human intervention. >> >> 3. jail creation and usage as non-root >> >> nuff said. >> >> 4. more programmable/scriptable configs >> >> I would love to see FreeBSD be the programmable server environment. >> >> - libxo all the things >> - more stuff like libifconfig libpf libzfs -- "lib-ify" all the things >> - UCL all the things >> >> A+ >> Dave >> > > I was discussing the idea of 'user jails' with a few people around > EuroBSDcon. Do you have some specific user cases, and/or ideas of what > would be allowed and not allowed? Back to the topic: Can I PLEASE get some help on sysutils/lsof (which has been broken for all of 13 and 14's lifetime)? If I can't, I'm going to rmport it. -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_8dd0cffa7efb31d55063887bc75e5b63 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=484 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEyBAEBCAAdFiEEHjgknedhWzvJgwVzaXyZsatIp30FAmGe0m4ACgkQaXyZsatI p339agf3fk+WmojVAzSWfaSvIK8++pXnzJfgOld83sg+hZ8C0+SxhpAvucGcgGF/ TRpwOHxFx4UdT2XnwpfaibBQxw9uxBiK5ORvo6vmYzQqR11XelNdTwNoSlULQVEU wfGaH7O9+FUZ67dbQ7UzlkWG7Hke+sp4ll4HNEwfKsPcAT6WduK/1heiC5DLK/gP kiFUuTO2GdJ0p4EpRW/Zs1rcFkBTnfTVDHzNgnRO71KqO1YfbGBvTlD3TDTUH3Iy UzFrEvwO/fTFTP8EAAsVFd48waAy5wRss0tvWYY/7brFlegUPFVYhDCttrq8U5eF t7qZst0IJjjALqEaKhW0Hv1cgAEc =uidZ -----END PGP SIGNATURE----- --=_8dd0cffa7efb31d55063887bc75e5b63-- From nobody Thu Nov 25 00:02:27 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3159B189280A for ; Thu, 25 Nov 2021 00:02:30 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzyjx6zvsz4VmB for ; Thu, 25 Nov 2021 00:02:29 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637798550; 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=O3aH1LpISV4j/3o1Xtx7b2PnVpwLlejCfgN+VZwnsog=; b=ftEX88KjoPxrOVqVz451ZyAk+bO2O5kgCUEPfTL63XRvA0OWhOJ+Z0XydPLA0oSSN+Zdjj SuhkpkoXYcf7Yyqt7hygHGymxC5+GBOHUuGZmz/WQXDUbME6sErpx6aLbvsyaKv3zCcfVR mlxFUqhT9L06z3z8DW4NryRp1HkphZW6fjfCutMpYTueq2Qh7IGtv89nVFmgU9Uzi4j9MR +8cKwqbgjjbtKmn7+YLaJ5xgRfC5rOlyhtGRn2/UfmrjKtsTfOUuj9S0srBlbbUbNlh5g/ tjhAoSUlvH8vaGFEjBxJccmfzTF4WHF2I/QJ3fWYUv+ilabuDFgm/FnPKPy1aw== Received: by freefall.freebsd.org (Postfix, from userid 1471) id C1AC9AAE3; Thu, 25 Nov 2021 00:02:29 +0000 (UTC) Date: Thu, 25 Nov 2021 01:02:27 +0100 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211125000227.dssjkh43inmyvcdy@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> <20211124213150.6lsyaqgwbkgfcgzi@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6vv2w7x3lkwdwk76" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637798550; 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=O3aH1LpISV4j/3o1Xtx7b2PnVpwLlejCfgN+VZwnsog=; b=CbXngYhRkGohXbLT1wIrqGn5XtU3D5B97VKEKdmbTYe+MWPCPaj8Mv23HtNPHde5Qo4atq es9goXN9Ont44vD43ZWujj5+FE8TGBm7pdYK6L/D8714K6r0UCr0IY/OPMNPEugCg/AlqA xBLL3QIZlr1wrFDOPvn3sleNETB/jKKNbsDgVqFLJqNKyaSgjWx5xsGrZ1Hjrc6cdjjf/Y qAp//Qmo5hAKFajyYqlG1a96NF3XtrYdpO0cPe/0yJRtIUo1QUqqldiLzzEj6GNfFKSS8P FOBdgBbfL8aLzt8yKzYN+atMHUCcCdlTi82f5ZUyGVVLgkfWEubLfWiRII7Xaw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637798550; a=rsa-sha256; cv=none; b=PAqPjmKmTV46hEqzPwcMTE2bTZctqpL72Ekr0uIkrtqIXo9eBEG8Ok3qqHwu3fdPA/eOok Q2ml4mwKGOMlrxJKgQ0kAla+TsANwb9Ym7GiGdEQXheVWghjTWXBkJIrzwRvzy7rSl2H9s HjI1PooKn+P90jF8KHCu5DT/mMEu8iptY8CZpPEtDWPW3k8ve/C+VL+LU27RnprgmWy0St WXAb+GSmajKTSNN8pshJK5IRK9ON1qLsDKB1NkS2hStUNRoY9sjBW3mNG/B+Fh/h2SD9+M 9h70x6el4SX3XvXMTjHxG4bfJw7pf522hFInDRNfNmmfILtgX49Opq0vEzmkZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --6vv2w7x3lkwdwk76 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2021 at 10:44:16PM +0100, Fernando Apestegu=EDa wrote: >El mi=E9., 24 nov. 2021 22:32, Shawn Webb >escribi=F3: > >> On Tue, Nov 23, 2021 at 06:28:14PM -0500, Shawn Webb wrote: >> > On Tue, Nov 23, 2021 at 06:41:01PM -0400, Joseph Mingrone wrote: >> > > Hello FreeBSD community, >> > > >> > > The Foundation is seeking suggestions for new projects to support. >> What >> > > gaps in the Project are not being addressed by the broader community? >> > > >> > > You can read about past Foundation-supported projects at >> > > https://freebsdfoundation.org/our-work/projects/ and the Foundation's >> > > four main areas of focus in the 'Technology Roadmap' article at >> > > https://freebsdfoundation.org/blog/technology-roadmap/. >> > > >> > > Right now we are gathering ideas. We will send out a call for proje= ct >> > > grant proposals soon. If you prefer to send your project ideas >> directly >> > > to the Foundation, we will be monitoring responses at >> > > techteam@freebsdfoundation.org. >> > >> > Hey Joseph, >> > >> > Thanks for sending this out! >> > >> > Here's just a few things I'd love to see: >> > >> > 1. wireless mesh support. this would go _a long_ ways for supporting >> > human rights efforts. >> > 2. 100% llvm toolchain for base and ports. freebsd seems to already be >> > going in this direction. >> > 3. jail orchestration in base. it's great that we have all these >> > disparate jail management ports, but we lack a fully >> > coherent/integreated solution. I'd love to see jail orchestration >> > get the same love as zfs in base. >> > 4. tor browser bundle (port from openbsd?) >> > >> > That's at least what I can think of off the top of my head. >> >> Another idea: >> >> 5. Distributed Poudriere. I have a few systems that would benefit from >> such a feature. For example, two ThunderX1 systems. And once I >> resurrect our partially-dead ThunderX2 system, we'll have three >> arm64 appliances in which we can build packages. >> > >Package seeding in poudriere Hi folks, This has been in poudriere since May 2021 according to [1], and is currently usable if you install poudriere-devel. Also, can I appeal to everyone's better nature, and ask not to +1 if there's nothing else to add. This is a call for proposals, if there's any voting to be done it will surely not be done via mailing lists. :) Yours hopefully, Daniel Ebdrup Jensen --6vv2w7x3lkwdwk76 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmGe0pNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87oJrgf+NotgtKo3chZddnjpHQJ1CtcZqY1rkHY/iYWXYEkutVNxwcJkZs12GqTA FB7gtnrmSXr+61pc7Z+cNROl6rlWgseHVosn20TqJGzMnEpD0KHJAEJ4hi2mFat9 Yf7TZXghWZwLiJIStfohDwdD4kwPtIsZ3/HwJ+GeeKeC/vu1fVnEi62FSOcVr6Wl 7Qzf/Yax5I7+Y2npQlZZH8X6Pw3MuEO44Nsk3Jo8KZJ3VENGBF2ffHxnC+H7hGLb ELNDRUwCg6jco7S3iPzF7tcmH8YCdP9QmbPEw75fc7DyctaMcK9zHSDlAIWONHT/ H/hzcgvJWyj0zh8cMQmmoJiF0KOFXA== =Q89A -----END PGP SIGNATURE----- --6vv2w7x3lkwdwk76-- From nobody Thu Nov 25 00:08:44 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 48EA918959AD for ; Thu, 25 Nov 2021 00:08:47 +0000 (UTC) (envelope-from gjb@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 4HzysC1Gl0z4YbX; Thu, 25 Nov 2021 00:08:47 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637798927; 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=8+WFHijqVziL21y4Mu6XStz8V3g57KxSRq1u2t+/9cA=; b=t7ZNNnSltEjkawUZoLAPYO+2BmjZXRzXOW+PjyyL2kXdQgqrGrRo65nL/9okAQf12DgTX9 uLyDe4TVw6jInaZXArpWgX6uyXflNaRXKx9bbzClszk6NZfG1njWFcKy5SKTOvPU+kI/E6 0L3zmhzkNpXsUxA0l2k7Ssy4DCgpZD2kmJLTxjewNYJCaT0nN8HwxmjYnbSGkAyL/qOb5I vPubf/+vCmYsJMKcqLsMaqQyII5yLUp2uoPjBfFTpMcU8Xg9ZGWiu0oqmqeZjmnvhygazb N/rFqC4t/GSdZe+fG1oYj+Q/GIb0k0vYR7/IwlM6UxjYoBY20YjgVrmMSacnBQ== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id C0EE2AAEE; Thu, 25 Nov 2021 00:08:46 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Thu, 25 Nov 2021 00:08:44 +0000 From: Glen Barber To: Graham Perrin Cc: FreeBSD Hackers Subject: Re: Top posting and linking Message-ID: <20211125000844.GA97139@FreeBSD.org> References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XLTQE3HqOi3RIrZG" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637798927; 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=8+WFHijqVziL21y4Mu6XStz8V3g57KxSRq1u2t+/9cA=; b=Y/ZMycQSoY8nSIBqkxWYlhWMgt24UizJuTpoRSfXP6WBs0tbWLXlYivzgqyshUSAanNmLA mlan83YbwS6AkQKTNVFcUTt4S8WhFe6JzYaD0wsD2YpiAUj7aVjoYUcx1Hm8W9hLEklpd9 qt5lEPQ1J29YLUngHQenikvoFjyih0ce+Yn2AZMJpXLSeZ5p/S5k3wGJpmNe+24an6O+oD g6AYdrpbN9nV3mVVbEO46XQCUcE98DYR92fehz4nNPHkjnRLIRyZcd/zoLcuZp+SiffbDS RPYAU0UpBS8g5Rx0rTvW04rNpS4wy5YCCd54yuwHdX+nSQegr8819I4KyRX/cA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637798927; a=rsa-sha256; cv=none; b=TzeyJpSGeAO9GpqCY6845f8k7alEiDHgeTDjwuakxDJytnKntplUqUXjl0tRsBorlokwwq UMCnsmNu/eY/vy2iHsJEXzxt5G3had1FTVbuoduun+JtvM8qQnHmqrnj/dbl7V5Gol14EV YoBsv1qTEWiRsYAd0sTSHYScvENLNYlVlo3eEU90dU6OHXar/7XZSpBkCY5DZapI+Qx98D fGvTe0BVkQ9y1Ff5FNc0Ul432B8QSBQzTvqORzefFacIzX2dt40LmRUe4UgE9LM/9JboqD XoEGWh42ZtJKkBKBRYTvxbiFr2tSYdtG0ddy84OqPHZpJpdh40fayOHBm8aPuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --XLTQE3HqOi3RIrZG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2021 at 11:05:05PM +0000, Graham Perrin wrote: > On 24/11/2021 22:45, Mehmet Erol Sanliturk wrote: > >=20 > >=20 > > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000404= =2Ehtml > > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000423= =2Ehtml > > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000427= =2Ehtml > > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000428= =2Ehtml > >=20 > >=20 > > My suggestion is this . >=20 > Too terse. >=20 > There's _no_ at-a-glance context; it's necessary to step _away_ from what= 's > currently on screen, to discover the linked content. >=20 > > On Thu, Nov 25, 2021 at 1:28 AM Graham Perrin > > wrote: > >=20 Agreed. Sorry, couldn't resist. Glen Happy holiday season, everyone. > > On 24/11/2021 22:21, Mehmet Erol Sanliturk wrote: > > > not useful in these days > >=20 > > I respectfully disagree. > >=20 > > Bottom posting is preferable for a variety of reasons, not least: > > order. > >=20 > > I find things unnecessarily difficult to digest when they're > > disorderly/jagged. > >=20 --=20 Glen --XLTQE3HqOi3RIrZG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmGe1AUACgkQAxRYpUeP 4pPuxxAAotyF+Pb4UWk5sCPPFpNs1jsXdxrgVv4GxT19KSt9T0T1dFZuECb8LTMc g3gfjJwyuPijCBFNAU0VEpUpN1vrJ+hZYl1t2ffOSMsEZpMTPzvMMkeYKzlWvkAg C5S+aIunBKQ8G6tNl6JnZYc76VPspSV79BLQHjjW3mhmF13XlDHGN3Cb5D7SF/R0 L2NzUrW8/RQzROUpE3El4XBxNQXWQNOu7BOC46+HtW6QMcU9ZV1oMOk8f4V3GRM2 3U7gwHjBCELZj2sJznaqX/ER47iZ0S08LuBmbqGwf224t63HKb31rVB/AJhAxdmW UPQmvmzoxdD23KwIxuOtqu/pml8oo1rl8zDzmyy+bzaT+mkT8dlxw7i1ujqit5vI u8Je7T3uOjc3K5UxcRioK850G91gO18t+nwanyd7mcLdVgIbj5Lw+lOaFHEHA4wL kWfOpIED5Isq3ESWhAn5rCKd1JNSh/oBpXmQmSg78ketROWA02LqY6ejc4H/O/8l vJjrNyU0EJ94npaBF4Jxl7XsK6YzqjPEr2x0yjf+qfslrpQ92dL0SK6OhOwVG3sG 2bH4AFg2GCpuB062nvncpub11pwwv4VnPELbyKAv/eQXGw9fh249hLLvCXo0F2X1 1kFYNi5XEjR9R6k/i6zQ/z1oZPtbMnXuM454bi057w52Fninbsg= =Qs/K -----END PGP SIGNATURE----- --XLTQE3HqOi3RIrZG-- From nobody Thu Nov 25 00:09:51 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 52C6E189702E for ; Thu, 25 Nov 2021 00:09:54 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzytV0x18z4ZTW; Thu, 25 Nov 2021 00:09:54 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637798994; 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=FVsViyPrvxMQZ/IA12OvNXg7acddetL1CtZ8BUq4xVU=; b=HIcTz9/yLY+ecuGPq1GhTodcK+cSwn+jW4h1flHaJBdYOpNjwLkE41hTexoWVRcc5LWN32 AStuTckvTYl339yv4xfaa9RKZBtfWdQJ9N5bJLDuDE2SNclyN0eaqB/odl18X0o1h0QT+m ZY45bArXYpvw9SVFduml2/cPlLAO0ZY2Tuaitm0G7Iyc51veJBYErKGyUGDDuygpv+wC31 eY3Cr6pP6zTgoRGUz23mc44qBK+tdSrpkoqVpssVBXv4d9FkFBeJ1lCP7H58d9FEb9StL5 ImSR4J3gJlu/b+LwTkn6S8TfpOsMTTOe9/ArY40wAJXss7tvT/BFGWTjS3BQDg== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 7C27CABC7; Thu, 25 Nov 2021 00:09:53 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Thu, 25 Nov 2021 00:09:51 +0000 From: Glen Barber To: Ka Ho Ng Cc: Michael Schuster , Mehmet Erol Sanliturk , Graham Perrin , FreeBSD Hackers , Joseph Mingrone Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) Message-ID: <20211125000951.GB97139@FreeBSD.org> References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Cou6PmgoyP0+llr2" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637798994; 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=FVsViyPrvxMQZ/IA12OvNXg7acddetL1CtZ8BUq4xVU=; b=YJnBLeAZ2NqUx+ayZ/oeo4v8Cv8T7BrXMTKsazSm63OV4/KK5GtVvIX8+amlSKMfTve71q 8AV0GgG6hn9SFMnK6bjEYCB7jOd3TqyLyLQ3BJa54arrVqA0G81imxsFAHf7m712UzCLka SyW68wKCN2ZCmidXkItHuaPrfql8R1fR8zvhlsWqXNR1DQqKaV7Fmr15lER178aLuKeFOl G0JeNb1fbhm6IhFZjiF8jWG+oGsCSHMMNbeMAxz865sJrI+CCYzq9GhkTlehqktRj87zrH bAtkwFMy2aZLoWg5hnnPR37mXMJLw1mTzeiFKkzZFn+fF7LAEgw/Ovp9jmH7Rg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637798994; a=rsa-sha256; cv=none; b=mq5G8pUwV9Ii0O2oubb26kBbOfQiB4TnoMljdyA39lJLGMwmYwBxGXODHFAhrnjsk1L/yK yaNF4DBRKprt/kNF8QB5V/19uiWaQWA2n6SJy/oDR+m5Wlphx/3VJvCwtrXfXP88PBWavM OI9jDMRTYgz3nA673AsxBO9hGH2IYzhBwr9wtv46bcSswJU0YnObgoopkf0jNW3m13Es13 SYHd1/DSulpDzbY4QjH4QIdyobcY2IgsIRJWGb55A5n+ocfaJikwQ4VZ1xCLwlRX0+YF7W N1h3zN3ZvVzbbqbcP8oojlcICYUKQmTc4EFMVDVaPIMhEoNOnHnzSBkmRALUrw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Cou6PmgoyP0+llr2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2021 at 06:37:43PM -0500, Ka Ho Ng wrote: > To be honest, the policies regarding top-posting or bottom-posting in the > mailing list is not much relevant to the Foundation. >=20 Nope, just a bikeshed that arises every few months/years. Glen --Cou6PmgoyP0+llr2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmGe1E8ACgkQAxRYpUeP 4pMrKw/+LWUDtf9KNylQlq+ti9Ses7USVlStwjqis0W77h69kxWihYDSkAeYf8Sx In/3VGQL2MjM3TvbT5cqNS58nX8lnIX+1d747cVTXZD+8CvgSdGWUN0w6eswz1Y/ 4NUsB16JYf7pkIzBoF/LkqyJpL83GZyHgIC45rzYs9pmkCRBFnm9241uiHC7ri9f GpTLyHfYCdHBG1xZqSRqpoSfgXDs+aoBSLAeRACqMHYBvHOt5qQExXQwrJ9HLGSd oeYOdBrZWFLneSEeQvj1AHk0Ypgq2xW84MehIPqGERtuXZCW3WsNbE4BlK7O4TFZ 8vBfhzdb8ilxCFQk6PL4vW0ywZ0Unhjyg1sC3++LMI1BvEnAUOqdWanFWHBNIgxX ltgdLoCBj8f5WO86+Hh1DX61R7oPcSqelgCamxnT75TxUglcxYAdlQUpjtZMQ3CJ sdqz+Y9UXIjBlYyatQ8KO/1vdZIXKTPo1lCOXWm59SZqop9uAyYwxbz49l8X36UH NpMMRTKKXx2VqS/lXMTjYxIMmb5hr/ZHLK7LMJXyJP84VVrLmKtD8dAivOChzbJi 9iSVhQDto/u6/zW6H2EBvrqLhu1QdyOYwYnND+0MNNiQDX80SSN06uJS5jKZDPNU feH00MeGp2WeUHrLg65OFLJVTi/jwBD/nzL80jRoNeU0jax8gUw= =sFCC -----END PGP SIGNATURE----- --Cou6PmgoyP0+llr2-- From nobody Thu Nov 25 00:49:16 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 33A1B18AB97E for ; Thu, 25 Nov 2021 00:49:23 +0000 (UTC) (envelope-from SRS0=87oI=QM=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 4Hzzm222yxz4p5p; Thu, 25 Nov 2021 00:49:22 +0000 (UTC) (envelope-from SRS0=87oI=QM=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 5256F28416; Thu, 25 Nov 2021 01:49:20 +0100 (CET) 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 2C7FE28411; Thu, 25 Nov 2021 01:49:17 +0100 (CET) Subject: Re: Call for Foundation-supported Project Ideas To: Shawn Webb , Joseph Mingrone Cc: FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz> Date: Thu, 25 Nov 2021 01:49:16 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Hzzm222yxz4p5p X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=87oI=QM=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=87oI=QM=quip.cz=000.fbsd@elsa.codelab.cz" X-Spamd-Result: default: False [-1.79 / 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]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.985]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=87oI=QM=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[78.45.215.131:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=87oI=QM=quip.cz=000.fbsd@elsa.codelab.cz] X-ThisMailContainsUnwantedMimeParts: N On 24/11/2021 00:28, Shawn Webb wrote: [...] > 3. jail orchestration in base. it's great that we have all these > disparate jail management ports, but we lack a fully > coherent/integreated solution. I'd love to see jail orchestration > get the same love as zfs in base. While we are talking about jail orchestration in base (which will be really useful to me as well) I would like to see better integration of jail in more aspects in base. Jails are part of the base for more than a decade but still kind of hidden (similar to cpuset - many users don't know about it / how to use it easily). Alexander Leidinger posted proposal in 2019 "automatic jailing of services (rc.d/*)" [1] with patch [2]. This seems useful and easy to implement in base to me. As far as I know, Alexander also have patch to allow run Xorg in jail. As for cpuset thing - 11 years ago I proposed patch to add support for cpuset in rc.subr for any service [3] PR 142434 [4]. I think it is even more useful these days as computers have really a lot of CPU cores. [1] https://lists.freebsd.org/pipermail/freebsd-jail/2019-February/003710.html [2] https://pastebin.com/LBZRezgu [3] https://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001816.html [4] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=142434 Kind regards Miroslav Lachman From eugen@grosbein.net Thu Nov 25 05:43:12 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0235C18AE64B for ; Thu, 25 Nov 2021 05:43:27 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J06HK5gh5z3jmr for ; Thu, 25 Nov 2021 05:43:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AP5hMWJ042664 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 25 Nov 2021 05:43:23 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AP5hLMV050958 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 25 Nov 2021 12:43:22 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Top posting To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> From: Eugene Grosbein Message-ID: <105ed883-06ae-d801-2bde-05d78d31f233@grosbein.net> Date: Thu, 25 Nov 2021 12:43:12 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J06HK5gh5z3jmr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.11 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.99)[0.995]; 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:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 25.11.2021 4:33, Graham Perrin wrote: > On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: >> Change policy about discouraging top posting and convert it to encouraging >> top posting > > Please, don't. +1 From nobody Thu Nov 25 06:37:01 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9F9A818A9C03 for ; Thu, 25 Nov 2021 06:38:12 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J07VX3DSPz4VMt; Thu, 25 Nov 2021 06:38:12 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-qk1-x733.google.com with SMTP id q64so9401924qkd.5; Wed, 24 Nov 2021 22:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=3VEObC+w9n4XgjJl7mg9097TMcAtaWDI8h6R1AjIwxE=; b=LcATilGx61Hen+riich65c/70ImFNNRSpAIPiESGcq1mE55GeZLGmtKf3aCoVZCkSa ExGaYdjWKRg4d4Ux0IFccRFZn+mJEnbDmYRPOvBFyqk2bQ9Ir9TWxNNP9mldjq8QRJJh NYBOv8WQ+9K/9LvuN86nsse99C7wv1CsDJW3nVlH3ROlekm+Hga7ARx4O7mL3Akdb629 oXCWQZrXIBGHD5dNshesR3qYGMbppQiaaAbx7FckVm4hszV3pDGTq4kbkN2HAhM2/sqr 3kG8OypxWsYYk+9F9sd4OCtV+mXwe0I4dpSiBLOz5hUGj1F24yAPw1ozPVJQWC0FyaxS XuKQ== 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:content-transfer-encoding; bh=3VEObC+w9n4XgjJl7mg9097TMcAtaWDI8h6R1AjIwxE=; b=5/5i5GQuwSgk8IUf1nPrgmROh4jIzD7NO1gXmbQ5hCZbNyHj9pEs90DRqLXGPe//d4 MOg3QWyujeUpN9GyoJfADVGC+OWfNKVmvV6NRiLvAUatvkoT9lgVNmuAyXfwyzY0XXMF 30UGTSUwMawg2kzC5ds32YCunDzZqKrk4fPPAGT7yqHcZcI+V5+6kNDYxq+OfJBm2FZC tAAOK3frSCZpV/Z6MaYhsxO9esaAVcbgqUI+VeMr022nc1Vo1GUD3dbtwY3c16/OvxdM AlrrlSGikmjf0xyLDlTBDCEnFzeNJ+OFZHnCCzYS7fjOoUs2PQus1gAgkYQH89uSx0Gh oZhw== X-Gm-Message-State: AOAM533Xfz59Pc+HP3fGZaSs8L/xrgOLSHL0v6U9rsOGKbk8Q56R+ZiL 6zChAkCJDXnz2TM3DUe6WeDjU+qqUOY54efcxFpd1Juv4lYgow== X-Google-Smtp-Source: ABdhPJxXRJkT+/W10e2Zgooligv1ydWblgiSbuBlwU7G9lYyMgOs+5WQLI5GH19jfngO+7QEVtEiqPLz7ctIAYTdKAs= X-Received: by 2002:a25:d386:: with SMTP id e128mr3889670ybf.176.1637822285577; Wed, 24 Nov 2021 22:38:05 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> <20211124213150.6lsyaqgwbkgfcgzi@mutt-hbsd> <20211125000227.dssjkh43inmyvcdy@nerd-thinkpad.local> In-Reply-To: <20211125000227.dssjkh43inmyvcdy@nerd-thinkpad.local> From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Thu, 25 Nov 2021 07:37:01 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Daniel Ebdrup Jensen , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J07VX3DSPz4VMt 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: N On Thu, Nov 25, 2021 at 1:02 AM Daniel Ebdrup Jensen wrote: > > On Wed, Nov 24, 2021 at 10:44:16PM +0100, Fernando Apestegu=C3=ADa wrote: > >El mi=C3=A9., 24 nov. 2021 22:32, Shawn Webb > >escribi=C3=B3: > > > >> On Tue, Nov 23, 2021 at 06:28:14PM -0500, Shawn Webb wrote: > >> > On Tue, Nov 23, 2021 at 06:41:01PM -0400, Joseph Mingrone wrote: > >> > > Hello FreeBSD community, > >> > > > >> > > The Foundation is seeking suggestions for new projects to support. > >> What > >> > > gaps in the Project are not being addressed by the broader communi= ty? > >> > > > >> > > You can read about past Foundation-supported projects at > >> > > https://freebsdfoundation.org/our-work/projects/ and the Foundatio= n's > >> > > four main areas of focus in the 'Technology Roadmap' article at > >> > > https://freebsdfoundation.org/blog/technology-roadmap/. > >> > > > >> > > Right now we are gathering ideas. We will send out a call for pro= ject > >> > > grant proposals soon. If you prefer to send your project ideas > >> directly > >> > > to the Foundation, we will be monitoring responses at > >> > > techteam@freebsdfoundation.org. > >> > > >> > Hey Joseph, > >> > > >> > Thanks for sending this out! > >> > > >> > Here's just a few things I'd love to see: > >> > > >> > 1. wireless mesh support. this would go _a long_ ways for supporting > >> > human rights efforts. > >> > 2. 100% llvm toolchain for base and ports. freebsd seems to already = be > >> > going in this direction. > >> > 3. jail orchestration in base. it's great that we have all these > >> > disparate jail management ports, but we lack a fully > >> > coherent/integreated solution. I'd love to see jail orchestration > >> > get the same love as zfs in base. > >> > 4. tor browser bundle (port from openbsd?) > >> > > >> > That's at least what I can think of off the top of my head. > >> > >> Another idea: > >> > >> 5. Distributed Poudriere. I have a few systems that would benefit from > >> such a feature. For example, two ThunderX1 systems. And once I > >> resurrect our partially-dead ThunderX2 system, we'll have three > >> arm64 appliances in which we can build packages. > >> > > > >Package seeding in poudriere > > Hi folks, > > This has been in poudriere since May 2021 according to [1], and is > currently usable if you install poudriere-devel. Thanks for pointing that out. I've been closely following this feature in GH and the last comments from the "original" proposal is: "#797 is merged but there are a lot of pitfalls that make this not as useful as it seems. For example, llvm and all the other big stuff still builds. #822 will probably be needed to fix that." Also https://github.com/freebsd/poudriere/issues/822 is still open. Package seeding is important precisely to avoid building big stuff (llvm, cmake, qt5*, etc). How often does poudriere get updated with changes from poudriere-devel? Or if poudriere-devel is stable enough I could give it a try anyway. > > Also, can I appeal to everyone's better nature, and ask not to +1 > if there's nothing else to add. This is a call for proposals, if > there's any voting to be done it will surely not be done via > mailing lists. :) > > Yours hopefully, > Daniel Ebdrup Jensen From nobody Thu Nov 25 06:52:03 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9814518AD759 for ; Thu, 25 Nov 2021 06:52:16 +0000 (UTC) (envelope-from matt@ixsystems.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 4J07pm3Cxkz4ZHD for ; Thu, 25 Nov 2021 06:52:16 +0000 (UTC) (envelope-from matt@ixsystems.com) Received: by mail-wr1-x434.google.com with SMTP id i5so9342081wrb.2 for ; Wed, 24 Nov 2021 22:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R3xVS2NyJwZayoZo41M24qgiFLTEqX1LJO7wD9Au06I=; b=acKiipyNDSSf10FHjs52Yw4S6qbZ31gugbdFTE9AuzHf4NffCyyqfSaNNde3g2ol2A zVHgUErwQa9N6Ka//dhUbdyg6fTIkFnWPO9D1UfPiivJdU+tOMcQEMozTYqpg8negmW+ QGWo/Bokvlz5Bcv4QFYvkg2yeXy9RhbJST1rKh8A1LUJDL/SDgAOY66/eAasiIxVjocy nFIwf4LCvjOUWE093C31SAbftek9n6WIFFydybfbHtL137bHKmZSd3HWrzgClc4zeGcG m0S4FxV8T3qajIRGED24RR+/z6cdmApnP4Mx++J72FiKeke5OQyoDvrw6pgGZfrLYUvT 9N8w== 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=R3xVS2NyJwZayoZo41M24qgiFLTEqX1LJO7wD9Au06I=; b=2w58nvcGFieQ5tva7Rm2StSv77aqY1iTwo8w8pggx5BA4/OtkVkx8IY5IkEVNdgQAA jXzK+fR4PZLK/Rqwyvp3mgKO3tZz9JmiUVBqlKdItqH60tJY0m8Dfd6xvuxZRMw+F2uo q417XkSQ+Hb6toXtsvadIIocJO2A4WPbNA353F25Pmi2okVWPvZty1b8Z5ocNwL/DFxK R7VTA4aQPoUVATWUxk4iMCVoOPGRRDwf1IJ3Q64opYn2AbkAtOnY7Ku0kSiMTLcu7KR3 RTCFU4mw2djr+Dns5OuLEQqXLM1SsgF1WKSZmJ39dOi1HRQ8mHITKE+KDfbCFd7l/CtV N/0Q== X-Gm-Message-State: AOAM530WHVN0yTUnEFOxBcjWsoU1JBJj/X2hPvr3YSnA3xXcQhPgziG5 wGcwIYLLDKQwk73suTnm9Ebwl8WXiGCU2QqNLWvCIQ== X-Google-Smtp-Source: ABdhPJxKF3zwGBGMGAub+DNhQv9zdgPkMZmfc/3RpdkQl7Ukbi+bZ5/WoDxDuMbHNZWq5u9isfuF2hmS8NBdOAR1xgQ= X-Received: by 2002:a05:6000:120a:: with SMTP id e10mr4133557wrx.156.1637823135458; Wed, 24 Nov 2021 22:52:15 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <20211125000951.GB97139@FreeBSD.org> In-Reply-To: <20211125000951.GB97139@FreeBSD.org> From: Matt Olander Date: Wed, 24 Nov 2021 22:52:03 -0800 Message-ID: Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) To: Glen Barber Cc: Ka Ho Ng , Michael Schuster , Mehmet Erol Sanliturk , Graham Perrin , FreeBSD Hackers , Joseph Mingrone Content-Type: multipart/alternative; boundary="00000000000031ccc605d1976a05" X-Rspamd-Queue-Id: 4J07pm3Cxkz4ZHD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000031ccc605d1976a05 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 24, 2021, 4:11 PM Glen Barber wrote: > > Nope, just a bikeshed that arises every few months/years. > Definitely. Top posting is lazy and insulting, so you'd think that I would like it more than I do. However, there are far more relevant issues we could be discussing besides the effort required to scroll through a post while on a mobile device. For instance, how about Foundation-supported Project Ideas! I'll come back with some good suggestions that don't involve WordPress, I promise ;) Cheers, -matt --00000000000031ccc605d1976a05-- From nobody Thu Nov 25 07:12:57 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DB1BA18B5EC5 for ; Thu, 25 Nov 2021 07:13:06 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (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 "mailserver.netfence.it", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J08Gn714bz4gcq for ; Thu, 25 Nov 2021 07:13:05 +0000 (UTC) (envelope-from ml@netfence.it) Received: from [192.168.134.64] (jack.fabbrievecchi.it [89.97.212.98]) (authenticated bits=0) by soth.netfence.it (8.17.1/8.16.1) with ESMTPSA id 1AP7CvDp046838 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 25 Nov 2021 08:12:59 +0100 (CET) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host jack.fabbrievecchi.it [89.97.212.98] claimed to be [192.168.134.64] Message-ID: <8a108e41-c8bc-b226-ceff-66e2ca6a828e@netfence.it> Date: Thu, 25 Nov 2021 08:12:57 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Top posting and linking Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> From: Andrea Venturoli In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4J08Gn714bz4gcq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; 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:35612, ipnet:78.134.0.0/17, country:IT]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/25/21 00:05, Graham Perrin wrote: > On 24/11/2021 22:45, Mehmet Erol Sanliturk wrote: >> >> >> https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000404.html >> >> https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000423.html >> >> https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000427.html >> >> https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000428.html >> >> >> >> My suggestion is this . This is simply horrible. bye av. From nobody Thu Nov 25 07:13:24 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A78F418B5EFD for ; Thu, 25 Nov 2021 07:13:29 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (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 "mailserver.netfence.it", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J08HD6jFjz4h11 for ; Thu, 25 Nov 2021 07:13:28 +0000 (UTC) (envelope-from ml@netfence.it) Received: from [192.168.134.64] (jack.fabbrievecchi.it [89.97.212.98]) (authenticated bits=0) by soth.netfence.it (8.17.1/8.16.1) with ESMTPSA id 1AP7DOG7046894 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 25 Nov 2021 08:13:24 +0100 (CET) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host jack.fabbrievecchi.it [89.97.212.98] claimed to be [192.168.134.64] Message-ID: Date: Thu, 25 Nov 2021 08:13:24 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Top posting Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <105ed883-06ae-d801-2bde-05d78d31f233@grosbein.net> From: Andrea Venturoli In-Reply-To: <105ed883-06ae-d801-2bde-05d78d31f233@grosbein.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4J08HD6jFjz4h11 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; 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:35612, ipnet:78.134.0.0/17, country:IT]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/25/21 06:43, Eugene Grosbein wrote: > 25.11.2021 4:33, Graham Perrin wrote: >> On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: >>> Change policy about discouraging top posting and convert it to encouraging >>> top posting >> >> Please, don't. > > +1 +2 :) From nobody Thu Nov 25 07:58:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2A04E18A75C1 for ; Thu, 25 Nov 2021 07:59:06 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J09Hs6gVjz3DbB; Thu, 25 Nov 2021 07:59:05 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165022.dip0.t-ipconnect.de [91.22.80.34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 6EC0725D52; Thu, 25 Nov 2021 08:59:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1637827142; 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=Z2Pqg2o4qoYpUzivREAODr/zoNEx+xdZxyZzCkWVJSw=; b=T+WCvnK309M0Qsb5Zy4hT7cMhNCYJIrx1+Ff9DGOK+lTY1blfqjw1FdjBwwhXM/nxv3GOe cPvNmsVE4TCHObKPnqP3PqIXWOfLh60OqZ7uw5FKxGKbRhWlYXUhyFBc/Tmqc2yOTrZ1U+ KWqce2OCX3ZgylWQIKuB1ywHRGRkOn9OTZKofNLbtQumvdWsffIR1ySwFU86Jft9zRvft+ mv0gYtLMOwr58h/FZKSDCgpby6sgzQzfuZOr339pKXnPXESYcfzS8hVVH+5cozW4M+H9Pq 6EQajs/DflfOy1PbX4uUgNweOQDIvTH2Avcsyg1WoT06S2fJtuiGlu978C7Lyg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 0F2D05C07; Thu, 25 Nov 2021 08:58:44 +0100 (CET) Date: Thu, 25 Nov 2021 08:58:42 +0100 Message-ID: <20211125085842.Horde.8bA9IGWNOXWbVThVBaYDG8r@webmail.leidinger.net> To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Joseph Mingrone , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz> In-Reply-To: <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz> Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Queue-Id: 4J09Hs6gVjz3DbB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: Alexander@leidinger.net From: Alexander Leidinger via freebsd-hackers X-Original-From: Alexander Leidinger X-ThisMailContainsUnwantedMimeParts: N Quoting Miroslav Lachman <000.fbsd@quip.cz> (from Thu, 25 Nov 2021 01:49:16 +0100): > Alexander Leidinger posted proposal in 2019 "automatic jailing of > services (rc.d/*)" [1] with patch [2]. This seems useful and easy to > implement in base to me. I have a patch. I consider it an useful idea. I have 1 service on my server in the basement which is using it. I have converted a few more services (basically just the rc scripts to make use of the feature), but don't use them at home (I converted some easy ones, but have no use for them at home). I have run into some cases, where this doesn't work on the rc-level, as the patch I have for this feature I have made in a minimal-invasive way. But this part of the rc framework is not really suited for what I want to use it for (currently I use the fast*/force*/one* part to add a jail* prefix, but this runs into issues if you want to use e.g. onestart with a service which is supposed to run in a jail automatically). If someone who has more intimate knowledge about rc.subr comes up with an idea how to implement it in a better way, I'm all ears... My patch (last regenerated Apr 2020): https://www.leidinger.net/FreeBSD/current-patches/libexec:rc:rc.subr.diff > As far as I know, Alexander also have patch to allow run Xorg in jail. The only reason this is not committed is, that there was feedback in a way that I shall not use a jail-parameter (currently allow.kmem_access) to enable the feature. This can be understood in two ways: 1) do not use the corresponding KPI 2) continue to use the KPI, but add some code to jail(8) to translate a new kind of argument to the corresponding allow.kmem_access KPI In both cases the security aspect is the same, this makes the host completely accessible to any program run as root in the jail which has this enabled, it's just a different interface to enable it. Personally I do not see a difference between "--new-way-of-enabling-this-feature" or "allow.kmem_access" (or "allow.give_mem_access_to_complete_host_and_compromise_security"). As such I do not intend to write any code for 1) or 2). My patch (last regenerated Apr 2020, only the first part, the file contains some more unrelated changes): https://www.leidinger.net/FreeBSD/current-patches/sys:kern.diff > [1] > https://lists.freebsd.org/pipermail/freebsd-jail/2019-February/003710.html > [2] https://pastebin.com/LBZRezgu Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Thu Nov 25 10:07:58 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E46B018A76D6 for ; Thu, 25 Nov 2021 10:07:58 +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 4J0D8Z66d3z4fZZ; Thu, 25 Nov 2021 10:07:58 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637834878; 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=vdlEnyEFD/C6CieXFGs2FtXczX5XBBsHQSKOeG7reAc=; b=K7SYhh5B2PoFOSNBFzKZLsZzn7bONBveTsH//LDq+HE4RcW/fgDpbb4+LudYwE5pjWzM57 CS1j+EoLoDfJ2YxldHX8hJSfgAQ7wZdA13TViRxWGoDjBAytPq3wBfPN1SMh+HZxkcTcXy SVurugoP1HQCBXwAW5I+QIHUv1U7WPTeA8yl2HlktvS8a+xKyF3wKB8yIukHOlvhJMs4QW 4xGaVB+DUGubI+6hepYrV6x3cisvLT6eC7gnmYrzw8N0sqs4r5wcyYVoMKNHzpJayJNLU5 dyDSME1pBrTU9VevAZxrjmkUr0Tw8pCkw3zdpddS+40AngWRSpFJJjF2HsMFPw== Received: by freefall.freebsd.org (Postfix, from userid 1403) id B0BFAC9BA; Thu, 25 Nov 2021 10:07:58 +0000 (UTC) Date: Thu, 25 Nov 2021 10:07:58 +0000 From: "Piotr P. Stefaniak" To: Andrea Venturoli Cc: freebsd-hackers@freebsd.org Subject: Re: Top posting Message-ID: References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <105ed883-06ae-d801-2bde-05d78d31f233@grosbein.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637834878; 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=vdlEnyEFD/C6CieXFGs2FtXczX5XBBsHQSKOeG7reAc=; b=ant7scdZJT1iOx1WmrSAfD2M7K90/LZZsCHhExCU3vPzd2DUnc4+j90LBdS9igWxVmIULL JqEM35rsF4pd4e3X4lfd9RzjexffIyq9zjd+NIbwswuSIKqIO2b++lN+PTHWFVWYTYKBQD M1Up7JE3HmuXPdqmeHyhdDao5bwHiuhtarl0epnNHds3GYg9BJMczA3T4SuUFkMP/Kipo5 0QrvxvsjFKLwTsC5HP6ACcd7/gtu0mgG4j16HwwxSxWhCAuz1pPIuwnvD8W2xIUGyULb5e RUdZhDt2DKO8rQEx/o/bV0CmPiFupNIdsd1OobD0f7fT/Qoe0wgIBx/QHSi0hw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637834878; a=rsa-sha256; cv=none; b=S7zsZu9+xH1z6T9lRg+EqgSmlCpg9tLyGWb4PTgQ6v8Q5oVz4+3lcYJZM5AlS59K0ha7gQ 3zi54jKRTsZUZMZLB+tbszcrgqyuJ7mTAP5dbMVuER38O8LkRhzTuj9j1fZi7hpaG0RTQz f7H3BmzrVqct1ohLegPPTaEZaCFsqqgGvGjZIlZ/2sNRLVzeBYbi7UV+CprPSga2sl3Ayf GUKn/FYjH7H1a8qIYPiV1mVw1SOYTraC33MEUyXffzc0tQNwM9/c0Qw3k/oR2zqb9kOnBy uj/u1gRIJeOzbdsDvvV19XcGEHCANbFFj7z+BoDFS/PEG8IkWOq3m6URNIOv0A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N +1 On 2021-11-25 08:13:24, Andrea Venturoli wrote: >On 11/25/21 06:43, Eugene Grosbein wrote: >> 25.11.2021 4:33, Graham Perrin wrote: >>> On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: >>>> Change policy about discouraging top posting and convert it to encouraging >>>> top posting >>> >>> Please, don't. >> >> +1 > >+2 :) > From nobody Thu Nov 25 10:26:11 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9F60018B1B9D for ; Thu, 25 Nov 2021 10:26:20 +0000 (UTC) (envelope-from paul.g.webster@googlemail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 4J0DYm3lvRz4mYK; Thu, 25 Nov 2021 10:26:20 +0000 (UTC) (envelope-from paul.g.webster@googlemail.com) Received: by mail-wr1-x42a.google.com with SMTP id v11so10482648wrw.10; Thu, 25 Nov 2021 02:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=reply-to:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=2f6Iu6XPZxqzNQHM8QvRBGXpYLnLBi/yoxY/0QMAhWY=; b=IKVKxS6e+2Oh4y6g9WiXHLGYj2o8CmtLR5KcYvg2kz0kTnjRKxgOzunHOMqX2bs4ek jG32O/UG6PtrHMWCA2IJQi93k2PR/KS1m18D8dBicvH6VpzeMBdiRROLU6zmUnjWpzXs gzJdI0x24NoAIA2COdOLwfNhKDM+Q2vmWJCP294c8l9SaWbbcQsML37yWDxA3FTGGqe5 ixCBGRTsxoKqXTgzLQ0aPLtrDBd9meqOGcRQlodrvPx+1/ZkPt65OzsUTORNjUK80UPd WF/SqxmVhpAH5CDluf1MCNqEO7GUBsANu+EnRBogbaxURNZ5362YUxAkeJe0OD5WN8Ar GvhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=2f6Iu6XPZxqzNQHM8QvRBGXpYLnLBi/yoxY/0QMAhWY=; b=3GAE7KwgePssA5gtKbv5meOUOgaMVjT8RjFg9q1gjmcph/vHNySFyR97Fkw6MJYVp3 XqfbTLiL/2vaYT+RqU+j0bAMKEufrHiMwB/JAk4nNILS3yxltBoZWzPmoQaP5sAqLX2q 5d0aa4mBY/tXqvx8Wg7PDN3icGR9eRaqEYlhxi8qsF34+a9ONDTNBmlsRIdU0wnSMlRG mOGn4ndka/2whV7ZFPB9udOG97HEW3GH2Kni+umKslP5faucMGSAoZwftoWxh4JTT6lO HStysez6naNMLgl/cEL4IOcGLtBPIlO6csnJUH8k2c/1YMePNLFg4GdKmbubv59lmPOL zcGQ== X-Gm-Message-State: AOAM530rIBSXu90WzuI78UG6Jw5QIjglee+fhk64uvQq9jXMordzClWD Q0JHlCMV9OgV6YpjMhPd8pIiRyGNDlu6Yw== X-Google-Smtp-Source: ABdhPJynXuA9LN+Alc6eZ+bW9nLCKQSBBgNYeVEwV5pstOlZNjIJVxUSiB1IvDeUmaQ8sZx9vuRTbA== X-Received: by 2002:a5d:624f:: with SMTP id m15mr5216442wrv.13.1637835972460; Thu, 25 Nov 2021 02:26:12 -0800 (PST) Received: from PaulDesktop ([2a00:23c7:551f:f800:41df:609d:467e:b878]) by smtp.gmail.com with ESMTPSA id g18sm8988068wmq.4.2021.11.25.02.26.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Nov 2021 02:26:11 -0800 (PST) Reply-To: From: To: "'Matt Olander'" , "'Glen Barber'" Cc: "'Ka Ho Ng'" , "'Michael Schuster'" , "'Mehmet Erol Sanliturk'" , "'Graham Perrin'" , "'FreeBSD Hackers'" , "'Joseph Mingrone'" References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <20211125000951.GB97139@FreeBSD.org> In-Reply-To: Subject: RE: Top posting (was: Call for Foundation-supported Project Ideas) Date: Thu, 25 Nov 2021 10:26:11 -0000 Organization: Paul Webster Message-ID: <006501d7e1e6$deabfce0$9c03f6a0$@googlemail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJGF5QjmUftfKBheoi+SViUiLzunQFM6tTvAmtAu9QCN0svnQGtmBU0AiYn77UBotAaqADbLgijqtWUvtA= X-Rspamd-Queue-Id: 4J0DYm3lvRz4mYK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Apologies for my ignorance on the subject, but what is 'top posting' ? -----Original Message----- From: owner-freebsd-hackers@freebsd.org = On Behalf Of Matt Olander Sent: 25 November 2021 06:52 To: Glen Barber Cc: Ka Ho Ng ; Michael Schuster = ; Mehmet Erol Sanliturk = ; Graham Perrin ; = FreeBSD Hackers ; Joseph Mingrone = Subject: Re: Top posting (was: Call for Foundation-supported Project = Ideas) On Wed, Nov 24, 2021, 4:11 PM Glen Barber wrote: > > Nope, just a bikeshed that arises every few months/years. > Definitely. Top posting is lazy and insulting, so you'd think that I = would like it more than I do. However, there are far more relevant issues we could be discussing = besides the effort required to scroll through a post while on a mobile = device. For instance, how about Foundation-supported Project Ideas! I'll come back with some good suggestions that don't involve WordPress, = I promise ;) Cheers, -matt From nobody Thu Nov 25 10:27:28 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 171F118B20F2 for ; Thu, 25 Nov 2021 10:27:36 +0000 (UTC) (envelope-from paul.g.webster@googlemail.com) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 4J0DbC6gPVz4n2y; Thu, 25 Nov 2021 10:27:35 +0000 (UTC) (envelope-from paul.g.webster@googlemail.com) Received: by mail-wr1-x430.google.com with SMTP id d24so10602169wra.0; Thu, 25 Nov 2021 02:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=reply-to:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=PMW6mRDiyugnKq7Vrwic28JreOc+aaQ88mXEaYEyOKY=; b=fCx2KlSpdbfNvekPpMNtGe4c0s3fJjUiaqa7kb7cgh9GVlC2XTaPtzb6bA1wnA6oi2 fAGJNZvxN8+KfrFN13SsqJ63mU9k4X3e3zJKSnYf+8v6c6XwftDNZ5LecFzHKry97O0G KLuQmAnQmoKbNR36xiveYPvFP6VpVUDcAIfNILe3UQQM8cv/y+4cWwnMkW4YbZmj5STt /4VMNRUu0f3bHnlfPiFkOn6llx/soLhVLSOnvaCL+9TFraCWhSAzenGHvkxb7eezhFNB DbPiju9Z5PyZ0C7k5tUvsaAasdp0Pb30jsMtEW9KRrFO8mv4dHeS1lMhwN0tg2+0RTgI ClXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=PMW6mRDiyugnKq7Vrwic28JreOc+aaQ88mXEaYEyOKY=; b=aoYkMWs7SLWYusGmzyHWCnNRY0XiurO/7nGmSRlGVuN10E/84XzFYtOcctK8Pw2m5v VyzUBiDrS7LgEeQ/L3c0v9+qzzhd9cDHVu9oONyNcOovLRlkvAwKZb/MbzyP39y73jGE 3Ki/ugIfya2RLmwfFt5Fp/laicuxgUIsJqi2K7+VAINs9IvfrYF1mENU1Oq7reZkDBIC geLorv0NLFL5nf4KuGaW/kPPo5ynPqucQHvaaDWD7PsZYZyCn6cytXIi3cgDFb/FjCgb p/Ms9EB+jKRVlHsSXPDmnel26pMQEomRIye6o1JkAJztbfePFoBz7+CZ5+F4HWFyoHhT yO9g== X-Gm-Message-State: AOAM531DGSRznJQAnhC3S1r7ptk6a5+Zys2HBsStyVWqVAlsuXj8MM1V hGS3uGfLsXAoWbUIPkBKUr7gA1R713MJcQ== X-Google-Smtp-Source: ABdhPJyfcMcKv9q+sOp3Sr4mXenvVpmW8BMTZgyJ23aaJWxrtewEOax5gn57HAioAZ43PADfNTACJQ== X-Received: by 2002:a05:6000:1889:: with SMTP id a9mr5448211wri.68.1637836048626; Thu, 25 Nov 2021 02:27:28 -0800 (PST) Received: from PaulDesktop ([2a00:23c7:551f:f800:41df:609d:467e:b878]) by smtp.gmail.com with ESMTPSA id k27sm9298966wms.41.2021.11.25.02.27.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Nov 2021 02:27:28 -0800 (PST) Reply-To: From: To: "'Miroslav Lachman'" <000.fbsd@quip.cz>, "'Shawn Webb'" , "'Joseph Mingrone'" Cc: "'FreeBSD Hackers'" References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz> In-Reply-To: <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz> Subject: RE: Call for Foundation-supported Project Ideas Date: Thu, 25 Nov 2021 10:27:28 -0000 Organization: Paul Webster Message-ID: <006c01d7e1e7$0c30f8f0$2492ead0$@googlemail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJGF5QjmUftfKBheoi+SViUiLzunQI/G58dAsHZdpWrD5cdsA== X-Rspamd-Queue-Id: 4J0DbC6gPVz4n2y 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: N You can add Bhyve and IPFW to that list as well, though both are well documented good examples and guides that are not ancient and out of date are rare as gold dust. -----Original Message----- From: owner-freebsd-hackers@freebsd.org On Behalf Of Miroslav Lachman Sent: 25 November 2021 00:49 To: Shawn Webb ; Joseph Mingrone Cc: FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas On 24/11/2021 00:28, Shawn Webb wrote: [...] > 3. jail orchestration in base. it's great that we have all these > disparate jail management ports, but we lack a fully > coherent/integreated solution. I'd love to see jail orchestration > get the same love as zfs in base. While we are talking about jail orchestration in base (which will be really useful to me as well) I would like to see better integration of jail in more aspects in base. Jails are part of the base for more than a decade but still kind of hidden (similar to cpuset - many users don't know about it / how to use it easily). Alexander Leidinger posted proposal in 2019 "automatic jailing of services (rc.d/*)" [1] with patch [2]. This seems useful and easy to implement in base to me. As far as I know, Alexander also have patch to allow run Xorg in jail. As for cpuset thing - 11 years ago I proposed patch to add support for cpuset in rc.subr for any service [3] PR 142434 [4]. I think it is even more useful these days as computers have really a lot of CPU cores. [1] https://lists.freebsd.org/pipermail/freebsd-jail/2019-February/003710.html [2] https://pastebin.com/LBZRezgu [3] https://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001816.html [4] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=142434 Kind regards Miroslav Lachman From nobody Thu Nov 25 13:33:30 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F385B189BCDE for ; Thu, 25 Nov 2021 13:33:52 +0000 (UTC) (envelope-from dch@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 4J0Jk84j0Pz4mcd; Thu, 25 Nov 2021 13:33:52 +0000 (UTC) (envelope-from dch@freebsd.org) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: dch/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 806E8A837; Thu, 25 Nov 2021 13:33:52 +0000 (UTC) (envelope-from dch@freebsd.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 4E56927C0054; Thu, 25 Nov 2021 08:33:52 -0500 (EST) Received: from imap44 ([10.202.2.94]) by compute5.internal (MEProxy); Thu, 25 Nov 2021 08:33:52 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrhedtgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfffgrvhgv ucevohhtthhlvghhuhgsvghrfdcuoegutghhsehfrhgvvggsshgurdhorhhgqeenucggtf frrghtthgvrhhnpeegkefgieeiieekveehueevveduvdejkedvleeiffekheekleelvdfh hfduvdeggfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegutghhodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeijeekudekudeh vddquddvudefuddujeejqdgutghhpeepfhhrvggvsghsugdrohhrghesfhgrshhtmhgrih hlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 26D23FA0AA6; Thu, 25 Nov 2021 08:33:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: In-Reply-To: <246adde5-6a7a-4102-abb4-16c766ea78d1@freebsd.org> References: <861r36xzpe.fsf@phe.ftfl.ca> <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> <246adde5-6a7a-4102-abb4-16c766ea78d1@freebsd.org> Date: Thu, 25 Nov 2021 13:33:30 +0000 From: "Dave Cottlehuber" To: "Allan Jude" Cc: "FreeBSD Hackers" Subject: Re: Call for Foundation-supported Project Ideas Content-Type: text/plain ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637847232; 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=X0chI9CpvElwdf9JMs2rGTtdgsKIqrhl83wPclfP2xk=; b=vkc4agDCn4FpfflPXKURlks1rDHiq9xkQMclt5DwjiUwsopa4QqDMPyj2yN6gZqPGKTm6C Wlh1xzW069AYGcwPmd/MiXVUOjyFYYHKmIdoSiBAQobCe4+VoeXuVGDbrWl1NruCjfgn1s IRQYlyjQ6iy+nfXSZPvDw80tCYiAqVTABR1eed6qifmFfGmC8gTdl70s8hRgPhzVKG4S6q JdzuM2oXJFOcsRGOs9fpyC8GmDrR3EX0o6Yr/4q9aDUErS1JmtXsfXMx4eP66/r5YTR/wi Ot3d8ucuo3ysHz5lvn5cmqpKHpVaSl1cxpxy4uERb7LxPLXO0OfHbwHVwTc1KQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637847232; a=rsa-sha256; cv=none; b=tG5PpjnX7Pgh0lFPXDjao1ZsT+ptTH9jS+VS3symGx8p91WXmFWVyfXm+FaKNI13Pl2Bru Hrea3YzL3qu79ORKXOy9NAokrOUzBJfpcqVFRA1iy9FVgOi3RDv9mII3HnwURbQ1d3yYeC RYExwT46WYZcxpT0LOCW4HcXFEzsLUcMltIFY6PKqK+N70GIb9dTLX/9fYAURxeth5aljS KyQ4RULN8BGFYkGQvJ3WYeCI20F5MfGLrhqDUiB2Se6jMEVzydsTPoW1utc83kWtjz+KV3 94kxncn0hO7ZSyH2No8/5REB3Im8tvxGdd04AYMlIPyny6gJZPgHTkt7wBS11Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, 24 Nov 2021, at 21:46, Allan Jude wrote: > >> 3. jail creation and usage as non-root > > I was discussing the idea of 'user jails' with a few people around > EuroBSDcon. Do you have some specific user cases, and/or ideas of what > would be allowed and not allowed? My classic use case is that we do a bunch of CI-like stuff that requires: - the network stack & jailed pf rules are already set up in advance, as it doesn't change in practice for each jail - delegated zfs permissions to prepare a new jail from template - mount a few random things into it (tmpfs, nullfs & more zfs, no root reqd) - *now* I want a jail with the above prepared already the first 3 can be done already without root. I could totally live with that as bare bones, but bonus points for: - there should be an event (a la devd for example) on jail creation, & when the jail is complete (or a timeout has occurred) to clean up = running the entire jail as non-root and unable to escalate to root - a random uid for the jail user (not just inheriting *curent* user) - faking zfs permissions to match the random uid (e.g. on mount rewrite www:www as 8000:8000 instead) - setting more restrictions than than the user's jail already has (cpu/mem resource controls for example) A+ Dave From nobody Thu Nov 25 13:35:30 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 80CB6189EC99 for ; Thu, 25 Nov 2021 13:36:05 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 4J0Jmg3gY6z4nwS for ; Thu, 25 Nov 2021 13:36:03 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 598E53201C60 for ; Thu, 25 Nov 2021 08:35:56 -0500 (EST) Received: from imap44 ([10.202.2.94]) by compute5.internal (MEProxy); Thu, 25 Nov 2021 08:35:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=LksvXrP0Bqe5vcnXmKQkmQ4zPXQU0sH WwVDyy9V1mGg=; b=bjeGlsujdik54pCTUsitpDn9mJtK1k+vq6vBJ8a6q+efMtw CbArnHMj5Xg1scO8FdmJW6n+eQeHGNaVjPc7tPD/6sNaHKDPe8SUmliyj3yxBMb7 43UhPhR1i9cPnIVXI09kLOf2U1qiyjV5rX3qvrmCEVziM/XXAiV4qfhVyEzYwpy5 VRomR/aQmigqKxHeCUrwf9E8ctZvK8TBwF2Ntek+zpPeEHvf/dGX9yPoKJoy7DJ8 TIF80Z9ou16s0XS6coSW4C1T0XNagcE5XmyEt9SRInNhkyhxNIDId/40sEYqwrWL Hks0pnquRfFKVwPJr9WBylu5dZbHZO+x5Zkgo3Q== 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=LksvXr P0Bqe5vcnXmKQkmQ4zPXQU0sHWwVDyy9V1mGg=; b=iFYTkpdAMXvhx3ucHss7oo iTFyFQwpQiQHO2snZ/BBNDSF0g/x6mMog7kVLYSY4qWZHjLaXGAE+ludeQPtG744 ZpMNNywngqQpTFTI3V7ZSJTNkxhtSjlwlg3VbMlLMNriZ9Ai9hxraKRP8rF8nNUS meuGpTQ6PhSFaSz9j4AT/C4ZY2jQVFx7Cq3Lgr1FC9fBEtvu0/7an5bqZ++dDZmf PBO+dh1TknT2W0viluE8xU3Q2mBLuYhs1cMtmf1q6oT+rOgnj0B+N66n4Fumh6De Yf/KnrzDLIKdhuqqM4UA/TJXYy+4Cw2FgTlrW4jBUVaxjjl6zusH+oQrxJyu7uIw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrhedtgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfffgrvhgv ucevohhtthhlvghhuhgsvghrfdcuoegutghhsehskhhunhhkfigvrhhkshdrrghtqeenuc ggtffrrghtthgvrhhnpeekffefvdefteekffeggfffvdefuefguefhhffhudefvdetgfei leeujeffhedvjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegutghhsehskhhunhhkfigvrhhkshdrrght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 64325FA0AA7; Thu, 25 Nov 2021 08:35:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: <7603b22e-e1a1-4fc7-a508-037fec55e0cf@www.fastmail.com> In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <105ed883-06ae-d801-2bde-05d78d31f233@grosbein.net> Date: Thu, 25 Nov 2021 13:35:30 +0000 From: "Dave Cottlehuber" To: "FreeBSD Hackers" Subject: Re: Top posting Content-Type: text/plain X-Rspamd-Queue-Id: 4J0Jmg3gY6z4nwS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=bjeGlsuj; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=iFYTkpdA; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 64.147.123.25 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-1.91 / 15.00]; XM_UA_NO_VERSION(0.01)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.79)[-0.787]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; 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.25:from]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[dch]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[skunkwerks.at]; NEURAL_SPAM_MEDIUM(0.47)[0.468]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N +0 the only useful reply to a top/bottom posting thread is one that has no context and only a single line anyway thus illustrating the sheer absurdity From nobody Thu Nov 25 14:28:45 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 375F018B82E7 for ; Thu, 25 Nov 2021 14:29:19 +0000 (UTC) (envelope-from darcy@druid.net) Received: from mail.vex.net (mail.vex.net [98.158.132.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4J0Ky53XlKz3NRs for ; Thu, 25 Nov 2021 14:29:17 +0000 (UTC) (envelope-from darcy@druid.net) Received: from [100.77.135.237] (unknown [98.186.197.13]) (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) (Authenticated sender: druid) by mail.vex.net (Postfix) with ESMTPSA id 6775749FAE for ; Thu, 25 Nov 2021 09:28:49 -0500 (EST) Message-ID: <7cbaaa0d-a965-85d8-f860-3b32c7efb4f7@druid.net> Date: Thu, 25 Nov 2021 08:28:45 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Top posting Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <105ed883-06ae-d801-2bde-05d78d31f233@grosbein.net> <7603b22e-e1a1-4fc7-a508-037fec55e0cf@www.fastmail.com> From: D'Arcy Cain In-Reply-To: <7603b22e-e1a1-4fc7-a508-037fec55e0cf@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------JJwRUXqVkuw01d9393kWj7I6" X-Rspamd-Queue-Id: 4J0Ky53XlKz3NRs X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of darcy@druid.net has no SPF policy when checking 98.158.132.68) smtp.mailfrom=darcy@druid.net X-Spamd-Result: default: False [-0.56 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; SIGNED_PGP(-2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:19842, ipnet:98.158.132.0/24, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[98.186.197.13:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.55)[-0.550]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[druid.net]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.99)[0.991]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------JJwRUXqVkuw01d9393kWj7I6 Content-Type: multipart/mixed; boundary="------------kkWaJ20FytWoiB56BNk5AL3c"; protected-headers="v1" From: D'Arcy Cain To: freebsd-hackers@freebsd.org Message-ID: <7cbaaa0d-a965-85d8-f860-3b32c7efb4f7@druid.net> Subject: Re: Top posting References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <105ed883-06ae-d801-2bde-05d78d31f233@grosbein.net> <7603b22e-e1a1-4fc7-a508-037fec55e0cf@www.fastmail.com> In-Reply-To: <7603b22e-e1a1-4fc7-a508-037fec55e0cf@www.fastmail.com> --------------kkWaJ20FytWoiB56BNk5AL3c Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTEvMjUvMjEgMDc6MzUsIERhdmUgQ290dGxlaHViZXIgd3JvdGU6DQo+ICswIHRoZSBv bmx5IHVzZWZ1bCByZXBseSB0byBhIHRvcC9ib3R0b20gcG9zdGluZyB0aHJlYWQgaXMgb25l IHRoYXQgaGFzIG5vIGNvbnRleHQgYW5kIG9ubHkgYSBzaW5nbGUgbGluZSBhbnl3YXkgdGh1 cyBpbGx1c3RyYXRpbmcgdGhlIHNoZWVyIGFic3VyZGl0eQ0KDQpUaGUgc3VnZ2VzdGlvbiBp cyB0byB0cmltLCBub3QgZ3V0Lg0KDQotLSANCkQnQXJjeSBKLk0uIENhaW4gPGRhcmN5QGRy dWlkLm5ldD4gICAgICAgICB8ICBEZW1vY3JhY3kgaXMgdGhyZWUgd29sdmVzDQpodHRwOi8v d3d3LmRydWlkLm5ldC9kYXJjeS8gICAgICAgICAgICAgICAgfCAgYW5kIGEgc2hlZXAgdm90 aW5nIG9uDQorMSA0MTYgNzg4IDIyNDYgICAgIChEb0QjMDA4MikgICAgKGVOVFApICAgfCAg d2hhdCdzIGZvciBkaW5uZXIuDQpJTTogZGFyY3lAVnliZU5ldHdvcmtzLmNvbSwgVm9JUDog c2lwOmRhcmN5QGRydWlkLm5ldA0K --------------kkWaJ20FytWoiB56BNk5AL3c-- --------------JJwRUXqVkuw01d9393kWj7I6 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQSQJTNYM0vv3aTmBCs/5DDweYZnXQUCYZ+dnQUDAAAAAAAKCRA/5DDweYZnXZmb AP9+q5ZK2vNuX55OWOVLB8iDk8wdZsKyRn8AQ62UWr0eagD9GBcH9NGfS5ARqcuqCDpX7/YtaeHZ 8ugPzS549qImygw= =UNWg -----END PGP SIGNATURE----- --------------JJwRUXqVkuw01d9393kWj7I6-- From nobody Thu Nov 25 18:37:29 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3706818A0498 for ; Thu, 25 Nov 2021 18:37:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 4J0RT04gFXz4YWh for ; Thu, 25 Nov 2021 18:37:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f43.google.com with SMTP id k21so8630575ioh.4 for ; Thu, 25 Nov 2021 10:37:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fASI5osCcSsnnzSY1BopPMlyVGQQR5TVltN+3ly8kP4=; b=KeIyoOchSj+r1Z2yuyWHJcdAZtWg2SDDcNmOKzz/lXg77MeLDL5VjzZwXfMufyaWRt QnN7u1R9wWMfic/a2FESAGFhqPPAXiCxFImWTYVuXcUxpho/4IVKCLKdRoBSlF8xcXob 6qresufbpiK3KJRpmlMmtf+gMzko3119eSXGH8IWdAgbNhJoRMJZmyeYV4BFxyyAcMWF Uw6Xg6aGlKHZWWWM9MwlgRyoYaF0Pj+R71K3Ew5cZrg7nwQEl2vCB9jE8zqmhp80vaeh 1CxLNMcrQPyAsxrX1hnBBP9wTMSP+3naHtmMT4x6bwICjQWIrwfcKM9mVfT3O1YIdI7M b4aw== X-Gm-Message-State: AOAM531OJlUsgPe0X5Rc4xJYweoujsybNsnYOwpOlQ5s7n73nCWnijP3 pCWUQrchF/wmTr28e2bcgT5V9ea2rz9eVEwZfnnjWwmVEG0= X-Google-Smtp-Source: ABdhPJyDH29hAAp5Fhqnl4YDIE0dezc2YC+SKrvCQ08hennwxO1aJzEoXo66z9+MpbxoCorxDWsQ/JuieBzJOUX78JY= X-Received: by 2002:a5e:9b0e:: with SMTP id j14mr28118714iok.127.1637865469332; Thu, 25 Nov 2021 10:37:49 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Ed Maste Date: Thu, 25 Nov 2021 13:37:29 -0500 Message-ID: Subject: Retiring WITHOUT_CXX To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J0RT04gFXz4YWh 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.43 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.04 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.59)[0.587]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.994]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.43:from]; NEURAL_HAM_MEDIUM(-0.63)[-0.629]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.43:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Several base system components are written in C++, and the WITHOUT_CXX option is not regularly tested and is often broken. I fixed a number of WITHOUT_CXX issues in response to Michael Dexter's recent Build Option Survey runs, but it will break again absent ongoing effort. This does not seem like a useful endeavour given the limitations it imposes on the resulting system. I'm proposing we remove the WITHOUT_CXX option and have opened a review to do so: https://reviews.freebsd.org/D33108 From nobody Thu Nov 25 18:39:11 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2025418A1C20 for ; Thu, 25 Nov 2021 18:39:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0RVy51v0z4ZgL; Thu, 25 Nov 2021 18:39:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f180.google.com with SMTP id t8so6682539ilu.8; Thu, 25 Nov 2021 10:39:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gyx/eiC/tGNJ8OvJRC70Nl3FfagXMvwyN9BiSDgfidM=; b=oFo+bS5cu3on94DUMexQ7w7oN2m+/DPeQUz28wq56aTZXbxhcWcfwhlSa3sfCcYB70 xneyahUlEVPvxZr6Zl0w44EiZk42ErU3fj28mZNLAecDrlYDVyHb02/SRQulRRYj31/9 FmSSw7r53csqDCYYPh8N0rrIKBK/TiSKiw/WJpvGhcE4hpAlHWWLTds9/ZlbNINbrWf6 eUHj8k6xdvw3+thVDXLoS/cwlwaiSdGs1YtQTRtWWweMflhljljmXe5asA3+pptLlk1h +b42i5aiYdkZ31wmHGmVW76YgybjfwNrwsbAJyAJkLOOY5fdwBimRTdYbk4Bh2G5/Cv3 NZiA== X-Gm-Message-State: AOAM532/xmk6oFr1fP/pLYQISoJj2amrtP05Dny20p5QPQh32YT4d5zs x2AubdlHpGmXpov6uMc9ntSNphlh0gQOWu1OBpbsdZCH X-Google-Smtp-Source: ABdhPJz6Q1ezYRRmRh/MbFk6n9y8oby1jvIjq7lEmJeEtTTlYEYzjgdGpazaa2b+LdLPM7W26//vsf0pqV7aJGMvqFc= X-Received: by 2002:a05:6e02:1487:: with SMTP id n7mr22243385ilk.252.1637865571457; Thu, 25 Nov 2021 10:39:31 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: From: Ed Maste Date: Thu, 25 Nov 2021 13:39:11 -0500 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: "Piotr P. Stefaniak" Cc: Joseph Mingrone , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J0RVy51v0z4ZgL 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.180 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.81 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.59)[-0.585]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.23)[-0.229]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.180:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.180: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]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Wed, 24 Nov 2021 at 03:01, Piotr P. Stefaniak wrote: > > Let me ask a question instead. There are two tracking bugs for > FreeBSD-Foundation sponsored issues for FreeBSD: 203349 and 231027. > Would it make sense to add all tracked bugs from 203349 to 231027 and > close the former as a duplicate of the latter? All of the still-open bugs in 203349 were already in 231027, and I've now closed the former. From nobody Thu Nov 25 20:00:53 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8E48D18B3D79 for ; Thu, 25 Nov 2021 20:01:07 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0TJy5CjRz3PHM; Thu, 25 Nov 2021 20:01:06 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-ed1-x530.google.com with SMTP id w1so29946680edc.6; Thu, 25 Nov 2021 12:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XO7zoK7eoBDtSsDbdpsPEL0+nS/bjX7+2t1Qm+c8rDA=; b=aFEP/0mN27Ta4VldF0Az8lQWOMKVvfrhiTFtMhOWm764vm6vwB9O+ZTGQ8MXi79lji S/39qHJU45f0bGmXyxZf5ofw0gJcU2AV58y/LqI0shBU/2ykuagPh+GGHpTTS/p//H6f +BCqZDKB5i+JhDSAxSIlOd3fUlKDlk2aFLzELDSgw/U/L0KUDJQMrd25viLzasLEtncq Rjv3UHeb2DFxGAp1DB+dj8n8UlEhY0g2OBoTuF+3EAgfusxrlMnz+rL9JmPVya2PpCZ3 SQUyoNLxG8Q0+fRmKCILJ6T7Cnqkg2qOzCFgFboifTpn4twu4B+a2s0hb9JfrFin77EJ PzEw== 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=XO7zoK7eoBDtSsDbdpsPEL0+nS/bjX7+2t1Qm+c8rDA=; b=Yjf0AFg16hNQHgt0dbbYA8bceXXNVZnfmUjZ7Fnxe6OdSUAiWj8nNtaNUQsue0iU8V 2CmeqkXSZG5fz4pRIH8YyPVwkJaPHhznoatrawPCqYrohWD2Ot7xeU0wM9r190wtkRjy J0OBTjYYjE3cUkn3yv9LLTJKLVyRt+DCogg/89HwDVDmF87FxSlf/CeN+AT5NMkBdiM1 G4gdR1bH3lC6kfQcaOPI85JDmHuhWz3WL534Q7KJqEeR/vdNAW+6f8ML+xeGgrL1Ym8K rb5q2QI/VRNTDli/FDp7K2VSDwjXNIo+sHL6CQAyV8C+uq8ctmC6xQl/A+jj6NxftAWS 5cGQ== X-Gm-Message-State: AOAM5300mwp1JFYFKeeDNEvMIySJvbF4KrCTLK4FaLlzyoS3TZsM4FsW qmaGQdiX0NEpbrGYMZGK0oncAnkAQccB1udGSg6hupTaTwg= X-Google-Smtp-Source: ABdhPJzEvdIdx+zXiRiCfDp1grhausb3Tv9W99+oJWWQLENt+x2mMEerw9J9j7Uzotp46xNiXIWSKcnf85GsxLmcI3Q= X-Received: by 2002:a17:906:81cb:: with SMTP id e11mr33707731ejx.186.1637870465212; Thu, 25 Nov 2021 12:01:05 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> From: Pavel Timofeev Date: Thu, 25 Nov 2021 13:00:53 -0700 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000044674405d1a26f20" X-Rspamd-Queue-Id: 4J0TJy5CjRz3PHM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="aFEP/0mN"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of timp87@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=timp87@gmail.com X-Spamd-Result: default: False [-1.76 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.70)[-0.702]; NEURAL_SPAM_MEDIUM(0.95)[0.946]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --00000000000044674405d1a26f20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=82, 23 =D0=BD=D0=BE=D1=8F=D0=B1. 2021 =D0=B3. =D0=B2 15:41, Josep= h Mingrone : > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) > > I saw that desktop is kind of a priority for FreeBSD now. My idea is to fix pcm/sound to play nice with dynamically appearing and disappearing audio devices. Right now it's a pain if you have a laptop and an usb headset. Once the usb headset device is attached and chosen, then if WM is started you can't detach the headset= . Otherwise it will make your system a brick spitting "Waiting for sound application to exit!" messages. This is a problem not only for people using usb headsets, but also those who have a dock station which may have HDMI ports as it registers them as audio devices. You can't even easily send your laptop to sleep with this bug. I know, there are workarounds, like this one https://forums.freebsd.org/threads/forcing-off-the-computer-endlessly-waiti= ng-for-sound-application-to-exit-at-sleep-suspend-time.80412/ But it's rather a dirty workaround which is error prone. --00000000000044674405d1a26f20-- From nobody Thu Nov 25 21:45:23 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C52118C5A10 for ; Thu, 25 Nov 2021 21:45:34 +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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0WdV3P8Mz4jhd for ; Thu, 25 Nov 2021 21:45:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92b.google.com with SMTP id j14so14831926uan.10 for ; Thu, 25 Nov 2021 13:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fnhiRc5F78RX+cfsNw3GHLV8pUVVnCvppNBA4IEPNvE=; b=nM+05AJf7Xs1GKIEp5MhS8hlFitNHEGrAfUJv1+UH+5gggB3YXTybajojZNjvYc53J FibEEeqVmlLtj6B6H/SqppBzUUbDquDAFkAsuIHPFBZi8Zwqlr6VWK2vR+YKyezGrzJL KELX6JWlUPo9kB6h9SLTGdPBkvbRSR5xEi5bl9/W4rY7AR8bpMBMsQdwLdY84gevTXWM TB5JSccQnhYRevFxrFJgl4BHJUY0O7SnDSmr3X9i1LcVjAY/nk+9+voD6mGGdI0bz4UD of4MuWCt2Jwsq+pxSYc+ZQAAxgoDnlQ0NSpJahcXe3e+4TVFUVAYbnFrkqC9PfMkYFw0 iZ0g== 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=fnhiRc5F78RX+cfsNw3GHLV8pUVVnCvppNBA4IEPNvE=; b=MlR5BvYj3iJirLzql4EuzHscADo9+l2SNus6K+uqLqTBvKKjX/sdD+Mr0j3FMbed3p 3I0gva5jcEV+rhYqp7Cf/ZexocX0PXLM4A4wLpm+LmN3LnO+esW2zPPgb2eazuf92L6+ b9kn/gEBJ99dVD1S1Bz81hreD4Tcx1KDzev+wTyd034ib97ZSRL9wxtNe5bp6Ng07An2 on+CGw1C4l3u6pxDFggatzgD1ESS/C5ArV/EfkbfUf/ihjMpO+M9kVNF9fhp/gGfPLrI e1eEMweaCOmt12aSiPHmtrBLtlJI6cXyLkUpe5fGMkSahqeXn4tmxcw5gjU0Dg7C4JjL TqUw== X-Gm-Message-State: AOAM531ioI2mbt8JFBjFUI7riMb7B93nzTJMMvKkMm5ZZFyEOpZ7W0aF Zq/y1aVeAibDIKd66g4NXLrvkR3lIZRWzy+uJffIkQ== X-Google-Smtp-Source: ABdhPJzSNu2DhCaANxkSnVQrB87EbLNQttcEsY7MKCHX4ipNrsDKjuSukmcxgaAHnzqKF3jueZg3b8dxjiXtXCydRzY= X-Received: by 2002:a9f:21d7:: with SMTP id 81mr30737965uac.39.1637876733929; Thu, 25 Nov 2021 13:45:33 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 25 Nov 2021 14:45:23 -0700 Message-ID: Subject: Re: Retiring WITHOUT_CXX To: Ed Maste Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000e9ac8605d1a3e452" X-Rspamd-Queue-Id: 4J0WdV3P8Mz4jhd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000e9ac8605d1a3e452 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 25, 2021 at 11:39 AM Ed Maste wrote: > Several base system components are written in C++, and the WITHOUT_CXX > option is not regularly tested and is often broken. I fixed a number > of WITHOUT_CXX issues in response to Michael Dexter's recent Build > Option Survey runs, but it will break again absent ongoing effort. > This does not seem like a useful endeavour given the limitations it > imposes on the resulting system. > > I'm proposing we remove the WITHOUT_CXX option and have opened a > review to do so: https://reviews.freebsd.org/D33108 We've grown enough C++ support this is likely sane. Warner --000000000000e9ac8605d1a3e452-- From eugen@grosbein.net Thu Nov 25 21:51:53 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0218318A1916 for ; Thu, 25 Nov 2021 21:52:16 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0WnC5Gt0z4mmN; Thu, 25 Nov 2021 21:52:15 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1APLq3H0047146 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Nov 2021 21:52:04 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: imp@bsdimp.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1APLq2fa059460 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Nov 2021 04:52:02 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Retiring WITHOUT_CXX To: Warner Losh , Ed Maste References: Cc: FreeBSD Hackers From: Eugene Grosbein Message-ID: <13a7b078-9e53-6bc2-a94e-b366ac1413dd@grosbein.net> Date: Fri, 26 Nov 2021 04:51:53 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J0WnC5Gt0z4mmN 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 26.11.2021 4:45, Warner Losh wrote: >> Several base system components are written in C++, and the WITHOUT_CXX >> option is not regularly tested and is often broken. I fixed a number >> of WITHOUT_CXX issues in response to Michael Dexter's recent Build >> Option Survey runs, but it will break again absent ongoing effort. >> This does not seem like a useful endeavour given the limitations it >> imposes on the resulting system. >> >> I'm proposing we remove the WITHOUT_CXX option and have opened a >> review to do so: https://reviews.freebsd.org/D33108 > > > We've grown enough C++ support this is likely sane. How embedded-friendly is this? I mean a difference in required space for self-contained small file system. Comparing with 8.x/9.x, minimal FreeBSD image become pretty big. From nobody Thu Nov 25 22:16:37 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CA1DF18AF91E for ; Thu, 25 Nov 2021 22:17:05 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (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 4J0XKs4mr5z3BsV for ; Thu, 25 Nov 2021 22:17:05 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f181.google.com with SMTP id h16so6292210ila.4 for ; Thu, 25 Nov 2021 14:17:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HojAaXR9kufb1stNw5MGtuqqxJFce2fDY5yHot7Z+3M=; b=e4fnxVLUj46nRHNF22sIktIX3fO5p5yZWMJ1iGG/YOsPwX3e00k0GUUruDF6TAGgSB fCSlBmrESHrIElQgn2AuJ+uxkeSWLlPstmO+ffJCYk5Cb/V/UNmWv8IT2JYd5jPvDFvT VtsXVNebaiMs76XNtc89dd0aPZZtpCzedzg3cwg0bBbWiwOiNcOtft4f6pQtoMDRML/q HYZhyafI2WutT1pJ5vrB08DIameZaa/yoCA6sqeCvsJrYymgUhX3e80nc/+4nIFtYb80 ZX0QV1OkZESzB7y3ujfgmS6Ctn5q51B9D9Iw9m/hiInPRlh7XHNihBvBx/6S5kGEKMDz m2bg== X-Gm-Message-State: AOAM5314plwz2CR8EuurAGP6lwmqX8YpDn5tMpxKEa35A9dvrAHaPp9X i0wyWpbRXPizZCx/EX+Kl1qHqfxCN34zHT7ihitwTLUl X-Google-Smtp-Source: ABdhPJzWNI9jAFf9G/U0L7uvqO5XRFiCpdFwd+3mClYU5en3ctlv8fZSruJS0leGTnzyXGO1LvLsoT8bvF0DP88+Jrs= X-Received: by 2002:a92:dc8d:: with SMTP id c13mr27240345iln.75.1637878619202; Thu, 25 Nov 2021 14:16:59 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <13a7b078-9e53-6bc2-a94e-b366ac1413dd@grosbein.net> In-Reply-To: <13a7b078-9e53-6bc2-a94e-b366ac1413dd@grosbein.net> From: Ed Maste Date: Thu, 25 Nov 2021 17:16:37 -0500 Message-ID: Subject: Re: Retiring WITHOUT_CXX To: Eugene Grosbein Cc: Warner Losh , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J0XKs4mr5z3BsV 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 Thu, 25 Nov 2021 at 16:52, Eugene Grosbein wrote: > > 26.11.2021 4:45, Warner Losh wrote: > > > > We've grown enough C++ support this is likely sane. > > How embedded-friendly is this? I mean a difference in required space for self-contained small file system. > Comparing with 8.x/9.x, minimal FreeBSD image become pretty big. I'm not really concerned about this with respect specifically to WITHOUT_CXX. Of course it's important to support small images, but we need to do so via pkgbase, nanobsd, etc., rather than poorly-maintained build knobs. (Knobs like WITHOUT_INCLUDES are built into our make infrastructure, and are fine.) From nobody Thu Nov 25 22:18:51 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 657DA18B0A5F for ; Thu, 25 Nov 2021 22:19:00 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 4J0XN40yynz3DGL; Thu, 25 Nov 2021 22:18:59 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 348E716056; Thu, 25 Nov 2021 23:18:52 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 9C24320BE; Thu, 25 Nov 2021 23:18:51 +0100 (CET) Date: Thu, 25 Nov 2021 23:18:51 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: FreeBSD Hackers Cc: Miroslav Lachman <000.fbsd@quip.cz>, Shawn Webb , Joseph Mingrone Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211125221851.RUtyA%steffen@sdaoden.eu> In-Reply-To: <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz> References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz> Mail-Followup-To: FreeBSD Hackers , Miroslav Lachman <000.fbsd@quip.cz>, Shawn Webb , Joseph Mingrone User-Agent: s-nail v14.9.23-159-gccc1ac94e1 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4J0XN40yynz3DGL 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 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Miroslav Lachman wrote in <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz>: |On 24/11/2021 00:28, Shawn Webb wrote: | |[...] | |> 3. jail orchestration in base. it's great that we have all these |> disparate jail management ports, but we lack a fully |> coherent/integreated solution. I'd love to see jail orchestration |> get the same love as zfs in base. | |While we are talking about jail orchestration in base (which will be |really useful to me as well) I would like to see better integration of |jail in more aspects in base. Jails are part of the base for more than a |decade but still kind of hidden (similar to cpuset - many users don't |know about it / how to use it easily). | |Alexander Leidinger posted proposal in 2019 "automatic jailing of |services (rc.d/*)" [1] with patch [2]. This seems useful and easy to |implement in base to me. |As far as I know, Alexander also have patch to allow run Xorg in jail. | |As for cpuset thing - 11 years ago I proposed patch to add support for |cpuset in rc.subr for any service [3] PR 142434 [4]. I think it is even |more useful these days as computers have really a lot of CPU cores. All that is really great. I have seen pkg got some jail-specific improvements not too long ago. What i always found desirable would be data sharing, without full population of the file system; i.e., the jail overlays the base filesystem via null mounts, and only gets writable storage for dynamic data where desired. What would be even more cool would be if most of the filesystem would be hidden upon request, you know, you give the name of the pkgs you want, and the rest gets automatically removed; or even better, you start with anything whiteout, and only un-whiteout desired pkg content. Anyway like that disk space is saved, and all jails (managed like that) automatically operate with the same set of files as the base system does. And for some base-system daemons predefined configs could be made available, just enough to get them work; and some ports could ship with the according recipe too; now that there is pkg everywhere. (You know, i dreamed of that when jails came first, was this in 2004 with 5.3? I still think it would be cool!) |[1] |https://lists.freebsd.org/pipermail/freebsd-jail/2019-February/003710.html |[2] https://pastebin.com/LBZRezgu |[3] https://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001816.html |[4] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=142434 | |Kind regards |Miroslav Lachman | --End of <6f33be37-a7c1-6217-8646-30b7c0306226@quip.cz> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Nov 25 23:48:16 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C6BC418BADB7 for ; Thu, 25 Nov 2021 23:48:27 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4J0ZMG4Gmqz4RdC; Thu, 25 Nov 2021 23:48:26 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) by lax.lemis.com (Postfix) with ESMTP id 1E784280DD; Thu, 25 Nov 2021 23:48:17 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 6F3932635BF; Fri, 26 Nov 2021 10:48:16 +1100 (AEDT) Date: Fri, 26 Nov 2021 10:48:16 +1100 From: Greg 'groggy' Lehey To: Graham Perrin Cc: FreeBSD Hackers , Joseph Mingrone , Mehmet Erol Sanliturk Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) Message-ID: <20211125234816.GE96868@eureka.lemis.com> References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J4XPiPrVK1ev6Sgr" Content-Disposition: inline In-Reply-To: <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4J0ZMG4Gmqz4RdC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-2.93 / 15.00]; ARC_NA(0.00)[]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.13)[-0.133]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com] X-ThisMailContainsUnwantedMimeParts: N --J4XPiPrVK1ev6Sgr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wednesday, 24 November 2021 at 21:33:50 +0000, Graham Perrin wrote: > On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: >> Change policy about discouraging top posting and convert it to encouragi= ng >> top posting > > Please, don't. Agreed entirely in this context. But what are we talking about here? Mehmet refers to a policy, but who has read it? My guess is that his real issue is "bottom posting", which is arguably even worse than "top posting". In each case, the reply is separate =66rom the original, and the only difference is where you find it. But that's not what the policy says. As I know it, it's at the end of https://docs.freebsd.org/en/articles/freebsd-questions/ and obviously refers to that mailing list, but in principle it applies to any mailing list or even private exchanges. Trimming (of course!): Unless there is a good reason to do otherwise, reply to the sender and to FreeBSD-questions. Many people on the FreeBSD-questions are "lurkers": they learn by reading messages sent and replied to by others. If you take a message which is of general interest off the list, you are depriving these people of their information. Be careful with group replies; lots of people send messages with hundreds of CCs. If this is the case, be sure to trim the Cc: lines appropriately. Include relevant text from the original message. Trim it to the minimum, but do not overdo it. It should still be possible for somebody who did not read the original message to understand what you are talking about. Use some technique to identify which text came from the original message, and which text you add. I personally find that prepending =E2=80=9C>=E2=80=9D to the original message works best. Leaving white spa= ce after the =E2=80=9C> ;=E2=80=9D and leave empty lines between your text and the= original text both make the result more readable. Put your response in the correct place (after the text to which it replies). It is very difficult to read a thread of responses where each reply comes before the text to which it replies. If the submitter did not abide by format conventions (lines too long, inappropriate subject line) please fix it. In the case of an incorrect subject line (such as "HELP!!??"), change the subject line to (say) "Re: Difficulties with sync PPP (was: HELP!!??)". That way other people trying to follow the thread will have less difficulty following it. It's over 20 years old, but I still believe that it is correct. It also should work for mobile phones, better than "top posting". Comments? Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php --J4XPiPrVK1ev6Sgr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmGgIMAACgkQIubykFB6QiONigCfc8MnwEi/8hrgDd9sY9D+zjrw Mc0Amwe4nebp7dTwgDEgOT6HDl65y2Dl =zprR -----END PGP SIGNATURE----- --J4XPiPrVK1ev6Sgr-- From eugen@grosbein.net Fri Nov 26 02:38:55 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7BCE18BAFD2 for ; Fri, 26 Nov 2021 02:39:12 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0f8J38vMz3qHq; Fri, 26 Nov 2021 02:39:12 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AQ2d5d7047806 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Nov 2021 02:39:06 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: emaste@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AQ2d5C5061864 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Nov 2021 09:39:05 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Retiring WITHOUT_CXX To: Ed Maste References: <13a7b078-9e53-6bc2-a94e-b366ac1413dd@grosbein.net> Cc: Warner Losh , FreeBSD Hackers From: Eugene Grosbein Message-ID: <84615b2d-b9cd-708f-78f8-c52fadb71d18@grosbein.net> Date: Fri, 26 Nov 2021 09:38:55 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J0f8J38vMz3qHq 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 26.11.2021 5:16, Ed Maste wrote > On Thu, 25 Nov 2021 at 16:52, Eugene Grosbein wrote: >> >> 26.11.2021 4:45, Warner Losh wrote: >>> >>> We've grown enough C++ support this is likely sane. >> >> How embedded-friendly is this? I mean a difference in required space for self-contained small file system. >> Comparing with 8.x/9.x, minimal FreeBSD image become pretty big. > > I'm not really concerned about this with respect specifically to WITHOUT_CXX. > > Of course it's important to support small images, but we need to do so > via pkgbase, nanobsd, etc., rather than poorly-maintained build knobs. > (Knobs like WITHOUT_INCLUDES are built into our make infrastructure, > and are fine.) I use nanobsd to build my images and knobs are main tool for nanobsd (though not only) to exclude unneeded parts of system from resulting image. That's why I have asked. From nobody Fri Nov 26 05:01:23 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7DEE18B76DE for ; Fri, 26 Nov 2021 05:01:33 +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 4J0jJX6XZdz51k5; Fri, 26 Nov 2021 05:01:32 +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 1AQ51Oqe099522; Fri, 26 Nov 2021 05:01:24 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 1AQ51NCR099521; Fri, 26 Nov 2021 05:01:23 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202111260501.1AQ51NCR099521@donotpassgo.dyslexicfish.net> Date: Fri, 26 Nov 2021 05:01:23 +0000 Organization: Dyslexic Fish To: m.e.sanliturk@gmail.com, grahamperrin@gmail.com Cc: jrm@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 26 Nov 2021 05:01:25 +0000 (GMT) X-Rspamd-Queue-Id: 4J0jJX6XZdz51k5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.56 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.86)[-0.859]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; 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:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Mehmet Erol Sanliturk wrote: > (1) persons tracking messages continuously do not need to read the same > texts many times I agree, so in that case DELETE the quoted text, if it's not relevent to context. > (2) persons tracking messages continuously are forced to move the cursor at > the end of long messages . This is > taking unnecessarily long times which is a waste of time and difficult > in cell phones I find that annoying on a cell phone - when people "top post" and then quote the whole message below, and I have to scroll through it all to see if there's anything I'm missing. > (3) if links to the previous messages are used , it is not important to > place of the current message Then don't quote the reply at all. It's that simple. > (4) I am a subscriber of many mailing lists . Most of them are using top > posting . FreeBSD convention is only an > annoyance for persons continuously reading messages ( some may think in > a different way , obviously we will welcome > their ideas ) . Bottom posting is a reward to the persons occasionally > reading the messages , a punishment > to the persons continuously reading messages . This is not a fair > behavior toward the interested persons to And they are wrong. In fact, the reasons I'm not more active in these FreeBSD lists is precisely because of all the top-posting that goes on here. There was a time people would be blasted for posting so inconsiderately. What you don't get is that the whole point of quoting is to do it selectively, to give context to the reply. Just like I'm doing now. You shouldn't blindly quote the whole message - either at the top or the bottom - that's just dumb. > Therefore , insisting on historically used conventions which are not useful > in these days will not supply any benefit to the > FreeBSD other than lowering the number of interested users , causing not > participating in its components such as mailing lists . The "historical" convention is indeed useful if done properly. You don't appear to understand what the "historical" convention is. Stop turning every message into an annoying upside down chain-mail. Quote selectively, and in context. It's logical, pretty obvious, and correct. Jamie From nobody Fri Nov 26 05:21:03 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5A3331898209 for ; Fri, 26 Nov 2021 05:21:05 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4J0jl51Fx3z56Mq; Fri, 26 Nov 2021 05:21:04 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) by lax.lemis.com (Postfix) with ESMTP id C090A28034; Fri, 26 Nov 2021 05:21:03 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 1BDCE2635BF; Fri, 26 Nov 2021 16:21:03 +1100 (AEDT) Date: Fri, 26 Nov 2021 16:21:03 +1100 From: Greg 'groggy' Lehey To: Jamie Landeg-Jones Cc: m.e.sanliturk@gmail.com, grahamperrin@gmail.com, jrm@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) Message-ID: <20211126052103.GF96868@eureka.lemis.com> References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <202111260501.1AQ51NCR099521@donotpassgo.dyslexicfish.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="twz1s1Hj1O0rHoT0" Content-Disposition: inline In-Reply-To: <202111260501.1AQ51NCR099521@donotpassgo.dyslexicfish.net> Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4J0jl51Fx3z56Mq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --twz1s1Hj1O0rHoT0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 26 November 2021 at 5:01:23 +0000, Jamie Landeg-Jones wrote: > What you don't get is that the whole point of quoting is to do it selectively, > to give context to the reply. Just like I'm doing now. Right. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php --twz1s1Hj1O0rHoT0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmGgbr4ACgkQIubykFB6QiOpGQCgp75/qHPuH+lJcd6QBd3OxUu2 5rcAmwZjKJCyGNhALib6RW7IdH4k9bOu =/kbp -----END PGP SIGNATURE----- --twz1s1Hj1O0rHoT0-- From nobody Fri Nov 26 09:09:21 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 305C118A45AA for ; Fri, 26 Nov 2021 09:09:30 +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 4J0ppd5KFnz3FfY; Fri, 26 Nov 2021 09:09:29 +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 1AQ99Le6023878; Fri, 26 Nov 2021 01:09:21 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 1AQ99LY2023877; Fri, 26 Nov 2021 01:09:21 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> Subject: Re: Retiring WITHOUT_CXX In-Reply-To: To: Ed Maste Date: Fri, 26 Nov 2021 01:09:21 -0800 (PST) CC: FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4J0ppd5KFnz3FfY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > Several base system components are written in C++, and the WITHOUT_CXX > option is not regularly tested and is often broken. I fixed a number That is not a true statement, the WITHOUT_CXX option is regularly tested, as that is why Michael Dexter has reported that it is broken, as he *regularly* runs the Build Option Survey. > of WITHOUT_CXX issues in response to Michael Dexter's recent Build > Option Survey runs, but it will break again absent ongoing effort. > This does not seem like a useful endeavour given the limitations it > imposes on the resulting system. > > I'm proposing we remove the WITHOUT_CXX option and have opened a > review to do so: https://reviews.freebsd.org/D33108 So is the feature model of FreeBSD becoming, oh it gets broken cause it is not regularly tested, so lets remove that feature. This seams to becoming more and more the norm. -- Rod Grimes rgrimes@freebsd.org From nobody Fri Nov 26 09:51:43 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1504B18B7881 for ; Fri, 26 Nov 2021 09:51:59 +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 4J0qlf6SLbz3j3c; Fri, 26 Nov 2021 09:51:58 +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 D759F8929B; Fri, 26 Nov 2021 09:51: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 1AQ9pjHW044891 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 26 Nov 2021 09:51:45 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 1AQ9phkb044890; Fri, 26 Nov 2021 09:51:43 GMT (envelope-from phk) Message-Id: <202111260951.1AQ9phkb044890@critter.freebsd.dk> To: Ed Maste cc: Eugene Grosbein , Warner Losh , FreeBSD Hackers Subject: Re: Retiring WITHOUT_CXX In-reply-to: From: "Poul-Henning Kamp" References: <13a7b078-9e53-6bc2-a94e-b366ac1413dd@grosbein.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44888.1637920303.1@critter.freebsd.dk> Date: Fri, 26 Nov 2021 09:51:43 +0000 X-Rspamd-Queue-Id: 4J0qlf6SLbz3j3c 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 -------- Ed Maste writes: > Of course it's important to support small images, but we need to do so > via pkgbase, nanobsd, etc., rather than poorly-maintained build knobs. > (Knobs like WITHOUT_INCLUDES are built into our make infrastructure, > and are fine.) Just a bit of nit-picking and some commentary: At least as far as NanoBSD goes, that is a tautological argument, because slim NanoBSD images are created using WITHOUT_* options[1]. WITHOUT_CXX used to be one of the good ones, it freed up a lot of space, at a cost of, as I remember it, groff. We should always have a few such supported "shaves a lot" options, if for no other reason than because the B-O-S does positively explodes if it has to do all the combinatorics. These days, WITHOUT_TOOLCHAIN is my goto for really slim images, it shaves twice as much as WITHOUT_CXX. Poul-Henning [1] This is why I wrote the build-option-survey in the first place :-) -- 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 Nov 26 14:03:04 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 39D9318C769B for ; Fri, 26 Nov 2021 14:03:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 4J0xL310h7z4VSM for ; Fri, 26 Nov 2021 14:03:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-lf1-f43.google.com with SMTP id f18so24586311lfv.6 for ; Fri, 26 Nov 2021 06:03:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B1p/+3yx2aAzq93al/RuLuYMFusZBMAeQkwpGccyXvg=; b=TyE80dS851vNM/mjX6fqCU03sJZO84LRVTcKe+qWzudhHe2uSWKUndassdxHly8dWp J4HA7TxQFNzdMkkDfR5iu4FsmBvLBqRfEomEoUJHor1Y+pqC/tT9ZoUOm+LwTVbMgGh2 aMuvJFgZSWKDWXk6tyBCTqjMomd9kBrKXESmaz101lDBhOPTN+wbZTCdppM6n2+HcTng lIt4yG6fQy8Ff8RmjtNE4UygqKR1jN3Sm/tPZfL8cehnw1kEcIcUAn7rVbkg6jI3JsAy cTT13aRWFd4EFHKi/pGj474IV6dJz0QUpKDmzj5PyGOFsf21RjZaFCld1xGSjUqz0SbH 4mlA== X-Gm-Message-State: AOAM5337cpWIAn4qtWzELCRyAv4N45bRGJfoH64RHH0V/bbv5Ha/1OA9 IkXFMpgmNFoysr46dgf+DtFMvz2Kz9XT2e0UJdZfuaHt X-Google-Smtp-Source: ABdhPJzK5uuDxGDasi6i13LuyAYqklByp0YXdqqGoAcaCQOsLqwZrVrKBL6dKCC1sMQy0GkN+/skVfrztBomP8iXRQo= X-Received: by 2002:a05:6512:31ce:: with SMTP id j14mr29750047lfe.247.1637935409993; Fri, 26 Nov 2021 06:03:29 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> In-Reply-To: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> From: Ed Maste Date: Fri, 26 Nov 2021 09:03:04 -0500 Message-ID: Subject: Re: Retiring WITHOUT_CXX To: "Rodney W. Grimes" Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J0xL310h7z4VSM 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, 26 Nov 2021 at 04:09, Rodney W. Grimes wrote: > > So is the feature model of FreeBSD becoming, oh it gets broken > cause it is not regularly tested, so lets remove that feature. I don't agree with that. We have a large and growing CI infrastructure to regularly test functionality and are continually adding to it over time. But it's important to test and maintain what is actually used and is useful. Disabling C++ support made sense when obrien@ added the original knob in 2000, but it makes less sense today when parts of FreeBSD are written in C++. From eugen@grosbein.net Fri Nov 26 14:38:02 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7559918AC12D for ; Fri, 26 Nov 2021 14:38:19 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0y6254tNz4lq3; Fri, 26 Nov 2021 14:38:18 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AQEcDTQ050943 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Nov 2021 14:38:14 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: emaste@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AQEcC5P068399 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Nov 2021 21:38:12 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Retiring WITHOUT_CXX To: Ed Maste , "Rodney W. Grimes" References: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> Cc: FreeBSD Hackers From: Eugene Grosbein Message-ID: Date: Fri, 26 Nov 2021 21:38:02 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J0y6254tNz4lq3 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 26.11.2021 21:03, Ed Maste wrote: > On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes > wrote: >> >> So is the feature model of FreeBSD becoming, oh it gets broken >> cause it is not regularly tested, so lets remove that feature. > > I don't agree with that. We have a large and growing CI infrastructure > to regularly test functionality and are continually adding to it over > time. But it's important to test and maintain what is actually used > and is useful. Disabling C++ support made sense when obrien@ added the > original knob in 2000, but it makes less sense today when parts of > FreeBSD are written in C++. It depends on what are those parts exactly. For example, I exclude devd (written in C++) from my FreeBSD images because it does only harm for a router with fixed hardware but ever-changing set of ngXXX interfaces being created/removed (PPPoE server with high load). So I also build the image WITHOUT_CXX. From nobody Fri Nov 26 15:04:54 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 42E6018B7F0A for ; Fri, 26 Nov 2021 15:05:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0yht6b4Kz4vCC for ; Fri, 26 Nov 2021 15:05:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1637939095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=NjNEA7Vq+B1brrAZFS5azRCnHlI3DryDjVNY5M4QjDA=; b=NCjyquY73UOWqUKY6kihP9B+QPflhRtucbf4wY91a2HLO0IvRtJEIehNXFKngKBGMGlmFb IbTy4CiLXmG+jKO/Dfo9tOU4uaHcqOQ8qE63tqFTTApILZh9/xUztaPQZ/u3ZgrzbUdlnq i292YbZej4yzA4G9teaxY4Y63A0FV5Q= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 3013f216 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 26 Nov 2021 15:04:55 +0000 (UTC) Date: Fri, 26 Nov 2021 16:04:54 +0100 From: Emmanuel Vadot To: freebsd-hackers@freebsd.org Subject: Reasons for keeping sc(4) and libvgl ? Message-Id: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J0yht6b4Kz4vCC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=NCjyquY7; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello all, I'm currently re-implementing the framebuffer code in linuxkpi for drm-kmod and this made me look at sc(4), vt(4) and friends. So I looked at what sc could do and vt couldn't and vice-versa. What sc(4) can't do : - Work with EFI firmware. - Support UTF-8 - Maybe other things but everything here is EFI-based so let me know. What vt(4) can't do : - You can't get the modes or adapter info with vidcontrol. vidcontrol -i mode is really made for anything vesa based as it iterates on all the modes and display them if present. In the modern world (EFI), we don't have that, EFI GOP doesn't support changing resolution after ExitBootService was called so there is only one "mode". I could possibly hack some patch so vidcontrol -i mode/adapter would work and display the current framebuffer info if people wants (but I honestly doubt that vidcontrol is useful at all in an EFI world). - "Blanking" screen doesn't do what you think it does. For some reason in vt(4) we just write black colors on the screen and ignore the blank mode passed in the ioctl. Now again, blanking/dpms/blah isn't possible with efi_fb but it make sense to fix vt(4) and drm-kmod so it calls the drm module blanking function, I'll work on that next week. - There is no screensaver, again see notes above for dpms but do people still use sc(4) just for the screensaver ?? - Maybe other things, please let me know. For libvgl it probably made sense back in the 90s but does it now ?? Based on my small list I don't see any good reason to keep sc(4) but maybe I've missed something bigger so please let me know. P.S.: I'm really not interested by people saying stuff like "I've always used sc(4), it works for me don't touch it" without some technical argument. Cheers, -- Emmanuel Vadot From nobody Fri Nov 26 15:45:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4219A18B3A90 for ; Fri, 26 Nov 2021 15:45:19 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 4J0zbM1Btwz3Ny7 for ; Fri, 26 Nov 2021 15:45:19 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x134.google.com with SMTP id b1so25153328lfs.13 for ; Fri, 26 Nov 2021 07:45:19 -0800 (PST) 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=f6rXc/8+Gs73hfoGgM7ZWKbPxREK4rA1OTLpDpQRNks=; b=dU2fr1agRAiLEVmFJpTDyyn65VFXrvcas64dtHFtRZam/NPFC/WpOjGZRDpOD5RWUx w/EZgI/nVZzO5HXet+P7ILGAaLLSQTy54G3SDZE4WOQLTtWgxM4ZbO8DT0cY5+qV002e FH3wB5bIPyIiCe4ye8nkRwhW0SVT9giKwS93bHHybndNOnp4BLxQiP6gkTKtjdh7q03r mUhzZkx0Q/Qg2VGO7Ws1WTFxDvP/gjRsjoN4FqaLY+z4GqoyYTtURCyYDuctfRKuEy+n cpPn1wasb1KhMr10cpIYiXaamwVjNaOSV1Zx0l1oOvLkQP77+vrJXoA4MqqsvPm+lAcJ b/EA== 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=f6rXc/8+Gs73hfoGgM7ZWKbPxREK4rA1OTLpDpQRNks=; b=tMxykCAMOZC02X/r6Lbx1brEzgEhKvePjMBKGFh1+fVrsmCllaq9dNGkB8bLA0IR3n YaG8vpSY+erUYmtPe0fNOUMKADQTgpVRn77rwh+82Q7RUcQ7fGxD5cq7D6LEC2V72EML cJIw9Aw4tatJwBHlXfI7xfQ/J1K/gKOAzQ7RlmcEfxhBV0C/RuoWKXp2EN1cvvrX3Cth fdp4Azq2X0cFYz/pKTO1ME9HNdiscFIWKjxNyRHbW77JALBQhVzbWH5eQpzcIPZ5CviH qroUKCSblaYZ+3SP9CIEYQMZ70DI6agGPUt1qPefEz/Twgu9vF8FLWsjiDInlbqy+Gp4 uOcA== X-Gm-Message-State: AOAM533elfsXLoIPkY6cjj22jWm3GCT1x/Rv3OZQvh3CJ675i58KCcqK M6GUaJLLDbjsfg9nTswNxuyI8jjfk6+27VGRih5JjHE3 X-Google-Smtp-Source: ABdhPJzazX+Jawme5vqI2m++irHmWn0dSG2dzLBEfOlDFynrAh5pk+WdANJR5gPDr3Lis/MspcmDXLym77RKKs7hseA= X-Received: by 2002:a05:6512:e89:: with SMTP id bi9mr30839650lfb.465.1637941517933; Fri, 26 Nov 2021 07:45:17 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Fri, 26 Nov 2021 07:45:17 -0800 (PST) In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> From: Stefan Blachmann Date: Fri, 26 Nov 2021 16:45:17 +0100 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Emmanuel Vadot Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J0zbM1Btwz3Ny7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Main technical reasons why I consider sc(4) essential: - vt/vesa.ko break suspend/resume on nvidia cards. To make suspend/resume work on computers with nvidia, it is necessary to build a kernel *without* vt/vesa modules. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253733 - vt is so horridly buggy that it is no fun to use it at all if one is accustomed to well-working, bugfree sc(4). Just one example: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211922 The hate and disregard against sc(4) and against nvidia and the arrogance that can be observed from some FreeBSD core guys amazes me again and again. I often wonder why Nvidia has not already dropped FreeBSD support due to such attitudes. On 11/26/21, Emmanuel Vadot wrote: > > Hello all, > > I'm currently re-implementing the framebuffer code in linuxkpi for > drm-kmod and this made me look at sc(4), vt(4) and friends. > > So I looked at what sc could do and vt couldn't and vice-versa. > > What sc(4) can't do : > > - Work with EFI firmware. > - Support UTF-8 > - Maybe other things but everything here is EFI-based so let me know. > > What vt(4) can't do : > > - You can't get the modes or adapter info with vidcontrol. > vidcontrol -i mode is really made for anything vesa based as it > iterates on all the modes and display them if present. > In the modern world (EFI), we don't have that, EFI GOP doesn't > support changing resolution after ExitBootService was called so there > is only one "mode". I could possibly hack some patch so vidcontrol -i > mode/adapter would work and display the current framebuffer info if > people wants (but I honestly doubt that vidcontrol is useful at all in > an EFI world). > - "Blanking" screen doesn't do what you think it does. For some reason > in vt(4) we just write black colors on the screen and ignore the blank > mode passed in the ioctl. > Now again, blanking/dpms/blah isn't possible with efi_fb but it make > sense to fix vt(4) and drm-kmod so it calls the drm module blanking > function, I'll work on that next week. > - There is no screensaver, again see notes above for dpms but do > people still use sc(4) just for the screensaver ?? > - Maybe other things, please let me know. > > For libvgl it probably made sense back in the 90s but does it now ?? > > Based on my small list I don't see any good reason to keep sc(4) but > maybe I've missed something bigger so please let me know. > > P.S.: I'm really not interested by people saying stuff like > "I've always used sc(4), it works for me don't touch it" > without some technical argument. > > Cheers, > > -- > Emmanuel Vadot > > From eugen@grosbein.net Fri Nov 26 15:59:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0614818BAC90 for ; Fri, 26 Nov 2021 16:00:05 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0zwN55T7z3jry for ; Fri, 26 Nov 2021 16:00:04 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AQG01vH051394 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Nov 2021 16:00:01 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: manu@bidouilliste.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AQG00iO068832 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Nov 2021 23:00:00 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Emmanuel Vadot , freebsd-hackers@freebsd.org References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> From: Eugene Grosbein Message-ID: <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> Date: Fri, 26 Nov 2021 22:59:49 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J0zwN55T7z3jry X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 26.11.2021 22:04, Emmanuel Vadot wrote: > For libvgl it probably made sense back in the 90s but does it now ?? I enjoyed games/digger-vgl for a while in VGA console :-) > Based on my small list I don't see any good reason to keep sc(4) but > maybe I've missed something bigger so please let me know. > > P.S.: I'm really not interested by people saying stuff like > "I've always used sc(4), it works for me don't touch it" > without some technical argument. sc(4) is still better quality for BIOS-based systems or EFI-based with CSM legacy mode working. sc(4) is better to such an extent FreeBSD's unusable with vt(4) for some fresh systems being sold but boots and works fine with sc(4). An example with many people complaining: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172 I'd like more FreeBSD developers respect POLA these days and take responds like "I've always used sc(4), it works for me don't touch it" seriously. Please, don't touch what works and works good. From eugen@grosbein.net Fri Nov 26 16:06:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0CFC018BD5CE for ; Fri, 26 Nov 2021 16:06:24 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J103g5PP4z3mNl for ; Fri, 26 Nov 2021 16:06:23 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AQG6LEB051435 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Nov 2021 16:06:21 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: manu@bidouilliste.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AQG6Kt9068874 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Nov 2021 23:06:20 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Emmanuel Vadot , freebsd-hackers@freebsd.org References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> From: Eugene Grosbein Message-ID: Date: Fri, 26 Nov 2021 23:06:10 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J103g5PP4z3mNl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 26.11.2021 22:04, Emmanuel Vadot wrote: > > Hello all, > > I'm currently re-implementing the framebuffer code in linuxkpi for > drm-kmod and this made me look at sc(4), vt(4) and friends. > > So I looked at what sc could do and vt couldn't and vice-versa. > > What sc(4) can't do : > > - Support UTF-8 This is not true. I tested UTF-8 support with sc(4) in FreeBSD 8 and it worked fine. It required some kernel options: options SC_PIXEL_MODE options VESA options TEKEN_XTERM options TEKEN_UTF8 And optionally for /boot/device.hints: hint.sc.0.flags="0x180" # switch to graphics mode at boot time hint.sc.0.vesa_mode="0x1F0" # preferred framebuffer video mode code And the port sysutils/jfbterm to render fonts. From eugen@grosbein.net Fri Nov 26 16:10:59 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 54DA318C1619 for ; Fri, 26 Nov 2021 16:11:15 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J109G0pSZz3qGX for ; Fri, 26 Nov 2021 16:11:14 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AQGBAYq051459 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Nov 2021 16:11:11 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: manu@bidouilliste.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AQGBAUr068914 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Nov 2021 23:11:10 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Emmanuel Vadot , freebsd-hackers@freebsd.org References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> From: Eugene Grosbein Message-ID: Date: Fri, 26 Nov 2021 23:10:59 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J109G0pSZz3qGX X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [1.99 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_MEDIUM(0.09)[0.091]; 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.995]; 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]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 26.11.2021 22:59, Eugene Grosbein wrote: > sc(4) is still better quality for BIOS-based systems or EFI-based with CSM legacy mode working. > sc(4) is better to such an extent FreeBSD's unusable with vt(4) for some fresh systems being sold > but boots and works fine with sc(4). An example with many people complaining: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172 Sorry, not completly "unusable" (it seems manual work-around exists) but without knowledge of obscure work-around one cannot use the hardware with vt(4) and FreeBSD versions 11.2+ (11.1-RELEASE was last one working out of the box). From nobody Fri Nov 26 16:13:50 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B695118C24A5 for ; Fri, 26 Nov 2021 16:13:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J10DK2bZSz3rwX for ; Fri, 26 Nov 2021 16:13:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1637943231; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ddDQnY6VmE0ldlfFuCkt6Pcb43sjKJgpJY/unOsxLOA=; b=Xje9/HD6dpvDlzbY6v5DWORs8R700HwkTJwVV9Jt1CxCdpsvvliA4+LEKiIqz63H69tjNF xAjfTRzKWQ3mBTJ/qWPMEcXSJs3qYVBdaOzyrA0QhheIk3kjvaEdZ13ZXtT3qQdgX5W0p9 9lhMhGR0bJ93vd+RvG0ZMGkPIqqaybo= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 3689c108 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 26 Nov 2021 16:13:51 +0000 (UTC) Date: Fri, 26 Nov 2021 17:13:50 +0100 From: Emmanuel Vadot To: Eugene Grosbein Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20211126171350.bf976c035095e1d8ac5e43fa@bidouilliste.com> In-Reply-To: <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J10DK2bZSz3rwX 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, 26 Nov 2021 22:59:49 +0700 Eugene Grosbein wrote: > 26.11.2021 22:04, Emmanuel Vadot wrote: > > > For libvgl it probably made sense back in the 90s but does it now ?? > > I enjoyed games/digger-vgl for a while in VGA console :-) > > > Based on my small list I don't see any good reason to keep sc(4) but > > maybe I've missed something bigger so please let me know. > > > > P.S.: I'm really not interested by people saying stuff like > > "I've always used sc(4), it works for me don't touch it" > > without some technical argument. > > sc(4) is still better quality for BIOS-based systems or EFI-based with CSM legacy mode working. Why ? > sc(4) is better to such an extent FreeBSD's unusable with vt(4) for some fresh systems being sold > but boots and works fine with sc(4). An example with many people complaining: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172 Better as in it doesn't respect the specs ? You said yourself in this PR that we should blame the manufacturer. Now if you want to work on making hw.vga.acpi_ignore_no_vga better in loader based on the smbios info and some quirk table please go ahead. But don't say that sc(4) is better because it works on buggy hardware as it ignores some stuff. > I'd like more FreeBSD developers respect POLA these days > and take responds like "I've always used sc(4), it works for me don't touch it" seriously. > > Please, don't touch what works and works good. > Why POLA ? I'm asking for reasons to keep sc(4), how the hell is that POLA to ask some questions ? -- Emmanuel Vadot From nobody Fri Nov 26 16:16:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2CAB618C4C14 for ; Fri, 26 Nov 2021 16:16:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J10H66Lx7z3trQ for ; Fri, 26 Nov 2021 16:16:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1637943377; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8HB6dEr6CK0xq7n6Bvijt/5ArTgQzf4oEtatPgz+N0g=; b=c2DQ5Ry99uRN5LRT2TTaLoq7OSI7FPu3FK+GXDmb8iIhkklWhVJ6ErW0VY9TfY3gPOlxuo VDGHyodLx7fk5jOYbMSoh0Q88iBr/nSEPSm/eRKvQh/N6LyjhHit/s6mRNKLY3l4WHdfGP qQHzwGIbQJtrodjdoHJU4rf9iM+K99k= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id c77801a9 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 26 Nov 2021 16:16:17 +0000 (UTC) Date: Fri, 26 Nov 2021 17:16:17 +0100 From: Emmanuel Vadot To: Stefan Blachmann Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20211126171617.f57c65e9c4dbdb0d1a2863c0@bidouilliste.com> In-Reply-To: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J10H66Lx7z3trQ 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, 26 Nov 2021 16:45:17 +0100 Stefan Blachmann wrote: > Main technical reasons why I consider sc(4) essential: > > - vt/vesa.ko break suspend/resume on nvidia cards. To make > suspend/resume work on computers with nvidia, it is necessary to build > a kernel *without* vt/vesa modules. See > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253733 I'm not sure I understand your report, does the system suspend/resume fine if you use vt or not ? To me it seems that the problem is when you have vt(4) in the kernel but uses sc(4). > - vt is so horridly buggy that it is no fun to use it at all if one is > accustomed to well-working, bugfree sc(4). Just one example: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211922 Oh yes, one scroll bug that I even can't reproduce locally clearly makes vt(4) 'horridly buggy'. > > The hate and disregard against sc(4) and against nvidia and the > arrogance that can be observed from some FreeBSD core guys amazes me > again and again. > I often wonder why Nvidia has not already dropped FreeBSD support due > to such attitudes. > > > On 11/26/21, Emmanuel Vadot wrote: > > > > Hello all, > > > > I'm currently re-implementing the framebuffer code in linuxkpi for > > drm-kmod and this made me look at sc(4), vt(4) and friends. > > > > So I looked at what sc could do and vt couldn't and vice-versa. > > > > What sc(4) can't do : > > > > - Work with EFI firmware. > > - Support UTF-8 > > - Maybe other things but everything here is EFI-based so let me know. > > > > What vt(4) can't do : > > > > - You can't get the modes or adapter info with vidcontrol. > > vidcontrol -i mode is really made for anything vesa based as it > > iterates on all the modes and display them if present. > > In the modern world (EFI), we don't have that, EFI GOP doesn't > > support changing resolution after ExitBootService was called so there > > is only one "mode". I could possibly hack some patch so vidcontrol -i > > mode/adapter would work and display the current framebuffer info if > > people wants (but I honestly doubt that vidcontrol is useful at all in > > an EFI world). > > - "Blanking" screen doesn't do what you think it does. For some reason > > in vt(4) we just write black colors on the screen and ignore the blank > > mode passed in the ioctl. > > Now again, blanking/dpms/blah isn't possible with efi_fb but it make > > sense to fix vt(4) and drm-kmod so it calls the drm module blanking > > function, I'll work on that next week. > > - There is no screensaver, again see notes above for dpms but do > > people still use sc(4) just for the screensaver ?? > > - Maybe other things, please let me know. > > > > For libvgl it probably made sense back in the 90s but does it now ?? > > > > Based on my small list I don't see any good reason to keep sc(4) but > > maybe I've missed something bigger so please let me know. > > > > P.S.: I'm really not interested by people saying stuff like > > "I've always used sc(4), it works for me don't touch it" > > without some technical argument. > > > > Cheers, > > > > -- > > Emmanuel Vadot > > > > -- Emmanuel Vadot From eugen@grosbein.net Fri Nov 26 16:26:07 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E4B118A1AAB for ; Fri, 26 Nov 2021 16:26:21 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J10Vh61HCz4SNX for ; Fri, 26 Nov 2021 16:26:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AQGQIDr051663 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Nov 2021 16:26:19 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: manu@bidouilliste.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AQGQHfU069021 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Nov 2021 23:26:17 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Emmanuel Vadot References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> <20211126171350.bf976c035095e1d8ac5e43fa@bidouilliste.com> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: Date: Fri, 26 Nov 2021 23:26:07 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20211126171350.bf976c035095e1d8ac5e43fa@bidouilliste.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J10Vh61HCz4SNX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 26.11.2021 23:13, Emmanuel Vadot wrote: > Better as in it doesn't respect the specs ? People (expept of programmers :-) do not work with specs, they work with real pieces of metal. sc(4) works out of the box and an upgrade does not ruin the system, so it is considered better. I was forced to deal with production system broken with 11.1->11.2 upgrade (it used vt(4) by default) and it was not fun. > You said yourself in this PR that we should blame the manufacturer. > Now if you want to work on making hw.vga.acpi_ignore_no_vga better in > loader based on the smbios info and some quirk table please go ahead. > But don't say that sc(4) is better because it works on buggy hardware > as it ignores some stuff. No, I will keep saying that compatibility with buggy hardware is better than lack of compatibility; at least in case we already have the compatibility and going to lose it. >> I'd like more FreeBSD developers respect POLA these days >> and take responds like "I've always used sc(4), it works for me don't touch it" seriously. >> >> Please, don't touch what works and works good. >> > > Why POLA ? > I'm asking for reasons to keep sc(4), how the hell is that POLA to ask > some questions ? Removal of sc(4) will astonish part of our userbase. We should avoid it. From eugen@grosbein.net Fri Nov 26 16:26:47 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F5D618A1DDF for ; Fri, 26 Nov 2021 16:27:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J10WS6gk8z4SMy for ; Fri, 26 Nov 2021 16:27:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1AQGQwPN051671 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Nov 2021 16:26:59 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: manu@bidouilliste.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1AQGQv4h069031 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Nov 2021 23:26:58 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Emmanuel Vadot References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> <20211126171350.bf976c035095e1d8ac5e43fa@bidouilliste.com> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <1b0eb704-9322-9b7a-363b-7ad5b55ecf7b@grosbein.net> Date: Fri, 26 Nov 2021 23:26:47 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20211126171350.bf976c035095e1d8ac5e43fa@bidouilliste.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J10WS6gk8z4SMy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 26.11.2021 23:13, Emmanuel Vadot wrote: > Better as in it doesn't respect the specs ? People (except of programmers :-) do not work with specs, they work with real pieces of metal. sc(4) works out of the box and an upgrade does not ruin the system, so it is considered better. I was forced to deal with production system broken with 11.1->11.2 upgrade (it used vt(4) by default) and it was not fun. > You said yourself in this PR that we should blame the manufacturer. > Now if you want to work on making hw.vga.acpi_ignore_no_vga better in > loader based on the smbios info and some quirk table please go ahead. > But don't say that sc(4) is better because it works on buggy hardware > as it ignores some stuff. No, I will keep saying that compatibility with buggy hardware is better than lack of compatibility; at least in case we already have the compatibility and going to lose it. >> I'd like more FreeBSD developers respect POLA these days >> and take responds like "I've always used sc(4), it works for me don't touch it" seriously. >> >> Please, don't touch what works and works good. >> > > Why POLA ? > I'm asking for reasons to keep sc(4), how the hell is that POLA to ask > some questions ? Removal of sc(4) will astonish part of our user base. We should avoid it. From nobody Fri Nov 26 17:09:54 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C315F18B6CE6 for ; Fri, 26 Nov 2021 17:09:56 +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 4J11T03b3sz4hqY; Fri, 26 Nov 2021 17:09: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 1AQH9sRF025508; Fri, 26 Nov 2021 09:09:54 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 1AQH9sHg025507; Fri, 26 Nov 2021 09:09:54 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> Subject: Re: Retiring WITHOUT_CXX In-Reply-To: To: Ed Maste Date: Fri, 26 Nov 2021 09:09:54 -0800 (PST) CC: "Rodney W. Grimes" , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4J11T03b3sz4hqY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N [ Charset UTF-8 unsupported, converting... ] > On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes > wrote: > > > > So is the feature model of FreeBSD becoming, oh it gets broken > > cause it is not regularly tested, so lets remove that feature. > > I don't agree with that. We have a large and growing CI infrastructure > to regularly test functionality and are continually adding to it over > time. But it's important to test and maintain what is actually used > and is useful. Disabling C++ support made sense when obrien@ added the > original knob in 2000, but it makes less sense today when parts of > FreeBSD are written in C++. > You can disagree with my assertion, but I shall continue to assert that it *seems* as if rather than adding B O S to the CI such that it is not only regularly tested, but continuously tested is the correct path forward here. Removing an option that seems to break due to not beeing tested (your original assertion) is not only false (I pointed out, and do know for a fact that Michael Dexter runs BOS on a very regulary basis, infact near continously.) and the wrong path forward. Fix the broken stuff, stop letting stuff rot because you don't care to work on it, or because it is not being "tested". -- Rod Grimes rgrimes@freebsd.org From nobody Fri Nov 26 17:15:50 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F2C2E18BA5CD for ; Fri, 26 Nov 2021 17:15:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J11bs4lGzz4kwQ for ; Fri, 26 Nov 2021 17:15:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1637946950; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6GL/OexTTQv2YyxQTOh8WNwCeLWWjdATM0m9GBk1IVE=; b=GFt8yz6kHbxSW7EG+57wuWUs4qBfxvme866pr8isybZOMtmNTEKWDs/AcCNO0XKN2HwWeW 46qswHcvcIKgKrYyTrIHwfdgkukiENlNzV00+C898436Zq5qN2NJ7RNcfPXkbSQkrpXy7p M3vdqEaaslMcu4U02jfG5iacAcQQmWY= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 86832b6e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 26 Nov 2021 17:15:50 +0000 (UTC) Date: Fri, 26 Nov 2021 18:15:50 +0100 From: Emmanuel Vadot To: Eugene Grosbein Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20211126181550.ff4f633fd70fd8aa5a256f16@bidouilliste.com> In-Reply-To: <1b0eb704-9322-9b7a-363b-7ad5b55ecf7b@grosbein.net> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> <20211126171350.bf976c035095e1d8ac5e43fa@bidouilliste.com> <1b0eb704-9322-9b7a-363b-7ad5b55ecf7b@grosbein.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J11bs4lGzz4kwQ 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, 26 Nov 2021 23:26:47 +0700 Eugene Grosbein wrote: > 26.11.2021 23:13, Emmanuel Vadot wrote: > > > Better as in it doesn't respect the specs ? > > People (except of programmers :-) do not work with specs, > they work with real pieces of metal. sc(4) works out of the box > and an upgrade does not ruin the system, so it is considered better. That's one way of seeing things. > I was forced to deal with production system broken with 11.1->11.2 upgrade (it used vt(4) by default) > and it was not fun. > > > You said yourself in this PR that we should blame the manufacturer. > > Now if you want to work on making hw.vga.acpi_ignore_no_vga better in > > loader based on the smbios info and some quirk table please go ahead. > > But don't say that sc(4) is better because it works on buggy hardware > > as it ignores some stuff. > > No, I will keep saying that compatibility with buggy hardware is better than lack of compatibility; > at least in case we already have the compatibility and going to lose it. And we have a workaround for this issue, I think it should be better so I understand your point here. BTW all those users with buggy system will never had this problem if they choose to use uefi but ... > >> I'd like more FreeBSD developers respect POLA these days > >> and take responds like "I've always used sc(4), it works for me don't touch it" seriously. > >> > >> Please, don't touch what works and works good. > >> > > > > Why POLA ? > > I'm asking for reasons to keep sc(4), how the hell is that POLA to ask > > some questions ? > > Removal of sc(4) will astonish part of our user base. We should avoid it. I'm not saying that we should remove sc(4) now obviously. I'm saying that remove it should be the plan (and I think have been for quite some time now) and I'd like to understand the last issues with vt(4) for this. -- Emmanuel Vadot From nobody Fri Nov 26 17:29:24 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9FD1318A1078 for ; Fri, 26 Nov 2021 17:29:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 4J11vY71K7z4pp9 for ; Fri, 26 Nov 2021 17:29:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637947769; bh=W/VGTpO7ddK/P2UOxGHSfJsKngFoHWCYHtOn5F4dIqw=; h=From:Subject:References:To:Date:From:Subject:Reply-To; b=JwhEuAbSphx2UhySU5YNIvfJ/bXyzM0qst5SstKP3hSbgPpkVaACmsl4/OyHU2R20DJuO8jB4ouGoO/xmSQ/0QOBCewmRduqZfJ1eDdkd3QHQVVIBXBYHJWBw+R831y+uWvhHricWCL+v+ErjruHBNtpJLCbQrml59kxAfYXNpx/NhycqeoZlBlFvm+PzAZcExdG+Bl1W/2ftyM6ROKU9p+W0J6mUrfX1FaDv2PPGA1eU1v1eQX5NCRKKAFSx5XiLstOBw/joufs2ddpz7ZfAWgJMBZURpkVckOk8S08GtR8G+j/MLCQU+b5mFHSYisQx3+l+g2Hn8VkHogWFBGjnA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637947769; bh=IRw8bBArXu4vse/6PUxfP7RKZmF3T3c52wIMKZRzHsx=; h=X-Sonic-MF:From:Subject:To:Date:From:Subject; b=HQHF9YAlAjC2huKCThjr81GrbMt7ccWV9AJQqvvjS27b15nXtLn+VdeWvp5+7EcMG61dFfvhq9nSH48Sv7w/DdN9bpr5lHvQKsSYX9Tvk3nriF9SVeQ8oboW9rfTdqx8wLau9TX7JIrWFGH9nSINl59qXWx8P+5lGuUq8U7El9fcTLBblH3T90N+oxlP+BLtyWJcp37r75zaIVHf1MO3lNsNw7Vzva/VZPzxxR6D7t+z6sJ7wpQ25tUZ5i3mkn/+KEXFgjs6cPgNS4MKxGvs2A6Q+2g/m+sTpetAyiuqS/g1g/6Tj2s+oyDEBeNL1lRVwHZQQnkDOIv6vSmO2MlFKA== X-YMail-OSG: Y9XegLsVM1kEh8UPgqdazsUVxo92xKnDzQ8QdHEac1cKtC8afrnbxV_xMgZi0CN R8pwudnz18pL8MC_W.V1vv0jbJmxNXbt62ov9ez.g9ZHcWgEd6zXqNnFdREIJB.k5ziLO7C6cWdf fauSRFMHMiNOMRdfkoQOl0Gganv9pAWjh33nJwvUXF3PPCFX4yxb.rHJJ99eklh8HEDkOZxSqaur xq8DEUX95ltJG1fsQX1sjH1uJvBbNygviPoRVr715fcC4vIV3OZ_InB0EAXb0BLxf0KUjXUcy1OZ 3EqWfOGtxftkNPJKXqs.AVq.3sDq7Y4_MASipIyADJOKgyoggPgcoypavw63YG9ABywHxE9lSK8j i_HRHu0bH0FAuikQ4h5rcq7P43TrvH7uYYK7WwjQi1qkgOKs_mgrMb7o.g1sM3I4cuUriA22y4qs w51jozJ5bJLm9El0WCXEVcVzH_Z7yAo43I90L3Ik5YccMFIKydD9ZiKgbU.1IHsj7BJMSymm1ZbS cpivXmmsB9o0dUtXHNEoyXB0NE3h9Jijxyex6nMA3xhP5PjC7TYN.NmrmstQ0SpMYvwCWi7tQd3n OxwJPJ7gjSeA0SbLyy27w6PwFRgRm0axgNy67cVS3VaWJqCG.hlPdUI7yBnNN0ENLsNowcrCqoGe usK7xJL9t.TY4VgnCYUZkecp8A1n1jag7VEe5feCm77167WzglK8VNxKgDxWW2A0p27t3Q7QP.vD 95iK5nlC_yypCk0EeclO9aDahwnOn3KMoeQM6jOlcYpDMJkps0hFG.DxB_srrm90BuKm77ud9VgE eX7rU4lpxVagMtz49vJL5cggapRmpQBobBAkCBwE2l2hqBN7XRSFC7ZvLmSRmO45heQBFnaUN4IQ dMPvBhVSTROPPEe6ubjM5f57rL6Bf1jaZkG.YxpIldvQ3O6W7h5Ti9MvAEKFHiZQtFnXeGw_fAgF Cew3BX.9W9lJp1qCH5cGLwlEgG7MxZpk_VUdtIFNFJwr6gb_8PVLSzRJtEcQKpZBnlhHTpKn_PtL QUMN4QHC74L1qobYQRs2f7YQYKHrDk3y74n8fQ1kdJ1ia.jXHM4kk9Z.ZpmKe98qd_jltI.AexFw .ay.rWNFZsSgUbWj2ahetOel3DVWAgJQz4i979UVX1z8690C3ZZGpaDDxohPaR.UjuIvZPDO1rh9 mR.ZYJ4dYKDHJIwjClnMBjxJGMhT5_AokTP3npr3SVxScFLREA2z7sXFxEOaCvecNfDqaI7Svxhb ejQP.h8x4kEkAQ.taOIH0d2e8ndBdm.67NMZQjbL7h_TwXohDsRk6Sgj3Igq_fVVVhPHab9Hrs24 ZWOkDikauZgexX_R9j5_TkEC9I5V5uM8tiysi5dfJAGTGWKhDa64TktZSeAy9m2QwURnouSOzneh NYnyH9IBQ.v3sq12FT3EmGIER0o2S4Av6cB1nmMIQWhmRcHsPhlJFXa2omXmOiJbpnDBmgE9FAG6 1AhDlxoq.mVCo8f7iHnuZUPVybtGY8e1qHDyvb7dlazxyFLCQXEOLy2urCpM9ykQVQE8Mr3XqAVb RJT7j0n9JiOOsIHmMNHYxDArgZJoga1ih4zU5vcx.k_NqdXaxENsJBDcanuqjOt4D_YjnMVQ0ozB i_RLOgLhqXlLyzsFIFK7ZYYiidU0zpU6lqKp0tU3gRj.aTKfArxvXQleqARHQv2zEmAoHj9Po9N3 UwvITghPdP58v2if.7DxljI1fGCq.PiLC_TWBOU82wtIhjOhXotNmR8WbCO6Zjeq1i_t357rQ3nW JJVVwkrDD19fe3r7gma9XIiM_KPQ1gIjS.dGq84Dkq.r18yTd8Swmf.fk.qEUlia9YJmbw1eBp41 MfOz4jtUf9nDqIzNNWbDnlKWCz9pfDnvWqOjf4DoxN4MgTlb_bOk6ncitrGilGMEfbRPor5mLvc9 d29OyZo1TiqMM5LYk3BjYGGXEYclxRWaq0s4xC.2dA5LhO8HvzmXw9ZnFDnF7bweYKqKreAW1lf8 Tne8J1rENdEHgfOBz0ewNpHoXXBkrRu9mU4sSrRP38xgkyM_n8t.3.0cpYgX1hTJkVbpOW5_lMmt 8fCb6CZUrRdqzwJH1KJaFG1mz5B51cu_6ngfBphVCqktsMPjbMRDoMyMwXDttwWxwG4.4KlPo8vq f6CpWX.yBHwD1JLsYLijQsoO3HEm50ekDALMYKwx4ZpvAdYW9Toi_sPtkLfyjV4xP0noAkBNtGfj 3Bl7R8k3ViGYyzSfuLpNNCZx6an8d0JY2F4T8jR9ou4bRJJwuN6t.IsnZnHFISiTlMdhQe72FyAj bGpumBDszG47OVEjJTP2VRhE- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 26 Nov 2021 17:29:29 +0000 Received: by kubenode504.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 63d96e83d3f0b36a88dff07cbe6203f2; Fri, 26 Nov 2021 17:29:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Fwd: Reasons for keeping sc(4) and libvgl ? Message-Id: References: <5E10E4FD-4C52-4B96-807B-2B6008E4886C@yahoo.com> To: Emmanuel Vadot , FreeBSD Hackers Date: Fri, 26 Nov 2021 09:29:24 -0800 X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J11vY71K7z4pp9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=JwhEuAbS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-hackers X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N [This is a resend after joining freebsd-hackers (again?).] This is just a history FYI. I no longer have access to powerpc* systems. When I did they were all old PowerMacs. I can not test the current status any more. > What vt(4) can't do : . . . Well, what vt(4) didn't (doesn't?) do on some powerpc systems . . . But there were also the other direction: ones where vt worked but sc did not. So I used a mix on powerpc systems. The contexts were basic video console use, not X11 or such. Of, course, tier 2 breakage on old PowerMac hardware may not be enough to drive the choice about keeping sc, even if vt could not be made to work. I looked up some of my old list messages and back on 2021-Jan-13 I reported to Warner: PowerMac7,2 G5: vt worked, sc hang just after "Kernel entry at 0x100580 ...". iMac G3 (PowerMac4,1): sc worked, vt failed (showing a blank screen). However in that time frame the old old 2-socket-/2-cores-each G5 with the Radeon X1950 was dead and untestable. It used to be that vt mishandled a 2560x1440 display for this context and caused a boot-crash. The smaller displays worked fine. But I do know that in the 2021-Jan-13 the GeForce 7800 GT based 2-socket-/2-cores-each G5 handled the same display just fine. (That machine died since then.) So the vt issue involved here might have been fixed. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Nov 26 17:45:40 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A00B18ABC8C for ; Fri, 26 Nov 2021 17:45:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 4J12GZ1RzZz3Bwx for ; Fri, 26 Nov 2021 17:45:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2d.google.com with SMTP id 188so6447749vku.8 for ; Fri, 26 Nov 2021 09:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SAep5k3TpH5EwbAg+DbBH1XAJBS4LuuoV+I7tmzKefQ=; b=3oZ5hHIEI4+1WWbmsFzF8R1c0YtEhUOw9o3UQ+MFLlMWlAPoZsK4QJXHdyqvQHtX65 pW+7XWITkKs0J6RS6SFcgK+x+Z9c7Ub2EhcutubzVYPdUQ5Y69WEvHdT27aZ3XUY/zG6 JVW6ObWj/U6WVMWhnLVOa4wcRZaFcpBbrmIHEJjGC4UXv20JRnLbx3HVhG2iq3/lnimg NA9tira0+W8jMPoaZ1Gv9BjczCBIFmRpOEyGDsY+aJcRd8bjHD5tRX9FFNePrqBNeP32 skln/F9lTpFYoCtxbqGvkxATLY+SKDIsUduBNGhPa8oKFA5wDtHn1ltyXGLsooNeJqqD qe5A== 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=SAep5k3TpH5EwbAg+DbBH1XAJBS4LuuoV+I7tmzKefQ=; b=tIKl28dcpxAa4VoPvuaab6wmWsLEZxTBWV9Wnv08JzfF2JwX6vxYGFioPdenn/pdwH Z3tcPs8bWBBUTgret4YT+cyt2slXStvrRikdd09JUlF0raQTluILmZ6FM6MZ//Rw/eCd CQhhbQNB4NQkqfaeHte4ghVeem/lWDdocNNaPItVd5ohimYbvqU/CNcJpiDvAbofvUlT nh0uvgcz5D4D1HNVM4AuVnX8/wWnUidPgF00yOqCtRFR/r1I3MQhK85bRQcbdongzz0j cG+So89G5IQZN7LFUcc5q6SpuuLi264guCFZCsrxYFB3OhTXaOqPpuzgN6RVHpq3OgAk 6KVw== X-Gm-Message-State: AOAM533kKqbXSOlnvMIrktfvRdX+yNXivwfAE7FggEwL/CKWENh7yIuP SHkVPkoRf/5w33KepCLB7PKDrsMnPDLJCOTNJdYEyA== X-Google-Smtp-Source: ABdhPJwaSxxvnR5AQw/Wxngo8jNWtDNzkY6i7VQELdJu5QeUnJkl2qDj8/RcWKOG8qkMYwBoV5eXZ18e37cvXVejWnQ= X-Received: by 2002:a05:6122:988:: with SMTP id g8mr21312883vkd.2.1637948750884; Fri, 26 Nov 2021 09:45:50 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> In-Reply-To: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> From: Warner Losh Date: Fri, 26 Nov 2021 10:45:40 -0700 Message-ID: Subject: Re: Retiring WITHOUT_CXX To: "Rodney W. Grimes" Cc: Ed Maste , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000075042e05d1b4a9ad" X-Rspamd-Queue-Id: 4J12GZ1RzZz3Bwx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000075042e05d1b4a9ad Content-Type: text/plain; charset="UTF-8" On Fri, Nov 26, 2021 at 10:11 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > [ Charset UTF-8 unsupported, converting... ] > > On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes > > wrote: > > > > > > So is the feature model of FreeBSD becoming, oh it gets broken > > > cause it is not regularly tested, so lets remove that feature. > > > > I don't agree with that. We have a large and growing CI infrastructure > > to regularly test functionality and are continually adding to it over > > time. But it's important to test and maintain what is actually used > > and is useful. Disabling C++ support made sense when obrien@ added the > > original knob in 2000, but it makes less sense today when parts of > > FreeBSD are written in C++. > > > > You can disagree with my assertion, but I shall continue to assert > that it *seems* as if rather than adding B O S to the CI such that > it is not only regularly tested, but continuously tested is the > correct path forward here. Testing all possible options takes on the order days. Testing all possible combinations takes much longer. It's not practical to test them all on every commit. It's computationally difficult. > Removing an option that seems to > break due to not beeing tested (your original assertion) is not > only false (I pointed out, and do know for a fact that Michael > Dexter runs BOS on a very regulary basis, infact near continously.) > and the wrong path forward. > I think you're missing the data here. While it's great that Dexter's BOS run finds things (don't get me wrong here), the fact that he's finding it with a BOS run w/o user reports of it being broken suggests that it's not very popular. > Fix the broken stuff, stop letting stuff rot because you don't care > to work on it, or because it is not being "tested". > We do have to stop and consider the bigger picture: is it an option that's useful enough to have it be one of the subset of things we test on a regular basis, and enforce some sort of pre-commit requirements for. Or is it an option we're content to test after the fact and have some sane plan for remediation? Or is it an option that we've slavishly carried forward from a time where it made a lot of sense to a time where the situation on the ground is such that it no longer makes sense? That's the discussion we're having here. Is it important enough to require everybody to pay attention to it or not... Warner --00000000000075042e05d1b4a9ad-- From nobody Fri Nov 26 18:02:39 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1BD1518B25C0 for ; Fri, 26 Nov 2021 18:02:42 +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 4J12ds6bFYz3H8c; Fri, 26 Nov 2021 18:02:41 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (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 ABF3528D04; Fri, 26 Nov 2021 18:02:41 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 9236852BC5; Fri, 26 Nov 2021 19:02:39 +0100 (CET) Date: Fri, 26 Nov 2021 19:02:39 +0100 From: Baptiste Daroussin To: "Rodney W. Grimes" Cc: Ed Maste , FreeBSD Hackers Subject: Re: Retiring WITHOUT_CXX Message-ID: <20211126180239.rwuaaq3onohjoywv@aniel.nours.eu> References: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637949761; 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=phFrxVUMYGnb/SCwC7Kx78ANISFS+W6JCyZFxpLT7h4=; b=eWD0H01cR87l7uO0L492jqPsDqpf2d9Iw3gXO+QaprnyzaZgeauHDJWKr52s2yxp6nRaLC 9oHNmz2wLbk8iHmR0Pasvhh05hZ4wJD+vchMo5d/gp68JU89DmygYlE1YA35iLwbrKZN4s V1nTouB/7yfCsAQlqR6MecSVeMJPnl6VvcP4/36mHwjvU82swqkFxXsPU6UGEBrDtmJi7t Qz08l71HInkHcFQLBqbQrJmaPBGeXpjp99Vw6eAuD7htHSWZK+xYXHItlmWhVlsHiByyav zfvryZ+Y/0kI75lln8qFF0zcsqsHN35SSloAEKzk2Vks6IYYDZce+C2wVSRQIg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637949761; a=rsa-sha256; cv=none; b=a+fsWC3rT2onAG4kN0KkdBIQBKt+sgfWZq6YLYKqTSCfDnpwSD4gvDAS3fqddOZK5JXGuS Upj32O23Jph2in44jOqttLBRH9uZWotdYbZRuwladnkPdXCV3z5vtYnX28Z+sb8DNB8bz/ 2NQVhzkGX7PAF4tOZC2PxJ6m4C1XjPVfk41Vptbn9M9lNPFtQk/DDtlCAuaxVatPCzjtuC olv8WpfHqtdgW2gIXsAmLFdiRH/tjLmT8CyHFy/z0+XAhpoiaBa12uEZAjM0NL238doL2T IPzQtl37N/p0JdnREwA8NFijuvP87BzS2AfQ+BmGSGER9Om0XeWU+wzgqchDAg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Nov 26, 2021 at 09:09:54AM -0800, Rodney W. Grimes wrote: > [ Charset UTF-8 unsupported, converting... ] > > On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes > > wrote: > > > > > > So is the feature model of FreeBSD becoming, oh it gets broken > > > cause it is not regularly tested, so lets remove that feature. > > > > I don't agree with that. We have a large and growing CI infrastructure > > to regularly test functionality and are continually adding to it over > > time. But it's important to test and maintain what is actually used > > and is useful. Disabling C++ support made sense when obrien@ added the > > original knob in 2000, but it makes less sense today when parts of > > FreeBSD are written in C++. > > > > You can disagree with my assertion, but I shall continue to assert > that it *seems* as if rather than adding B O S to the CI such that > it is not only regularly tested, but continuously tested is the > correct path forward here. Removing an option that seems to > break due to not beeing tested (your original assertion) is not > only false (I pointed out, and do know for a fact that Michael > Dexter runs BOS on a very regulary basis, infact near continously.) > and the wrong path forward. > > Fix the broken stuff, stop letting stuff rot because you don't care > to work on it, or because it is not being "tested". This is a volunteer based project people are doing their best to try to fix broken stuff if 1/ they are aware of the issue 2/ if they are able to fix it. The limit of a volunteer project is how much time everyone can dedicate to it. The more options we have and more complex it is to ensure that every combinations do work. It is interesting how much you are patronizing every one on what should be fixed and what should be done and how but you are actually doing nothing as an individual to help here, you can volunteer to fix things at your level you know? This thread is about the usefulness of an option, and yet noone has demonstrated the usefulness of WITHOUT_CXX here in 2021. For any embedded systems the WITHOUT_* have never been enough and there are way to build a very very tiny viable FreeBSD image in an industrial manner which are way more efficient that the WITHOUT KNOBS. I am not saying we should stop providing those, just we should stop maintaining the one that makes no sense anymore or are very complicated to maintain. Best regards, Bapt From nobody Fri Nov 26 18:17:08 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 652BB18B9542 for ; Fri, 26 Nov 2021 18:17:12 +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 4J12yc0skYz3Mtg; Fri, 26 Nov 2021 18:17: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 1AQIH8p1025745; Fri, 26 Nov 2021 10:17:08 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 1AQIH8TS025744; Fri, 26 Nov 2021 10:17:08 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202111261817.1AQIH8TS025744@gndrsh.dnsmgr.net> Subject: Re: Retiring WITHOUT_CXX In-Reply-To: To: Warner Losh Date: Fri, 26 Nov 2021 10:17:08 -0800 (PST) CC: "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4J12yc0skYz3Mtg 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, Nov 26, 2021 at 10:11 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > [ Charset UTF-8 unsupported, converting... ] > > > On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes > > > wrote: > > > > > > > > So is the feature model of FreeBSD becoming, oh it gets broken > > > > cause it is not regularly tested, so lets remove that feature. > > > > > > I don't agree with that. We have a large and growing CI infrastructure > > > to regularly test functionality and are continually adding to it over > > > time. But it's important to test and maintain what is actually used > > > and is useful. Disabling C++ support made sense when obrien@ added the > > > original knob in 2000, but it makes less sense today when parts of > > > FreeBSD are written in C++. > > > > > > > You can disagree with my assertion, but I shall continue to assert > > that it *seems* as if rather than adding B O S to the CI such that > > it is not only regularly tested, but continuously tested is the > > correct path forward here. > > > Testing all possible options takes on the order days. Testing all > possible combinations takes much longer. It's not practical to test > them all on every commit. It's computationally difficult. There is more than one way to run CI type testing, one of those is to continuously run long tail types of testing in a loop, not testing every commit, but testing a fairly small set of commits. Love how the excuse is "oh, we cant do that so lets do nothing at all????" > > > > Removing an option that seems to > > break due to not beeing tested (your original assertion) is not > > only false (I pointed out, and do know for a fact that Michael > > Dexter runs BOS on a very regulary basis, infact near continously.) > > and the wrong path forward. > > > > I think you're missing the data here. While it's great that Dexter's BOS run > finds things (don't get me wrong here), the fact that he's finding it with > a BOS run w/o user reports of it being broken suggests that it's not > very popular. My take, many people stop reporting the broken stuff in FreeBSD and move to another platform. Lack of reports != lack of use, or lack of attemps. Further IIRC I have seen at least 2 people report they do use this option, probably not on a daily basis, but it is used. > > > > Fix the broken stuff, stop letting stuff rot because you don't care > > to work on it, or because it is not being "tested". > > > > We do have to stop and consider the bigger picture: is it an option > that's useful enough to have it be one of the subset of things we test > on a regular basis, and enforce some sort of pre-commit requirements > for. Or is it an option we're content to test after the fact and have some > sane plan for remediation? Or is it an option that we've slavishly > carried forward from a time where it made a lot of sense to a time where > the situation on the ground is such that it no longer makes sense? Already implemented, works, just got fixed, why are we even having the discussion? > > That's the discussion we're having here. Is it important enough to require > everybody to pay attention to it or not... > > Warner -- Rod Grimes rgrimes@freebsd.org From nobody Fri Nov 26 18:18:00 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C644318B9AB0 for ; Fri, 26 Nov 2021 18:18:09 +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 4J12zj4NTrz3NTb; Fri, 26 Nov 2021 18:18:09 +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 6C0898929B; Fri, 26 Nov 2021 18:18:07 +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 1AQII1SM077480 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 26 Nov 2021 18:18:01 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 1AQII0Ep077479; Fri, 26 Nov 2021 18:18:00 GMT (envelope-from phk) Message-Id: <202111261818.1AQII0Ep077479@critter.freebsd.dk> To: Baptiste Daroussin cc: "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers Subject: Re: Retiring WITHOUT_CXX In-reply-to: <20211126180239.rwuaaq3onohjoywv@aniel.nours.eu> From: "Poul-Henning Kamp" References: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> <20211126180239.rwuaaq3onohjoywv@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77477.1637950680.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Nov 2021 18:18:00 +0000 X-Rspamd-Queue-Id: 4J12zj4NTrz3NTb 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 -------- Baptiste Daroussin writes: > On Fri, Nov 26, 2021 at 09:09:54AM -0800, Rod= ney W. Grimes wrote: > > You can disagree with my assertion, but I shall continue to assert > > that it *seems* as if rather than adding B O S to the CI = I dont know how long time B-O-S runs these days, it used to take a couple of weeks, and I have a hard time squaring that with any contemporary use of the "CI" paradigme :-) -- = 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 Nov 26 18:19:11 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2AB9718BAA54 for ; Fri, 26 Nov 2021 18:19:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 4J13166CTxz3PQ9 for ; Fri, 26 Nov 2021 18:19:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x934.google.com with SMTP id a14so20336353uak.0 for ; Fri, 26 Nov 2021 10:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hLlQIDPYxXhMzp8Hgpw7YDWdRfDNlZsRk715ZR+JHfg=; b=FV/BcLfKNpBzIn6u2HZN8kMNwNIwc56AoVG0qzvkkHqUKFhd8BSMYoSCHuY3FtQMmt 8HVVrwQ+wrB6Vo1b1HiijB6zPR7S4IfwIsdwnr0zMxSHwsGqgomRFWQRGdl20dHQVeGV O+a2/mzoIpER/gYmu+W9htxiEvDN81daSA+QBk7A4mtc43ALJ3v5KvYPuZo4k9W7CgGU rA0JIhcZTEwuQUDxrbbd0zgzLcHxb7KN+1wu6bkftG14+qMMGjb+M6KkI0l9eEgLIq2P Ny+DHNLJtaqNuB+PQnXK2eB2WG7hvjv1TpPLFKic1+GzAQsmtfv6vxKpBEPmO5XyFqFv 1MXQ== 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=hLlQIDPYxXhMzp8Hgpw7YDWdRfDNlZsRk715ZR+JHfg=; b=u1L3EyRfCPCUm22UPKHeLX2XPlJ0pGH+cxQsJX6WJ0drg+Xb6AgeVSsgSSLOqtMyn8 4TmtTbfIA2m5NhG0j9GDq70k09VB8BJeww36DTtnpVoC0qp2Ugwwa/4QpBYEYtLMUnj+ cUe0wEby7BHFImDbAXUp0NOLyFR4JuTXEM/8yLcGF6+K1rbhnowuBor7qQ8FegJmEup8 tQONgx1Z3k7l8BdGjGgHH2qC9BPys3Q64Qqlfn1ldVbgMk2Z3mobZ/BC7AUK8yGORjbu 3lTojiCkadW6nqbvQ2LI23JwCmYJzlqlwUvwasFI/RAthxLn4dtQDk9pX5VAJchj4HSO dmHQ== X-Gm-Message-State: AOAM531zNyC7C1EA2dqAMY22SgTJWKpLsIllGk/J869Qx5+FLGVVU7T6 CT8fz/Gg7GJRLrzG/shtqVWE0RzcLw0raEwlqNGmjw== X-Google-Smtp-Source: ABdhPJzLu+mxXQ0GfpVn7cw+4aiCRqPANz1b1UHll2r8Ow4LVSf0r0GEY5v8Xtm+189inPKKzp2FmzkLeqagX21HoBQ= X-Received: by 2002:a67:f950:: with SMTP id u16mr19011388vsq.68.1637950762226; Fri, 26 Nov 2021 10:19:22 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> <20211126180239.rwuaaq3onohjoywv@aniel.nours.eu> In-Reply-To: <20211126180239.rwuaaq3onohjoywv@aniel.nours.eu> From: Warner Losh Date: Fri, 26 Nov 2021 11:19:11 -0700 Message-ID: Subject: Re: Retiring WITHOUT_CXX To: Baptiste Daroussin Cc: "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000057aa6705d1b52154" X-Rspamd-Queue-Id: 4J13166CTxz3PQ9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000057aa6705d1b52154 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 26, 2021 at 11:04 AM Baptiste Daroussin wrote: > For any embedded systems the WITHOUT_* have never been enough and there > are way > to build a very very tiny viable FreeBSD image in an industrial manner > which are > way more efficient that the WITHOUT KNOBS. I am not saying we should stop > providing those, just we should stop maintaining the one that makes no > sense > anymore or are very complicated to maintain. > Has anybody ever done the radical experiment of instrumenting a 'fat' system with filemon to see everything that's used/touched during operations and tailoring lists of files to include based on that (plus maybe some white listing for things like supported locales)? Warner --00000000000057aa6705d1b52154-- From nobody Fri Nov 26 18:21:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B139418BCF8B for ; Fri, 26 Nov 2021 18:21:40 +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 4J133m0qKBz3R3w for ; Fri, 26 Nov 2021 18:21:39 +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 73A97896A6; Fri, 26 Nov 2021 18:21:38 +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 1AQILWgY077511 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 26 Nov 2021 18:21:32 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 1AQILWh3077510; Fri, 26 Nov 2021 18:21:32 GMT (envelope-from phk) Message-Id: <202111261821.1AQILWh3077510@critter.freebsd.dk> To: Emmanuel Vadot cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? In-reply-to: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> From: "Poul-Henning Kamp" References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77508.1637950892.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Nov 2021 18:21:32 +0000 X-Rspamd-Queue-Id: 4J133m0qKBz3R3w X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- Emmanuel Vadot writes: > For libvgl it probably made sense back in the 90s but does it now ?? Have you grep'ed ports ? I remember it as libvgl happened in order to support certain emulation pro= grams. Mind you, that might have been ibcs2 :-) -- = 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 Nov 26 18:23:51 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7D11A18BEC1D for ; Fri, 26 Nov 2021 18:23:54 +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 4J136K4nYBz3jfV; Fri, 26 Nov 2021 18:23:53 +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 1AQINpde025795; Fri, 26 Nov 2021 10:23:51 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 1AQINp2R025794; Fri, 26 Nov 2021 10:23:51 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202111261823.1AQINp2R025794@gndrsh.dnsmgr.net> Subject: Re: Retiring WITHOUT_CXX In-Reply-To: <20211126180239.rwuaaq3onohjoywv@aniel.nours.eu> To: Baptiste Daroussin Date: Fri, 26 Nov 2021 10:23:51 -0800 (PST) CC: "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4J136K4nYBz3jfV 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, Nov 26, 2021 at 09:09:54AM -0800, Rodney W. Grimes wrote: > > [ Charset UTF-8 unsupported, converting... ] > > > On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes > > > wrote: > > > > > > > > So is the feature model of FreeBSD becoming, oh it gets broken > > > > cause it is not regularly tested, so lets remove that feature. > > > > > > I don't agree with that. We have a large and growing CI infrastructure > > > to regularly test functionality and are continually adding to it over > > > time. But it's important to test and maintain what is actually used > > > and is useful. Disabling C++ support made sense when obrien@ added the > > > original knob in 2000, but it makes less sense today when parts of > > > FreeBSD are written in C++. > > > > > > > You can disagree with my assertion, but I shall continue to assert > > that it *seems* as if rather than adding B O S to the CI such that > > it is not only regularly tested, but continuously tested is the > > correct path forward here. Removing an option that seems to > > break due to not beeing tested (your original assertion) is not > > only false (I pointed out, and do know for a fact that Michael > > Dexter runs BOS on a very regulary basis, infact near continously.) > > and the wrong path forward. > > > > Fix the broken stuff, stop letting stuff rot because you don't care > > to work on it, or because it is not being "tested". > > This is a volunteer based project people are doing their best to try to fix > broken stuff if > 1/ they are aware of the issue > 2/ if they are able to fix it. > > The limit of a volunteer project is how much time everyone can dedicate to it. > The more options we have and more complex it is to ensure that every > combinations do work. Every combination is not at issue here, what is at issue here is the fact that single options if used get broken. B O S catches these, that is all. > > It is interesting how much you are patronizing every one on what should be > fixed and what should be done and how but you are actually doing nothing as an > individual to help here, you can volunteer to fix things at your level you know? Doing nothing, Hum, ok, as usual you attacking the person, without full knowledge of what a person may or may not do (you do NOT have visibility into my world), Dexter would not even be running BOS had I not spent time helping him getting it set up, and helping him get the initial brokeness in a state that the fall out was an approachable task. > > This thread is about the usefulness of an option, and yet noone has demonstrated > the usefulness of WITHOUT_CXX here in 2021. Seems more false assertions, I do believe 2 people in the thread have asserted that they a) use this option and b) find its function useful. > > For any embedded systems the WITHOUT_* have never been enough and there are way > to build a very very tiny viable FreeBSD image in an industrial manner which are > way more efficient that the WITHOUT KNOBS. I am not saying we should stop > providing those, just we should stop maintaining the one that makes no sense > anymore or are very complicated to maintain. Exists, is used, presently works. Does it make sense to remove it? > Best regards, > Bapt -- Rod Grimes rgrimes@freebsd.org From nobody Fri Nov 26 18:24:52 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0D67618BEEE9 for ; Fri, 26 Nov 2021 18:24: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 4J137W6vgbz3kJp; Fri, 26 Nov 2021 18:24:55 +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 1AQIOrJa025805; Fri, 26 Nov 2021 10:24:53 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 1AQIOq0Y025804; Fri, 26 Nov 2021 10:24:52 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202111261824.1AQIOq0Y025804@gndrsh.dnsmgr.net> Subject: Re: Retiring WITHOUT_CXX In-Reply-To: <202111261818.1AQII0Ep077479@critter.freebsd.dk> To: Poul-Henning Kamp Date: Fri, 26 Nov 2021 10:24:52 -0800 (PST) CC: Baptiste Daroussin , "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4J137W6vgbz3kJp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > -------- > Baptiste Daroussin writes: > On Fri, Nov 26, 2021 at 09:09:54AM -0800, Rodney W. Grimes wrote: > > > > You can disagree with my assertion, but I shall continue to assert > > > that it *seems* as if rather than adding B O S to the CI > > I dont know how long time B-O-S runs these days, it used to take > a couple of weeks, and I have a hard time squaring that with any > contemporary use of the "CI" paradigme :-) Dexter can provide an exact number, but IIRC on his purpose built test box it is on the order of 2 or 3 days. -- Rod Grimes rgrimes@freebsd.org From nobody Fri Nov 26 18:34:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D9C4418A38C6 for ; Fri, 26 Nov 2021 18:34:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J13LY555Bz3nW7 for ; Fri, 26 Nov 2021 18:34:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f41.google.com with SMTP id p23so12502769iod.7 for ; Fri, 26 Nov 2021 10:34:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lR/RrB3i0lWEj4wS/LvITepqNK1I5G5Mvy0YnR9ENWc=; b=cEQ+3F7za5seozacWYPL7IZXupqqfG/qt6zan07ZDE6T+zxkCZgpZDn/v4EHbS7r0T nBgT0U6vlaHTLU7Tp6igjwSDuOMLCyCBEer7OPzRwXRyOQ0Ept9E8Ui1XXqwmui4RAWC VAF9zDIho0+NVQ0om3svlRAw5/GQiPX7IeEPEOVKvuyeKH9rglWyqB4ptX4heZI7e7vS wh0IYpGxMchS7TpSIZzjHjGLISOvvG07hHWtqoUdbT35k+pxvVpXwOF6DrN8CMjAGz12 IClcaJH1E/VdVl7nmw7N1SrXQ2xiBfW96MTlgW7LAyAMBtTeWthPdhg+ev1s6DoMZVcz ZIWA== X-Gm-Message-State: AOAM5325hFiJztNgqH/Ug5o4lkm7w8gz8lfX2bHhyMZqx6ef96W9CmIl tFpAv1jrFTMaIfLbaTSGUnZ/0+OvDwjmIKNXYt7AkO4sqsw= X-Google-Smtp-Source: ABdhPJxBWSf4nnw+1o9jWzjOygmGRh0Kwns34pMWCzNJhzT+PcURFETSh2hITZBK3IXpXOYH08fCF9Jpry2rcxNuRak= X-Received: by 2002:a05:6638:22c2:: with SMTP id j2mr44903670jat.105.1637951663070; Fri, 26 Nov 2021 10:34:23 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> In-Reply-To: From: Ed Maste Date: Fri, 26 Nov 2021 13:34:10 -0500 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Stefan Blachmann Cc: Emmanuel Vadot , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J13LY555Bz3nW7 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, 26 Nov 2021 at 10:45, Stefan Blachmann wrote: > > - vt is so horridly buggy that it is no fun to use it at all if one is > accustomed to well-working, bugfree sc(4). Just one example: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211922 This issue is waiting on feedback since 2021-09-25. There is one issue that's still reproducible when I last tested, but "horridly buggy" is quite a stretch. From nobody Fri Nov 26 18:38:15 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D483518A7ED8 for ; Fri, 26 Nov 2021 18:38:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J13R64kktz3rRj for ; Fri, 26 Nov 2021 18:38:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92e.google.com with SMTP id j14so20237618uan.10 for ; Fri, 26 Nov 2021 10:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZZ4e94ip7HzL8GQGnb4XyF61dO/sgzawA+VNiK9T1/4=; b=Xsxy6nuolzfKEyChSyatx6bx4IkUt2Knme55Ko63E5U46ZrCn9vuidSpgd2+rGlNXo gFh1eW/7Kg8wCaMO621TDg2zAs//p6zuyYo8j4xrbXlnyMW6nCInbLEj7ob7H8fIskyt 3dB2L7HqRVIsgOi4wnfMxlYXf/xLE24IEznMBuOOpX2GmudFzzdV9u53ThKnCO1LrhdS C3GYlKUb9msiuQ1U6+QLUfK4c1J/MZrR9m8U6iDQjsjJ+uB6WnmXu3N9dd7FAav/4FCz ZgKkqpMPi4xmac9RP+GAUglSuW7l82J8wpyfvwzmsiWC+jJp63H6cm119H81CW8AMx72 6AfQ== 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=ZZ4e94ip7HzL8GQGnb4XyF61dO/sgzawA+VNiK9T1/4=; b=ksX9LHH6izUNjXqSfu5+m6h58VnuLe8Z4wHz9KX3jwoP5NFAu7xVNlXA6bAOt3rAS/ rgZdQuWpPv/WDAgMsQX9K1FeklogDb0lKV2EedFe352t7512u8r33yBE5rELw4bytCbP QiGQMvrSaaVTY9q1RIkQDuT7nIV6iGQuK8ZImxR5yAUEIOACqRa8WFDcqULAlqNRpPWp /OT2ttDomQoHeTqOeqbAxP0wf4T/CF9RdlhnAO0HxVzuwH8iXt2znM78Qr77vpobJacg Wx8gDHIrjnPoLCQOZUtOTFCsK6DhMfzFnwkzJ/r015iaYQsPFAIxlL7avkp6A7aiSjX3 PZQA== X-Gm-Message-State: AOAM5327ylQpeQVK4llHuhh7xsVc5B8OxEVoijdzof9MtOTLrp/tkTmq dvrX4p+dkyUnGz0RRH6+BNa4dKqefHaWK/DZRVs4iierjb5kQg== X-Google-Smtp-Source: ABdhPJxPXo9VmlTJbtJDtlWvrfoDbgPe2/fP2+ThZC2Wy8nMijPshmg3hSk/ypYyIQofDCIH2rK/enHA2Nn6xg+aUNA= X-Received: by 2002:a67:ec8f:: with SMTP id h15mr19088925vsp.42.1637951906232; Fri, 26 Nov 2021 10:38:26 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202111261817.1AQIH8TS025744@gndrsh.dnsmgr.net> In-Reply-To: <202111261817.1AQIH8TS025744@gndrsh.dnsmgr.net> From: Warner Losh Date: Fri, 26 Nov 2021 11:38:15 -0700 Message-ID: Subject: Re: Retiring WITHOUT_CXX To: "Rodney W. Grimes" Cc: Ed Maste , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000087d1e205d1b565a6" X-Rspamd-Queue-Id: 4J13R64kktz3rRj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000087d1e205d1b565a6 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 26, 2021 at 11:17 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > Already implemented, works, just got fixed, why are we even having > the discussion? > Asked and answered: we have too many options, and this one broke and nobody noticed for a while. Does it make sense to continue to even having it, risking that it will break again in the future as it's proven to be a bit fragile over the years. Warner --00000000000087d1e205d1b565a6-- From nobody Fri Nov 26 18:46:35 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8939C18AC48F for ; Fri, 26 Nov 2021 18:46:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 4J13cs3GLnz3vhZ for ; Fri, 26 Nov 2021 18:46:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f54.google.com with SMTP id z26so12500876iod.10 for ; Fri, 26 Nov 2021 10:46:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g3trK6BmbdXg37Zw+hT19MM5szncMtANjzBNDIXknrM=; b=3zyyd3hh8fWkN89AecugbbMDeV9smfm77A34MjwA0XJyvEtarbEKTwQ15/K9F/1YZE iFXvNEXlNvCXv+hkSR+B4PtBZYOC6rYi0XlafqacE4lBg8xg/trhPB8X8OFUtwbkz2/z Fq7yH2erK7tDgV1ZySQ44xB8IKPumTvTK1ZSOZ8n1521eZuZA1Ca4MB+fUFJePm0tPer pOHM6cA3rhkU3SqFyxrET5BTETsWPHDJXkUvhK6ESBjnsT/du9JxRZiKT7wp4LvLMI1Y wK+FugJMpA9nkqCScyGkgr2KlAc8EwjFXaWbeEYXZnIgUp6mtyNqFTE5osDNTwbe03O3 dtcA== X-Gm-Message-State: AOAM532E2e0qKdR+LDFoAfyqThI5gG5DL6FBlJIZ8VY5sixquHdSWjEM cYcRXUjFWEGo1PZofcLMTzS7hb3LWldJwydgSLI= X-Google-Smtp-Source: ABdhPJw7Wsn0uSVyGSSU1plOrxb2DcvJTuZBHrzshSNvXMnJ3I5SQ/mg6FlFzen25cRgVE7XXx8s1BHu4kE57ESBGIE= X-Received: by 2002:a05:6602:2d81:: with SMTP id k1mr36500673iow.112.1637952407637; Fri, 26 Nov 2021 10:46:47 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> In-Reply-To: <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> From: Ed Maste Date: Fri, 26 Nov 2021 13:46:35 -0500 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Eugene Grosbein Cc: Emmanuel Vadot , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J13cs3GLnz3vhZ 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, 26 Nov 2021 at 11:00, Eugene Grosbein wrote: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172 As far as I can tell all reports in this PR are due to broken ACPI tables reporting that there is no VGA present. If there are any cases where hw.vga.acpi_ignore_no_vga="1" does *not* work as a workaround, please note them in the PR. From nobody Fri Nov 26 18:47:35 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A62F218AC957 for ; Fri, 26 Nov 2021 18:47:43 +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 4J13dq2DLdz3w8L; Fri, 26 Nov 2021 18:47:43 +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 C0BF7896A6; Fri, 26 Nov 2021 18:47:41 +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 1AQIlZK9077631 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 26 Nov 2021 18:47:35 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 1AQIlZsH077630; Fri, 26 Nov 2021 18:47:35 GMT (envelope-from phk) Message-Id: <202111261847.1AQIlZsH077630@critter.freebsd.dk> To: "Rodney W. Grimes" cc: Baptiste Daroussin , Ed Maste , FreeBSD Hackers Subject: Re: Retiring WITHOUT_CXX In-reply-to: <202111261824.1AQIOq0Y025804@gndrsh.dnsmgr.net> From: "Poul-Henning Kamp" References: <202111261824.1AQIOq0Y025804@gndrsh.dnsmgr.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77628.1637952455.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Nov 2021 18:47:35 +0000 X-Rspamd-Queue-Id: 4J13dq2DLdz3w8L 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 -------- Rodney W. Grimes writes: > > -------- > > Baptiste Daroussin writes: > On Fri, Nov 26, 2021 at 09:09:54AM -0800,= Rodney W. Grimes wrote: > > = > > > > You can disagree with my assertion, but I shall continue to assert > > > > that it *seems* as if rather than adding B O S to the CI = > > = > > I dont know how long time B-O-S runs these days, it used to take > > a couple of weeks, and I have a hard time squaring that with any > > contemporary use of the "CI" paradigme :-) > > Dexter can provide an exact number, but IIRC on his purpose built > test box it is on the order of 2 or 3 days. Well, sponsor his electricity bill then... -- = 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 Nov 26 18:48:44 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7331618AD821 for ; Fri, 26 Nov 2021 18:48:56 +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 4J13gD1y4kz4RF1 for ; Fri, 26 Nov 2021 18:48:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id 84so6548064vkc.6 for ; Fri, 26 Nov 2021 10:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OgezigoHCgZQRe6Lq8jiouVwU89twzL16YbjElU+Hhc=; b=7PC/4CkxFkfcVPQyN8zv+Q465l0wmCEz+euSeDHy6QaqHiGOlH+sWnoRjSfbiTBUIk 9HJg51Sa1dmB3wQJ94hUu2M48I6DceuFROxjjWu8aEd2Dg9urK54KuegMtt5BU7D0lHD lfezhu6B03CyQjK/7vygD3ENIAcmM5VNL4QxCE5ceQt2gVRpFLo8uv0PDDXU0OvTPjnx vUGPTFlqs06nqikN4+FyoO+24hNENCHCwVCY4kk4etCB1uZce1OwRgdqoKaGfdO7nWNB LH6Mww189OiC545ANbQyEBFSiUny2dPRJ4W4ECM9kXTHqk8ycXTniyb4ffBdaaiz5oWR qp5w== 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=OgezigoHCgZQRe6Lq8jiouVwU89twzL16YbjElU+Hhc=; b=p9kk+90kRxFhbA4lEVFgdWJbdirO++4pmmqnvRge4WRCJ/g2glO9m90muITLuF7EO+ 6D6c3VZA+65ftRZ9IxQ/dm5ZYcqApOYApubqsMHag5N66yKHJwu7m9oVPas7vzkPHY2E iaaUKL+4B/TaYk/+FmDrzqMyPufj9+II+8xFNkwV/tNKHL6oR6D/OZ6DP/bpEPWrWgok lcSJK3gWi0W6Pi096JnD5jpHZ+0JPEvaqqFnF3k5ukW8ISBO7wxH1ad64hqe2cterOXu iX12UGCU9lYo6wzb9myhcmLbYzR31/FAolazlAQxBGGb2TD/8+6ZyppXe2nEPdcJxxTH sBpw== X-Gm-Message-State: AOAM532Manb2DDgbq//fjq0GHDAVG1lwQrUGed13aygPi0X4UpvXo1rK n9jmuFhvqMoE76vyebFOe8ms5p9oddDXrt+I3Xm0QKVE81Fq4A== X-Google-Smtp-Source: ABdhPJxWungt3ZQUvzReB4TAhu//nxqUv4aI4AOYt/6luD/VsU85dJ6dW54bJ+XHS45skbmiGpaI3tggaHfZPe/GIBs= X-Received: by 2002:a1f:5c86:: with SMTP id q128mr16973685vkb.40.1637952535714; Fri, 26 Nov 2021 10:48:55 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202111261818.1AQII0Ep077479@critter.freebsd.dk> <202111261824.1AQIOq0Y025804@gndrsh.dnsmgr.net> In-Reply-To: <202111261824.1AQIOq0Y025804@gndrsh.dnsmgr.net> From: Warner Losh Date: Fri, 26 Nov 2021 11:48:44 -0700 Message-ID: Subject: Re: Retiring WITHOUT_CXX To: "Rodney W. Grimes" Cc: Poul-Henning Kamp , Baptiste Daroussin , Ed Maste , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000000cf31e05d1b58be6" X-Rspamd-Queue-Id: 4J13gD1y4kz4RF1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000000cf31e05d1b58be6 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 26, 2021 at 11:26 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > -------- > > Baptiste Daroussin writes: > On Fri, Nov 26, 2021 at 09:09:54AM -0800, > Rodney W. Grimes wrote: > > > > > > You can disagree with my assertion, but I shall continue to assert > > > > that it *seems* as if rather than adding B O S to the CI > > > > I dont know how long time B-O-S runs these days, it used to take > > a couple of weeks, and I have a hard time squaring that with any > > contemporary use of the "CI" paradigme :-) > > Dexter can provide an exact number, but IIRC on his purpose built > test box it is on the order of 2 or 3 days. > I can do a clean buildworld in about ~20-30 minutes on my fastest machine. There's ~300 build options which puts us at ~74 hours, or ~3 days. I've not done a build survey, though, to know for sure. Note that this doesn't do combinations, which is a combinatoric explosion in size (even doing all pairs would be 150x slower). Which is at least ~20x too slow to put into any pre-commit workflow, but would be suitable for periodic testing, perhaps. But then we need to ask if that ~75 hours of CPU time on a 128-thread CPU generates useful information in proportion to the size of the test... But it boils down to all things having a cost. And some costs are too great. Warner --0000000000000cf31e05d1b58be6-- From nobody Fri Nov 26 19:06:13 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D807B18B5D82 for ; Fri, 26 Nov 2021 19:06:15 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 4J143C5J2sz4ZT2; Fri, 26 Nov 2021 19:06:15 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x129.google.com with SMTP id n12so26501386lfe.1; Fri, 26 Nov 2021 11:06:15 -0800 (PST) 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=06G7JDhslX8eVwKMUinvrXDgobkdNlRSijHtUk+r8k4=; b=KO4ABqoJV7t0XdPF3Tl+HE0n63s8jHmhKJ8zE/WtbXk5XDzfnAGu+b0K6JJ6orVrwk IRt9l7Q71Frqrf3UZyfpJnIQQFL1k1qkp0bYwJ9wqMVHpq7De1e7zb2KPU1Kk18QTF8R Kl11Sm4bKRlC4WFKzSUXtxLnUgIf6bOclwVcBKrRX791zFTxK+F8NylpnFk0cxuhAU6S JVW5hJTZbkZgQdg/LM/kYR14nQbYXWZZ18lRvdNW6MS+rdHCbgyuGHIJsBCpLUuKzgUi 0CjnFyKnkPSnntV01RMAh/yZp+RIN1RFj5+PB11falZBbrxb/rW/g/96H3sdha3QZok7 TPHA== 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=06G7JDhslX8eVwKMUinvrXDgobkdNlRSijHtUk+r8k4=; b=jzBYSfHA1xaJatdG9Fof/DVYU6SoqxXREBxFqSGewA8XvMuODmtariqNRNJuy+Fmb4 JamLVudeBGroKtXRHTCQna1M2FpkQSN6UgTCvOfWgnA1MqTf31aGnVtyy5o5WBs0bVhR 4cM3i3kfLYiuBMAbWwde9ma8lEBXHQJ/yUlnY30Ph9JqbetHMWKvok5tJR015cw0QUE5 r8U/OT4jiXINK/tCk5nRqJNQWHJP3FG0Z1yBiVwiRG9Kn3Ys9bm60RrySMtK/76aOykV UeC78swWbW7C870e0hjnv9yIKPQvCpQbDBar4AkcsEf/MDSV2aK1i9tugHCug8E9AJLy 90YQ== X-Gm-Message-State: AOAM530Jd2Dlka6boNxktDB8Zd8saivuTV+UCU87C/Z1U9BmJmiVAvda Bn20yOW+DYkuv2givGdmUU0CtoLlmb8z7QINt2uv+Z3I X-Google-Smtp-Source: ABdhPJw6HQx5A5xOE4zfMmFrEWCvIIVmNejCecJ4ueEsdHuLBGInffxkjlwO9pK6pPSgdEf750liZRkI46R7ebAz4yw= X-Received: by 2002:a05:6512:e89:: with SMTP id bi9mr31729747lfb.465.1637953574419; Fri, 26 Nov 2021 11:06:14 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Fri, 26 Nov 2021 11:06:13 -0800 (PST) In-Reply-To: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> From: Stefan Blachmann Date: Fri, 26 Nov 2021 20:06:13 +0100 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Ed Maste Cc: Emmanuel Vadot , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J143C5J2sz4ZT2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N I encountered some other bugs in vt while I used it. Aside of the computers I am using for testing of my installer, I use vt only in the time from installation of computers to when I get time to configure/build a new kernel to remove vesa (and vt because it pulls in vesa,ko) from the kernel to make suspend/resume work. So I feel usually in some hurry when I want to get a system up and running.. And then I am not in the mood to bother spending time making vt bug reports. Maybe a reason that many of these bugs are not reported is that I love to use mouse mark/paste in the console, and most of the bugs are related to this. No idea how common it is to use mice in console mode; if it is not common this might be why these bugs are apparently under-reported. Almost all my computers still have CSM support, so I use that, as I do not use Microsoft OSes. When time comes and I have to buy computers that do no longer support CSM, I'll look into the sc source to add a VGA BIOS interrupt call to change from UEFI graphics to text mode at initialization time. This should be sufficient to support sc on UEFI machines. Actually I do not understand why this has not yet been done. Do you think such a patch to make sc work on UEFI systems would be accepted into FreeBSD? On 11/26/21, Ed Maste wrote: > On Fri, 26 Nov 2021 at 10:45, Stefan Blachmann > wrote: >> >> - vt is so horridly buggy that it is no fun to use it at all if one is >> accustomed to well-working, bugfree sc(4). Just one example: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211922 > > This issue is waiting on feedback since 2021-09-25. There is one issue > that's still reproducible when I last tested, but "horridly buggy" is > quite a stretch. > From nobody Fri Nov 26 19:06:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5BBDC18B5DEE for ; Fri, 26 Nov 2021 19:06:51 +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 4J143v1Nz9z4b0F; Fri, 26 Nov 2021 19:06:50 +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 1ABD58D4A212; Fri, 26 Nov 2021 19:06:46 +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 41A10E70816; Fri, 26 Nov 2021 19:06:45 +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 pr2YUdDQue4p; Fri, 26 Nov 2021 19:06:43 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3AD8BE707D9; Fri, 26 Nov 2021 19:06:43 +0000 (UTC) Date: Fri, 26 Nov 2021 19:06:42 +0000 (UTC) From: "Bjoern A. Zeeb" To: Ed Maste cc: FreeBSD Hackers Subject: Re: Retiring WITHOUT_CXX In-Reply-To: Message-ID: References: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4J143v1Nz9z4b0F 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, 26 Nov 2021, Ed Maste wrote: > On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes > wrote: >> >> So is the feature model of FreeBSD becoming, oh it gets broken >> cause it is not regularly tested, so lets remove that feature. > > I don't agree with that. We have a large and growing CI infrastructure > to regularly test functionality and are continually adding to it over > time. But it's important to test and maintain what is actually used > and is useful. Disabling C++ support made sense when obrien@ added the > original knob in 2000, but it makes less sense today when parts of > FreeBSD are written in C++. I used to disable it in my images but started to need devd and that is really the only reason its there currently #WITHOUT_CXX= # devd needs it I used to have a conversation with Warner a while ago about it and the conclusion was the bits of C++ could be reimplemented in C if needed but obviously no one ever got to that. Maybe it would be good to list what it actually stops building. - devd / libdevdctl - a specific about libproc - dtc - atf / kyua - zfsd - users (that's a wow but okay); can't remember when I last typed that - "toolchain" but that's a dead end for tiny images anyway Ignoreing lib*.a it's still going to save 800-900k on libraries which is a lot of dead weight if you don't need it and removing the knob means one has to do it in post-processing on ones own so re-implementing the wheel... Even on 40MB images that is still more than 2% and I wish I could save those every time. Finding a 2% performance improvement for the kernel one wouldn't "waste" so easily. Here's an example of what happens over time (compressed!) just to give you an idea: 5.3M Dec 29 2007 base7-radiata-200712290220.gz 11M Aug 10 2020 base13-radiata-r364080.gz There's gazillions of things I'd rather remove or combine and things which never made sense to me to be MK_* src.conf knobs really but the explosion of options is elsewhere but not on CXX which never made more sense than it did today. my 2cts /bz -- Bjoern A. Zeeb r15:7 From nobody Fri Nov 26 19:17:00 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7F3F18B9DB7 for ; Fri, 26 Nov 2021 19:17:12 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J14Hq2Q1Sz4dx7 for ; Fri, 26 Nov 2021 19:17:11 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 1AQJH0JU051484 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 26 Nov 2021 20:17:00 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1637954220; bh=SYzv8Nn2D3/wvNTVHE3JT6OL9LUyIEI+dhw+zDWpbg4=; h=Date:From:Subject:To:References:In-Reply-To; b=HW4BAgYwFfVYJthseMLknOtnxeuk6AdpF1tCcf4Bx2bQKhfq7ivOfjUmCFzf1Iqiu 77J25gl8DSiZUuytPDAAP5wIIVKRLBGcDMR7f55U/5VJr3YR+y5dCzl1QZM4LnGDlT zKZ+LRTXfx6VvT07IIESfb+4zWVb6pcdB0A+Wd27NasvxNc12nqSn83tTTGbIRmeIc Y6/iL/o1531e5OYhlBGUGkgkvXrzWoSVoKExHt5jGhviryIjR3e5iXAG4PpRP8cAIM AH4uPKM6UMsgI/7Noaqb8XxCHfSa9PGQSHzJWkUKyt3WquWHUXBC4VlYVAjbBxqolU bleDzK/DMVGKw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: <93f6f099-fb1c-bad2-1001-b6efe698dc65@plan-b.pwste.edu.pl> Date: Fri, 26 Nov 2021 20:17:00 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 From: Marek Zarychta Subject: Re: Reasons for keeping sc(4) and libvgl ? To: freebsd-hackers@freebsd.org References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> Content-Language: pl In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------7pKKf6SzNELJhEW1TcZS8CCE" X-Rspamd-Queue-Id: 4J14Hq2Q1Sz4dx7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=HW4BAgYw; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-0.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ATTACHMENT(0.00)[]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------7pKKf6SzNELJhEW1TcZS8CCE Content-Type: multipart/mixed; boundary="------------Sep00Lhi6C1hmXcMXu0PFH5L"; protected-headers="v1" From: Marek Zarychta To: freebsd-hackers@freebsd.org Message-ID: <93f6f099-fb1c-bad2-1001-b6efe698dc65@plan-b.pwste.edu.pl> Subject: Re: Reasons for keeping sc(4) and libvgl ? References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> --------------Sep00Lhi6C1hmXcMXu0PFH5L Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SG9ub3VyYWJsZSBjb21taXR0ZXJzLCBkZWFyIHN1YnNjcmliZXJzLA0KDQpXIGRuaXUgMjYu MTEuMjAyMSBvwqAxNjowNCwgRW1tYW51ZWwgVmFkb3QgcGlzemU6DQo+IA0KPiAgIEhlbGxv IGFsbCwNCj4gDQo+ICAgSSdtIGN1cnJlbnRseSByZS1pbXBsZW1lbnRpbmcgdGhlIGZyYW1l YnVmZmVyIGNvZGUgaW4gbGludXhrcGkgZm9yDQo+IGRybS1rbW9kIGFuZCB0aGlzIG1hZGUg bWUgbG9vayBhdCBzYyg0KSwgdnQoNCkgYW5kIGZyaWVuZHMuDQo+IA0KPiAgIFNvIEkgbG9v a2VkIGF0IHdoYXQgc2MgY291bGQgZG8gYW5kIHZ0IGNvdWxkbid0IGFuZCB2aWNlLXZlcnNh Lg0KPiANCj4gICBXaGF0IHNjKDQpIGNhbid0IGRvIDoNCj4gDQo+ICAgLSBXb3JrIHdpdGgg RUZJIGZpcm13YXJlLg0KPiAgIC0gU3VwcG9ydCBVVEYtOA0KPiAgIC0gTWF5YmUgb3RoZXIg dGhpbmdzIGJ1dCBldmVyeXRoaW5nIGhlcmUgaXMgRUZJLWJhc2VkIHNvIGxldCBtZSBrbm93 Lg0KPiANCj4gICBXaGF0IHZ0KDQpIGNhbid0IGRvIDoNCj4gDQo+ICAgLSBZb3UgY2FuJ3Qg Z2V0IHRoZSBtb2RlcyBvciBhZGFwdGVyIGluZm8gd2l0aCB2aWRjb250cm9sLg0KPiAgICAg dmlkY29udHJvbCAtaSBtb2RlIGlzIHJlYWxseSBtYWRlIGZvciBhbnl0aGluZyB2ZXNhIGJh c2VkIGFzIGl0DQo+IGl0ZXJhdGVzIG9uIGFsbCB0aGUgbW9kZXMgYW5kIGRpc3BsYXkgdGhl bSBpZiBwcmVzZW50Lg0KPiAgICAgSW4gdGhlIG1vZGVybiB3b3JsZCAoRUZJKSwgd2UgZG9u J3QgaGF2ZSB0aGF0LCBFRkkgR09QIGRvZXNuJ3QNCj4gc3VwcG9ydCBjaGFuZ2luZyByZXNv bHV0aW9uIGFmdGVyIEV4aXRCb290U2VydmljZSB3YXMgY2FsbGVkIHNvIHRoZXJlDQo+IGlz IG9ubHkgb25lICJtb2RlIi4gSSBjb3VsZCBwb3NzaWJseSBoYWNrIHNvbWUgcGF0Y2ggc28g dmlkY29udHJvbCAtaQ0KPiBtb2RlL2FkYXB0ZXIgd291bGQgd29yayBhbmQgZGlzcGxheSB0 aGUgY3VycmVudCBmcmFtZWJ1ZmZlciBpbmZvIGlmDQo+IHBlb3BsZSB3YW50cyAoYnV0IEkg aG9uZXN0bHkgZG91YnQgdGhhdCB2aWRjb250cm9sIGlzIHVzZWZ1bCBhdCBhbGwgaW4NCj4g YW4gRUZJIHdvcmxkKS4NCj4gICAtICJCbGFua2luZyIgc2NyZWVuIGRvZXNuJ3QgZG8gd2hh dCB5b3UgdGhpbmsgaXQgZG9lcy4gRm9yIHNvbWUgcmVhc29uDQo+IGluIHZ0KDQpIHdlIGp1 c3Qgd3JpdGUgYmxhY2sgY29sb3JzIG9uIHRoZSBzY3JlZW4gYW5kIGlnbm9yZSB0aGUgYmxh bmsNCj4gbW9kZSBwYXNzZWQgaW4gdGhlIGlvY3RsLg0KPiAgICAgTm93IGFnYWluLCBibGFu a2luZy9kcG1zL2JsYWggaXNuJ3QgcG9zc2libGUgd2l0aCBlZmlfZmIgYnV0IGl0IG1ha2UN Cj4gc2Vuc2UgdG8gZml4IHZ0KDQpIGFuZCBkcm0ta21vZCBzbyBpdCBjYWxscyB0aGUgZHJt IG1vZHVsZSBibGFua2luZw0KPiBmdW5jdGlvbiwgSSdsbCB3b3JrIG9uIHRoYXQgbmV4dCB3 ZWVrLg0KPiAgICAtIFRoZXJlIGlzIG5vIHNjcmVlbnNhdmVyLCBhZ2FpbiBzZWUgbm90ZXMg YWJvdmUgZm9yIGRwbXMgYnV0IGRvDQo+IHBlb3BsZSBzdGlsbCB1c2Ugc2MoNCkganVzdCBm b3IgdGhlIHNjcmVlbnNhdmVyID8/DQo+ICAgIC0gTWF5YmUgb3RoZXIgdGhpbmdzLCBwbGVh c2UgbGV0IG1lIGtub3cuDQo+IA0KPiAgIEZvciBsaWJ2Z2wgaXQgcHJvYmFibHkgbWFkZSBz ZW5zZSBiYWNrIGluIHRoZSA5MHMgYnV0IGRvZXMgaXQgbm93ID8/DQo+IA0KPiAgIEJhc2Vk IG9uIG15IHNtYWxsIGxpc3QgSSBkb24ndCBzZWUgYW55IGdvb2QgcmVhc29uIHRvIGtlZXAg c2MoNCkgYnV0DQo+IG1heWJlIEkndmUgbWlzc2VkIHNvbWV0aGluZyBiaWdnZXIgc28gcGxl YXNlIGxldCBtZSBrbm93Lg0KPiANCj4gICBQLlMuOiBJJ20gcmVhbGx5IG5vdCBpbnRlcmVz dGVkIGJ5IHBlb3BsZSBzYXlpbmcgc3R1ZmYgbGlrZQ0KPiAgICJJJ3ZlIGFsd2F5cyB1c2Vk IHNjKDQpLCBpdCB3b3JrcyBmb3IgbWUgZG9uJ3QgdG91Y2ggaXQiDQo+ICAgd2l0aG91dCBz b21lIHRlY2huaWNhbCBhcmd1bWVudC4NCj4gDQo+ICAgQ2hlZXJzLA0KPiANCkkgcmVzcG9u ZGVkIHRvIHRoaXMgaW5xdWlyeSBvbiBJUkMgZWFybGllciwgYnV0IHdpbGwgYWxzbyBnaXZl IHNvbWUgDQpmZWVkYmFjayBoZXJlLg0KDQpUaGVyZSBpcyBvbmx5IG9uZSByZWFzb24gZm9y IG1lIHRvIHN0aWxsIHVzZSBzYyg0KSBvbiBhIGZldyBhbWQ2NCANCm1hY2hpbmVzIG5vdCBy dW5uaW5nIFgxMSBzZXJ2ZXJzIHdoaWNoIGhhdmUgZWl0aGVyIG9sZCBLVk1zIG9yIGRpcmVj dGx5IA0KY29ubmVjdGVkIG1vbml0b3JzOiB0aGUgYWJpbGl0eSB0byB1c2Ugc2F2ZXIoNCkg d2l0aCBncmVlbl9zYXZlci5rbyANCndoaWNoIGNhbiBwb3dlciBvZmYgdGhlIG1vbml0b3Ig dmlhIERQTVMuIFByb2JhYmx5IGl0IGlzIG9uZSBvZiB0aGUgbW9zdCANCm1pc3NpbmcgZmVh dHVyZXMgb2YgdnQoNCkuDQoNClJlZ2FyZHMsDQoNCi0tIA0KTWFyZWsgWmFyeWNodGENCkZy ZWVCU0QgdXNlciBzaW5jZSBtaWQtMTk5MHMNCg== --------------Sep00Lhi6C1hmXcMXu0PFH5L-- --------------7pKKf6SzNELJhEW1TcZS8CCE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmGhMqwFAwAAAAAACgkQHZW8vIFppoKb owf7B0pgOLBx1TW/c5qt1SqbMCxJS/fpKtgsiLRC9h6NCa6qKPXoRAAoA7umuzMklNiljHVhRflf AJNn/LW+cj+cq/Yowsk7VOccga28m7A7AicCawSpY3MzVVKgtOCzw1zTV5bkW/ClXUzrxjfC1YRL 5oLXmTtOLlXIme1+F0u2cTVmDHeCg/+y2T+g0450wblv7zg2RC5OD03CrQdg+e1+cDWAdWRvidB8 dBJTGwkfYa7IpVHBG8bR7ZNz1C1x1Q8WUUKcw8N1pvFBSkEVyVKqHpoyyyXCSQN6AH3SpT2llMjt bM6ITEkdhk9pwHDMeRJKJ7PvgvgrnFYt/5mI5Iqn4g== =1RCX -----END PGP SIGNATURE----- --------------7pKKf6SzNELJhEW1TcZS8CCE-- From nobody Fri Nov 26 20:37:33 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2EB3E18BC882 for ; Fri, 26 Nov 2021 20:37:42 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from cameronkatri.com (cameronkatri.com [206.189.178.249]) (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 4J164j2H4Mz3kMd for ; Fri, 26 Nov 2021 20:37:41 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from [10.16.0.16] (unknown [89.46.62.26]) by cameronkatri.com (Postfix) with ESMTPSA id 951BB417E0 for ; Fri, 26 Nov 2021 15:37:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cameronkatri.com; s=20201109; t=1637959054; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=phbzk1P+JAtaN7J3phh8SDiLs+NDDRgpMsbH0iyysh8=; b=ZeStcpkoAjuSEFMcPb39+ZRzXS3DA13lTBZ1BeakFhZxHDlopxOKNITuEy6DI4B2ji55V1 6pfIX05/4A6VAdiLMu8wtNolSQeMZDv+7sNB1IMFoxP5YeILzeEK/5r+U5eRMET6EYEcyV yZtUcjIjZSnfMPsHnthJy9Hh44ljgsM= Message-ID: <497aa572-aaf8-c855-8095-01074419a78e@cameronkatri.com> Date: Fri, 26 Nov 2021 15:37:33 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Retiring WITHOUT_CXX Content-Language: en-US To: freebsd-hackers@freebsd.org References: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J164j2H4Mz3kMd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cameronkatri.com header.s=20201109 header.b=ZeStcpko; dmarc=pass (policy=reject) header.from=cameronkatri.com; spf=pass (mx1.freebsd.org: domain of me@cameronkatri.com designates 206.189.178.249 as permitted sender) smtp.mailfrom=me@cameronkatri.com X-Spamd-Result: default: False [0.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cameronkatri.com:s=20201109]; FREEFALL_USER(0.00)[me]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; DKIM_TRACE(0.00)[cameronkatri.com:+]; DMARC_POLICY_ALLOW(-0.50)[cameronkatri.com,reject]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:206.189.176.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: me@cameronkatri.com From: Cameron Katri via freebsd-hackers X-Original-From: Cameron Katri X-ThisMailContainsUnwantedMimeParts: N On 11/26/21 14:06, Bjoern A. Zeeb wrote: > - users  (that's a wow but okay); can't remember when I last typed that users is very simple, it wouldn't take long to reimplement in C - Cameron katri ----- Cameron Katri Email: me@cameronkatri.com PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C From nobody Fri Nov 26 21:47:38 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CEFA518C09E1 for ; Fri, 26 Nov 2021 21:47:42 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 4J17dV1WSWz4cNc for ; Fri, 26 Nov 2021 21:47:41 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-qv1-xf2b.google.com with SMTP id i13so8215791qvm.1 for ; Fri, 26 Nov 2021 13:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OESfpJi9gVYSZSnaWLUd7R8ok5a69arSJCD0hv7uXtg=; b=I/NzURUQuB+jPaZFV3/j06WaQFr4dwvjLZJ+Ip/6llNWQS74cVS7LHD8QV67WfMshi J3KNOGoBtE9x12IscLRn504QWalvbO//YM9fCLC44f2M75OiRhlh00C+RsiGL0yUgLJa BmP1fHue8n0yF04zF3p/jsVZuprqrC4/1KNe1f9zZkYv4aLDq8T11JETkUORSnYCgbxS 3T7DIGEMOdpkei5rWz8apxqfhR2uzJfKJFI8p+gbc1lkJXoHLeeQkgOVr+AxxmKfFOo2 Xe1ZDvhQsigznrAvd9Z8/nrLIP8GxcYxeQoPNuuErs0P4DIIj+au2Qz4aXLgtot0CBHf j5gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OESfpJi9gVYSZSnaWLUd7R8ok5a69arSJCD0hv7uXtg=; b=0qOQtgpHOFpIFiK7hKXcTM/Ms4yXQZFNml5qwxlWXykvfcKNYz+ofHFRG5Do+yqA5N TCTqEPatrxgEoCcG9Jt4yTVztlnFJEKBxENIBkuZ1IeSZDkb3QhO8EjlEmXPumX0r0ZG PciJoAJnKc6w3b6e7cdZE3I2r+mgXHh8A3EQmEVZ1ciItzm7QmC49IKpG+iYAarcIbY1 sAD+1ksWaVVCiLiC2XetNbnlKWcU8MGyB7RejOjW69L+bd4sIrtzth7JPRG6E1AYvhmF lht98cfmyPOOEUcBdqX0FQPkSa1ON10PoKszKtQpZ31HigZHnq9uY2aQsfY2FpXMOsWd LrzQ== X-Gm-Message-State: AOAM531N+DXLn456gpTwrVE+SK/+/1B67tYuyZGYUZzKyakX9TgRAKlh wVyyNHH+wwl4F9M1KUZ0L7LxM3o/lyV3SDgi X-Google-Smtp-Source: ABdhPJwC+81UT1J5f5qfhcpkspqakdZymWSkuECwvC2c4AbEbk4IylNhsKgWWPHs2/cy/k5QEWvc5A== X-Received: by 2002:ad4:5b82:: with SMTP id 2mr15942395qvp.90.1637963261202; Fri, 26 Nov 2021 13:47:41 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id x190sm3575590qkb.115.2021.11.26.13.47.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Nov 2021 13:47:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: Retiring WITHOUT_CXX From: Bakul Shah In-Reply-To: Date: Fri, 26 Nov 2021 13:47:38 -0800 Cc: "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers Content-Transfer-Encoding: 7bit Message-Id: <0C4C3821-52EE-43D5-94D0-B595F1269CD2@iitbombay.org> References: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> To: Warner Losh X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Rspamd-Queue-Id: 4J17dV1WSWz4cNc 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 Nov 26, 2021, at 9:45 AM, Warner Losh wrote: > > On Fri, Nov 26, 2021 at 10:11 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > >> >> You can disagree with my assertion, but I shall continue to assert >> that it *seems* as if rather than adding B O S to the CI such that >> it is not only regularly tested, but continuously tested is the >> correct path forward here. > > > Testing all possible options takes on the order days. Testing all > possible combinations takes much longer. It's not practical to test > them all on every commit. It's computationally difficult. Would it make sense to define a number of option sets and test only those? This would reduce the test load from testing 2^N option sets to a much smaller number. I suspect *useful* combinations are far fewer than 2^N. > We do have to stop and consider the bigger picture: is it an option > that's useful enough to have it be one of the subset of things we test > on a regular basis, and enforce some sort of pre-commit requirements > for. Or is it an option we're content to test after the fact and have some > sane plan for remediation? Or is it an option that we've slavishly > carried forward from a time where it made a lot of sense to a time where > the situation on the ground is such that it no longer makes sense? It appears the following in /usr/src have .cc files: [ls **/*.cc|sed 's,/[^/]*$,,'|uniq] cddl/usr.sbin/zfsd cddl/usr.sbin/zfsd/tests cddl/usr.sbin/zfsd contrib/bsnmp/tests contrib/capsicum-test contrib/googletest/googlemock/src contrib/googletest/googlemock/test contrib/googletest/googletest/codegear contrib/googletest/googletest/samples contrib/googletest/googletest/src contrib/googletest/googletest/test contrib/googletest/googletest/xcode/Samples/FrameworkSample contrib/libcbor/oss-fuzz contrib/libcxxrt contrib/libucl/examples contrib/netbsd-tests/lib/libc/sync crypto/openssh/regress/misc/fuzz-harness lib/csu/tests lib/libc/tests/stdlib lib/libdevdctl lib/libdevdctl/tests lib/libnv/tests lib/libpmc sbin/devd tests/sys/fs/fusefs tools/tools/mcgrab tools/tools/mctest usr.bin/dtc usr.bin/users usr.sbin/pmc Looks like a lot of the .cc files are required for testing (that most users won't care about). I was surprised to see .cc files in lib/libc/tests/stdlib! There are only two .cc files here. lib/libpmc has just one. googletest's README.md says: Welcome to **Google Test**, Google's C++ test framework! If it will help I can rewrite devd in C, and may be more. I have a very small program that converts .dtb files to .dts. Adding a parser for .dts files wouldn't be hard (with usr.bin/dtc as a reference). Not trivial but doable. > That's the discussion we're having here. Is it important enough to require > everybody to pay attention to it or not... > > Warner From nobody Sat Nov 27 01:29:07 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E353618BA4A4 for ; Sat, 27 Nov 2021 01:29:24 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1DYJ59Wsz4mk7 for ; Sat, 27 Nov 2021 01:29:24 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 1AR1T7bG044252; Fri, 26 Nov 2021 17:29:14 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Fri, 26 Nov 2021 17:29:07 -0800 From: Chris To: Emmanuel Vadot Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> User-Agent: UDNSMS/17.0 Message-ID: <71a345838d7ef72e9100e31c42896953@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_1203912b2604ee9460be11341483da38" X-Rspamd-Queue-Id: 4J1DYJ59Wsz4mk7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_1203912b2604ee9460be11341483da38 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2021-11-26 07:04, Emmanuel Vadot wrote: > Hello all, > > I'm currently re-implementing the framebuffer code in linuxkpi for > drm-kmod and this made me look at sc(4), vt(4) and friends. > > So I looked at what sc could do and vt couldn't and vice-versa. > > What sc(4) can't do : > > - Work with EFI firmware. > - Support UTF-8 > - Maybe other things but everything here is EFI-based so let me know. > > What vt(4) can't do : > > - You can't get the modes or adapter info with vidcontrol. > vidcontrol -i mode is really made for anything vesa based as it > iterates on all the modes and display them if present. > In the modern world (EFI), we don't have that, EFI GOP doesn't > support changing resolution after ExitBootService was called so there > is only one "mode". I could possibly hack some patch so vidcontrol -i > mode/adapter would work and display the current framebuffer info if > people wants (but I honestly doubt that vidcontrol is useful at all in > an EFI world). > - "Blanking" screen doesn't do what you think it does. For some reason > in vt(4) we just write black colors on the screen and ignore the blank > mode passed in the ioctl. > Now again, blanking/dpms/blah isn't possible with efi_fb but it make > sense to fix vt(4) and drm-kmod so it calls the drm module blanking > function, I'll work on that next week. > - There is no screensaver, again see notes above for dpms but do > people still use sc(4) just for the screensaver ?? > - Maybe other things, please let me know. > > For libvgl it probably made sense back in the 90s but does it now ?? > > Based on my small list I don't see any good reason to keep sc(4) but > maybe I've missed something bigger so please let me know. > > P.S.: I'm really not interested by people saying stuff like > "I've always used sc(4), it works for me don't touch it" > without some technical argument. I always use sc(4). So please don't remove it. Technical reason: On nVidia hardware (a|g)pu's I require the following in loader.conf(5) kern.vty=sc if not, the EOL is always at the end of the screen width. Not at the end of the line of text. There are other problems with the pasted text as well. That's my only argument against it's removal. Thanks for bringing it up. :-) --Chris > > Cheers, --=_1203912b2604ee9460be11341483da38 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_1203912b2604ee9460be11341483da38-- From nobody Sat Nov 27 07:40:57 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A3F0F18B7E56 for ; Sat, 27 Nov 2021 07:41:08 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-250.nys.biz.rr.com [24.97.5.250]) (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 "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1NpC74q6z3nYG for ; Sat, 27 Nov 2021 07:41:07 +0000 (UTC) (envelope-from david@crossfamilyweb.com) X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from winry.priv.dcrosstech.com (d130.office.dcrosstech.com [10.1.12.130]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 1AR7evCE018586 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 27 Nov 2021 07:40:58 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d130.office.dcrosstech.com [10.1.12.130] claimed to be winry.priv.dcrosstech.com To: freebsd-hackers@freebsd.org From: "David E. Cross" Subject: bhyve -D not cleaning up after itself Message-ID: Date: Sat, 27 Nov 2021 02:40:57 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A8B7A2064EAB048E5235D381" Content-Language: en-US X-Rspamd-Queue-Id: 4J1NpC74q6z3nYG X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@crossfamilyweb.com designates 24.97.5.250 as permitted sender) smtp.mailfrom=david@crossfamilyweb.com X-Spamd-Result: default: False [1.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_SPAM_LONG(1.00)[1.000]; DMARC_NA(0.00)[crossfamilyweb.com]; NEURAL_SPAM_SHORT(0.22)[0.220]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --------------A8B7A2064EAB048E5235D381 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have noticed for awhile that bhyve -D doesn't seem to actually do what is claimed  (to destroy a VM on guest initiated power-off).  This evening I decided to ktrace it to see if I was just not getting something about how this was supposed to work, and found:  68613 vcpu 0   CALL __sysctlbyname(0x1ebcdb20a133,0xe,0,0,0x1ebce4ba60f0,0x9)  68613 vcpu 0   SCTL "hw.vmm.destroy"  68613 vcpu 0   RET   __sysctlbyname -1 errno 1 Operation not permitted  68613 vcpu 0   CALL  exit(0x1) Reading quickly the kernel code for vm_destroy(), I find 2 candidates: static int vmm_priv_check(struct ucred *ucred) {         if (jailed(ucred) &&             !(ucred->cr_prison->pr_allow & pr_allow_flag))                 return (EPERM);         return (0); } This doesn't seem to be it, my process is not jailed. That leads to the only other (I think) call in sysctl_vmm_destroy that could return EPERM: error = sysctl_handle_string(oidp, buf, buflen, req); But I am just not seeing it.  Also this EXACT same call works from the context of bhyvectl --vm=FOO --destroy, run from the same shell as the bhyve process that just terminated.  Is the 'ctx' somehow incorrect in bhyve?  I is used earlier in that function, so I am assuming it is right? Any help appreciated! --------------A8B7A2064EAB048E5235D381-- From nobody Sat Nov 27 08:18:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 29DD918AC15C for ; Sat, 27 Nov 2021 08:18:47 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 4J1Pdf31M6z4VJ0 for ; Sat, 27 Nov 2021 08:18:46 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42f.google.com with SMTP id d9so2795439wrw.4 for ; Sat, 27 Nov 2021 00:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=SrHumiaJKZRQoLRBQIyep0+KCxCNub9A7dy5ic7OCMQ=; b=pMZlhdDP10cW2NhCLRhHExyFuLZXcwtT+xEjvdOjYDOOgMlRKSXdS0GvOr0dRTqXk2 9NBZsH/xcEFDwrHCm8KR11/8bHjIOnqsr1rdG+x+dPvBTriInG+SphWo7LCJhLNfvJZL VkzFmni6uYiwRJ5xUUPjElvWd/dDBVMb0Q7GPB5pFC+ESZqnsHNSRL/7kSTDYGMAwVJf gIevxrxuKskGdAlb6cFPUlp4zd56hb3RAylhsmjjK+gv7YPbupqNBYWRlxpZYEPg1N+M X+Dn0hgn6cf/zhjErAaL6M3XtiL4anpUlQor1JAYbnaW74UMBl2MxK3jd7Lj+HJeU3Mb hNbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=SrHumiaJKZRQoLRBQIyep0+KCxCNub9A7dy5ic7OCMQ=; b=ZfBEZpicYRHWkjb/0QGrXfv1J3c3WnmaCRA89qoD88fZd59infdOzYsEUrzV4DXgcR w7Ysjzo+lLUjoLOjlflFHojIgM0AVb114TlvOg7M64PHq/yHvFj55B7tPCcuCgPHhnCb hxKksB6pYY09j9bm+EL80IxHctWQrntouvNH/9jUdOs/8SVqkgJHQH2m2sxlY+JY+QkK kwNluATDELskthRrz8HmfFeI8I9XK4GzDW3WpufhgS52A0rrEg69gwajSHTMi4k0sHA7 n1fD3sDjt5N/sCRS2c4GZSioIGC0DdUCHg4Czp9yEQmaeVoBhu7+DedE/geLnHdsS9Xm o+Vw== X-Gm-Message-State: AOAM532MPGPujC80sFhowbctEIyZxv5RuzCUh6uS0g+v+7/lNO6gsk13 eOEWli2GADqSI9VDTCxaAsNIa0EWR8N0ug== X-Google-Smtp-Source: ABdhPJxdxgQj3ZDsjbiEGeyDi/N/IZdpkTsF/MSRYKYGZg2JdjxqjDX83X6qpLHfceBe15a890lalQ== X-Received: by 2002:a5d:404d:: with SMTP id w13mr18505198wrp.293.1638001124095; Sat, 27 Nov 2021 00:18:44 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id f7sm16254097wmg.6.2021.11.27.00.18.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Nov 2021 00:18:43 -0800 (PST) Message-ID: Date: Sat, 27 Nov 2021 08:18:42 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Handbook versions (was: Call for Foundation-supported Project Ideas) Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> X-Priority: 5 (Lowest) From: Graham Perrin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J1Pdf31M6z4VJ0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pMZlhdDP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42f as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-0.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; 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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.98)[0.981]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42f:from]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 24/11/2021 01:25, Mehmet Erol Sanliturk wrote: > … > > (2) > > Separate Handbook sliding versions and make it Handbook per version , and > make available for each version just like > manual pages specific to versions . > > … HTH From nobody Sat Nov 27 08:30:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AC55A18B239B for ; Sat, 27 Nov 2021 08:30:45 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 4J1PvS55wrz4Z7m for ; Sat, 27 Nov 2021 08:30:44 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42f.google.com with SMTP id a9so23742455wrr.8 for ; Sat, 27 Nov 2021 00:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:cc:in-reply-to:content-transfer-encoding; bh=ZcpuPE913lSN+QK7btnzbu8y6Toswff/nfFpXewCsKY=; b=G50OE51xW1p3qljLjHWHxckhloJLgUXvjZ4cDXoG+YoW4Lse27BeFxExf/kTRN3rCE fmprs0v456sIg1fdLGYraHMI5LIKC6JPvmXg34bzYdZhZ0EnfgROfhr5RwuUSf4D0WWj VqpM7OyzL7bM3io/FtJoQvbWaJlDmzhaS747qfXn8iQil8NDwfzlNy+dwm+Dv7+bLQbN 7kPzKS2NQ+hv20sBurPZUH6ca6/gmK6Z14RIuyy00eXytSVJfvgSpc/CA/AO4AUY+sVY wBxs3r2I2oz80zJL/VRbxlSM2k0nTYdRHNUNbHDaFs988jqafDpNjjEZRD5CvTilW/RV F7Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:cc:in-reply-to :content-transfer-encoding; bh=ZcpuPE913lSN+QK7btnzbu8y6Toswff/nfFpXewCsKY=; b=cDgAmQ+/K1ayUl7P6WX/h24mKEbCDEeTWEOEs4sIb/Th4w5vKK5Ea+g/PuwdMXUwat Jmm++DQW2cHweCPl14XxbDljJ65fK5qLmoC+syIp9DwJqx6lVDpPhOTQL/VqsrfIni7K bcRLk766ItDBaDS768DGr7KU9ehue0LmKFzFhCPHlw9/ieinjqh4tMvVlWnLuE0lRy73 Kr++EJe4xeQgut6vxpgFd48XWBK7+NS8NQNQ0QA0FrJxVVGrOt4FZZUnoSLVMn4uU+wT K/kvmjMekP6ya8r3xB+FcB3XqNwqUx+50jCa/sYWxadO++EeZ6CEbDyE6FzXmMnrfMkd bO9w== X-Gm-Message-State: AOAM531I5RLKbbX027uzr9qxq07JFMsgDKNrY2TnnZinJ9m9MEAOKQ+h tJbbh92gGO8Pe9STooRQJxs= X-Google-Smtp-Source: ABdhPJzBYhlvPWSCOR/mUWu0d9SbW5FSixpqKcN+kYuaUCgGMuGg3EzOQXaGR8Jd9R6IeONxhKRNMQ== X-Received: by 2002:a5d:618f:: with SMTP id j15mr18827162wru.506.1638001843732; Sat, 27 Nov 2021 00:30:43 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id m34sm17485822wms.25.2021.11.27.00.30.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Nov 2021 00:30:43 -0800 (PST) Message-ID: <91e62d1a-1306-51a6-3f90-8bf35315d777@gmail.com> Date: Sat, 27 Nov 2021 08:30:42 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: poudriere and poudriere-devel discussions (was: Call for Foundation-supported Project Ideas) Content-Language: en-GB To: =?UTF-8?Q?Fernando_Apestegu=c3=ada?= References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> <20211124213150.6lsyaqgwbkgfcgzi@mutt-hbsd> <20211125000227.dssjkh43inmyvcdy@nerd-thinkpad.local> From: Graham Perrin X-Priority: 5 (Lowest) Cc: freebsd-hackers@freebsd.org In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J1PvS55wrz4Z7m X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=G50OE51x; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42f as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42f:from]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 25/11/2021 06:37, Fernando Apesteguía wrote: > … How often does poudriere get updated with changes from > poudriere-devel? Or if poudriere-devel is stable enough I could give > it a try anyway. … Stability of poudriere-devel From nobody Sat Nov 27 08:34:38 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2707518B35CA for ; Sat, 27 Nov 2021 08:34:42 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 4J1Q01183tz4bX3; Sat, 27 Nov 2021 08:34:41 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x32e.google.com with SMTP id 137so9954438wma.1; Sat, 27 Nov 2021 00:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:cc:in-reply-to:content-transfer-encoding; bh=zOl5MUTWHVjTmkpRqu1bDB6FVH0rOC0QqUr/faZsq2k=; b=fzGvIlZkZCT5kR7ly3oe2MF1TpQpPJrdXi94rjdk0z8XC+c6i9eELzB8uZNp1oA51K qjfYarETkMpF+KUrIktAPJ4k/z9aJnjWA7lvGxuupNV6v16Ihh1DnQp7uXyCP0Fb1yZ7 mz/0aK3mUTuCHeA0zkeihN956oyqWOSM71yXhx0gbLlBXs5LJW24mOpY69etxo2ByVuh WPHdEeqV7W8DHkYOb406xWZYmn5D0IRlCuQ6DZELU8cFCsGfOenKVjpzj7hE5nOXih0X BqdbQQ6QEpIhvlrfefzUoKgRjDCn1hG9CSAmjWvSR765/nKeGjdyJakNm6FVaVTkTWr+ 0MrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:cc:in-reply-to :content-transfer-encoding; bh=zOl5MUTWHVjTmkpRqu1bDB6FVH0rOC0QqUr/faZsq2k=; b=IAbJcXMt/5bdONwAVxkMH2YAg8VBvAZKNVFTqhKcd2G0sHyqx0YAnb1vO3hrX1myjI /tKgejtWuNVi9W86cH7W6LTxeR61OQFsAcvbG7kkhn6ABCgl+HnZTrrWoZWxNfwzCBIk CXmphAkWQNrkENvURSW1VE/yKbc8no0HvnUd03g8L13B1pnLENcwH/baiRYFV+WGxdNE XgGzxVvACkP2RZS7P7LA+jEW+zfexPt8snxYeSu7FGEstQy4xx3xIaRJs02xC0awAEic VMJuWy48MbQU/1Oj1fFsHXoNKles2wINW1cZgKIYnNv6Dk7SRIl4f1cdt8qlex19SsLt hi1A== X-Gm-Message-State: AOAM532nCURrcUcl6tk7RYuuf+vJ5By7I6RXXzMrml1ZpqTTKZHjrJ/8 MAxJ7yyUeRyqRIBjQZTSVmKh6ygRUvjlDQ== X-Google-Smtp-Source: ABdhPJwHyZ6X16RB5A2lcDoADzGcAy5Eag7YPFx/0gowcZAXe+LUrU/TqK0r4yAMctB4LmB7uTL7fA== X-Received: by 2002:a05:600c:1c8d:: with SMTP id k13mr21295953wms.177.1638002079952; Sat, 27 Nov 2021 00:34:39 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id y6sm7893198wrh.18.2021.11.27.00.34.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Nov 2021 00:34:39 -0800 (PST) Message-ID: <6e7d550f-78bf-29cc-7283-93d5c8263519@gmail.com> Date: Sat, 27 Nov 2021 08:34:38 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Call for Foundation-supported Project Ideas: lsof Content-Language: en-GB To: Larry Rosenman References: <861r36xzpe.fsf@phe.ftfl.ca> <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> <246adde5-6a7a-4102-abb4-16c766ea78d1@freebsd.org> <39d7dec472c4d937404aabba91a5ead6@FreeBSD.org> From: Graham Perrin Cc: freebsd-hackers@freebsd.org In-Reply-To: <39d7dec472c4d937404aabba91a5ead6@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J1Q01183tz4bX3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fzGvIlZk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-1.91 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.91)[-0.910]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from]; 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]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 25/11/2021 00:01, Larry Rosenman wrote: > 𠉧… Back to the topic: > Can I PLEASE get some help on sysutils/lsof (which has been broken for > all of 13 and 14's lifetime)? > If I can't, I'm going to rmport it. … Is that, more than anything, for compatibility with (OpenZFS) ZFS? From eugen@grosbein.net Sat Nov 27 11:41:55 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DECB518C602B for ; Sat, 27 Nov 2021 11:42:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1V8T4jHhz4ZyS; Sat, 27 Nov 2021 11:42:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1ARBg7OD055977 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Nov 2021 11:42:08 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: emaste@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1ARBg7rO077684 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 27 Nov 2021 18:42:07 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Stefan Blachmann , Ed Maste References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> Cc: Emmanuel Vadot , FreeBSD Hackers From: Eugene Grosbein Message-ID: <7981e765-38d7-9a3f-a222-c2e36ccd7b64@grosbein.net> Date: Sat, 27 Nov 2021 18:41:55 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J1V8T4jHhz4ZyS 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 27.11.2021 2:06, Stefan Blachmann wrote: > When time comes and I have to buy computers that do no longer support > CSM, I'll look into the sc source to add a VGA BIOS interrupt call to > change from UEFI graphics to text mode at initialization time. > This should be sufficient to support sc on UEFI machines. > Actually I do not understand why this has not yet been done. > Do you think such a patch to make sc work on UEFI systems would be > accepted into FreeBSD? I've been told there are UEFI variants that do not support old text mode at all. From nobody Sat Nov 27 14:34:54 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 026EE18A8F33 for ; Sat, 27 Nov 2021 14:35:33 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1Z0M5rxxz4Qxx for ; Sat, 27 Nov 2021 14:35:31 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: by mail-ed1-x536.google.com with SMTP id t5so51340781edd.0 for ; Sat, 27 Nov 2021 06:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=WEVCa0Qsq4AX9gnGWO8bOytk92dg+VShOAx5sTdedIE=; b=cKgClDnGq+cVy3wgZHN+NtvyWbcgpXNB3Rbsj4SWByiUURgC5dcy7Yp4oMGRabzNOu 5WgI0xLYmvd6jqmJtKg6TaHjG/01HhLryUwjOreakYTFajaSAzDEDqFrG0jNBUDvv2MT KHmEBDzlQ6BqeJ7mGbnEhO/pH9NvH8Jq8diadhAlm+uEJA+syNdd7krd+A2PcftojWS2 aNT65q1r/L7IgYLh0FscAMOmUPmKWljspgAKJigQgS+BBz1P13R1dtEEdYQuWya8HvQ4 lc+hr/RQviJf0JcT09JeTL8AMPUCdxSwcsUi1VKBGPqD7p6tBBDmwh1reXjPdrbQRqzX 181g== 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=WEVCa0Qsq4AX9gnGWO8bOytk92dg+VShOAx5sTdedIE=; b=IX7oNwpqeIse/BjYMXjFVCC5DAyttfXYOBPjccjSnlV1nAPPmZRg6K5JoTdUalfFgp 7GRRAXL2CsiQ18x/scNET1ZTFd3hMOWdI706w32UXF3ZgsNTtHvZQhJ1KdumpF6fvK7y XtV/9C2nRzbV7nehDWgkUhofaxBFeXnkORB8wjWyC2mkChXJQOZFO04XzBP+EenONWHR r5uxtx0sjRdHOAvIy26KKv4FF/oWTmmY5K8D3apYlW/tM/aBzxCbKB7emyy+43DnaVsB qLG+lX7gE4edtJS7iIDE/eBh+3S0jpN4vkHBTen3dcbWLAOqEJl/fq9xA2K94+J9XmDC zInw== X-Gm-Message-State: AOAM530uOUxytW2FvqO2dYPbK+dMNzUJlpChDkdSYNc1KGUZiBCwEgfV laKzpf5UzP33/6mZ2cuIZA1ihw8GqUyPIiB6MJu1A2fCXq4= X-Google-Smtp-Source: ABdhPJxiWGB9SoufLT+4nKBhuBrgJ5QlGmmAlvmM9KY7FYeFXYRQmCHmCuUClvr6wbrOF2Qs8tOlNGT4E3Xl9RhA6DE= X-Received: by 2002:a17:906:b090:: with SMTP id x16mr45756363ejy.438.1638023730819; Sat, 27 Nov 2021 06:35:30 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Stanislaw Adaszewski Date: Sat, 27 Nov 2021 15:34:54 +0100 Message-ID: Subject: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J1Z0M5rxxz4Qxx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cKgClDnG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sadaszewski@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=sadaszewski@gmail.com X-Spamd-Result: default: False [0.08 / 15.00]; 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)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; NEURAL_SPAM_LONG(0.98)[0.983]; 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]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Dear All, Could you please guide me so that we can together integrate the following piece of work into the FreeBSD base system? Thank you for your time and consideration. I have created the following bundle of work [1]. The referenced patch implements on top of releng/13.0, the support for TPM2 in the EFI bootloader and in the kernel in order to allow for storage and retrievel of a GELI passphrase in a TPM2 module, secured with a PCR policy. The way the bootloader behavior is modified is the following: 1) before calling efipart_inithandles() an attempt to retrieve the passphrase from a TPM2 module might be performed - how this is achieved is described later on. 2) if a passphrase is indeed retrieved, then after determining currdev, the currdev is checked for the presence of a /.passphrase_marker file which must contain the same passphrase as retrieved from the TPM. This is supposed to ensure that we do not end up booting an environment not on the device we just unlocked with the passphrase. 3a) If all is go, the autoboot_delay is set to -1 in order to prevent any interaction and continue the boot process of the "safe" environment, a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set to the passphrase from TPM in order for kernel use later, as well as a kern.geom.eli.passphrase.from_tpm2.was_retrieved'='1' variable. 3b) If the passphrase marker does not match, the bootloader cleans up GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits. The way the kernel behavior is modified is the following: 1) In init_main.c, after vfs_mountroot() a check is added 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not set to 1, then we do nothing and continue the boot process 2b) If the was_retrieved variable is set to '1' then we check for the same passphrase marker as the bootloader, its content compared against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable. 3a) If all is go, the passphrase variable is unset and the boot process continues, 3c) If the passphrase marker does not match, we panic. The configuration of the bootloader for this procedure looks the following: 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex to contain the TPM2 NV Index we store our passphrase in, e.g. 0x1000001 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr to contain the PCR policy used to secure the passphrase, e.g. sha256:0,2,4,7 3a) If both are set, the bootloader will attempt to retrieve the passphrase and behave in the modified way described above 3b) Otherwise, it behaves as the vanilla version and will ask for GELI passphrases if necessary The configuration of the TPM and the passphrase marker looks the following: 1) echo -n "passphrase" >/.passphrase_marker 2) chmod 600 /.passphrase_marker 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L policy.digest -A "policyread|policywrite" 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,2,4,7 [1] https://github.com/sadaszewski/freebsd-src/compare/releng/13.0...tpm-support-in-stand Kind regards, -- Stanislaw From nobody Sat Nov 27 15:51:40 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ECC8718ABA50 for ; Sat, 27 Nov 2021 15:51:48 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1bhN4Bt1z4mmj; Sat, 27 Nov 2021 15:51:48 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1638028301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Lry63RqYWzxqZ8oqZldq32j4XBKDVy1hKP5tYl74ii0=; b=lXyyIo1GPIMk86CyaGrBWhCPROXr8yQSKCTLgMQIaoey9h7tdvIXmWeZ11JO06xHOwwZtw xPxhq7g7LJfvmpHuKVDzc/myMpsxkGwEYVQrEprtdCf+GJUtQVeWQIEdYnw39Ad8k6pagf 4PPw2TwfgZ1YKDK3Yl3035RWu9ohDhA= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 86c70f32 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 27 Nov 2021 15:51:41 +0000 (UTC) Date: Sat, 27 Nov 2021 16:51:40 +0100 From: Emmanuel Vadot To: Stefan Blachmann Cc: Ed Maste , FreeBSD Hackers Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20211127165140.7dd38b9448f8653e557829e4@bidouilliste.com> In-Reply-To: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J1bhN4Bt1z4mmj 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, 26 Nov 2021 20:06:13 +0100 Stefan Blachmann wrote: > I encountered some other bugs in vt while I used it. > > Aside of the computers I am using for testing of my installer, I use > vt only in the time from installation of computers to when I get time > to configure/build a new kernel to remove vesa (and vt because it > pulls in vesa,ko) from the kernel to make suspend/resume work. So I > feel usually in some hurry when I want to get a system up and > running.. > > And then I am not in the mood to bother spending time making vt bug reports. > Maybe a reason that many of these bugs are not reported is that I love > to use mouse mark/paste in the console, and most of the bugs are > related to this. No idea how common it is to use mice in console mode; > if it is not common this might be why these bugs are apparently > under-reported. If you don't report the bugs don't expect them to be fixed ... > Almost all my computers still have CSM support, so I use that, as I do > not use Microsoft OSes. > > When time comes and I have to buy computers that do no longer support > CSM, I'll look into the sc source to add a VGA BIOS interrupt call to > change from UEFI graphics to text mode at initialization time. > This should be sufficient to support sc on UEFI machines. > Actually I do not understand why this has not yet been done. Because it's not possible ? > Do you think such a patch to make sc work on UEFI systems would be > accepted into FreeBSD? > > > On 11/26/21, Ed Maste wrote: > > On Fri, 26 Nov 2021 at 10:45, Stefan Blachmann > > wrote: > >> > >> - vt is so horridly buggy that it is no fun to use it at all if one is > >> accustomed to well-working, bugfree sc(4). Just one example: > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211922 > > > > This issue is waiting on feedback since 2021-09-25. There is one issue > > that's still reproducible when I last tested, but "horridly buggy" is > > quite a stretch. > > > -- Emmanuel Vadot From nobody Sat Nov 27 15:52:21 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7CE2D18ABF5A for ; Sat, 27 Nov 2021 15:52:23 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1bj30WXMz4n6K; Sat, 27 Nov 2021 15:52:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1638028341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V3vRLJL0BoopACrPiK9UMCmXtMvSvKCI7JB2WzNOhV8=; b=DSafMeLAcrRLmPdc78BXuvkf341hpGeEH4sp7ubu53KR7ZA/ukgW/8T7QhCyiCFYj3l3it C4e/aNLMe2yJRVqS+RfaXJUDExvsqye2c1Fs8+aQWIVHF0gnUHzWb/Zax8Qu1xdq08Gdk9 m+hqK6GUQ757bNh6pTZ+lHFVv36WOHw= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 6a354d72 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 27 Nov 2021 15:52:21 +0000 (UTC) Date: Sat, 27 Nov 2021 16:52:21 +0100 From: Emmanuel Vadot To: Eugene Grosbein Cc: Stefan Blachmann , Ed Maste , FreeBSD Hackers Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20211127165221.3c53e298df731008c747db1b@bidouilliste.com> In-Reply-To: <7981e765-38d7-9a3f-a222-c2e36ccd7b64@grosbein.net> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <7981e765-38d7-9a3f-a222-c2e36ccd7b64@grosbein.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J1bj30WXMz4n6K 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 Sat, 27 Nov 2021 18:41:55 +0700 Eugene Grosbein wrote: > 27.11.2021 2:06, Stefan Blachmann wrote: > > > When time comes and I have to buy computers that do no longer support > > CSM, I'll look into the sc source to add a VGA BIOS interrupt call to > > change from UEFI graphics to text mode at initialization time. > > This should be sufficient to support sc on UEFI machines. > > Actually I do not understand why this has not yet been done. > > Do you think such a patch to make sc work on UEFI systems would be > > accepted into FreeBSD? > > I've been told there are UEFI variants that do not support old text mode at all. There is no text mode in UEFI, there is UGA for the old EFI 1.0 and GOP for 2.0. -- Emmanuel Vadot From nobody Sat Nov 27 17:00:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CD98F18A3E21 for ; Sat, 27 Nov 2021 17:00:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 4J1dCc53QMz3P1G for ; Sat, 27 Nov 2021 17:00:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92d.google.com with SMTP id n6so24933793uak.1 for ; Sat, 27 Nov 2021 09:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fBy62RXg11dYoXtE3y7Te+VnQvTXxniJ19BQEyr5QL0=; b=YX98I0rmZ9BysThwugg4F+MkmGf8p5xpezGnX8I7UaDwdCUrLMXp9KRy5u+jlBj0sD PMrfXDiGz3Wzbs3j/Ot1MNmJy5GSrao5pbTns4H12gjCfcgnZe3OJsRpLGnG0n0fNwDI hsXcNyBqjvJZqQS+ToA2NEhyJL9gzHONoZJxJSbon/mkCDem8zfSZWj3e2ml0gUSYtfV 1RhWFkXz2L68UAbcdF/EFjiDKkki94aKeOR+rpIH5LSOHFUSAMpnWRyP3pRr7FZn+sSH DXcfbPcrcD5sdyR7kK2cwzEP5FhPPGJyYFranHIZmbYPj5UUSXIz0F37SHNAHxp2FhXj aHnA== 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=fBy62RXg11dYoXtE3y7Te+VnQvTXxniJ19BQEyr5QL0=; b=DJ9Fk2YIJUUUE06uhZ2eYsTs8Yslv2Lz69G95wUtcZ5GUmmvoqrVo7s51HeSWn2A2f NR2DrBPtaTVg/6Mbtmx9AhF8AflWI7cktYH3X/XpHG26EqZ+om2jfaX/I5iYYZuhkw1Z RtxQUrxekRxIidIKi0uxPVlBJEYZ2lZsMORGXNapYHv44EL0WEMLcYuJdyb7RH4L8OsF EtM7WSSbAl9B1iIeLaRd8jZvpK41dTDW8aBmwDqeSnmTC33qZtrERcDKww7vr1s3O2y3 4++GogCckHWZDZenTvRoTa6pITRbozh4uUIabb3xzffoJBoCRLfaR7nPA3LN5I/t3xFk 2/jA== X-Gm-Message-State: AOAM531pig66eFfONbQqccyftGHv8/3TxMse+uxSLaUzZB15CNpkCayM hsdQ3F4VHPCp5AJWcENw2vYAOyMjuWX1nFzYr6bG2QIFoAQKtQ== X-Google-Smtp-Source: ABdhPJx4M1BnuRJ1QbWklg6cj+LeHrlkAFfyqWeJ2gauanYk7/tx6B5K3xhvtFE3DPhvykLUFG5MkSok/FYYMUhRAn8= X-Received: by 2002:a67:f950:: with SMTP id u16mr24662718vsq.68.1638032428019; Sat, 27 Nov 2021 09:00:28 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 27 Nov 2021 10:00:10 -0700 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Stanislaw Adaszewski Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000000c52905d1c825fd" X-Rspamd-Queue-Id: 4J1dCc53QMz3P1G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000000c52905d1c825fd Content-Type: text/plain; charset="UTF-8" On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski wrote: > Dear All, > > Could you please guide me so that we can together integrate > the following piece of work into the FreeBSD base system? > Thank you for your time and consideration. > See below for some advice. I have created the following bundle of work [1]. The referenced > patch implements on top of releng/13.0, the support for TPM2 > in the EFI bootloader and in the kernel in order to allow for > storage and retrievel of a GELI passphrase in a TPM2 module, > secured with a PCR policy. > > The way the bootloader behavior is modified is the following: > > 1) before calling efipart_inithandles() an attempt to retrieve the > passphrase from a TPM2 module might be performed - > how this is achieved is described later on. > 2) if a passphrase is indeed retrieved, then after determining > currdev, the currdev is checked for the presence of a > /.passphrase_marker file which must contain the same passphrase > as retrieved from the TPM. This is supposed to ensure that we > do not end up booting an environment not on the device we just > unlocked with the passphrase. > 3a) If all is go, the autoboot_delay is set to -1 in order to prevent > any interaction and continue the boot process of the "safe" environment, > a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set > to the passphrase from TPM in order for kernel use later, as well as a > kern.geom.eli.passphrase.from_tpm2.was_retrieved'='1' variable. > 3b) If the passphrase marker does not match, the bootloader cleans up > GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits. > I worry about information disclosure having the pass phrase available on the running system with this setup. Can you explain why that design point was selected? Usually there is something signed with a private key that the public key can be used to verify instead of a direct comparison like this to prevent disclosure of key material. I've not looked at the code yet, so it may already do this... The way the kernel behavior is modified is the following: > > 1) In init_main.c, after vfs_mountroot() a check is added > 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not > set to 1, then we do nothing and continue the boot process > 2b) If the was_retrieved variable is set to '1' then we check for the > same passphrase marker as the bootloader, its content compared > against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' > variable. > 3a) If all is go, the passphrase variable is unset and the boot process > continues, > 3c) If the passphrase marker does not match, we panic. > I'm sure that main_init should not know about geom or geli. This is usually done with a handler of some sort so the mountroot code can just call the generic handler. Can your code be restructured such that this is possible? The reason I ask is that ZFS supports encryption too and it would be nice to use that instead of geli. The configuration of the bootloader for this procedure looks the following: > > 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex > to contain the TPM2 NV Index we store our passphrase in, e.g. 0x1000001 > 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr > to contain the PCR policy used to secure the passphrase, e.g. > sha256:0,2,4,7 > 3a) If both are set, the bootloader will attempt to retrieve the passphrase > and behave in the modified way described above > 3b) Otherwise, it behaves as the vanilla version and will ask for GELI > passphrases if necessary > > The configuration of the TPM and the passphrase marker looks the following: > > 1) echo -n "passphrase" >/.passphrase_marker > 2) chmod 600 /.passphrase_marker > 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7 > 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L > policy.digest -A "policyread|policywrite" > 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,2,4,7 > > [1] > https://github.com/sadaszewski/freebsd-src/compare/releng/13.0...tpm-support-in-stand This sounds cool. Any chance you can rebase this to the tip of the main branch? All code goes into FreeBSD that way and 13.0 is about a year old already. Thanks for sharing this. Despite some reservations expressed above, I think this has potential to be quite cool. Warner > Kind regards, --00000000000000c52905d1c825fd-- From nobody Sat Nov 27 18:02:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1BA4F18A90AB for ; Sat, 27 Nov 2021 18:02:24 +0000 (UTC) (envelope-from khng300@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4J1fb4041kz4S9g for ; Sat, 27 Nov 2021 18:02:24 +0000 (UTC) (envelope-from khng300@gmail.com) Received: by mail-lf1-x12d.google.com with SMTP id bu18so32733896lfb.0 for ; Sat, 27 Nov 2021 10:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BAPtZG0quRtHJZ9ZAWfD9Zm6o4S9wua3Jhbph50Cwk0=; b=RbRchqWXdNf7rb4dLhvChiFhK13xDk0OmdXxMDwo36F4wWZ8pSOuSKsyJn06TlrF46 y+26lCrGS0aLU9AFObimCayg9zdORguMeHOuEx+u72Uv/CJvMak67w89t11+dWtkDvPm CdYqDgN6BHMOjZ6tFRS4blG4wIbd4ilrt5Y6cgQUnMx8nkHgW7PXu6Pig98xkg8rMbLY FMPdlj+YHpqPOft/qNO+nXeFedIueMVrJmtMtu+Dsyx6rRg53e8jd5cT3bzpQ/Yu0VEK PZCXMzM4Mwmvy5Ih5j5B7hYN90s7U14mcM2mQ/8G3JFeUfNV2ECP3T0lCGVp1DR+XrW9 lBVg== 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=BAPtZG0quRtHJZ9ZAWfD9Zm6o4S9wua3Jhbph50Cwk0=; b=SwBaGBRFWDew3hefhmC13wz4nWsltS/PeCB5nl/Ja4fmzsNRKLA2Fb5wKAGri/0Ex4 NX62jy19CkVcxUu2I8a1NLvlkuhQZlrcjiriLnIUmxnE6zjMpeXkimxXdLvnKFWViG04 pWT+mnV8Ry8tEt1Ivb8+DHzrw4K0VxqgDbsFoYJApQaiFRwYFcABodv4NtQ1wSzNbxSl Smo/BBY+QUUXNSM5VRVPtmZVYDLBk6jXzXC3nJkEdizCt7xcf0h6YM7sWOU6F0JlwvMZ M/BD6EsCHElCwfuV2Fk3kkPE3P5HGqVN8PGcs2qeD70GsjItAukW6A6/+Iu0ckqnhJ5o 0uSA== X-Gm-Message-State: AOAM5329GmPRSSjN/rMl9MEWgcSfe6+E6RUhtnvVv99bcBtJJwer9pUX lgNAngZCdSMcIyMKPiwBvFnE1J+0GUQK/ftXGqg= X-Google-Smtp-Source: ABdhPJzLbSMRgoQsLn5RscWQhcIDdq/yWzyfcruVVag5xOjPbJu9qfLgVdYtWRLII4uKzfaNdCEC/53g118PBVZAeWc= X-Received: by 2002:a19:770a:: with SMTP id s10mr39073217lfc.234.1638036142653; Sat, 27 Nov 2021 10:02:22 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ka Ho Ng Date: Sat, 27 Nov 2021 13:02:42 -0500 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Warner Losh Cc: Stanislaw Adaszewski , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000069870e05d1c902f7" X-Rspamd-Queue-Id: 4J1fb4041kz4S9g X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000069870e05d1c902f7 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 27, 2021, 12:00 Warner Losh wrote: > On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski > > wrote: > > > Dear All, > > > > Could you please guide me so that we can together integrate > > the following piece of work into the FreeBSD base system? > > Thank you for your time and consideration. > > > > See below for some advice. > > I have created the following bundle of work [1]. The referenced > > patch implements on top of releng/13.0, the support for TPM2 > > in the EFI bootloader and in the kernel in order to allow for > > storage and retrievel of a GELI passphrase in a TPM2 module, > > secured with a PCR policy. > > > > The way the bootloader behavior is modified is the following: > > > > 1) before calling efipart_inithandles() an attempt to retrieve the > > passphrase from a TPM2 module might be performed - > > how this is achieved is described later on. > > 2) if a passphrase is indeed retrieved, then after determining > > currdev, the currdev is checked for the presence of a > > /.passphrase_marker file which must contain the same passphrase > > as retrieved from the TPM. This is supposed to ensure that we > > do not end up booting an environment not on the device we just > > unlocked with the passphrase. > > 3a) If all is go, the autoboot_delay is set to -1 in order to prevent > > any interaction and continue the boot process of the "safe" environment, > > a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set > > to the passphrase from TPM in order for kernel use later, as well as a > > kern.geom.eli.passphrase.from_tpm2.was_retrieved'='1' variable. > > 3b) If the passphrase marker does not match, the bootloader cleans up > > GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits. > > > > I worry about information disclosure having the pass phrase available on > the running system with this setup. Can you explain why that design point > was selected? Usually there is something signed with a private key that the > public key can be used to verify instead of a direct comparison like this > to prevent disclosure of key material. I've not looked at the code yet, so > it may already do this... > > The way the kernel behavior is modified is the following: > > > > 1) In init_main.c, after vfs_mountroot() a check is added > > 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not > > set to 1, then we do nothing and continue the boot process > > 2b) If the was_retrieved variable is set to '1' then we check for the > > same passphrase marker as the bootloader, its content compared > > against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' > > variable. > > 3a) If all is go, the passphrase variable is unset and the boot process > > continues, > > 3c) If the passphrase marker does not match, we panic. > > > > I'm sure that main_init should not know about geom or geli. This is usually > done with a handler of some sort so the mountroot code can just call the > generic handler. Can your code be restructured such that this is possible? > The reason I ask is that ZFS supports encryption too and it would be nice > to use that instead of geli. > > The configuration of the bootloader for this procedure looks the following: > > > > 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex > > to contain the TPM2 NV Index we store our passphrase in, e.g. 0x1000001 > > 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr > > to contain the PCR policy used to secure the passphrase, e.g. > > sha256:0,2,4,7 > > 3a) If both are set, the bootloader will attempt to retrieve the > passphrase > > and behave in the modified way described above > > 3b) Otherwise, it behaves as the vanilla version and will ask for GELI > > passphrases if necessary > > > > The configuration of the TPM and the passphrase marker looks the > following: > > > > 1) echo -n "passphrase" >/.passphrase_marker > > 2) chmod 600 /.passphrase_marker > > 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7 > > 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L > > policy.digest -A "policyread|policywrite" > > 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,2,4,7 > I did not read into the code yet, but in my opinion the usual way to perform this is by utilizing TPM measurement taken place in different boot stages. Only when things matches the TPM should unseal the sealed key lying somewhere in either GELI's key slot or ZFS's corresponding part. I agree the passphrase marker looks weird in the first place as we are never supposed to present this file in file system namespace if possible. I am not even sure if such protection is really necessary in the first place. > > > [1] > > > https://github.com/sadaszewski/freebsd-src/compare/releng/13.0...tpm-support-in-stand > > > This sounds cool. Any chance you can rebase this to the tip of the main > branch? All code goes into FreeBSD that way and 13.0 is about a year old > already. > > Thanks for sharing this. Despite some reservations expressed above, I think > this has potential to be quite cool. > > Warner > > > > Kind regards, Ka Ho > --00000000000069870e05d1c902f7-- From nobody Sat Nov 27 20:35:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5E80A18A17E4 for ; Sat, 27 Nov 2021 20:36:16 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4J1k0c1yYbz3kZx for ; Sat, 27 Nov 2021 20:36:16 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: by mail-ed1-x531.google.com with SMTP id w1so53960473edc.6 for ; Sat, 27 Nov 2021 12:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9vXFvGrCHbHHM/5RER1brMlMgejfOVE/K5h7AE7+dmw=; b=bKTHjUXYPHBdLW8xTnPAeJUdFm7OBvcouhIRgqEgdPUEhtUqdK8hs8lHUJcx6w+LJu oyTp+xRoIQT9XxUnQoav/4qaxuZMDr2chI4l2WbJ8iUsQ4MMvC3e+j+CSucRzapzq42f JtBHH5+M6KV7c/3eAYuJjJSDqQKTXKqp9bADB/ogXNsGXHXHwV4YE1vAd/9g7b9Iosek cloeGIXoIsJwRg1GwSgob9blr3IVF53gIwMwiyZg6ckeekkzGhN7YsO5uSUpRpgA9lQ3 y1MW8hr1H50y3JUZZHLcCVnBorl7WYYgleXCvXkjuUvzQwYS9G5Jt23iIiiMINAV58w5 ZgYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9vXFvGrCHbHHM/5RER1brMlMgejfOVE/K5h7AE7+dmw=; b=jlvOsnnRQ6oMgNVaemmFB2iHOJa01RJmHDIEHMeslUVRShvw/sHEJ2Hh/JduXKQTA1 /uExSXNDeSKC4H3Yuh8rbyFBflR/tgLuv84wFHB26lTySaNhIorRGe4sR4kmGQGfsyFg 1v/8qmImHJh0e6JpiNaFQW57mMpBrQkpULzqMpZ/C7YDUc0+Mc3z40TxhLyBVMx9LVia oPw3UtZBoHvdFoNzOWFsetQtxuCjwXcQdVUwaSELiOvL6/DLBLKIkgVkZLe0WL93B613 JUS5XT+pc9jLFvLmFFu+j4KVTxI9fra31cBh+ajS+d+ByiNBHCiLflKLRzo2RAs1saOF 5wzg== X-Gm-Message-State: AOAM531bPEXBm/LkA+yEDbM039tY56QBF9rebcacZuJGyKKxwJlw/gaJ iFTLAOZ9Cn9YAuHQhiebnbvcZh6n1xBFTK2pbSvrXFpFs8Y= X-Google-Smtp-Source: ABdhPJx594/LMREKKAoInnx3IisSdDzh0tBG/P3AmBrrT1uEBmKHb5/ClZevxi90KS2ZnWnfJuudwK77b18LGmMzxL0= X-Received: by 2002:a50:e0cf:: with SMTP id j15mr59401396edl.23.1638045368921; Sat, 27 Nov 2021 12:36:08 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Stanislaw Adaszewski Date: Sat, 27 Nov 2021 21:35:32 +0100 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Warner Losh Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J1k0c1yYbz3kZx 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: N Hi Warner, Thanks a lot for the quick reaction - that helps. Accordingly, I have taken several actions (below). If you have any more tips how to push this forward, please let me know. Like I don't know is there a person formally responsible for this kind of contributions? Let's say when you are happy with the general architecture of the solution and the quality of the code (it still requires some polishing) - is that enough to pull the changes into the codebase? How does that work? Thank you in advance! 1. I have rebased my changeset on top of the tip of the FreeBSD's main branch [1] 2. I have changed the /.passphrase_marker convention to hold (instead of the passphrase) a human-readable lower-case digest of SHA256(salt | passphrase) where salt is a new (optional) parameter which can be passed using another EFI variable: KernGeomEliPassphraseFromTpm2Salt. I think it is more for the peace of mind than anything else, as anyone having access to /.passphrase_marker would normally have to be the root user. Nevertheless it is perhaps nicer not to keep raw passphrases laying around in files. We still pass the passphrase to the kernel via a kernel variable kern.geom.eli.passphrase.from_tpm2.passphrase which is unset before the system becomes interactive. I could be easily passing the hash computed by the bootloader instead - what do you think? One thing to keep in mind is that another kernel variable - kern.geom.eli.passphrase has been passed around like this as well and it is being unset precisely in init_main.c. But even more importantly, one has to keep in mind that geli_export_key_buffer() passes all GELI keys to the kernel anyway, so access to the encrypted drives is already possible by that alone. Not to mention that the root user can simply read the driver's master key with a simple geli show. 3) As an explanation, also to @Ka Ho Ng, the /.passphrase_marker serves only as a tag to allow to reliably pair a boot filesystem to the keyphrase retrieved from the TPM. If we were to just retrieve the passphrase and pass it to any boot environment then one would simply boot another OS with another root password and could read all our secrets. The same goes for the root filesystem that is mounted in turn by the kernel. If one would for example remove the boot drive - that would cause the kernel to drop out to interactive mountfrom> prompt and then one could for example boot from another drive. That is unacceptable. Kernel is by default very "boot happy" - it tries really hard to boot SOMETHING rather than accept a strict specification of what is allowed to boot. 4) The code is fully functional and I have tested it quite a bit on a Zotac CI622 mini-PC with the latest BIOS update which enables the TPM functionality on the Intel 10110U process in there. If you have a TPM-capable BIOS and CPU, I would encourage you to try, like this you will understand better how it works and that the design is necessary like it is with the /.passphrase_marker. I am not 100% sure if there are no ways left to fool the system to boot or run some arbitrary code. Such attacks would generally consist of causing some kind of errors on the "trusted" UFS-on-GELI or ZFS-on-GELI systems and making the system drop out into some kind of interactive prompts. I hope that does not happen. For example if one removes the drive during init= . I would certainly expect that no process drops out to interactive prompts on a system with a root password set bit this kind of scares is a tradeoff of not using full VERIEXEC. It is however very convenient to say - just trust everything on the XXX-on-GELI since this was encrypted and therefore tampering-proof. More tests are necessary but also - VERIEXEC can be enabled in addition to that to ensure that such weird scenarios do n= ot happen. 5) @Ka Ho Ng what you said is taking place clearly, the code relies on a PC= R policy of user's choice and uses that to read the passphrase. 6) Regarding ZFS encryption I am not sure if that is supported in the EFI bootloader - at first glance I would say that it isn't. With that said, the code can be used to further modify the loader to read any kind of values stored in the TPM and put them in kernel variables for later use in the boot process. Just a big WARNING, kenv seems to let even lusers to r= ead the variables. So whatever one would do with them, it would have to be done quickly and the variables would need to be discarded before letting the lusers log in. [1] https://github.com/sadaszewski/freebsd-src/compare/main...main-cherry-p= ick-tpm-support-in-stand Kind regards, -- Stanislaw On Sat, 27 Nov 2021 at 18:00, Warner Losh wrote: > > > > On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski wrote: >> >> Dear All, >> >> Could you please guide me so that we can together integrate >> the following piece of work into the FreeBSD base system? >> Thank you for your time and consideration. > > > See below for some advice. > >> I have created the following bundle of work [1]. The referenced >> patch implements on top of releng/13.0, the support for TPM2 >> in the EFI bootloader and in the kernel in order to allow for >> storage and retrievel of a GELI passphrase in a TPM2 module, >> secured with a PCR policy. >> >> The way the bootloader behavior is modified is the following: >> >> 1) before calling efipart_inithandles() an attempt to retrieve the >> passphrase from a TPM2 module might be performed - >> how this is achieved is described later on. >> 2) if a passphrase is indeed retrieved, then after determining >> currdev, the currdev is checked for the presence of a >> /.passphrase_marker file which must contain the same passphrase >> as retrieved from the TPM. This is supposed to ensure that we >> do not end up booting an environment not on the device we just >> unlocked with the passphrase. >> 3a) If all is go, the autoboot_delay is set to -1 in order to prevent >> any interaction and continue the boot process of the "safe" environment, >> a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set >> to the passphrase from TPM in order for kernel use later, as well as a >> kern.geom.eli.passphrase.from_tpm2.was_retrieved'=3D'1' variable. >> 3b) If the passphrase marker does not match, the bootloader cleans up >> GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits. > > > I worry about information disclosure having the pass phrase available on = the running system with this setup. Can you explain why that design point w= as selected? Usually there is something signed with a private key that the = public key can be used to verify instead of a direct comparison like this t= o prevent disclosure of key material. I've not looked at the code yet, so i= t may already do this... > >> The way the kernel behavior is modified is the following: >> >> 1) In init_main.c, after vfs_mountroot() a check is added >> 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not >> set to 1, then we do nothing and continue the boot process >> 2b) If the was_retrieved variable is set to '1' then we check for the >> same passphrase marker as the bootloader, its content compared >> against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' >> variable. >> 3a) If all is go, the passphrase variable is unset and the boot process >> continues, >> 3c) If the passphrase marker does not match, we panic. > > > I'm sure that main_init should not know about geom or geli. This is usual= ly done with a handler of some sort so the mountroot code can just call the= generic handler. Can your code be restructured such that this is possible?= The reason I ask is that ZFS supports encryption too and it would be nice= to use that instead of geli. > >> The configuration of the bootloader for this procedure looks the followi= ng: >> >> 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex >> to contain the TPM2 NV Index we store our passphrase in, e.g. 0x1000001 >> 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr >> to contain the PCR policy used to secure the passphrase, e.g. >> sha256:0,2,4,7 >> 3a) If both are set, the bootloader will attempt to retrieve the passphr= ase >> and behave in the modified way described above >> 3b) Otherwise, it behaves as the vanilla version and will ask for GELI >> passphrases if necessary >> >> The configuration of the TPM and the passphrase marker looks the followi= ng: >> >> 1) echo -n "passphrase" >/.passphrase_marker >> 2) chmod 600 /.passphrase_marker >> 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7 >> 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L >> policy.digest -A "policyread|policywrite" >> 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,2,4,= 7 >> >> [1] https://github.com/sadaszewski/freebsd-src/compare/releng/13.0...tpm= -support-in-stand > > > This sounds cool. Any chance you can rebase this to the tip of the main b= ranch? All code goes into FreeBSD that way and 13.0 is about a year old alr= eady. > > Thanks for sharing this. Despite some reservations expressed above, I thi= nk this has potential to be quite cool. > > Warner > >> >> Kind regards, From nobody Sat Nov 27 21:55:06 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CD8E618B0C96 for ; Sat, 27 Nov 2021 21:55:09 +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 4J1lld2pscz4dNb; Sat, 27 Nov 2021 21:55:09 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f2e:2500:950c:f552:7324:1999] (p200300cd5f2e2500950cf55273241999.dip0.t-ipconnect.de [IPv6:2003:cd:5f2e:2500:950c:f552:7324:1999]) (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 13E666241; Sat, 27 Nov 2021 21:55:07 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <1bd2140c-60fd-2f3c-432d-c945caf5e3dd@freebsd.org> Date: Sat, 27 Nov 2021 22:55:06 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas: lsof Content-Language: en-US To: Graham Perrin , Larry Rosenman Cc: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> <246adde5-6a7a-4102-abb4-16c766ea78d1@freebsd.org> <39d7dec472c4d937404aabba91a5ead6@FreeBSD.org> <6e7d550f-78bf-29cc-7283-93d5c8263519@gmail.com> From: Stefan Esser In-Reply-To: <6e7d550f-78bf-29cc-7283-93d5c8263519@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------LHoa47pkDSvrAZfbA9fUDsAb" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638050109; 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=k9FrAZqR3xSDJKEHDJsk1f8/zVmCQniDl2MHGIM1NEI=; b=wQLCWfUDlg699rnwHMynUlHvuXeNHconeN1KmTTrR7NvJd77qhoI/7j6mD5egJbpVaUjEl aTq3Izf/JdiS0pbivrL/vDzBjsXI2cNLf4Vc0yJcdEdCJGiPfLy4MwhFvNzRYSqrk0pQox Izjamb11dNhj9qvMsPKfTyRqieoDA4zmHDZgI1rvjUspbGrxn3zJ6H5gsGeHFa6XUXJ4UT kZwNInGPBzmWBD31YXyeUonsIp3KmWCrouPsXvgcNhenm+C0bHHIEjrDq+zrLjADsP+jf4 K3C8I5pqZH+bAF+GgDZoLWuzW8A6YCkyB84RsLIq5OliH/9l/oZunAovITAjeA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638050109; a=rsa-sha256; cv=none; b=xxb+wSXxksqpHKrtp8eklifkcQ3gPyssC0nP2H7HrItt/Yb87fFYjIyM0JEa5lPZEt+LYW yxmDiQhCxPk2W2+qHP5bKkY1nFudxQg5l4itJZI6vZmZ7UXs/mfJjicrxhYPnsvIOZkB3W OC7kjMLdUXXjwUUOYaCW2rl65ROe699s1s2Xjsbl8hvLQ6QBK3XuONcuKYStexdi12uYAH NvD8v+ImH2bkuLqxg9G/KmNJjCEKYgI3WcjW6182EYBehvFeBwjiwlHp2gp2zQGCW5RKBx BuIRFHAU/5BvF31cQZKnvYjBNbLF68Y22YokhsuKovmHFyx3i6A/cIa2rxq3jA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------LHoa47pkDSvrAZfbA9fUDsAb Content-Type: multipart/mixed; boundary="------------cFQHwZWG3d0QcEHTvzrRrW41"; protected-headers="v1" From: Stefan Esser To: Graham Perrin , Larry Rosenman Cc: freebsd-hackers@freebsd.org Message-ID: <1bd2140c-60fd-2f3c-432d-c945caf5e3dd@freebsd.org> Subject: Re: Call for Foundation-supported Project Ideas: lsof References: <861r36xzpe.fsf@phe.ftfl.ca> <66b556bf-e797-483b-b377-182859be572a@www.fastmail.com> <246adde5-6a7a-4102-abb4-16c766ea78d1@freebsd.org> <39d7dec472c4d937404aabba91a5ead6@FreeBSD.org> <6e7d550f-78bf-29cc-7283-93d5c8263519@gmail.com> In-Reply-To: <6e7d550f-78bf-29cc-7283-93d5c8263519@gmail.com> --------------cFQHwZWG3d0QcEHTvzrRrW41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 27.11.21 um 09:34 schrieb Graham Perrin: > On 25/11/2021 00:01, Larry Rosenman wrote: >> =F0=A0=89=A7=E2=80=A6 Back to the topic: >> Can I PLEASE get some help on sysutils/lsof (which has been broken for= all of >> 13 and 14's lifetime)? >> If I can't, I'm going to rmport it. =E2=80=A6 >=20 >=20 > Is that, more than anything, > for compat= ibility > with (OpenZFS) ZFS? I have develioped a patch that supports the openzfs file layout, but did not get lsof to build with OpenZFS headers. There are a number of type conflicts and did not have any spare time to sort them out ... A TAR file of the lsof port directory with some of the required patches is available from: https://people.freebsd.org/~se/ports/lsof-port.tar.bz2 Some of the changes are experimental and not to be included in a final version of the port. I first wanted to get the port to compile, then work= out the correct way to pass required options etc. It still fails while compiling dnode2.c: In file included from dnode2.c:45: In file included from /usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/types.h:36: In file included from /usr/src/sys/contrib/openzfs/lib/libspl/include/sys/types.h:75: In file included from /usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/param.h:34: In file included from /usr/include/sys/param.h:142: /usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/time.h:53:9: erro= r: unknown type name 'longlong_t' typedef longlong_t hrtime_t; ^ /usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/time.h:67:1: erro= r: redefinition of 'gethrtime' gethrtime(void) ^ /usr/src/sys/contrib/openzfs/lib/libspl/include/sys/time.h:100:1: note: previous definition is here gethrtime(void) ^ In file included from dnode2.c:45: In file included from /usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/types.h:36: In file included from /usr/src/sys/contrib/openzfs/lib/libspl/include/sys/types.h:75: In file included from /usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/param.h:38: In file included from /usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/systm.h:33: In file included from /usr/include/sys/systm.h:179: /usr/include/sys/kpilite.h:33:10: fatal error: 'offset.inc' file not foun= d #include "offset.inc" ^~~~~~~~~~~~ 3 errors generated. *** Error code 1 Regards, STefan --------------cFQHwZWG3d0QcEHTvzrRrW41-- --------------LHoa47pkDSvrAZfbA9fUDsAb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGiqToFAwAAAAAACgkQR+u171r99UQL HQgAh/NHmqqzFcSg3rkJKJf8sz//KghageEb6WZ9RjMszsAv/tXXRkhG99SFNgqqpElGmn4ck7v0 Zl6Ws4wxu9xixTNuJ2O5EI649FyHftndJ15wrrWnHP2qm95D7YFzdSJXGoF4gX8jxi4UT0AMoNk+ 9TCuqhuRUpaw9aKsEzlf1Ulp8ZHNRWm6syk0HnRILWQL0MU2i7B8Ao8wXTxr0UNHcvqZc03AqAV4 ZNRk/wjInwAoeS3EH6F19zE1n5bOnUV1DgimPzyhas3eNCyL3EvaLj160G4rokvjHGmZbzX91JHR qRxUe/GcIVNbS/did02FjVP88UrsTpx3E7Od4bktdA== =j8Zs -----END PGP SIGNATURE----- --------------LHoa47pkDSvrAZfbA9fUDsAb-- From nobody Sat Nov 27 22:40:24 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E398C18C637D for ; Sat, 27 Nov 2021 22:40:36 +0000 (UTC) (envelope-from obsto.clades@zohomail.com) Received: from sender4-pp-o91.zoho.com (sender4-pp-o91.zoho.com [136.143.188.91]) (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 4J1mm35cMXz4svQ for ; Sat, 27 Nov 2021 22:40:35 +0000 (UTC) (envelope-from obsto.clades@zohomail.com) ARC-Seal: i=1; a=rsa-sha256; t=1638052827; cv=none; d=zohomail.com; s=zohoarc; b=DOHKE/baGiGEkJhlFC1oa7YZ0RoFIK9b4jRfSRhc6qcLWVuYDI5URDKhLouQfK/kHWWdttbM1hyWTCCs2Pl4f0kdpJqwNvoECvSFKmBynXWaKv/VZAZgQITMleF7QIGiUNs1YcLN1KfNhatEBgBJ+3GBKPzhN9Ewss3dYbfyvdk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638052827; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To; bh=riDVOFGF+s1X/5emrHX4Av5WBGsTK+HUawEhKpnPF8Q=; b=cPLldaicXQmduhvwONfjr89ifEfjopsW9OBuph3UYA8S2xcs7evIlgt+TX7LhgxnqIVwdf9igQZtjKHXXnMbls1//ac4eGHvGUBt4rmYq5P4+jHsgQuNglntfe5hf8jlD/q4QHxugP0uMyqXf8u+guIiiMTTw1NfM6JWWOBnVYQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zohomail.com; spf=pass smtp.mailfrom=obsto.clades@zohomail.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1638052827; s=zm2020; d=zohomail.com; i=obsto.clades@zohomail.com; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=riDVOFGF+s1X/5emrHX4Av5WBGsTK+HUawEhKpnPF8Q=; b=UDVSX4nki1/obn1LYVyYAhknLny9xwekbneAatfKpys7ShBYeM8XCyyFYOUSGIfS 71s75icSUBtzH8hq7G7WHHrGcPcOOvI8l1s9jWI4JhPWzCP8ZxGg/cACeNir9mlZAe6 lD5PSpFlwh5+An6KgAiDBp5QTDiHhQbI+AZjbgUw= Received: from [10.0.0.2] (97-113-103-185.tukw.qwest.net [97.113.103.185]) by mx.zohomail.com with SMTPS id 1638052825332452.79972499098733; Sat, 27 Nov 2021 14:40:25 -0800 (PST) To: freebsd-hackers@FreeBSD.org Subject: Hello Message-ID: Date: Sat, 27 Nov 2021 14:40:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ZohoMailClient: External X-Rspamd-Queue-Id: 4J1mm35cMXz4svQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zohomail.com header.s=zm2020 header.b=UDVSX4nk; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=pass (policy=reject) header.from=zohomail.com; spf=pass (mx1.freebsd.org: domain of obsto.clades@zohomail.com designates 136.143.188.91 as permitted sender) smtp.mailfrom=obsto.clades@zohomail.com X-Spamd-Result: default: False [-4.95 / 15.00]; DWL_DNSWL_NONE(0.00)[zohomail.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[zohomail.com:s=zm2020]; RECEIVED_SPAMHAUS_PBL(0.00)[97.113.103.185:received]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/24:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[zohomail.com:+]; DMARC_POLICY_ALLOW(-0.50)[zohomail.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.91:from]; NEURAL_HAM_SHORT(-0.95)[-0.946]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/23, country:US]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Reply-To: obsto.clades@zohomail.com From: Obsto Clades via freebsd-hackers X-Original-From: Obsto Clades X-ThisMailContainsUnwantedMimeParts: N I hacked on the FreeBSD source code to produce a version of the OS that cannot be remotely hacked.  Before you tell me that is impossible, I have an answer to that response on my FAQ page. If you are interested in checking out my OS, you can find instructions on my site's home page:  https://obstoclades.tech/ I invite you to check it out. -- Obsto Clades, LLC From nobody Sat Nov 27 23:26:43 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B32A18ACBD3 for ; Sat, 27 Nov 2021 23:27:01 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1nnc4HrPz3PDG for ; Sat, 27 Nov 2021 23:27:00 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 1ARNQi3I096355 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 27 Nov 2021 18:26:50 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> Date: Sat, 27 Nov 2021 18:26:43 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Hello Content-Language: en-US To: freebsd-hackers@freebsd.org References: From: George Mitchell In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4J1nnc4HrPz3PDG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-3.25 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 11/27/21 17:40, Obsto Clades via freebsd-hackers wrote: > I hacked on the FreeBSD source code to produce a version of the OS that > cannot be remotely hacked.  Before you tell me that is impossible, I > have an answer to that response on my FAQ page. > > If you are interested in checking out my OS, you can find instructions > on my site's home page:  https://obstoclades.tech/ > > I invite you to check it out. > Hmm, my mother told me never to click on links in strange emails ... -- George From nobody Sun Nov 28 00:17:22 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 29BFD18A61A4 for ; Sun, 28 Nov 2021 00:17:31 +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 4J1pvt329vz3vPp; Sun, 28 Nov 2021 00:17:30 +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 1AS0HN5H080801; Sun, 28 Nov 2021 00:17:23 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 1AS0HMYG080800; Sun, 28 Nov 2021 00:17:23 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202111280017.1AS0HMYG080800@donotpassgo.dyslexicfish.net> Date: Sun, 28 Nov 2021 00:17:22 +0000 Organization: Dyslexic Fish To: grog@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: Top posting (was: Call for Foundation-supported Project Ideas) References: <861r36xzpe.fsf@phe.ftfl.ca> <8483eae3-3ee2-1548-8786-42bb96d4937a@gmail.com> <20211125234816.GE96868@eureka.lemis.com> In-Reply-To: <20211125234816.GE96868@eureka.lemis.com> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sun, 28 Nov 2021 00:17:23 +0000 (GMT) X-Rspamd-Queue-Id: 4J1pvt329vz3vPp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.57)[-0.574]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.22)[-0.223]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; 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:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N "Greg 'groggy' Lehey" wrote: > On Wednesday, 24 November 2021 at 21:33:50 +0000, Graham Perrin wrote: > > On 24/11/2021 01:31, Mehmet Erol Sanliturk wrote: > >> Change policy about discouraging top posting and convert it to encouraging > >> top posting > > > > Please, don't. > > Agreed entirely in this context. But what are we talking about here? > Mehmet refers to a policy, but who has read it? > > My guess is that his real issue is "bottom posting", which is arguably > even worse than "top posting". In each case, the reply is separate > from the original, and the only difference is where you find it. But I agree that "bottom posting" is an annoying problem too. > that's not what the policy says. As I know it, it's at the end of > https://docs.freebsd.org/en/articles/freebsd-questions/ and obviously > > [POLICY] > > It's over 20 years old, but I still believe that it is correct. It > also should work for mobile phones, better than "top posting". > > Comments? I agree. Whether I'm using mobile or desktop, that is by far the easiest format to navigate. It's almost as if whoever wrote that had some relevant experience on the matter! :-) Cheers, Jamie From nobody Sun Nov 28 01:06:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8D71D18BC6C8 for ; Sun, 28 Nov 2021 01:06:29 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4J1r0P3VxHz4f8P for ; Sun, 28 Nov 2021 01:06:29 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mail-io1-xd2d.google.com with SMTP id e144so16267715iof.3 for ; Sat, 27 Nov 2021 17:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yVq/qSsNkmzmjgTc0zLnX6RLusY5ppLaS8+9rAwI6nU=; b=bHTXxZOz0BZ+bKJE2HNnIjVlWkcmhVEELouONTNxnfsA7Nwa2CUw85Aye/Yn67zBIY /HBk2Lo+npgoRGuVzGI+dhZQGaGwMt3RJNI42hHuv+yrmtAJB0OGUhLTtOzjJrWJskvX Uk40Ef/8EkNHlyxDV10IrfoeoOEX3tmkaz6CI= 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=yVq/qSsNkmzmjgTc0zLnX6RLusY5ppLaS8+9rAwI6nU=; b=P6cu5R3ZNWcQlBjSIdGzS9ZBZxBMZShNxOPUq3HK63mt7f65NY9FTJd44YLk0PIbz2 pbinckenVK7NDGkeKokm9n3HDQiQRXecl7g2eRcxmCyu9A8SoS7qyXh6t7lx2LiDaWpl j1lrpCyVaCfi7Set2J8Qv+XB+5B48mOW0s5o4zaZvO2YE9n5x6s9NNvPUYPdJB7yAQWF jsgDZ9xqh8UmHtRXY6o4mGqIWxKMIq9WpkmqNOvOptcdH+ba28Pbss+63EX0PJXLYwWB 6x6POOso5U1KMG35QlkaYGiyHjmwGiyOe554DOShwqZcsKt8zxmrDFLtqv99d0emu9Ww BETA== X-Gm-Message-State: AOAM530eW9HQLdeylgcVvMpRxNa2VRE6ImZ/+hXpbBbUKPSjiegKdcVR orUiRj4ex/zkjMYn55LBJ1c+fEH7ehjhn0MEntoBoCx/Kbw= X-Google-Smtp-Source: ABdhPJxd/bQtO0Iu1KGKLT9C9tIkXe5ncoKP/fk+T2aC0/SDHwT9oErsstAusblUU5fZY0Yc490L+Rhm6Oe7aTd0oyM= X-Received: by 2002:a5d:81d3:: with SMTP id t19mr50108099iol.199.1638061588010; Sat, 27 Nov 2021 17:06:28 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> In-Reply-To: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> From: Mario Lobo Date: Sat, 27 Nov 2021 22:06:17 -0300 Message-ID: Subject: Re: Hello To: freebsd-hackers Content-Type: multipart/alternative; boundary="00000000000012ed6105d1ceef7e" X-Rspamd-Queue-Id: 4J1r0P3VxHz4f8P X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000012ed6105d1ceef7e Content-Type: text/plain; charset="UTF-8" On Sat, Nov 27, 2021, 20:27 George Mitchell wrote: > On 11/27/21 17:40, Obsto Clades via freebsd-hackers wrote: > > I hacked on the FreeBSD source code to produce a version of the OS that > > cannot be remotely hacked. Before you tell me that is impossible, I > > have an answer to that response on my FAQ page. > > > > If you are interested in checking out my OS, you can find instructions > > on my site's home page: https://obstoclades.tech/ > > > > I invite you to check it out. > > > > Hmm, my mother told me never to click on links in strange emails ... > -- George > curl http://obstoclades.tech Connection denied by Geolocation

Connection denied by Geolocation Setting.

Reason: Blocked country:

The connection was denied because this country is blocked in the Geolocation settings.

Please contact your administrator for assistance.

WatchGuard Technologies, Inc.
> --00000000000012ed6105d1ceef7e-- From nobody Sun Nov 28 06:13:47 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DBC5C18C3BBC for ; Sun, 28 Nov 2021 06:14:30 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1yqp5lNLz3H2Q for ; Sun, 28 Nov 2021 06:14:30 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-vk1-xa35.google.com with SMTP id u68so8729486vke.11 for ; Sat, 27 Nov 2021 22:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bWy6vVZw7X4ETqYel7l2wYGSPK/DmIGRD2/TFaiv7d8=; b=aKNSmLcxTLRAqH9qoJ1DKme1K59OH7ZqoA3BuLJLlqTCWnSnjW4Jkjz2YDXdWQBGuS YyJIvYJ0RjqHPJrTHONCgMiTBp9NUa+bmcYI7+Cghzn8V4gDC2hDwQ9IHzDExtqgkH1L 3KFLT+MtpGusQrscK8SisF8OTcfp/Xc+olC/8gfdCDjGDuSV5n0OW/e6J24+JwqcoUmz U3eUfOIl9oVXSd6T3+YXyS4nzercBQRGWGyPBJXRfP24llp9Q5LW77M83I5r17asZUKF em+isvvz+8J01OQlJ43rbwXWR7Rx4O6v2YyhOLpWweQ8WfdAdceFgHcHpLLUfs2ByoCF DN/g== 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=bWy6vVZw7X4ETqYel7l2wYGSPK/DmIGRD2/TFaiv7d8=; b=YLLR5VJBG4g/f/qAfm5toJQz9Cu+UXVXDt8SZPiQUEetSduYgkGW4IfeNrpPza2Fwg v836DSWDW7FXNmhkOa6RU6C/kGxvAdOr3b/YMZshtCxjOinb0GnRo8ZBNo2nk1fscp2G 4nbGYKg8EfP3cA1vJM/GUZ9tVx3QqNp18ijfEZiQRzb3eco/6RCfoQhKDH2R1jv7mlGn TC0XFv4OY02P+jHtxcwm/XYAUnSbC9akdQMZNBbCTX2QVUtYjW8eyj2Sy1KbxC+XojkT ypopNArF1XRAC/CpATey8PoePC/ajlQ0OX+Yo8UwPbO7wCoES3NthAfH9kfoTQVTyNKS owYA== X-Gm-Message-State: AOAM5306xi7iZ2mfSYng73nig8Jw+17cPOiA5kwW8cM75R/QzCSXcQG/ 1WbKKP0yzcd4FvK6APrerMzo/tONnUYZYgex8ZCg2CTadRA= X-Google-Smtp-Source: ABdhPJwVrrfJWvjq3OJejTai8sInBU3OdjYzckfUwuM0pjFc3qHyfGONLMbVU+Ye/O3czaYM0v0je/5de4WkkbL3XSI= X-Received: by 2002:a05:6122:2015:: with SMTP id l21mr29636823vkd.16.1638080064169; Sat, 27 Nov 2021 22:14:24 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Sun, 28 Nov 2021 09:13:47 +0300 Message-ID: Subject: Re: Hello To: obsto.clades@zohomail.com Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000056ab0605d1d33c1b" X-Rspamd-Queue-Id: 4J1yqp5lNLz3H2Q 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 --00000000000056ab0605d1d33c1b Content-Type: text/plain; charset="UTF-8" When accessed to your website , the response from the Firefox is the following : "Your connection is not secure The owner of obstoclades.tech has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website. ..." Mehmet Erol Sanliturk On Sun, Nov 28, 2021 at 1:41 AM Obsto Clades via freebsd-hackers < freebsd-hackers@freebsd.org> wrote: > I hacked on the FreeBSD source code to produce a version of the OS that > cannot be remotely hacked. Before you tell me that is impossible, I > have an answer to that response on my FAQ page. > > If you are interested in checking out my OS, you can find instructions > on my site's home page: https://obstoclades.tech/ > > I invite you to check it out. > > -- > Obsto Clades, LLC > > > --00000000000056ab0605d1d33c1b-- From nobody Sun Nov 28 08:13:23 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 664A018BC085 for ; Sun, 28 Nov 2021 08:13:55 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4J21Tb2D2Xz4cTZ for ; Sun, 28 Nov 2021 08:13:55 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: by mail-ed1-x52e.google.com with SMTP id x6so58063968edr.5 for ; Sun, 28 Nov 2021 00:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=wphHAr5Qdp2Kt4KWyqlhohEg78jy6VYS0CAxQPET7U8=; b=LEaejDNLJTW4qdBUjoW4iB6Y5W+JeibungtLU95ln5t6qfCcYfw7eCq+9bpjT4RMZa 4rmuAlj05kruOrewCjwPAptRrHaAMDmPoAOeMqY2AEgPBw0R56lVLPHRBSj+7Wr8uAn/ kMnf5mUGcdlZr0oB31eVDbu3t2GuH8EPpPxwsiFVJQk484639dR4NI9soEnaPAl7YrNO KeCZr3h62daiuY603ASYQjIebDqwVGEBDE6kej2NAvVSkib+z3jZ+suUaVN8ctlStCJd No1ft1GR2RPMo6DruIZ368SHlV4GvAIT8iQf+4OATJep67xp2Qhex3bjHWaK2stUXmqb noPA== 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:content-transfer-encoding; bh=wphHAr5Qdp2Kt4KWyqlhohEg78jy6VYS0CAxQPET7U8=; b=e1Q9GfNd4L3PetaZVNX9nAvqe+VE0RzUF9pGdk9AIGGO8ngnTGXk7yTDSp3ZCf2jhv BP3w6Xg9Soq/1FCfIgWjkUwavr0j0wCSD2YjNSZrqwUon+GbNzV57HjW7FJ/PtkBy4L1 y1tKpHAoQpE8AQu7WwU0tpyx01w8lV+ATzbI0CJpwH7jJToxRRK8peKaW+AFnt935j6R jJFFEDHpDyWhDh+kS+Zh/TSAxrmCGeo8gD72R2Trxg66bf1ACpYZrMIDxuaYnZY9KARx kmFj+dphlnM91/2FYJKRuKtC5eDaSff/uIgkrpFv3pM/g0P/O0W7m+9UrpGSiL/FxkPP cOOQ== X-Gm-Message-State: AOAM533j4feHPOmBMvyMSqesH5vykra1sWufvfd9dOP91h1r2faEv356 fB/6mv2YWxb7ng9PWp6iYJrSiyQAFV4TJ5fokapPaJV7 X-Google-Smtp-Source: ABdhPJxH/vhNwUoZpDA0sYi1k+JbVyao+jUnGBAW+NZRx+EIjiZA6Vjo1k1uIYfqvX5c91fZibo5W7yeklH73XNu5Kw= X-Received: by 2002:a50:d492:: with SMTP id s18mr64458786edi.145.1638087234250; Sun, 28 Nov 2021 00:13:54 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Stanislaw Adaszewski Date: Sun, 28 Nov 2021 09:13:23 +0100 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J21Tb2D2Xz4cTZ 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: N Hi Ka Ho Ng, Thanks for the interesting remarks! > I believe putting that somewhere as container metadata for consumption by= geom_eli > would be more favorable for such usage. That should make it look more tai= lored given > encryption is a volume property rather. The system does not think in terms of GELI anymore when it considers a rootfs. For a ZFS-on-GELI rootfs it is passed from the bootloader at as zfs:zroot/ROOT/default: and that's it, no mention of GELI. See below - the drive could be substituted for a hostile one before the kernel gets to mounting the rootfs. A check for the /.passphrase_marker is necessary AFTER vfs_mountroot(). The root ZFS could be as well spanning multiple GELI devices, etc. It is simply on a higher level than GELI. > In a strict environment it might be better to simply drop the prompt and = directly > panic instead. This could be implemented as well but is currently not done as it would not be enough to ensure a trusted rootfs. Conversely, after ANY successful vfs_mountroot(), the rootfs is checked for the presence of the correct /.passphrase_marker and we panic if this is not the case. This makes for a real protection. You could imagine unplugging the boot dri= ve in the early stages of kernel runtime (before mounting the rootfs) and pluggin= g in another one with a ZFS pool (with the same name) on an unencrypted partition - AFAIK the kernel would pick it up without any complaint and boot straight into a hostile userland while keeping all the secrets available in memory. In fact, if you re-plugged the boot drive then, it would use the cached GELI keys and decrypt it straight away. > Despite tpm2_nvwrite is used instead of sealing. TPM non-volatile storage= is not > something we can spare as they are limited resources. Sealing does not re= quire > non-volatile storage in TPM module, while achieving what you have describ= ed. The TPM PC platform specification says: "1.The TPM SHALL provide a minimum = of 6962 bytes of NV Storage.". The passphrase is only using a dozen. That shou= ld be fine. Aren't sealed persistent objects on the TPM eating into the same memory anyway? Perhaps you could elaborate? In either case switching to sealed objects (if there really is a rationale) would be a minor change. Kind regards, -- Stanislaw On Sat, 27 Nov 2021 at 21:35, Stanislaw Adaszewski wrote: > > Hi Warner, > > > Thanks a lot for the quick reaction - that helps. Accordingly, > I have taken several actions (below). If you have any more tips > how to push this forward, please let me know. Like I don't know > is there a person formally responsible for this kind of > contributions? Let's say when you are happy with the general > architecture of the solution and the quality of the code > (it still requires some polishing) - is that enough to pull > the changes into the codebase? How does that work? > Thank you in advance! > > > 1. I have rebased my changeset on top of the tip of the > FreeBSD's main branch [1] > > > 2. I have changed the /.passphrase_marker convention to hold > (instead of the passphrase) a human-readable lower-case digest > of SHA256(salt | passphrase) where salt is a new (optional) > parameter which can be passed using another EFI variable: > KernGeomEliPassphraseFromTpm2Salt. > > I think it is more for the peace of mind than anything else, > as anyone having access to /.passphrase_marker would normally > have to be the root user. Nevertheless it is perhaps nicer not > to keep raw passphrases laying around in files. > > We still pass the passphrase to the kernel via a kernel variable > kern.geom.eli.passphrase.from_tpm2.passphrase which is unset > before the system becomes interactive. I could be easily > passing the hash computed by the bootloader instead - what do > you think? > > One thing to keep in mind is that another kernel variable - > kern.geom.eli.passphrase has been passed around like this > as well and it is being unset precisely in init_main.c. > > But even more importantly, one has to keep in mind that > geli_export_key_buffer() passes all GELI keys to the kernel > anyway, so access to the encrypted drives is already possible > by that alone. Not to mention that the root user can simply > read the driver's master key with a simple geli show. > > > 3) As an explanation, also to @Ka Ho Ng, the /.passphrase_marker > serves only as a tag to allow to reliably pair a boot filesystem > to the keyphrase retrieved from the TPM. If we were to just > retrieve the passphrase and pass it to any boot environment then > one would simply boot another OS with another root password and > could read all our secrets. The same goes for the root filesystem > that is mounted in turn by the kernel. If one would for example > remove the boot drive - that would cause the kernel to drop out > to interactive mountfrom> prompt and then one could for example > boot from another drive. That is unacceptable. Kernel is by default > very "boot happy" - it tries really hard to boot SOMETHING rather > than accept a strict specification of what is allowed to boot. > > > 4) The code is fully functional and I have tested it quite a bit > on a Zotac CI622 mini-PC with the latest BIOS update which enables > the TPM functionality on the Intel 10110U process in there. If you > have a TPM-capable BIOS and CPU, I would encourage you to try, like > this you will understand better how it works and that the design is > necessary like it is with the /.passphrase_marker. I am not 100% sure > if there are no ways left to fool the system to boot or run some > arbitrary code. Such attacks would generally consist of causing some > kind of errors on the "trusted" UFS-on-GELI or ZFS-on-GELI systems and > making the system drop out into some kind of interactive prompts. I > hope that does not happen. For example if one removes the drive during in= it. > I would certainly expect that no process drops out to interactive prompts > on a system with a root password set bit this kind of scares is > a tradeoff of not using full VERIEXEC. It is however very convenient > to say - just trust everything on the XXX-on-GELI since this was encrypte= d > and therefore tampering-proof. More tests are necessary but also - VERIEX= EC > can be enabled in addition to that to ensure that such weird scenarios do= not > happen. > > > 5) @Ka Ho Ng what you said is taking place clearly, the code relies on a = PCR > policy of user's choice and uses that to read the passphrase. > > > 6) Regarding ZFS encryption I am not sure if that is supported in the EFI > bootloader - at first glance I would say that it isn't. With that said, > the code can be used to further modify the loader to read any kind of > values stored in the TPM and put them in kernel variables for later use > in the boot process. Just a big WARNING, kenv seems to let even lusers to= read > the variables. So whatever one would do with them, it would have to be do= ne > quickly and the variables would need to be discarded before letting > the lusers log in. > > > [1] https://github.com/sadaszewski/freebsd-src/compare/main...main-cherry= -pick-tpm-support-in-stand > > > Kind regards, > > -- > Stanislaw > > On Sat, 27 Nov 2021 at 18:00, Warner Losh wrote: > > > > > > > > On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski wrote: > >> > >> Dear All, > >> > >> Could you please guide me so that we can together integrate > >> the following piece of work into the FreeBSD base system? > >> Thank you for your time and consideration. > > > > > > See below for some advice. > > > >> I have created the following bundle of work [1]. The referenced > >> patch implements on top of releng/13.0, the support for TPM2 > >> in the EFI bootloader and in the kernel in order to allow for > >> storage and retrievel of a GELI passphrase in a TPM2 module, > >> secured with a PCR policy. > >> > >> The way the bootloader behavior is modified is the following: > >> > >> 1) before calling efipart_inithandles() an attempt to retrieve the > >> passphrase from a TPM2 module might be performed - > >> how this is achieved is described later on. > >> 2) if a passphrase is indeed retrieved, then after determining > >> currdev, the currdev is checked for the presence of a > >> /.passphrase_marker file which must contain the same passphrase > >> as retrieved from the TPM. This is supposed to ensure that we > >> do not end up booting an environment not on the device we just > >> unlocked with the passphrase. > >> 3a) If all is go, the autoboot_delay is set to -1 in order to prevent > >> any interaction and continue the boot process of the "safe" environmen= t, > >> a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set > >> to the passphrase from TPM in order for kernel use later, as well as a > >> kern.geom.eli.passphrase.from_tpm2.was_retrieved'=3D'1' variable. > >> 3b) If the passphrase marker does not match, the bootloader cleans up > >> GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits. > > > > > > I worry about information disclosure having the pass phrase available o= n the running system with this setup. Can you explain why that design point= was selected? Usually there is something signed with a private key that th= e public key can be used to verify instead of a direct comparison like this= to prevent disclosure of key material. I've not looked at the code yet, so= it may already do this... > > > >> The way the kernel behavior is modified is the following: > >> > >> 1) In init_main.c, after vfs_mountroot() a check is added > >> 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not > >> set to 1, then we do nothing and continue the boot process > >> 2b) If the was_retrieved variable is set to '1' then we check for the > >> same passphrase marker as the bootloader, its content compared > >> against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' > >> variable. > >> 3a) If all is go, the passphrase variable is unset and the boot proces= s > >> continues, > >> 3c) If the passphrase marker does not match, we panic. > > > > > > I'm sure that main_init should not know about geom or geli. This is usu= ally done with a handler of some sort so the mountroot code can just call t= he generic handler. Can your code be restructured such that this is possibl= e? The reason I ask is that ZFS supports encryption too and it would be ni= ce to use that instead of geli. > > > >> The configuration of the bootloader for this procedure looks the follo= wing: > >> > >> 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex > >> to contain the TPM2 NV Index we store our passphrase in, e.g. 0x100000= 1 > >> 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr > >> to contain the PCR policy used to secure the passphrase, e.g. > >> sha256:0,2,4,7 > >> 3a) If both are set, the bootloader will attempt to retrieve the passp= hrase > >> and behave in the modified way described above > >> 3b) Otherwise, it behaves as the vanilla version and will ask for GELI > >> passphrases if necessary > >> > >> The configuration of the TPM and the passphrase marker looks the follo= wing: > >> > >> 1) echo -n "passphrase" >/.passphrase_marker > >> 2) chmod 600 /.passphrase_marker > >> 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7 > >> 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L > >> policy.digest -A "policyread|policywrite" > >> 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,2,= 4,7 > >> > >> [1] https://github.com/sadaszewski/freebsd-src/compare/releng/13.0...t= pm-support-in-stand > > > > > > This sounds cool. Any chance you can rebase this to the tip of the main= branch? All code goes into FreeBSD that way and 13.0 is about a year old a= lready. > > > > Thanks for sharing this. Despite some reservations expressed above, I t= hink this has potential to be quite cool. > > > > Warner > > > >> > >> Kind regards, From nobody Sun Nov 28 09:16:25 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0F3E718B007C for ; Sun, 28 Nov 2021 09:16:30 +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 4J22sn58NQz3Bym; Sun, 28 Nov 2021 09:16:29 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f2e:2500:f0fa:80ce:6608:8313] (p200300cd5f2e2500f0fa80ce66088313.dip0.t-ipconnect.de [IPv6:2003:cd:5f2e:2500:f0fa:80ce:6608:8313]) (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 4049AC014; Sun, 28 Nov 2021 09:16:29 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: Date: Sun, 28 Nov 2021 10:16:25 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Does not appear to be (too) malicious ... Content-Language: en-US To: freebsd-hackers References: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------jJawxrU5A1eSOwo2T9I0TDz1" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638090989; 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=D9VjLFSEvav7TqSyj8Kp/2Gx+Zx9zwRavxYhBIBRr8M=; b=G/WNu5qxu1jgVaqV7MV7cyAHjD5SYxLwZ0ALBGktPUn5igY0nT8lftdQ35P+tyaSay+lm/ /fJaP7JZ7taoRiYQ28d9eAFUtAHXx6g7GQ0twLTdGzDOX3eSu3cqv9Loc06oO+n/850F4/ s2WThO9KB8+6Ys1U3v7JIqcAD3YXj5EeKGciSNa8kU3Ptuvs4PqDyAYPUG9tbiAR702Qr2 sWIPOLpsbQvH5dopGCyeR8zsH881VjhFoF6W5i3D1Pvt516r19RCgslNHZDWvgZ+X/ypd5 XLRWIn78/2xFfBp699ZBlulysQPJl1TVWgokyuk0bKTsNrJIvrEasi1G7gXB2g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638090989; a=rsa-sha256; cv=none; b=TgmzVUeGdXlYwuLeGC8yqCk7UX5ny9l2OZT38tul9+QpDonScy5KH3dRnvGxL8MV4QYd/F ICApAXJXwOpCA3waBZtQ7wJwwOYLAsrGde4qZRrM1O1UQs1USpVo/wxo/Vm0flwp9xb6vB gZodF1TT5hE3L9QHYDNOrQxiqZ5iTn4I8jEc5ModSoT1OUxIA9DI8F5JjJbwZ/Zsik82O/ fzNrXlxvgaR1mR7RH3DIBO0AOoG6JtKcMTDHGA62mt491XiFSc0L2GaT+HJVS3neHI3Cp8 TcT4kh5ceSKLtNO0rRDFNpjxtBIKRMqI6Kmbz/lxccboMt4mkMg/B6jY6YmXWQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------jJawxrU5A1eSOwo2T9I0TDz1 Content-Type: multipart/mixed; boundary="------------r89bkpw8tJuQV0dww9P5PQpt"; protected-headers="v1" From: Stefan Esser To: freebsd-hackers Message-ID: Subject: Does not appear to be (too) malicious ... References: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> In-Reply-To: --------------r89bkpw8tJuQV0dww9P5PQpt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 28.11.21 um 02:06 schrieb Mario Lobo: > On Sat, Nov 27, 2021, 20:27 George Mitchell wr= ote: >=20 >> On 11/27/21 17:40, Obsto Clades via freebsd-hackers wrote: >>> I hacked on the FreeBSD source code to produce a version of the OS th= at >>> cannot be remotely hacked. Before you tell me that is impossible, I >>> have an answer to that response on my FAQ page. >>> >>> If you are interested in checking out my OS, you can find instruction= s >>> on my site's home page: https://obstoclades.tech/ >>> >>> I invite you to check it out. >>> >> >> Hmm, my mother told me never to click on links in strange emails ... >> -- George >> >=20 > curl http://obstoclades.tech [...] >

Connection denied by Geolocation Setting.

>

Reason: Blocked country:

>

The connection was denied because this country is blocked in = the > Geolocation settings.

>

Please contact your administrator for assistance.

> >
WatchGuard Technologies, Inc.
> > > $ fetch --no-verify-peer -v -o /tmp/obstoclades.html https://obstoclades.= tech resolving server address: obstoclades.tech:443 SSL options: 82004854 Verify hostname TLSv1.3 connection established using TLS_AES_256_GCM_SHA384 Certificate subject: /CN=3Dobstoclades.tech Certificate issuer: /C=3DUS/O=3DLet's Encrypt/CN=3DR3 requesting https://obstoclades.tech/ fetch: https://obstoclades.tech: size of remote file is not known local size / mtime: 34916 / 1638088913 /tmp/obstoclades.html 34 kB 181 kBps 00s There is actual contents in this file, and it does not seem to contain an= y malicious parts. It starts with: Security is a Joke And besides the jquery.min.js dowloaded from ajax.googleapis.com only the= following short and apparently benign script is downloaded as obstoclades= =2Ejs: /* * File: obstoclades.js * Copyright (c) 2017 Obsto Clades, LLC */ $(document).ready(function() { var $content =3D $(".content").hide(); $(".img").on("click", function (e) { $(this).parent().parent().toggleClass("expanded"); var ttt =3D $(this).parent().children(".tooltiptext"); if ($(this).parent().parent().hasClass("expanded")) { ttt.replaceWith("Click to close"); } else { ttt.replaceWith("Click to open"); } $(this).parent().parent().next().slideToggle(); }); var textHeight =3D $("#left-side-header-text").height(); $("#old_english_sheepdog").height(textHeight).width(textHeight); $("#button").click(function() { $("#contactus-form").submit(); }) }); He invites to attack his server using a SSH login with provided credentia= ls, and offers US$1000 for any successful modification of the test server. Se= e the following video, which shows that root on the consonle and root via s= u in the SSH session get quite different environments: https://obstoclades.tech/video/demo-video.mp4 This looks like a setup with lots of restrictions applied, probably noexe= c mounts of temporary file systems and the like, possibly jails and/or MAC restrictions. He thinks that an embedded system configured that way could not be attack= ed, but explains that his concept is limited to e.g. IoT use cases (what he calls "single-purpose computer system"). Anyway, I could not find any malicious content on the web server. Accessi= ng with a SSH session (obviously configured to not allow backwards tunneling= ) should also not be too dangerous from a dumb terminal (but beware of esca= pe sequence attacks possible with ANSI terminals, e.g. reprogramming of func= tion keys with "ESC[code;string;...p"). It looks to me like kind of a honeypot setup gathering attack attempts to= see whether a throw-away system can withstand them. All attack attempts a= re logged, either to learn how to perform them, or to actually improve the security of his protection concept in case of a successful break-in. Regards, STefan --------------r89bkpw8tJuQV0dww9P5PQpt-- --------------jJawxrU5A1eSOwo2T9I0TDz1 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGjSOkFAwAAAAAACgkQR+u171r99UQ3 Wwf8Dk21TWeuXp++0S2nN41g9aATwGvAdujX9WXQLRTEVYPufzLULK3uJcexbzlBIS4/oOrcVaMD A0PpJx5XBd7GhnijkfPGal1fE3D/rJmnFwE70U8PYbc/9YsR8yVZcZIoLixDZtu5/dqEhhkRRk9K WkCNg8+l/I/eUEA1UpU1xBfgw2GOQC9rlCMdxqVWodS+yUP/V3w43sOPXbOwdxOlwBsZaBABZhXD mw+v7t/ocQeNGmd1575sTKuNds+GETIrrDfUrVulhrYMCbgzhdQZ5yZRNWNhzNudu6CD9z+QEqRS tHdNxm5EUUtBL4QnOxUY0UpZ3t7ZUceKFFGRIhJ/QA== =KTD3 -----END PGP SIGNATURE----- --------------jJawxrU5A1eSOwo2T9I0TDz1-- From nobody Sun Nov 28 10:13:25 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 212D218A3CA1 for ; Sun, 28 Nov 2021 10:14:04 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J248D09S4z3kNJ; Sun, 28 Nov 2021 10:14:04 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ua1-x92e.google.com with SMTP id az37so27728009uab.13; Sun, 28 Nov 2021 02:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JAt13WBkO/GBDVVoeQpSIfK2uSI/AIPHIoabqSnEGHQ=; b=M7Wjle0+Ke3aSEj/B6OWcj11fuubIbT2CR8FFxqBab1ysyaUQzPjdJAr/UqQO62hCn 4bnEVoB3N/LmcYiAk09fVhXtv7a+bbjZ5oIzChLUbXbdvJtxFier8+tkMAWV2639UF9B mvjOJs9EePdDbQab+gx8kliS9c8Ajh75ScKKg20V3ZR+gbyAxZpWK8nCLqOygaYxCkSo yt1NcdWphEVdSdMN6k3tAFsdzWH4NxBrnB8cwxq0HiiKenfieo8hfaHv1mBbNtbj0wgf DTyTzXRGgyJ6hkASQtRw48UF/LHLHpbfdV7gD5HbIwNhc7Bky4EJV6KwdyCv3WE2xYJ8 /2kA== 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=JAt13WBkO/GBDVVoeQpSIfK2uSI/AIPHIoabqSnEGHQ=; b=3LVvsJyJexWYQcYRPHwAR1YSGtNNvtSxdMdF3EzoRVvOGcQC0pEQyBavVA9yHrxfVZ SgF5yJ9u6UsUIams/va8azHEclfXUtaHWsLgHbokR4mk3z49bPSVA/nfCYLAiyDTVZ0F ZRTJVwRiOAjpgZrto1CPn0rpGFPVtn1uXyS+5xCk8+fLl0r91igveJRlQ3168uJKcE/K rANrd5jBN7hVSfyZ48jx+7/QR9/iauZSvfOWAY3uDBLEYxB2SKl/qZrF6paUHOXp3Qqh Cd7UjCXfx17WJGzp7DKx5pWcfK7ypWk+VhZnEdos0LVd95yco2u2BRVWwpvH8EfGIChh VVNA== X-Gm-Message-State: AOAM530RP65uKNpfHKTZ7A0lliZNmX8hcfTBCfU249Elhylt5NEjat1M TCb+d7T/zIgD+FXslzjjHQzWVnl2vkvbZ0wBvc46BxZU+78= X-Google-Smtp-Source: ABdhPJzjK+dxPdtwvBeJWAdOY6wiRkfjRdkrITOVSD/06c1ww48n82GqCqID86vECs2mN5rANxVDvmaqL+hwcVo1rJc= X-Received: by 2002:a67:c79a:: with SMTP id t26mr26994344vsk.37.1638094443362; Sun, 28 Nov 2021 02:14:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> In-Reply-To: From: Mehmet Erol Sanliturk Date: Sun, 28 Nov 2021 13:13:25 +0300 Message-ID: Subject: Re: Does not appear to be (too) malicious ... To: Stefan Esser Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="00000000000067be0605d1d695b4" X-Rspamd-Queue-Id: 4J248D09S4z3kNJ 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 --00000000000067be0605d1d695b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 28, 2021 at 12:17 PM Stefan Esser wrote: > Am 28.11.21 um 02:06 schrieb Mario Lobo: > > On Sat, Nov 27, 2021, 20:27 George Mitchell > wrote: > > > >> On 11/27/21 17:40, Obsto Clades via freebsd-hackers wrote: > >>> I hacked on the FreeBSD source code to produce a version of the OS th= at > >>> cannot be remotely hacked. Before you tell me that is impossible, I > >>> have an answer to that response on my FAQ page. > >>> > >>> If you are interested in checking out my OS, you can find instruction= s > >>> on my site's home page: https://obstoclades.tech/ > >>> > >>> I invite you to check it out. > >>> > >> > >> Hmm, my mother told me never to click on links in strange emails ... > >> -- George > >> > > > > curl http://obstoclades.tech > [...] > >

Connection denied by Geolocation Setting.

> >

Reason: Blocked country: >

> >

The connection was denied because this country is blocked in > the > > Geolocation settings.

> >

Please contact your administrator for assistance.

> > > >
WatchGuard Technologies, Inc.
> > > > > > > > $ fetch --no-verify-peer -v -o /tmp/obstoclades.html > https://obstoclades.tech > resolving server address: obstoclades.tech:443 > SSL options: 82004854 > Verify hostname > TLSv1.3 connection established using TLS_AES_256_GCM_SHA384 > Certificate subject: /CN=3Dobstoclades.tech > Certificate issuer: /C=3DUS/O=3DLet's Encrypt/CN=3DR3 > requesting https://obstoclades.tech/ > fetch: https://obstoclades.tech: size of remote file is not known > local size / mtime: 34916 / 1638088913 > /tmp/obstoclades.html 34 kB 181 kBps 00s > > There is actual contents in this file, and it does not seem to contain an= y > malicious parts. It starts with: > > > > > > > Security is a Joke > content=3D"This demonstrates a modified BSD Operating System > designed > to prevent remote hacking of single-purpose computer systems."> > > > > > > > And besides the jquery.min.js dowloaded from ajax.googleapis.com only the > following short and apparently benign script is downloaded as > obstoclades.js: > > /* > * File: obstoclades.js > * Copyright (c) 2017 Obsto Clades, LLC > */ > > $(document).ready(function() > { > var $content =3D $(".content").hide(); > $(".img").on("click", function (e) > { > $(this).parent().parent().toggleClass("expanded"); > var ttt =3D $(this).parent().children(".tooltiptext"); > if ($(this).parent().parent().hasClass("expanded")) > { > ttt.replaceWith("Click to > close"); > } > else > { > ttt.replaceWith("Click to > open"); > } > $(this).parent().parent().next().slideToggle(); > }); > var textHeight =3D $("#left-side-header-text").height(); > $("#old_english_sheepdog").height(textHeight).width(textHeight); > $("#button").click(function() > { > $("#contactus-form").submit(); > }) > }); > > He invites to attack his server using a SSH login with provided > credentials, > and offers US$1000 for any successful modification of the test server. Se= e > the following video, which shows that root on the consonle and root via s= u > in the SSH session get quite different environments: > > https://obstoclades.tech/video/demo-video.mp4 > > This looks like a setup with lots of restrictions applied, probably noexe= c > mounts of temporary file systems and the like, possibly jails and/or MAC > restrictions. > > He thinks that an embedded system configured that way could not be > attacked, > but explains that his concept is limited to e.g. IoT use cases (what he > calls "single-purpose computer system"). > > Anyway, I could not find any malicious content on the web server. Accessi= ng > with a SSH session (obviously configured to not allow backwards tunneling= ) > should also not be too dangerous from a dumb terminal (but beware of esca= pe > sequence attacks possible with ANSI terminals, e.g. reprogramming of > function > keys with "ESC[code;string;...p"). > > It looks to me like kind of a honeypot setup gathering attack attempts to > see whether a throw-away system can withstand them. All attack attempts a= re > logged, either to learn how to perform them, or to actually improve the > security of his protection concept in case of a successful break-in. > > Regards, STefan > The message above is really a very good one because of its information content . As a response to my message in the following link https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000515.htm= l Obsto Clades asked me with a private message , approximately , " I am connecting to the web site ... without any such message . Do you have more information ? " . I replied , "No ." When the following link ( please notice that it is http , not https ) http://obstoclades.tech/ the response of Firefox ( 57.0.1) is the following : -------------------------------------------------------- Connection denied by Geolocation Setting. * Reason: * Blocked country: The connection was denied because this country is blocked in the Geolocation settings. Please contact your administrator for assistance. WatchGuard Technologies, Inc. -------------------------------------------------------- When the following link ( please notice that it is https , not http ) https://obstoclades.tech/video/demo-video.mp4 the response of Firefox ( 57.0.1) is the following : -------------------------------------------------------- Your connection is not secure The owner of obstoclades.tech has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website. Learn more=E2=80=A6 Report errors like this to help Mozilla identify and block malicious sites -------------------------------------------------------- In "Learn more ..." the linked page is https://support.mozilla.org/en-US/kb/error-codes-secure-websites?as=3Du&utm= _source=3Dinproduct How to troubleshoot security error codes on secure websites There are 2 knobs not copyable : (1) Go back (2) Advanced When "Advanced" is clicked ( there is no linked page ) , the following message is displayed : -------------------------------------------------------- obstoclades.tech uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is not valid for the name obstoclades.tech. Error code: SEC_ERROR_UNKNOWN_ISSUER -------------------------------------------------------- With a knob ( without any linked page ) as follows : "Add Exception ..." with an dialog pane display to add an exception for that page ( which I did not added because website owner may correct her/his certificate or configuration of the website ) . With my best wishes for all , Mehmet Erol Sanliturk --00000000000067be0605d1d695b4-- From nobody Sun Nov 28 11:19:52 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0F7B218A3DDC for ; Sun, 28 Nov 2021 11:20:36 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4J25cz6T9Hz4Yg0 for ; Sun, 28 Nov 2021 11:20:35 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: by mail-ed1-x535.google.com with SMTP id e3so59384620edu.4 for ; Sun, 28 Nov 2021 03:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TatG01oWToQNdy7zkwkLuFJmzhtSur2UVsRnwpC2d5Y=; b=Vqt6crb1ce9bBroFNlJ5h2Nliq+CTRCkIqHHMwsL+/1u2DBprp2TvBPIAxVhWeTJLl ehr9QmYzGgbOrJEFA1VknXAMjYVGRWvKOvccLZuy8DBiSF5uTbyyrL1+eO7yqmo1fOoy WXIkabofT5DDhuso4TTOquC8YTlusnQCATFqtcEiQbFCpf9hQIcCaiVu7RH+BdscAsro NHfkRBklXIlVVJdJ2g8X4uZTYBvkuY4/kwQiTMeSverZ9ZNCZyhIBmzgyGmjZBcJHlDy XQnhorCINYP6SaedAiWB0ZzCj7LdRkTze4eu7keh16kOtSnpCa8wo1HdkZUXp85JQ58r GaEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TatG01oWToQNdy7zkwkLuFJmzhtSur2UVsRnwpC2d5Y=; b=nt8D7tJbOo5YvCJDyegcKnLssNp3E5xn6VGB8KJpWsO9Hg/71+c0QY4+ybI36TS4Ei jENqBYrvCTT0/voGEkpmh/GkTUlFvDDZcnPupw68272ptKTFz5lAdIoiDYcKH4FhJvVf VUmkZVEIX81zW7uFu2aulToCrZDtZTGqW57q3qSC6L5FEwvZMXljk3QJ6nAfyF6kYEF9 Hqz5TuUpl0N/monpR3+XdDwtJKAI8xt+v5+XOwI7NIDZP1d69uBlDQF2lXmMAvub62en juJPbbx43Ou3opHQInBV7xSgPOnSCCOSr9WCwL+K4OPX8psLzrUUPOPw351tLHHoRpsB M1Fw== X-Gm-Message-State: AOAM530Yp8S9V8Pm6xv2BqcxZc94tSRabeE6aToG8Ik8DW/O6AOuwXI8 MZ1y/A7wjfG5iNmKD6s0UDT8a56WnSpgn/goUILm7VPl X-Google-Smtp-Source: ABdhPJyOmrwSG1lKynwgI+Lvxfj0hbws6WEx9N1uwgo2y4xdWzGmrzwnFu79mIjOR1KNqJd0J+1s+DMGhjEs0DREaRo= X-Received: by 2002:a17:906:d152:: with SMTP id br18mr51044848ejb.287.1638098429111; Sun, 28 Nov 2021 03:20:29 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Stanislaw Adaszewski Date: Sun, 28 Nov 2021 12:19:52 +0100 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Warner Losh Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J25cz6T9Hz4Yg0 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: N I have made further modifications: 1) As per suggestion - use SYSINIT() and EVENTHANDLER_REGISTER() in a separate file (tpm2cpm.c) rather than hardcoding in init_main.c. 2) Make the functionality configurable / optional both for the kernel (option TPM2_PASSPHRASE) and the bootloader (WITH_LOADER_TPM2_PASSPHRASE). The one for the bootloader is enabled by default and the one for the kernel is enabled by default in the GENERIC amd64 kernel. Best regards, -- Stanislaw On Sat, 27 Nov 2021 at 21:35, Stanislaw Adaszewski wrote: > > Hi Warner, > > > Thanks a lot for the quick reaction - that helps. Accordingly, > I have taken several actions (below). If you have any more tips > how to push this forward, please let me know. Like I don't know > is there a person formally responsible for this kind of > contributions? Let's say when you are happy with the general > architecture of the solution and the quality of the code > (it still requires some polishing) - is that enough to pull > the changes into the codebase? How does that work? > Thank you in advance! > > > 1. I have rebased my changeset on top of the tip of the > FreeBSD's main branch [1] > > > 2. I have changed the /.passphrase_marker convention to hold > (instead of the passphrase) a human-readable lower-case digest > of SHA256(salt | passphrase) where salt is a new (optional) > parameter which can be passed using another EFI variable: > KernGeomEliPassphraseFromTpm2Salt. > > I think it is more for the peace of mind than anything else, > as anyone having access to /.passphrase_marker would normally > have to be the root user. Nevertheless it is perhaps nicer not > to keep raw passphrases laying around in files. > > We still pass the passphrase to the kernel via a kernel variable > kern.geom.eli.passphrase.from_tpm2.passphrase which is unset > before the system becomes interactive. I could be easily > passing the hash computed by the bootloader instead - what do > you think? > > One thing to keep in mind is that another kernel variable - > kern.geom.eli.passphrase has been passed around like this > as well and it is being unset precisely in init_main.c. > > But even more importantly, one has to keep in mind that > geli_export_key_buffer() passes all GELI keys to the kernel > anyway, so access to the encrypted drives is already possible > by that alone. Not to mention that the root user can simply > read the driver's master key with a simple geli show. > > > 3) As an explanation, also to @Ka Ho Ng, the /.passphrase_marker > serves only as a tag to allow to reliably pair a boot filesystem > to the keyphrase retrieved from the TPM. If we were to just > retrieve the passphrase and pass it to any boot environment then > one would simply boot another OS with another root password and > could read all our secrets. The same goes for the root filesystem > that is mounted in turn by the kernel. If one would for example > remove the boot drive - that would cause the kernel to drop out > to interactive mountfrom> prompt and then one could for example > boot from another drive. That is unacceptable. Kernel is by default > very "boot happy" - it tries really hard to boot SOMETHING rather > than accept a strict specification of what is allowed to boot. > > > 4) The code is fully functional and I have tested it quite a bit > on a Zotac CI622 mini-PC with the latest BIOS update which enables > the TPM functionality on the Intel 10110U process in there. If you > have a TPM-capable BIOS and CPU, I would encourage you to try, like > this you will understand better how it works and that the design is > necessary like it is with the /.passphrase_marker. I am not 100% sure > if there are no ways left to fool the system to boot or run some > arbitrary code. Such attacks would generally consist of causing some > kind of errors on the "trusted" UFS-on-GELI or ZFS-on-GELI systems and > making the system drop out into some kind of interactive prompts. I > hope that does not happen. For example if one removes the drive during in= it. > I would certainly expect that no process drops out to interactive prompts > on a system with a root password set bit this kind of scares is > a tradeoff of not using full VERIEXEC. It is however very convenient > to say - just trust everything on the XXX-on-GELI since this was encrypte= d > and therefore tampering-proof. More tests are necessary but also - VERIEX= EC > can be enabled in addition to that to ensure that such weird scenarios do= not > happen. > > > 5) @Ka Ho Ng what you said is taking place clearly, the code relies on a = PCR > policy of user's choice and uses that to read the passphrase. > > > 6) Regarding ZFS encryption I am not sure if that is supported in the EFI > bootloader - at first glance I would say that it isn't. With that said, > the code can be used to further modify the loader to read any kind of > values stored in the TPM and put them in kernel variables for later use > in the boot process. Just a big WARNING, kenv seems to let even lusers to= read > the variables. So whatever one would do with them, it would have to be do= ne > quickly and the variables would need to be discarded before letting > the lusers log in. > > > [1] https://github.com/sadaszewski/freebsd-src/compare/main...main-cherry= -pick-tpm-support-in-stand > > > Kind regards, > > -- > Stanislaw > > On Sat, 27 Nov 2021 at 18:00, Warner Losh wrote: > > > > > > > > On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski wrote: > >> > >> Dear All, > >> > >> Could you please guide me so that we can together integrate > >> the following piece of work into the FreeBSD base system? > >> Thank you for your time and consideration. > > > > > > See below for some advice. > > > >> I have created the following bundle of work [1]. The referenced > >> patch implements on top of releng/13.0, the support for TPM2 > >> in the EFI bootloader and in the kernel in order to allow for > >> storage and retrievel of a GELI passphrase in a TPM2 module, > >> secured with a PCR policy. > >> > >> The way the bootloader behavior is modified is the following: > >> > >> 1) before calling efipart_inithandles() an attempt to retrieve the > >> passphrase from a TPM2 module might be performed - > >> how this is achieved is described later on. > >> 2) if a passphrase is indeed retrieved, then after determining > >> currdev, the currdev is checked for the presence of a > >> /.passphrase_marker file which must contain the same passphrase > >> as retrieved from the TPM. This is supposed to ensure that we > >> do not end up booting an environment not on the device we just > >> unlocked with the passphrase. > >> 3a) If all is go, the autoboot_delay is set to -1 in order to prevent > >> any interaction and continue the boot process of the "safe" environmen= t, > >> a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set > >> to the passphrase from TPM in order for kernel use later, as well as a > >> kern.geom.eli.passphrase.from_tpm2.was_retrieved'=3D'1' variable. > >> 3b) If the passphrase marker does not match, the bootloader cleans up > >> GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits. > > > > > > I worry about information disclosure having the pass phrase available o= n the running system with this setup. Can you explain why that design point= was selected? Usually there is something signed with a private key that th= e public key can be used to verify instead of a direct comparison like this= to prevent disclosure of key material. I've not looked at the code yet, so= it may already do this... > > > >> The way the kernel behavior is modified is the following: > >> > >> 1) In init_main.c, after vfs_mountroot() a check is added > >> 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not > >> set to 1, then we do nothing and continue the boot process > >> 2b) If the was_retrieved variable is set to '1' then we check for the > >> same passphrase marker as the bootloader, its content compared > >> against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' > >> variable. > >> 3a) If all is go, the passphrase variable is unset and the boot proces= s > >> continues, > >> 3c) If the passphrase marker does not match, we panic. > > > > > > I'm sure that main_init should not know about geom or geli. This is usu= ally done with a handler of some sort so the mountroot code can just call t= he generic handler. Can your code be restructured such that this is possibl= e? The reason I ask is that ZFS supports encryption too and it would be ni= ce to use that instead of geli. > > > >> The configuration of the bootloader for this procedure looks the follo= wing: > >> > >> 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex > >> to contain the TPM2 NV Index we store our passphrase in, e.g. 0x100000= 1 > >> 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr > >> to contain the PCR policy used to secure the passphrase, e.g. > >> sha256:0,2,4,7 > >> 3a) If both are set, the bootloader will attempt to retrieve the passp= hrase > >> and behave in the modified way described above > >> 3b) Otherwise, it behaves as the vanilla version and will ask for GELI > >> passphrases if necessary > >> > >> The configuration of the TPM and the passphrase marker looks the follo= wing: > >> > >> 1) echo -n "passphrase" >/.passphrase_marker > >> 2) chmod 600 /.passphrase_marker > >> 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7 > >> 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L > >> policy.digest -A "policyread|policywrite" > >> 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,2,= 4,7 > >> > >> [1] https://github.com/sadaszewski/freebsd-src/compare/releng/13.0...t= pm-support-in-stand > > > > > > This sounds cool. Any chance you can rebase this to the tip of the main= branch? All code goes into FreeBSD that way and 13.0 is about a year old a= lready. > > > > Thanks for sharing this. Despite some reservations expressed above, I t= hink this has potential to be quite cool. > > > > Warner > > > >> > >> Kind regards, From nobody Sun Nov 28 12:11:57 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0B13E18BE78C for ; Sun, 28 Nov 2021 12:12:18 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 4J26md6bPWz4tb2; Sun, 28 Nov 2021 12:12:17 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-pj1-x1029.google.com with SMTP id j6-20020a17090a588600b001a78a5ce46aso13194176pji.0; Sun, 28 Nov 2021 04:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=KzMGLb4FC1dHNRuww501aUzqonTDCUwJeC7Q9Z2BRzU=; b=Qd1AJSEVxW3U4kHZ+20mSzzqdtTabJyc0amlV3CyEPatoF+at2ZhF6Frbt7eTaXZIS 01fAk+CfCDfFEQjMAiMHT1JUqe/b+85cZWXlDmQN2CbnjjvVcRlmeWnt9vKli0FNr2qg DpCUtK+RTLCBq3EegXEupJ1zHTBRAt9zf0G6n4oOcc9sxs4d7CRK6PVpON4kyJ3HxJ2v JzhURKRQdSWDjCsWaMDvP8uJlMssiwouXcdGFjMmsKrNTs4pQ3svQXZGvXU1PMtKvRZr dOmCpgQW7rEvR+IsrT/Xh2KwFZtt4wFMNq+ORcWC0/dU1RE4UBgKRD5Wdv3vCPkhCwEy D/yg== 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:reply-to :from:date:message-id:subject:to:cc; bh=KzMGLb4FC1dHNRuww501aUzqonTDCUwJeC7Q9Z2BRzU=; b=d3Wku4CxrdXq36KgmsuIVyrpNcunRkbrjljT/2WQS1RYDeQ3hb2Pdc8siwNB81O6X5 nC6FWqIXAGXxXIej+73ykVNL27cZvP0Fmp+Jp5R71OzucXQwYE+JrNUlNWwGKkkZJi75 MCB8dyrssdDtEM8uw0qRgejB8o/lv0QHg77272r3GLvI5TJ5M04TMNnY3byBXgx+FzYq vgh6sJ3AJD+/2gge17zhgfLPQYBpuaxGfUt1R1BqRmGCuCHPyO0vRM+A5m1sZA+RNayB U5Dmeg3BlEZMF9xvUcjsVJO5SXVR7rSTW6zj4EqTAVpGhNHmGkviJBCUm7VrGLlpvHw2 sscg== X-Gm-Message-State: AOAM532l7ZpKxSkP4700fo1wOZ3UeNK3ufms5XaabIHtK24jd0DooLGd 8EpvKcFXCfW+t58wNi1RcwSV1iocyG05QWa//48O/fqf1Xc= X-Google-Smtp-Source: ABdhPJz8GuSEs4iq5xkMgpTfCmHPw4kBft6kuVpigF08AzqlF04R0ypIjdCOkXUUZ/pBeysUsqc3oLKCe566BAQyR50= X-Received: by 2002:a17:90b:4c4d:: with SMTP id np13mr31059565pjb.233.1638101530675; Sun, 28 Nov 2021 04:12:10 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> In-Reply-To: Reply-To: araujo@freebsd.org From: Marcelo Araujo Date: Sun, 28 Nov 2021 20:11:57 +0800 Message-ID: Subject: Re: Does not appear to be (too) malicious ... To: Mehmet Erol Sanliturk Cc: Stefan Esser , freebsd-hackers Content-Type: multipart/alternative; boundary="000000000000d78b7405d1d83b91" X-Rspamd-Queue-Id: 4J26md6bPWz4tb2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000d78b7405d1d83b91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable you all have a lot of free time. On Sun, Nov 28, 2021, 18:14 Mehmet Erol Sanliturk wrote: > On Sun, Nov 28, 2021 at 12:17 PM Stefan Esser wrote: > > > Am 28.11.21 um 02:06 schrieb Mario Lobo: > > > On Sat, Nov 27, 2021, 20:27 George Mitchell > > wrote: > > > > > >> On 11/27/21 17:40, Obsto Clades via freebsd-hackers wrote: > > >>> I hacked on the FreeBSD source code to produce a version of the OS > that > > >>> cannot be remotely hacked. Before you tell me that is impossible, = I > > >>> have an answer to that response on my FAQ page. > > >>> > > >>> If you are interested in checking out my OS, you can find > instructions > > >>> on my site's home page: https://obstoclades.tech/ > > >>> > > >>> I invite you to check it out. > > >>> > > >> > > >> Hmm, my mother told me never to click on links in strange emails ... > > >> -- George > > >> > > > > > > curl http://obstoclades.tech > > [...] > > >

Connection denied by Geolocation Setting.

> > >

Reason: Blocked country: > >

> > >

The connection was denied because this country is blocked i= n > > the > > > Geolocation settings.

> > >

Please contact your administrator for assistance.

> > > > > >
WatchGuard Technologies, Inc.
> > > > > > > > > > > > > $ fetch --no-verify-peer -v -o /tmp/obstoclades.html > > https://obstoclades.tech > > resolving server address: obstoclades.tech:443 > > SSL options: 82004854 > > Verify hostname > > TLSv1.3 connection established using TLS_AES_256_GCM_SHA384 > > Certificate subject: /CN=3Dobstoclades.tech > > Certificate issuer: /C=3DUS/O=3DLet's Encrypt/CN=3DR3 > > requesting https://obstoclades.tech/ > > fetch: https://obstoclades.tech: size of remote file is not known > > local size / mtime: 34916 / 1638088913 > > /tmp/obstoclades.html 34 kB 181 kBps 00= s > > > > There is actual contents in this file, and it does not seem to contain > any > > malicious parts. It starts with: > > > > > > > > > > > > > > Security is a Joke > > > content=3D"This demonstrates a modified BSD Operating System > > designed > > to prevent remote hacking of single-purpose computer systems."> > > > > > > > > > > > > > > And besides the jquery.min.js dowloaded from ajax.googleapis.com only > the > > following short and apparently benign script is downloaded as > > obstoclades.js: > > > > /* > > * File: obstoclades.js > > * Copyright (c) 2017 Obsto Clades, LLC > > */ > > > > $(document).ready(function() > > { > > var $content =3D $(".content").hide(); > > $(".img").on("click", function (e) > > { > > $(this).parent().parent().toggleClass("expanded"); > > var ttt =3D $(this).parent().children(".tooltiptext"); > > if ($(this).parent().parent().hasClass("expanded")) > > { > > ttt.replaceWith("Click to > > close"); > > } > > else > > { > > ttt.replaceWith("Click to > > open"); > > } > > $(this).parent().parent().next().slideToggle(); > > }); > > var textHeight =3D $("#left-side-header-text").height(); > > $("#old_english_sheepdog").height(textHeight).width(textHeight); > > $("#button").click(function() > > { > > $("#contactus-form").submit(); > > }) > > }); > > > > He invites to attack his server using a SSH login with provided > > credentials, > > and offers US$1000 for any successful modification of the test server. > See > > the following video, which shows that root on the consonle and root via > su > > in the SSH session get quite different environments: > > > > https://obstoclades.tech/video/demo-video.mp4 > > > > This looks like a setup with lots of restrictions applied, probably > noexec > > mounts of temporary file systems and the like, possibly jails and/or MA= C > > restrictions. > > > > He thinks that an embedded system configured that way could not be > > attacked, > > but explains that his concept is limited to e.g. IoT use cases (what he > > calls "single-purpose computer system"). > > > > Anyway, I could not find any malicious content on the web server. > Accessing > > with a SSH session (obviously configured to not allow backwards > tunneling) > > should also not be too dangerous from a dumb terminal (but beware of > escape > > sequence attacks possible with ANSI terminals, e.g. reprogramming of > > function > > keys with "ESC[code;string;...p"). > > > > It looks to me like kind of a honeypot setup gathering attack attempts = to > > see whether a throw-away system can withstand them. All attack attempts > are > > logged, either to learn how to perform them, or to actually improve the > > security of his protection concept in case of a successful break-in. > > > > Regards, STefan > > > > > The message above is really a very good one because of its information > content . > > As a response to my message in the following link > > > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000515.h= tml > > Obsto Clades asked me with a private message , approximately , > > " I am connecting to the web site ... without any such message . > > Do you have more information ? " . > > I replied , "No ." > > > When the following link ( please notice that it is http , not https ) > > > http://obstoclades.tech/ > > > the response of Firefox ( 57.0.1) is the following : > > -------------------------------------------------------- > > Connection denied by Geolocation Setting. > > * Reason: * Blocked country: > > The connection was denied because this country is blocked in the > Geolocation settings. > > Please contact your administrator for assistance. > WatchGuard Technologies, Inc. > > > -------------------------------------------------------- > > > > When the following link ( please notice that it is https , not http ) > > > https://obstoclades.tech/video/demo-video.mp4 > > > the response of Firefox ( 57.0.1) is the following : > > -------------------------------------------------------- > > > Your connection is not secure > > The owner of obstoclades.tech has configured their website improperly. To > protect your information from being stolen, Firefox has not connected to > this website. > > Learn more=E2=80=A6 > > Report errors like this to help Mozilla identify and block malicious site= s > > > > -------------------------------------------------------- > > > In "Learn more ..." > > the linked page is > > > https://support.mozilla.org/en-US/kb/error-codes-secure-websites?as=3Du&u= tm_source=3Dinproduct > How to troubleshoot security error codes on secure websites > > > There are 2 knobs not copyable : > > (1) Go back > > (2) Advanced > > > When "Advanced" is clicked ( there is no linked page ) , > > the following message is displayed : > > > > > -------------------------------------------------------- > > > obstoclades.tech uses an invalid security certificate. > > The certificate is not trusted because it is self-signed. > The certificate is not valid for the name obstoclades.tech. > > Error code: SEC_ERROR_UNKNOWN_ISSUER > > > -------------------------------------------------------- > > > > With a knob ( without any linked page ) as follows : > > > "Add Exception ..." > > > with an dialog pane display to add an exception for that page > > ( which I did not added because website owner may correct her/his > certificate > > or configuration of the website ) . > > > With my best wishes for all , > > > Mehmet Erol Sanliturk > --000000000000d78b7405d1d83b91-- From nobody Sun Nov 28 12:51:02 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2582418AA0AB for ; Sun, 28 Nov 2021 12:51:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J27dW6MFlz3MY8 for ; Sun, 28 Nov 2021 12:51:11 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 1ASCp3Kc084795 for ; Sun, 28 Nov 2021 21:51:03 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 28 Nov 2021 21:51:02 +0900 From: Tomoaki AOKI To: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas Message-Id: <20211128215102.1e75b30b90d79bf0d9163e2c@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J27dW6MFlz3MY8 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [1.79 / 15.00]; FAKE_REPLY(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.07)[0.070]; NEURAL_HAM_LONG(-0.43)[-0.427]; DMARC_NA(0.00)[sakura.ne.jp]; NEURAL_HAM_MEDIUM(-0.26)[-0.257]; 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:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N > On 11/23/2021 9:01 PM, Miroslav Lachman wrote: >> On 23/11/2021 23:41, Joseph Mingrone wrote: >>> Hello FreeBSD community, >>> >>> The Foundation is seeking suggestions for new projects to support. What >>> gaps in the Project are not being addressed by the broader community? >>> >>> You can read about past Foundation-supported projects at >>> https://freebsdfoundation.org/our-work/projects/ and the Foundation's >>> four main areas of focus in the 'Technology Roadmap' article at >>> https://freebsdfoundation.org/blog/technology-roadmap/. >>> >>> Right now we are gathering ideas. We will send out a call for project >>> grant proposals soon. If you prefer to send your project ideas directly >>> to the Foundation, we will be monitoring responses at >>> techteam_at_freebsdfoundation.org. >> >> I would really like to see Foundation sponsored project to bring SMBv2 >> and SMBv3 support in to smbfs in base instead of deprecating smbfs / CIFS. >> >> FreeBSD is the only one widely used operating system lacking support for >> modern SMB / CIFS versions. SMB is still widely used in desktops and >> servers environment for mounting shares between different OSes. >> >> The latest thread from October with this discussion can be found in >> freebsd-current_at_ archive >> https://lists.freebsd.org/archives/freebsd-current/2021-October/000893.html >> And continuing in November >> https://lists.freebsd.org/archives/freebsd-current/2021-November/000915.html >> >> >> Kind regards >> Miroslav Lachman >> > > Ed Maste and I looked at this a bit a few weeks ago, and it seems there > is a version in IllumOS that is based on the old smbfs that is in > FreeBSD, and it might be an "relatively" easy path forward. Just need > someone with the interest, time, and background knowledge to actually > work on it. > > -- > Allan Jude (Re-sent as not yet reached after nearly one day.) +1. Some NAS (and Windoze, too?) already made SMB1 default-off (at least, Synology DSM 6 and 7 has option to re-enable it currently). It's important for me to have newer (ideally, latest) version of SMB/CIFS support on FreeBSD smbfs.ko. But I noticed I'm not enough skilled and having not enough time to port it when I partially looked in Darwin source few years ago. :-( -- Tomoaki AOKI From nobody Sun Nov 28 15:00:48 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6D5D518A8DA6 for ; Sun, 28 Nov 2021 15:01:33 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 4J2BWx2KFsz4l1Q; Sun, 28 Nov 2021 15:01:33 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-vk1-xa2b.google.com with SMTP id s17so9241498vka.5; Sun, 28 Nov 2021 07:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C6vbNk87x7x39iVpUmYIA/BImeiMK9whx/63TzWn9gw=; b=LjJYPFgL5BuGxdsboQbT9j82F+eVBeMZiB22lFg5AioYmE7S8KQQiAul9nDQfm/m/2 XksGPGf4//HlSQScKk6finJbILqB8YmSIh4jjN86nCv7SfKYAF3zgalWOUXL71AFKiph ct3CbySvQL+20ogtt+cG0psR4c9hRgTRUESG5nmil7cy0V8yDeLNgk+QbWtKnYxPBtKG +ee+85YE/3gPxQKp+YOIee/nbA/z1YPyCHwh1NWHxTTtsCDq9ZY+dEGvBIE9erLVkeym ZxB5c8XWV3LvEWLvi9jql1gcxCoQvOPF3JEdRqSvL62meeM/AB9NNzFSxGfD0x90hSub fv5g== 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=C6vbNk87x7x39iVpUmYIA/BImeiMK9whx/63TzWn9gw=; b=ugwVQe3aqsDeDO6YPP/4C0rkjKFgMqPk63AC/Glfig0dlR1c2tnuxmVoRdLniYgHKZ 82Dgiyo1Dqh6nF6ob6m95uyfXxMYHP0hhiJ/TE0c8Fs66xIdDlOuf3djKIWJ5fY62e0g EZ9ZHlJLnQ2yX7lFQhbTPAbjIKJHSNXZmAUdEgpF3SJgJmUEpd+EalMjM1WgpFochu5y QKG8lBPJ2kyarLuXIPr5h7tCyUhXDyScTUcn1YhK88Y2yUV5DScgcAJYvHd1idb0NnB4 ZWl7B+1PdFtqg1PESMymnzSbVcPEHULcg7JKqibIpsz4+ieMgIMsMCJDuG0AWSR7AfDI 0NCw== X-Gm-Message-State: AOAM5320u8YRU78y6W1oPZcULqx3I0N22Rlg65apaDG0LAYhOVEaBIqF eAFvMx5COjGXb2NqoC7eww3i0IK7dxaMOcIFqcrUiH/s0Rc= X-Google-Smtp-Source: ABdhPJwl9v+wS2Wp2Qf5ol2/0m7R0ZX+shNVq+DMeVCIgH2+1gXr/axIxJBDizgCrRCKYnRsOAK9SYqYcgUhABQheak= X-Received: by 2002:a05:6122:16a3:: with SMTP id 35mr30424665vkl.11.1638111686161; Sun, 28 Nov 2021 07:01:26 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> In-Reply-To: From: Mehmet Erol Sanliturk Date: Sun, 28 Nov 2021 18:00:48 +0300 Message-ID: Subject: Re: Does not appear to be (too) malicious ... To: araujo@freebsd.org Cc: Stefan Esser , freebsd-hackers Content-Type: multipart/alternative; boundary="00000000000028040705d1da99c8" X-Rspamd-Queue-Id: 4J2BWx2KFsz4l1Q 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 --00000000000028040705d1da99c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 28, 2021 at 3:12 PM Marcelo Araujo wrote: > you all have a lot of free time. > > Actually "no" . I am retired now and I am not working for anyone , because (1) health conditions , (2) to know too much , no one is liking to see me around her/him with fear "He may become boss instead of me" or "I may be regarded weak when he work in here" ( <--- These are experimental results , not assumptions ) <----- This is absolute nonsense because I never wanted to be a "boss" or "degrader of the people" , but a "scientist" for solving computing problems encountered by the people since 1970 having a root since 1965 . I am still studying very hard up to mostly morning 2.00 to 3.00 . My most important ( let's say it ) "hobby" is to help to the people to solv= e their problems such ( to prepare software to solve research problems such data analysis of PhD theses or more advanced researches , to develop "knowledge system design and management" software , to try to develop a "research analysis" software , ... Now I will start to develop a new operating system with a permissive license such as BSD , etc. , to be able to handle ( not "Very" , but ) "Large scale software stacks" because at present there is no such an operating system . My multimedia ( data , information , knowledge ) system ( its PhD thesis name is : A multi-media Information management system ) has hit an internal limit(s) of both FreeBSD and Linux and it is not possible to continue to develop it any further because I could not find why the program is wiped away from the screen without leaving even a simple message . Logging is not usable because the last part is completely missing . Debugging is impossible because a few minute run is using approximately entry-exit pairs reaching at least 500 hundred millions excluding mouse interrupts , run is based on recursive entries of a body running correctly with a very large number of re-entries . To be able to continue , it is necessary to to have a NEW operating system able to manage such large systems : Because : (1) Used compilation . linking , and execution models are not suitable for such large systems , (2) There is a need to distribute computations over systems . Existing systems are no more than , approximately , NFS . (3) The present models are not able to find error sources when they occur . used debugging models can only be used on small systems . They are not able to detect errors in a large distributed system , (4) Present time hardware is designed for a single user , connected with a network facility . They are not secure , and it is not possible to generate a very secure system . The need is to design a new hardware computing system being able to support software running over it . . . . . . And many more completely "CRAZY" ideas about " ... software development " ... . . . . . It is possible to see that there is NO FREE and WASTABLE TIME ... Trying to help people is important for me because I gained my knowledge solely based on work and help from my predecessors . Now it is the time to pay back their contributions to newcomers when I am able to do it and have sufficient ability for it . The state is this . With my best wishes for all . Mehmet Erol Sanliturk > On Sun, Nov 28, 2021, 18:14 Mehmet Erol Sanliturk > wrote: > >> On Sun, Nov 28, 2021 at 12:17 PM Stefan Esser wrote: >> >> > Am 28.11.21 um 02:06 schrieb Mario Lobo: >> > > On Sat, Nov 27, 2021, 20:27 George Mitchell >> > wrote: >> > > >> > >> On 11/27/21 17:40, Obsto Clades via freebsd-hackers wrote: >> > >>> I hacked on the FreeBSD source code to produce a version of the OS >> that >> > >>> cannot be remotely hacked. Before you tell me that is impossible,= I >> > >>> have an answer to that response on my FAQ page. >> > >>> >> > >>> If you are interested in checking out my OS, you can find >> instructions >> > >>> on my site's home page: https://obstoclades.tech/ >> > >>> >> > >>> I invite you to check it out. >> > >>> >> > >> >> > >> Hmm, my mother told me never to click on links in strange emails ..= . >> > >> -- George >> > >> >> > > >> > > curl http://obstoclades.tech >> > [...] >> > >

Connection denied by Geolocation Setting. >> > >

Reason: Blocked country: >> >> >

>> > >

The connection was denied because this country is blocked = in >> > the >> > > Geolocation settings.

>> > >

Please contact your administrator for assistance.

>> > > >> > >
WatchGuard Technologies, Inc.
>> > > >> > > >> > > >> > >> > $ fetch --no-verify-peer -v -o /tmp/obstoclades.html >> > https://obstoclades.tech >> > resolving server address: obstoclades.tech:443 >> > SSL options: 82004854 >> > Verify hostname >> > TLSv1.3 connection established using TLS_AES_256_GCM_SHA384 >> > Certificate subject: /CN=3Dobstoclades.tech >> > Certificate issuer: /C=3DUS/O=3DLet's Encrypt/CN=3DR3 >> > requesting https://obstoclades.tech/ >> > fetch: https://obstoclades.tech: size of remote file is not known >> > local size / mtime: 34916 / 1638088913 >> > /tmp/obstoclades.html 34 kB 181 kBps 0= 0s >> > >> > There is actual contents in this file, and it does not seem to contain >> any >> > malicious parts. It starts with: >> > >> > >> > >> > >> > >> > >> > Security is a Joke >> > > > content=3D"This demonstrates a modified BSD Operating System >> > designed >> > to prevent remote hacking of single-purpose computer systems."> >> > >> > >> > >> > >> > >> > >> > And besides the jquery.min.js dowloaded from ajax.googleapis.com only >> the >> > following short and apparently benign script is downloaded as >> > obstoclades.js: >> > >> > /* >> > * File: obstoclades.js >> > * Copyright (c) 2017 Obsto Clades, LLC >> > */ >> > >> > $(document).ready(function() >> > { >> > var $content =3D $(".content").hide(); >> > $(".img").on("click", function (e) >> > { >> > $(this).parent().parent().toggleClass("expanded"); >> > var ttt =3D $(this).parent().children(".tooltiptext"); >> > if ($(this).parent().parent().hasClass("expanded")) >> > { >> > ttt.replaceWith("Click t= o >> > close"); >> > } >> > else >> > { >> > ttt.replaceWith("Click t= o >> > open"); >> > } >> > $(this).parent().parent().next().slideToggle(); >> > }); >> > var textHeight =3D $("#left-side-header-text").height(); >> > $("#old_english_sheepdog").height(textHeight).width(textHeight); >> > $("#button").click(function() >> > { >> > $("#contactus-form").submit(); >> > }) >> > }); >> > >> > He invites to attack his server using a SSH login with provided >> > credentials, >> > and offers US$1000 for any successful modification of the test server. >> See >> > the following video, which shows that root on the consonle and root vi= a >> su >> > in the SSH session get quite different environments: >> > >> > https://obstoclades.tech/video/demo-video.mp4 >> > >> > This looks like a setup with lots of restrictions applied, probably >> noexec >> > mounts of temporary file systems and the like, possibly jails and/or M= AC >> > restrictions. >> > >> > He thinks that an embedded system configured that way could not be >> > attacked, >> > but explains that his concept is limited to e.g. IoT use cases (what h= e >> > calls "single-purpose computer system"). >> > >> > Anyway, I could not find any malicious content on the web server. >> Accessing >> > with a SSH session (obviously configured to not allow backwards >> tunneling) >> > should also not be too dangerous from a dumb terminal (but beware of >> escape >> > sequence attacks possible with ANSI terminals, e.g. reprogramming of >> > function >> > keys with "ESC[code;string;...p"). >> > >> > It looks to me like kind of a honeypot setup gathering attack attempts >> to >> > see whether a throw-away system can withstand them. All attack attempt= s >> are >> > logged, either to learn how to perform them, or to actually improve th= e >> > security of his protection concept in case of a successful break-in. >> > >> > Regards, STefan >> > >> >> >> The message above is really a very good one because of its information >> content . >> >> As a response to my message in the following link >> >> >> https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000515.= html >> >> Obsto Clades asked me with a private message , approximately , >> >> " I am connecting to the web site ... without any such message . >> >> Do you have more information ? " . >> >> I replied , "No ." >> >> >> When the following link ( please notice that it is http , not https ) >> >> >> http://obstoclades.tech/ >> >> >> the response of Firefox ( 57.0.1) is the following : >> >> -------------------------------------------------------- >> >> Connection denied by Geolocation Setting. >> >> * Reason: * Blocked country: >> >> The connection was denied because this country is blocked in the >> Geolocation settings. >> >> Please contact your administrator for assistance. >> WatchGuard Technologies, Inc. >> >> >> -------------------------------------------------------- >> >> >> >> When the following link ( please notice that it is https , not http ) >> >> >> https://obstoclades.tech/video/demo-video.mp4 >> >> >> the response of Firefox ( 57.0.1) is the following : >> >> -------------------------------------------------------- >> >> >> Your connection is not secure >> >> The owner of obstoclades.tech has configured their website improperly. T= o >> protect your information from being stolen, Firefox has not connected to >> this website. >> >> Learn more=E2=80=A6 >> >> Report errors like this to help Mozilla identify and block malicious sit= es >> >> >> >> -------------------------------------------------------- >> >> >> In "Learn more ..." >> >> the linked page is >> >> >> https://support.mozilla.org/en-US/kb/error-codes-secure-websites?as=3Du&= utm_source=3Dinproduct >> How to troubleshoot security error codes on secure websites >> >> >> There are 2 knobs not copyable : >> >> (1) Go back >> >> (2) Advanced >> >> >> When "Advanced" is clicked ( there is no linked page ) , >> >> the following message is displayed : >> >> >> >> >> -------------------------------------------------------- >> >> >> obstoclades.tech uses an invalid security certificate. >> >> The certificate is not trusted because it is self-signed. >> The certificate is not valid for the name obstoclades.tech. >> >> Error code: SEC_ERROR_UNKNOWN_ISSUER >> >> >> -------------------------------------------------------- >> >> >> >> With a knob ( without any linked page ) as follows : >> >> >> "Add Exception ..." >> >> >> with an dialog pane display to add an exception for that page >> >> ( which I did not added because website owner may correct her/his >> certificate >> >> or configuration of the website ) . >> >> >> With my best wishes for all , >> >> >> Mehmet Erol Sanliturk >> > --00000000000028040705d1da99c8-- From nobody Sun Nov 28 15:51:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 70EB018C1B76 for ; Sun, 28 Nov 2021 15:51:36 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 4J2Cdh1tkdz3J0d for ; Sun, 28 Nov 2021 15:51:36 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id c4so31044866wrd.9 for ; Sun, 28 Nov 2021 07:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=rhfDG8qhKtApFShSeJzej9pLo+I4uBuLzmtHEpPiXgM=; b=U8Gd4mQlICAsV2zvb7z0TXqZZISIByUsOW5aCoHXQEq6FJZ95NRzu15cZH5sfiXbDh rTb6mC4lrcooSGU7z/doocSJZW+Tid8/hUcMUqsqao8RxhYfYNNEvKQmGjzUDpCMFwvm q7bLCfmDSCPfyNOQq5+HIIkI4wLq/SD/UaZX95xPtqVhT9h3qYDS1xJwtAJtNCB5jT/r QrQu9FeyK4QhynkZ+CXiYN9PFNZ5CtHQOUdjwlZwIBSY5N9oQxjZECfsVgAB2j9hk9fz jSMOdp4Gm1UUcza/N9fe8N2iHzZFx+xZVBvF/TNd4QjcK1rTwWCenKsRoCc/HPiz/7Id fThQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=rhfDG8qhKtApFShSeJzej9pLo+I4uBuLzmtHEpPiXgM=; b=Kdn7pcXl/Vj9HMmfLVwY7iiJx+8OJT89n2OynDwEalz+V6qBllOLGV55IFcavdHtmq V8/Oila9M/Hen2o+mUTwf1Vxb41Rr7Ch+3eH/T9Aa5DQCkv2IFigf3zUyo4MuNR4YWdB L7WAsLCWnQV6nVeTQ4jkUolL+ZxtLXIgail8mT5T3QYVZoVsU7/aLAv+Eyh1U6lcth6N BSM30Z6Jl4RMQ9VTquvrMZqqfBdbCKnYAssKpklCVJpkm9vOfd8YJFADdZNzsbAvWL3x NeJGnyx5zAZtQc4L8kVvvQIImvLFQljWvnEMQ5RMUtntNxuCqOzqKwvkuExXDLf2xk8B zb1g== X-Gm-Message-State: AOAM530MAp13tjV/Mc25r0lqsNyM+8SKKi+5fv4ZGDSCVQWEmXA0S/0p lytgb6wJxw6cuo4ePW7cpTGFXnwBdvETig== X-Google-Smtp-Source: ABdhPJzpr3X5CZrrLP4YmI6FL2tXRL01VnbjjuFErWGxQA04FZjaHZAUoZCunVAMcnsRzgURV82nDQ== X-Received: by 2002:a5d:40c8:: with SMTP id b8mr27578748wrq.610.1638114694110; Sun, 28 Nov 2021 07:51:34 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id d15sm15384658wri.50.2021.11.28.07.51.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Nov 2021 07:51:33 -0800 (PST) Message-ID: Date: Sun, 28 Nov 2021 15:51:32 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: OpenZFS: FreeBSD bootloader support for encrypted file systems (was: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase) Content-Language: en-GB To: freebsd-hackers@freebsd.org References: From: Graham Perrin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J2Cdh1tkdz3J0d 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 27/11/2021 20:35, Stanislaw Adaszewski wrote: > … > > 6) Regarding ZFS encryption I am not sure if that is supported in the EFI > bootloader - at first glance I would say that it isn't. … (2021-06-21) described work in progress however, to the best of my knowledge: * there's not yet a dedicated place where discussion/work can be tracked. If so: which one of the following areas might be most suitable, for starters, for tracking? From nobody Sun Nov 28 16:43:44 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3D80918BABA7 for ; Sun, 28 Nov 2021 16:44:07 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2DpG3Z02z3q91 for ; Sun, 28 Nov 2021 16:44:06 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f47.google.com with SMTP id m9so18151782iop.0 for ; Sun, 28 Nov 2021 08:44:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OCcSzfr8n1wp+NPsNq4dWQPNoQDf0JaqBuRZQQsSyjY=; b=WJtgffg3nfqKAwACVrR5Soq2qAoiBIuu+5vyqGr8EgFKCQNEXWelw8U55V1Bbx7dED Gw/DcKkMH75rV3Y3ShKb8XIwEL3HAtlTqSGO4bR9QEM17Pm/OAUUf6nDm8Opui1uW24z GmflhOmlxIwib1FzebcUP3vIM2Knjy/mqBkK/LF7S8Fn44vKOeLjN0VQ+02Ez0jl+inX sxESs54fDMJGddqKHQ+7nvRye+0Wtoy0CjK5CGnXfuwfJJlMErT+uR8uwFhWGHOnZXnj l8Wb1yZTb/ma4PpqqDL7Dn2/SmVd1jOTI7c6q6YeCEvcEgAD7W55vxjL4vqK45mucmPO JAXg== X-Gm-Message-State: AOAM532X9xkyz+3KMJf2qMV6xf/ReaPz2nKY5gEcFjTRte7jFS3dBVbt 0m0cI0QCbOvllUofYDh7kaB1HY0D9xQWyTRRB5589jzt/4c= X-Google-Smtp-Source: ABdhPJz+nB/Md+tuqD6ersvaMvgw0iqrYNCfvLXMWhtGaBmQY9VzULfojlxrvbFATJq+eGQ/slqW1PMovTFQg0AjM1M= X-Received: by 2002:a5d:818a:: with SMTP id u10mr50339254ion.140.1638117839471; Sun, 28 Nov 2021 08:43:59 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> In-Reply-To: From: Ed Maste Date: Sun, 28 Nov 2021 11:43:44 -0500 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: FreeBSD Hackers Cc: Emmanuel Vadot , Stefan Blachmann Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J2DpG3Z02z3q91 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.47 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.91 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_CC(0.00)[bidouilliste.com,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]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.972]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.47:from]; NEURAL_HAM_MEDIUM(-0.12)[-0.120]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.47:from]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-ThisMailContainsUnwantedMimeParts: N On Fri, 26 Nov 2021 at 10:45, Stefan Blachmann wrote: > > Main technical reasons why I consider sc(4) essential: > > - vt/vesa.ko break suspend/resume on nvidia cards. To make > suspend/resume work on computers with nvidia, it is necessary to build > a kernel *without* vt/vesa modules. See > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253733 To wrap up this one - this is an issue with `options VESA` / vesa.ko. It is not related to vt(4), which does not use that VESA driver. I have removed `options VESA` from GENERIC now in b8cf1c5c30a5. It serves no purpose when vt(4) is in use, and the kernel module is still available for sc(4) users who want to set a VBE mode. As an aside, the loader can set a VBE mode and vt(4) will make use of that, it just does not support mode changing after boot. From nobody Sun Nov 28 17:09:12 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F5FB18C7D83 for ; Sun, 28 Nov 2021 17:09:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4J2FMP5n39z4T8w for ; Sun, 28 Nov 2021 17:09:21 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From; bh=blO7X6Q6QrUTIO0g4fYL8RjLj2dmUh4BI8hYuXfL0ks=; b=Bc2P9RL+4iWS+DuWFez17q1MFjJEu9m7vEs7VMMTuNidr6g5CDX93dtF/V2Cc6amUc3vOVC8GC6knkL9LVeLt7iG+YCDKRMyw3n2e7gnGPtzzgcD+VRCD8DQHVaAfWttgCeI8tFMotBYGtURbM6NXRcc01N+DRkkG3Ss4yuhd1e6pinKoxqhpkdfKKOuLv/DykQ+QdbhDnoLETRvOqdVNTZHvXFDsXruKFJl9XFtJN78DRkm1tE/NSC4xKRkcpZ7Cso0H+xps+BEJlDWFxvuyFnIboiWEem344NhCxWYBQYBXb7s8G/F4rAnxKboH3f+L7dAi4dnUa2U2OcHBbjihQ==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1mrNfs-000CG9-Ne for hackers@freebsd.org; Sun, 28 Nov 2021 19:09:12 +0200 From: Daniel Braniss Content-Type: multipart/alternative; boundary="Apple-Mail=_EE4447ED-6959-4F1C-9CBD-1A1F94A5CD11" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: usb serial - need quirk? Message-Id: <11EBCD70-3259-4E4D-8B9C-9F25364BC73C@cs.huji.ac.il> Date: Sun, 28 Nov 2021 19:09:12 +0200 To: freebsd- X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Rspamd-Queue-Id: 4J2FMP5n39z4T8w X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=Bc2P9RL+; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-0.998]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_EE4447ED-6959-4F1C-9CBD-1A1F94A5CD11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi, this usb device (actually the micro usb on a esp32c3) is reported by = FreeBSD 12.1 as: ugen0.10: at usbus0, cfg=3D0 md=3DHOST = spd=3DFULL (12Mbps) pwr=3DON (134mA) and dimes shows: Nov 28 19:02:19 pampa kernel: ugen0.10: at usbus0 Nov 28 19:02:19 pampa kernel: umodem0 on uhub3 Nov 28 19:02:19 pampa kernel: umodem0: on usbus0 Nov 28 19:02:19 pampa kernel: umodem0: data interface 1, has no CM over = data, has no break it=E2=80=99s the last line that I think is causing failure to flash the = device (probably needs the break to set the speed?) any ways, is there some fix for this? thanks, danny --Apple-Mail=_EE4447ED-6959-4F1C-9CBD-1A1F94A5CD11-- From nobody Sun Nov 28 18:33:09 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DE07818A865C for ; Sun, 28 Nov 2021 18:33:28 +0000 (UTC) (envelope-from watsonbladd@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4J2HDS1FRSz3CBw; Sun, 28 Nov 2021 18:33:28 +0000 (UTC) (envelope-from watsonbladd@gmail.com) Received: by mail-ed1-x52a.google.com with SMTP id x15so62270103edv.1; Sun, 28 Nov 2021 10:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gi5pe1Bpfit9JZLRirZfwpk3ZKAblKSFBXVJz4izVoo=; b=QNj//r7ZcuCY1cZdnDUlLemhK2V6K0R805toAOGz44YQtqnQukx5lZm9xYL9E1MY9I gAyO/ymwMoVc1K2CYssUzW8FEbk01EFHOvjDihGidU/Ho0L6PzTRjso1PObIBsaNbW/o 9gIoRFo5oM5ZvMuVYUP7DJVs2mhXSLjAVlfwOjoa+16jt6PshDgBrQ5l2cV/DTWNacbd CZX8LM5N14KLa1/N9KnZk3iSdzKYc2VGSgqTuN2RmhmKuFJg8BS6/TbxALtlT2XAm0uw mn9fe0ITUTkGfBV6jP4MhR1OmDGxWEE4cCiL0brRoTLyAIFdr1F0J9PK+deBYEyp3hfI MlBQ== 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=Gi5pe1Bpfit9JZLRirZfwpk3ZKAblKSFBXVJz4izVoo=; b=WBWSxQTlJa2+z3IzpLquz/pQztv7mtxm4VPv8vwTGs0JSCcyzYuxOZuNyczXT+Ckf8 VnxCUmLBku2EUQrG2k/E6lKjBM2XQrvDLMmvBVf9g5pm4R2UKLBx3udPJSx18A7WTNbH f/vrroH/1TiPhe1+hoYwKtTByQMZCInoWDLUH6Mk5r6nodV+2woLky84uXXxemuKioEk zi9JuP0UUeVMVaTc2dgsC9nFbq+qbGursEKViy/7YgDeaq0ekXjpmQXz3LEhpjYzy/a6 iAOaEM98JpQwMpT8Q6o/j4MAbqZZwRuO/QL7RBfVtd+KHFn90quO4/alZWRCPJRbXqSZ TWVA== X-Gm-Message-State: AOAM530L6kOK109tQ1b0G2IY8lM3S072R7Cyt7mBSZpx6Ni30I7Fx0qg 4ksky4u3kx2yroXfIHjsUBbWVLFrhgKD73BKF51VyetM X-Google-Smtp-Source: ABdhPJzYlrzIQpDfO0bt5LLxCdGRVQ40XdIVvSolPIThGPBtbnz3pClz9j6go+nYO2yJrWGiYqOUuUzSjrdKnaIsUPs= X-Received: by 2002:a17:907:7d8b:: with SMTP id oz11mr56016916ejc.507.1638124401394; Sun, 28 Nov 2021 10:33:21 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> From: Watson Ladd Date: Sun, 28 Nov 2021 13:33:09 -0500 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J2HDS1FRSz3CBw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="QNj//r7Z"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of watsonbladd@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=watsonbladd@gmail.com X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.80)[-0.804]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; 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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 23, 2021, 5:42 PM Joseph Mingrone wrote: > > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? Building and transporting jails (paddywagon?). If jail could be made in an OCI compatible way then kubernetes and maybe docker might be portable to FreeBSD in a way that doesn't depend on linux emulation. From nobody Sun Nov 28 18:39:21 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7D7D618AC363 for ; Sun, 28 Nov 2021 18:39:30 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2HMP3xvFz3FZr; Sun, 28 Nov 2021 18:39:29 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 1ASIdLFQ035577 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 28 Nov 2021 13:39:21 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4::29] ([IPv6:2607:f3e0:0:4:0:0:0:29]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 1ASIdLBH003323 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 28 Nov 2021 13:39:21 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <69e878bf-9379-f97e-0c9b-011952fd3daf@sentex.net> Date: Sun, 28 Nov 2021 13:39:21 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: Joseph Mingrone , FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> From: mike tancsa In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4J2HMP3xvFz3FZr X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-1.26 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-0.69)[-0.685]; NEURAL_SPAM_MEDIUM(0.73)[0.726]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/23/2021 5:41 PM, Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? Maybe some bug squashing on the FreeBSD golang runtime. There are a number of open issues. Would be great to see better support as its getting to be a more popular dev platform.     ---Mike From nobody Sun Nov 28 19:36:13 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B6A518C6B9E for ; Sun, 28 Nov 2021 19:36:20 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2Jd02HJvz3p7G for ; Sun, 28 Nov 2021 19:36:20 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x729.google.com with SMTP id i9so20524088qki.3 for ; Sun, 28 Nov 2021 11:36:20 -0800 (PST) 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=fiV0iA8mGNAPTcrAXxUf5khP6DVbC9zLarjrp4BU9VE=; b=BNK14ogxsDtQXhO/GnGoeX5fsshfNmY6SE0h13/U+wwsAIW2o1otLewQw8yyk+A6Bo cXjcydX4R0RK4hpp+y7Khw2t7heVjpFMioS9yLpBXgN2Kr04drEMapFgRSa20SyLxju2 7bmVhGYmEIzbXoTmvIfBp1MTPZ8BF5WIvuMDL9+VtadQgKju0E/XBQU2XSGayVMY/IzE /xrV1CdfygTyJYGN63tPzWpIvaEyr/sR1/nvKZHz+bYSbUsF6NlKToURGT89eIXSwkaW uily2UNQiP/dknQ0zC6BeEtHdVgMrQoceC0voB84DkxkUFKu/rzUjXYbhgy7ckgO0Tn2 4GEA== 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=fiV0iA8mGNAPTcrAXxUf5khP6DVbC9zLarjrp4BU9VE=; b=cyT2l1mAWD6DrHGBr2Ookk8lOQ+6K78QVDoETvj7ZuY/LOL2iYXaQHRdwHl3u8oJHy 6c5X/aOiSGtMwEka3+k9+yQGrmznx7blgead0mwajYYDdrycAUFnhBWCD9rqlQH7xt2E 6FA5yeB8DEpQQ9Wm3ekR3VOxImBzawy6ZyI9GEC0AY1XRYgffotpTF0mVRnzIWV6Ef2T Cv7koQVBbrciKXk+jHzNH9eV7RATeVL50UMsuPIaRmb3OIsbmb3G+gNNLx7natoOJVuj YjgRzwMWZ7QUQgk/UuT/yYHFO2ryt2NKzKRoIg/lpm0ryneK4K0YqoJjeh/BpZc/xsC6 YEwQ== X-Gm-Message-State: AOAM531OdWR0aYny66E/KXTJUoMaKnBOKvoPkD26DJvsI0TWN3aDeaNP IfD5AeAfq9b6BAZE+vNBrFDJTA== X-Google-Smtp-Source: ABdhPJxldzKh4cmhcG0lXU37ycomiwfBV9Js+eXJKjG9V0n3cAj7jl38M3fXIJ2gA+YPNFrwMryo2w== X-Received: by 2002:a05:620a:94d:: with SMTP id w13mr35194678qkw.419.1638128174148; Sun, 28 Nov 2021 11:36:14 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id l1sm7126925qkp.125.2021.11.28.11.36.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Nov 2021 11:36:13 -0800 (PST) Date: Sun, 28 Nov 2021 14:36:13 -0500 From: Shawn Webb To: mike tancsa Cc: Joseph Mingrone , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211128193613.mpvyu7kvwphxnyos@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: <861r36xzpe.fsf@phe.ftfl.ca> <69e878bf-9379-f97e-0c9b-011952fd3daf@sentex.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jktuehiql7d64tbs" Content-Disposition: inline In-Reply-To: <69e878bf-9379-f97e-0c9b-011952fd3daf@sentex.net> X-Rspamd-Queue-Id: 4J2Jd02HJvz3p7G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --jktuehiql7d64tbs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 28, 2021 at 01:39:21PM -0500, mike tancsa wrote: > On 11/23/2021 5:41 PM, Joseph Mingrone wrote: > > Hello FreeBSD community, > >=20 > > The Foundation is seeking suggestions for new projects to support. What > > gaps in the Project are not being addressed by the broader community? >=20 > Maybe some bug squashing on the FreeBSD golang runtime. There are a number > of open issues. Would be great to see better support as its getting to be= a > more popular dev platform. A little tidbit: When building PIE golang applications, golang still creates a mapping at a deterministic address. I opened a bug report[0] a few years back, but it seems the bug is still open. Supporting PIE golang apps would go a long way with FreeBSD's recent ventures into AS{L}R. [0]: https://github.com/golang/go/issues/27583 Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --jktuehiql7d64tbs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGj2ioACgkQ/y5nonf4 4fpf3g/+L1+duevXVAbJzF/TrKO5wdRbfb4oAYYbX33tRa9MNzOMMHCRiTlRjYMc ZKaGN4EpVPzHLuY8vLyVtZsSvDH1TwH4nZBGU1fHm8S2aIOELB2xj3WC1wDffttJ zTovREL3x4PIZgsZXb2u0TEOt6p7WQJin1R9vAVuQ+gKS9lz5Dh6sXAalEsSYjCJ KtOGNFgRFjXwLNLHphvvgTn4vKNmKqHcELfePVsGDwuyzqHyz8VLXWsGaNGF6+gW RCF8k/otPdOWlfHFNRtVraTR+0AxPVjglrmhCgGSZsu9Mu4vALFEdngmsG0q70ZH 0Uorssr1oyyqu4yQj1LtKOLxYtvgQaDnfilbV41dDJvfgo2ywRgsPQGAJbabtFVr ZR9OD576rm4rn3mpzpG9KsWKNB1OdhYbGwTBmQekKvo9oJak2L8VzM07hPLKHco0 lo+WKLH7rJOXs3uJBR5llpu3spr5GayWE9dSFVvhL0Bp4qGvZa9Jy+LnKlYgAoP4 GOU1lcijeN+LY4PQnIAbmPYi5dE+DQI5U+KJbN38tvLQ933bKcIwY2doLVGvdB8C gqYkHmcM/vLbT+v/hSQm2+b2DBiRbA7CmZOviWa9QaZbhW2L8yiMEWCvFpPbTWvG 7sovGpG1xbAlidFs31lbdqHU6S3sZoe1FRaxQWEpC/XbMcFDyEM= =JvqA -----END PGP SIGNATURE----- --jktuehiql7d64tbs-- From nobody Sun Nov 28 19:59:20 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E984518B48B7 for ; Sun, 28 Nov 2021 19:59:31 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from fedex2.jetcafe.org (fedex2.jetcafe.org [205.147.26.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "fedex2.jetcafe.org", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2K7l4yXqz4SvK for ; Sun, 28 Nov 2021 19:59:31 +0000 (UTC) (envelope-from dave@jetcafe.org) X-Envelope-To: freebsd-hackers@freebsd.org X-Rcpt-Mailer: X-Mail-Mailer: local X-SMTP-Proto: ESMTP Received: from bigus.dream-tech.com (bigus.jetcafe.org [205.147.26.7]) by fedex2.jetcafe.org (8.16.1/8.16.1) with ESMTP id 1ASJxKXh085243; Sun, 28 Nov 2021 11:59:20 -0800 (PST) (envelope-from dave@jetcafe.org) Date: Sun, 28 Nov 2021 11:59:20 -0800 From: Dave Hayes To: George Mitchell Cc: freebsd-hackers@freebsd.org Subject: Re: Hello Message-ID: <20211128115920.61240092@bigus.dream-tech.com> In-Reply-To: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> References: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1 ( out of 5.1) ALL_TRUSTED,SHORTCIRCUIT X-Spam-Checker-Version: SpamAssassin version 3.4.5-jetcafeglobal X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4J2K7l4yXqz4SvK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[freebsd]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 27 Nov 2021 18:26:43 -0500 George Mitchell wrote: > On 11/27/21 17:40, Obsto Clades via freebsd-hackers wrote: > > If you are interested in checking out my OS, you can find instructions= =20 > > on my site's home page:=C2=A0 https://obstoclades.tech/ >=20 > Hmm, my mother told me never to click on links in strange emails ... Did your mother ever use cURL? :D prompt> curl -kv https://obstoclades.tech * Trying 209.181.137.95:443... * Connected to obstoclades.tech (209.181.137.95) port 443 (#0) ... * SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: CN=3Dobstoclades.tech * start date: Oct 16 20:04:54 2021 GMT * expire date: Jan 14 20:04:53 2022 GMT * issuer: C=3DUS; O=3DLet's Encrypt; CN=3DR3 * SSL certificate verify result: unable to get local issuer certificate (2= 0), continuing anyway. It seems there's a problem with his certificate chain, but this is not unus= ual. > GET / HTTP/1.1 > Host: obstoclades.tech > User-Agent: curl/7.77.0 > Accept: */* >=20 * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Server: nginx/1.20.1 < Date: Sun, 28 Nov 2021 19:50:00 GMT < Content-Type: text/html; charset=3Dutf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Cache-Control: no-cache, no-store, must-revalidate < Pragma: no-cache < Expires: 0 No obvious problem there. The only possibly questionable thing (other than jquery, which comes from google) is this: which is this: /* * File: obstoclades.js * Copyright (c) 2017 Obsto Clades, LLC */ $(document).ready(function() { var $content =3D $(".content").hide(); $(".img").on("click", function (e) { $(this).parent().parent().toggleClass("expanded"); var ttt =3D $(this).parent().children(".tooltiptext"); if ($(this).parent().parent().hasClass("expanded")) { ttt.replaceWith("Click to close"); } else { ttt.replaceWith("Click to open"); } $(this).parent().parent().next().slideToggle(); }); var textHeight =3D $("#left-side-header-text").height(); $("#old_english_sheepdog").height(textHeight).width(textHeight); $("#button").click(function() { $("#contactus-form").submit(); }) }); There's nothing in that I can see that's malicious. I could be wrong.=20 I looked briefly at the content. This person is trying to do good by securi= ty, so in my book it's worth a look. If said machine is actually impervious to sudo root, and all the compilers/interpreters work, that's likely going to work well. Am I missing something here?=20 --=20 Dave Hayes - Consultant - LA CA, USA - dave@dream-tech.com >>>> *The opinions expressed above are entirely my own* <<<< No system is any use if you merely possess it. Ownership requires operation. No system is useful if one can only experiment with it. For a system to be useful, it must be correctly operated. From nobody Sun Nov 28 22:07:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B9A118A9F48 for ; Sun, 28 Nov 2021 22:07:41 +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 4J2Mzc1qJ3z3kfC; Sun, 28 Nov 2021 22:07:39 +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 1ASM7Wcv081151 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 28 Nov 2021 14:07:32 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1ASM7WOr081150; Sun, 28 Nov 2021 14:07:32 -0800 (PST) (envelope-from sgk) Date: Sun, 28 Nov 2021 14:07:32 -0800 From: Steve Kargl To: Joseph Mingrone Cc: FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211128220732.GA81140@troutmask.apl.washington.edu> References: <861r36xzpe.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> X-Rspamd-Queue-Id: 4J2Mzc1qJ3z3kfC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-3.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; 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:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 23, 2021 at 06:41:01PM -0400, Joseph Mingrone wrote: > Hello FreeBSD community, >=20 > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? >=20 > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. >=20 > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. >=20 1.) Replace clang with something/anything that is more performant. Going on day 3 of "make buildworld". Still in the lib/clang/libclang directory. % ps -ww -p 77387 PID TT STAT TIME COMMAND 77387 2 R 40:34.67 c++ -target x86_64-unknown-freebsd14.0 --sysroot=3D= /usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin= -O2 -pipe -g -O1 -fno-common -I/usr/obj/usr/src/amd64.amd64/lib/clang/libc= lang -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/contrib/ll= vm-project/clang/lib/Basic -I/usr/src/contrib/llvm-project/clang/lib/Driver= -I/usr/src/contrib/llvm-project/clang/include -DCLANG_ENABLE_ARCMT -DCLANG= _ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include -I/usr/src/contrib/llv= m-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__= STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DLLVM_DEFAULT_TARGET_TRIPLE=3D"x8= 6_64-unknown-freebsd14.0" -DLLVM_HOST_TRIPLE=3D"x86_64-unknown-freebsd14.0"= -DDEFAULT_SYSROOT=3D"" -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=3D= LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeX86AsmP= rinter -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeX86Disassembler -DLLVM_NA= TIVE_TARGET=3DLLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=3DLLVMInitia= lizeX86TargetInfo -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeX86TargetMC -ffunc= tion-sections -fdata-sections -Wno-format-zero-length -fstack-protector-str= ong -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-er= ror=3Dunused-but-set-variable -Wno-tautological-compare -Wno-unused-value -= Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unu= sed-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enu= m -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -fno-exce= ptions -fno-rtti -std=3Dc++14 -stdlib=3Dlibc++ -Wno-c++11-extensions -c /us= r/src/contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp -o Sema/SemaExpr.o 40 minutes for 1 file with many exceeding 30 minutes seems a tad bit excessive. --=20 Steve From nobody Sun Nov 28 23:55:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E57BE18BF3B7 for ; Sun, 28 Nov 2021 23:56:30 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2QP96wRtz4r6l for ; Sun, 28 Nov 2021 23:56:29 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qk1-x729.google.com with SMTP id m186so20980029qkb.4 for ; Sun, 28 Nov 2021 15:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=sVsKD4Ry1UiQfWRjRccl3oy1kYtYK3Q4LtilENLvODE=; b=hwJeaXo5Nt90EZk4q7br4hY+UOKR9GsU0YyGi2DGz9SnLJ/mKvf0d6PDz5/b/f5z9d ZOvrB3o21ivnqs6FKoWw+ZO9GWFCLyTZpd69CL3PvY2sY2MI+DRt5BiOEkp5pIE3raF4 XbujyiizrLH++p/Tqy6Y5/OYqtzrHgbQBIXf9q5T/DY2HMmErdKSoA77FHvS3FZCaOxh ActS28D21yZWznKVUnOme1VbGOxuzjLtmofSRGeLGe/mUrCKNSuhOz6xbx0QLfkvHmDr Wu6jikxSqegBaEoCymiL/qRje8iNUOuRkobu/ojQX5bI365t8+3pmmemxNCDW4C6kJ4C x24Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=sVsKD4Ry1UiQfWRjRccl3oy1kYtYK3Q4LtilENLvODE=; b=Ds2o3sg6BIc+2bnCAyYBdANmmqlJUqJpDp1WGVoQV1LcpOtKPNwNSb3lZaf83MAF/O xP9+GSb0Vz0BlPGwqJNN2fnThQLAI/DSAH4Y43mVcAxdvnHTuJC3NFjW6rNOr5lJ50mz pSo1DXxAr0qIbTdBcequKnGTwrXcONMCV7ZSy+ZMOCLcAzxvhMpm34sa9BfVmVs3Lckn eYMRdtwS2XwjT/T8aq5K2DbE+IXuHoScPI74gdxU/WcXEmUFhxRvO5IUkWSbO+zIZ8co isYHRk3SqnNzfXj/M1Ormnt1dB6JSGP6jQ8XXsHMmaxcbafESS8/qe1K5bbetZH7EAAc eqOg== X-Gm-Message-State: AOAM531UxnjyjGDNRKF7Wy39JwDTLXZA671pZf9bt0G0e7DOomKg+5Cu Fcrwt8XpvYoJ+XEzWoQNGjlKh6VZZ6g= X-Google-Smtp-Source: ABdhPJz+88nkxG6uLYdKxh6Ltw1IcivXTIZKo6RxAxOX1MH1KzgJP3yprPxXwLTzZJ0DxtX9mL40/A== X-Received: by 2002:a05:620a:2a03:: with SMTP id o3mr35882705qkp.477.1638143789197; Sun, 28 Nov 2021 15:56:29 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id h11sm7579288qko.18.2021.11.28.15.56.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Nov 2021 15:56:28 -0800 (PST) Message-ID: Date: Sun, 28 Nov 2021 17:55:32 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> From: Jason Bacon In-Reply-To: <20211128220732.GA81140@troutmask.apl.washington.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 4J2QP96wRtz4r6l X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hwJeaXo5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::729 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-1.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.31)[-0.309]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.74)[-0.745]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::729:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N T24gMTEvMjgvMjEgMTY6MDcsIFN0ZXZlIEthcmdsIHdyb3RlOg0KPiANCj4gJSAgcHMgLXd3 IC1wIDc3Mzg3DQo+ICAgIFBJRCBUVCAgU1RBVCAgICAgVElNRSBDT01NQU5EDQo+IDc3Mzg3 ICAyICBSICAgIDQwOjM0LjY3IGMrKyAtdGFyZ2V0IHg4Nl82NC11bmtub3duLWZyZWVic2Qx NC4wIC0tc3lzcm9vdD0vdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcCAtQi91c3Iv b2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL3Vzci9iaW4gLU8yIC1waXBlIC1nIC1PMSAt Zm5vLWNvbW1vbiAtSS91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvbGliL2NsYW5nL2xp YmNsYW5nIC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC9saWIvY2xhbmcvbGlibGx2 bSAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9CYXNpYyAtSS91 c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9Ecml2ZXIgLUkvdXNyL3Ny Yy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9pbmNsdWRlIC1EQ0xBTkdfRU5BQkxFX0FS Q01UIC1EQ0xBTkdfRU5BQkxFX1NUQVRJQ19BTkFMWVpFUiAtSS91c3Ivc3JjL2xpYi9jbGFu Zy9pbmNsdWRlIC1JL3Vzci9zcmMvY29udHJpYi9sbHZtLXByb2plY3QvbGx2bS9pbmNsdWRl IC1EX19TVERDX0NPTlNUQU5UX01BQ1JPUyAtRF9fU1REQ19GT1JNQVRfTUFDUk9TIC1EX19T VERDX0xJTUlUX01BQ1JPUyAtREhBVkVfVkNTX1ZFUlNJT05fSU5DIC1ETExWTV9ERUZBVUxU X1RBUkdFVF9UUklQTEU9Ing4Nl82NC11bmtub3duLWZyZWVic2QxNC4wIiAtRExMVk1fSE9T VF9UUklQTEU9Ing4Nl82NC11bmtub3duLWZyZWVic2QxNC4wIiAtRERFRkFVTFRfU1lTUk9P VD0iIiAtRExMVk1fVEFSR0VUX0VOQUJMRV9YODYgLURMTFZNX05BVElWRV9BU01QQVJTRVI9 TExWTUluaXRpYWxpemVYODZBc21QYXJzZXIgLURMTFZNX05BVElWRV9BU01QUklOVEVSPUxM Vk1Jbml0aWFsaXplWDg2QXNtUHJpbnRlciAtRExMVk1fTkFUSVZFX0RJU0FTU0VNQkxFUj1M TFZNSW5pdGlhbGl6ZVg4NkRpc2Fzc2VtYmxlciAtRExMVk1fTkFUSVZFX1RBUkdFVD1MTFZN SW5pdGlhbGl6ZVg4NlRhcmdldCAtRExMVk1fTkFUSVZFX1RBUkdFVElORk89TExWTUluaXRp YWxpemVYODZUYXJnZXRJbmZvIC1ETExWTV9OQVRJVkVfVEFSR0VUTUM9TExWTUluaXRpYWxp emVYODZUYXJnZXRNQyAtZmZ1bmN0aW9uLXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAtV25v LWZvcm1hdC16ZXJvLWxlbmd0aCAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVduby1lbXB0 eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdW51c2VkLWNvbnN0LXZhcmlhYmxl IC1Xbm8tZXJyb3I9dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLVduby10YXV0b2xvZ2ljYWwt Y29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1X bm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tZW51bS1jb252ZXJzaW9uIC1Xbm8tdW51c2VkLWxv Y2FsLXR5cGVkZWYgLVduby1hZGRyZXNzLW9mLXBhY2tlZC1tZW1iZXIgLVduby1zd2l0Y2gg LVduby1zd2l0Y2gtZW51bSAtV25vLWtuci1wcm9tb3RlZC1wYXJhbWV0ZXIgLVduby1wYXJl bnRoZXNlcyAtUXVudXNlZC1hcmd1bWVudHMgLWZuby1leGNlcHRpb25zIC1mbm8tcnR0aSAt c3RkPWMrKzE0IC1zdGRsaWI9bGliYysrIC1Xbm8tYysrMTEtZXh0ZW5zaW9ucyAtYyAvdXNy L3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9saWIvU2VtYS9TZW1hRXhwci5jcHAg LW8gU2VtYS9TZW1hRXhwci5vDQo+IA0KPiA0MCBtaW51dGVzIGZvciAxIGZpbGUgd2l0aCBt YW55IGV4Y2VlZGluZyAzMCBtaW51dGVzIHNlZW1zIGEgdGFkIGJpdA0KPiBleGNlc3NpdmUu DQoNCkkgd291bGQgYmV0IHlvdSBoYXZlIGEgaGFyZHdhcmUgaXNzdWUuICBJJ3ZlIG5ldmVy IHNlZW4gYSBidWlsZHdvcmxkIA0KdGFrZSBtb3JlIHRoYW4gYSBmZXcgaG91cnMgYW5kIHRo YXQgd2FzIG9uIHNvbWUgdmVyeSBvbGQgaGFyZHdhcmUuDQoNCi0tIA0KQWxsIHdhcnMgYXJl IGNpdmlsIHdhcnMsIGJlY2F1c2UgYWxsIG1lbiBhcmUgYnJvdGhlcnMgLi4uIEVhY2ggb25l IG93ZXMNCmluZmluaXRlbHkgbW9yZSB0byB0aGUgaHVtYW4gcmFjZSB0aGFuIHRvIHRoZSBw YXJ0aWN1bGFyIGNvdW50cnkgaW4NCndoaWNoIGhlIHdhcyBib3JuLg0KICAgICAgICAgICAg ICAgICAtLSBGcmFuY29pcyBGZW5lbG9uDQo= From nobody Mon Nov 29 00:25:37 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6E53618CC92B for ; Mon, 29 Nov 2021 00:26:20 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2R3c2Wm9z3Gh4 for ; Mon, 29 Nov 2021 00:26:20 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ua1-x92b.google.com with SMTP id t13so30449561uad.9 for ; Sun, 28 Nov 2021 16:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dnpu318YNVTHsovDsQXsytvbKNHmrHjsDGNELQSnN1U=; b=IcsGUIf5Aze71asheaz8GGvvgpXT9/NrCWzcPh/YJKOYU64YvseC6+ia+p8bLuu6ax VGED3bmkLlmcTCYgHt91W18db6jAFK0ue4KACmeQuP92+wkIiNV8L+KggvxaIPsbG6oG G4C7hjE3TcriirQb/BZUHqXjs0aOzn5pBG0kofCOjVvHbGddYWYFn6EYTjLDBNPHnVtZ F96uaCqZscHPUeJLGryR2WNZ0VVRdf5T9iz+dEB39L1V3TWqjGa0oaV2n5L/cNDEYqg8 QFxPVrmhSSECpC/vqi1CmrOqOS2ksKTpgitYD70xyRpI/bgT9W+4oMCT4OFj3pdHAZhG rBAg== 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=dnpu318YNVTHsovDsQXsytvbKNHmrHjsDGNELQSnN1U=; b=YgFnb8Kai8Oc4uR6vT+aEyRhdJT41RpNK5dbS7c3js4OvKB0ttCZFOaABqIVl/9tix IsAHsZ2JrtyX5gpeNPlFyPdbt3gvAJSq/BT++G1mu8IrL02xovL7ov1zruaHmvxIOliJ oPnXrVGrqQqpRMgmHRnaMZOjYQSN+WE6gw58DtbtK/sFndHSTWoIkGVz/LVlctzeVHq5 65yRX3Y+qYNYN01w802OZU34jdrIDemUg0DPN6k3dtOqZ9fGzPhJwZbvhZ15f5qjJua5 +v2FtE/kSYINUHbXIouaxxVD/6pMvPtCjvB21X6FmuIJS87zXmFRZcX9sfzNPMx0V271 jN2A== X-Gm-Message-State: AOAM531Z6SnQDfDSHfTqc7Y+7cq7kW6tBFUwcDqSMFYYQ0/EeSz+YfSu ZXWnA3ZqB1oMxgm8WGiby5toEdXuhITwdvLpn/U2EL3u X-Google-Smtp-Source: ABdhPJxjJJ63ha0xrvh2HZPUjAScIgrte1zVbq99OXpNhVLUuoQ/1HrHuKnP2eqxDiyo48CWSgTEHxugdtkQUp+aw1g= X-Received: by 2002:a05:6102:126a:: with SMTP id q10mr14444221vsg.42.1638145574429; Sun, 28 Nov 2021 16:26:14 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> In-Reply-To: From: Mehmet Erol Sanliturk Date: Mon, 29 Nov 2021 03:25:37 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Jason Bacon Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000000de70105d1e27d06" X-Rspamd-Queue-Id: 4J2R3c2Wm9z3Gh4 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 --0000000000000de70105d1e27d06 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 29, 2021 at 2:57 AM Jason Bacon wrote: > On 11/28/21 16:07, Steve Kargl wrote: > > > > % ps -ww -p 77387 > > PID TT STAT TIME COMMAND > > 77387 2 R 40:34.67 c++ -target x86_64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -g -O1 -fno-common > -I/usr/obj/usr/src/amd64.amd64/lib/clang/libclang > -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm > -I/usr/src/contrib/llvm-project/clang/lib/Basic > -I/usr/src/contrib/llvm-project/clang/lib/Driver > -I/usr/src/contrib/llvm-project/clang/include -DCLANG_ENABLE_ARCMT > -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC > -DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-freebsd14.0" > -DLLVM_HOST_TRIPLE="x86_64-unknown-freebsd14.0" -DDEFAULT_SYSROOT="" > -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser > -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter > -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler > -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target > -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo > -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections > -fdata-sections -Wno-format-zero-length -fstack-protector-strong > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > -Wno-error=unused-but-set-variable -Wno-tautological-compare > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function > -Wno-enum-conversion -Wno-unused-local-typedef > -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum > -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments > -fno-exceptions -fno-rtti -std=c++14 -stdlib=libc++ -Wno-c++11-extensions > -c /usr/src/contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp -o > Sema/SemaExpr.o > > > > 40 minutes for 1 file with many exceeding 30 minutes seems a tad bit > > excessive. > > I would bet you have a hardware issue. I've never seen a buildworld > take more than a few hours and that was on some very old hardware. > > I would support the above idea because (1) sometimes cables of HDD units are becoming corroded and causing delays ( repetitions of disk read tries ) , (2) HHD unit is dying and again it is causing a large number of reread tries (3) It may be useful to check memory chips by memory test programs There may be other hardware issues , but I am not able to suggest a good solution other than ( if you have another computer , please use it for comparison ) . Some compilation parameters may cause trouble . If you are using an NFS server , its parameters for definition of it may cause very long delays . Mehmet Erol Sanliturk > -- > All wars are civil wars, because all men are brothers ... Each one owes > infinitely more to the human race than to the particular country in > which he was born. > -- Francois Fenelon > --0000000000000de70105d1e27d06-- From nobody Mon Nov 29 00:36:35 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BE64E189B624 for ; Mon, 29 Nov 2021 00:36:36 +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 4J2RHS3ybCz3LHV for ; Mon, 29 Nov 2021 00:36:36 +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 1AT0aZLV081591 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 28 Nov 2021 16:36:35 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1AT0aZZl081590; Sun, 28 Nov 2021 16:36:35 -0800 (PST) (envelope-from sgk) Date: Sun, 28 Nov 2021 16:36:35 -0800 From: Steve Kargl To: Jason Bacon Cc: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211129003635.GA81568@troutmask.apl.washington.edu> References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J2RHS3ybCz3LHV 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, Nov 28, 2021 at 05:55:32PM -0600, Jason Bacon wrote: > On 11/28/21 16:07, Steve Kargl wrote: > > > > % ps -ww -p 77387 > > PID TT STAT TIME COMMAND > > 77387 2 R 40:34.67 c++ > > > > 40 minutes for 1 file with many exceeding 30 minutes seems a tad bit > > excessive. > > I would bet you have a hardware issue. I've never seen a buildworld take > more than a few hours and that was on some very old hardware. > It's certainly not the latest and greatest, CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz K8-class CPU) ... ada0: ACS-4 ATA SATA 3.x device ada0: Serial Number 1B0607771A0800257271 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) but this laptop has built FreeBSD for several years and each year and with new import of llvm the buildworld times go up, up, up... buildworld is essentially the only thing running on it. last pid: 4921; load averages: 2.17, 2.12, 2.29; b up 4+22:40:32 16:35:53 78 processes: 3 running, 75 sleeping CPU: 0.2% user, 98.0% nice, 1.4% system, 0.4% interrupt, 0.0% idle Mem: 1045M Active, 1543M Inact, 11M Laundry, 776M Wired, 395M Buf, 575M Free Swap: 3881M Total, 84M Used, 3798M Free, 2% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 4918 root 1 106 4 220M 153M RUN 1 2:17 97.05% c++ 4763 root 1 106 4 1140M 924M CPU0 0 13:29 95.20% c++ 4921 kargl 1 20 0 14M 3392K CPU1 1 0:00 1.47% top 1018 kargl 3 21 0 169M 23M select 0 50:22 1.14% Xorg 4889 kargl 1 20 0 22M 8636K select 0 0:00 0.16% xterm From nobody Mon Nov 29 00:36:57 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6831C189BCFD for ; Mon, 29 Nov 2021 00:37:46 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2RJn305pz3M8N for ; Mon, 29 Nov 2021 00:37:44 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.16.1/8.16.1) with ESMTPS id 1AT0bRst092176 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 29 Nov 2021 11:07:27 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1638146251; bh=LcZljnnueZImvrlwq+dXR/p1iJCbbevdQ6V1d2fU67E=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OaiTfxiUV72aCTDBEowyP1IkwQ9IrcOgviCEiL34jC/t5ysr9KezLf0cpom7qI5wa uniZfqfVemwZmJyFOmCzlqMz9B6Vmrp/0Syyj2Y8SPBVKnGOFTIlJzAxuQCa9NjpGb CCZQSLF/B11mkiIn5EPRFHY2k6OndpsRT4A7QLuA= Received: (from mailnull@localhost) by midget.dons.net.au (8.16.1/8.16.1/Submit) id 1AT0awq4092168 for ; Mon, 29 Nov 2021 11:06:58 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-f0f0b4ff001831caa5b8ac39868c4c7e9b4d12fc: 2001:44b8:1d2:8900:a9cb:700e:9980:3d76 Received: from smtpclient.apple ([IPv6:2001:44b8:1d2:8900:a9cb:700e:9980:3d76] [2001:44b8:1d2:8900:a9cb:700e:9980:3d76]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 1AT0avY0092163; Mon, 29 Nov 2021 11:06:58 +1030 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: usb serial - need quirk? In-Reply-To: <11EBCD70-3259-4E4D-8B9C-9F25364BC73C@cs.huji.ac.il> Date: Mon, 29 Nov 2021 11:06:57 +1030 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: <20F9C20E-BB89-4FC1-A339-171447368AD2@dons.net.au> References: <11EBCD70-3259-4E4D-8B9C-9F25364BC73C@cs.huji.ac.il> To: Daniel Braniss X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4J2RJn305pz3M8N X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: darius@dons.net.au From: Daniel O'Connor via hackers X-Original-From: Daniel O'Connor X-ThisMailContainsUnwantedMimeParts: N > On 29 Nov 2021, at 03:39, Daniel Braniss wrote: >=20 > hi, > this usb device (actually the micro usb on a esp32c3) is reported by = FreeBSD 12.1 as: > ugen0.10: at usbus0, cfg=3D0 md=3DHOST= spd=3DFULL (12Mbps) pwr=3DON (134mA) >=20 > and dimes shows: >=20 > Nov 28 19:02:19 pampa kernel: ugen0.10: at usbus0 > Nov 28 19:02:19 pampa kernel: umodem0 on uhub3 > Nov 28 19:02:19 pampa kernel: umodem0: on usbus0 > Nov 28 19:02:19 pampa kernel: umodem0: data interface 1, has no CM = over data, has no break >=20 > it=E2=80=99s the last line that I think is causing failure to flash = the device (probably needs the break to set the speed?) Why would it need break to set the speed? > any ways, is there some fix for this? You didn't actually post the problem you are having so it's impossible = to say :) I assume esptool fails but it would be helpful if you posted the output. I haven't used an ESP32-C3 but all of the other ESP's don't have USB = built in so it depends what USB UART you have on your board - any idea = which one it it? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Mon Nov 29 01:42:16 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1626118AA4E1 for ; Mon, 29 Nov 2021 01:42:11 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 4J2Sl66hZJz3vTx for ; Mon, 29 Nov 2021 01:42:10 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qv1-xf33.google.com with SMTP id m17so12971013qvx.8 for ; Sun, 28 Nov 2021 17:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Kdfim5zP21PTzCXOoduTzFjhseT/PWsbTp06YrwgwIs=; b=AMRdBcTyKhy+d/wELT5i5y5URbOTJPE2IXG3dAw1kbyCfVn00EmhLMbFn2E/oc/tKy 3kDp0DQq7skKy+7dl85r42TIbjX1Nc1iO3vDepvb07L+w10qFEoWyCT9I8ZABAO9ytyz RHGP23ylfILWxc1Ml41wa27sKxw6SHjemdZnD4AG4MacjfUwKF15drm8Wf8Vi9qiePPg gMIQSbCr4F2wkB9Vx5YwWEJ4da8D6ngbuM8IHrUV9+dQIrliLbfJszJIHWGrBE2n2/Ag CM8tjz+ajDCIEBWlWtObio/lRZGF1NaZIDwodOJYGKh+NXssPQJZfY4CfiMSBHXoxQ52 j9Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Kdfim5zP21PTzCXOoduTzFjhseT/PWsbTp06YrwgwIs=; b=f/Ww9IpRGEEIGtZ1LBh8Ybg+THqZUjcemTNEdjAzDDFAo6zIc7g+wvZ6U8XfvtapSl Da4lwa4zDMQewVxUricSs34nxSJcTuI+GIROtcSkjoa3fG2yv29pW9d/jS5S3zGcyQwn JBX8wC0d/hjj8QCMuq/xuGjEkRXx3ipA3SG51FNJ+pnlJaxmlMiqwNUJiD72ByVxmUZq u3NyVWW6S0+zzGj+DGETZdhnkETBEvPnfCdNHdU2b26HAu+e8NKkZp4kfvaxyBQ6Zssi z9KS5qHhKu3B41IMsHCh9ouJ/JFooE6RF5YN5/n94HFG4Ov4y98CugwWpcg54Hq520kW mt7Q== X-Gm-Message-State: AOAM532dk+UiN4wz6byCnzvCB3qxkgqCWdQnndU3egJrXcaETDcjjJPL 0zGk7Gkx7NCBoJ5hXIJNBOYliJZhpbA= X-Google-Smtp-Source: ABdhPJxPaAljl16NJnlWwFfq6mEJCdVAbYonlQHXBFnykP090i2Bws4PX3NAyXgDGtwKLGgfZeNN+g== X-Received: by 2002:a05:6214:401e:: with SMTP id kd30mr27712254qvb.80.1638150130539; Sun, 28 Nov 2021 17:42:10 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:6e88:14ff:fea7:590c? (2603-6000-a401-3a00-6e88-14ff-fea7-590c.res6.spectrum.com. [2603:6000:a401:3a00:6e88:14ff:fea7:590c]) by smtp.gmail.com with ESMTPSA id z10sm8047119qtw.71.2021.11.28.17.42.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Nov 2021 17:42:10 -0800 (PST) Message-ID: <836e9e78-7220-c3aa-796c-7f31b23aae6f@gmail.com> Date: Sun, 28 Nov 2021 19:42:16 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: Steve Kargl Cc: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> From: Jason Bacon In-Reply-To: <20211129003635.GA81568@troutmask.apl.washington.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J2Sl66hZJz3vTx 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 11/28/21 18:36, Steve Kargl wrote: > On Sun, Nov 28, 2021 at 05:55:32PM -0600, Jason Bacon wrote: >> On 11/28/21 16:07, Steve Kargl wrote: >>> >>> % ps -ww -p 77387 >>> PID TT STAT TIME COMMAND >>> 77387 2 R 40:34.67 c++ >>> >>> 40 minutes for 1 file with many exceeding 30 minutes seems a tad bit >>> excessive. >> >> I would bet you have a hardware issue. I've never seen a buildworld take >> more than a few hours and that was on some very old hardware. >> > > It's certainly not the latest and greatest, > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz K8-class CPU) > ... > ada0: ACS-4 ATA SATA 3.x device > ada0: Serial Number 1B0607771A0800257271 > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > but this laptop has built FreeBSD for several years and each > year and with new import of llvm the buildworld times go up, > up, up... > > buildworld is essentially the only thing running on it. > > last pid: 4921; load averages: 2.17, 2.12, 2.29; b up 4+22:40:32 16:35:53 > 78 processes: 3 running, 75 sleeping > CPU: 0.2% user, 98.0% nice, 1.4% system, 0.4% interrupt, 0.0% idle > Mem: 1045M Active, 1543M Inact, 11M Laundry, 776M Wired, 395M Buf, 575M Free > Swap: 3881M Total, 84M Used, 3798M Free, 2% Inuse > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 4918 root 1 106 4 220M 153M RUN 1 2:17 97.05% c++ > 4763 root 1 106 4 1140M 924M CPU0 0 13:29 95.20% c++ > 4921 kargl 1 20 0 14M 3392K CPU1 1 0:00 1.47% top > 1018 kargl 3 21 0 169M 23M select 0 50:22 1.14% Xorg > 4889 kargl 1 20 0 22M 8636K select 0 0:00 0.16% xterm > CPU utilization close to 100% would pretty much rule out a disk bottleneck, assuming it stays at that level most of the time. I would watch it closely for a while, as well as the swap stats. I would guess the compiler WCPU will plummet at some point if it's taking half an hour to compile one file. -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From nobody Mon Nov 29 03:17:00 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C4D5318AED0B for ; Mon, 29 Nov 2021 03:17:24 +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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2Vs05C47z4txS for ; Mon, 29 Nov 2021 03:17:24 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f50.google.com with SMTP id v23so19554964iom.12 for ; Sun, 28 Nov 2021 19:17:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vs3MevXtWYncfslw8W6hhYc4QWQs2Rylg+71kcVbAhU=; b=d40ILjMkvDYxAqk6D2MoHu94mfDz2dQPmoliFJrwFFvkb/pVnpe6FGwjXVH8jv4FKx FRVil9aZmEI5ntgTzX2jKqVZPclP7s9xFNKTNprREDfXFKUxiRY3r3/1CgJBzRvw5BtI w6diOB+mtBBCdQ5ORzUeCfhKcRukoDXq2dodu22Me3ulTHTfBgGDUHTVK2jOF5ov+mnI MEzS886kt8rByq/hsJGwgBTUFiYyqPSCS/fNGN/HR0mvGKFrkKpq+ksKoNmeSwWrHzUX pogCu8kEoPXE+QOWdsvJfp1AaFRJ2j8ndPFI0yfZDD9DIOk+b25NKzh5ClgPa+si4UXv x7lA== X-Gm-Message-State: AOAM533QcmMcK45PWNC+kq22NTC4uy7DLHFJTwes5EK1seYiZ32R/zIt AY8ifs2ljDpQiZr68PvRDYvNVgfTH7V1Funw0PU= X-Google-Smtp-Source: ABdhPJy/w71PGeyNaVYtvXR6xLijMefyfUtmmMkS9zgo4i7EXIlaiM9tyM1znt9ph17ofspQzHwv+BHqwXbaGTwCgeQ= X-Received: by 2002:a5d:818a:: with SMTP id u10mr53884298ion.140.1638155837969; Sun, 28 Nov 2021 19:17:17 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> In-Reply-To: <20211129003635.GA81568@troutmask.apl.washington.edu> From: Ed Maste Date: Sun, 28 Nov 2021 22:17:00 -0500 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Steve Kargl Cc: Jason Bacon , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J2Vs05C47z4txS 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, 28 Nov 2021 at 19:37, Steve Kargl wrote: > > It's certainly not the latest and greatest, > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz K8-class CPU) If you're content to use a compiler from a package you can save a lot of time by building with `CROSS_TOOLCHAIN=llvm13` and `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. Cirrus-CI builds CROSS_TOOLCHAIN and WITHOUT_TOOLCHAIN to reduce build time significantly, given that the vast majority of CI build/test runs are not targeting compiler changes. From nobody Mon Nov 29 03:52:39 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7300618BF11C for ; Mon, 29 Nov 2021 03:52:47 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2Wdp3B4Hz3M6b for ; Mon, 29 Nov 2021 03:52:46 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ua1-x92f.google.com with SMTP id t13so31219337uad.9 for ; Sun, 28 Nov 2021 19:52:46 -0800 (PST) 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; bh=detsIJV80Wk3OzA8HatEOEs+zODEe6gs0dgUXDOfvgE=; b=dgK4NJC9EDHITMHxF/J7AXZlrECE+rZjD9jmmTXXPbRPcx7c+tfa8wnwjg5nyxjmu4 p6CGuT8ljh15gxKoEOyzVEUoexjct4BP90+iDYZEgukGK8V+jpgKZJEKwYvDMC/K6l9Y 92iGwkwBqyumS/YyS+wSfOOAVe2pTawtohm3s8zpJof+mNujBWABz3CwrojeyHjw7r/v vpU2xF24V1NHgVTv6kNIcaF4t4u4WdJ2XxqQJXg6vo0CuJi+pu1UBDsRuDnxwDVhhZoZ batA9vG2G6/hJTWelg/8aOPyFSaTzLNNhVdm6gIakGcrv1B6iybj88PZKO4rm+T9sRlp KSqg== 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; bh=detsIJV80Wk3OzA8HatEOEs+zODEe6gs0dgUXDOfvgE=; b=CAvf3Ghj/WyBxa/ZSnPh2Ad1x1jgxVeVqNpWl2YzF1ZzBnPdKok9qoNBacTwJJ/smD ajkRgcjW7wRGS1XZOi3uEF1ahd0CfvpVqIanh/m5SsE6hH2O2/2ACoPQY5ZAkPUTJ56+ FZz3Uk1HOssB8Rw/X1V73PS1pZ6VsffMsApQH+rJwx3I+U5NdVCdNNbWMwXGb6frTHhm GYDdHtALvwzH62x4k+Rd++09gW/wH1+IXuaiRBun13z5ZczKqow2ypMt5XX744y0h6jN 1ruYyy/8pfWAwN9np20OwBmxvw9Fc65DelA2kpN7/eVhOqwtNRGCoW1YUaXXdRCrh8rg 49BA== X-Gm-Message-State: AOAM530s3L33HHy+JjUGMyBxusD95gBzpWXIjvnLVJv2C6Octs0WQvUk p4thJslPo5KQeaJsKTNg4/xDXWcpJr1+lJ11dp995q/5lXdBNQ+Q X-Google-Smtp-Source: ABdhPJx8gor9hwgMVCSE+F2/hJTM0s5a3XVJTinFW8xnNBNpdQr4P0CMJfMcpZcE8AZQ1p2gkQd+lZ5KuCTxE2hMnPw= X-Received: by 2002:a05:6102:e0f:: with SMTP id o15mr29637871vst.51.1638157960262; Sun, 28 Nov 2021 19:52:40 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:9946:0:b0:248:630f:3460 with HTTP; Sun, 28 Nov 2021 19:52:39 -0800 (PST) In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> References: <861r36xzpe.fsf@phe.ftfl.ca> From: grarpamp Date: Sun, 28 Nov 2021 22:52:39 -0500 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J2Wdp3B4Hz3M6b X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=dgK4NJC9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::92f as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.47)[-0.471]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92f:from]; 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:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N jail -t , sets the initial time inside the jail at launch, from which time then progresses inside as usual. From nobody Mon Nov 29 03:58:05 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 474EF18C2B84 for ; Mon, 29 Nov 2021 03:58:17 +0000 (UTC) (envelope-from ozkan.kirik@gmail.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 4J2Wm83t9mz3PZ4 for ; Mon, 29 Nov 2021 03:58:16 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x92c.google.com with SMTP id p2so31173219uad.11 for ; Sun, 28 Nov 2021 19:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=OYABjSfhjB++JPCZBF1/+ptlcBqh8tWqArv+epMMFM0=; b=N+HeyBgg+gVD5ajyGyLZCNQ0MI3uMYsPwqSWqvInGCAZeIBCwxRO7erct76F/1HyH1 557qVAAYgh6TLg8xQjep6ERFgIvDQIISPhqIfrrGKm2BpjVa/xNMjtt6TTUlb4q9wMqK rZJKHcXFJzL+zc6HwMA2BmOSeFEbsBSvduZn1HnaRnM4Be20AkOJkMn2REhG2dm5YEfP 7Dws8DqUVLg2FaAEDo945FuY2Z9QPJoc+0VX2aM98pjxvqgt6GOdxH+Q3Wk8/kPv3/k3 UA3p2E/Z4RR4iN+5+uM7U4Yqo+Z/cG/gsgAZzQcEcP/xErUw2U3V3Y6e3BTI8i4/xXUi 9WWg== 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:cc; bh=OYABjSfhjB++JPCZBF1/+ptlcBqh8tWqArv+epMMFM0=; b=QG2Yf4Q99MTfMpplo4HDR2Gg2FF6VeijeanFSWmEnnPCHwoQopXmlY4T9AHwBJX3BN AvAKYVx9BXArdiusdJ/WNUmsHfIghJwIxEdZgeNHKdQbWWC221SnhhlUbxWkBolx5WEz 7Z3oSKoCsVn3//s7iemTTbjSJwuDojeJZocNNCcOaVnR77Ia+ZF2GBjfW/K/tQD8vHy8 9Vl3+Vk3IAcZl3e8zCnTu1OXGzMpoPHL/Rup+wkMY4qwxyIFY20Ce59wX2IMZ5XQt6sN FKNzGKo9kE+vnHOJiySO+6dJOLRxF14S6YV7nQUCUY/VGpoJeZ8c5Ypm7q89j3LTzbqn UAMA== X-Gm-Message-State: AOAM53197CScogknYLdsgHMlRBo2NZ9fBD/AQJL5AEFDNqyO/yOnlmcO 1wVZIDAqFSlWE63WXlGAuIH2QhmxA3pyFGlza9ASq1f8 X-Google-Smtp-Source: ABdhPJzCbWjaaV+j9oTfJDNIJH9j4CAt3cjWG3W04A8p9k9l70H9AJQvPe6Y3v5o7IKaj5CyJM3HdQWmkvB0sdaht1k= X-Received: by 2002:a67:c90a:: with SMTP id w10mr30339692vsk.56.1638158296009; Sun, 28 Nov 2021 19:58:16 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Mon, 29 Nov 2021 06:58:05 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J2Wm83t9mz3PZ4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=N+HeyBgg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::92c as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [-1.43 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MISSING_TO(2.00)[]; 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:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; R_MIXED_CHARSET(0.56)[subject]; 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(-0.98)[-0.982]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92c:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Now, FreeBSD doesn't have a good Traffic Shaper. ALTQ doesn't support multiqueue NICs. DUMMYNET is single threaded and it's easly to saturate cpu core with high pps rates. We need a good, multiqueue NICs supported and multi threaded traffic shaper. Some NICs can offload "tc". Is it possible to port "tc" to FreeBSD ? But I don't know if "tc" meets this requirements. Have a nice day On Mon, Nov 29, 2021 at 6:53 AM grarpamp wrote: > > jail -t , sets the initial time inside the jail at launch, > from which time then progresses inside as usual. > From nobody Mon Nov 29 04:05:27 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EFB3A18C6314 for ; Mon, 29 Nov 2021 04:05:38 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 4J2Wwf6Ggfz3hjb for ; Mon, 29 Nov 2021 04:05:38 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-vk1-xa32.google.com with SMTP id u68so10079528vke.11 for ; Sun, 28 Nov 2021 20:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc :content-transfer-encoding; bh=+3WZ4ipaNNTHFNXqURBCvMqNkdtPL83SrfBgWcMrN4A=; b=S5lO7u3U1Fz/RaJtPIa0aPo1J1AppHo93gqH5f2TggQ1OJ64udIxJX4eeADNaCZcAX WF84DATGlAK3ZJQkWGW6T4rPN5KuSkPaBVrXStnGy7Xpit/T/vlGI3A8EnswLQmxXaqH 7bNpf40Yr7skvP38uG1Sb+/cCLWtsyJmFdxWf9elL5sRH9FCbm+i7qNCKSOv+nFWdh56 ZHJZVfhYMS/CGiHfZGW+gsWMibIbtAu9vXCcF2ejV9LTS0JVK8qUKG+1X5JAMIyBuGJX pN9qlnN9DYUti+lS8VkZI2ITdR86sbyHqSgfA+B+7+vh9J6U9n4xmqMB5MwmAbor8/cL N5zQ== 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:cc:content-transfer-encoding; bh=+3WZ4ipaNNTHFNXqURBCvMqNkdtPL83SrfBgWcMrN4A=; b=X2c2YHOKQ8Vbjb70DSKSD5w5EZQUOEXotAwmFlX6GRS7rKl3WRZZkvIxAAmhQNDBqd nbNNnUg023ztL81EJfJ4vIzA24R10DVKAgU9tBO1oVy4A4nqDKjLWlMuhuSwyJG01cBU 9Ax1YVMk3uyXRodevq9nrwjioHP38j1dGJDVmMDFa8MpypvJGp1WyYf6PavQmrqeIsdR axwfyoh5F4bhH+vkwUx0/pH87Q6iMlPQZqlfmOmqvRnPMZp7GJiIkKkU90nKv45ZAL1a 72KRa24OE8boru4eFw9CBwoxTtVCWN/f9JfQwJ7UTBr0LCoE8fMzD8jDHgOs70HuJY48 MDWg== X-Gm-Message-State: AOAM53213OWLu+wah1+Z+J8NNih5wAbl6LPi2YNQ7OEV7VHzORdt8rRm /NFiZyuXs0OsB7QKzBK0ztAjI7q4F+eD2aA7oFleJE7p X-Google-Smtp-Source: ABdhPJzDCtAL27IfjYp3oPP+OWD1NFJ0IERSsTEfIs4qTbUir1yq7rGFl9gR5dDbWlSWWqAx5RZ4knEYAKt3xgxSAFo= X-Received: by 2002:a1f:18cb:: with SMTP id 194mr33587975vky.16.1638158738065; Sun, 28 Nov 2021 20:05:38 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Mon, 29 Nov 2021 07:05:27 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J2Wwf6Ggfz3hjb 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: N SCTP support for pf On Mon, Nov 29, 2021 at 6:58 AM =C3=96zkan KIRIK wr= ote: > > Now, FreeBSD doesn't have a good Traffic Shaper. > ALTQ doesn't support multiqueue NICs. > DUMMYNET is single threaded and it's easly to saturate cpu core with > high pps rates. > > We need a good, multiqueue NICs supported and multi threaded traffic > shaper. Some NICs can offload "tc". Is it possible to port "tc" to > FreeBSD ? > But I don't know if "tc" meets this requirements. > > Have a nice day > > On Mon, Nov 29, 2021 at 6:53 AM grarpamp wrote: > > > > jail -t , sets the initial time inside the jail at launch, > > from which time then progresses inside as usual. > > From nobody Mon Nov 29 04:09:15 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CE7DF18A98B8 for ; Mon, 29 Nov 2021 04:09:26 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2X125K7wz3l1K for ; Mon, 29 Nov 2021 04:09:26 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x930.google.com with SMTP id p2so31217699uad.11 for ; Sun, 28 Nov 2021 20:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc :content-transfer-encoding; bh=8nnMJ33AFiBii2BK3dUIMfegCurfVSAyb4v4+kP59p0=; b=E7fYgZAUCyj7sQJSnybL/4gwY7Ot/G60Gh7FKh2weZ3gbPOpZZgtuNApU5fowwAb0L DI9nndXNangcp35tIAvfbaxdBiQfgCaX9CeJ0Ax49iea18TPIZ6ivvcSEXA6Qf1HHbyx nD1/rnHK3zSz1dx0N8rX7STaXK/dbcjSbF5OjwFMYUFG6sqTyswN8nN6mfcM8cjKMhHp cjcscD/BGAzjiuqUYE1YnhH22Hs72yTZ3UcUhJ6DVR5g9cRxlvsK9p50n+NrqmKQ3aAM qCUZoCN9eB6hxpx9JLF2TvYLGOHb4+o7ppaEj29ROw6d+DwuvEOT6acaaAE7RVn6NF8H uAiA== 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:cc:content-transfer-encoding; bh=8nnMJ33AFiBii2BK3dUIMfegCurfVSAyb4v4+kP59p0=; b=xXxA12dwbE57tU2jYmFtovL07FzlNX6iTMiQA9Nzj+7CPQ+zdC/cIpYNio3zabrp70 TDqIfT1P/zvvOgLilK7DHAw4VmMm/64dTF9P4xrlLUPLCHN4gk8XMcpUmQw7zSFO9uaq L0A5Zv6ZO2aFH3ru/N1RCChBdH89I0MgBOCny/s5IE11fhqHJkhi4ubLfQAknTxB4iZH CCcW5nBdNpzZ/yFtuYOY9jkvlLTl1t2cC2/i1pULsX2kCH7cpkgER6GvNZvlNN5LPCyk fdHDSBmJe40U2p2muEOPEH29eNMCqLwNSKiOIQRjK5POhPDOSSk2evhkELCtGwlUjF7E 7G1Q== X-Gm-Message-State: AOAM532h3S+BqPPqkMnk1i0QAd1yoy6UnHPDNCXb5p1QIrnQi0+KbUzz EOy40eBts5KkueHV0vj263HWW4zGHu2PP6Q8F5e0cZlW X-Google-Smtp-Source: ABdhPJxaZ8k6MdJcabZyApvMuSBliAHehak1BTaY5G0ujYbapboUDGk1NaZnopPmg9ongD9YaowDS9yS5szmDMtUjSQ= X-Received: by 2002:a67:c90a:: with SMTP id w10mr30356003vsk.56.1638158966242; Sun, 28 Nov 2021 20:09:26 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Mon, 29 Nov 2021 07:09:15 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J2X125K7wz3l1K 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: N support for "any" interface such as: tcpdump -ni "any" On Mon, Nov 29, 2021 at 7:05 AM =C3=96zkan KIRIK wr= ote: > > SCTP support for pf > > On Mon, Nov 29, 2021 at 6:58 AM =C3=96zkan KIRIK = wrote: > > > > Now, FreeBSD doesn't have a good Traffic Shaper. > > ALTQ doesn't support multiqueue NICs. > > DUMMYNET is single threaded and it's easly to saturate cpu core with > > high pps rates. > > > > We need a good, multiqueue NICs supported and multi threaded traffic > > shaper. Some NICs can offload "tc". Is it possible to port "tc" to > > FreeBSD ? > > But I don't know if "tc" meets this requirements. > > > > Have a nice day > > > > On Mon, Nov 29, 2021 at 6:53 AM grarpamp wrote: > > > > > > jail -t , sets the initial time inside the jail at launch, > > > from which time then progresses inside as usual. > > > From nobody Mon Nov 29 04:36:12 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 99F3718B6B0B for ; Mon, 29 Nov 2021 04:36:14 +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 4J2Xby33kKz3sk4; Mon, 29 Nov 2021 04:36:13 +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 1AT4aCUt082299 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 28 Nov 2021 20:36:12 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1AT4aC9R082298; Sun, 28 Nov 2021 20:36:12 -0800 (PST) (envelope-from sgk) Date: Sun, 28 Nov 2021 20:36:12 -0800 From: Steve Kargl To: Ed Maste Cc: Jason Bacon , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211129043612.GA82224@troutmask.apl.washington.edu> References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J2Xby33kKz3sk4 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, Nov 28, 2021 at 10:17:00PM -0500, Ed Maste wrote: > On Sun, 28 Nov 2021 at 19:37, Steve Kargl > wrote: > > > > It's certainly not the latest and greatest, > > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz K8-class CPU) > > If you're content to use a compiler from a package you can save a lot > of time by building with `CROSS_TOOLCHAIN=llvm13` and > `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps > `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. > > Cirrus-CI builds CROSS_TOOLCHAIN and WITHOUT_TOOLCHAIN to reduce build > time significantly, given that the vast majority of CI build/test runs > are not targeting compiler changes. And therein lies the rub. Cirrus-CI skirts the issue with the slowing down of builds, so developers don't see the problem. I suspect developers also tend to use ccache or meta_mode. Reported "buildworld times" are not really "buildworld times" but more like partial "buildworld times". Unfortunately, I've wasted a weekend trying to get an up-to-date to chase down what may be a bug in (1) how the kernel delivers signals to a thread; (2) a problem with libthr; or a problem with asynchronous IO in gfortran. My REAL buildworld will finish eventually, so I'l be able to look more closely at the issue. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103444 -- Steve From nobody Mon Nov 29 07:05:12 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3FD6518B2C3C for ; Mon, 29 Nov 2021 07:05:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4J2bvy6sTPz54jZ for ; Mon, 29 Nov 2021 07:05:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=kw+WYW8oSJH/nJlEjKp82M6V+HxThuGZ2IM7U8j2IpA=; b=a7RG3JR2woX6bMw25bdUwj370HAjI1TrbxGXua0kxhpl6Tl5a1VAyUZqB/XR0p2HbBBoG1/Hd/iiKwalL84Ufgp53WfhtF/kxBrpsVbn7iBpUSZzKn7GIXwLsfq+Mb1uW77K1zqPTfbiAI+MIp+wyMvOSbXn8fZQ6CRwyfcEQghr0IZJJAZ87T1qmaXvfzpzHR+Am0uwTub+8OXHL9fP0A0O2a60eVTo+Bv/z9Hons5TGebTBa74T2P/6Tyyr4O2SqksOioT5YqpsJaYPdUlaTUAl/2ZHF9JtpDAiwj0zw/J53lx5kopKU8Yf6Qe1scTrJiDA2OQc+s3u+8NnWMg2w==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1mraiv-000CA6-2I; Mon, 29 Nov 2021 09:05:13 +0200 From: Daniel Braniss Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_809D77B7-F639-42C2-988E-9A4197914A37" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: usb serial - need quirk? Date: Mon, 29 Nov 2021 09:05:12 +0200 In-Reply-To: <20F9C20E-BB89-4FC1-A339-171447368AD2@dons.net.au> Cc: freebsd- To: Daniel O'Connor References: <11EBCD70-3259-4E4D-8B9C-9F25364BC73C@cs.huji.ac.il> <20F9C20E-BB89-4FC1-A339-171447368AD2@dons.net.au> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J2bvy6sTPz54jZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_809D77B7-F639-42C2-988E-9A4197914A37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Nov 2021, at 02:36, Daniel O'Connor wrote: >=20 >=20 >=20 >> On 29 Nov 2021, at 03:39, Daniel Braniss wrote: >>=20 >> hi, >> this usb device (actually the micro usb on a esp32c3) is reported by = FreeBSD 12.1 as: >> ugen0.10: at usbus0, cfg=3D0 = md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (134mA) >>=20 >> and dimes shows: >>=20 >> Nov 28 19:02:19 pampa kernel: ugen0.10: at usbus0 >> Nov 28 19:02:19 pampa kernel: umodem0 on uhub3 >> Nov 28 19:02:19 pampa kernel: umodem0: on usbus0 >> Nov 28 19:02:19 pampa kernel: umodem0: data interface 1, has no CM = over data, has no break >>=20 >> it=E2=80=99s the last line that I think is causing failure to flash = the device (probably needs the break to set the speed?) >=20 > Why would it need break to set the speed? don=E2=80=99t know, but I=E2=80=99ve seen in the past serial stuff that = needed the break to synchronize. >=20 >> any ways, is there some fix for this? >=20 > You didn't actually post the problem you are having so it's impossible = to say :) > I assume esptool fails but it would be helpful if you posted the = output. the flashing keeps failing with: Chip is ESP32-C3 (revision 3) Features: Wi-Fi Crystal is 40MHz MAC: 7c:df:a1:a3:61:74 Uploading stub... A fatal error occurred: Failed to write to target RAM (result was = 01070000) >=20 > I haven't used an ESP32-C3 but all of the other ESP's don't have USB = built in so it depends what USB UART you have on your board - any idea = which one it it? all the other esp32 I have work fine, it=E2=80=99s this esp32c3 that = fails. anyways, i got hold of a ttl to usb from m5stack, and after some = fiddling got it to flash! this chip is CP2104, so the problem seems to be in the driver for the unknown chip on this = esp32c3 - no indication in the diagrams, nor can I read the micro words on the chip = :-( thanks, danny >=20 > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum --Apple-Mail=_809D77B7-F639-42C2-988E-9A4197914A37-- From nobody Mon Nov 29 07:24:20 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 06C6F18B722E for ; Mon, 29 Nov 2021 07:24:45 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2cLN3b26z583f for ; Mon, 29 Nov 2021 07:24:44 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.16.1/8.16.1) with ESMTPS id 1AT7ORSM082797 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 29 Nov 2021 17:54:32 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1638170675; bh=51fH60+9DHg0gTouR6fwyo7gF4Z33maCZTQrw82ZZ6s=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=W7lrs59aTcEcMsGZ2z+QTnZNcAHfggUSUj2rOsL5+yyoYafUfJiHHA8BlPnaPFZAr Erv7eE5KbU+c23nXvM0ED8xgBFX64Jl833wO6VqLu5h4WAwp8HwF55DLe5VWkKIPEB Mbvq99s1DxoBRH6va+pOrPaWrLUYdBhG9MOKn8Zg= Received: (from mailnull@localhost) by midget.dons.net.au (8.16.1/8.16.1/Submit) id 1AT7OLKk082789 for ; Mon, 29 Nov 2021 17:54:21 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-f0f0b4ff001831caa5b8ac39868c4c7e9b4d12fc: 2001:44b8:1d2:8900:a9cb:700e:9980:3d76 Received: from smtpclient.apple ([IPv6:2001:44b8:1d2:8900:a9cb:700e:9980:3d76] [2001:44b8:1d2:8900:a9cb:700e:9980:3d76]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 1AT7OKI1082784; Mon, 29 Nov 2021 17:54:21 +1030 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: usb serial - need quirk? In-Reply-To: Date: Mon, 29 Nov 2021 17:54:20 +1030 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: References: <11EBCD70-3259-4E4D-8B9C-9F25364BC73C@cs.huji.ac.il> <20F9C20E-BB89-4FC1-A339-171447368AD2@dons.net.au> To: Daniel Braniss X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4J2cLN3b26z583f X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: darius@dons.net.au From: Daniel O'Connor via hackers X-Original-From: Daniel O'Connor X-ThisMailContainsUnwantedMimeParts: N > On 29 Nov 2021, at 17:35, Daniel Braniss wrote: >>> it=E2=80=99s the last line that I think is causing failure to flash = the device (probably needs the break to set the speed?) >>=20 >> Why would it need break to set the speed? > don=E2=80=99t know, but I=E2=80=99ve seen in the past serial stuff = that needed the break to synchronize. >>=20 >>> any ways, is there some fix for this? >>=20 >> You didn't actually post the problem you are having so it's = impossible to say :) >> I assume esptool fails but it would be helpful if you posted the = output. > the flashing keeps failing with: > Chip is ESP32-C3 (revision 3) > Features: Wi-Fi > Crystal is 40MHz > MAC: 7c:df:a1:a3:61:74 > Uploading stub... >=20 > A fatal error occurred: Failed to write to target RAM (result was = 01070000) >>=20 >> I haven't used an ESP32-C3 but all of the other ESP's don't have USB = built in so it depends what USB UART you have on your board - any idea = which one it it? > all the other esp32 I have work fine, it=E2=80=99s this esp32c3 that = fails. > anyways, i got hold of a ttl to usb from m5stack, and after some = fiddling got it to flash! > this chip is CP2104, > so the problem seems to be in the driver for the unknown chip on this = esp32c3 - no > indication in the diagrams, nor can I read the micro words on the chip = :-( I had a look at the ESP32-C3 datasheet and it *does* have a USB = interface built in and it talks about a CDC-ACM virtual serial port = which matches what you see. The only ACM quirk I can see is UQ_ASSUME_CM_OVER_DATA so you could try = that I suppose.. (See the usb_quirk man page) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Mon Nov 29 07:39:52 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 286DC18C02DA for ; Mon, 29 Nov 2021 07:39:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4J2cgt5tgdz3Gvg for ; Mon, 29 Nov 2021 07:39:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=W+wMU/F+Bdpstyk949/7xiW0ZbJKHOR4Ri2KVN4EX0U=; b=dAukpgtcCVamOfV+tUqmlBYiH7Z8QVq64NruW8wgp08f3C6OMysCciZeyRL4IValTokN1y/H0CnMPtLoKHYE91qdXHAYI4BFiW1dw9HeuwiDJS377WCjCXi+uFaSOh+ey2kFQA6I6k9oyILPb4YCWg5snSYWRzDsmXhhOwZD74Kz9M4G71z9iWV06dkru1PprDcsiVMp3DhChyNTXrGFD2g2ZoUNlJ/r6+AdHDyIWlpBeSgCechDigCFiXM2MiBpVBEBwEn2CPQghpSk2ObOGzefiN+1X142z/mm16RT0u1CKwVjpglct1wVVMU5gNKKa9duoSJVKNoXGJI2b7IJ/w==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1mrbGS-000DAd-Fh; Mon, 29 Nov 2021 09:39:52 +0200 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: usb serial - need quirk? From: Daniel Braniss In-Reply-To: Date: Mon, 29 Nov 2021 09:39:52 +0200 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: References: <11EBCD70-3259-4E4D-8B9C-9F25364BC73C@cs.huji.ac.il> <20F9C20E-BB89-4FC1-A339-171447368AD2@dons.net.au> To: Daniel O'Connor X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J2cgt5tgdz3Gvg 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 29 Nov 2021, at 09:24, Daniel O'Connor wrote: >=20 >=20 >=20 >> On 29 Nov 2021, at 17:35, Daniel Braniss wrote: >>>> it=E2=80=99s the last line that I think is causing failure to flash = the device (probably needs the break to set the speed?) >>>=20 >>> Why would it need break to set the speed? >> don=E2=80=99t know, but I=E2=80=99ve seen in the past serial stuff = that needed the break to synchronize. >>>=20 >>>> any ways, is there some fix for this? >>>=20 >>> You didn't actually post the problem you are having so it's = impossible to say :) >>> I assume esptool fails but it would be helpful if you posted the = output. >> the flashing keeps failing with: >> Chip is ESP32-C3 (revision 3) >> Features: Wi-Fi >> Crystal is 40MHz >> MAC: 7c:df:a1:a3:61:74 >> Uploading stub... >>=20 >> A fatal error occurred: Failed to write to target RAM (result was = 01070000) >>>=20 >>> I haven't used an ESP32-C3 but all of the other ESP's don't have USB = built in so it depends what USB UART you have on your board - any idea = which one it it? >> all the other esp32 I have work fine, it=E2=80=99s this esp32c3 that = fails. >> anyways, i got hold of a ttl to usb from m5stack, and after some = fiddling got it to flash! >> this chip is CP2104, >> so the problem seems to be in the driver for the unknown chip on this = esp32c3 - no >> indication in the diagrams, nor can I read the micro words on the = chip :-( >=20 > I had a look at the ESP32-C3 datasheet and it *does* have a USB = interface built in and it talks about a CDC-ACM virtual serial port = which matches what you see. >=20 > The only ACM quirk I can see is UQ_ASSUME_CM_OVER_DATA so you could = try that I suppose.. > (See the usb_quirk man page) >=20 i=E2=80=99ll try this ASAP, thanks BTW, looking at the m5 stamp c3 diagram, I can=E2=80=99t see how the = usb-typec is connected to the esp32c3 from the esp32c3 docs, it=E2=80=99s gpio9 that needs to be grounded to = flash, and I don=E2=80=99t see that happening when using the onboard usb. oh well, thanks again, danny > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum >=20 From nobody Mon Nov 29 08:16:31 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4206F18B22C5 for ; Mon, 29 Nov 2021 08:17:14 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2dVx5Gbxz3kGq for ; Mon, 29 Nov 2021 08:17:13 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.16.1/8.16.1) with ESMTPS id 1AT8Gvjx022382 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 29 Nov 2021 18:46:58 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1638173828; bh=j6R0kyU4q+XuVCeFLkJLfFnU3TOoLqFHVxzMrDZzJ90=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=VqhP+5I0hrkqAJ9nTBHzprhErBZp7G8xgII6xhZbAQ+sE8KWRDclA9hXrRaoHRH0p Y3iSZ9cuA6cb9/pXcssYgkzDrkwGdocNxbPKhWKYRzP9//deo1upv0MAoktNIFNfhU mNdtO3RdxUKRgMgGnTsAZItWOpTSCGTcHNi9rKmo= Received: (from mailnull@localhost) by midget.dons.net.au (8.16.1/8.16.1/Submit) id 1AT8GVSr022352 for ; Mon, 29 Nov 2021 18:46:31 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-f0f0b4ff001831caa5b8ac39868c4c7e9b4d12fc: 2403:5800:5200:4700:45dc:652d:ba89:512b Received: from smtpclient.apple (2403-5800-5200-4700-45dc-652d-ba89-512b.ip6.aussiebb.net [2403:5800:5200:4700:45dc:652d:ba89:512b]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 1AT8GV6j022347; Mon, 29 Nov 2021 18:46:31 +1030 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: usb serial - need quirk? In-Reply-To: Date: Mon, 29 Nov 2021 18:46:31 +1030 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: References: <11EBCD70-3259-4E4D-8B9C-9F25364BC73C@cs.huji.ac.il> <20F9C20E-BB89-4FC1-A339-171447368AD2@dons.net.au> To: Daniel Braniss X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spam-Score: 0.8 () No, score=0.8 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4J2dVx5Gbxz3kGq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: darius@dons.net.au From: Daniel O'Connor via hackers X-Original-From: Daniel O'Connor X-ThisMailContainsUnwantedMimeParts: N > On 29 Nov 2021, at 18:09, Daniel Braniss wrote: >=20 >> On 29 Nov 2021, at 09:24, Daniel O'Connor wrote: >>=20 >> I had a look at the ESP32-C3 datasheet and it *does* have a USB = interface built in and it talks about a CDC-ACM virtual serial port = which matches what you see. >>=20 >> The only ACM quirk I can see is UQ_ASSUME_CM_OVER_DATA so you could = try that I suppose.. >=20 >=20 >> (See the usb_quirk man page) >>=20 > i=E2=80=99ll try this ASAP, thanks >=20 > BTW, looking at the m5 stamp c3 diagram, I can=E2=80=99t see how the = usb-typec is connected to the esp32c3 > from the esp32c3 docs, it=E2=80=99s gpio9 that needs to be grounded to = flash, and I don=E2=80=99t see that happening when > using the onboard usb. > oh well, The schematic at = https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/static/assets/i= mg/product_pics/core/stamp_c3/stamp_c3_sch_01.webp it has a CH9102F and = some googling suggests it presents as a CDC ACM device. It looks like it has RTS and DTR hooked up so they can reset and drive = GPIO9 for programming. Unfortunately I can't see anything obvious about why it doesn't work :( -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Mon Nov 29 08:42:54 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0C0AA18BF376 for ; Mon, 29 Nov 2021 08:42:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4J2f4d5dBGz3sVK for ; Mon, 29 Nov 2021 08:42:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=UkDKsgYjQwlHFFEScuRWUqG0Um9vCwLqu0XO0dR1CZU=; b=eEZsdJnaY18c1OcFHv0gnKN9q/1qL/XO3ue2KtShAQwlrIBqh4fUS1WfWEO8wdMe0rK0C78skEzpQBtQVv7zOc76zb3uz8II3JXTtLIbI+kxa+MO4x7PVCEwKKyQe8KflEfoh/sic+HxFuf6krYSfdpgOcCnqsQXBXclONRjQRCJP4Gf2Cl2FmP2VNJpXQLOs8uP7DcYWf+1Sc7RityM8pGAwvsH178cZxiOgSwHsM4kaoiloYomO810O8vpb99QQpHawRfqHH8pcrgBZn6lTsYcKuqn2XnywguBAT90sJ1LOSOXeRdr/p9ZwtNWoq4UMFxMppedersfH2B8ckplBA==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1mrcFS-000Gne-SG; Mon, 29 Nov 2021 10:42:54 +0200 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: usb serial - need quirk? From: Daniel Braniss In-Reply-To: Date: Mon, 29 Nov 2021 10:42:54 +0200 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: References: <11EBCD70-3259-4E4D-8B9C-9F25364BC73C@cs.huji.ac.il> <20F9C20E-BB89-4FC1-A339-171447368AD2@dons.net.au> To: Daniel O'Connor X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J2f4d5dBGz3sVK 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 29 Nov 2021, at 10:16, Daniel O'Connor wrote: >=20 >=20 >=20 >> On 29 Nov 2021, at 18:09, Daniel Braniss wrote: >>=20 >>> On 29 Nov 2021, at 09:24, Daniel O'Connor = wrote: >>>=20 >>> I had a look at the ESP32-C3 datasheet and it *does* have a USB = interface built in and it talks about a CDC-ACM virtual serial port = which matches what you see. >>>=20 >>> The only ACM quirk I can see is UQ_ASSUME_CM_OVER_DATA so you could = try that I suppose.. >>=20 >>=20 >>> (See the usb_quirk man page) >>>=20 >> i=E2=80=99ll try this ASAP, thanks >>=20 >> BTW, looking at the m5 stamp c3 diagram, I can=E2=80=99t see how the = usb-typec is connected to the esp32c3 >> from the esp32c3 docs, it=E2=80=99s gpio9 that needs to be grounded = to flash, and I don=E2=80=99t see that happening when >> using the onboard usb. >> oh well, >=20 > The schematic at = https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/static/assets/i= mg/product_pics/core/stamp_c3/stamp_c3_sch_01.webp it has a CH9102F and = some googling suggests it presents as a CDC ACM device. >=20 > It looks like it has RTS and DTR hooked up so they can reset and drive = GPIO9 for programming. >=20 > Unfortunately I can't see anything obvious about why it doesn't work = :( well, I tried adding the quirk but no change, so using a different = ttl2usb works - though needs manual=20 intervention to ground pin 9 - im ok, I need to flash via serial only = once, since after that I can use OTA (unless I screwup and it panics :-) BTW: who ever is interested in the esp-idf the master version now = installs and works almost out of the box on FreeBSD 13.0 thanks, danny >=20 > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum >=20 From nobody Mon Nov 29 08:56:56 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 843B918C5956 for ; Mon, 29 Nov 2021 08:57:08 +0000 (UTC) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (kazi.fit.vutbr.cz [IPv6:2001:67c:1220:808::93e5:80c]) (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 "kazi.fit.vutbr.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2fNz0jLcz4S0X for ; Mon, 29 Nov 2021 08:57:06 +0000 (UTC) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (localhost [127.0.0.1]) by kazi.fit.vutbr.cz (8.16.1/8.16.1) with ESMTPS id 1AT8uux7098611 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 29 Nov 2021 09:56:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fit.vutbr.cz; s=mx1; t=1638176216; bh=NLcYsMv7KjxOcMGaLV1sLJFTyatSUlA8CSSePJxjBAk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=EYYqbXVo61Hp3dcV/+B6Lc5WLnhDO0lox1RXNEg0JfJCMfzQUdL5W823+FC0MqYBC PqHErI+BsTR01zh5W7nWChRfHPlQDrKC1/DfAf/RJWvNWPVQRTUh59GZ4D7LEhbvhc 16Nz4tpuZBKv/+OyM/rFYrzBhbnk5B/nXy/IYkZI= Received: (from cejkar@localhost) by kazi.fit.vutbr.cz (8.16.1/8.16.1/Submit) id 1AT8uuSl098610; Mon, 29 Nov 2021 09:56:56 +0100 (CET) X-Authentication-Warning: kazi.fit.vutbr.cz: cejkar set sender to cejkar@fit.vutbr.cz using -f Date: Mon, 29 Nov 2021 09:56:56 +0100 From: Cejka Rudolf To: Emmanuel Vadot Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-ID: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> X-Rspamd-Queue-Id: 4J2fNz0jLcz4S0X X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fit.vutbr.cz header.s=mx1 header.b=EYYqbXVo; dmarc=none; spf=none (mx1.freebsd.org: domain of cejkar@fit.vutbr.cz has no SPF policy when checking 2001:67c:1220:808::93e5:80c) smtp.mailfrom=cejkar@fit.vutbr.cz X-Spamd-Result: default: False [-2.28 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[fit.vutbr.cz:s=mx1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.982]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[vutbr.cz]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[fit.vutbr.cz:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:197451, ipnet:2001:67c:1220::/46, country:CZ]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I have one problem or two with VT in FreeBSD 12. I wrote a question in freebsd-stable what to do, but without response, so I still have to use SC. Please, could you look at it? There is not configured device /dev/console without monitor after upgrade from 11 to 12 and device /dev/kbdmux0 is busy using VT but not with SC. Subject: Unable to grab keyboard with VT on a headless node in stable/12 Hello, I have a headless node without monitor and without keyboard. There is just network and USB card reader in keyboard mode. In stable/11, there was no problem to disconnect USB card reader from kbdmux using kbdcontrol -A ukbd0 < /dev/console and open /dev/ukbd0 in a program. However, under stable/12 it works just with connected monitor. Without monitor, there is an error: # kbdcontrol < /dev/console -bash: /dev/console: Device not configured Furthermore with default VT, it is also impossible to use /dev/kbdmux0: # kbdcontrol < /dev/kbdmux0 -bash: /dev/kbdmux0: Device busy I have found a workaround using SC, where it is possible to atleast open /dev/kbdmux0 and use kbdcontrol -A ukbd0 < /dev/kbdmux0, but why keyboard operation is now dependend on connected monitor? And why VT does not allow to open /dev/kbdmux0? Thank you. -- Rudolf Cejka http://www.fit.vut.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic From nobody Mon Nov 29 16:12:35 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B6BC518CCDDC for ; Mon, 29 Nov 2021 16:13:15 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2r4B4Ykpz3Kf4 for ; Mon, 29 Nov 2021 16:13:14 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: by mail-ed1-x536.google.com with SMTP id w1so74362004edc.6 for ; Mon, 29 Nov 2021 08:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FFavrgx+cnUY8Hu9SfkouOD7h58pnDt7Euzb2KK2vgk=; b=P0/uB5HVHOIqSglGbqPRih+ADGp525CxnlbKYXdI14s7uCiTyRePISEfHi0ZjP48w3 JLKJB1O8IAmbutLAylNh/6iwR0oAD245GRKtKZ7KpKqdNV4XJtC7iZadBYcBIR6JlJsG XgQXD04SFq8P2h8FSihaoEkgxJTCIRGXwj1iKEsf4NJyl968nrnIXJC5eNbLv/mRJuqp GPYtSmkzHE5dqClhBM+MQ2rj/5fpySkom9cdbjMJRG5Nlj2ZLf4VE9xqyixikNqqaVk7 Y4zgRGN4NpRCY+gY494O3n7BAj/smI50qJdWn1QbkoVWIsJ2nGsNLho56D4VS3BApkEI LCYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FFavrgx+cnUY8Hu9SfkouOD7h58pnDt7Euzb2KK2vgk=; b=t3UBIwHg/8QCeaXmWWT50iL1GkdDV4KYiNZajoS/66VGctEanrH8NO8KOc9NlI6DaL wHO3FSpk5C3tytCOIaJYRAUUv1PjhN5mboet9aMyVWKq+4FE6BTib8nzQIDQfzKOSI24 EPDQf+ZdUvGUbcA8bCMiQE4XD2JwPcNL7K4oFbd/lY94xLxdPhg+rcY65A5zyRDDX5yN z7Ybio4ehjXa+ZfnSl9CtTiXmp5lnFzMnt8U7vuFXnw+70GA3kryDmUZ7eC44rtko9ir QsnAfeJ/cxauNylKwD9ggOylTjf98s4SVWaX4/ZummI54dG9f0lXvwzutmnw403FV9SS waiA== X-Gm-Message-State: AOAM532d8ymQTPE6JMkwmrUXDE3OpopTM8a9+WSiWtqRWp0nv/GruDKT GH/FvkNhXMY4RHLFF23kAnmoTG0UN5qqHBKlBukIs3pZ X-Google-Smtp-Source: ABdhPJxtEtK4RuvTfXIFTxN3Gw4C7o5pehCTn+h2q+bxxuuqSDl9ZgHOyDZX5nI581XmubU9oHENg75KOEQT4GL4CZk= X-Received: by 2002:a17:906:d54d:: with SMTP id cr13mr17625597ejc.409.1638202392111; Mon, 29 Nov 2021 08:13:12 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Stanislaw Adaszewski Date: Mon, 29 Nov 2021 17:12:35 +0100 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Warner Losh Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J2r4B4Ykpz3Kf4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="P0/uB5HV"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sadaszewski@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=sadaszewski@gmail.com X-Spamd-Result: default: False [0.65 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.22)[0.225]; NEURAL_SPAM_SHORT(0.42)[0.421]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_LONG(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]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Made a handful of other changes: 1) Prevent interaction (exit) if autoboot fails (stand/common/interp.c) 2) Wipe env vars and GELI keys before panic()'ing the kernel in case the passphrase marker does not match - probably does not really help much but I guess the idea to narrow the time window any secrets are in memory a good rule of thumb, 3) Call Tpm2NvReadLock() right after retrieving the passphrase from TPM in the bootloader. Therefore, it cannot be read again from the TPM until th= e next restart. Thus, it remains unavailable for example in the booted OS. On Sun, 28 Nov 2021 at 12:19, Stanislaw Adaszewski wrote: > > I have made further modifications: > > 1) As per suggestion - use SYSINIT() and EVENTHANDLER_REGISTER() > in a separate file (tpm2cpm.c) rather than hardcoding in init_main.c. > > 2) Make the functionality configurable / optional both for the kernel > (option TPM2_PASSPHRASE) and the bootloader > (WITH_LOADER_TPM2_PASSPHRASE). The one for the bootloader > is enabled by default and the one for the kernel is enabled by default > in the GENERIC amd64 kernel. > > Best regards, > > -- > Stanislaw > > On Sat, 27 Nov 2021 at 21:35, Stanislaw Adaszewski > wrote: > > > > Hi Warner, > > > > > > Thanks a lot for the quick reaction - that helps. Accordingly, > > I have taken several actions (below). If you have any more tips > > how to push this forward, please let me know. Like I don't know > > is there a person formally responsible for this kind of > > contributions? Let's say when you are happy with the general > > architecture of the solution and the quality of the code > > (it still requires some polishing) - is that enough to pull > > the changes into the codebase? How does that work? > > Thank you in advance! > > > > > > 1. I have rebased my changeset on top of the tip of the > > FreeBSD's main branch [1] > > > > > > 2. I have changed the /.passphrase_marker convention to hold > > (instead of the passphrase) a human-readable lower-case digest > > of SHA256(salt | passphrase) where salt is a new (optional) > > parameter which can be passed using another EFI variable: > > KernGeomEliPassphraseFromTpm2Salt. > > > > I think it is more for the peace of mind than anything else, > > as anyone having access to /.passphrase_marker would normally > > have to be the root user. Nevertheless it is perhaps nicer not > > to keep raw passphrases laying around in files. > > > > We still pass the passphrase to the kernel via a kernel variable > > kern.geom.eli.passphrase.from_tpm2.passphrase which is unset > > before the system becomes interactive. I could be easily > > passing the hash computed by the bootloader instead - what do > > you think? > > > > One thing to keep in mind is that another kernel variable - > > kern.geom.eli.passphrase has been passed around like this > > as well and it is being unset precisely in init_main.c. > > > > But even more importantly, one has to keep in mind that > > geli_export_key_buffer() passes all GELI keys to the kernel > > anyway, so access to the encrypted drives is already possible > > by that alone. Not to mention that the root user can simply > > read the driver's master key with a simple geli show. > > > > > > 3) As an explanation, also to @Ka Ho Ng, the /.passphrase_marker > > serves only as a tag to allow to reliably pair a boot filesystem > > to the keyphrase retrieved from the TPM. If we were to just > > retrieve the passphrase and pass it to any boot environment then > > one would simply boot another OS with another root password and > > could read all our secrets. The same goes for the root filesystem > > that is mounted in turn by the kernel. If one would for example > > remove the boot drive - that would cause the kernel to drop out > > to interactive mountfrom> prompt and then one could for example > > boot from another drive. That is unacceptable. Kernel is by default > > very "boot happy" - it tries really hard to boot SOMETHING rather > > than accept a strict specification of what is allowed to boot. > > > > > > 4) The code is fully functional and I have tested it quite a bit > > on a Zotac CI622 mini-PC with the latest BIOS update which enables > > the TPM functionality on the Intel 10110U process in there. If you > > have a TPM-capable BIOS and CPU, I would encourage you to try, like > > this you will understand better how it works and that the design is > > necessary like it is with the /.passphrase_marker. I am not 100% sure > > if there are no ways left to fool the system to boot or run some > > arbitrary code. Such attacks would generally consist of causing some > > kind of errors on the "trusted" UFS-on-GELI or ZFS-on-GELI systems and > > making the system drop out into some kind of interactive prompts. I > > hope that does not happen. For example if one removes the drive during = init. > > I would certainly expect that no process drops out to interactive promp= ts > > on a system with a root password set bit this kind of scares is > > a tradeoff of not using full VERIEXEC. It is however very convenient > > to say - just trust everything on the XXX-on-GELI since this was encryp= ted > > and therefore tampering-proof. More tests are necessary but also - VERI= EXEC > > can be enabled in addition to that to ensure that such weird scenarios = do not > > happen. > > > > > > 5) @Ka Ho Ng what you said is taking place clearly, the code relies on = a PCR > > policy of user's choice and uses that to read the passphrase. > > > > > > 6) Regarding ZFS encryption I am not sure if that is supported in the E= FI > > bootloader - at first glance I would say that it isn't. With that said, > > the code can be used to further modify the loader to read any kind of > > values stored in the TPM and put them in kernel variables for later use > > in the boot process. Just a big WARNING, kenv seems to let even lusers = to read > > the variables. So whatever one would do with them, it would have to be = done > > quickly and the variables would need to be discarded before letting > > the lusers log in. > > > > > > [1] https://github.com/sadaszewski/freebsd-src/compare/main...main-cher= ry-pick-tpm-support-in-stand > > > > > > Kind regards, > > > > -- > > Stanislaw > > > > On Sat, 27 Nov 2021 at 18:00, Warner Losh wrote: > > > > > > > > > > > > On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski wrote: > > >> > > >> Dear All, > > >> > > >> Could you please guide me so that we can together integrate > > >> the following piece of work into the FreeBSD base system? > > >> Thank you for your time and consideration. > > > > > > > > > See below for some advice. > > > > > >> I have created the following bundle of work [1]. The referenced > > >> patch implements on top of releng/13.0, the support for TPM2 > > >> in the EFI bootloader and in the kernel in order to allow for > > >> storage and retrievel of a GELI passphrase in a TPM2 module, > > >> secured with a PCR policy. > > >> > > >> The way the bootloader behavior is modified is the following: > > >> > > >> 1) before calling efipart_inithandles() an attempt to retrieve the > > >> passphrase from a TPM2 module might be performed - > > >> how this is achieved is described later on. > > >> 2) if a passphrase is indeed retrieved, then after determining > > >> currdev, the currdev is checked for the presence of a > > >> /.passphrase_marker file which must contain the same passphrase > > >> as retrieved from the TPM. This is supposed to ensure that we > > >> do not end up booting an environment not on the device we just > > >> unlocked with the passphrase. > > >> 3a) If all is go, the autoboot_delay is set to -1 in order to preven= t > > >> any interaction and continue the boot process of the "safe" environm= ent, > > >> a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set > > >> to the passphrase from TPM in order for kernel use later, as well as= a > > >> kern.geom.eli.passphrase.from_tpm2.was_retrieved'=3D'1' variable. > > >> 3b) If the passphrase marker does not match, the bootloader cleans u= p > > >> GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits= . > > > > > > > > > I worry about information disclosure having the pass phrase available= on the running system with this setup. Can you explain why that design poi= nt was selected? Usually there is something signed with a private key that = the public key can be used to verify instead of a direct comparison like th= is to prevent disclosure of key material. I've not looked at the code yet, = so it may already do this... > > > > > >> The way the kernel behavior is modified is the following: > > >> > > >> 1) In init_main.c, after vfs_mountroot() a check is added > > >> 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not > > >> set to 1, then we do nothing and continue the boot process > > >> 2b) If the was_retrieved variable is set to '1' then we check for th= e > > >> same passphrase marker as the bootloader, its content compared > > >> against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' > > >> variable. > > >> 3a) If all is go, the passphrase variable is unset and the boot proc= ess > > >> continues, > > >> 3c) If the passphrase marker does not match, we panic. > > > > > > > > > I'm sure that main_init should not know about geom or geli. This is u= sually done with a handler of some sort so the mountroot code can just call= the generic handler. Can your code be restructured such that this is possi= ble? The reason I ask is that ZFS supports encryption too and it would be = nice to use that instead of geli. > > > > > >> The configuration of the bootloader for this procedure looks the fol= lowing: > > >> > > >> 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex > > >> to contain the TPM2 NV Index we store our passphrase in, e.g. 0x1000= 001 > > >> 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr > > >> to contain the PCR policy used to secure the passphrase, e.g. > > >> sha256:0,2,4,7 > > >> 3a) If both are set, the bootloader will attempt to retrieve the pas= sphrase > > >> and behave in the modified way described above > > >> 3b) Otherwise, it behaves as the vanilla version and will ask for GE= LI > > >> passphrases if necessary > > >> > > >> The configuration of the TPM and the passphrase marker looks the fol= lowing: > > >> > > >> 1) echo -n "passphrase" >/.passphrase_marker > > >> 2) chmod 600 /.passphrase_marker > > >> 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7 > > >> 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L > > >> policy.digest -A "policyread|policywrite" > > >> 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,= 2,4,7 > > >> > > >> [1] https://github.com/sadaszewski/freebsd-src/compare/releng/13.0..= .tpm-support-in-stand > > > > > > > > > This sounds cool. Any chance you can rebase this to the tip of the ma= in branch? All code goes into FreeBSD that way and 13.0 is about a year old= already. > > > > > > Thanks for sharing this. Despite some reservations expressed above, I= think this has potential to be quite cool. > > > > > > Warner > > > > > >> > > >> Kind regards, From nobody Mon Nov 29 16:29:30 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3812318AD700 for ; Mon, 29 Nov 2021 16:29:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2rRS14Q4z3QBh for ; Mon, 29 Nov 2021 16:29:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f44.google.com with SMTP id c3so22297915iob.6 for ; Mon, 29 Nov 2021 08:29:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dnxfSbzRea0js2l2z6qQRkDRCql02gSWZKHDtdmbcuo=; b=N2aBCWbLN93FlAzMMA/Z1FgL3GVm8Xxbt1HD5b2QGrYOpV7q/tfqqBUD7qjWj1pchy vw3kx8O2uuZ6Erf4r4VV4eaQIgYhsI8pIJ09Jh8ZYhUbtF+LQPcgv3FRZOw0IRkTYt4W KG1JjkzW0WwT1Rp04yWRzmAl5NPnA0+F4vLEeMUPD0K+8mt1I1ttqOl6NE/MjhLlbwzT Gp81f2GXF4NpCq+ZYKjMutHBL0QXRueBAknzycrTaMLlFP/9djMqXTg6qh2m/SCqLkgq jefqB3TtBntL4OeLAQghzhB3DVvLMVCTCYL9NHUFkLgV8qtzKeKfseY/Wq57d0Lw412Q TEqg== X-Gm-Message-State: AOAM530sqXNP47ZLVvGeQtm0BbDoog6gvA9m4PKDg6eg0iFf5s0EQj/6 ia3yE93GTum3jjDwREJriP+0fRoZTqQPmmtPk6SiqpEY X-Google-Smtp-Source: ABdhPJw/P4r4tCNXCZ9gIBUVf0XszXRhFwEYnimZAHqnnjHTAqCw8Es5ycg0ilpR7IJE24/wnwdF7eaP+XULHI1eB8Q= X-Received: by 2002:a5d:818a:: with SMTP id u10mr56964247ion.140.1638203389309; Mon, 29 Nov 2021 08:29:49 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> <20211129043612.GA82224@troutmask.apl.washington.edu> In-Reply-To: <20211129043612.GA82224@troutmask.apl.washington.edu> From: Ed Maste Date: Mon, 29 Nov 2021 11:29:30 -0500 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Steve Kargl Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J2rRS14Q4z3QBh 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, 28 Nov 2021 at 23:36, Steve Kargl wrote: > > And therein lies the rub. Cirrus-CI skirts the issue with the > slowing down of builds, so developers don't see the problem. This isn't the case. Developers are well aware that buildworld takes longer than desirable, but it's reasonable on contemporary hardware. Cirrus-CI and Jenkins are adjunct to the development process, they don't replace local buildworlds. From nobody Mon Nov 29 21:19:59 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6722618B2789 for ; Mon, 29 Nov 2021 21:20:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 4J2ytC31glz4khJ for ; Mon, 29 Nov 2021 21:20:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2c.google.com with SMTP id 14so23286531ioe.2 for ; Mon, 29 Nov 2021 13:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=0DClOK/SU9dbYuTVVD0V6yII2Om+InwpA+f9+cJzkMQ=; b=PQmQMwbiXohith+ZA0yF92lMi403a4eYFeiE21Mx++vFaOu7HyK5af1dWgzL2So4j5 rmt24+UvhSmTGqfpJoIW89Y8EleWLWwBj6Upq/kgLhaMEtTL2TLHlufXlBdZzdB9nw9x dG3SgAOkjhhcYjZqZd+PhitOqpMrF92Ho8fWzyJKJGqI11hOuv3IWprO79pH449MoDV4 HuQ0eewWG040pW8UYKLwnbtkMyRknNPJjT1f+Cn2dTsxvFFYf/IQQHh2bMkLLFIX/uqp nL2CWcbjAQooMS4qSXvIcZeLevMtma8XZ+0F4foCnWQqFzBMsWQQxtodFDgIf3qYHQQQ m/8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=0DClOK/SU9dbYuTVVD0V6yII2Om+InwpA+f9+cJzkMQ=; b=3Ghb0V6z18ktnysB41YEJdZFuXtoq3PrOHsoscT1hIQ8SwLB/Qs7GaPKcay4mWXGR4 64aPKqWOOj4bx4n+yeR0X/Ed4GojV7hopujzl9Egbb198j+2MJ6H1/T7JMw3o+UuO5kr Cg3zNOlFkLXuYxUN71BZVDDXpLIjrb9TdraYOtRMOfzJDP6Iu10fHGmYEQKkhZBA23G7 qpsXzNsUwZaZi9R8DhX9dhnYmyff3JpZbBqnXgdVlHiKClCcjn6tdlXnqvpTXIiv0CDA g1S+ypEijtXwGhhRZ6+HuPrHbGgNIF0zZAcWuFLzVQMf5sTdN98HA/L7hfS7ddDlHyKh R04Q== X-Gm-Message-State: AOAM532UwJqTlG86Sd8HFdzY4OWTXvcqmNgVPwwOpbm6/MP7n042PS9U oTwYGMMtPJBhO6oX6feTTsi3i3lNRIw= X-Google-Smtp-Source: ABdhPJxH5fIgFGm3BgR7iYoqFMC+1qXkmuEWoE8LL6HRR0/CxiruAsNWodz3iJS+kjW/4g8JsjjuRg== X-Received: by 2002:a05:6602:2c85:: with SMTP id i5mr57338734iow.89.1638220802864; Mon, 29 Nov 2021 13:20:02 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id k19sm5993613ilr.47.2021.11.29.13.20.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Nov 2021 13:20:02 -0800 (PST) Date: Mon, 29 Nov 2021 16:19:59 -0500 From: Mark Johnston To: "David E. Cross" Cc: freebsd-hackers@freebsd.org Subject: Re: bhyve -D not cleaning up after itself Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4J2ytC31glz4khJ X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=PQmQMwbi; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2c as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [1.38 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2c:from]; NEURAL_HAM_SHORT(-0.82)[-0.822]; NEURAL_SPAM_LONG(0.90)[0.903]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Sat, Nov 27, 2021 at 02:40:57AM -0500, David E. Cross wrote: > I have noticed for awhile that bhyve -D doesn't seem to actually do what > is claimed (to destroy a VM on guest initiated power-off). This > evening I decided to ktrace it to see if I was just not getting > something about how this was supposed to work, and found: > > > 68613 vcpu 0 CALL > __sysctlbyname(0x1ebcdb20a133,0xe,0,0,0x1ebce4ba60f0,0x9) > 68613 vcpu 0 SCTL "hw.vmm.destroy" > 68613 vcpu 0 RET __sysctlbyname -1 errno 1 Operation not permitted > 68613 vcpu 0 CALL exit(0x1) > > > Reading quickly the kernel code for vm_destroy(), I find 2 candidates: > > static int > vmm_priv_check(struct ucred *ucred) > { > > if (jailed(ucred) && > !(ucred->cr_prison->pr_allow & pr_allow_flag)) > return (EPERM); > > return (0); > } > > This doesn't seem to be it, my process is not jailed. > > That leads to the only other (I think) call in sysctl_vmm_destroy that > could return EPERM: > > error = sysctl_handle_string(oidp, buf, buflen, req); > > > But I am just not seeing it. Also this EXACT same call works from the > context of bhyvectl --vm=FOO --destroy, run from the same shell as the > bhyve process that just terminated. Is the 'ctx' somehow incorrect in > bhyve? I is used earlier in that function, so I am assuming it is right? The problem is that bhyve runs in capability mode (see capiscum(4)), which restricts access to the sysctl namespace. In particular, most sysctls are not accessible, including hw.vmm.destroy, so -D is effectively broken. One possible solution is to spawn an unsandboxed helper process which can toggle the sysctl on bhyve's behalf. That is a rather heavyweight solution, though. Earlier this year some work was done on using a file descriptor-based interface to create and destroy VMs, moving away from the old sysctl-based interface. It's stalled at the moment but I hope to return to that work quite soon. That should also help fix the problem but will take some time to complete. I think it may be easiest to simply allow writes to the sysctl for the time being: https://reviews.freebsd.org/D33169 From nobody Tue Nov 30 03:04:41 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7928618AD514 for ; Tue, 30 Nov 2021 03:04:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.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 4J36X726n2z4t4P for ; Tue, 30 Nov 2021 03:04:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638241495; bh=kDJNX2YdAYDXBPKcykuROA8eR97MU9d/Kik37+ksowk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=HTPjL6+tdwMyvYc7WiakK5nywxOIg2a8h78fuc6O7hYZWFn0bYf53qjkOUw2TvcK+tAu1FGqARgypBV2Pu6Wznt22G+dAkQDJNmrfiSztZEOqxUTQhC9UpuujEwUCNzBTlKUvhUfrpOrvJkSRx4A2I7UCT1LkprOEfnR3rqH8xbf3yeq8pzcK4jYFOCflMu17Fc473iWqbWJkwM4m04Malz77TdzrjxHgPTXfr5ErFKfAfDHIpG3uAxTHXCDuPIbcFAf/hu1ZdpDQySTq17ibphmmyb7kZPL3qvpu8xEyVdUfB+og0r+a4x+mslHz91N86yEdXlKtGYosZrGPYNg0g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638241495; bh=dixS/u2Z/bJkUhxRPr0+pU65MsdmgKJFro0ZuuRqV9n=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=N6ZOhv8ZjoezrssGGwGbgEHnYd6y6tvZW0YEt7DI51MsIv/fMXMQhKhDsuSTJAqu7bIrWxZARsYdan5tRFmfQQ4AMujFLRhE7PVmcRPnhjzIotwfIwHrT85NPg0B5K0G7iBWeqTJ+DQ7HvbaZKAqdLPaJKKM5BHNPvizUpD37vMonvBLrMJJuzZXO1OPscy1nw+VDx4twa0kgN81V8EKQzDcCI6k93aSyD+GYpn+6Nlem5ytM47MLd2SC2J6eQngyXv18IAJT7cRGEhChkAIOm0SbNjZ6218/0XIL4So6QMFApfVqi/C+NkS4NJGOHcfHD5jj4UE3L+6oEptF4FClA== X-YMail-OSG: Tj5WemIVM1nzKJ9TN6oFfSYfuEaxbfoU_Odphc6W8kI6wXuvrdYDXht1KJVEEpl WXRsZ4Nz6nqIAus_pmMr0apD8g6841ZPUJegPFPB_RK_b6MSH.mirYbTOR3kPNsMSxJatHn0sWZG fqghrYsFW2HH1wru0cv5hLzbEdNozbKxmAL3Tggg3ztBfWDpnK3r12uTwEsZdx6qDGliwTmCAxKj 2qEVllc7LnRm78h67TW8a8Kwb8.hFkL4WS_W6KznMb0BFPsFG0_VLkuV_WahqN0fq5h_3i6GtIRi wGpu2cqSg_NzgC1YzCCvahFQrYptfLC6FYNTjNpgsfFllooriGHGRpySXR3b2nxXvhMv_Qxrro0h CaN.BIn.yQBUycr5YPpPSXcfQSupmdxlOQ3qD5cdhjLyyE3HZFFvaebULOpU2RQ3ViTcXt7r9Ao0 PtCRfU0kyk.mVAWYPX870LZYdTc8yoKAi42_6xSU5b8kxosTcZTVWiMU17FN9m2JWZ7RrUoiXoOn XDEVrB5PnWLZ8_.F5J_pk7V6XOcy5snPHGlsCFzVIGg4MSDZPU03OwUnTXcgd2yOPaiqNLsNd2iU .N.WBQaIn37AA0oZtt8YHvVKiArMyhLIccyEpxdgRX71xqTdSPWrjeEnTv67dOcweewZebV9wkWd _LfcIzESGZwqVXxhUxppMLpKail0aBmSJoLiSksPy9V4GYiStqr_WjshC1hWOskEO827VY.l9qRC pmjuDyqfip1InDiydedBqys9MfDVDpKwSRs2WasAOKm98BTC9Rwael8wF013RexxO1uKe8graUVD YLMlrxQBzrtfxjSHuhcJmqdGcP0nokZIAFBRXTNtyZCJSBzBrwWYTyvpumuMfPCRvzyZ1vfJ5Ozf CM0P.YDCtwuiDp0wh72ZaRllRVhnzoOKrOP1oTpeqFkgx1lU2Wh_yq847KKFScakVq5HaHalSyeN nKNIX43fvF7g4m_BGqRjV2a5G8Rh.oQO7R4.qc.UFQvTZ4kCZZUtE1hwovxwFYNL.xzU.q8ZGH8l gt4tKZYqdLVunmYJfypk20DKyK9WFng0gDNQ5FHeAsu.YtbSPGmmTk_H_27E2nvEZEHqLBLR4wS_ hQyP4RozC9jk1RLJpfIEH2TKpUDRDp7FbWhNle9nj4lPeqm9NpS6cO31H7WvJ6zgiP88bZfbQK.T 7lj.H3GntnH9umopHUGGDgmUQkyttJxMauNCuLMecEJlMNsY6N3F4GTaDwqQHwHL8JtjDzfuq9ox yTKE.ffpN995jW0PffSgtJYRDmaWh345WJpC6NF.T1UVEndcAnFMeT0tSSyaWGtGrT.J2RaZeWv_ zG8QUXvJg9GCXvVfvjVLcB79GGG47oASWblUhjMDgBSM0WmYHeRlzLxKS2y6W2xiDRQtzaZozVPY dB0iwxJ1VZNr5Fvj6TQWqXP37Q3XEDX8Ss.bjZ7.33db3f2G4aMzeW5ObUGslF3cge1G6f21yirN WY.TnTXLNCAFfUuwvXDAE4ep6EcvmlZct4Nsqk2LOERV057pVuXTJN6zTZCgcn6ZGihdqpnCBwbw tAP7pcmqvh6JqBx75db7PGPrLVg2mJe0kXZoWXOnl.1V10yuz0BzKXdFIFrw1YJZdI954lLxrDzL c0hriR4OF3rtTLYpZXLGWold97WgHfrtu0d2GbJ5qj0iumByO5kU32..mQqHjfCnUPJTaHBP3BOF bB7biWVl6NtvBOL0CBM7T1wUA4H18.xg_KNLMu0CXF7WaKr0KRoOaIQF.D8el4qs5gvxyYAEszMC YEY9CngUOixfnN4MdyQRx1i8pivCzmoDI4l7wgqF6p50xYbKUCG8LVArvRcCDcB0SyzZaGn7YJuf N7M3etOBOpocia6T2EXxJv_lGPNO4YrxbkRWxA4CyfDLthL2sJrGQOBhCrILVciDTIgaslBWYd2p WsCSIHKZ5NjZ5Iy_25SAME3G..WD2YZ.fAICIJXW44ZLnm6nshV8Q0kfvfBBx6qZfpVoUVdt9t80 JwX4Pcz0A7aPbCUgbHN8i1BEEdR0_T7yBfaHME_0.BwNe9CNsTBDgip3ZttUSnXOm1s_8Lho4Nf3 PK72GJ6ew_pwuOFR8.5fhES33wfnbWTO77SjZlHLvjHOkfmm94IFE.gSbwW.S4DF8wbsxiOnB2xj Um03iriMDJLzW6vfMvMpPcVVbkWK10nqHFfXthKTnEeFeu5EXZEsH1YaJAStbtblGQMZz8T9iPvw U6r8oVOYhSkeWeaI4rMA4HcLP7wGSNoQfPonPXLE- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Nov 2021 03:04:55 +0000 Received: by kubenode519.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8b3b2304fe27918fbb360284e2fd11fe; Tue, 30 Nov 2021 03:04:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Call for Foundation-supported Project Ideas (buildworld buildkernel time issue) Message-Id: <896380E9-C3BB-4677-8CA8-CCCB3C5C94D8@yahoo.com> Date: Mon, 29 Nov 2021 19:04:41 -0800 To: Steve Kargl , FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <896380E9-C3BB-4677-8CA8-CCCB3C5C94D8.ref@yahoo.com> X-Rspamd-Queue-Id: 4J36X726n2z4t4P X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=HTPjL6+t; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.17 / 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.64.32:from]; FROM_HAS_DN(0.00)[]; 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]; NEURAL_HAM_MEDIUM(-0.67)[-0.670]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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-hackers X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N From: Steve Kargl wrote on Date: Sun, 28 Nov 2021 14:07:32 -0800 > 1.) Replace clang with something/anything that is more performant. > Going on day 3 of "make buildworld". Still in the lib/clang/libclang > directory. Just an FYI for comparison: An appropriately configured 8GiByte RPi4B builds such in much less time than that: under 10 hours. Building the system llvm materials is included in the measured example below, but not a bootstrap compiler or linker. (This is the type of build example I give below because it was also handy for something I want to do.) I'd not call a well-configured 8 GiByte RPi4B high-end these days. But, nor is it low end as far as small board computers go. (Hardware like the MACCHIATObin Double Shot [4 Cortext-A72 cores, 16 GiBytes of RAM installed] and the old OverDrive 1000 [4 Cortext-A57 cores, 8 GiBytes of RAM installed]=20 are/were not SBCs and take/took noticeably less time based mostly on a more performant RAM + RAM-caching implementation from what I've seen. The slower clock rate and older Cortex variant in the OverDrive 1000 historicially took the least time of the 3, again mostly for RAM + RAM-caching tied performance reasons from what I saw.) The following is for a from-scratch debug build of main [so: 14] being built by a non-debug system that was built from the same source. Thus the WITH_META_MODE=3D that is in use adds some overhead to the specific build. It is an example where the system compiler and linker are built only once: bootstrapping copies are not built. That would add some time but is not needed often. (I've no clue if your 2+ day build built a bootstrap compiler and/or linker or not.) --- buildworld --- make[1]: "/usr/main-src/Makefile.inc1" line 340: SYSTEM_COMPILER: = Determined that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. make[1]: "/usr/main-src/Makefile.inc1" line 345: SYSTEM_LINKER: = Determined that LD=3Dld matches the source tree. Not bootstrapping a = cross-linker. It is a -j4 build (there are 4 cores in the RPi4B). buildworld time: World build completed on Mon Nov 29 18:12:55 PST 2021 World built in 23919 seconds, ncpu: 4, make -j4 So: somewhat under 6.7 hours. buildkernel time: Kernel build for GENERIC-DBG-CA72 completed on Mon Nov 29 18:40:44 PST = 2021 Kernel(s) GENERIC-DBG-CA72 built in 1669 seconds, ncpu: 4, make -j4 So: somewhat under 0.5 hours. Total time: 23919 sec + 1669 sec =3D=3D 25588 sec So: somewhat under 7.2 hours, but say under 10 hours to allow for some variation in what might be built and the like. For reference for the building environment: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 Even my "nodbg" builds include debug information, despite being optimized. It is the kernel's debug features which have been disabled. I give the src.config configuration later. The various WITHOUT_LLVM_TARGET_*'s do save some time but not huge amounts of it relative to the times reported here --but I also do WITH_CLANG_EXTRAS=3D which adds some time. I buildworld and buildkernel with -mcpu=3Dcortex-a72 involved, a type of thing I only do for lower end systems, not for something like a ThreadRipper 1950X. The build never used the swap space. My patched top (that tracks and reports various maximum-observed figures) reported: . . . Mem: . . . 2380Mi MaxObsActive, 3866Mi MaxObsWired, 4941Mi = MaxObs(Act+Wir+Lndry) . . . Swap: 14336Mi Total, 14336Mi Free, 2380Mi MaxObs(Act+Lndry+SwapUsed), = 4941Mi MaxObs(Act+Wir+Lndry+SwapUsed) (UFS tends to get very different Wired figures, and, so, also difference for various other figures.) The 8 GiByte RPi4B is using USB3 portable SSD media (a: T7 Touch). The media that I used is set up with root-on-ZFS (no UFS use) but historically root-on-UFS (no ZFS use) has not been a large variation. I could time via the UFS-based media if it is of interest (also T7 Touch media). The RPi4B has heat sinks and case with a fan. I use a CanaKit 5.1V 3.5A power supply. I have: over_voltage=3D6=20 arm_freq=3D2000=20 sdram_freq_min=3D3200=20 force_turbo=3D1=20 in the RPi4B's config.txt . These settings are ones that were set to work well with every RPi4B that I've used, with some margin. (All have heat sinks, a case with fan, and a 5.1V 3.5A power supply, so I've not tested other contexts.) The src.conf sort of material looks like: # more ~/src.configs/src.conf.CA72-dbg-clang.aarch64-host TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} # KERNCONF=3DGENERIC-DBG-CA72 TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D WITH_SYSTEM_LINKER=3D # #WITH_LLD_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL=3D WITH_LLVM_TARGET_AARCH64=3D WITH_LLVM_TARGET_ARM=3D WITHOUT_LLVM_TARGET_MIPS=3D WITHOUT_LLVM_TARGET_POWERPC=3D WITHOUT_LLVM_TARGET_RISCV=3D WITHOUT_LLVM_TARGET_X86=3D #WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D # # WITHOUT_WERROR=3D #WERROR=3D #MALLOC_PRODUCTION=3D WITHOUT_MALLOC_PRODUCTION=3D WITH_ASSERT_DEBUG=3D WITH_LLVM_ASSERTIONS=3D # # Avoid stripping but do not control host -g status as well: DEBUG_FLAGS+=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a72 XCXXFLAGS+=3D -mcpu=3Dcortex-a72 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-a72+crypto ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-a72+crypto ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-a72+crypto (Comments about why specific options were not used for reasons of some odd consequence once observed may not have been checked in some time. Options commented out without such notes are just a simple choices, not driven by such oddities.) One thing that can slow down builds if there is rapid build output at times: serial console handling of that output. (Very noticeable for installworld and installkernel to a directory.) I used an ssh session to avoid the potential contribution to the time. The OverDrive 1000 died some time ago but I still have access to the MACHHIATObin Double Shot and I could run a timing test on it for building the same sources that same way. (Same Cortex-A72 clock rate in use as used in the RPi4B test: 2.0 GHz.) Hmm. The buildkernel got a bunch of: ERROR: ctfconvert: failed to get mapping for tid ????? notices. I do not expect the issue changed the time much but note them in case. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 30 07:35:36 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ED30118CA0CB for ; Tue, 30 Nov 2021 07:35:49 +0000 (UTC) (envelope-from tux2bsd@protonmail.com) Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3DXh75lqz3P5m for ; Tue, 30 Nov 2021 07:35:48 +0000 (UTC) (envelope-from tux2bsd@protonmail.com) Date: Tue, 30 Nov 2021 07:35:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1638257740; bh=zS44y6lsWw5qHK3dac0CJ108YIuEecyD4CRr6jui3j8=; h=Date:To:From:Reply-To:Subject:From; b=KBI2mCoKR23ymJai8WauHptZMCEEi9LoIALwCgy79D0VLsVKQJxp8Y5/Re0L6W1aI 1Zz1mwjqcX/TT65468ajbAmpBFoOIfsrFeP8Jrmw+ivJLCbY+Q7mskRkOFgTTStuhQ 54l/9Y1SbtAybm2iTUND7Di9+E2/KZ8iSyJWgdS8= To: "freebsd-hackers@freebsd.org" Reply-To: tux2bsd Subject: Call for Foundation-supported Project Ideas Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_xuRuNwcj5NmMxjmnjjv51nTlapUbRaqRGHD3jRHGG4Q" X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4J3DXh75lqz3P5m X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail header.b=KBI2mCoK; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of tux2bsd@protonmail.com designates 185.70.43.24 as permitted sender) smtp.mailfrom=tux2bsd@protonmail.com X-Spamd-Result: default: False [1.10 / 15.00]; HAS_REPLYTO(0.00)[tux2bsd@protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24:c]; FREEMAIL_FROM(0.00)[protonmail.com]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; 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]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[0.997]; TO_DN_EQ_ADDR_ALL(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.43.24:from] Reply-To: tux2bsd@protonmail.com From: tux2bsd via freebsd-hackers X-Original-From: tux2bsd X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --b1_xuRuNwcj5NmMxjmnjjv51nTlapUbRaqRGHD3jRHGG4Q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgSm9lCgpDYWxsIGZvciBGb3VuZGF0aW9uLXN1cHBvcnRlZCBQcm9qZWN0IElkZWEsIHdlbGwg bm90IGEgcHJvamVjdCBidXQgYW4gaXRlbSBvZiBpbXBvcnRhbmNlIGluIG15IG9waW5pb24gKHRo ZSBob3N0aWxlIGZvcnVtcyBkaXNhZ3JlZSB3aXRoIG1lKS4KClNvbWUgaGVscCB0byBmaXggZnJl ZWJzZC11cGRhdGUgLCBhIHZlcnkgbG9uZ3N0YW5kaW5nIHBvb3IgcGVyZm9ybWFuY2UgcHJvYmxl bSBJIHRvb2sgdGhlIHRpbWUgdG8gaW52ZXN0aWdhdGUgYW5kIHByb3ZpZGUgYW4gYXR0ZW1wdCB0 byBmaXgsCmh0dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9 MjU4ODYzCgpJJ3ZlIGJlZW4gd29ya2luZyB3aXRoIENvbGluIFBlcmNpdmFsIHRvd2FyZHMgcHJv dmlkaW5nL2ZpbmUtdHVuaW5nIGEgd29ya2Fyb3VuZCBidXQgdGhlIHByb2dyYW0gaXRzZWxmIGlz IG1vbm9saXRoaWMgYW5kIHZlcnkgaW50ZXJ0d2luZWQgd2hpY2ggbWVhbnMgYSBzZWVtaW5nbHkg dHJpdmlhbCBmaXggaXMgYWN0dWFsbHkgYSBuaWdodG1hcmUgLSB0aGUgZ29hbCBwb3N0cyBrZWVw IGNoYW5naW5nIHdpdGggZWFjaCBzdGVwIGZvcndhcmQuIFF1aXRlIGZydXN0cmF0aW5nIGFjdHVh bGx5IHNvIEknZCBhcHByZWNpYXRlIHNvbWUgaGVscCBpZiBtaW5pLXByb2plY3RzIGFyZSBhY2Nl cHRhYmxlLgoKVGhhbmtzCnR1eDJic2QKKGFwb2xvZ2llcyBmb3IgdGhlIHRocmVhZCBidXN0aW5n IGVtYWlsKQ== --b1_xuRuNwcj5NmMxjmnjjv51nTlapUbRaqRGHD3jRHGG4Q-- From nobody Tue Nov 30 09:53:47 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 737C318C82D9 for ; Tue, 30 Nov 2021 09:53:49 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (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 4J3Hbw6MvXz3CTV for ; Tue, 30 Nov 2021 09:53:48 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: (Authenticated sender: daniel.engberg@pyret.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id D2DE91C000E for ; Tue, 30 Nov 2021 09:53:47 +0000 (UTC) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 30 Nov 2021 10:53:47 +0100 From: Daniel Engberg To: freebsd-hackers@FreeBSD.org Subject: Re: Call for Foundation-supported Project Ideas Message-ID: X-Sender: daniel.engberg.lists@pyret.net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J3Hbw6MvXz3CTV X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of daniel.engberg.lists@pyret.net designates 217.70.183.197 as permitted sender) smtp.mailfrom=daniel.engberg.lists@pyret.net X-Spamd-Result: default: False [1.60 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[217.70.183.197:from]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.183.192/28:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.62)[0.622]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[pyret.net]; NEURAL_HAM_SHORT(-0.61)[-0.609]; NEURAL_SPAM_LONG(0.98)[0.984]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.197:from] X-ThisMailContainsUnwantedMimeParts: N Hi, A few projects that I think would be beneficial * Native exFAT and F2FS support, I think someone (with a FreeBSD hat) already expressed interest in adding exFAT support to FreeBSD 14 * Better documentation for the iflib network driver framework * ARM "CPU cluster" support, both big.LITTLE awareness and support for running at different clockspeeds I'm not sure if there could be some generic framework as we're starting to see this on x86 too (Intel 12th Gen) * Better documentation for ARM/ARM64 devices, it's even hard for devs to figure out how to get boards booting despite being supported like the Macchiato/Espressobin or how to "convert" existing images to other supported boards which do not have a separate image. Right now most information is scattered on the wiki and mailinglist and it's hard to find the most recent information. * Support Ryzen ECC memory status and reporting (what Linux refers to as EDAC) Best regards, Daniel From nobody Tue Nov 30 11:08:19 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 31E2118C21F2 for ; Tue, 30 Nov 2021 11:08:23 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 4J3KFy4cjhz3rbP for ; Tue, 30 Nov 2021 11:08:22 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42f.google.com with SMTP id a18so43580380wrn.6 for ; Tue, 30 Nov 2021 03:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:from:subject :content-transfer-encoding; bh=Ve7ld4a9EZ6M2rb4w2s95eR7gJFmw0xT2a/OngGfjAE=; b=EWprMpR2QgtsKYQdPBa33MI8mNIL/+KAE1jErs6lj4G7czg9afbHTxnm9K8Hv5fLiq KKzQdBRkPadjGCHbcUHZ0MvKG2CHT91ZoviPMQtw9Q+FvZXdSfO5E3ujItfPhpDaPFZN jQRuVQKnu9dHahNdK4oaF1KZdl/OpZRWmD/j7a7Ov3tusTRhY03M9BNC4N4WPSQuK3kE twmkWoiDRnp2Aa1yS0dL0cBo/NL5Vmhv1XfXR22l40PxJsEmjrKl0TXbizybbPVdyUs0 QjlyAY2MiigwhjZhIFvszw7i0QxCJ7O0f3pKlG9nSIbVEAE+mfe1dM+rRwhtgBL+C2Bv zZ/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to:from :subject:content-transfer-encoding; bh=Ve7ld4a9EZ6M2rb4w2s95eR7gJFmw0xT2a/OngGfjAE=; b=7EbLKn2ol757j1Waev6sYFkwQA3X6cfcy7mjVuWC77Sxord9CE7f2RB6tuCMQKDnhT WtSLMO7AYgIaJ0ACTD1wUgkQKHbEWvPI1s9dHEcSeOyQvaPH9PxSqPREBHqftwVbotm/ 4rbCUQRdv3AbyFfUC1VOLLDjC/HhJ+eLjFEywbwYqZu//Znyzw3JYcA+snK9liEfbPB/ qYw7hxtncmrCqwJ3zvTpvwk0Frs92jNG7rmXslun8y0iFxVXMvqaP9T3OFam2IFIO1PA JTGER4mgcsKuMVHJxLuznOlgt/5bLdwu9lsk2TcnZeSARMnxRykbU4bHp0KskSS/Qt+M 6U4g== X-Gm-Message-State: AOAM5303TGHASasmYv8pF2oBr9WcH2O9Bur6bgvHqp7frgFAR/qNKZK5 NxdPJh10+wxUg4uGYJlvs2GvgrkduIROXckB X-Google-Smtp-Source: ABdhPJxBxCfdzq7RZmH66XFhvsVdkx0HGPSA/HzpQ67Dr3raHsJ/dOtRbAm+MaiwPwCVXeZ4cX+0Ww== X-Received: by 2002:adf:d1e2:: with SMTP id g2mr40834393wrd.346.1638270501582; Tue, 30 Nov 2021 03:08:21 -0800 (PST) Received: from [137.202.253.121] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id x1sm16328113wru.40.2021.11.30.03.08.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 03:08:21 -0800 (PST) Message-ID: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> Date: Tue, 30 Nov 2021 12:08:19 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 To: freebsd-hackers@FreeBSD.org From: "Floyd, Paul" Subject: llvm/clang upstream Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J3KFy4cjhz3rbP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=EWprMpR2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42f as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-1.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.29)[-0.289]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42f:from]; 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]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi Not sure where the best place is to ask this. Any ideas why llvm seems so incredibly slow in taking FreeBSD patches? It would be nice to be able to just 'git clone && cmake && make' (roughly speaking). A+ Paul From nobody Tue Nov 30 11:37:25 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 36BE418AB988 for ; Tue, 30 Nov 2021 11:37:29 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 4J3KvX6pdfz4Wqv for ; Tue, 30 Nov 2021 11:37:28 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: by mail-lj1-x22b.google.com with SMTP id i63so40514350lji.3 for ; Tue, 30 Nov 2021 03:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moritz-systems.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=LWKLnCldf4tJ+HtaD/af2QIyubux+nZvyrBFWhyAyP8=; b=0C6YAdKzkCJj9qzIZjsgPLobMDu7aY1z4cqAbUhsNL5k5ZWacHG20xr98hbzXgRmmA vIXgANi0nHKJKjuu2C1L/r8tD3iq1ei4AYTQvrkNPbr/9LJAk+59A++arRpJ36s9NBkQ 9LW+xGroYsNbjUiAVV5opT+ndcoxKTJcXWp9hUZTrkxYLcMwmGm8+S7h7l0onhm4ED+D HW6lk02qJDk9ngxtl9mBKdq9ne7Ly1SNlhx1cTTvrxwPxZlo9aMCVnhcS1VuiFr8tEF3 KfbGgyOMMKGrSfupfmkP8JUYmSuBRKPNedq/bwMYwCIeDq+jo3/eyr+gsNCLRY24Bi7v yq6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=LWKLnCldf4tJ+HtaD/af2QIyubux+nZvyrBFWhyAyP8=; b=mS59omvgg9raLWL7N2lXs8vNMBJat6HIydqzvhoMTWF4H/incVIErTlcrkBcOM7GOQ DMeA9DkIEED0yIXf9A5lypdXAwwt7uz7KXmNHMtBmFcAoWwT0xOYcNj7BMZUqG4BE5PI HE38p2cV6cKkpNhmkBsUU4k2l8AurnWG8ZmEQeS3KLnfZA9tmTro+AwYLZW5Ab0FsS5B iQJTxa7a1AVbmcfEiOgUFe4NcgzoXDXhdpNO4YtUK/C+a4oAM+PJ1OMpymdPDvK1OiWO iWSKw1msJLPPha0DIMT6QFg/dRNnDCvXbDzzco2Mx8vDOqXBtAmhhfoMDwqR83oIxmzE 3raQ== X-Gm-Message-State: AOAM533MbUy55ZsVoXRTl4JTqVT3eXw8JVJZMOHj2BmKBAOW7+lED4gr IZRIu9Guz6rd7FyOuLk7ZreHDQ== X-Google-Smtp-Source: ABdhPJwyY/noLMC21CHxwaXuHDPNHRuZcLZ6k0lILGG8MaEYeNDwusTocAFHXoKrjVOlwxLfa5U3nQ== X-Received: by 2002:a2e:96c2:: with SMTP id d2mr55286756ljj.46.1638272247513; Tue, 30 Nov 2021 03:37:27 -0800 (PST) Received: from [192.168.1.17] (c139-65.icpnet.pl. [85.221.139.65]) by smtp.gmail.com with ESMTPSA id n2sm401174ljq.30.2021.11.30.03.37.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 03:37:26 -0800 (PST) Message-ID: <2cd0ba0002db6d25c41a8dc8f2a856b372370605.camel@moritz.systems> Subject: Re: llvm/clang upstream From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: "Floyd, Paul" , freebsd-hackers@FreeBSD.org Date: Tue, 30 Nov 2021 12:37:25 +0100 In-Reply-To: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> References: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3KvX6pdfz4Wqv 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, 2021-11-30 at 12:08 +0100, Floyd, Paul wrote: > Not sure where the best place is to ask this. > > Any ideas why llvm seems so incredibly slow in taking FreeBSD patches? > > It would be nice to be able to just 'git clone && cmake && make' > (roughly speaking). In my opinion, LLVM is an overgrown project whose organization structure didn't follow. I don't know about FreeBSD patches specifically but in general the hardest part is finding someone to approve your patch. Many patches rot without a single reply from anyone, and I think the whole process discourages people from trying. -- Best regards, Michał Górny From nobody Tue Nov 30 11:45:41 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CE25318AFFA1 for ; Tue, 30 Nov 2021 11:45:44 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3L542h6Wz4Zsj for ; Tue, 30 Nov 2021 11:45:44 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x331.google.com with SMTP id d72-20020a1c1d4b000000b00331140f3dc8so14559967wmd.1 for ; Tue, 30 Nov 2021 03:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=tccn6OTjfwsuWfRrxowDcx7SG87KQLy48p7w8zYbBF4=; b=RHa6PJA0Ln7gv7oBaISMIu8HFTDYAYOcEVv+LVPweg/f6JSLZkNgnXusrFdqJSIpox E3chu07Xp8WyyXezRkYatmzj3s42zZ3L1/U1FawB+GWwuxJr52V1TUWeXKy57XkOsL/Q rACcpFmev7VBRf4ScdTQT4CP2yb00PbNkN6UiewIzZXBT7vD+It2MJVTMhAgovMPGXhC zYJGBYxKdMg6f9hwHER1tJiVG8tArFzSjFpadDsBaqZsftFtEPptrbHsg/SYxjW68VJp G5jKg8rUHd8+YnD41RHryj5Bj4ID6qMQvTqyYVnWwaObtwTNzk2TCxEwY/7WjbLEvv8k LjcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=tccn6OTjfwsuWfRrxowDcx7SG87KQLy48p7w8zYbBF4=; b=kYw1LAhKV9WpWK257PIe+BT9oQNMmSCeB5VODO14mCG4Zu3l6SLsf1aG7m/2UTU9A7 Fb27I8g/ISxWHMfOjDcAYLzrs8wc+IwWqu9WsUe/CGDkbhVp4Ds/RFIV61VogRjtXqOW rDEKyymQP4VPYpV7doWNb9eyaukQPgaVbeVrQWHMp1tcODvFW2m0CFylfeBJV2p8ab49 AI9t0y3YLlbnZ9fqrjLbccXYxt1NLbloWRtG8mxWFaFtIJRtDJvIOZSm6VMYMLRWJ0Ux l4zWNmAisRtnBPFj7zg/43rqcILqgKrHDaQkdGW1HZKBNxiIAaYE85E5Dh619iEjkTqi UYJw== X-Gm-Message-State: AOAM533viOPjKKpkNHC5KjTssWNKmOicZ5hh0FG1zRo27GessMWykuDU vhYlIq8GclJqqpR1t9fQiEVpqZFjKMK/GdfL X-Google-Smtp-Source: ABdhPJzWiSYHpIiyt38OfzMOaN288ewTkDSFsxxhX7bFQgUXXm/PlnY7tgqKqs8DXMtQA0ca1ALDpA== X-Received: by 2002:a1c:4d0b:: with SMTP id o11mr4361307wmh.68.1638272743270; Tue, 30 Nov 2021 03:45:43 -0800 (PST) Received: from [137.202.253.121] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id e3sm16437066wrp.8.2021.11.30.03.45.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 03:45:42 -0800 (PST) Message-ID: <754be46a-a5c7-86b5-e6f6-354d007160ff@gmail.com> Date: Tue, 30 Nov 2021 12:45:41 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: llvm/clang upstream To: freebsd-hackers@FreeBSD.org References: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> <2cd0ba0002db6d25c41a8dc8f2a856b372370605.camel@moritz.systems> From: "Floyd, Paul" In-Reply-To: <2cd0ba0002db6d25c41a8dc8f2a856b372370605.camel@moritz.systems> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3L542h6Wz4Zsj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=RHa6PJA0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-0.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::331:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.50)[0.501]; 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]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2021-11-30 12:37, Michał Górny wrote: > On Tue, 2021-11-30 at 12:08 +0100, Floyd, Paul wrote: >> Not sure where the best place is to ask this. >> >> Any ideas why llvm seems so incredibly slow in taking FreeBSD patches? >> >> It would be nice to be able to just 'git clone && cmake && make' >> (roughly speaking). > In my opinion, LLVM is an overgrown project whose organization structure > didn't follow. I don't know about FreeBSD patches specifically > but in general the hardest part is finding someone to approve your > patch. Many patches rot without a single reply from anyone, and I think > the whole process discourages people from trying. That makes some sense.  The main backers (Apple and Google) have their own agendas, and are mainly interested in macOS/iOS and Android. I have seen some effort to free up llvm recently though, they are migrating their bug database from bugzilla to github. When that's done I'll try to see if I can find any FreeBSD patch requests, and see if poking them makes anything move. A+ Paul From nobody Tue Nov 30 11:53:08 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 76FEE18B3BE6 for ; Tue, 30 Nov 2021 11:53:19 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 4J3LFp1031z4dWB for ; Tue, 30 Nov 2021 11:53:18 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x32b.google.com with SMTP id az34-20020a05600c602200b0033bf8662572so14592489wmb.0 for ; Tue, 30 Nov 2021 03:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:from:subject:to:references :in-reply-to:content-transfer-encoding; bh=7gXyLqqhWsv9bbRF6UDsIOOcRj6l3lzH+HbzcLi2eOk=; b=qN4EcVUUjSyn6X+hK8fFfcIkL0ExpltmTrvinb+DNEkV5lkGKAfXcTE/MxXy7C9+v1 4uOup/7qivRJMpwjzWSBt55ub4IGsrD2GhiDid8UxwvYPuO38PX5DPQQNqj9oMXNVqF7 WX9adzP6OLC/0tG0Bwcepy16yZWrztbOLzdPqZanvm80ltPd8d65pAC2CyxZ58hemZdT AYBzg1PrtNblyqnDzWHMY8qDeKH0D7oclMjkXQ5lfOA4/OQQY9xC8GIKQ+XDCH6ZoFR4 dMU760wxsEHvKwzUsPcsRtQD1A0ISwq9Kx117T7BOf96BF3BeVEZcuqkkkvKQfBjWpma U2nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:references:in-reply-to:content-transfer-encoding; bh=7gXyLqqhWsv9bbRF6UDsIOOcRj6l3lzH+HbzcLi2eOk=; b=55whyLId4lYB49qGT/LNtns6eF0mSF4Sk5jln9eAsBmO4ytSD5IjmCmorKcGxYDjUL ErPG3gO5oMRUGxB6ywULcldEMsHjEjF/DyDyXtIaC0VgKgYCsAWOOcAoMrB8h+85ME7w E9K8vDkeZcZo6kbhOOawzC/D6xaIOhT+2+ThUpdmlsfs/ktohYK2pTiq0wTsjg5ctRYm pP6ADil6XV9+1YB6zh69WR/6vHEs775gGY21SZpHeOIQx4FhB534UaikwoGJx79zosEI wyycu5lJ5QRWhA1Tu0YwRTT0hP2tNkfNnWYOoaKdb+C2MA5c1nVV0fLENg2UGktTlAbL 159Q== X-Gm-Message-State: AOAM533X8FJKcKyaVcehaHzLPEdixCVcp4uQD4DtsDbLqUeTBVT3kE2J Bv4ZJTUb18sb6P7E+3lH9Cit0VAekdVKWtBM X-Google-Smtp-Source: ABdhPJw3KPjirZ4vkqv6fLWiQCY+u97ut0c90G4iNlsnyoXQPYGi48m2Le984K3/l7Xt6UvPl1xnAw== X-Received: by 2002:a1c:3546:: with SMTP id c67mr4315715wma.43.1638273190620; Tue, 30 Nov 2021 03:53:10 -0800 (PST) Received: from [137.202.253.121] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id t11sm16575467wrz.97.2021.11.30.03.53.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 03:53:10 -0800 (PST) Message-ID: <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> Date: Tue, 30 Nov 2021 12:53:08 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 From: "Floyd, Paul" Subject: Re: Call for Foundation-supported Project Ideas To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J3LFp1031z4dWB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qN4EcVUU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32b as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-1.61 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.62)[-0.617]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32b:from]; NEURAL_HAM_SHORT(-0.99)[-0.989]; 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]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N > Message du 24/11/21 11:08 > De : "Stefan Blachmann" > Port nouveau to FreeBSD. > > Reason: > There are ongoing changes in the xorg API which break older > proprietary Nvidia cards' legacy drivers. > In addition, Nvidia plans to drop/discontinue support for their 390 > driver in 2022. > Nvidia already stopped support releases for their 340 and older > drivers so that a lot of Nvidia graphics cards can no longer be used > on FreeBSD already or will be unusable very soon. > > https://nvidia.custhelp.com/app/answers/detail/a_id/3142/~/support-timeframes-for-unix-legacy-gpu-releases That's bad news that I hadn't seen. However I'm not sure that porting nouveau will help. My experience on Fedora is that nouveau simply never works. A+ Paul From nobody Tue Nov 30 11:53:20 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 66E9D18B3F82 for ; Tue, 30 Nov 2021 11:53:25 +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 4J3LFx1DJvz4d7c; Tue, 30 Nov 2021 11:53:25 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f2e:2500:fc0c:6aa2:fcd3:b0c3] (p200300cd5f2e2500fc0c6aa2fcd3b0c3.dip0.t-ipconnect.de [IPv6:2003:cd:5f2e:2500:fc0c:6aa2:fcd3:b0c3]) (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 97B0951D7; Tue, 30 Nov 2021 11:53:24 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: Date: Tue, 30 Nov 2021 12:53:20 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: Joseph Mingrone , FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> From: Stefan Esser In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8X4XvH4ckeU4gxW3O270aypK" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638273205; 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=eVy0aVIE1mERytOkkU1P79PIx36MoUgZiPIx9aKygd8=; b=MCOH5XkN2f56wvRiq7WaMpqxDHB3x/ZzOUZV5eEKF4TPX6qfzYoyI6fS/P7f7SMxJFX1Eb ULR6AKKHJ5Iiqn471WesMYBgrG3GscKM8ZphKLqywCRR/dScijro/4ISsCDdE0SKRhn2ii lIZsfbv7Xkq2avRLZJbjW9PbBXxLYLv5Ph3vfCJ+Qm9KFO+bKpy4epv0R4t6okwVDEHwfl skUxuHMhLnLNp71jtlfrqa07HIe2w9HUCDb72glP3QGi44Bhd13endjoJDFfKM7cGs1M6m l+aiXihO0iYQEHPRsaC9RZ3H6C4aAoYyAMHZ3r+I7hHozcd73PnoK0yfK75TVA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638273205; a=rsa-sha256; cv=none; b=xEft1qAg4bYw2i9EC7uA1UPHsi8xu5pQK0AlI2oy5eVufNUP6C2CIgSxhTlsVKnjbosvmA milHLcdLmDJJ7RthIbOw15q4wKN78+PbC5a1Qoyhz7I4fvWCBTggstZN4kJ1xcblNGq9Ep /errL8JWFvH4MOSQ24kyrcF+++ztDa6mjSOcr4GWA+pmWvi+f+AezGJIp7wnZ1eF78Un+5 +2f/SyL73sZjSwiHj9tkTcKTNpi891tVIKO0RYNb537niCMbAw689c32X2wR5JqggppgDb s3OK1ue5/HeFh82X7/9Xfsc6iK8znD+RTqYEp8uhv/XyWoei8v/KvmOY6MevOA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8X4XvH4ckeU4gxW3O270aypK Content-Type: multipart/mixed; boundary="------------SB1EV19uYbJkmCPSY0AgS0xL"; protected-headers="v1" From: Stefan Esser To: Joseph Mingrone , FreeBSD Hackers Message-ID: Subject: Re: Call for Foundation-supported Project Ideas References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> --------------SB1EV19uYbJkmCPSY0AgS0xL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 23.11.21 um 23:41 schrieb Joseph Mingrone: > Hello FreeBSD community, >=20 > The Foundation is seeking suggestions for new projects to support. Wha= t > gaps in the Project are not being addressed by the broader community? The "new" ULE scheduler has a number of well-known issues, which leads to the "old" BSD scheduler giving better performance on many systems and loads, but is based on concepts that made sense in pre-SMP times. ULE suffers from pathological behavior in many scenarios, and it does not know how to best deal with simultaneous multi-threading, big/little architectures, or the effects of virtualization. ULE does not care for the "niceness" of a process and lets nice -19 processes run with hardly any reduction of the share of CPU cycles granted compared to competing nice 0 processes, for example. Virtualization gives a number of additional requirements and restrictions= in both the host and client. Schedulers in other operating systems have been modified to reduce the risk of side-channel attacks by running only processes for one user at a time on the virtual processors of an SMT core= =2E Within a virtual machine, the real topology of the underlying hardware may be hidden and scheduling effects by the VM host may need to be taken into consideration (e.g. clock variations and "time jumps"). There is a connection to bhyve, at least (perhaps also to other virtualization platforms) that has to be taken into account. Another aspect is optimization for performance vs. optimization for low power use, which both require a specific scheduling strategy on complex CPU topologies. IMHO, a scheduler design that is based on experiences gained by other projects and our knowledge of deficiencies of the currently available schedulers in FreeBSD under specific loads could be a huge win for the project. This would be a long-term project, and I do not see any developer currently working on designing or implementing a new scheduler. There have been minor changes to SCHED_ULE, recently, but I'd think that a completely new design will be required, based on knowledge gained in the last 1 or 2 decades and able to deal with architectural changes that have occurred in that time frame. Regards, STefan --------------SB1EV19uYbJkmCPSY0AgS0xL-- --------------8X4XvH4ckeU4gxW3O270aypK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGmELAFAwAAAAAACgkQR+u171r99UTs +wgAxxfH21oG1Z6P9YHXIvy2dg1IPWo9AvFmFq2NWF5wmqLkvymGSIcorsd0f0b5xNx1y7pWripl PmVRQgMobwNNNLLVWazOkAXEzHBPZJULwsCqLj0FvMwgQ5H6WSprs8I9C8WGwHUPMhhdEp4r+bYG X7IPHJZsfhS9KHdlX0+NvX4SD3C4jbz1fXaMYFb3rC1QoxSlnodmrnsAo7C+Oon4gGa/CLpTDhdj w9VxujPC/3SA/m80jl/z4MWVAu5RBorTv0j2Nskag524Zvr1YgznSCNwt0efgOnMyqo2my56PbMF PFBEiJqJEcAmjwf8gVdLknXqkEhDynB5sLHUPWUT7A== =fs4t -----END PGP SIGNATURE----- --------------8X4XvH4ckeU4gxW3O270aypK-- From nobody Tue Nov 30 12:16:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7F6A118BEAF0 for ; Tue, 30 Nov 2021 12:16:20 +0000 (UTC) (envelope-from dim@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 4J3LmN2GRqz4lxJ; Tue, 30 Nov 2021 12:16:20 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id F34244FF8; Tue, 30 Nov 2021 12:16:19 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DCFE953D9A; Tue, 30 Nov 2021 13:16:17 +0100 (CET) From: Dimitry Andric Message-Id: <0E4F98DC-1B05-4E1C-813F-4246C45E9C85@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_8FC912C4-7F81-4215-B37F-3CCAA780B752"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm/clang upstream Date: Tue, 30 Nov 2021 13:16:10 +0100 In-Reply-To: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> Cc: "freebsd-hackers@freebsd.org" To: "Floyd, Paul" References: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638274580; 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=KOz49dqVB/XSdpfMUCGy3aemmnP47oRPbS3HZ//Axew=; b=Uafca4LooUNJwtmtVU2h19umt+lCJnrUFKHXE6zVzRtH7yrTtzn5fX/Fo506+wWpPPRADs 0f3XzCHkv+oGNqn4k5c8e3Oh/RVvv7uUNVJ+FbfRoKwPEwl+XnROlZk/xIP+eVFl0yofAv Qb6ybj7R0jkN2NNJ/1s8uADv0Xm363vLR4e6xhQGC4Jabl2I80AbTiMfydm0qRp1XrNje3 LHiOLxqFilJk1IuujlNYu8Bkii8xbaJUjwXzBFEgV0rmuulO+LTAdR2AxPl8hAMeXkTimd D5XkABMC32AjZXDEK0KtaBImcFWRsJv4hdaU24FES6CZ9g0XroZHDiZgeUAK0w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638274580; a=rsa-sha256; cv=none; b=DnAdFiznHHO04v5j9+eBl5ulJ11/K0UNeUlCHQAIKMaodlztvuF8O0eZ+S/ddif88v2VAg xpJqyfVU2uHTC9FVetjKaid8M7nGauJREsOcHedI1JklRkHj3m3tsVQ1MjoX8PUD1CuXNY 2YnmBVUHDIBkbm9N0BmTXGFrVNsrmzWUPHvT301e/iYXN/ooOtGfjWmmEvG9qFfFIBijxc V42bHAEoucm/t5Lwzb9FDbW+91yG3DH6L5Rso4vE1Ym6O0NTfudNvtpege5dfmEqQBHq1V J24Y8cSbGSDmsNxTrV36xGHpritduHQhjHEc65yZltimpkCDxamif1DaXoZ7SA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_8FC912C4-7F81-4215-B37F-3CCAA780B752 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30 Nov 2021, at 12:08, Floyd, Paul wrote: >=20 > Not sure where the best place is to ask this. >=20 > Any ideas why llvm seems so incredibly slow in taking FreeBSD patches? Is there any specific patch you can point us to? (As Micha=C5=82 already pointed out, the hard part is finding somebody = to review patches. This is usually the case for any open source project, FreeBSD itself included.) > It would be nice to be able to just 'git clone && cmake && make' = (roughly speaking). I do this all the time. What seems to be the problem? -Dimitry --Apple-Mail=_8FC912C4-7F81-4215-B37F-3CCAA780B752 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYaYWCgAKCRCwXqMKLiCW ow0BAJ4l0/ZFdNpS0IjW4L0uzaWFCSdLjwCgtav7BPswA655sTPwbjIRBn5IKc0= =Zx8W -----END PGP SIGNATURE----- --Apple-Mail=_8FC912C4-7F81-4215-B37F-3CCAA780B752-- From nobody Tue Nov 30 12:22:57 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1F79B18C21FD for ; Tue, 30 Nov 2021 12:23:02 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 4J3Lw43XQNz4pgF for ; Tue, 30 Nov 2021 12:23:00 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x336.google.com with SMTP id m25-20020a7bcb99000000b0033aa12cdd33so7590754wmi.1 for ; Tue, 30 Nov 2021 04:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=PmtkqMp5sPodot22onvEvGWOU/vCsbXA4NyeqF/322I=; b=MhBROp+x96il1OQvrDiwWpKYsCnXfFwQhCw/Fu36UY7yfpd4VV68kNKPaluazwIC3j LCGkF9V265DL7gLUfusQkLCD6fb4mQmw3Cl6p7jkpcSbygzCFtu4wZXsZUDhPnEfqV3B Eb/K07dC9qlzARZjiyzAMhHO9sjL0YnbSs/WdZrtJSd7fg8x8ihh0mY2vvuVa/rk/EG7 aMUsjgscPWXXDR0y4UOWeoUfJDH/lmiL/7HjExCo4Wz3TX6kJzDranwF5qvaMSneKfFh RG56ltKbaE5x4UXFg1cWUCl4R/i0WTXk5Fq9jaP9XFG0fIDS+Hmjt80+vPTh7hZ0iPId jK2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=PmtkqMp5sPodot22onvEvGWOU/vCsbXA4NyeqF/322I=; b=oeEIe70TRTYVjlFlSu3fNGYsf5Zlbdeclgrt/HhGFwKtpGvw3nJs8AczZVsxGABKZb Ae5riU/rmliT3Bp3PYv59V/C12YJzkNoDpuHUDVTLeohjTGmxyMYcWX6XImjCdBf2XWc ZWln2z2ll402EY6i0yQYf57x+rRBlP8V/4b5SjRCAXP2n6T+UFAERJ1fA1O6invp6PS/ 1UzGqhXv3FemCuU+TG3m35Mrk9Ql+rcvV+65rQzAFbADeI5mQ1mEFoeBVr4dNqSSKI22 sJbiAdaEISOCwGDBdmFJbS2wgEt0C68Am0h4NhvRNJV3OZXp21CT+Xd0YDRXSpB2u50D CLKQ== X-Gm-Message-State: AOAM532mV6noNtE5WN3gFW4ywWZa91bohyZtsWpoBZHnIMAF4SgfR2Pv PCYmH6U6lEdHvbvmC7MYehK52GJ5/FId9UsI X-Google-Smtp-Source: ABdhPJy5dYJ922BmwNfbghPP7zX1j2otrDvI8wiP4+pZ42CI4oVJD2MZHjCLZj3EvAK0JkZFRPCTKw== X-Received: by 2002:a05:600c:34c2:: with SMTP id d2mr4792220wmq.102.1638274979135; Tue, 30 Nov 2021 04:22:59 -0800 (PST) Received: from [137.202.253.121] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id t127sm2273415wma.9.2021.11.30.04.22.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 04:22:58 -0800 (PST) Message-ID: Date: Tue, 30 Nov 2021 13:22:57 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: llvm/clang upstream To: "freebsd-hackers@freebsd.org" References: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> <0E4F98DC-1B05-4E1C-813F-4246C45E9C85@FreeBSD.org> From: "Floyd, Paul" In-Reply-To: <0E4F98DC-1B05-4E1C-813F-4246C45E9C85@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J3Lw43XQNz4pgF X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=MhBROp+x; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [1.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_SHORT(0.94)[0.936]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; NEURAL_SPAM_LONG(0.93)[0.934]; 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]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N >> It would be nice to be able to just 'git clone && cmake && make' (roughly speaking). > I do this all the time. What seems to be the problem? Now that I'm looking at this again, I think that the problem was that when I first set up llvm builds I wrote a couple of scripts to run cmake and then to run make. The cmake config script might now be out of date. When running make I get an error finding unwind.h. So my guess us that building libcxxapi without libunwind is broken but either not building libcxxapi or building it with libunwind works. A+ Paul From nobody Tue Nov 30 12:32:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4475F18A8DB5 for ; Tue, 30 Nov 2021 12:32:55 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3M7W12mbz4vw3 for ; Tue, 30 Nov 2021 12:32:55 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: by mail-ed1-x532.google.com with SMTP id z5so20873311edd.3 for ; Tue, 30 Nov 2021 04:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=J4cndTd+B/3Y2OAUVjF1blTKCQARwJU7G10IbC4tcuI=; b=Tof/CA8aBKuHwtUtD9Sv2ZXktkUI8a/k9iOtvo/5i0i1mEX06hQwujTbWoYfJibnaO HyjWxGWNVy3VElUDyM1Xki3S7EnpSc5X//cJzK1CMXkEa6KDA81Instuc/YqrJdN9HMJ dU3W4zctZQJ8YfeElOiJPcbpCcz46PZ5At61McgUN3h1xaagc5xA8qctBjEW1u498mFq Cj7V20Ed6a+WuRDgs+BoM8w/ILs0h9hYoJ6n4pSaktgvUYnEKrizdXIBMHhw5i8pr3Hk 33kwCncyutaJSE/JhBRlSc7EvUTaJsdYQD4v9qXYlL7Zc0Uy6XzSSnE55ZwGDi63XB/V kmEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=J4cndTd+B/3Y2OAUVjF1blTKCQARwJU7G10IbC4tcuI=; b=LWyzwNxrSD0HwmyxUeHBalqIF+9JcbEK6/jK1kT1GOL0P4BxNFixynwo7P/YL3oA7J EGaFeYgi/H3b/dgxS1fAPGxfG7/F3D2H68zZN6lkjrvo+GlNtbwF3XIzhXQ8akOHN7Sq A4pVkRuaO9RAmwm6lQeDunO2hsqgj0nNtYF54aqqnblNiSAu96KboEEYStmpMpC9gjTR rcMXHADLRE3mXeE3AHVqfKpvw2xM0P8dQuHRvIA5f8T3ROCeFu2eCa4vzXpwfnckRB5o uyiF5S/ZPnC5UkHnw3YkAYlQj5+St+yvg4LHwxkc4vb/MSiGTuwKomZp4jEqVAtxUYrJ 4NVQ== X-Gm-Message-State: AOAM5323NJL4tax+O8CjRmQKlwJX/aBW2doVEdOqE7YRHfE2CM4YVgZ0 IhaMDhcfryX+BCMQLTvAiehKklZL09XckCllg9yd0QJktEE= X-Google-Smtp-Source: ABdhPJxliafA+inw2bEejA0PS5rZVRVAp+h4Oym4a0ChrPVhoIaNYB1EaOZFLg45F3WVnbzbT7vosOHimhWdxhsYKfI= X-Received: by 2002:a50:a6ca:: with SMTP id f10mr81662747edc.81.1638275573975; Tue, 30 Nov 2021 04:32:53 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Stanislaw Adaszewski Date: Tue, 30 Nov 2021 13:32:17 +0100 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Warner Losh Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J3M7W12mbz4vw3 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: N I have submitted a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D= 260138 On Mon, 29 Nov 2021 at 17:12, Stanislaw Adaszewski wrote: > > Made a handful of other changes: > > 1) Prevent interaction (exit) if autoboot fails (stand/common/interp.c) > > 2) Wipe env vars and GELI keys before panic()'ing the kernel in case the > passphrase marker does not match - probably does not really help much > but I guess the idea to narrow the time window any secrets are in memory > a good rule of thumb, > > 3) Call Tpm2NvReadLock() right after retrieving the passphrase from TPM > in the bootloader. Therefore, it cannot be read again from the TPM until = the > next restart. Thus, it remains unavailable for example in the booted OS. > > On Sun, 28 Nov 2021 at 12:19, Stanislaw Adaszewski > wrote: > > > > I have made further modifications: > > > > 1) As per suggestion - use SYSINIT() and EVENTHANDLER_REGISTER() > > in a separate file (tpm2cpm.c) rather than hardcoding in init_main.c. > > > > 2) Make the functionality configurable / optional both for the kernel > > (option TPM2_PASSPHRASE) and the bootloader > > (WITH_LOADER_TPM2_PASSPHRASE). The one for the bootloader > > is enabled by default and the one for the kernel is enabled by default > > in the GENERIC amd64 kernel. > > > > Best regards, > > > > -- > > Stanislaw > > > > On Sat, 27 Nov 2021 at 21:35, Stanislaw Adaszewski > > wrote: > > > > > > Hi Warner, > > > > > > > > > Thanks a lot for the quick reaction - that helps. Accordingly, > > > I have taken several actions (below). If you have any more tips > > > how to push this forward, please let me know. Like I don't know > > > is there a person formally responsible for this kind of > > > contributions? Let's say when you are happy with the general > > > architecture of the solution and the quality of the code > > > (it still requires some polishing) - is that enough to pull > > > the changes into the codebase? How does that work? > > > Thank you in advance! > > > > > > > > > 1. I have rebased my changeset on top of the tip of the > > > FreeBSD's main branch [1] > > > > > > > > > 2. I have changed the /.passphrase_marker convention to hold > > > (instead of the passphrase) a human-readable lower-case digest > > > of SHA256(salt | passphrase) where salt is a new (optional) > > > parameter which can be passed using another EFI variable: > > > KernGeomEliPassphraseFromTpm2Salt. > > > > > > I think it is more for the peace of mind than anything else, > > > as anyone having access to /.passphrase_marker would normally > > > have to be the root user. Nevertheless it is perhaps nicer not > > > to keep raw passphrases laying around in files. > > > > > > We still pass the passphrase to the kernel via a kernel variable > > > kern.geom.eli.passphrase.from_tpm2.passphrase which is unset > > > before the system becomes interactive. I could be easily > > > passing the hash computed by the bootloader instead - what do > > > you think? > > > > > > One thing to keep in mind is that another kernel variable - > > > kern.geom.eli.passphrase has been passed around like this > > > as well and it is being unset precisely in init_main.c. > > > > > > But even more importantly, one has to keep in mind that > > > geli_export_key_buffer() passes all GELI keys to the kernel > > > anyway, so access to the encrypted drives is already possible > > > by that alone. Not to mention that the root user can simply > > > read the driver's master key with a simple geli show. > > > > > > > > > 3) As an explanation, also to @Ka Ho Ng, the /.passphrase_marker > > > serves only as a tag to allow to reliably pair a boot filesystem > > > to the keyphrase retrieved from the TPM. If we were to just > > > retrieve the passphrase and pass it to any boot environment then > > > one would simply boot another OS with another root password and > > > could read all our secrets. The same goes for the root filesystem > > > that is mounted in turn by the kernel. If one would for example > > > remove the boot drive - that would cause the kernel to drop out > > > to interactive mountfrom> prompt and then one could for example > > > boot from another drive. That is unacceptable. Kernel is by default > > > very "boot happy" - it tries really hard to boot SOMETHING rather > > > than accept a strict specification of what is allowed to boot. > > > > > > > > > 4) The code is fully functional and I have tested it quite a bit > > > on a Zotac CI622 mini-PC with the latest BIOS update which enables > > > the TPM functionality on the Intel 10110U process in there. If you > > > have a TPM-capable BIOS and CPU, I would encourage you to try, like > > > this you will understand better how it works and that the design is > > > necessary like it is with the /.passphrase_marker. I am not 100% sure > > > if there are no ways left to fool the system to boot or run some > > > arbitrary code. Such attacks would generally consist of causing some > > > kind of errors on the "trusted" UFS-on-GELI or ZFS-on-GELI systems an= d > > > making the system drop out into some kind of interactive prompts. I > > > hope that does not happen. For example if one removes the drive durin= g init. > > > I would certainly expect that no process drops out to interactive pro= mpts > > > on a system with a root password set bit this kind of scares is > > > a tradeoff of not using full VERIEXEC. It is however very convenient > > > to say - just trust everything on the XXX-on-GELI since this was encr= ypted > > > and therefore tampering-proof. More tests are necessary but also - VE= RIEXEC > > > can be enabled in addition to that to ensure that such weird scenario= s do not > > > happen. > > > > > > > > > 5) @Ka Ho Ng what you said is taking place clearly, the code relies o= n a PCR > > > policy of user's choice and uses that to read the passphrase. > > > > > > > > > 6) Regarding ZFS encryption I am not sure if that is supported in the= EFI > > > bootloader - at first glance I would say that it isn't. With that sai= d, > > > the code can be used to further modify the loader to read any kind of > > > values stored in the TPM and put them in kernel variables for later u= se > > > in the boot process. Just a big WARNING, kenv seems to let even luser= s to read > > > the variables. So whatever one would do with them, it would have to b= e done > > > quickly and the variables would need to be discarded before letting > > > the lusers log in. > > > > > > > > > [1] https://github.com/sadaszewski/freebsd-src/compare/main...main-ch= erry-pick-tpm-support-in-stand > > > > > > > > > Kind regards, > > > > > > -- > > > Stanislaw > > > > > > On Sat, 27 Nov 2021 at 18:00, Warner Losh wrote: > > > > > > > > > > > > > > > > On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski wrote: > > > >> > > > >> Dear All, > > > >> > > > >> Could you please guide me so that we can together integrate > > > >> the following piece of work into the FreeBSD base system? > > > >> Thank you for your time and consideration. > > > > > > > > > > > > See below for some advice. > > > > > > > >> I have created the following bundle of work [1]. The referenced > > > >> patch implements on top of releng/13.0, the support for TPM2 > > > >> in the EFI bootloader and in the kernel in order to allow for > > > >> storage and retrievel of a GELI passphrase in a TPM2 module, > > > >> secured with a PCR policy. > > > >> > > > >> The way the bootloader behavior is modified is the following: > > > >> > > > >> 1) before calling efipart_inithandles() an attempt to retrieve the > > > >> passphrase from a TPM2 module might be performed - > > > >> how this is achieved is described later on. > > > >> 2) if a passphrase is indeed retrieved, then after determining > > > >> currdev, the currdev is checked for the presence of a > > > >> /.passphrase_marker file which must contain the same passphrase > > > >> as retrieved from the TPM. This is supposed to ensure that we > > > >> do not end up booting an environment not on the device we just > > > >> unlocked with the passphrase. > > > >> 3a) If all is go, the autoboot_delay is set to -1 in order to prev= ent > > > >> any interaction and continue the boot process of the "safe" enviro= nment, > > > >> a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set > > > >> to the passphrase from TPM in order for kernel use later, as well = as a > > > >> kern.geom.eli.passphrase.from_tpm2.was_retrieved'=3D'1' variable. > > > >> 3b) If the passphrase marker does not match, the bootloader cleans= up > > > >> GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exi= ts. > > > > > > > > > > > > I worry about information disclosure having the pass phrase availab= le on the running system with this setup. Can you explain why that design p= oint was selected? Usually there is something signed with a private key tha= t the public key can be used to verify instead of a direct comparison like = this to prevent disclosure of key material. I've not looked at the code yet= , so it may already do this... > > > > > > > >> The way the kernel behavior is modified is the following: > > > >> > > > >> 1) In init_main.c, after vfs_mountroot() a check is added > > > >> 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not > > > >> set to 1, then we do nothing and continue the boot process > > > >> 2b) If the was_retrieved variable is set to '1' then we check for = the > > > >> same passphrase marker as the bootloader, its content compared > > > >> against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' > > > >> variable. > > > >> 3a) If all is go, the passphrase variable is unset and the boot pr= ocess > > > >> continues, > > > >> 3c) If the passphrase marker does not match, we panic. > > > > > > > > > > > > I'm sure that main_init should not know about geom or geli. This is= usually done with a handler of some sort so the mountroot code can just ca= ll the generic handler. Can your code be restructured such that this is pos= sible? The reason I ask is that ZFS supports encryption too and it would b= e nice to use that instead of geli. > > > > > > > >> The configuration of the bootloader for this procedure looks the f= ollowing: > > > >> > > > >> 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex > > > >> to contain the TPM2 NV Index we store our passphrase in, e.g. 0x10= 00001 > > > >> 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr > > > >> to contain the PCR policy used to secure the passphrase, e.g. > > > >> sha256:0,2,4,7 > > > >> 3a) If both are set, the bootloader will attempt to retrieve the p= assphrase > > > >> and behave in the modified way described above > > > >> 3b) Otherwise, it behaves as the vanilla version and will ask for = GELI > > > >> passphrases if necessary > > > >> > > > >> The configuration of the TPM and the passphrase marker looks the f= ollowing: > > > >> > > > >> 1) echo -n "passphrase" >/.passphrase_marker > > > >> 2) chmod 600 /.passphrase_marker > > > >> 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4= ,7 > > > >> 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L > > > >> policy.digest -A "policyread|policywrite" > > > >> 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:= 0,2,4,7 > > > >> > > > >> [1] https://github.com/sadaszewski/freebsd-src/compare/releng/13.0= ...tpm-support-in-stand > > > > > > > > > > > > This sounds cool. Any chance you can rebase this to the tip of the = main branch? All code goes into FreeBSD that way and 13.0 is about a year o= ld already. > > > > > > > > Thanks for sharing this. Despite some reservations expressed above,= I think this has potential to be quite cool. > > > > > > > > Warner > > > > > > > >> > > > >> Kind regards, From nobody Tue Nov 30 13:03:14 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 97FB218BA9EC for ; Tue, 30 Nov 2021 13:03:18 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3MpZ3Y8bz3QR6 for ; Tue, 30 Nov 2021 13:03:18 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: by mail-lj1-x236.google.com with SMTP id p8so27488767ljo.5 for ; Tue, 30 Nov 2021 05:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moritz-systems.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=H/E+kITh41Tw3/dE/IzozlpU4CN75t++lTzbQLVhco0=; b=3GJm8rlt6xl9iNemh5kqnGXJkEjevIQUuEh0nXl6MlIA/pyKeqTmtSQsXecHys35g/ N7HhQH7mMebMWGTdzvwkGX50LHTae6uXSzbCTbBR9PP9acx4KfhDPCMDJ+RUPSDZyM76 RRaYr2Ut+ZZV23iPcB1EyMOO4IBCheOFlQ3oFmkxbh/mQFodL1w34MJeG+s2SA/EHBKl QvMVFH8fmIkNTew8UFC0hOIr2F8fzGRp/P7yVoys26jIBbcVV9bYe3domjkh64nCg9or yb/hMZkWNrka57Um7jtoJZ4vyaJNGUnNxAO4Rqo32uBrAOWcqxXYRPtvpL/gbUEyKtS8 WxqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=H/E+kITh41Tw3/dE/IzozlpU4CN75t++lTzbQLVhco0=; b=MX7y0NIExClLwNjxotA+aocOqC5oq+vOiRthQWgy69GlYeyrufCRa14OwM8ICka7vh tWXZhwN77BLmfbu8hwOZ8c71rKCubEj7FT2T8SO8QDGQXSbvB+Eux8twUDo7frSh54qP QJrSfyqHsmGtBsh/NnXTDr7iGpFE7uWs91JGT7MQd9fnwqX5ybqHbULoWEqZKNgPsL66 2TZBUGwpuLWPAuZWegtOk7S7A1BxtkBLJ8Wh58FJ932mfiSpvJjdwrgMtjzEp8CbP7jo r2onSByp9aN4OznLjoSuwxIZycPI98lBOyaL0LjRKUEqD1h5Z8MC0pffx9NLaGRxPwhs qynQ== X-Gm-Message-State: AOAM53354YrtOrlbkaRQeLyosI51YFdfsLzuGGXRylbYgXZESU8p7E6a wl0lKjfPA3vARDXfKMCGzq+iXw== X-Google-Smtp-Source: ABdhPJzr+QG97CjF1mz1FirZA31pOPLShqq/B2SmMqeO79F6Yn/p2oPq2hB3om9avAzJsgSFiysUAg== X-Received: by 2002:a2e:81da:: with SMTP id s26mr56190508ljg.63.1638277397228; Tue, 30 Nov 2021 05:03:17 -0800 (PST) Received: from [192.168.1.17] (c139-65.icpnet.pl. [85.221.139.65]) by smtp.gmail.com with ESMTPSA id d15sm1710925lfq.38.2021.11.30.05.03.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 05:03:16 -0800 (PST) Message-ID: <308f3c42a357e6be288e01060868fa7b003ced4b.camel@moritz.systems> Subject: Re: llvm/clang upstream From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: "Floyd, Paul" , "freebsd-hackers@freebsd.org" Date: Tue, 30 Nov 2021 14:03:14 +0100 In-Reply-To: References: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> <0E4F98DC-1B05-4E1C-813F-4246C45E9C85@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3MpZ3Y8bz3QR6 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, 2021-11-30 at 13:22 +0100, Floyd, Paul wrote: > > > It would be nice to be able to just 'git clone && cmake && make' > > > (roughly speaking). > > I do this all the time. What seems to be the problem? > > Now that I'm looking at this again, I think that the problem was that > when I first set up llvm builds I wrote a couple of scripts to run > cmake > and then to run make. The cmake config script might now be out of > date. > > When running make I get an error finding unwind.h. > > So my guess us that building libcxxapi without libunwind is broken but > either not building libcxxapi or building it with libunwind works. Please note that the "official" way of building stuff has changed a few times, so you might be using an outdated approach. I think the current way of building runtimes is via LLVM_ENABLE_RUNTIMES. -- Best regards, Michał Górny From nobody Tue Nov 30 13:27:09 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 955CF18C4830 for ; Tue, 30 Nov 2021 13:27:12 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3NL75TCtz3mkM for ; Tue, 30 Nov 2021 13:27:11 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id d9so23563763wrw.4 for ; Tue, 30 Nov 2021 05:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=M+ao93pK8udEACsvHjiWXVTdasNEdUTbXzA1o6OayJg=; b=O3c9deYM79NIcdI5uD42b2kP76zI4noJqvGxT1h4ToPwZcfxcFxcDCl980HF+ml7NZ C8CVAmX7JIkvX0BMt0/eDZxH6lUJdzJvA2VGWS/fuR210BFXpM+OvvR6D2QQH33/89k8 bZorYDEFVTirgCj1FtpVF3J5lxX6R1xPSGF/z2Ivi3RbTcCJuhU5OPXWjtB/SNNkwnuv K/3HBxb16idG+0dGT7/SaLdOZBVVji6EduZWO+l5STv3XeMRGICdefcjB9Ly36I0z21M yecF+gg4d5Q9yT/a53usrRN+89aMNKaZnvmeoZGoI1QHfiK8kjrjSXgV57tStuWIbcl4 YWUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=M+ao93pK8udEACsvHjiWXVTdasNEdUTbXzA1o6OayJg=; b=vYSY0HtHuqh/UBc88PxRyQDUm4mJd0UT2M2XU8mYZrWTiTHLT0Pxj8dgZF2wb6m+7c fcrA8OYtEH8NTOQ7aTSELtZ5HBBrR473zDq0lpY62Us9WUzJxkMLZKXKFOWLlVHPQnLk t9+WhQhI0s20c/OMGkZKZrxo1ll7I/5RQiOKXOOa7PzXkGzm3WMG0OniIVWufAjzcFmh PQuDFI9y53uvLx8k9wOlBAi3fi6EADj/TtYAcGgQPDM2Ge3fPIwrjjUq2wbcuY19I7a6 lbo822F2wTefbWk0atczgJLv3ESbYjg8LTCnVd4QHKrRRoQemwv4y6Wc7KcdF6iEUc42 3wcA== X-Gm-Message-State: AOAM531l2avr3FQ+s8iaxbXdEAasw0zPDlq1aO49ajkBA+R9dvbd4B+9 DCUSBK3T620RTJBRdYICXpU5StNdm8K9TMrA X-Google-Smtp-Source: ABdhPJx4niVwHX7hvejCaekwzcBXadbd/9rZiwsGeBaCkKW19YIKHJaKBxBOANT3t7cgRGblqibrYA== X-Received: by 2002:adf:c406:: with SMTP id v6mr40543949wrf.570.1638278830758; Tue, 30 Nov 2021 05:27:10 -0800 (PST) Received: from [192.168.1.24] (lfbn-lyo-1-397-34.w2-7.abo.wanadoo.fr. [2.7.224.34]) by smtp.gmail.com with ESMTPSA id 138sm2372539wma.17.2021.11.30.05.27.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 05:27:10 -0800 (PST) Message-ID: Date: Tue, 30 Nov 2021 14:27:09 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: llvm/clang upstream Content-Language: en-US To: "freebsd-hackers@freebsd.org" References: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> <0E4F98DC-1B05-4E1C-813F-4246C45E9C85@FreeBSD.org> <308f3c42a357e6be288e01060868fa7b003ced4b.camel@moritz.systems> From: Paul Floyd In-Reply-To: <308f3c42a357e6be288e01060868fa7b003ced4b.camel@moritz.systems> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3NL75TCtz3mkM X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=O3c9deYM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::433 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [1.79 / 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]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.224.34:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.952]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.83)[0.835]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::433:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/30/21 14:03, Michał Górny wrote: > > Please note that the "official" way of building stuff has changed a few > times, so you might be using an outdated approach. I think the current > way of building runtimes is via LLVM_ENABLE_RUNTIMES. I'll take a look at the 'official' llvm web pages tonight Up to now I've been using cmake -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=~/tools/clang -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;libunwind;compiler-rt;lldb;openmp;pstl" (just added libunwind) which gives /home/paulf/scratch/clang/llvm-project/compiler-rt/lib/sanitizer_common/sanitize r_unwind_linux_libcdep.cpp:26:10: fatal error: 'unwind.h' file not found #include         ^~~~~~~~~~ 1 error generated. A+ Paul From nobody Tue Nov 30 13:39:50 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B32BA18AC28D for ; Tue, 30 Nov 2021 13:39:53 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 4J3Ncn4P8Gz3sJf for ; Tue, 30 Nov 2021 13:39:53 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: by mail-lj1-x22b.google.com with SMTP id j18so27967805ljc.12 for ; Tue, 30 Nov 2021 05:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moritz-systems.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=tRF/g/m3mybKpjfYuF9KLjS3KjDRoGxOL0Sl35T6Ek0=; b=5vXYktgRboh1hN8Vge9ucPLtQ+5LUVJQsHaIMuKAcA6yI4VuIyk+kLUNa87E6V1dp1 A5B/YuSS8d55fHqoB0fR+oRD7cUwuon7jxhG25SJyokzZ1KD0Oqr4LZoIaXN58PwMtWk 8CC18lwljVOxcepCCP01wAgqPOd72cjQ+kmseMp98QLGM1ei6ySR1+4dxn4dpLZHcqfE IJljX9YUYDUkc71qSdPq5ngmi2SMW8zsX+Bf6KzuAPWSmLn56Qf8CHuhzWIjh4RAzUnD nWVnpi4NfkTiPkk8bHIU6Sij+oYtPtelCAQxV+3XslO/+sAo/dIXtQNMiuV/m7AdrUm5 sssg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=tRF/g/m3mybKpjfYuF9KLjS3KjDRoGxOL0Sl35T6Ek0=; b=t1vAMBUa+ZAQTEZCGHq7X+Ssmmjxo1qH8d4OIhyVqxRBhmUAptIqicOhbT+FHlmmYt PVo/psfAcHcqgBzfuY3qhlY8glEHFhyYjO/q1/GEz4mUd7yO1bRdeKXbF7YUP2w3Qm5M 2z0sdexNNrgFAFt8SqUeZv3Kim5oBzZxQJnr6WK77YSjsYauh2kus10TJwBeHMqcp3nj qvRTxcmsAT9fk7xrFtTd0AQLCm0jlkG4Y1gz/OwiN81gqk2RHTw5NZubR8Uh/65iscbk pnS6Pw2FgsEAcY73phD5x4S4CEU+vzFxErGnpv8hL0HAXuufPscKRnBSP9hvY0QnPM5D NmxQ== X-Gm-Message-State: AOAM531ez7iXhfU8h69JiLvJvEJRFBDbevsuAkpchdTRmziS/Zbr9DGF TupfUG9bZ6dFodGVLY2xgz7mbA== X-Google-Smtp-Source: ABdhPJzrhwqUUQdbzZ4q36H3DldN1ltYJJ8Q83u0qdg6dZAm2NjmyzjVXShqHkiWKnsLR21rbwTBmw== X-Received: by 2002:a2e:bf26:: with SMTP id c38mr57645769ljr.127.1638279592166; Tue, 30 Nov 2021 05:39:52 -0800 (PST) Received: from [192.168.1.17] (c139-65.icpnet.pl. [85.221.139.65]) by smtp.gmail.com with ESMTPSA id be25sm1566282ljb.114.2021.11.30.05.39.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 05:39:51 -0800 (PST) Message-ID: <5a0663e3379ea37bf29b6a12c1fbd4a194fe7204.camel@moritz.systems> Subject: Re: llvm/clang upstream From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: Paul Floyd , "freebsd-hackers@freebsd.org" Date: Tue, 30 Nov 2021 14:39:50 +0100 In-Reply-To: References: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> <0E4F98DC-1B05-4E1C-813F-4246C45E9C85@FreeBSD.org> <308f3c42a357e6be288e01060868fa7b003ced4b.camel@moritz.systems> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3Ncn4P8Gz3sJf 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, 2021-11-30 at 14:27 +0100, Paul Floyd wrote: > On 11/30/21 14:03, Michał Górny wrote: > > > > Please note that the "official" way of building stuff has changed a few > > times, so you might be using an outdated approach. I think the current > > way of building runtimes is via LLVM_ENABLE_RUNTIMES. > > > I'll take a look at the 'official' llvm web pages tonight > > Up to now I've been using > > > cmake -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=~/tools/clang > -DCMAKE_BUILD_TYPE=Release > -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;libunwind;compiler-rt;lldb;openmp;pstl" Yeah, I think LLVM_ENABLE_PROJECTS no longer works correctly for runtimes, and I'm pretty sure I've already experienced this first-hand. -- Best regards, Michał Górny From nobody Tue Nov 30 13:41:34 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1037418ACDDE for ; Tue, 30 Nov 2021 13:41:47 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3Nfw5g07z3t78 for ; Tue, 30 Nov 2021 13:41:44 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 1AUDfZhc044796 for ; Tue, 30 Nov 2021 22:41:35 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 30 Nov 2021 22:41:34 +0900 From: Tomoaki AOKI To: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas Message-Id: <20211130224134.2fea1d41e7b74482461e6810@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J3Nfw5g07z3t78 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-0.32 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; NEURAL_HAM_SHORT(-0.99)[-0.987]; NEURAL_SPAM_LONG(0.27)[0.271]; NEURAL_HAM_MEDIUM(-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:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N On Tue, 30 Nov 2021 10:53:47 +0100 Daniel Engberg wrote: > Hi, > > A few projects that I think would be beneficial > > * Native exFAT and F2FS support, I think someone (with a FreeBSD hat) > already expressed interest in adding exFAT support to FreeBSD 14 At least exFAT support would need to be on ports even when implememted as non-fuse filesystem, as of patent issue, unless MS grants unlimited right to publish. > * Better documentation for the iflib network driver framework > * ARM "CPU cluster" support, both big.LITTLE awareness and support for > running at different clockspeeds > I'm not sure if there could be some generic framework as we're > starting to see this on x86 too (Intel 12th Gen) Implementation of NUMA support could be a good start point. >From resource management view, it would be non-uniform process (or processor, instead) allocation. Just an idea, though. > * Better documentation for ARM/ARM64 devices, it's even hard for devs to > figure out how to get boards booting despite being supported like the > Macchiato/Espressobin or how to "convert" existing images to other > supported boards which do not have a separate image. > Right now most information is scattered on the wiki and mailinglist > and it's hard to find the most recent information. > * Support Ryzen ECC memory status and reporting (what Linux refers to as > EDAC) > > Best regards, > Daniel > -- Tomoaki AOKI From nobody Tue Nov 30 13:50:30 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6233818B32C9 for ; Tue, 30 Nov 2021 13:50:25 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 4J3Nrw2Mq5z4RpQ for ; Tue, 30 Nov 2021 13:50:24 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qt1-x82e.google.com with SMTP id t34so20197224qtc.7 for ; Tue, 30 Nov 2021 05:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=MYXpGJwJOht/C5nCuaDfF8zQDnD1d5ZAAp1PF+DA2u0=; b=FKopplWODPv1hEcn4RbY4sXuAQgmQ48UKDoiN0JV+VvgPgymciX7+BH4NhBD9P2ZFy Ix0rxd/zZjEFm7kxWzO/r/74L3gK+8cO4ftq8XDUq6l/ElaoFdqMHQ9ofhGu+0S1xkzx wzpLVgsu5a358chPivyDWsF6ahB7aahvFHNVU0lfb7tBl01EGqDBZ2qgTzFKuv/8nid+ 1OnSZ2UnnSe1YJn94pbshn3bQL8YTr5jxtTmP/24Pmprn2x+LeCh+um5aCYCbP448+db uXhSpU+A/B6HNdKHcRyngkKZCwfrD36Q9KDZATlQpbz7cRlaeLZeT0hYVj3L7oD8M/BF O+ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=MYXpGJwJOht/C5nCuaDfF8zQDnD1d5ZAAp1PF+DA2u0=; b=Fi7cqhLmEaaGQujDIGnB1uQP/PbEP+T8L1fvrQC7sMYKBrG6iHAKeXtKVmyxk6JY2l r8e5OWLKhd0icotNkJRT7iZW3sThmv8NbyRyQmEbwcyUaIu8vEuovhK+mrMEQwvFm0Y7 PYKsmmmuzdazCBGU24pOfsMQFhDakbs3zLlpVGwfN15MKdWn+PSh2hKw/UrN+lPS9bKk 4Z0zwN90bfubDJnDwW/4xNTAFFLHCBID2wh8+bquMk1mR+ujwsVGIVsCHF1WDxsLsyQ0 Q5wwXNqOntP3Y8cjRhcJyz982sMf1zSCXgZl5ZQGSqoKC/BXewypRx6tooBXEnGpSi// /rkA== X-Gm-Message-State: AOAM5319kf7yNltHxkfSxsjU6ZZn9BDitkO7wFWBLNsfT00hE8CW9mSo tW5rujJ0dW8k7jfr06WNLeY1pjkmRQw= X-Google-Smtp-Source: ABdhPJxC2dVUeGrsMzufE/PPAnnV5JVFXYJ1603yy49J6iLRKpCrny229Q3LJszFByT+/S+fgu96ug== X-Received: by 2002:a05:622a:48c:: with SMTP id p12mr4023323qtx.77.1638280223656; Tue, 30 Nov 2021 05:50:23 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:6e88:14ff:fea7:590c? (2603-6000-a401-3a00-6e88-14ff-fea7-590c.res6.spectrum.com. [2603:6000:a401:3a00:6e88:14ff:fea7:590c]) by smtp.gmail.com with ESMTPSA id 8sm11057239qtz.28.2021.11.30.05.50.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 05:50:23 -0800 (PST) Message-ID: <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> Date: Tue, 30 Nov 2021 07:50:30 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> From: Jason Bacon In-Reply-To: <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J3Nrw2Mq5z4RpQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=FKopplWO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::82e as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-3.95 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.95)[-0.949]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82e:from]; 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:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 11/30/21 05:53, Floyd, Paul wrote: >> Message du 24/11/21 11:08 >> De : "Stefan Blachmann" >> Port nouveau to FreeBSD. >> >> Reason: >> There are ongoing changes in the xorg API which break older >> proprietary Nvidia cards' legacy drivers. >> In addition, Nvidia plans to drop/discontinue support for their 390 >> driver in 2022. >> Nvidia already stopped support releases for their 340 and older >> drivers so that a lot of Nvidia graphics cards can no longer be used >> on FreeBSD already or will be unusable very soon. >> >> https://nvidia.custhelp.com/app/answers/detail/a_id/3142/~/support-timeframes-for-unix-legacy-gpu-releases >> > > > That's bad news that I hadn't seen. > > However I'm not sure that porting nouveau will help. My experience on > Fedora is that nouveau simply never works. > > A+ > Paul If your nVidia cards are basically landfill, like some of mine, and you don't care about 3D support, xf86-video-nv still works in some case that would otherwise call for v304. I wonder if it would be a simple matter to add support to it for some additional older hardware supported by v340. Yes, I know nv is deprecated, but this may be the only solution for ancient hardware. -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From nobody Tue Nov 30 14:03:25 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AFD6C18BA286 for ; Tue, 30 Nov 2021 14:03:29 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3P802zKYz4YYT for ; Tue, 30 Nov 2021 14:03:28 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id v11so44670208wrw.10 for ; Tue, 30 Nov 2021 06:03:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=aNTyVXyCDfhnaVGg9udBsHisuZz39QmstUtMq4Dwi1w=; b=Lwwo6sXpMt8zs5KV7pZ7tjDbRUuGzBUSVJp/HXPnxkJzW5iBxXjbTDerc/YoTJchHQ p5SmCTV+Sqmwt18/R3dt2dgJFawhrXyPZvKNuJtfOOwpVhh563S/dSGSZd+xyggUaVaY GJBvGi+WCaHKax6afeVJffYDn1Eb4VRdc+9cTj2s3Ii2WuGPscEaZ1CXcHmxDZwb2Oai IYby2yDccoiBFwsle5Xx6KRCMfG1e0iPD5T5etybLNqxtQZmHfso4vzmAneCcPz/h2kk oimf2hEKi937ifRLepCtblpPagc/Tqbtl0j3wQdrfKfSJlMHLvLVe1oYIE3jtP2TFFF0 hqHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=aNTyVXyCDfhnaVGg9udBsHisuZz39QmstUtMq4Dwi1w=; b=Wb3V0HDKNyLa60sa+xv7YmE8bXvCt7Oh/Sv71wA3+Z4l+JQ5ulG2NtmJxq9C1Rwz0h j7HGb+o2J+EUSx1jKoyFUb9RImG8zFJEABUZvswAhpekwoRYWNm1InGOhQjdrQsFlsSG G0WYLMKvJXS8j0Sr0yCOLAE/GH+8koKvW5QKRYO/HM3otAPl4M/7sbIRMCYm9sn1WEfr H+eanuKlarF6n4GBWF2CSOkxVxBXgQFCB2vhyh0bTetWvSTrDAtU69GGc+LVLzaxOsuB Y/sQEpxxhqF18i6h8gm+a4QUMschFWKa0oFMFxM9zMgcZeVLBm9zuBFUr2qjiDjz7C3t JENw== X-Gm-Message-State: AOAM531I2f9x+LPEelWqtVzZOZw9T19jXF6pDx/+YrpabVLKWAD1j4jG v/g1FvqwG/iEuujcBOW9FZKCGsRNbMndq/Xc X-Google-Smtp-Source: ABdhPJynZ3dg11ASH4Wcp6sqJ2m+0r/zq46tIg4/17/HfWlZoCO2uutKwiy39fY11exccZFd7wNPWQ== X-Received: by 2002:a5d:4d8b:: with SMTP id b11mr39858346wru.393.1638281007260; Tue, 30 Nov 2021 06:03:27 -0800 (PST) Received: from [137.202.253.121] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id w4sm17295356wrs.88.2021.11.30.06.03.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 06:03:26 -0800 (PST) Message-ID: Date: Tue, 30 Nov 2021 15:03:25 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> From: "Floyd, Paul" In-Reply-To: <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J3P802zKYz4YYT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Lwwo6sXp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-3.92 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.92)[-0.920]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; 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]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2021-11-30 14:50, Jason Bacon wrote: > > If your nVidia cards are basically landfill, like some of mine, and > you don't care about 3D support, xf86-video-nv still works in some > case that would otherwise call for v304.  I wonder if it would be a > simple matter to add support to it for some additional older hardware > supported by v340.  Yes, I know nv is deprecated, but this may be the > only solution for ancient hardware. > No, not quite that bad. I do have one old workstation running Solaris 11.3. If ever that gets upgraded, it'll also be most of the hardware in the box. My FreeBSD machine has a GT-730 based card. When it boots linux, it uses the 390 driver. For some reason on FreeBSD 340 works but not 390 (at least that was the case when I installed, ~18 months ago, I should perhaps try again). A+ Paul From nobody Tue Nov 30 14:41:31 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A03BB18CDAAF for ; Tue, 30 Nov 2021 14:41:43 +0000 (UTC) (envelope-from dim@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 4J3Q0739JVz4pqj; Tue, 30 Nov 2021 14:41:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 380EF6785; Tue, 30 Nov 2021 14:41:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CE15253EDE; Tue, 30 Nov 2021 15:41:41 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_866B34B4-775B-494E-9B7B-E5E870EB2A0D"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm/clang upstream Date: Tue, 30 Nov 2021 15:41:31 +0100 In-Reply-To: Cc: "freebsd-hackers@freebsd.org" To: Paul Floyd References: <43a13a6b-baee-e8cb-3624-ee98da510ad0@gmail.com> <0E4F98DC-1B05-4E1C-813F-4246C45E9C85@FreeBSD.org> <308f3c42a357e6be288e01060868fa7b003ced4b.camel@moritz.systems> X-Mailer: Apple Mail (2.3654.120.0.1.13) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638283303; 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=eNvcrToYD0ynDln91ZsD6mgx+Oa2rEa9ufVQ2YfPwGg=; b=OmznoIXGxH1OQQf8Bgn47AhiLUFZi6m5/Kde/5/Nr9Hcq7QEC+YihPOVOktYB/Oj+xjXLe Wz+F9Z+ebJv7EJRynwETBQkzNX5C/EB4TS6xD+YKkOQWm2VMFRnjgDdUs/YVVSvDXJetB4 Oz+S+lfEU+3OE4R7Si+wtSaXE/PNtqluzArVgHHnRpUskbya2RTDXk90YBLvY00Bdgamh+ byGU3ctALwhORqhRVMR65LuoNjJhcwncXuNgRjLTSrVXBo9svQpS8mU2NxOSrgxVVwD4GP ZDPU0egBl+74GJAhyqs8NQZTQ3gubOtebXRO3wUhiisJ6wcC6We9r9Dw23u5kg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638283303; a=rsa-sha256; cv=none; b=cl0c6sGiRs2imxb2thqabzrBqwyQSmGNOzbHqPJ3R+WDDpJ2ML42441g9aM+31JZd4HP0G Ag2aRURnWastwOITA/HPfIGkj2smUxDD6onHEDc4a+RBWtu/2PapZjbBXhuTrNdlsI+2Dz i101q3zoO72NRb/h1tgZGBm0AVtiSjvAWC2PzNAflJbNpJurIA1ivQPLnfLJbflN3ffi1Z 0njgH8lB92up1XVwDwqqg/HBNElg/MwsKZob6dUBJX3q1WebPl4r95Tev441bkYnLWlH4g AWn9nFYUeI1NGRGUuF4Ike1xpLcgufbfuwnc29XkZTfiv9hFN+YGtxZFMCMAsA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_866B34B4-775B-494E-9B7B-E5E870EB2A0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30 Nov 2021, at 14:27, Paul Floyd wrote: >=20 > On 11/30/21 14:03, Micha=C5=82 G=C3=B3rny wrote: >>=20 >> Please note that the "official" way of building stuff has changed a = few >> times, so you might be using an outdated approach. I think the = current >> way of building runtimes is via LLVM_ENABLE_RUNTIMES. > I'll take a look at the 'official' llvm web pages tonight >=20 > Up to now I've been using >=20 >=20 > cmake -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=3D~/tools/clang= -DCMAKE_BUILD_TYPE=3DRelease = -DLLVM_ENABLE_PROJECTS=3D"clang;libcxx;libcxxabi;libunwind;compiler-rt;lld= b;openmp;pstl" >=20 >=20 > (just added libunwind) >=20 >=20 > which gives >=20 >=20 > = /home/paulf/scratch/clang/llvm-project/compiler-rt/lib/sanitizer_common/sa= nitize > r_unwind_linux_libcdep.cpp:26:10: fatal error: 'unwind.h' file not = found > #include > ^~~~~~~~~~ > 1 error generated. Yes, this is a rather annoying shortcoming of our base system, really. We should provide unwind.h (and associated headers) directly in /usr/include, while we have historically only provided it in our C++ include directories (/usr/include/c++/v1 now, but this used to be /usr/include/c++/4.2.1 in the g++ times.) The trouble is that we have dragged multiple slightly incompatible unwind libraries and headers in our src tree for ages now, with no really good solution in sight. At some point we should choose one of the N implementations and stick that into /usr/include. :) -Dimitry --Apple-Mail=_866B34B4-775B-494E-9B7B-E5E870EB2A0D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYaY4GwAKCRCwXqMKLiCW o0FrAKDf60lLTFCCewGPe+B+/acmZzpcIgCfU74J4BsvNz9R+khk8v0onilsNwk= =mMWH -----END PGP SIGNATURE----- --Apple-Mail=_866B34B4-775B-494E-9B7B-E5E870EB2A0D-- From nobody Tue Nov 30 14:55:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7D1A418AD63E for ; Tue, 30 Nov 2021 14:55:51 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3QJQ4CB2z4vTv for ; Tue, 30 Nov 2021 14:55:50 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 1AUEtg8L013074 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 30 Nov 2021 09:55:48 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <8a3b989f-cdeb-7371-6d75-caf14a1b6050@m5p.com> Date: Tue, 30 Nov 2021 09:55:42 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> From: George Mitchell In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4J3QJQ4CB2z4vTv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-0.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_SHORT(-0.29)[-0.294]; NEURAL_SPAM_LONG(0.39)[0.386]; NEURAL_HAM_MEDIUM(-0.70)[-0.696]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 11/30/21 06:53, Stefan Esser wrote: > Am 23.11.21 um 23:41 schrieb Joseph Mingrone: >> Hello FreeBSD community, >> >> The Foundation is seeking suggestions for new projects to support. What >> gaps in the Project are not being addressed by the broader community? > > The "new" ULE scheduler has a number of well-known issues, which leads > to the "old" BSD scheduler giving better performance on many systems > and loads, but is based on concepts that made sense in pre-SMP times. > > [... a collection of highly salient points about both schedulers ...] I'll second the recommendation to take a hard look at FreeBSD scheduling and to consider a brand new one. At the same time, it would be most helpful if the choice of scheduler were a boot-time tunable. -- George > Regards, STefan > From nobody Tue Nov 30 15:32:57 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2D66B18C00BA for ; Tue, 30 Nov 2021 15:33:05 +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 4J3R7N6BRSz3QRB for ; Tue, 30 Nov 2021 15:33:04 +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 1AUFWvj4041331; Tue, 30 Nov 2021 07:32:57 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 1AUFWvc6041330; Tue, 30 Nov 2021 07:32:57 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202111301532.1AUFWvc6041330@gndrsh.dnsmgr.net> Subject: Re: Call for Foundation-supported Project Ideas In-Reply-To: <8a3b989f-cdeb-7371-6d75-caf14a1b6050@m5p.com> To: George Mitchell Date: Tue, 30 Nov 2021 07:32:57 -0800 (PST) CC: freebsd-hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4J3R7N6BRSz3QRB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[freebsd]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 11/30/21 06:53, Stefan Esser wrote: > > Am 23.11.21 um 23:41 schrieb Joseph Mingrone: > >> Hello FreeBSD community, > >> > >> The Foundation is seeking suggestions for new projects to support. What > >> gaps in the Project are not being addressed by the broader community? > > > > The "new" ULE scheduler has a number of well-known issues, which leads > > to the "old" BSD scheduler giving better performance on many systems > > and loads, but is based on concepts that made sense in pre-SMP times. > > > > [... a collection of highly salient points about both schedulers ...] > > I'll second the recommendation to take a hard look at FreeBSD scheduling > and to consider a brand new one. At the same time, it would be most > helpful if the choice of scheduler were a boot-time tunable. -- George I'll third it, I almost always switch to running the "old" BSD scheduler. > > Regards, STefan -- Rod Grimes rgrimes@freebsd.org From nobody Tue Nov 30 16:32:37 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DC3A818BE113 for ; Tue, 30 Nov 2021 16:32:37 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 4J3SS55MH6z4TJk for ; Tue, 30 Nov 2021 16:32:37 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x835.google.com with SMTP id z9so20763234qtj.9 for ; Tue, 30 Nov 2021 08:32:37 -0800 (PST) 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=U9I/+MA0G9MOKdkiuZAtIU0zpQLX272U3CfJelB0dPU=; b=dP8/EYssKq75MCPRc/Cf3FHV3iMEP2jPAf0PqMr6gJBtpLMpWDbDnK8USsBaT7bMbL mZsUKqsKaFVXGbpOQ4NYvKxhdYet17m6+gofXgNVi0koc+l5Mf3S+MFxf4FUgClp0qSM K7DpdAwANtiGgGplqMVgOqkcOr2yyadCrHMB6lZq6u9jhukOg6tsM7vDyTCzlfXMbVkL JGwXCqNL04nzHjnj8VKoJ/bjNWQgQstT3vk8E9bdElIz7P7xnjc9Gp3S95RIv8tSGMxn lUVoAKNolLfpCxCt85UFVGoGnHyon1es3QwWiTOAlesLlqxauip6h4cF288frm+w+sPA CDyg== 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=U9I/+MA0G9MOKdkiuZAtIU0zpQLX272U3CfJelB0dPU=; b=Tx+ILZTeimlWaIbk7Axs/ddPfogxmdQABe4r/X8Xt1ZbUXq1IbRK0papMX1z5Acv7L aAAzoHRI1L8fZKKXDNZrHiAs9pHERPxnO6laY/L1VUv13H+Uxy/5keWNjn6KBGgHuh3L boGHA3xfqEUpDBs8+6k86jKd9eq/+V9kMunppcfxAhKi5X++7LpRzwehbZDeRtOFmef7 e3PfN6xiQCvvtCHYHj5Sg4NWzTSDMtBJiiNSnM9oLC2cqTdF9+VGrBrhw7mDG6XodrXj gRmBctfDsamT0ZrISxtoITnSNqEg522ltE7aSWM1o+qorxVkDwQfARzWQe7nznNXHi7z CiwQ== X-Gm-Message-State: AOAM53352IrlH5br3PSkJet8UGlOVUQzjyIWvaXngYDnXYhbgKbomsJa 6M4pPUV1mDMXivVJeIO+CQDavg== X-Google-Smtp-Source: ABdhPJzK4gC88sbrQTkMq3t5uMX5cBfyCoCeqcCVI+Zl+KqydznHxaIPQYPCMubYeCWKrTKAW0yYGg== X-Received: by 2002:a05:622a:1310:: with SMTP id v16mr382089qtk.431.1638289957324; Tue, 30 Nov 2021 08:32:37 -0800 (PST) Received: from mutt-hbsd ([38.140.209.220]) by smtp.gmail.com with ESMTPSA id w10sm10141573qkp.121.2021.11.30.08.32.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 08:32:36 -0800 (PST) Date: Tue, 30 Nov 2021 11:32:37 -0500 From: Shawn Webb To: Stefan Esser Cc: Joseph Mingrone , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211130163237.hdfl7bsthccbxo7l@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: <861r36xzpe.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x37rvubhivh732aa" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J3SS55MH6z4TJk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --x37rvubhivh732aa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 30, 2021 at 12:53:20PM +0100, Stefan Esser wrote: > Am 23.11.21 um 23:41 schrieb Joseph Mingrone: > > Hello FreeBSD community, > >=20 > > The Foundation is seeking suggestions for new projects to support. What > > gaps in the Project are not being addressed by the broader community? >=20 > The "new" ULE scheduler has a number of well-known issues, which leads > to the "old" BSD scheduler giving better performance on many systems > and loads, but is based on concepts that made sense in pre-SMP times. >=20 > ULE suffers from pathological behavior in many scenarios, and it does > not know how to best deal with simultaneous multi-threading, big/little > architectures, or the effects of virtualization. >=20 > ULE does not care for the "niceness" of a process and lets nice -19 > processes run with hardly any reduction of the share of CPU cycles > granted compared to competing nice 0 processes, for example. >=20 > Virtualization gives a number of additional requirements and restrictions > in both the host and client. Schedulers in other operating systems have > been modified to reduce the risk of side-channel attacks by running only > processes for one user at a time on the virtual processors of an SMT core. >=20 > Within a virtual machine, the real topology of the underlying hardware > may be hidden and scheduling effects by the VM host may need to be taken > into consideration (e.g. clock variations and "time jumps"). There is > a connection to bhyve, at least (perhaps also to other virtualization > platforms) that has to be taken into account. >=20 > Another aspect is optimization for performance vs. optimization for > low power use, which both require a specific scheduling strategy on > complex CPU topologies. >=20 > IMHO, a scheduler design that is based on experiences gained by other > projects and our knowledge of deficiencies of the currently available > schedulers in FreeBSD under specific loads could be a huge win for the > project. >=20 > This would be a long-term project, and I do not see any developer > currently working on designing or implementing a new scheduler. >=20 > There have been minor changes to SCHED_ULE, recently, but I'd think > that a completely new design will be required, based on knowledge > gained in the last 1 or 2 decades and able to deal with architectural > changes that have occurred in that time frame. I also wonder how the recent push to big.little on multiple CPU architectures affects FreeBSD and how we could support it. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --x37rvubhivh732aa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGmUiIACgkQ/y5nonf4 4forKg/+KPAYRJRx3csbecFMw7k6q+RMUn1Tn8Gf+SGzLvTltl0wMKOZqR/v3Wa3 MuOop1kTFBquT9rzdtlcxH9LkVoRyVjM4Vdm7lBQnRT2oyhe8R7EP7STlQV+wAlF ntRk9Mz1yj2c41/G+T7J3bRU2VW9fw3oMPXQ7s8Pe562oeD6kqifF8wZkQp3xFpv ZaZZ3YYVwuce7KEaA8whUjAhcZ2QnGHpOH1599BtNOC9sekgXKmx69MtJUa+eff/ YsZ70EzRLNa5rosbBY8fqojyNnJ6HuogC8HRn9RiId38LpiCv5g4ORDCENviD4Rv YDLO7ZSd0NdvaUzGFrvZSH6L1gZFeWuyiDy7UvNJJaBtvCtQrQrGvGzRn5HEjoPb k7ymZ1v4Wi0hZ/D3bFOdUat0TErnzSiY1ad9ssVKvSMk6mubLGlrfj9jv6AtGbV3 IqSbjMRmk5Pop6BiNhddF2ffOqkeAvNxHcr+HGcWO3oALAyCU/vmafFviM6TqI8o 9jpHB+WVOODP7VvshiwGkeWmutc/JRv3//RzW1rAIk8srlCTeZoB5bExbxPIbdqa 9oxNfdobA/HZ5cjtl6jWunO2+UcwrQ5DmzDo0hmw/RiEpYBMw1F4LQgjAmY8KiVd ELSByXV6wfMxr9HbsaSKoOdgawANT6oSVWOvUTDzG3yOs/5Op2Y= =fhGt -----END PGP SIGNATURE----- --x37rvubhivh732aa-- From nobody Tue Nov 30 17:15:24 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B279418A9929 for ; Tue, 30 Nov 2021 17:15:27 +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 4J3TPW43YSz4jWY; Tue, 30 Nov 2021 17:15:27 +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 0F77671DB; Tue, 30 Nov 2021 17:15:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <9b14c3fc-67dc-b07c-6e2c-d3d9ada38abd@FreeBSD.org> Date: Tue, 30 Nov 2021 19:15:24 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.3.0 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: "Floyd, Paul" , freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> From: Andriy Gapon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638292527; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/1+E12zw77GUiNsmwSgY/a2RaTQPaOx/k2M0Weaic40=; b=UD4UGrn/iBIErXoIeSngmpFzMmYLUrPHNdhzt+yUVoWHwiwO56nusE9TX+BFEyoppOGL+2 CvW4Al45vDsuJyQ5YBomVVhXS7DfewFj/dJPT1tA8UiEcW3sXSld3AQ/w9tgorGWo2YCwc xildDbt7efokPgnme4j2101e7R6OERHnlBl2k6OXaF4eFjYuPypCzGfvxyVPDLTJXcRVcK ZdsZbV1wfwRdOxkPDaxLRPwtgeLiZmRQB1ejYT7gTAfTnd0KyXDvXJCXBX/8aSVKzBUMNg yA/0jCzbY9ZvcdSqTr3uPNfRzBoU1tcl/ev3vAA2fi2fn0FXwVHOeAHCKnzoCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638292527; a=rsa-sha256; cv=none; b=n7aLXuKoGeI+bMoXUU5fLx/lLilu2v7e2upD6d2bQDWs39YOIXfEdg4NW2att2/PVjFCq2 G2BbTVE8WcvRR89SOsXfWI8qYYZ20FNlj+AyrrvT23VsLRhvLo4AVDjMyRh5xOiTAI97TD YG06oJL/dlBuTgIYvl0BRIUiafrQvFdRsnesYTjHzJjqvLzr8WXHszRAxvBXP8+8NpTrVE L7X13Zo1gp3uHfrXIbVPrDxGpmqutHz50i0bzomWIchk3pBZ3uzT26EHgGZo1QrZrFD1lr skPzOBeZsUskxxUJjRtaL1ej5qLE4Dd882Ehw5eysniPTdy+x5sw3mBEu1fTmA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 30/11/2021 16:03, Floyd, Paul wrote: > > On 2021-11-30 14:50, Jason Bacon wrote: >> >> If your nVidia cards are basically landfill, like some of mine, and you don't >> care about 3D support, xf86-video-nv still works in some case that would >> otherwise call for v304.  I wonder if it would be a simple matter to add >> support to it for some additional older hardware supported by v340.  Yes, I >> know nv is deprecated, but this may be the only solution for ancient hardware. >> > > No, not quite that bad. I do have one old workstation running Solaris 11.3. If > ever that gets upgraded, it'll also be most of the hardware in the box. > > My FreeBSD machine has a GT-730 based card. When it boots linux, it uses the 390 > driver. For some reason on FreeBSD 340 works but not 390 (at least that was the > case when I installed, ~18 months ago, I should perhaps try again). Just as a data point, nvidia-driver-470.86 seems to work well for my GT 730: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 470.86 Tue Oct 26 21:43:42 UTC 2021 nvidia0: on vgapci0 -- Andriy Gapon From nobody Tue Nov 30 17:55:40 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 50A3F18C1809 for ; Tue, 30 Nov 2021 17:55:42 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 4J3VHy1McPz3HQC for ; Tue, 30 Nov 2021 17:55:42 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lj1-x22a.google.com with SMTP id i63so42703184lji.3 for ; Tue, 30 Nov 2021 09:55:42 -0800 (PST) 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=kTzHAm6S3bB8jlYuJEGuJIpXjNWzxvYX1NHnOAwkFbQ=; b=PV9a+tgj15+/UIkeAeCLHRQZg1zOG/gChoVPK+GB1ZkgsNoy4eZ1jW6Z+KzAfKp9iS 1p0fusZOAFDZAKeMaaDGXVrWK14MlqC1WkneWFH+Gz4VzbNPVskWXDnI8f+fwaX70Rkq eC4oaYrPcASo965jKkBHOyLnrrUybe+JZYQ7gtjwNFRbUz/oCUCrLJpzw4W1ceYGoaP0 ANTKTBt2ceCpqUKOf6VZM64K8kJTuvGAHUMhTbceWe5/D3OCsIDgm8vRe4ke8Jyop4ww iW8xovmINPV2w9BptFp6RBWW5PkdECqSB4ummsSxIcZ0Fm9bLjLTojl/hY1pCNfbIGJ7 juZA== 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=kTzHAm6S3bB8jlYuJEGuJIpXjNWzxvYX1NHnOAwkFbQ=; b=yGFqWDugIb+hPjHACqRBNic5zxpP9CMkzRH2S6kKknwN3ACxAqD6zwFy+cP9qtnv0I +5YnqLjiklH1jbWhUq4Nmfk+aXeRb8tjK84N1xAGsA/UtCE1Cja3qcWoAVnd8LwjtSYg 8nBQpss/XnlXC9ieCT7BM8pez0b9mCn8/oNsDah++C8ir8dlb0O7JFq569mQmIxbejhW scAFFQ0qeL0ImvPf0VriGAsqi1B/Hbz8C7XIcbL6abd+ytWk1qyzH3FtSsWRJANyTAqv WWwEwgMa9ZW3hacK/MYw0ypeczK88KAJi7IZ6ujgAURIPN5rpxAQOGr4XqblqeQO0otk 3IfA== X-Gm-Message-State: AOAM531sB/CGJWPu6z3nvRbwNdOSWXtHs4ZR3ucYFE3yfIaUCuGfB/c3 SqiYHOiVcpBJS+Jei9ATXB2bBf6b/cvcuGuusnsMNnRh X-Google-Smtp-Source: ABdhPJylqlrbXUY40aKXxIiz8iqAAoNbsa/4KoNrW5b5KfedFy0ZVHpA6LtQGrIZXvM9OS9DkqCnyik9UDWIY7vBdc4= X-Received: by 2002:a2e:a7cb:: with SMTP id x11mr458090ljp.308.1638294941047; Tue, 30 Nov 2021 09:55:41 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Tue, 30 Nov 2021 09:55:40 -0800 (PST) In-Reply-To: <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> From: Stefan Blachmann Date: Tue, 30 Nov 2021 18:55:40 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Jason Bacon Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J3VHy1McPz3HQC 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 11/30/21, Stefan Esser wrote: > ULE does not care for the "niceness" of a process and lets nice -19 > processes run with hardly any reduction of the share of CPU cycles > granted compared to competing nice 0 processes, for example. I can confirm this... always believed it's just me. I'd like very much if renicing would have more, actually usable, effect. On 11/30/21, Jason Bacon wrote: > If your nVidia cards are basically landfill, like some of mine, and you > don't care about 3D support, xf86-video-nv still works in some case that > would otherwise call for v304. I wonder if it would be a simple matter > to add support to it for some additional older hardware supported by > v340. Yes, I know nv is deprecated, but this may be the only solution > for ancient hardware. Actually xf86-video-nv overlaps into the range of what is supported by nvidia-driver-304. Practically all nvidia proprietary drivers overlap in their range of supported cards with the "adjacent" versions. So it is common, for example, to see the newer ones of the cards that are supported by 390 are still supported by, for example, 470, while the older ones still supported by 390 are supported by 340, too, but not by 4xx. The bad thing now is that with nvidia having already dropped 304 and 340 support, the next xorg ABI change will render the "middle field" (eg not yet historic, but not yet very new either) of nvidia cards useless on FreeBSD if there is no nouveau port. On 11/30/21, Floyd, Paul wrote: > However I'm not sure that porting nouveau will help. My experience on > Fedora is that nouveau simply never works. Never used Fedora. Maybe it's because Fedora is very close to commercial RHEL which might be not really targeted at desktop? Personally, I never have tried Fedora, but used several other distros. Nouveau always worked fine for me. So no idea what's the cause the difficulties you are experiencing on Fedora. On practically every Linux distro Nouveau is the quasi standard driver for any type of Nvidia cards, as the proprietary Nvidia drivers are non-free category. So I think one can consider Nouveau as very well-tested and reliable and that porting it to FreeBSD would be worthwhile, profiting many users who would else either have to buy a new graphics card or migrate to Linux. From nobody Tue Nov 30 18:59:11 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 00BD618BF944 for ; Tue, 30 Nov 2021 18:59:48 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 4J3Wjv5jhhz3rVd for ; Tue, 30 Nov 2021 18:59:47 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ua1-x933.google.com with SMTP id p2so43486476uad.11 for ; Tue, 30 Nov 2021 10:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/yvWYt2x5KLry4dnr4z2J4+UrvqN39jOeM4UtxznlSs=; b=HuVN0b97rt3kLgLTIW6pfdBkNd75nnml4ViN8bYQfk/paRuKkJxZre1Duoc6l4Wjwk rdHPs/HQDrQdMmXyB9IrgP1hO3avXHUQtf/d4UPUo+7y0iH2yrp5fS/GFVR+kZ2T0r5Y Vbk4VP2m65jNgM8KcWmnrd7OpiAHJJglr67ZLqwNdilcOuOQxuYsWOnDPAvaRf231SG4 vRmAxxNcE45fU77u2Lml9ITrCZuB5h/cdpMFYswLrRB+NM+mZAx1XWY8wdCCwgB3gvLI QvR+DVRF3LgFnV0hJ61FT4JcV3+YN+WpP5VrjAReomj+SggtfOZDa72SYy6zfCd/+2Ge zxbQ== 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=/yvWYt2x5KLry4dnr4z2J4+UrvqN39jOeM4UtxznlSs=; b=S9jfWweZb4OiMF/dFwK/vmkgyC8ZUqOnXs9iBjT/6z3XryvvXquOZZhWkho0JFr3ze RMhSSJOV+UWqecfyfx48Fjru2HkSWpbpldZqWRChDrQQv1oEa+iwOq7dU98coKIzEfCL WifkWKeFooi5+g2TbFDC3qqPDz0cZVfwXVdqzIw//0u1oOnD9n6YIE+1pRjMfnsPSOUm MBJvDRhbCNfXj+TLnVlWsAShQOYuoNgG+eKnbOZ8xKJJ+LX6SZO7z1E+j4B3ICstDx09 7JmaQCdkrA0ybn85Wyq5BQHrRJd3hMYQ6kMhTVI0pkupvctkQEGR2Rx/vebjEw9RTXFB VNiA== X-Gm-Message-State: AOAM531IKdziezJsCBdPQvsa+gci4EYdL2v6pgRulu/H0SZimGYfMMal 63atRi8puHVYGKE1sofljV1EACDuMTPd5DclR1w8YZkO X-Google-Smtp-Source: ABdhPJzaGQRbRdXfHs26776lTsvUxX3KqqxedYjX7rfa9FeXLyr3xtjLoWvvnsaMzsuH/hycqjBlPjaljz6xLHlkmmY= X-Received: by 2002:a67:c79a:: with SMTP id t26mr1007672vsk.37.1638298787385; Tue, 30 Nov 2021 10:59:47 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> In-Reply-To: From: Mehmet Erol Sanliturk Date: Tue, 30 Nov 2021 21:59:11 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: Jason Bacon , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000042168a05d2062927" X-Rspamd-Queue-Id: 4J3Wjv5jhhz3rVd 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 --00000000000042168a05d2062927 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 30, 2021 at 8:56 PM Stefan Blachmann wrote: > On 11/30/21, Stefan Esser wrote: > > ULE does not care for the "niceness" of a process and lets nice -19 > > processes run with hardly any reduction of the share of CPU cycles > > granted compared to competing nice 0 processes, for example. > > I can confirm this... always believed it's just me. > I'd like very much if renicing would have more, actually usable, effect. > > > On 11/30/21, Jason Bacon wrote: > > If your nVidia cards are basically landfill, like some of mine, and you > > don't care about 3D support, xf86-video-nv still works in some case that > > would otherwise call for v304. I wonder if it would be a simple matter > > to add support to it for some additional older hardware supported by > > v340. Yes, I know nv is deprecated, but this may be the only solution > > for ancient hardware. > > Actually xf86-video-nv overlaps into the range of what is supported by > nvidia-driver-304. > Practically all nvidia proprietary drivers overlap in their range of > supported cards with the "adjacent" versions. > So it is common, for example, to see the newer ones of the cards that > are supported by 390 are still supported by, for example, 470, while > the older ones still supported by 390 are supported by 340, too, but > not by 4xx. > > The bad thing now is that with nvidia having already dropped 304 and > 340 support, the next xorg ABI change will render the "middle field" > (eg not yet historic, but not yet very new either) of nvidia cards > useless on FreeBSD if there is no nouveau port. > > > On 11/30/21, Floyd, Paul wrote: > > However I'm not sure that porting nouveau will help. My experience on > > Fedora is that nouveau simply never works. > > Never used Fedora. Maybe it's because Fedora is very close to > commercial RHEL which might be not really targeted at desktop? > Personally, I never have tried Fedora, but used several other distros. > Nouveau always worked fine for me. So no idea what's the cause the > difficulties you are experiencing on Fedora. > > On practically every Linux distro Nouveau is the quasi standard driver > for any type of Nvidia cards, as the proprietary Nvidia drivers are > non-free category. > So I think one can consider Nouveau as very well-tested and reliable > and that porting it to FreeBSD would be worthwhile, profiting many > users who would else either have to buy a new graphics card or migrate > to Linux. > > I am using Fedora KDE after FreeBSD 9. ( I think 2 ) because it is not working on my computers ( mainboards are Intel ( using *915 ) produced for Windows ) . Up to now , the most effective disadvantage was the "scheduling" structure : If a program or programs starts to perform continuous disk read-write operations , the computer is becoming unusable because interactive operation requests are responded with an annoying delay . Now , my hard disks in a computer have become unusable due to a country-wise electricity fluctuation ( in Turkey ) . The Fedora KDE was version 28 . To obtain a workable computer as soon as possible , I have installed Fedora KDE 25 to use parameters of the OS from a computer using USB HDD with Fedora KDE 25 . This install converted my large number of compiled programs from open source repositories to be unusable because of library versions mismatch . Since all of the repositories are lost , I decided to install Fedora KDE 35 ( last ) . The previous versions were working very well , but version 35 had lost such a "working very well" capability . I have installed Fedora KDE 32 , with "no help" . This means that the older hardware support has been dropped while they are "working very well" . This is the "gift" from our "blessers" . Mehmet Erol Sanliturk I have decided to install --00000000000042168a05d2062927-- From nobody Tue Nov 30 19:17:20 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 77C3D18C9348 for ; Tue, 30 Nov 2021 19:17:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3X6l4GcXz4SGv for ; Tue, 30 Nov 2021 19:17:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f42.google.com with SMTP id k21so27590325ioh.4 for ; Tue, 30 Nov 2021 11:17:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3yVH9IxOsSYOe8Jf3vrO95iFEjGLD4dEs7G41j+jm+Q=; b=4R9J+nEEPjSO3k1zj0XH7QV5Lery1oEL435Fml/lpqAYEDBCbYX3zbREcHxTx8CZl6 mKgWuv1p+lpbZuYauH+dm1QXzePkwjQkSe+nbPmwOLY+jEbcD4MeZQ7zgBrkzvC0JqTP +iCKmbmoJsnT4GfKBeEabpLK+bbtvWr00MFVWgtzxQimfmp7g/SDAIp9WVHwk+5xv/I8 pRTpG5ObtcDG+SjYRqJ5Gm8G60MS+DKnrUKwBz9ADXyIHf3247bpgYP10QHJu/97LlXf yz1EtlV0y8ayDV5RdOhqlMnnAYe2Bj3jVnrk6NBBvQZL/sWMTAdyNjJS+9tZcZ7BcpGU ToPw== X-Gm-Message-State: AOAM5320gqb7je4iMRkhTDXfp0lJOUBjXapZWZA536cLS2orypNqcy6E SsAVydhpI5oUQOLJvjzS37LtLRCzFgzVvoEgCoVyncXq X-Google-Smtp-Source: ABdhPJwnJLNw6sbJ7pTREyMBkcdO4qGqaDl+PL95Stv4vNrXyJcQbkKrOv/pdJA0IrcUA4oQe4dCfAxb+yRkv4CuycY= X-Received: by 2002:a05:6638:3182:: with SMTP id z2mr1966066jak.134.1638299864715; Tue, 30 Nov 2021 11:17:44 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> <20211129043612.GA82224@troutmask.apl.washington.edu> In-Reply-To: From: Ed Maste Date: Tue, 30 Nov 2021 14:17:20 -0500 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Steve Kargl Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J3X6l4GcXz4SGv 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.42 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-0.88 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.88)[-0.881]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.42:from]; NEURAL_SPAM_LONG(1.00)[0.999]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.42: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]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, 29 Nov 2021 at 11:29, Ed Maste wrote: > > On Sun, 28 Nov 2021 at 23:36, Steve Kargl > wrote: > > > > And therein lies the rub. Cirrus-CI skirts the issue with the > > slowing down of builds, so developers don't see the problem. > > This isn't the case. Developers are well aware that buildworld takes > longer than desirable, but it's reasonable on contemporary hardware. > Cirrus-CI and Jenkins are adjunct to the development process, they > don't replace local buildworlds. To add a little data here, the default Cirrus-CI build (using the llvm13 package, and not building a target toolchain) took, in a recent run of mine: 42:32 total 21:30 buildworld + kernel (the non-build time is spent provisioning the VM, `git clone`, packaging world, and running a test in QEMU) A run that included two Clang builds (bootstrap and target compilers) took: 1:46:49 total 1:23:47 buildworld + kernel From nobody Tue Nov 30 19:30:43 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C4DD718CFC8C for ; Tue, 30 Nov 2021 19:30:49 +0000 (UTC) (envelope-from mr@freebsd.org) Received: from app.eeeit.de (app.eeeit.de [188.68.43.176]) (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 4J3XPh0p0Gz4XV5 for ; Tue, 30 Nov 2021 19:30:48 +0000 (UTC) (envelope-from mr@freebsd.org) Received: from [10.0.0.180] (ip5f5bfbdb.dynamic.kabel-deutschland.de [95.91.251.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mike@reifenberger.com) by app.eeeit.de (Postfix) with ESMTPSA id 7A76B3C09A for ; Tue, 30 Nov 2021 20:30:46 +0100 (CET) Date: Tue, 30 Nov 2021 20:30:43 +0100 From: Michael To: Daniel O'Connor via hackers Subject: Fwd: Call for Foundation-supported Project Ideas Message-ID: <949CAEC9-25C4-4448-9C60-30687D17410B@pretty.Easy.privacy> In-Reply-To: <2BC55859-CA32-4DDC-B5E8-C17ED4934E0C@pretty.Easy.privacy> References: <2BC55859-CA32-4DDC-B5E8-C17ED4934E0C@pretty.Easy.privacy> X-pEp-Version: 2.1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=----ND0NLUATGKYKHEWIAXFNP1YGLCR39N Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J3XPh0p0Gz4XV5 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 188.68.43.176 is neither permitted nor denied by domain of mr@freebsd.org) smtp.mailfrom=mr@freebsd.org X-Spamd-Result: default: False [1.05 / 15.00]; TO_DOM_EQ_FROM_DOM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[mr]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; ARC_NA(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_SOFTFAIL(0.00)[~all]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.986]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.93)[-0.932]; RECEIVED_SPAMHAUS_PBL(0.00)[95.91.251.219:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:197540, ipnet:188.68.32.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys] X-ThisMailContainsUnwantedMimeParts: N ------ND0NLUATGKYKHEWIAXFNP1YGLCR39N Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 -------- Original Message -------- From: Michael Sent: November 30, 2021 11:03:13 AM GMT+01:00 To: freebsd-hackers@freebsd=2Eorg Subject: Call for Foundation-supported Project Ideas Hi, one missing feature is USB device pass through for bhyve=2E That would be quite handy for passing unsupported USB devices to Linux/Windows on Laptops where a controller pass through isnt possible=2E -------- Original Message -------- From: tux2bsd via freebsd-hackers Sent: November 30, 2021 8:35:36 AM GMT+01:00 To: "freebsd-hackers@freebsd=2Eorg" Subject: Call for Foundation-supported Project Ideas Hi Joe Call for Foundation-supported Project Idea, well not a project but an item= of importance in my opinion (the hostile forums disagree with me)=2E Some help to fix freebsd-update , a very longstanding poor performance pro= blem I took the time to investigate and provide an attempt to fix, https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D258863 I've been working with Colin Percival towards providing/fine-tuning a work= around but the program itself is monolithic and very intertwined which mean= s a seemingly trivial fix is actually a nightmare - the goal posts keep cha= nging with each step forward=2E Quite frustrating actually so I'd appreciat= e some help if mini-projects are acceptable=2E Thanks tux2bsd (apologies for the thread busting email) -- -- ------ND0NLUATGKYKHEWIAXFNP1YGLCR39N Content-Type: application/pgp-keys; name="sender_key.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sender_key.asc"; size=3890 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4c0JOQkdHbWU2Z0JDQUMzeEpi YkRKZ0tzZ1MvTy9JZk1RbUxsbmN2OUI4MTFoa2VpVFBQcVYzbUFmUlRlaTRkCjNIOFFHZ1BMK0xi R0Eyb2hQd1padE9Hd21XWCtqbUV0VG1HTVFTUkVqZzRxZFhJMUQ2V3ltM2dScStBMzdZblEKbjhx NktEdSs0am5tTmxZZElnYU5qdzhHdEJvTmdpdnh0c3QyWHdJM2JZWXozUWJqZlVMUUIyWEM1bWdo SWw0KwpEQUo2alBXc0I5V2kzZitCUFhTN29PNVhNOE84T2ZYMkhTUkV0My8wdnRpTnc3dWlCVk1D YlAwVkRHcFJ1T2NWCmFqT21tUjdGMEc3Sks4TEcwaTQwZ3MxL0ZZL01xVjZhQW9MVW5xbFFVTjIx N2VtaFNMVVNFSzJsbzh4NUczaWgKbGs5bWxNbE1BcW4yTkMzY0ZRc0FteWVHV1F4aHdtaXRqYnNo QUJFQkFBSEN3TThFSHdFS0FJTUZnbUdtZTZnRgppUVdmcGdBREN3a0hDUkFCVVhjcFMwZVh5RWNV QUFBQUFBQWVBQ0J6WVd4MFFHNXZkR0YwYVc5dWN5NXpaWEYxCmIybGhMWEJuY0M1dmNtZTcxRTU4 WExPYVhMZGYxdE5aRUhlRlJaRHlUT1U0VHFwckxEc25MMDdESkFNVkNnZ0MKbXdFQ0hnRVdJUVJ4 cE91VHdLS0tNMDA2NnZzQlVYY3BTMGVYeUFBQUdnWUlBS1lnVEExbm9VLzBzZnl1a21OVQpuaHpx dzArc3BpWGVIUUFWOGxwcExpZjUvQ255ZTVuY05HSldtbWF1aVRVdDJVdWVRWmpUMmtmbENKUk4z bGk3CjRKYjFaSGNkeTAxbVp6cHhiWHQ2TDZpb0pXY3VpUDZlV00xMWhSSTlmMWtLbEFVZDFyeFVX Z2lKUTkvU1lHWjUKN2hsdmhKYm5hRnNid3hOTEdncGk0OGplYXZlejZ3R0piSzdRYVMvY29qRk5Y UDRvSkRhMzl1R1F6WUpoT3VVUwpDMTdVQkJPS0pKMk80RVVRSmM0WlBwYko5a3lJU0kxcmxwOEJO NzdRSjlwMHFPWmt1enluVWkzWjJRWTh2YkFYCkdpQnNwWnM3QUFjc3pYeGdGRHZmWlFmT244Ty9a QzlSV2FjczRFRVI4cDRjQmt5cnNMUUR4MHlqOUJVdXFsbGUKUjNMTkdFMXBZMmhoWld3Z1BHMXlR R1p5WldWaWMyUXViM0puUHNMQTBnUVRBUW9BaGdXQ1lhWjdxQVdKQlorbQpBQU1MQ1FjSkVBRlJk eWxMUjVmSVJ4UUFBQUFBQUI0QUlITmhiSFJBYm05MFlYUnBiMjV6TG5ObGNYVnZhV0V0CmNHZHdM bTl5WjBlWW9vbzdLSXlVQXlLb3VSTFUydVErZ3dSOG8zSFVSQlZ4SkFWbUVBYzdBeFVLQ0FLWkFR S2IKQVFJZUFSWWhCSEdrNjVQQW9vb3pUVHJxK3dGUmR5bExSNWZJQUFEWGNRZ0FnOHR0aHlYZmpW UWFyQXdhaFBkTQp1RElvaVZpbEtlZ0VPWEZMT3crYy82NW5VdDZ6SXF0YnVHSmxPVFgyM01rQWZi ZEhRVkVNSUcxQ0o2aWM0ODdoCkJsVG9TditEcW5Xa2YvNXMxRk5XYVo3cU5IcjlwNjlpd2pEV0pI R1NjMGw2RkZxSnB0WWVHVU9XMjlVRHcrdmwKZnMvWDZuSGdFYmtraWxheURacmRPRjg5VC9JT1B1 NEc4QVpNSHM2VFhocjBROFhvOW9pdURDUlhFMzFJTmZjMQpIL0VlKzR5QXRId3RrSnA5aVpYeG1n NWFOUzdWN2JBU3N5Vkc5UmFhVXFxR1F6OVd4Tm5yQWlJZm55VDU2Y3p2CjFLNHdpV3BvV0FOeWxR cVk4aW9vTHIwRFB4TUM2SmROdzJRT3JpaklGS255QVN0cDR0a09UbnEyc2ZRTGcyd0QKVU03QVRR UmhwbnVvQVFnQW9iZnk0b2tMcGl5RnVKVTlGQmdiZ2N5NlRzUVVTa0d2QVpaVXdKT2cvYkpIZWg2 dwpNZk5ic1BaWHBidkNSSVMyM1UxenRYRy9Ec0FHaFlLT1NBV1dnN2hHZ0RaRzFycHN5ODR2aDAv TUhkVHp2bkZsCmRNSWV1UThEM0VIcEwvTWd0WGZHbmh6OFdWWnpEYkJmbkZLb2RpemFVcTRvZFUy OU9UZHBXTnpqSlc4eVNYRTkKSnBrSE1Velh0dVNHTElsdVJ3TEZWV2hXNUFPMjIwMU55K3lvZHVM a2tJeVhTVWE0d0djT3dHSEM5bGlLU3cxdwpJQUtwUHlpTm9udC9VSTVUU0xZakJGbStZMVo1cE9m ZDVKNHFNMlJRT2JRdXNLM2dUaGF1ZU1aZGRaem45a0pICmczNlR4ck9mbTllSjBBdHF0UzNGSWtj Ukd5Q01CYzBQTHFtM1ZRQVJBUUFCd3NERUJCZ0JDZ0I0QllKaHBudW8KQllrRm42WUFDUkFCVVhj cFMwZVh5RWNVQUFBQUFBQWVBQ0J6WVd4MFFHNXZkR0YwYVc5dWN5NXpaWEYxYjJsaApMWEJuY0M1 dmNtZG54YmtOOWRtbkp1Mm9xYzByMmZjK0tBMmhFRGY3MDNzc3RKbnpSaVpBTWdLYkRCWWhCSEdr CjY1UEFvb296VFRycSt3RlJkeWxMUjVmSUFBQmMwd2YvWTAxVWxtNUpKTkJyZlVHR2hqMndXLzRI L3JYbjJ1ZGUKSVgzb0o0ditpb1pKcFAreXlJV2x4YVlrTFJpeFpidEQrOFA5d2VqUndPSHEvbUFI QnYvQXNONjRhaU9JeU94cgp0aFlSOXE0VVlHelkvNEMxemo0WWR1T01jODczcTFQUFRMNVVCLzdo VmQ2OTE5L2EzN242aVhCTFhpeFBSbFowCmJJTklTLzh1TlRBc2ViMlFCd2srNkplclhoRzA5Z0ds dnZHTzhRZjMzT1d3OU1ROXgwaXYzdlFJVExqSzNUWTYKYVJtdGc5dHRhT3JMRHFDQUhkcmlzMmh4 Zk9RYm16UGVUNFh3aXRGTE5ZOGpDc2VlenVsWG9JOUpUZlJxU3p5WApsQW5JNGUvYWRvZzZ0Nk9N NkNrL2RWaUozejAvbnJ6NmFkMm5Tb1JJc3lhRGxieC83RUNHZDg3QVRRUmhwbnVvCkFRZ0E1MDYr N3ZCN1lCRTBLNE9uOFp0ZGNiZm5mQWV5aDZtejIzeWFPdHovTVlWRXRURkdubUg5K096ZWg1VC8K NEJZbnBka2NhTWxvRm5tWmFWcW03RldRYjYwZ2FPZlVjc3pQZFhvTlI2b0FpUzQ0NXdSOEdXUTFi VFVhd0dJMQpKa3ZqemxXWDhIZ0J3NWRqcXZvcmNieHR3TmhENmFFNXo4UjhxQmpNM3kvS0kxeUR3 ZWRpa1R4RjBYaUs3RDNBCmpCTXdyUTZHR1hTZVB5ZVJtMnR5Y25pRWRTcEtwUzQxdjhNYTVKTUtu NVlEbnQ3ZTFSSjAraHNPNjBoMXdqS0MKSWZLeVZpcDVKbWhwN0VFRkVkaVJIV3lZdHRuZzBSUU9z S1FQQkxXVXpKeXBhNFY3TUY4WC9ndXZRcGwxM1o0MwpQRnlCLzhJay9md2hQWE4wNXdHcWVPV1Vr d0FSQVFBQndzSkNCQmdCQ2dIMkJZSmhwbnVvQllrRm42WUFDUkFCClVYY3BTMGVYeUVjVUFBQUFB QUFlQUNCellXeDBRRzV2ZEdGMGFXOXVjeTV6WlhGMWIybGhMWEJuY0M1dmNtZjEKbS9Eb3RrVzlu QmRwZThtU0VGeC96a1I3Zm8xd01qZnNaV09lU0lYcHhBS2JBc0M4b0FRWkFRb0Fid1dDWWFaNwpx QWtRcVpOQmpsVTRJRlJIRkFBQUFBQUFIZ0FnYzJGc2RFQnViM1JoZEdsdmJuTXVjMlZ4ZFc5cFlT MXdaM0F1CmIzSm5CM2JJTy83a1ZSZ3ZiQ2dBSDkrZ1k1TFY1OFlmTG44cWZiVnRjV3pGdHQwV0lR Umx3OTZoZy9XUDRnZGQKVzRLcGswR09WVGdnVkFBQTg5Z0gvUlVjN2pwSUpEZEpxVVNwSmlzajZo b1VoN0JGbEhJd2VIWkRsbXJxMWtaSApReXFlS3l1K2F0SFFHK2huSlVoOHVUY09WdlRRZHg4ME5V NGpadC9qV0JPS1E3dUVRV0pQbUp4d0VJVnRwS1dvCldad1dWenlod0MyVUIvL2tvVWI0WDFqNGpm QUVSaXc3eURvYzdKZzgrQnZtUTRhN0ZQTHpaQzk0WksrYmdaZXYKVTNJNnRtL2p3N3BQbFFjWXZ2 YnJ0dGtkR0xYZE90djhwRm1sM0JhR1pxZzVrQWFXV1lOZWpvV2x3LzFpRXpXeApkZVZqKzdrWUdq UVZWYm4yTlVhcllENHVNM1N3NFl1QTk4OVV6ODhoMnI2TjZOSW51cENjVE0vVjByYUEzcnRUCnVq K2dQVEUzYUdidzBlL0ExTnEwUlZ5TXZHYnFhbGUxVG1ua3QycmE4NW9XSVFSeHBPdVR3S0tLTTAw NjZ2c0IKVVhjcFMwZVh5QUFBN05RSUFLazhLNG9meDlpaEhWQk1GT1JPMkk4S200SVJuRUtKVjZt YURpTENqY3Fpa29ZQgpkQXRkQ21KMWNKY3JETEFKbDIyS09GR2dTMGp2Nm9sVy9EdUZ0T0l5K1Vw OTRqbTZxQXpISER2SkJiZTZySXlKCkFMbllVUGg2NllaSTh1emwvbG1nYm56UURZS05oNlNMRjBz RGxKMXNpOVc1Z1krYjlKUWJ0WnRBTXZ2Y0tqTS8Kc1hVRUtDd0JVVEVja0kzeTVSeU5GbjRBV0dw eGVROWIvS3V3SHpnQ1JSRnRqbm9MSTVrSzJJUzhTb2JNU2NSOQpza3BnNFJVREVRbFhsRlg0R2FO OVJPWk9hNG1GdThMTmZjMm5ScU82SXNILy91U0VPZ3dwa3J5NEtCeDB4YUh1CmhsZXZGTVNCSGZW MDR5OGRsbmFNVEZpOHFnWlJoSmloWHFUTktlND0KPWRKdWsKLS0tLS1FTkQgUEdQIFBVQkxJQyBL RVkgQkxPQ0stLS0tLQo= ------ND0NLUATGKYKHEWIAXFNP1YGLCR39N-- From nobody Tue Nov 30 19:52:39 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 89C2C18B1E48 for ; Tue, 30 Nov 2021 19:52:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3XvF4BVHz4gG8; Tue, 30 Nov 2021 19:52:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f178.google.com with SMTP id be32so43409817oib.11; Tue, 30 Nov 2021 11:52:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aSBWkTjmQDU3kbPmWlJVGCuviv7qCNvQEv5sjo2ponc=; b=54lqcjrnQBMf6u2EE7crW/PK8w1dsO4LxtQtPwDgvRuFf+ywmqYII99cHq3hHAXA5Q biUUE3O6ISR4W/V/LB4LtQRQzch9OwAnhCypsJgIjGPcS3aRSE6wPOV8fM6Y1Vfqrs4C Tr6GyLgoPSaF3aismfjqiCPrYq+8EiYyW9ptN/ESPGwWHyrc95b5SkWnlmlCoZmYZKRR VQeJfK4o0Okxnq2KFvTiTTiHikDv2lJn3EvBD7z0cByETE7Kf6G8gEoQfxP6CQFu2HUx 68TWhEFaNiw1CK/YiVGbitDEqNxIpKuq+0mmkbAC70fYqozGdaW3HbANpv72mSMI1cDH zSqg== X-Gm-Message-State: AOAM532ZdHJ4gn7wX0+bMOvs8+yCCwNr2anjbgoH1VxdAOhA7etzH0ga +wW6hXK+5NbmIMjVf4/da4sfc5qRjP6kahy+bQc5QV6E X-Google-Smtp-Source: ABdhPJwy/WHG1j7zkt3DpV/eF7IbLnsmGGfVNYX3f1gxMXi18b2JdqQp5fVIE2oqV1DT9VqsC3dkkCaO+vsB3oGepE8= X-Received: by 2002:a05:6808:ec3:: with SMTP id q3mr1108732oiv.57.1638301970606; Tue, 30 Nov 2021 11:52:50 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> From: Alan Somers Date: Tue, 30 Nov 2021 12:52:39 -0700 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J3XvF4BVHz4gG8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.178 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.958]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.178:from]; NEURAL_SPAM_LONG(0.65)[0.650]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.178: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)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 23, 2021 at 3:41 PM Joseph Mingrone wrote: > > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) virtio-fs support for BHyve. From nobody Tue Nov 30 22:36:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AAC8418A958D for ; Tue, 30 Nov 2021 22:36:57 +0000 (UTC) (envelope-from obsto.clades@zohomail.com) Received: from sender4-pp-o92.zoho.com (sender4-pp-o92.zoho.com [136.143.188.92]) (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 4J3cXS5Rgsz4XQD for ; Tue, 30 Nov 2021 22:36:56 +0000 (UTC) (envelope-from obsto.clades@zohomail.com) ARC-Seal: i=1; a=rsa-sha256; t=1638311807; cv=none; d=zohomail.com; s=zohoarc; b=cWJcyG2D+7sJgAvowGNKOiVZNBM71WUidmBF2x9fwq9oYbLeuMHvkz4UFu98DprEMjotMNB0jbQpzXzzCrblAbX4dnXCDizVTZIc41QMg6QsvC8ctYGvEKtimz1RRWTabYisqmp0QIsCOgTmPw3x/FVrBJGn45i1Fc3npgfBXFs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638311807; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=tio2hdyjHiZBYbwJdhOpEMY7q1wXRk1e73Hvr1fzvNI=; b=kGj7CHrXhPzJZc8Rek2INJ/pMM4fH8jJWCqXu6fl2SjCvtAIGKzHVUNIdO/laQU5zHPPrPElfdnhlPhPmyczYk0wBzNphJKtDJeGgHFnZRpLNozBB5m/lEF75Nk1uKIC/xepF7Xii6CAbHnfD8w6ERCmkGZYKmTiqpWXhZjLYbQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zohomail.com; spf=pass smtp.mailfrom=obsto.clades@zohomail.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1638311807; s=zm2020; d=zohomail.com; i=obsto.clades@zohomail.com; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=tio2hdyjHiZBYbwJdhOpEMY7q1wXRk1e73Hvr1fzvNI=; b=AC9hoB33iOlkFXAjgOEIeOtSpekfxBZBH8yruSKZZzMStdtAHbtw+Ed+KDvdIblR o8O06UNHZ0NPAJBt66Gwh3IkINmy7ETPthV9qBsTAmTU0Nbjv3nlhTeTpxcg/BNDPwG y1d4QUyEUohh1hBijYHj9CYRJ9VGd8jWqq7ysavg= Received: from [10.0.0.2] (97-113-103-185.tukw.qwest.net [97.113.103.185]) by mx.zohomail.com with SMTPS id 1638311803999369.6135599492778; Tue, 30 Nov 2021 14:36:43 -0800 (PST) Subject: Re: Hello To: freebsd-hackers@FreeBSD.org References: <05580cd8-1bbf-8783-b190-40d9cdacade6@m5p.com> <20211128115920.61240092@bigus.dream-tech.com> Message-ID: Date: Tue, 30 Nov 2021 14:36:42 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20211128115920.61240092@bigus.dream-tech.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ZohoMailClient: External X-Rspamd-Queue-Id: 4J3cXS5Rgsz4XQD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zohomail.com header.s=zm2020 header.b=AC9hoB33; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=pass (policy=reject) header.from=zohomail.com; spf=pass (mx1.freebsd.org: domain of obsto.clades@zohomail.com designates 136.143.188.92 as permitted sender) smtp.mailfrom=obsto.clades@zohomail.com X-Spamd-Result: default: False [-4.67 / 15.00]; DWL_DNSWL_NONE(0.00)[zohomail.com:dkim]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; R_DKIM_ALLOW(-0.20)[zohomail.com:s=zm2020]; RWL_MAILSPIKE_POSSIBLE(0.00)[136.143.188.92:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/24]; RECEIVED_SPAMHAUS_PBL(0.00)[97.113.103.185:received]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[zohomail.com:+]; DMARC_POLICY_ALLOW(-0.50)[zohomail.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.92:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_HTML_ONLY(0.20)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/23, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] Reply-To: obsto.clades@zohomail.com From: Obsto Clades via freebsd-hackers X-Original-From: Obsto Clades X-ThisMailContainsUnwantedMimeParts: N I appreciate your kind words.  I'd appreciate it even more if you spread the word to check out my work.  The more white-hat hackers who try to hack my OS, the more confidence I will have that my modifications are as good as I hope. On 11/28/21 11:59 AM, Dave Hayes wrote: > On Sat, 27 Nov 2021 18:26:43 -0500 > George Mitchell wrote: >> On 11/27/21 17:40, Obsto Clades via freebsd-hackers wrote: >>> If you are interested in checking out my OS, you can find instructions >>> on my site's home page:  https://obstoclades.tech/ >> Hmm, my mother told me never to click on links in strange emails ... > Did your mother ever use cURL? :D > > prompt> curl -kv https://obstoclades.tech > * Trying 209.181.137.95:443... > * Connected to obstoclades.tech (209.181.137.95) port 443 (#0) > ... > * SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 > * ALPN, server accepted to use http/1.1 > * Server certificate: > * subject: CN=obstoclades.tech > * start date: Oct 16 20:04:54 2021 GMT > * expire date: Jan 14 20:04:53 2022 GMT > * issuer: C=US; O=Let's Encrypt; CN=R3 > * SSL certificate verify result: unable to get local issuer certificate (20), > continuing anyway. > > It seems there's a problem with his certificate chain, but this is not unusual. > >> GET / HTTP/1.1 >> Host: obstoclades.tech >> User-Agent: curl/7.77.0 >> Accept: */* >> > * Mark bundle as not supporting multiuse > < HTTP/1.1 200 OK > < Server: nginx/1.20.1 > < Date: Sun, 28 Nov 2021 19:50:00 GMT > < Content-Type: text/html; charset=utf-8 > < Transfer-Encoding: chunked > < Connection: keep-alive > < Cache-Control: no-cache, no-store, must-revalidate > < Pragma: no-cache > < Expires: 0 > > No obvious problem there. The only possibly questionable thing (other than > jquery, which comes from google) is this: > > > > which is this: > > /* > * File: obstoclades.js > * Copyright (c) 2017 Obsto Clades, LLC > */ > > $(document).ready(function() > { > var $content = $(".content").hide(); > $(".img").on("click", function (e) > { > $(this).parent().parent().toggleClass("expanded"); > var ttt = $(this).parent().children(".tooltiptext"); > if ($(this).parent().parent().hasClass("expanded")) > { > ttt.replaceWith("Click to > close"); } > else > { > ttt.replaceWith("Click to > open"); } > $(this).parent().parent().next().slideToggle(); > }); > var textHeight = $("#left-side-header-text").height(); > $("#old_english_sheepdog").height(textHeight).width(textHeight); > $("#button").click(function() > { > $("#contactus-form").submit(); > }) > }); > > There's nothing in that I can see that's malicious. I could be wrong. > > I looked briefly at the content. This person is trying to do good by security, > so in my book it's worth a look. If said machine is actually impervious to > sudo root, and all the compilers/interpreters work, that's likely going to > work well. Am I missing something here? -- Obsto Clades, LLC From nobody Wed Dec 1 16:42:33 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E62F718BEE93 for ; Wed, 1 Dec 2021 16:43:38 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 4J44fL5WR1z4ST1 for ; Wed, 1 Dec 2021 16:43:38 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qv1-xf29.google.com with SMTP id u16so22245892qvk.4 for ; Wed, 01 Dec 2021 08:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=7KiBve0eRtjI33uqMmo8UHxjXAdXvJ/11Z3O6QR4TCQ=; b=FLcU1aW4QirWDj9T+HNhCFe6C2P+R2p9wvSazMMLypWQ+SvYi2KMtVe7ydk/clrESS Zh1nncdO8os/lf0QnEhRY7bbQfBOs3nw8R4SbLYGNd2S4mW5Xoj6UaOWYXVfUtPo12Pv b/OesRzbel17Q/TPRru9hvRv1z1ZezgXdvjx9cVTf54/eUjMAVdfA+lXQipzxCtqqZ/Y 0HxfeQ4n5IGm4fZmzLQcO++uTO0hx2Dpy0GTXc04rZme5o2y9UPAcgp1qwIhbSdAr2aN qUYW060BKlXxvRH3+p7LXie0PSH+yV8CIWjCdVopUXIZrt7QQOnkD+EdWveTpzQ1jl4m MejA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=7KiBve0eRtjI33uqMmo8UHxjXAdXvJ/11Z3O6QR4TCQ=; b=Aj/bxc0CpV8Sr04fg9eT28kzkPh57LJBtYBJhOrWX/04k2u/Sd5d/YkqpEnqOW0a1O YWUlaBzVC8/t2XS92IiVxayCh/YN7cQKXVxMcUw7RUfW/MHWkmdJ+WmnlsZpkXrqz7RW 6wD74Uiny206UOg5K0fctDcYiRXnQpERtTGh0x5Lnf1/IbzWvir/pZXacNKgVv2G/47y o0fUvkqLtVaiB7Xn3ZgJegikWO6wx5A7BMKR9Fev9tdu45IHmBbpf9bBwnB0Cs7zMxtl Sk5WhBw1yru8anw818p5728VKK1metXsaY81DR+O7eFBRC1tMDnaLkdyrqE4fx1ZJACW kOQQ== X-Gm-Message-State: AOAM532Fxn9dmT9ZmHD31trFDMsJIkhOSZlOMBTdu+z3KsZsC3iCdiXD 9N8MihTR9PbmuCPeU6ohI6VNnsmkK54= X-Google-Smtp-Source: ABdhPJyIMXicA1bmZIjXUbtS6XNba4LLTYBFD6jlOIeQ5cohbaM/IvNOM7isvbr0al34Gb9maBOoyg== X-Received: by 2002:ad4:58cf:: with SMTP id dh15mr7497919qvb.125.1638377018482; Wed, 01 Dec 2021 08:43:38 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id m4sm131059qtu.87.2021.12.01.08.43.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Dec 2021 08:43:37 -0800 (PST) Message-ID: Date: Wed, 1 Dec 2021 10:42:33 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: Stefan Blachmann Cc: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> From: Jason Bacon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J44fL5WR1z4ST1 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 11/30/21 11:55, Stefan Blachmann wrote: > On 11/30/21, Stefan Esser wrote: >> ULE does not care for the "niceness" of a process and lets nice -19 >> processes run with hardly any reduction of the share of CPU cycles >> granted compared to competing nice 0 processes, for example. > > I can confirm this... always believed it's just me. > I'd like very much if renicing would have more, actually usable, effect. > > > On 11/30/21, Jason Bacon wrote: >> If your nVidia cards are basically landfill, like some of mine, and you >> don't care about 3D support, xf86-video-nv still works in some case that >> would otherwise call for v304. I wonder if it would be a simple matter >> to add support to it for some additional older hardware supported by >> v340. Yes, I know nv is deprecated, but this may be the only solution >> for ancient hardware. > > Actually xf86-video-nv overlaps into the range of what is supported by > nvidia-driver-304. > Practically all nvidia proprietary drivers overlap in their range of > supported cards with the "adjacent" versions. > So it is common, for example, to see the newer ones of the cards that > are supported by 390 are still supported by, for example, 470, while > the older ones still supported by 390 are supported by 340, too, but > not by 4xx. > > The bad thing now is that with nvidia having already dropped 304 and > 340 support, the next xorg ABI change will render the "middle field" > (eg not yet historic, but not yet very new either) of nvidia cards > useless on FreeBSD if there is no nouveau port. > > > On 11/30/21, Floyd, Paul wrote: >> However I'm not sure that porting nouveau will help. My experience on >> Fedora is that nouveau simply never works. > > Never used Fedora. Maybe it's because Fedora is very close to > commercial RHEL which might be not really targeted at desktop? > Personally, I never have tried Fedora, but used several other distros. > Nouveau always worked fine for me. So no idea what's the cause the > difficulties you are experiencing on Fedora. > > On practically every Linux distro Nouveau is the quasi standard driver > for any type of Nvidia cards, as the proprietary Nvidia drivers are > non-free category. > So I think one can consider Nouveau as very well-tested and reliable > and that porting it to FreeBSD would be worthwhile, profiting many > users who would else either have to buy a new graphics card or migrate > to Linux. > A Nouveau port, if it works reliably and supports all the same hardware as the closed-source drivers, would greatly simplify things for sysutils/desktop-installer. I recall reading in a distant thread that the Nouveau developers are friendly to the idea of a FreeBSD port and the barriers are only technical. So maybe this is worth some investment if we have someone with the right skills available. -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From nobody Wed Dec 1 17:01:29 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6F94818C7E5E for ; Wed, 1 Dec 2021 17:01:33 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 4J45305btFz4bDL for ; Wed, 1 Dec 2021 17:01:32 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x332.google.com with SMTP id 133so21026811wme.0 for ; Wed, 01 Dec 2021 09:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=JpLw3gb3P2gK2jLNsrFuAYUPx52DvxlscpE4xY032EY=; b=p3r9jkfUBLyh0jDErMYP1pzsYytZSc2fNsQdAFlrurnf61xPXXsZQuyzXoz0G1pPFv ITB9YbYUJEWa46Egfzo7v9dYcwvv4z1sXf27Q3tq3+N6nEhdjHbJ2SdVTJEQMGtbJE6V w8FjJDHv8fYGylYpV9PUIeOOfNtIS9e6yy58UPtBuG4wGY4egSbz/5q5LpVnicWBjc96 qGCF9GD7FBsDzwT7ve4h/cPYo4KZbzo1MH/a3ZbiN9xATri6Vsb64v7qxlIloKYRMeDH FkXW4HwLVrnncf8/FNo41VRC9f4XBfjg/TiI//l1crCM2Vl/hzbm7T2XuoLSBEsXue9v QPyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=JpLw3gb3P2gK2jLNsrFuAYUPx52DvxlscpE4xY032EY=; b=bt7VvOXUpRehMVniqUaHJ5vK0pKymjJKQucfD+GsTjl4WewzV1iGs068r8fJsOBdGC 4yQoMxMEuYZtaslutYRZllu/l5bQal7qhm7DRXx4yZqWblfK15pQ2PbRIpJP90xJmi5P cUKcTNOTDYcMytKSsNiAQfuO8BEH8sYWDiKgl7rYG+NBq0x6XnRciLaoICnoKFsra+sV x2bFX66OyCP5G8FiGSZi9l94D3p9+cNGhOfrUnSXK+tvSs14bqhgFV5lRgwPcZ4bi//y clwifMne+dlt/dUw6a3FCp5k69MyLolHGTsLpdTPH9svwjwzVSNxOTDE/fhQo6OhovNi pLMg== X-Gm-Message-State: AOAM532grIvwM5zhMQDpKcyihrtKa11Ba8EAYthuZmfsmXJ+zrp9hcyD q+biIKbt5OYoSIZ0qxhpkdOQNMFxtyktz88c X-Google-Smtp-Source: ABdhPJykgO5pqhINeVua1dzTHmjAfZBBfDsjREgZUoW3AfDyOQkeTkw83U8ldh1yzJsnDdPxmfx95Q== X-Received: by 2002:a05:600c:1f19:: with SMTP id bd25mr8396490wmb.75.1638378091133; Wed, 01 Dec 2021 09:01:31 -0800 (PST) Received: from [137.202.253.121] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id ay21sm1513877wmb.7.2021.12.01.09.01.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Dec 2021 09:01:30 -0800 (PST) Message-ID: <996c704c-9ea4-6463-1339-958aa2d3798c@gmail.com> Date: Wed, 1 Dec 2021 18:01:29 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> From: "Floyd, Paul" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J45305btFz4bDL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=p3r9jkfU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::332 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-3.74 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.75)[-0.748]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::332:from]; NEURAL_HAM_SHORT(-0.99)[-0.992]; 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]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2021-11-30 18:55, Stefan Blachmann wrote: > On practically every Linux distro Nouveau is the quasi standard driver > for any type of Nvidia cards, as the proprietary Nvidia drivers are > non-free category. > So I think one can consider Nouveau as very well-tested and reliable > and that porting it to FreeBSD would be worthwhile, profiting many > users who would else either have to buy a new graphics card or migrate > to Linux. When I first installed Fedora, it defaulted to nouveau = black screen. So I switched to non-free nvidia. This breaks on a fairly regular basis due to incompatible kernel changes. DKMS will try to rebuild the kernel module, which fails = black screen. I retried nouveau again a couple of times, still always a black screen. That gave me the impression that nouveau is unmaintained. Sounds like I was wrong there. You kind of get used to it, hitting alt-f2 for a console login and waiting a few days or weeks for non-free nvidia to catch up. By comparison I've had almost no problems with the nvidia drivers on FreeBSD. A+ Paul From nobody Wed Dec 1 19:31:15 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0AEBA18C4036 for ; Wed, 1 Dec 2021 19:31:19 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4J48Mp1lc2z3tcV for ; Wed, 1 Dec 2021 19:31:18 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id j3so54674190wrp.1 for ; Wed, 01 Dec 2021 11:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=y+qCnY3vGdqm0AYotfIgBU8OU6yCSB1QJpHtf0DdhyY=; b=BJ7bMBzpiQ7k/22TJpFH8oikvid1boIe+TK5NUyF946k2FPc4MvTN8vL/0Z4Tswdys oOjZnGgP+FmjTz+/tITeBY5GvpTnPHqNoicyn0V00yYO1TrBcYsorWhpymMLCMdvD/Rm WaDMftC8P0Y3PMcXi+U0Q/tIT9ZlRIyM+NIfvvs9+KaFYCpj/hN2g97awA0S1ygh/UIZ FeQP7Va55ySjSoXlURbTaKOnpyRl3d8o3NJZonr7nWuL2XU3/Ywtvr2M5FFxfH59Cgd/ nqMGmzRjd5RW+LKU67ZkXBis43OpVKzazKz1nAsKBf73J0tkN41jFu/FNbvXQ36ujrp6 HKag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=y+qCnY3vGdqm0AYotfIgBU8OU6yCSB1QJpHtf0DdhyY=; b=GCjrZ/tG5QW+QSiHDtSvSh9Fr+8zv6lfx4QxVIRYSjvriPurH1Xn11djpuaDZ0enEc 9pyDQaE7vIaaDhwjKwIZyTYmt5Q1IeL9Hoq20xgmua9Nmjf2/Scpvz7fOk+/D7/dIQBk 6lHIidSjspCFpwDTUCobfjoO+LA8QS+BctFvfC3NNbuGELzHAudXfflUI/5KU0DPktTW Ni7C1ahHBJOBe34zitxoo2TaaTff3t8yrKbvnElENPYgR3NkBoOXnUIdsytrkZtAiMPH 5ocsV3cakpbhP4dIQEfo932GcxI0FyIZwW794y7OuF2Lrvop+p7ws4vaKOEbuTaUeJdU mM3Q== X-Gm-Message-State: AOAM532kSG0zZg82XqTZNQ2A/rss5AoPkWSzsZI6KyG0Nx7IU8KvBkqd TCJJ0nRPnnyHxjXx9ZxhzAwplkHnaxwcUk67 X-Google-Smtp-Source: ABdhPJzPnqowEPicP7JPny9tS/F9EWX3PQ5Qtc2U+zTMr0gTdU5xj+GRbb/Rpi+fcphLnumN54Y4VA== X-Received: by 2002:adf:fb05:: with SMTP id c5mr8881797wrr.497.1638387076939; Wed, 01 Dec 2021 11:31:16 -0800 (PST) Received: from [192.168.1.24] (lfbn-lyo-1-397-34.w2-7.abo.wanadoo.fr. [2.7.224.34]) by smtp.gmail.com with ESMTPSA id ay21sm202404wmb.7.2021.12.01.11.31.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Dec 2021 11:31:16 -0800 (PST) Content-Type: multipart/alternative; boundary="------------k0pmxgJrT7g8bQ2MpRcCpLpy" Message-ID: <0bba0856-b3ba-27dd-40ca-9707aec7f033@gmail.com> Date: Wed, 1 Dec 2021 20:31:15 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> <9b14c3fc-67dc-b07c-6e2c-d3d9ada38abd@FreeBSD.org> From: Paul Floyd In-Reply-To: <9b14c3fc-67dc-b07c-6e2c-d3d9ada38abd@FreeBSD.org> X-Rspamd-Queue-Id: 4J48Mp1lc2z3tcV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BJ7bMBzp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-0.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; 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]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.224.34:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.65)[0.655]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[0.996]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --------------k0pmxgJrT7g8bQ2MpRcCpLpy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/30/21 18:15, Andriy Gapon wrote: > Just as a data point, nvidia-driver-470.86 seems to work well for my > GT 730: > > nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX > platforms 470.86  Tue Oct 26 21:43:42 UTC 2021 > nvidia0: on vgapci0  I managed to get the 390 drivers working (with nvidia-modeset) but the 470 driver gives me [   103.404] (WW) NVIDIA(0): The NVIDIA GeForce GT 730 GPU installed in this system is [   103.404] (WW) NVIDIA(0):     supported through the NVIDIA 390.xx Legacy drivers. Please [   103.404] (WW) NVIDIA(0):     visit http://www.nvidia.com/object/unix.html for more [   103.404] (WW) NVIDIA(0):     information.  The 470.74 NVIDIA driver will ignore this [   103.404] (WW) NVIDIA(0):     GPU.  Continuing probe... [   103.404] (EE) No devices detected. [   103.404] (EE) Fatal server error: [   103.404] (EE) no screens found(EE) A+ Paul --------------k0pmxgJrT7g8bQ2MpRcCpLpy-- From nobody Wed Dec 1 21:43:29 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ABF9318B043A for ; Wed, 1 Dec 2021 21:43:33 +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 4J4CJP0V6gz3M70; Wed, 1 Dec 2021 21:43:33 +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 8D0922497A; Wed, 1 Dec 2021 21:43:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Wed, 1 Dec 2021 23:43:29 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.3.0 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: Paul Floyd , freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> <9b14c3fc-67dc-b07c-6e2c-d3d9ada38abd@FreeBSD.org> <0bba0856-b3ba-27dd-40ca-9707aec7f033@gmail.com> From: Andriy Gapon In-Reply-To: <0bba0856-b3ba-27dd-40ca-9707aec7f033@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638395013; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HCLTE9Npgf4vk+pBr+ES480hVDNdKUQbHQKqaQKTVV0=; b=gj5GHgNb/4e2iEoCUn6WgySxGNQyLEKRzf2UE+VzIcvE1s7ysUYw2deSa39XV62ZnZYQUw CF7XGIEnyoDv7u7sO6c7zkvcpOpIHwvgOxQ/UCb0fund4SEPmPs3kp2ygmcuIPzKZ4mt5X 6tTMlCcZdRCasQCQsPm3QNNzeugHDoiE9IZ7fmcRnwYS2qg54N7Eul1a1SvQKKNRrcO2sD QefwEFgqINsC/IjNnGpiUds79bhQz6ToOJuQj7Ho24x2rTJqb6bFn25e5q628FSD+hdI82 /hPaJXdZLKZ0AnxJv9O5Shm+o118Bn4P98HTaM9BGZEyxtLT3KbHVTgGR771DA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638395013; a=rsa-sha256; cv=none; b=oqBZVVvMwYm+oBiPXyMYPngzZrm1PhKtWgSGKw6bKsSRTucylKbbqODKYH9BXAYWUMa5aZ ntvF6e1I4HoYGfUMh2H+EqfSg0K5V24RrmczprQwOrZuOJipJvftDgVi/PFXUY+DF4asku GF8vNUcxIIKlWegW2AM1WeyHCMQtEtDw5yGqlkSmdSMyrg2wK+zLuES+E2iZFOHsRDH2CD Pt9KFGDfGw5gYgckBOmz4auriWApOJuD9V5BBktSF9YB72tdmzjVx2MDwTEdAUIZeJLRFn IpxSZmX73LhsnMWf98gtUKVI2YGDWB84ZpnZ8IuUgRcBqPBgNsGVJ649fnfq0Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 01/12/2021 21:31, Paul Floyd wrote: > On 11/30/21 18:15, Andriy Gapon wrote: >> Just as a data point, nvidia-driver-470.86 seems to work well for my GT 730: >> >> nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms >> 470.86  Tue Oct 26 21:43:42 UTC 2021 >> nvidia0: on vgapci0 > >  I managed to get the 390 drivers working (with nvidia-modeset) but the 470 > driver gives me > > [   103.404] (WW) NVIDIA(0): The NVIDIA GeForce GT 730 GPU installed in this > system is > [   103.404] (WW) NVIDIA(0):     supported through the NVIDIA 390.xx Legacy > drivers. Please > [   103.404] (WW) NVIDIA(0):     visit http://www.nvidia.com/object/unix.html > for more > [   103.404] (WW) NVIDIA(0):     information.  The 470.74 NVIDIA driver will > ignore this > [   103.404] (WW) NVIDIA(0):     GPU.  Continuing probe... > [   103.404] (EE) No devices detected. > [   103.404] (EE) > Fatal server error: > [   103.404] (EE) no screens found(EE) Apparently not all GT 730 cards are made equal. I bet yours has PCI device ID of 0x0F02 (GF108): https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/ Mine has device=0x1287 (GK208). -- Andriy Gapon From nobody Wed Dec 1 21:55:43 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A24D18B80DE for ; Wed, 1 Dec 2021 21:56:50 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 4J4Cbj6QGlz3jbG for ; Wed, 1 Dec 2021 21:56:49 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qv1-xf2a.google.com with SMTP id gu12so23103971qvb.6 for ; Wed, 01 Dec 2021 13:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=PBrCXonyPzG6F+4TaLGxC4faYDt45mKtKqB5CZWV1sE=; b=ZLEzLP0L176fSjBr9F7LibIAYsImedfzbrr5+mc+NUQai/WnPJYpjb4jIAdTFFBznO Z0lL86ZttSPm6tvJ490vy+2ikm+OsAg93dr85eLO/5PIw9eaxg1LSo8Mr6z2ynYl7zxV JkSCS8xy4No94/XVgHyCOYFXK+xV9iZG2kaLz+9bnJ3NzInR0WrLVhg3b98dqhgDBVYw Opn2CHZVt8wInypI2JSXGBfFncBfJFpxz832/ZpqnT/4mC4TQYPsVGx82zDQ7zmlCv5f p9foCA0uW0RNQRTSzSTH8PfKO+vh6rU6JhLe0KOuZMlpiwiFwqcK8w05wkvsEaeq+J5c VHkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=PBrCXonyPzG6F+4TaLGxC4faYDt45mKtKqB5CZWV1sE=; b=DNm+qqcVsAiTFIR5sF+tYSrhO9zIc4mfSmDhtE9QEP8UXkpz4rb1mnOWbX35A84Z4H RiiWfFkxyo1wf/7C+kVaEPS3r4lDvUxWXnoEVyiB0Kl700lnF3bwQPADbe5ve5msdzWh Nc3Tx3nV3HnHVlK7X1A23BqvjieaXd5IhJCpfs7CcnUJc4F+bf2Hrqv6X0YBzpP3TY92 Uo7r8ggVCbvszCA30quvqn/eQSGlLwX60Y/kE/bEgLzbL1PQ53PaREunuHeixJ+xDEh4 2rtM7WDWXg3UW6OGOUawqg83L845YwZgJFwjlfFEceJnwKgRm4gMJAf7p8XOqKKsTpae UCgw== X-Gm-Message-State: AOAM533aJQVmk2NtjWpdFXqhnsTx3H+BiRW1XGYPZ8OZpseJYKnRpewe LZrjvLFKXOm47z1JmItyFbvU5TPnf3E= X-Google-Smtp-Source: ABdhPJxvDkWuyNG4MaXd1c/TKwbI67s1bOwD5bzPCEisJiV7PP9A3pyUcF87NWlhwPU9lET3LJZ14Q== X-Received: by 2002:ad4:54ca:: with SMTP id j10mr9690519qvx.2.1638395809287; Wed, 01 Dec 2021 13:56:49 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id u27sm575596qtc.58.2021.12.01.13.56.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Dec 2021 13:56:48 -0800 (PST) Message-ID: <0454ed16-8835-4577-2eeb-479be3756cb0@gmail.com> Date: Wed, 1 Dec 2021 15:55:43 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <371b758c-1efa-b5df-6437-ce4f06369383@gmail.com> <23c3e735-22b5-7528-e311-d75657c33a69@gmail.com> <996c704c-9ea4-6463-1339-958aa2d3798c@gmail.com> From: Jason Bacon In-Reply-To: <996c704c-9ea4-6463-1339-958aa2d3798c@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J4Cbj6QGlz3jbG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZLEzLP0L; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::f2a as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2a:from]; 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:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 12/1/21 11:01, Floyd, Paul wrote: > On 2021-11-30 18:55, Stefan Blachmann wrote: >> On practically every Linux distro Nouveau is the quasi standard driver >> for any type of Nvidia cards, as the proprietary Nvidia drivers are >> non-free category. >> So I think one can consider Nouveau as very well-tested and reliable >> and that porting it to FreeBSD would be worthwhile, profiting many >> users who would else either have to buy a new graphics card or migrate >> to Linux. > > When I first installed Fedora, it defaulted to nouveau = black screen. > > So I switched to non-free nvidia. This breaks on a fairly regular basis > due to incompatible kernel changes. DKMS will try to rebuild the kernel > module, which fails = black screen. I retried nouveau again a couple of > times, still always a black screen. That gave me the impression that > nouveau is unmaintained. Sounds like I was wrong there. > > You kind of get used to it, hitting alt-f2 for a console login and > waiting a few days or weeks for non-free nvidia to catch up. > > By comparison I've had almost no problems with the nvidia drivers on > FreeBSD. > > A+ > > Paul I have only one anecdote from CentOS, where the closed-source nVidia drivers caused breakage during routine Yum updates. I switched the machine to nouveau and everything was fine from then on. I've also seen the closed-source drivers cause an occasional panic on FreeBSD. Seems less of a problem recently than many years ago. -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From nobody Thu Dec 2 00:38:55 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9667818BEEE0 for ; Thu, 2 Dec 2021 00:39:29 +0000 (UTC) (envelope-from jo@bruelltuete.com) Received: from email.jo-t.de (seppel.jo-t.de [45.132.244.126]) (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 4J4HCN4G5wz3Qkj for ; Thu, 2 Dec 2021 00:39:28 +0000 (UTC) (envelope-from jo@bruelltuete.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bruelltuete.com; s=bruelltuete18a; t=1638405568; bh=voGi7DQMApNQnF+hxzu6abQvQEDQSy9gW6DAr8noeDs=; h=Message-ID:Date:MIME-Version:From:Subject:To:References:From; b=JAgkaQBYSQ50NWzLbYoM3UbwBGYmCMiKJRWJRpJNyqv7BvKIMiyE18ioRUAIgU4Qp XaDjgLacWGOSIHHs7SUamv7UfE3UWeLUfrqBPgtKeXPyHhLQUaHgt4MLV55l5FjJic LE/peEoizDi+zgaWPYBQHoywtHvhyQfFgYGukfogQOvQ35CvLg+9CNj+73cbjMr9sx Ax392GAirdYyymBG1lLmXqUequT9WN5gtNehaBgDUfhFX94R8w2uHotR9ONLcdxmY+ B8rH90MYIuxNAOof6fQP+j6OtLOX5BVPaNVX8LsNSTQy9cLeKuqYlXqchX+MDiAwQK 7ArQ64i9inGiA== Message-ID: <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> Date: Thu, 2 Dec 2021 00:38:55 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Johannes Totz Subject: Re: Call for Foundation-supported Project Ideas To: freebsd-hackers@FreeBSD.org References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J4HCN4G5wz3Qkj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bruelltuete.com header.s=bruelltuete18a header.b=JAgkaQBY; dmarc=pass (policy=none) header.from=bruelltuete.com; spf=pass (mx1.freebsd.org: domain of jo@bruelltuete.com designates 45.132.244.126 as permitted sender) smtp.mailfrom=jo@bruelltuete.com X-Spamd-Result: default: False [-3.86 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.891]; R_DKIM_ALLOW(-0.20)[bruelltuete.com:s=bruelltuete18a]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.974]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bruelltuete.com:+]; DMARC_POLICY_ALLOW(-0.50)[bruelltuete.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:197540, ipnet:45.132.244.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 29/11/2021 03:17, Ed Maste wrote: > On Sun, 28 Nov 2021 at 19:37, Steve Kargl > wrote: >> >> It's certainly not the latest and greatest, >> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz K8-class CPU) > > If you're content to use a compiler from a package you can save a lot > of time by building with `CROSS_TOOLCHAIN=llvm13` and > `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps > `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. (re-send to list, sorry) Can we disconnect the compiler optimisation flag for base and clang? I don't need the compiler to be build with -O2 but I want the resulting base system to have optimisations enabled. Right now, looks like both get -O2 and a lot of time is spent on optimising the compiler (for no good reason). From nobody Thu Dec 2 16:54:04 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 36A8A18C255A for ; Thu, 2 Dec 2021 16:54:08 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 4J4hr00lbBz4hQb for ; Thu, 2 Dec 2021 16:54:08 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x136.google.com with SMTP id bi37so10379lfb.5 for ; Thu, 02 Dec 2021 08:54:08 -0800 (PST) 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=UEbdmLQQsajT8voS0a3Lu7AQbkgKn0EkywGszB0XjKY=; b=NemWIwVzTQ2PP+Zsy5RzRCr5CDyHqqtP9g4xHL9rYLLnqO2nPusYG6M+Qng0RF5iyh HVuUJ8+NAzhGQ+WZDdpkxy16OQlZyfZSAYpdksxO21f9bk2bWEdO4jehY/WOXUOo1fyf plLhx1QWItC2PAdB13IF3JruQfwpPc4RAXy2zw3i1O3kTBR2zEJCp1pWmFpbSKQyuLSK 8cT5ESK3MMc2KpUm+64ocAqB+yitLdHn3XX7mRv+4LCLYshi2S35+eG5mzWaZ8pn4Xgr mmD3XPYyMk4ZBY/r1CJAToL36MltZpbxm8Blvb4rB1GjA32j9tendM/UphQS0WHeKkNB nPLQ== 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=UEbdmLQQsajT8voS0a3Lu7AQbkgKn0EkywGszB0XjKY=; b=SuXyqldURXyBX2Db5UB/1iTE2OGqsK/nc6Z/gQeRKY7C8+pY3ctexVtLPcXcvJXIcX 6HXNiH+06WkqwLyDF+WY6ZMqwnkzeMlUqSDNTdkWi5dyHp2K+0u8EfDAVrZbxxI5R98U L6Pv7gOztHDpIOIjBYqOuo4c1dg5K8IkzFS+uiHhxb7ZV4bVfKpS9leviXLw/RDRiLyx ZNrAIcp0Jut51C7aUKOAh0i+Iu+yvysXtKelpfHNYsuexepN3MRB1J6fax9VVVq5rPDm 5yD9r26gCvATaI5UvNnH0JQ19SqpOAinHW2nYavN4L41VajC/ZgYaHC6LjqPCnwM23lR RvQQ== X-Gm-Message-State: AOAM5316iQq/l8zhkanY0lP15zQHvylEWuJwYz96CPUSiIB3NSQNkE9Y T7v23MTJ63dXhCKBU2Bdlgj2G0WqJn2gtyNA5KcDR6uM X-Google-Smtp-Source: ABdhPJyWFpfqtMSYlmOmucXk88vwZKqtprVBcc1+1GrHRc+fk7Y+j+YehugOWz3/rPBIB80FQ0LJM3sPD+tZxXuiqb0= X-Received: by 2002:a05:6512:e89:: with SMTP id bi9mr13175226lfb.465.1638464046073; Thu, 02 Dec 2021 08:54:06 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Thu, 2 Dec 2021 08:54:04 -0800 (PST) In-Reply-To: <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> From: Stefan Blachmann Date: Thu, 2 Dec 2021 17:54:04 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Johannes Totz Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J4hr00lbBz4hQb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Regarding the suggestions to either improve or replace the ULE scheduler, I would like to share another observation. Usually when I need to zero out HDDs using dd, I use a live Linux. This time I did that on FreeBSD (13). My observations: - On the same hardware, the data transfer rate is a small fraction (about 1/4th) of which is achieved by Linux. - The first dd process, which erases the first HDD, gets almost all CPU and I/O time. The second process which does the second HDD is getting starved. It actually really starts only after the first one finished. To me it was *very* surprising to find out that, while erasing two similar HDDs concurrently takes about one day on Linux, on FreeBSD, the first HDD was finished after three days, and only after that the remaining second dd process got the same CPU time, making it proceed fast instead of creepingly slowly. So I guess this might be a scheduler issue. I certainly will do some tests using the old scheduler when I got time. And, I ask myself: Could it be a good idea to sponsor porting the Dragonfly scheduler to FreeBSD? On 12/2/21, Johannes Totz wrote: > On 29/11/2021 03:17, Ed Maste wrote: >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl >> wrote: >>> >>> It's certainly not the latest and greatest, >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz >>> K8-class CPU) >> >> If you're content to use a compiler from a package you can save a lot >> of time by building with `CROSS_TOOLCHAIN=llvm13` and >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. > > (re-send to list, sorry) > Can we disconnect the compiler optimisation flag for base and clang? I > don't need the compiler to be build with -O2 but I want the resulting > base system to have optimisations enabled. > Right now, looks like both get -O2 and a lot of time is spent on > optimising the compiler (for no good reason). > > From nobody Thu Dec 2 17:00:24 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B994018C5F0A for ; Thu, 2 Dec 2021 17:00:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 4J4hzZ4T5Qz4l0B for ; Thu, 2 Dec 2021 17:00:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f53.google.com with SMTP id n17-20020a9d64d1000000b00579cf677301so449802otl.8 for ; Thu, 02 Dec 2021 09:00:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5/pwxfAyBbux1GDvybbxEZ8rMKtcQ3PoTU9qkLHAySA=; b=e3k0HbD4ANjYH/fvOC8iJaTVXCfrTE/q0yoFQwOeCMbVy2N8iCM4zgnR50JJlzoBkB NiizVVZcLrD/bxuBOvJ48mBpDqv2m9/hxmncPe4BN/PeiuYh57H+JH+7WL3rXkxMkPjF K06mhjRPtJKFO84rJBx+NjwVlwRlgPWb2UiWWPDjHyrxSJdnjL9eFHjPB+EVTwgrs1yG z6PgLNNeU/KOJ6xPrmD5I6sisqFC69zG1G8E+E7Jhj0TltZPizF3anzdOH3C5+oimhl3 RYJQ20U4/eeraCNuWvuvBmNMXE0oJ6lJj12A4q3rDXEHz/A2ZNXxf2JnWYMKlVui9893 A9ZA== X-Gm-Message-State: AOAM532/AfIdAL5AoowehLuvyWCpbSuRchnN73Jp+8mp3qUkXlWmLEji DAWlzY4moPgGEGZOw+fjSBy7o88cUYI7sO7rOAOBpWoF X-Google-Smtp-Source: ABdhPJwm8GQTMbzbFFJIBJ3I1YHgllXdgUG7fPJI4Oi7FQBp8Sdogi4iZRPfSWG9h6dRN5745uZ9B8NWv1Pg66MjPE4= X-Received: by 2002:a9d:7cce:: with SMTP id r14mr12011665otn.114.1638464435834; Thu, 02 Dec 2021 09:00:35 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> In-Reply-To: From: Alan Somers Date: Thu, 2 Dec 2021 10:00:24 -0700 Message-ID: Subject: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Stefan Blachmann Cc: Johannes Totz , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J4hzZ4T5Qz4l0B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is very surprising to me. I never see dd take significant CPU consumption until the speed gets up into the GB/s range. What are you using for the bs= option? If you set that too low, or use the default, it will needlessly consume extra CPU and IOPs. I usually set it to 1m for this kind of usage. And what kind of HDDs are these, connected to what kind of controller? On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann wrote: > > Regarding the suggestions to either improve or replace the ULE > scheduler, I would like to share another observation. > > Usually when I need to zero out HDDs using dd, I use a live Linux. > This time I did that on FreeBSD (13). > My observations: > - On the same hardware, the data transfer rate is a small fraction > (about 1/4th) of which is achieved by Linux. > - The first dd process, which erases the first HDD, gets almost all > CPU and I/O time. The second process which does the second HDD is > getting starved. It actually really starts only after the first one > finished. > > To me it was *very* surprising to find out that, while erasing two > similar HDDs concurrently takes about one day on Linux, on FreeBSD, > the first HDD was finished after three days, and only after that the > remaining second dd process got the same CPU time, making it proceed > fast instead of creepingly slowly. > > So I guess this might be a scheduler issue. > I certainly will do some tests using the old scheduler when I got time. > And, I ask myself: > Could it be a good idea to sponsor porting the Dragonfly scheduler to FreeBSD? > > On 12/2/21, Johannes Totz wrote: > > On 29/11/2021 03:17, Ed Maste wrote: > >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl > >> wrote: > >>> > >>> It's certainly not the latest and greatest, > >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz > >>> K8-class CPU) > >> > >> If you're content to use a compiler from a package you can save a lot > >> of time by building with `CROSS_TOOLCHAIN=llvm13` and > >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps > >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. > > > > (re-send to list, sorry) > > Can we disconnect the compiler optimisation flag for base and clang? I > > don't need the compiler to be build with -O2 but I want the resulting > > base system to have optimisations enabled. > > Right now, looks like both get -O2 and a lot of time is spent on > > optimising the compiler (for no good reason). > > > > > From nobody Thu Dec 2 17:02:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D3AA918C726E for ; Thu, 2 Dec 2021 17:02:19 +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 4J4j1R3pxLz4mMj; Thu, 2 Dec 2021 17:02:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id E38EC2E535; Thu, 2 Dec 2021 17:02:18 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Thu, 2 Dec 2021 09:02:17 -0800 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: "Bjoern A. Zeeb" , Ed Maste Cc: FreeBSD Hackers References: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> From: John Baldwin Subject: Re: Retiring WITHOUT_CXX In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638464539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f+uboWmUsWwQHo7mNh4W6ff2IbiiPyYcPsS4xsSqKcE=; b=isg2+yhSdtjP9EtSju4Dy6DR8Y7duxBX8fScdmIgn0XBbiS0JEqO9sJMnBQ9+S1MjzOu59 glillY2F05DypR4XEN9Z32fDW9/5BrI5nCJgd/kET6W3MyAvXhdXqjAZ0MWLGaRZ8ZNmbo W4Hs8ZPL2x7zeRfxX7J7onVkixlpcUl/CuSeFWFGSZn6yjVS35kxY5OPyzsYb5dVcETSnj U9EHbqcjq8g+rjqgZpDOnWbaODYGM/PYlGjBHwwR6sLIdP7lr73ExVt3F3dFlWOUcn+FPm sK1uGlWE0rvTX4DMzmhFQIPefbsVkVKHXO78ZRRc09RWaWbc3Lr4mtWt+DQXzQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638464539; a=rsa-sha256; cv=none; b=tgyeAnffgQLR/ZFL/huo+VXuiuepv/UwdFOiYOvCwvLPpdY8JAzl0WKd1JwBvekMkR1AMZ tQASZ7flc3a7ZFeKtQDMnT8AEFMW3aTzi/5IWt0jwwlJP2ECOXZ1e7tq5ZOh8QaKgqi3P2 hmQZK3UCWl5Jz/VinjV/aKPLxi85atoOQczIxrwb1b5JF4sQ+K/iooFwBKzpSDqBSjCPZB kpPtmLeoyUaVmAfHKnDVkPCSVrOqOyF+Dmz4fVfXn2AOEUUMKPCkPBqnXYT3Zu2gJ/GgSX IiNL9dNske8nEO4zW63g43C+FjVWm+yHjoPSO5FH5QjH5jV44pvrv7ciAD0A/A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/26/21 11:06 AM, Bjoern A. Zeeb wrote: > On Fri, 26 Nov 2021, Ed Maste wrote: > >> On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes >> wrote: >>> >>> So is the feature model of FreeBSD becoming, oh it gets broken >>> cause it is not regularly tested, so lets remove that feature. >> >> I don't agree with that. We have a large and growing CI infrastructure >> to regularly test functionality and are continually adding to it over >> time. But it's important to test and maintain what is actually used >> and is useful. Disabling C++ support made sense when obrien@ added the >> original knob in 2000, but it makes less sense today when parts of >> FreeBSD are written in C++. > > I used to disable it in my images but started to need devd and that is > really the only reason its there currently > > #WITHOUT_CXX= # devd needs it > > I used to have a conversation with Warner a while ago about it and the > conclusion was the bits of C++ could be reimplemented in C if needed > but obviously no one ever got to that. I honestly think that's the wrong direction. I'm currently hacking on a libiscsi for shared bits of iscsid and ctld and right now it has some home-grown containers (struct keys) that would be much better as a std::vector<> of a struct with two strings. It would also benefit from having an actual class for the instead of the typical C inheritance I've added. Similarly, I've wanted to use std::unordered_map in truss to handle the syscall counts since hash tables in C require a lot of boilerplate code. This is no longer 1985, or even 2003. I'm not ready to write a kernel in C++ with templates, but I think for userspace utilities you can buy a fair bit of robustness with RAII, unique_ptr, etc. and we shouldn't be crippling ourselves. Also, have you looked at what WITHOUT_CXX actually removes? c++ is just a hard link to clang. That's the big space eater, not libc++.so.1 or libcxxrt.so.1. For reference, on my 13.x desktop, libc.so.7 is about 3 times the size of libc++.so.1: -r--r--r-- 1 root wheel 1986208 Aug 19 15:28 /lib/libc.so.7 -r--r--r-- 1 root wheel 112200 Aug 19 15:29 /lib/libcxxrt.so.1 -r--r--r-- 1 root wheel 846200 Aug 19 15:29 /usr/lib/libc++.so.1 -- John Baldwin From nobody Thu Dec 2 17:37:44 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CDF6518AF919 for ; Thu, 2 Dec 2021 17:37:46 +0000 (UTC) (envelope-from sblachmann@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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4jpL4nqYz3CKr; Thu, 2 Dec 2021 17:37:46 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x135.google.com with SMTP id m27so204645lfj.12; Thu, 02 Dec 2021 09:37:46 -0800 (PST) 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=zH1BBaJZWgyMWgZaKEDJkDIhdVRXZAF+ZkqKNkSgh4Q=; b=Uk0hYPtfzc6XxuRi5Fwzf+5FiQTku1G2enoPt1QwtDxk1fMq3hBkH46bhVsV6s6bqM obPoGerdCQwSftGRjZHNVmAg8wW0odFF/ttWlfKE8FW7DaU+qFUCynphAP8Ez26/4Si9 CDKqoODZ0K8C11MJ/2XC9e9moY6ewd7N1iov3Fp3WKyiULP89zrHgubS9Sr5IpKfR6eD UmuhVV0JNz43RlpwvARu4sWWeCI7Jnk4OMoOAB8AKr4bWckwqUm9AQFZk3GygfkoPBCS E2t9qaGFs6m4ZeYTZMPpSS081kpfqSiQY+XkUCaU+p2AzdfGklkLckEObynbhmd33tDZ dNlw== 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=zH1BBaJZWgyMWgZaKEDJkDIhdVRXZAF+ZkqKNkSgh4Q=; b=c2H+ctviD8XCdHY823vgR1FH3uGcsPWRa50va6IED6QJUfIT5dvqWzwB2dlEr1BJ1f 1KlO546BT5APM0DdkhD8eevAEQqOqY+dGucRMgUzmt7XZ7mws2gMYCl6nqFbsVZ2Yojv /gQqjBGGDYO7fIH0E0OGGJUzk27eH9HJKlJTHFEVjh55YqFMz9vmwRPOvi5ZxDyS9exv cfE+0m1SWn2U4fPvaO/6BnXRpcWhA+5ac5G6SaZYQSHrRR19h/HhYBNuo6nrDvjh+Uke FTuSsUirTqgqY98x1eHraTe3KkF2fB1W89tSaQQItjYVpIHIH4e/jT48BQkre5ToOcwx 8vHw== X-Gm-Message-State: AOAM533pNoGSTqanHfH04BB7lAcS/o7aSqev8oqLhIBnmZYuRvKq76/w 6akv3vDWyiNuR4AHb2LT3T0i2B08lVYxAnytoe1yaGg8 X-Google-Smtp-Source: ABdhPJwUP1PDn8r7Xd++elvuO4Nd8zrrd7vnoM+S4RHYuhah+iU2KurMzOB+PPILybM5ZkZqQ1HlCkXD8yypz/hP2t0= X-Received: by 2002:a19:6717:: with SMTP id b23mr13192207lfc.659.1638466665359; Thu, 02 Dec 2021 09:37:45 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Thu, 2 Dec 2021 09:37:44 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> From: Stefan Blachmann Date: Thu, 2 Dec 2021 18:37:44 +0100 Message-ID: Subject: Re: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Alan Somers Cc: Johannes Totz , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J4jpL4nqYz3CKr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N I intentionally used dd without the bs parameter, as I do care less about "maximum speed" than clearing the drives completely and also do a lot of I/O transactions. The latter because drives that are becoming unreliable tend to occasionally throw errors, and the more I/O transactions one does the better the chance is to spot this kind of drives. The system is a HP Z420, the mainboard/chipset/controller specs can be found in the web. The drives in question here (quite old) 2TB WD Black enterprise grade 3.5" SATA drives. Their SMART data is good, not hinting at any problems. On Linux, erasing them both concurrently finished at almost the same time. Thus I do not really understand why on FreeBSD this is so much different. On 12/2/21, Alan Somers wrote: > This is very surprising to me. I never see dd take significant CPU > consumption until the speed gets up into the GB/s range. What are you > using for the bs= option? If you set that too low, or use the > default, it will needlessly consume extra CPU and IOPs. I usually set > it to 1m for this kind of usage. And what kind of HDDs are these, > connected to what kind of controller? > > On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann > wrote: >> >> Regarding the suggestions to either improve or replace the ULE >> scheduler, I would like to share another observation. >> >> Usually when I need to zero out HDDs using dd, I use a live Linux. >> This time I did that on FreeBSD (13). >> My observations: >> - On the same hardware, the data transfer rate is a small fraction >> (about 1/4th) of which is achieved by Linux. >> - The first dd process, which erases the first HDD, gets almost all >> CPU and I/O time. The second process which does the second HDD is >> getting starved. It actually really starts only after the first one >> finished. >> >> To me it was *very* surprising to find out that, while erasing two >> similar HDDs concurrently takes about one day on Linux, on FreeBSD, >> the first HDD was finished after three days, and only after that the >> remaining second dd process got the same CPU time, making it proceed >> fast instead of creepingly slowly. >> >> So I guess this might be a scheduler issue. >> I certainly will do some tests using the old scheduler when I got time. >> And, I ask myself: >> Could it be a good idea to sponsor porting the Dragonfly scheduler to >> FreeBSD? >> >> On 12/2/21, Johannes Totz wrote: >> > On 29/11/2021 03:17, Ed Maste wrote: >> >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl >> >> wrote: >> >>> >> >>> It's certainly not the latest and greatest, >> >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz >> >>> K8-class CPU) >> >> >> >> If you're content to use a compiler from a package you can save a lot >> >> of time by building with `CROSS_TOOLCHAIN=llvm13` and >> >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps >> >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. >> > >> > (re-send to list, sorry) >> > Can we disconnect the compiler optimisation flag for base and clang? I >> > don't need the compiler to be build with -O2 but I want the resulting >> > base system to have optimisations enabled. >> > Right now, looks like both get -O2 and a lot of time is spent on >> > optimising the compiler (for no good reason). >> > >> > >> > From nobody Thu Dec 2 17:51:11 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 77AFF18B62E5 for ; Thu, 2 Dec 2021 17:51:23 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (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 4J4k632LHPz3HBH; Thu, 2 Dec 2021 17:51:23 +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 01DCA8D4A129; Thu, 2 Dec 2021 17:51:15 +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 C7FF7E707CB; Thu, 2 Dec 2021 17:51:14 +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 aGDW7M1uLy20; Thu, 2 Dec 2021 17:51:12 +0000 (UTC) Received: from [169.254.1.48] (unknown [IPv6:fde9:577b:c1a9:4902:b8b8:a5eb:4883:c3fc]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 65324E707BF; Thu, 2 Dec 2021 17:51:12 +0000 (UTC) From: "Bjoern A. Zeeb" To: "John Baldwin" Cc: "Ed Maste" , "FreeBSD Hackers" Subject: Re: Retiring WITHOUT_CXX Date: Thu, 02 Dec 2021 17:51:11 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <08ECC9EA-B6A3-41A8-98E8-6A5772E0A76F@lists.zabbadoz.net> In-Reply-To: References: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J4k632LHPz3HBH 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 2 Dec 2021, at 17:02, John Baldwin wrote: > On 11/26/21 11:06 AM, Bjoern A. Zeeb wrote: >> On Fri, 26 Nov 2021, Ed Maste wrote: >> >>> On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes >>> wrote: >>>> >>>> So is the feature model of FreeBSD becoming, oh it gets broken >>>> cause it is not regularly tested, so lets remove that feature. >>> >>> I don't agree with that. We have a large and growing CI >>> infrastructure >>> to regularly test functionality and are continually adding to it >>> over >>> time. But it's important to test and maintain what is actually used >>> and is useful. Disabling C++ support made sense when obrien@ added >>> the >>> original knob in 2000, but it makes less sense today when parts of >>> FreeBSD are written in C++. >> >> I used to disable it in my images but started to need devd and that >> is >> really the only reason its there currently >> >> #WITHOUT_CXX= # devd needs it >> >> I used to have a conversation with Warner a while ago about it and >> the >> conclusion was the bits of C++ could be reimplemented in C if needed >> but obviously no one ever got to that. > > I honestly think that's the wrong direction. I'm currently hacking on > a libiscsi for shared bits of iscsid and ctld and right now it has > some > home-grown containers (struct keys) that would be much better as a > std::vector<> of a struct with two strings. It would also benefit > from > having an actual class for the instead of the typical C inheritance > I've > added. Similarly, I've wanted to use std::unordered_map in truss to > handle the syscall counts since hash tables in C require a lot of > boilerplate code. This is no longer 1985, or even 2003. I'm not > ready > to write a kernel in C++ with templates, but I think for userspace > utilities you can buy a fair bit of robustness with RAII, unique_ptr, > etc. and we shouldn't be crippling ourselves. I am not saying you should. But with the current set of essential things in base its a waste for tiny installs. > Also, have you looked at what WITHOUT_CXX actually removes? yes, I believe it was even in the email you quoted. > c++ is just > a hard link to clang. That's the big space eater, not libc++.so.1 or > libcxxrt.so.1. For reference, on my 13.x desktop, libc.so.7 is about > 3 > times the size of libc++.so.1: And I tried a few times in the past to see if we can anything about this and was explained “no”; if libc will be ever growing it’ll be a huge problem one day; we even had an option which never worked for SYMVER (you may remember removing last year; thanks for that!). > -r--r--r-- 1 root wheel 1986208 Aug 19 15:28 /lib/libc.so.7 > -r--r--r-- 1 root wheel 112200 Aug 19 15:29 /lib/libcxxrt.so.1 > -r--r--r-- 1 root wheel 846200 Aug 19 15:29 /usr/lib/libc++.so.1 If you are running a 32M/40M (once was in the 20MB) user space you will notice every MB and especially every library you don’t have to care about removes complexity of stripping things down. If we want to remove options to limit the mess (which was the other part of the discussion) there’s a lot of historic stuff which could be all or nothing really, like BOOTPARAMD BOOTPD RBOOTD … all just disabling a 1 single binary and not a “set of things”/subsystem (like Toolchain, ntp, nis, kerberos, ..) which reducing the number of options would stop heating the world at least some. /bz From nobody Thu Dec 2 18:07:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7CA9A18BF8B7 for ; Thu, 2 Dec 2021 18:08:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (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 4J4kTL3030z3NWc for ; Thu, 2 Dec 2021 18:08:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f49.google.com with SMTP id a23-20020a9d4717000000b0056c15d6d0caso683009otf.12 for ; Thu, 02 Dec 2021 10:08:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2i1+4bHt0a00X3uCSavtPr5TiGzhZg5eNznUQMfO0Qs=; b=OW3IxQx6EI7bQVm29RHxEN9ebVdjnzrnjHFwKU3BhC0C4qI0VMyhjcZs1Di9lIZ1r+ XzaijvRcmo9psIv5gCYAmBJgnknRfpLJPAopGxg6lM10WB9w1GVq3BYvPDYVCze/qlBR RqWeZl7MtZxoSizYiisRMqOtX4NAUoO1TTzfgsDTbI4sfzsfPkGU5s1ekQO22bevT85s Hg8kSAgb6+8RORiouJ/VPuerumaRfoYN6UcSPDrYAHPmqU+YPy8/+oneci2vAxnsDCmR jhYOBRwd0ms/29Ncl2u7U3XFLULMgpfiLjDlen8vi+6OmRzEvjiMWzpWbAc28ccflAaW 10hw== X-Gm-Message-State: AOAM533VtHRCVG9RP3z8/QTyR2Kfl5rsnRR6ycfW4397SCXE4r/bEUoA UTotnzCpbX9rZ+iI0VFTNM1kEkhaUPpYdurMZs3bI45GGpQ= X-Google-Smtp-Source: ABdhPJx0Nf8/GtrQefmxYvo1dsdgop0G/vFDAwyBh4CocXsX0bR7OXInVY0CV6bmGC/dYKbRLAbzfgo9p5y5uWMmQMs= X-Received: by 2002:a9d:7cce:: with SMTP id r14mr12280198otn.114.1638468480308; Thu, 02 Dec 2021 10:08:00 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> In-Reply-To: From: Alan Somers Date: Thu, 2 Dec 2021 11:07:49 -0700 Message-ID: Subject: Re: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Stefan Blachmann Cc: Johannes Totz , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J4kTL3030z3NWc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N That is your problem then. The default value for dd if 512B. If it took 3 days to erase a 2 TB HDD, that means you were writing 15,000 IOPs. Frankly, I'm impressed that the SATA bus could handle that many. By using such a small block size, you were doing an excellent job of exercising the SATA bus and the HDD's host interface, but its servo and write head were mostly just idle. The reason why Linux is different is because unlike FreeBSD it has a buffer cache. Even though dd was writing with 512B blocks, those writes probably got combined by the buffer cache before going to SATA. However, if you use the conv=direct option with dd, then they probably won't be combined. I haven't tested this; it's just a guess. You can probably verify using iostat. When you were trying to erase two HDDs concurrently but only one was getting all of the IOPs and CPU time, was your CPU saturated? I'm guessing not. On my machine, with a similar HDD, dd only consumes 10% of the CPU when I write zeros with a 512B block size. I need to use a 16k block size or larger to get the IOPs under 10,000. So I'm guessing that in your case the CPU scheduler was working just fine, but the SATA bus was saturated, and the SATA scheduler was the source of the unfairness. -Alan On Thu, Dec 2, 2021 at 10:37 AM Stefan Blachmann wrote: > > I intentionally used dd without the bs parameter, as I do care less > about "maximum speed" than clearing the drives completely and also do > a lot of I/O transactions. > The latter because drives that are becoming unreliable tend to > occasionally throw errors, and the more I/O transactions one does the > better the chance is to spot this kind of drives. > > The system is a HP Z420, the mainboard/chipset/controller specs can be > found in the web. > The drives in question here (quite old) 2TB WD Black enterprise grade > 3.5" SATA drives. Their SMART data is good, not hinting at any > problems. > > On Linux, erasing them both concurrently finished at almost the same time. > Thus I do not really understand why on FreeBSD this is so much different. > > On 12/2/21, Alan Somers wrote: > > This is very surprising to me. I never see dd take significant CPU > > consumption until the speed gets up into the GB/s range. What are you > > using for the bs= option? If you set that too low, or use the > > default, it will needlessly consume extra CPU and IOPs. I usually set > > it to 1m for this kind of usage. And what kind of HDDs are these, > > connected to what kind of controller? > > > > On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann > > wrote: > >> > >> Regarding the suggestions to either improve or replace the ULE > >> scheduler, I would like to share another observation. > >> > >> Usually when I need to zero out HDDs using dd, I use a live Linux. > >> This time I did that on FreeBSD (13). > >> My observations: > >> - On the same hardware, the data transfer rate is a small fraction > >> (about 1/4th) of which is achieved by Linux. > >> - The first dd process, which erases the first HDD, gets almost all > >> CPU and I/O time. The second process which does the second HDD is > >> getting starved. It actually really starts only after the first one > >> finished. > >> > >> To me it was *very* surprising to find out that, while erasing two > >> similar HDDs concurrently takes about one day on Linux, on FreeBSD, > >> the first HDD was finished after three days, and only after that the > >> remaining second dd process got the same CPU time, making it proceed > >> fast instead of creepingly slowly. > >> > >> So I guess this might be a scheduler issue. > >> I certainly will do some tests using the old scheduler when I got time. > >> And, I ask myself: > >> Could it be a good idea to sponsor porting the Dragonfly scheduler to > >> FreeBSD? > >> > >> On 12/2/21, Johannes Totz wrote: > >> > On 29/11/2021 03:17, Ed Maste wrote: > >> >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl > >> >> wrote: > >> >>> > >> >>> It's certainly not the latest and greatest, > >> >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz > >> >>> K8-class CPU) > >> >> > >> >> If you're content to use a compiler from a package you can save a lot > >> >> of time by building with `CROSS_TOOLCHAIN=llvm13` and > >> >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps > >> >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. > >> > > >> > (re-send to list, sorry) > >> > Can we disconnect the compiler optimisation flag for base and clang? I > >> > don't need the compiler to be build with -O2 but I want the resulting > >> > base system to have optimisations enabled. > >> > Right now, looks like both get -O2 and a lot of time is spent on > >> > optimising the compiler (for no good reason). > >> > > >> > > >> > > From nobody Thu Dec 2 18:23:33 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F9AD18C5628 for ; Thu, 2 Dec 2021 18:23:44 +0000 (UTC) (envelope-from chris.stephan@live.com) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12olkn2056.outbound.protection.outlook.com [40.92.22.56]) (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 4J4kqK2J1lz3hlY; Thu, 2 Dec 2021 18:23:41 +0000 (UTC) (envelope-from chris.stephan@live.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JWSpb/ZKyunqnDykK6RkKRG5MUiWqrO6kZHpQEfn8Xm64lQKuWnwx07sFSAj8XGLAAqQ+1D8lbvYDYp+QQQiZHWhN/HWTzhCdEyPTEC+fcOj80bF4XqajyA9ISO+ZD6wqjx2tytBig2KIayRIyVdWqXfPx5FbtdnYdF6eij4MJmIMa5Cp2+5oftUMxC28njwqok+3pFFUSOMVwRjiS8rSoZmzRpBpxlLAo86U8FeM8TMq8YaZBeSUQqZLwPbpluytYK96lSN+Q0T0eOKtn1cYQxzJd2VLsc6IdIuqDMwV5b2P0/3GLHvRCISPJoWL1FdBPNVCDVqOE1hU6exx/2N2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=woXcR2G9Vr3pxbxTUXWh6FQPNVCZdWbS4GZrVRmM1qE=; b=j80lz/JN/dw4EHfBrNl6tQPJmKKnPt2LC60UB+5JyZeP/9LcpeL7s6xAvUS+25KvQsZuSzXA6Y6rHb7h6BYy4yZVxiBbmWodTzNTkLUMDAeaQZYPel0LdWztuRd2gnl6AEVPKW5iyyei5aq1Ro21NhZpR/iJOyTXOl4rYkSB1eyPunRs4AjvSYCP6pqOKQVOREGpGohGTw0qe58oYjNFatFut+wwBTrccCJJM2JCntyjo4owqZ6UllfxfnVZYhGL+PVY+Qdmc9UYK5h7JRAOmfuR98y4amr8UpRmq5ls7YC44sBw5as8/915DQ4PLLEp4Iwuc4q2chWEeLxmfepHzA== 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=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=woXcR2G9Vr3pxbxTUXWh6FQPNVCZdWbS4GZrVRmM1qE=; b=fQEq0V6+VCBNzmwQjcIfqdiXk7iZF31IfkC4EpUYFPk/yux5zudGYWqDLkpkqC7CdfLytagwLom2UvBHIb42vh8kIeF6u+a9X2ckewF+qfHvizT9RwPYSKKt/C66ojQ8cM35og3K+UP8Kg6C6TeGP9Wc1Hgaq90eU3yB9Qs5oy6GOH7GH0JlyEmQpHE5T5XipI0hLNksAsUvNTSiPwMKVM1z8Ye7S2AENg9624NGWXflwAZ8DD6zX2NTnNwIQpzud8IYBSapG8Dlwb3+ieKkErTDDiWDtEgLBNJzbugObYDFnZUQeVL12IJBcW1JI1BB1w9Z/1SaTo27RT5AxP1WyQ== Received: from CO1PR02MB8667.namprd02.prod.outlook.com (2603:10b6:303:15e::24) by MW4PR02MB7410.namprd02.prod.outlook.com (2603:10b6:303:7f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.11; Thu, 2 Dec 2021 18:23:33 +0000 Received: from CO1PR02MB8667.namprd02.prod.outlook.com ([fe80::84ea:f215:8739:fc61]) by CO1PR02MB8667.namprd02.prod.outlook.com ([fe80::84ea:f215:8739:fc61%3]) with mapi id 15.20.4755.014; Thu, 2 Dec 2021 18:23:33 +0000 From: Chris Stephan To: Shawn Webb CC: Joseph Mingrone , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Thread-Topic: Call for Foundation-supported Project Ideas Thread-Index: AQHX4LtipOcMM12aTk+xOQZH38JxKqwRwhsAgA3P2gA= Date: Thu, 2 Dec 2021 18:23:33 +0000 Message-ID: References: <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> In-Reply-To: <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ID+haqNn3fa+8Une4XTxpcJidCF9tFmC] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa78a01c-1df5-4f4e-93e9-08d9b5c0d977 x-ms-traffictypediagnostic: MW4PR02MB7410: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Bh7uzhk178Pu1ZaAAGnPNne/F2xhpsGrBBU4+7sS85+UdcrMwZsWnQG8CO4b8JK3aErsWzZe59yTQlQgkUCzclhOy0qkt4cUN34VnURIXqLDvVwX0LGP01sN8b0R437NafZ9gN3tbn5ZlavdBmgsezF5ujghkfkWgJZnqSt3gLkN3E9OHhn/MgABfp4cspuw7TwowunmEmIRLn33bWClU9ov4COvgVbF/qQ9c45hTwMX05LMOHhcqN3v+6czbF151/l5+zGJKt6aU+97O5gBZpsqX/rM5KboDHyrWprp4uLbHzhWIWXRcmoNXtWknsbEGDeTblqghqovmOT7NzURvJ1FsoJW9VYeQunx6uCJM2+ihjIlmVZ6y+Mwphn9h5sM7EinSR3Cal9aD90vDheUGtFt+rcGIOa4xV3qVY5e3D6evLh5oLBLYTi511on5WFVndUYAQray+d1zaNGAcr6+DHz+P/21E0sxUL1pJ97nhxoAnVq987eExo6+JiOvzv5ZEaP/+O5yU1EZw4D5AbfLuxHW6nx8cF81vKznno2oTKENP+vpr5cd3tnRBi4C+F+o62qcO8TWvOF0kc7dRj/xgj54SViBJXqrUekGOWH4y2Emm/BYjahCCTvT6STBcXp x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NUJCT2lrUkpPbzdZOG8xV081Z0xkc2h1L2xsdnpBOUtUWHlBVE43Uk5EbmdE?= =?utf-8?B?eWp2REZmaktneWJ4VUg5cUlMQUhqMG1JM2pHVC9rVldMa2hqUitMbzlUMmU1?= =?utf-8?B?NVF1S2VEeUgxTk1rWXg4MmpNaFhYRlN4dCtOYmpSMktlcHVCalo5NnhmTmdE?= =?utf-8?B?SE9qY2JOR3ZrTjFwWHVwZm5ydXZJSlZDcGExQUVmcnZ1VVVBdGl6Q3ZiMXpi?= =?utf-8?B?czl3UUNMWVllVldaTW4xclc3YUtyWDFJS3ZHSzVCZlBHd0FOWTZSVFVxQTRZ?= =?utf-8?B?VXk4V2RjRnkwTHduWTVwWHpMM0hMVStPZkxVdzRDc24yZGc2dHY4NjBrTW9J?= =?utf-8?B?azlRdVdlWWh6S3BYMDljK1dVdXZSRXNpbmhhdm9udkpXQ1VPdUxnbVM0UE5l?= =?utf-8?B?a0NVQ1dTVGtpR3d1dE4zeHJRc29nK0RsdVNXQkJOZVUvZTBoNWp1QW4yL3du?= =?utf-8?B?NitlWGFlNExxeWdYZlRuRUR5L2g5NVllTUZBa2J4UHIzT2ZjUnY3MTUvRUYw?= =?utf-8?B?U3RlcHhsVU9QVDRHSmd6Ym9nTXUveUdZNG9ydlhCcXNDQ0t1UDNPdGI5SUV5?= =?utf-8?B?VnZpOVNlOTFWTmI4UUpYYTVadHI2bzJKcHlVZm1qemhnS2NrZGgxK3lvMVVy?= =?utf-8?B?eVA5VzVzYjltOGY1NFVnOXZwcFJqcjBvWitFeExqaXVjR0g2eGZDOThkTHBu?= =?utf-8?B?TnFhN3pXclVMVW5UTlRPZlJERWxtN09oOHErZGNoOW42ZWY4OXdhbVZuOEt2?= =?utf-8?B?Skt5a2hqeWh5ZXNCWjhNQXlwSkxXNjV6eU92QXJxMUFZanFJZVVjZ2l3ZEty?= =?utf-8?B?bGs5RDlBcnMvdlJhYUhnaHhpWnlTRGRaQXNodExwYzE3QVpJak1od05rZHY2?= =?utf-8?B?OVQwTzNaWnVzZEV6SytocngrLzY2eUd2cHQwQlJyVm9VeGhsbytNYzZYSlhs?= =?utf-8?B?RThoVTAvTHd6YUE1cXN5eURVOW9OajkvcmNxVTFMaTlqZ3ltbHdEVUx0STRP?= =?utf-8?B?TVZXSzltUDhpY2FpTXI0aHFnTjI3RUMveXZuL2JrK1dFK2F2d1RLYmdqb0NB?= =?utf-8?B?RWsyOWs2WElnK0lsYno1ZEpNcnVCN2VUSG82TVRnNE1RQzRLc2wzdi8zVFM4?= =?utf-8?B?RE1ZWWFvSm9DTHI3cmdtcmZxMHFJRGF3eGMyV2VmOE9FelJrS1k1bkZDdWZC?= =?utf-8?B?enFrT05VeGpjYUUvb2FLeHFuS0ViUXpTbEdianUyZDdwa0dlQjZFb0svTUpm?= =?utf-8?B?QnZDSTFkZVJWa1hJbXRYcUFvU1ZySGIycDVQSGhTaldSQ1VkQT09?= Content-Type: multipart/mixed; boundary="_004_CO1PR02MB866737D3798D2E6E997409739B699CO1PR02MB8667namp_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-99c3d.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR02MB8667.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: fa78a01c-1df5-4f4e-93e9-08d9b5c0d977 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2021 18:23:33.4764 (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: MW4PR02MB7410 X-Rspamd-Queue-Id: 4J4kqK2J1lz3hlY X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=live.com header.s=selector1 header.b=fQEq0V6+; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=live.com; spf=pass (mx1.freebsd.org: domain of chris.stephan@live.com designates 40.92.22.56 as permitted sender) smtp.mailfrom=chris.stephan@live.com X-Spamd-Result: default: False [-2.12 / 15.00]; DWL_DNSWL_NONE(0.00)[live.com:dkim]; R_DKIM_ALLOW(-0.20)[live.com:s=selector1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[live.com]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; HAS_ATTACHMENT(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[live.com:+]; MIME_BASE64_TEXT(0.10)[]; RCVD_IN_DNSWL_NONE(0.00)[40.92.22.56:from]; NEURAL_HAM_SHORT(-0.22)[-0.222]; DMARC_POLICY_ALLOW(-0.50)[live.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FREEMAIL_ENVFROM(0.00)[live.com]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.22.56:from] X-ThisMailContainsUnwantedMimeParts: Y --_004_CO1PR02MB866737D3798D2E6E997409739B699CO1PR02MB8667namp_ Content-Type: multipart/alternative; boundary="_000_CO1PR02MB866737D3798D2E6E997409739B699CO1PR02MB8667namp_" --_000_CO1PR02MB866737D3798D2E6E997409739B699CO1PR02MB8667namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gamFpbCBtYW5hZ2VtZW50IGluIGJhc2XigKYNCg0KMS4gIENhbiB3ZSBlaXRoZXIgc2hp bSB0aGUgamFpbCB0b29saW5nIHdpdGggQ05JIG9yIHByb3ZpZGUgQ05JIHN1cHBvcnQgaW4gdGhl IHRvb2xpbmcgc28gcHJvamVjdHMgcmVxdWlyaW5nIGNvbnRhaW5lcnMgY2FuIGxldmVyYWdlIGph aWxzPw0KDQoyLiBDb250cm9sIG9mIEJTRCBuZXR3b3JrIHN0YWNrIHZpYSBDTknigKYNCg0KMy4g V291bGQgYmUgZ3JlYXQgaWYgYmh5dmUgYWxzbyBsZXZlcmFnZWQgQ05J4oCmDQoNCkkgbWlnaHQg YmUgYWR2b2NhdGluZyBmb3IgQ0JTRCB1bmludGVudGlvbmFsbHkuIEl0IGlzIHF1aXRlIGltcHJl c3NpdmUgd2hhdCB0aGV54oCZdmUgYWNjb21wbGlzaGVkLCB0aG91Z2ggSSBwcmVmZXIgdGhlIGFw cHJvYWNoIHZtLWJoeXZlIChjaHVyY2hlcykgdG9vayB3aGljaCBmZWVscyBsaWtlIGEgZmx1aWQg bWVjaGFuaXNtIGZvciBpbnRlcmFjdGluZyB3aXRoIGJoeXZlIG1vcmUgc28gdGhhbiBDQlNELiAg QmFzdGlsbGUgaXMgYWxzbyBhIGdvb2Qgb3B0aW9uIG9yIHByb2plY3QgdG8gZXZhbHVhdGUgaW4g cmVnYXJkcyB0byB2aXJ0dWFsaXphdGlvbi9jb250YWluZXIgbWFuYWdlbWVudCBvZiBGcmVlQlNE IGd1ZXN0cy4NCg0KQWxsIHRoYXQgYmVpbmcgc2FpZCwgSeKAmW0gbm90IHRlcnJpYmx5IHBhcnRp Y3VsYXIsIGJleW9uZCBJIHRoaW5rIENOSSBtaWdodCBiZSBhIGdvb2QgaW50ZWdyYXRpb24gcG9p bnQgcmVnYXJkbGVzcyBvZiB0aGUgbG9jYWxpemVkIHRvb2xpbmcgZGVzaWduLg0KDQpUaGFua3Ms DQoNCkNocmlzDQoNClNlbnQgZnJvbSBGcmVlQlNEDQoNCk9uIE5vdiAyMywgMjAyMSwgYXQgNToy OSBQTSwgU2hhd24gV2ViYiA8c2hhd24ud2ViYkBoYXJkZW5lZGJzZC5vcmc+IHdyb3RlOg0KDQrv u79PbiBUdWUsIE5vdiAyMywgMjAyMSBhdCAwNjo0MTowMVBNIC0wNDAwLCBKb3NlcGggTWluZ3Jv bmUgd3JvdGU6DQpIZWxsbyBGcmVlQlNEIGNvbW11bml0eSwNCg0KVGhlIEZvdW5kYXRpb24gaXMg c2Vla2luZyBzdWdnZXN0aW9ucyBmb3IgbmV3IHByb2plY3RzIHRvIHN1cHBvcnQuICBXaGF0DQpn YXBzIGluIHRoZSBQcm9qZWN0IGFyZSBub3QgYmVpbmcgYWRkcmVzc2VkIGJ5IHRoZSBicm9hZGVy IGNvbW11bml0eT8NCg0KWW91IGNhbiByZWFkIGFib3V0IHBhc3QgRm91bmRhdGlvbi1zdXBwb3J0 ZWQgcHJvamVjdHMgYXQNCmh0dHBzOi8vZnJlZWJzZGZvdW5kYXRpb24ub3JnL291ci13b3JrL3By b2plY3RzLyBhbmQgdGhlIEZvdW5kYXRpb24ncw0KZm91ciBtYWluIGFyZWFzIG9mIGZvY3VzIGlu IHRoZSAnVGVjaG5vbG9neSBSb2FkbWFwJyBhcnRpY2xlIGF0DQpodHRwczovL2ZyZWVic2Rmb3Vu ZGF0aW9uLm9yZy9ibG9nL3RlY2hub2xvZ3ktcm9hZG1hcC8uDQoNClJpZ2h0IG5vdyB3ZSBhcmUg Z2F0aGVyaW5nIGlkZWFzLiAgV2Ugd2lsbCBzZW5kIG91dCBhIGNhbGwgZm9yIHByb2plY3QNCmdy YW50IHByb3Bvc2FscyBzb29uLiAgSWYgeW91IHByZWZlciB0byBzZW5kIHlvdXIgcHJvamVjdCBp ZGVhcyBkaXJlY3RseQ0KdG8gdGhlIEZvdW5kYXRpb24sIHdlIHdpbGwgYmUgbW9uaXRvcmluZyBy ZXNwb25zZXMgYXQNCnRlY2h0ZWFtQGZyZWVic2Rmb3VuZGF0aW9uLm9yZy4NCg0KSGV5IEpvc2Vw aCwNCg0KVGhhbmtzIGZvciBzZW5kaW5nIHRoaXMgb3V0IQ0KDQpIZXJlJ3MganVzdCBhIGZldyB0 aGluZ3MgSSdkIGxvdmUgdG8gc2VlOg0KDQoxLiB3aXJlbGVzcyBtZXNoIHN1cHBvcnQuIHRoaXMg d291bGQgZ28gX2EgbG9uZ18gd2F5cyBmb3Igc3VwcG9ydGluZw0KICBodW1hbiByaWdodHMgZWZm b3J0cy4NCjIuIDEwMCUgbGx2bSB0b29sY2hhaW4gZm9yIGJhc2UgYW5kIHBvcnRzLiBmcmVlYnNk IHNlZW1zIHRvIGFscmVhZHkgYmUNCiAgZ29pbmcgaW4gdGhpcyBkaXJlY3Rpb24uDQozLiBqYWls IG9yY2hlc3RyYXRpb24gaW4gYmFzZS4gaXQncyBncmVhdCB0aGF0IHdlIGhhdmUgYWxsIHRoZXNl DQogIGRpc3BhcmF0ZSBqYWlsIG1hbmFnZW1lbnQgcG9ydHMsIGJ1dCB3ZSBsYWNrIGEgZnVsbHkN CiAgY29oZXJlbnQvaW50ZWdyZWF0ZWQgc29sdXRpb24uIEknZCBsb3ZlIHRvIHNlZSBqYWlsIG9y Y2hlc3RyYXRpb24NCiAgZ2V0IHRoZSBzYW1lIGxvdmUgYXMgemZzIGluIGJhc2UuDQo0LiB0b3Ig YnJvd3NlciBidW5kbGUgKHBvcnQgZnJvbSBvcGVuYnNkPykNCg0KVGhhdCdzIGF0IGxlYXN0IHdo YXQgSSBjYW4gdGhpbmsgb2Ygb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZC4NCg0KVGhhbmtzIGFnYWlu LA0KDQotLQ0KU2hhd24gV2ViYg0KQ29mb3VuZGVyIC8gU2VjdXJpdHkgRW5naW5lZXINCkhhcmRl bmVkQlNEDQoNCmh0dHBzOi8vZ2l0LmhhcmRlbmVkYnNkLm9yZy9oYXJkZW5lZGJzZC9wdWJrZXlz Ly0vcmF3L21hc3Rlci9TaGF3bl9XZWJiLzAzQTRDQkVCQjgyRUE1QTY3RDlGMzg1M0ZGMkU2N0Ey NzdGOEUxRkEucHViLmFzYw0K --_000_CO1PR02MB866737D3798D2E6E997409739B699CO1PR02MB8667namp_-- --_004_CO1PR02MB866737D3798D2E6E997409739B699CO1PR02MB8667namp_-- From nobody Thu Dec 2 18:46:03 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6101A18CF279 for ; Thu, 2 Dec 2021 18:46:05 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 4J4lK91g3Tz3pfQ; Thu, 2 Dec 2021 18:46:05 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x12e.google.com with SMTP id c32so724268lfv.4; Thu, 02 Dec 2021 10:46:05 -0800 (PST) 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=nfxZYnmuRagHRfapQywV6ZrFie0fHblnsTs7Ca+xJRQ=; b=MxjmXz/rtjdBWdTzcI3PROO9Dumj1p77TLXqqJK1McovTL8rag2TbY06oNTagBXLKx mQlMyPItthYiZ3X1RfiLbsZR0jc5DQU4Y3vuEMfAVp3CDNRjDRnKEjTHxjddDFMBc3yv 59ZsqCA3WmTBnJ6g/hViS9NAXLgwHNNj3qLGjoHivUNU7gKTixmG1rk2NkMFkqYhh15h EbdkmCI0yqu9a7ZHGjo81v8CilJgdDSZ9XaNpnt5rDeTHaKaU8HsfXa6e5XEKki5/kCV RRDVtw5c2SiHliNk0gKReokH0DG2IakSEm+vkF/yZXxqPffzV2MIxjk2wm8lJGhiceDo Ap4w== 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=nfxZYnmuRagHRfapQywV6ZrFie0fHblnsTs7Ca+xJRQ=; b=2HctZauqSGO1mv6TJtek5yug2zHLdkaXXSu9D5++sIzMbENUZLF0e7LUD+qoxwKTAO D1D4gpBlsWmJe4mUCOToO4GHFaUYCXC8+vXfyLTIJv1HWbD6D5bi3NgsAi6RIcGCRno3 HlGK5iU/7PABwEqc1I8mVnYVoHpsOU5ItAOi83kll+zTS+AaakdPueTijyw6P9SRm2oq xicuv9YOrcSa58wbxNVN2B15bA7JufY9KBDz7P6gzvgVwTZv+CFNx6OzEnX6vVyFWIXP eD0juUlL+nCM4Q647BQcb2/NH+p9YVK8iR7vhrUzoXnGgTEBynlTaDfFjeqWpc5kXMBb c0Pg== X-Gm-Message-State: AOAM531LBNHjqAryOFNzpO7qU09I6HQgVnt5dflTkM0iyVRqrA3WH9DZ Wm/hMNMn6OciMIrXEtBmIpAWbmgKnOdZ+WPAWyhu9CAm X-Google-Smtp-Source: ABdhPJx7p1bwy1j+DSSEEJ2HUDW5WX5Xbr3tAgBz94RpflhInuyuxpIPRfuLcwGV4DSBcKtkbBAYRvoRyxVioi0MXLU= X-Received: by 2002:a05:6512:3718:: with SMTP id z24mr13593649lfr.563.1638470763913; Thu, 02 Dec 2021 10:46:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Thu, 2 Dec 2021 10:46:03 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> From: Stefan Blachmann Date: Thu, 2 Dec 2021 19:46:03 +0100 Message-ID: Subject: Re: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Alan Somers Cc: Johannes Totz , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J4lK91g3Tz3pfQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Ah, the buffer cache! Didn't think of that. Top shows the weighted cpu load is about 4%, so your guess that it was the SATA scheduler might be correct. Will try this on Linux the next days using conv=direct with a pair of identical HDDs. Already curious for the results. On 12/2/21, Alan Somers wrote: > That is your problem then. The default value for dd if 512B. If it > took 3 days to erase a 2 TB HDD, that means you were writing 15,000 > IOPs. Frankly, I'm impressed that the SATA bus could handle that > many. By using such a small block size, you were doing an excellent > job of exercising the SATA bus and the HDD's host interface, but its > servo and write head were mostly just idle. > > The reason why Linux is different is because unlike FreeBSD it has a > buffer cache. Even though dd was writing with 512B blocks, those > writes probably got combined by the buffer cache before going to SATA. > However, if you use the conv=direct option with dd, then they probably > won't be combined. I haven't tested this; it's just a guess. You can > probably verify using iostat. > > When you were trying to erase two HDDs concurrently but only one was > getting all of the IOPs and CPU time, was your CPU saturated? I'm > guessing not. On my machine, with a similar HDD, dd only consumes 10% > of the CPU when I write zeros with a 512B block size. I need to use a > 16k block size or larger to get the IOPs under 10,000. So I'm > guessing that in your case the CPU scheduler was working just fine, > but the SATA bus was saturated, and the SATA scheduler was the source > of the unfairness. > -Alan > > On Thu, Dec 2, 2021 at 10:37 AM Stefan Blachmann > wrote: >> >> I intentionally used dd without the bs parameter, as I do care less >> about "maximum speed" than clearing the drives completely and also do >> a lot of I/O transactions. >> The latter because drives that are becoming unreliable tend to >> occasionally throw errors, and the more I/O transactions one does the >> better the chance is to spot this kind of drives. >> >> The system is a HP Z420, the mainboard/chipset/controller specs can be >> found in the web. >> The drives in question here (quite old) 2TB WD Black enterprise grade >> 3.5" SATA drives. Their SMART data is good, not hinting at any >> problems. >> >> On Linux, erasing them both concurrently finished at almost the same >> time. >> Thus I do not really understand why on FreeBSD this is so much different. >> >> On 12/2/21, Alan Somers wrote: >> > This is very surprising to me. I never see dd take significant CPU >> > consumption until the speed gets up into the GB/s range. What are you >> > using for the bs= option? If you set that too low, or use the >> > default, it will needlessly consume extra CPU and IOPs. I usually set >> > it to 1m for this kind of usage. And what kind of HDDs are these, >> > connected to what kind of controller? >> > >> > On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann >> > wrote: >> >> >> >> Regarding the suggestions to either improve or replace the ULE >> >> scheduler, I would like to share another observation. >> >> >> >> Usually when I need to zero out HDDs using dd, I use a live Linux. >> >> This time I did that on FreeBSD (13). >> >> My observations: >> >> - On the same hardware, the data transfer rate is a small fraction >> >> (about 1/4th) of which is achieved by Linux. >> >> - The first dd process, which erases the first HDD, gets almost all >> >> CPU and I/O time. The second process which does the second HDD is >> >> getting starved. It actually really starts only after the first one >> >> finished. >> >> >> >> To me it was *very* surprising to find out that, while erasing two >> >> similar HDDs concurrently takes about one day on Linux, on FreeBSD, >> >> the first HDD was finished after three days, and only after that the >> >> remaining second dd process got the same CPU time, making it proceed >> >> fast instead of creepingly slowly. >> >> >> >> So I guess this might be a scheduler issue. >> >> I certainly will do some tests using the old scheduler when I got >> >> time. >> >> And, I ask myself: >> >> Could it be a good idea to sponsor porting the Dragonfly scheduler to >> >> FreeBSD? >> >> >> >> On 12/2/21, Johannes Totz wrote: >> >> > On 29/11/2021 03:17, Ed Maste wrote: >> >> >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl >> >> >> wrote: >> >> >>> >> >> >>> It's certainly not the latest and greatest, >> >> >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz >> >> >>> K8-class CPU) >> >> >> >> >> >> If you're content to use a compiler from a package you can save a >> >> >> lot >> >> >> of time by building with `CROSS_TOOLCHAIN=llvm13` and >> >> >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps >> >> >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. >> >> > >> >> > (re-send to list, sorry) >> >> > Can we disconnect the compiler optimisation flag for base and clang? >> >> > I >> >> > don't need the compiler to be build with -O2 but I want the >> >> > resulting >> >> > base system to have optimisations enabled. >> >> > Right now, looks like both get -O2 and a lot of time is spent on >> >> > optimising the compiler (for no good reason). >> >> > >> >> > >> >> >> > >