From nobody Mon Apr 29 01:09:17 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VSQGR0V8sz5Hs5X for ; Mon, 29 Apr 2024 01:09:35 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (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 4VSQGQ3z1fz4g67 for ; Mon, 29 Apr 2024 01:09:34 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 43T19Ksk071604; Sun, 28 Apr 2024 18:09:20 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 43T19HKw071603; Sun, 28 Apr 2024 18:09:17 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202404290109.43T19HKw071603@gndrsh.dnsmgr.net> Subject: Re: Multicast & Tunnel devices In-Reply-To: To: Dirk-Willem van Gulik Date: Sun, 28 Apr 2024 18:09:17 -0700 (PDT) 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-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4VSQGQ3z1fz4g67 > Would anyone know if there is something special with tunnel devices and multicast ? > > I?ve got some code that happily processes multicast packets on a normal interface; but appears not to do this on a tunnel interface. Tun0 shows multicast enabled: > > tun0: flags=8043 metric 0 mtu 1500 > > Tcpdump on that interface gives the expected thing (here with mDNS): > > tcpdump -n -i tun0 port 5353 > listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes > 19:26:03.976259 IP 10.31.0.6.5353 > 224.0.0.251.5353: 0 PTR (QM)? _raop._tcp.local. (34) > > And code, with a simple IP_ADD_MEMBERSHIP of the MC group on the IP of the local interface below works on a normal interface (e.g. igb0/10.0.0.1/24). > > ./listener 10.0.0.1 224.0.0.251 5353 Is 10.0.0.1 the IP address of tun0, or is it the address of some other interface? I suspect that the IP address of the tun0 interface is 10.31.0.6 from your tcpdump above. IIRC you have to join multicast group on all interfaces you expect to receive mustcast packets on. > Received packet, len=128 > etc > > But yields no output if ran against above tun0 interface (while tcpdump on same is fine). Does that ring a bell with anyone ? > > Dw > > > int main(int argc, char *argv[]) > { > struct sockaddr_in addr; > struct ip_mreq mreq; > > // skip error trapping command line arguments > > char* ip = argv[1]; > char* group = argv[2]; > int port = atoi(argv[3]); // 0 if error, which is an invalid port > > memset(&addr, 0, sizeof(addr)); > addr.sin_family = AF_INET; > addr.sin_addr.s_addr = htonl(INADDR_ANY); > addr.sin_port = htons(port); > > mreq.imr_interface.s_addr = inet_addr(ip); > mreq.imr_multiaddr.s_addr = inet_addr(group); > > // skip error trapping on inet_addr > > int fd = socket(AF_INET, SOCK_DGRAM, 0); > // skip error trapping socket > > if (bind(fd, (struct sockaddr*) &addr, sizeof(addr)) < 0) { > // skip error trapping > > if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char*) &mreq, sizeof(mreq)) < 0 ){ > // skip error trapping argumetns > > while (1) { > .. > int nbytes = recvfrom(fd,msgbuf,MSGBUFSIZE,0,(struct sockaddr *) &addr,&addrlen); > if (nbytes < 0) { > perror("recvfrom"); > return 1; > } > printf(?Received packet, len=%d\n", nbytes); > } > -- Rod Grimes rgrimes@freebsd.org From nobody Mon Apr 29 10:34:51 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VSfq82z7Gz5J2qB for ; Mon, 29 Apr 2024 10:35:16 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VSfq72Zt0z4n04 for ; Mon, 29 Apr 2024 10:35:15 +0000 (UTC) (envelope-from naddy@mips.inka.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of naddy@mips.inka.de designates 2a04:c9c7:0:1073:217:a4ff:fe3b:e77c as permitted sender) smtp.mailfrom=naddy@mips.inka.de Received: from mips.inka.de (naddy@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1s1OLi-003zv2-6h; Mon, 29 Apr 2024 12:35:06 +0200 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.18.1/8.18.1) with ESMTP id 43TAYpwl085493 for ; Mon, 29 Apr 2024 12:34:51 +0200 (CEST) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.18.1/8.18.1/Submit) id 43TAYp4D085492 for freebsd-hackers@freebsd.org; Mon, 29 Apr 2024 12:34:51 +0200 (CEST) (envelope-from naddy) Date: Mon, 29 Apr 2024 12:34:51 +0200 From: Christian Weisgerber To: freebsd-hackers@freebsd.org Subject: How to run tests without installing? Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[naddy]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[inka.de]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4VSfq72Zt0z4n04 How can I run the regression tests on my work-in-progress without installing it first? Say I'm changing something in sh. Can I run the tests on the compiled sh in /usr/obj, without having to install my potentially broken work into the system? Running "make tests" in src/bin/sh doesn't seem to actually test anything. -- Christian "naddy" Weisgerber naddy@mips.inka.de From nobody Mon Apr 29 14:36:20 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VSmCD6L3Pz5JSMq for ; Mon, 29 Apr 2024 14:38:00 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (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 "weser.webweaving.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VSmCD2RDDz4Lc9 for ; Mon, 29 Apr 2024 14:38:00 +0000 (UTC) (envelope-from dirkx@webweaving.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (fiber.static.cbizz.nl [185.142.248.117] (may be forged)) (authenticated bits=0) by weser.webweaving.org (8.17.1/8.17.1) with ESMTPA id 43TEaaBc012772; Mon, 29 Apr 2024 16:36:37 +0200 (CEST) (envelope-from dirkx@webweaving.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=webweaving.org; s=shared; t=1714401400; bh=uCgvF6Y2uDrxaK0L+CI40Mr65qKYP2+XafKFPUU2hUQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=RwrwBTf7QuHY2Sv8rn3uvzOjFuLInOtJ4uzt4GbhBFhVd7ix8vybvRIWi+HtVJNsf Qd+o7PjN/piogTu25M6L6F/SyJ62VE+7LxYb/U/ZbOR1Il7F5POsLHzfKxdftC6DRO k5xkcTcBIwS6+AFsJYhyScK7qr/Xo97/tZKmVOQU= X-Authentication-Warning: weser.webweaving.org: Host fiber.static.cbizz.nl [185.142.248.117] (may be forged) claimed to be smtpclient.apple From: Dirk-Willem van Gulik Message-Id: <2C4BC70A-750C-4E0F-B400-351CBBD6374B@webweaving.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_34D971FD-B2DA-4F26-B33F-055D8F4B9B9F" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Multicast & Tunnel devices Date: Mon, 29 Apr 2024 16:36:20 +0200 In-Reply-To: <202404290109.43T19HKw071603@gndrsh.dnsmgr.net> Cc: FreeBSD Hackers To: "Rodney W. Grimes" References: <202404290109.43T19HKw071603@gndrsh.dnsmgr.net> X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (weser.webweaving.org [148.251.234.232]); Mon, 29 Apr 2024 16:36:40 +0200 (CEST) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:148.251.0.0/16, country:DE] X-Rspamd-Queue-Id: 4VSmCD2RDDz4Lc9 --Apple-Mail=_34D971FD-B2DA-4F26-B33F-055D8F4B9B9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 29 Apr 2024, at 03:09, Rodney W. Grimes = wrote: >=20 >> Would anyone know if there is something special with tunnel devices = and multicast ?=20 >>=20 >> I?ve got some code that happily processes multicast packets on a = normal interface; but appears not to do this on a tunnel interface. Tun0 = shows multicast enabled: >> =09 >> tun0: flags=3D8043 metric 0 mtu = 1500 >>=20 >> Tcpdump on that interface gives the expected thing (here with mDNS): >>=20 >> tcpdump -n -i tun0 port 5353 >> listening on tun0, link-type NULL (BSD loopback), capture size = 262144 bytes >> 19:26:03.976259 IP 10.31.0.6.5353 > 224.0.0.251.5353: 0 PTR = (QM)? _raop._tcp.local. (34) >>=20 >> And code, with a simple IP_ADD_MEMBERSHIP of the MC group on the IP = of the local interface below works on a normal interface (e.g. = igb0/10.0.0.1/24).=20 >>=20 >> ./listener 10.0.0.1 224.0.0.251 5353 >=20 > Is 10.0.0.1 the IP address of tun0, or is it the address of some other = interface? > I suspect that the IP address of the tun0 interface is 10.31.0.6 from = your tcpdump above. That is correct 10.0.0.1/8. 10.31.0.6 is another machine at the other = end of the tunnel broadcasting. > IIRC you have to join multicast group on all interfaces you expect to = receive mustcast packets on. >=20 >> Received packet, len=3D128 >> etc >>=20 >> But yields no output if ran against above tun0 interface (while = tcpdump on same is fine). Does that ring a bell with anyone ? >>=20 >> Dw >>=20 >>=20 >> int main(int argc, char *argv[]) >> { >> struct sockaddr_in addr; >> struct ip_mreq mreq; >>=20 >> // skip error trapping command line arguments >>=20 >> char* ip =3D argv[1];=20 >> char* group =3D argv[2];=20 >> int port =3D atoi(argv[3]); // 0 if error, which is an invalid = port >>=20 >> memset(&addr, 0, sizeof(addr)); >> addr.sin_family =3D AF_INET; >> addr.sin_addr.s_addr =3D htonl(INADDR_ANY); >> addr.sin_port =3D htons(port); >>=20 >> mreq.imr_interface.s_addr =3D inet_addr(ip);=20 >> mreq.imr_multiaddr.s_addr =3D inet_addr(group); >>=20 >> // skip error trapping on inet_addr >>=20 >> int fd =3D socket(AF_INET, SOCK_DGRAM, 0); >> // skip error trapping socket >>=20 >> if (bind(fd, (struct sockaddr*) &addr, sizeof(addr)) < 0) { >> // skip error trapping >>=20 >> if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char*) &mreq, = sizeof(mreq)) < 0 ){ >> // skip error trapping argumetns >>=20 >> while (1) { >> .. >> int nbytes =3D recvfrom(fd,msgbuf,MSGBUFSIZE,0,(struct = sockaddr *) &addr,&addrlen); >> if (nbytes < 0) { >> perror("recvfrom"); >> return 1; >> } >> printf(?Received packet, len=3D%d\n", nbytes); >> } >>=20 --Apple-Mail=_34D971FD-B2DA-4F26-B33F-055D8F4B9B9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 29 Apr 2024, at 03:09, Rodney W. Grimes = <freebsd-rwg@gndrsh.dnsmgr.net> wrote:

Would anyone know if there is something special = with tunnel devices and multicast ? 

I?ve got some code = that happily processes multicast packets on a normal interface; but = appears not to do this on a tunnel interface. Tun0 shows multicast = enabled:
=
= tun0: flags=3D8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 = mtu 1500

Tcpdump on that interface gives the expected thing (here = with mDNS):

tcpdump -n -i tun0 port 5353
listening = on tun0, link-type NULL (BSD loopback), capture size 262144 = bytes
= 19:26:03.976259 IP 10.31.0.6.5353 > 224.0.0.251.5353: 0 PTR = (QM)? _raop._tcp.local. (34)

And code, with a simple = IP_ADD_MEMBERSHIP  of the MC group on the IP of the local interface = below works on a normal interface (e.g. igb0/10.0.0.1/24). 

= ./listener 10.0.0.1 224.0.0.251 5353

Is 10.0.0.1 the IP address of tun0, or is = it the address of some other interface?
I suspect that the IP address of the tun0 interface is = 10.31.0.6 from your tcpdump above.

That is = correct 10.0.0.1/8. 10.31.0.6 is another machine at the other end of the = tunnel broadcasting.

IIRC = you have to join multicast group on all interfaces you expect to receive = mustcast packets on.

Received packet, len=3D128
= etc

But yields no output if ran against above tun0 = interface (while tcpdump on same is fine). Does that ring a bell with = anyone ?

Dw


int main(int argc, char = *argv[])
{
   struct sockaddr_in = addr;
   struct ip_mreq mreq;

// skip = error trapping command line arguments

   char* ip = =3D argv[1]; 
   char* = group =3D argv[2]; 
   int = port =3D atoi(argv[3]); // 0 if error, which is an invalid = port

   memset(&addr, 0, = sizeof(addr));
   addr.sin_family =3D = AF_INET;
   addr.sin_addr.s_addr =3D = htonl(INADDR_ANY);
   addr.sin_port =3D = htons(port);

   mreq.imr_interface.s_addr =3D = inet_addr(ip); 
   mreq.im= r_multiaddr.s_addr =3D inet_addr(group);

// skip = error trapping on inet_addr

   int fd =3D = socket(AF_INET, SOCK_DGRAM, 0);
// skip error trapping = socket

   if (bind(fd, (struct sockaddr*) = &addr, sizeof(addr)) < 0) {
// skip error = trapping

   if (setsockopt(fd, IPPROTO_IP, = IP_ADD_MEMBERSHIP, (char*) &mreq, sizeof(mreq)) < 0 ){
// skip = error trapping argumetns

   while (1) {
= ..
       int nbytes =3D = recvfrom(fd,msgbuf,MSGBUFSIZE,0,(struct sockaddr *) = &addr,&addrlen);
       if = (nbytes < 0) = {
           per= ror("recvfrom");
         =   return = 1;
       }
= printf(?Received packet, len=3D%d\n", = nbytes);
    }


= --Apple-Mail=_34D971FD-B2DA-4F26-B33F-055D8F4B9B9F-- From nobody Mon Apr 29 17:52:28 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VSrWp0j3sz5JmhD for ; Mon, 29 Apr 2024 17:52:38 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (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 4VSrWn42bXz4fDQ for ; Mon, 29 Apr 2024 17:52:37 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 43THqUNk074360; Mon, 29 Apr 2024 10:52:30 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 43THqS5l074359; Mon, 29 Apr 2024 10:52:28 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202404291752.43THqS5l074359@gndrsh.dnsmgr.net> Subject: Re: Multicast & Tunnel devices In-Reply-To: <2C4BC70A-750C-4E0F-B400-351CBBD6374B@webweaving.org> To: Dirk-Willem van Gulik Date: Mon, 29 Apr 2024 10:52:28 -0700 (PDT) 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-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4VSrWn42bXz4fDQ > > > > On 29 Apr 2024, at 03:09, Rodney W. Grimes wrote: > > > >> Would anyone know if there is something special with tunnel devices and multicast ? > >> > >> I?ve got some code that happily processes multicast packets on a normal interface; but appears not to do this on a tunnel interface. Tun0 shows multicast enabled: > >> > >> tun0: flags=8043 metric 0 mtu 1500 > >> > >> Tcpdump on that interface gives the expected thing (here with mDNS): > >> > >> tcpdump -n -i tun0 port 5353 > >> listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes > >> 19:26:03.976259 IP 10.31.0.6.5353 > 224.0.0.251.5353: 0 PTR (QM)? _raop._tcp.local. (34) > >> > >> And code, with a simple IP_ADD_MEMBERSHIP of the MC group on the IP of the local interface below works on a normal interface (e.g. igb0/10.0.0.1/24). > >> > >> ./listener 10.0.0.1 224.0.0.251 5353 > > > > Is 10.0.0.1 the IP address of tun0, or is it the address of some other interface? > > I suspect that the IP address of the tun0 interface is 10.31.0.6 from your tcpdump above. > > That is correct 10.0.0.1/8. 10.31.0.6 is another machine at the other end of the tunnel broadcasting. > > > IIRC you have to join multicast group on all interfaces you expect to receive mustcast packets on. > > > >> Received packet, len=128 > >> etc > >> > >> But yields no output if ran against above tun0 interface (while tcpdump on same is fine). Does that ring a bell with anyone ? > >> > >> Dw > >> > >> > >> int main(int argc, char *argv[]) > >> { > >> struct sockaddr_in addr; > >> struct ip_mreq mreq; > >> > >> // skip error trapping command line arguments > >> > >> char* ip = argv[1]; > >> char* group = argv[2]; > >> int port = atoi(argv[3]); // 0 if error, which is an invalid port > >> > >> memset(&addr, 0, sizeof(addr)); > >> addr.sin_family = AF_INET; > >> addr.sin_addr.s_addr = htonl(INADDR_ANY); > >> addr.sin_port = htons(port); > >> > >> mreq.imr_interface.s_addr = inet_addr(ip); > >> mreq.imr_multiaddr.s_addr = inet_addr(group); > >> > >> // skip error trapping on inet_addr > >> > >> int fd = socket(AF_INET, SOCK_DGRAM, 0); > >> // skip error trapping socket > >> > >> if (bind(fd, (struct sockaddr*) &addr, sizeof(addr)) < 0) { > >> // skip error trapping > >> > >> if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char*) &mreq, sizeof(mreq)) < 0 ){ > >> // skip error trapping argumetns > >> > >> while (1) { > >> .. > >> int nbytes = recvfrom(fd,msgbuf,MSGBUFSIZE,0,(struct sockaddr *) &addr,&addrlen); > >> if (nbytes < 0) { > >> perror("recvfrom"); > >> return 1; > >> } > >> printf(?Received packet, len=%d\n", nbytes); > >> } > >> > -- Rod Grimes rgrimes@freebsd.org From nobody Mon Apr 29 20:47:46 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VSy5Y1FRlz5JwRf for ; Mon, 29 Apr 2024 22:03:45 +0000 (UTC) (envelope-from brooks@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 4VSy5Y0Vt2z4vwh; Mon, 29 Apr 2024 22:03:45 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714428225; 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=3RkWvzbCZpgYt1VNgHCsP+6QqfpExEHc/vys9HgSAsA=; b=RRp9fGy0yMEzC4spFkzsXdqsrmiena7KVDVtODAiR5WFSPuqYktbCGfUHKSkXXi0Mkl8AM J8bLuR5DN4wDp0M7GYrC+0S6HWU6TF0c/9A2MSBsIVcYL0d6C2mNapTh9AC5SFoFKRfT+D Sx7CxWEbvTR228YqQiGecuWlW7ITVOURESPKsiVpilknfS9o74jcZgRgiJU5qUkEG+iACz +IXPV4+sGiXbz0OCldPOal2h1bdN4vIpFROQw2qKfJc12gi5K2JRr1gcKGcs74lgzgBZ2N ACRyFADXhSngXwKFAIHgPhId3zWKh+BK4Jco/2tpJQhquQw1dUvIlEYANfbToQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1714428225; a=rsa-sha256; cv=none; b=WnQsikD3o+cL8jGBT2DJqVBvBBKY7WyFa6Jy3LNWdi8UKWxuCPHTMXOP72o42HueMN7qyH fg5nV1zAinNCLVRMSY84ka1KKhWSdAJQZDAMuUdPyZSKl22rAa2393lu8SNNMYpfqur3KY 1DioYVnCyPfyWiP/+U/JBgt3VUUE61SYjEG5wIktQ9813C1ZRj0ODkpD+GFUT9mOErgFii oph4NePepmzRc/VG/x5STZAVJHfrb97RJmfYw210AlZMViiCjaFsTD60wSmKHecW9ikRSF +E5WbwwXOEwUrIWBKCtOHTtMVmQ/LMuKJCh47Ar5dEIOQUzy2gzpNGkWi5HNxQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714428225; 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=3RkWvzbCZpgYt1VNgHCsP+6QqfpExEHc/vys9HgSAsA=; b=P0BjJ0UdxbmjJOKj3Z1RVa+uWcsKbrqbrZjOkGAsakQEmJnMsGXzuhhxJ3oje1y0CiUWVh 60aq20nBHcSkZWRALjxxiY/MdUNgP/aqnIr8qB3gnyX6w7/ZCUok1DctgB5+JTfJGoeBNu KenIe77KrK+onqpUr851TllN9sbilkrit0N8M0aZpJCCy63g2WeaEisWGoTei9uSpQdJT3 9rYYUc1ObSqpULjbCFrnhWwO6qqZvw6ZtbdaKoZiMUgaR/Zmy0ueaKEgeeJJpveYnbg6u6 CNRoOVL3GRmy+mYJo6PcvcdtEYOv5KHUJRPeR/KHSc9NhOPtrSs01H3ei70flg== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VSy5X6zdfzhVk; Mon, 29 Apr 2024 22:03:44 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 1B3FE3C019B; Mon, 29 Apr 2024 20:47:46 +0000 (UTC) Date: Mon, 29 Apr 2024 20:47:46 +0000 From: Brooks Davis To: Christian Weisgerber Cc: freebsd-hackers@freebsd.org Subject: Re: How to run tests without installing? 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=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Apr 29, 2024 at 12:34:51PM +0200, Christian Weisgerber wrote: > How can I run the regression tests on my work-in-progress without > installing it first? > > Say I'm changing something in sh. Can I run the tests on the > compiled sh in /usr/obj, without having to install my potentially > broken work into the system? Running "make tests" in src/bin/sh > doesn't seem to actually test anything. Generally speaking you can't. This is one of the problematic things about the current test framework. The best you can do for something like sh where you really don't want to install a broken one is probably installing in a jail and running tests there. -- Brooks From nobody Mon Apr 29 19:03:06 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VSyBJ6G1qz5JxHp for ; Mon, 29 Apr 2024 22:07:52 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (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 "weser.webweaving.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VSyBJ2hWXz41s8 for ; Mon, 29 Apr 2024 22:07:52 +0000 (UTC) (envelope-from dirkx@webweaving.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (fiber.static.cbizz.nl [185.142.248.117] (may be forged)) (authenticated bits=0) by weser.webweaving.org (8.17.1/8.17.1) with ESMTPA id 43TJ3HJR040485; Mon, 29 Apr 2024 21:03:18 +0200 (CEST) (envelope-from dirkx@webweaving.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=webweaving.org; s=shared; t=1714417400; bh=T+6U5QUbDp1mKi+8QBEviR4L9OlTIQZGNyeSbOtDgVk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OH/emFIeiKevMIyxoa3Jv2XCxh0hd3JUjdUuOSg5SsCgNWFIaMgm6DirG65s/qXtu QIoZ6evSQwJqk3AEFwIuJ+bBsh9Uhlv+ZEkSg8xq/AUwS/CzvXVsFu635KWQob4xfc rcwF/ojzv23O2r23f3qqu1pP50FNQ2u18Wega0JU= X-Authentication-Warning: weser.webweaving.org: Host fiber.static.cbizz.nl [185.142.248.117] (may be forged) claimed to be smtpclient.apple 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 16.0 \(3774.500.171.1.1\)) Subject: Re: Multicast & Tunnel devices From: Dirk-Willem van Gulik In-Reply-To: <202404291752.43THqS5l074359@gndrsh.dnsmgr.net> Date: Mon, 29 Apr 2024 21:03:06 +0200 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <8398E49B-629D-4199-BBF8-434E62AA36DB@webweaving.org> References: <202404291752.43THqS5l074359@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (weser.webweaving.org [148.251.234.232]); Mon, 29 Apr 2024 21:03:20 +0200 (CEST) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:148.251.0.0/16, country:DE] X-Rspamd-Queue-Id: 4VSyBJ2hWXz41s8 On 29 Apr 2024, at 19:52, Rodney W. Grimes = wrote: >>> On 29 Apr 2024, at 03:09, Rodney W. Grimes = wrote: >>>=20 >>>> Would anyone know if there is something special with tunnel devices = and multicast ?=20 >>>>=20 >>>> I?ve got some code that happily processes multicast packets on a = normal interface; but appears not to do this on a tunnel interface. Tun0 = shows multicast enabled: >>>> =09 >>>> tun0: flags=3D8043 metric 0 mtu = 1500 >>>>=20 >>>> Tcpdump on that interface gives the expected thing (here with = mDNS): >>>>=20 >>>> tcpdump -n -i tun0 port 5353 >>>> listening on tun0, link-type NULL (BSD loopback), capture size = 262144 bytes >>>> 19:26:03.976259 IP 10.31.0.6.5353 > 224.0.0.251.5353: 0 PTR = (QM)? _raop._tcp.local. (34) >>>>=20 >>>> And code, with a simple IP_ADD_MEMBERSHIP of the MC group on the = IP of the local interface below works on a normal interface (e.g. = igb0/10.0.0.1/24).=20 >>>>=20 >>>> ./listener 10.0.0.1 224.0.0.251 5353 >>>=20 >>> Is 10.0.0.1 the IP address of tun0, or is it the address of some = other interface? >>> I suspect that the IP address of the tun0 interface is 10.31.0.6 = from your tcpdump above. >>=20 >> That is correct 10.0.0.1/8. 10.31.0.6 is another machine at the other = end of the tunnel broadcasting. Thanks for your reply - it did make play with the several /30=E2=80=99s = aliases I was running in parallel on tun0. And found by accident that if I remove them - things spring to life. = Which is actually possible - as I can split the tun0 up into 8 separate = /24=E2=80=99s tunnels; one for each connection pair. With that - = IP_ADD_MEMBERSHIP does exactly what it says on the tin. Dw From nobody Mon Apr 29 22:16:58 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VSyP46WCPz5JyKG for ; Mon, 29 Apr 2024 22:17:12 +0000 (UTC) (envelope-from wlosh@bsdimp.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 4VSyP44V58z43nf for ; Mon, 29 Apr 2024 22:17:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-51acb95b892so6189404e87.2 for ; Mon, 29 Apr 2024 15:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1714429030; x=1715033830; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mNySv+uUrjebTettjux8qBQO6EUCmQdUsyyvUiDvhAo=; b=v612OmqeeIrPw6jCLFV+lArC0SIaVNDEaPmJgna7c4+d+f5ER+dfxWq9eSbVvUn7yB TtViK7N2NWTiP7COHT8hq9lHmX7mpE/GTXNhbCzMY4guafuh0PlJUX1le62C8bWk51yW hXb8fMnfdO2mXMOBXFLaTYB8VtI70r9TBlA0g8Uraut53tBADd9UkwGl+PFQdh5EQf9E Er9cSnmrsszVc6zIdkZpDNxZxgoV8oOEhLkJ0dhLJKz9Sv2agFBjU8AGF7DeTSnBX+8M 2FBaGeqzMfR4BWAxAFbhBSwqM0SBsSKEoztPBmwJ80jnyo0O8RaVbg3Y9C42DDmr8tB5 MsRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714429030; x=1715033830; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mNySv+uUrjebTettjux8qBQO6EUCmQdUsyyvUiDvhAo=; b=YmS2iQIiKclzAtjQwEGyqdIX8CXgOuN+AzsgeL8OEKRoJ87FkHNJSE+w9eDuzbkV+q 8q8R8hWjCvNbJ2fFF0AO13/t0Ez5M5aLLWMZ0e2wKWAdFwud5038fNBri6I98QsbXS4c bfqpj2/ERm7aAhMPHkAdnljBhvmorLtJN0mEm6q6hQq0IsqJAwEgEqBjSvq1RmkuXxYL FhSTsiNrjw49GEJpgXWD9qmkBTEx433UfTOSY+OpOdKz0FX0Ad9I9XkatBgBfWuMM0kE uYFpQKqSwKSCw6B8+zWKXBcn1vj3GW5NrSgLrMGgoYGUx4U0jkyOGsAFOy58mnfvZBfE IpKA== X-Forwarded-Encrypted: i=1; AJvYcCXpMNxb00Wi1dn+tFbjKB/deKvEcJ1xCSpmIL5C9SI22mf4NmV8PfxBx2IRNoJzi7CZF5cYhoLpsRONwt286xVkekfLwqY7hnkf3rg= X-Gm-Message-State: AOJu0YyP4lfziDHKzG6CYmuvUzboPoM+Gx43YwD6Gqx2lp5HFzufo1dd 84+s1+X63NBtHhEq4dqWCZrKcEB5Mb76djJbfeHMBVDyTOcfeiR18P1RfomxVDKoJCSj5yGpBK8 4Fk/CWfn0hg8UK6tjhoeB4ViiS+zMaGLRSMCB7e2LWPOj6pLHZ6U= X-Google-Smtp-Source: AGHT+IFmHydug+7Qc0MAzW3Nc8qhtiNudCYSenBNHrKdEK/tReqTt0A4w4QzJBPP/alEnTsGpD4+/5a9NP2NanMzVQ0= X-Received: by 2002:ac2:4c12:0:b0:515:cbf1:9fda with SMTP id t18-20020ac24c12000000b00515cbf19fdamr8614553lfq.61.1714429029921; Mon, 29 Apr 2024 15:17:09 -0700 (PDT) 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: Mon, 29 Apr 2024 16:16:58 -0600 Message-ID: Subject: Re: How to run tests without installing? To: Brooks Davis Cc: Christian Weisgerber , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000525a9b0617439d65" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VSyP44V58z43nf --000000000000525a9b0617439d65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2024 at 4:03=E2=80=AFPM Brooks Davis w= rote: > On Mon, Apr 29, 2024 at 12:34:51PM +0200, Christian Weisgerber wrote: > > How can I run the regression tests on my work-in-progress without > > installing it first? > > > > Say I'm changing something in sh. Can I run the tests on the > > compiled sh in /usr/obj, without having to install my potentially > > broken work into the system? Running "make tests" in src/bin/sh > > doesn't seem to actually test anything. > > Generally speaking you can't. This is one of the problematic things > about the current test framework. The best you can do for something > like sh where you really don't want to install a broken one is probably > installing in a jail and running tests there. > For library tests, though, you can run the individual test just like kyua would, but all bets are off if it relies on anything other than the code in the binary (and associated shared libraries). Even then, it's a royal pain. I usually stop one step short of a jail when I've needed to do this: I just make installworld DESTDIR=3D$HOME/mumble and then do sudo chroot $HOME/mumble. Though it doesn't work at all well for some tests (they hate being run in a chroot), but they tend to be networking tests anyway... But the same tests that don't work well in a chroot work even less well in a jail. There's a crazy lot of them that require different /dev/ entries, which is why I don't do the chroot thing that often... tl;dr: It's easier not to test, and that's actually a problem. Warner --000000000000525a9b0617439d65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 29, 2024 at 4:03=E2=80=AF= PM Brooks Davis <brooks@freebsd.or= g> wrote:
On Mon, Apr 29, 2024 at 12:34:51PM +0200, Christian Weisgerber wrote:
> How can I run the regression tests on my work-in-progress without
> installing it first?
>
> Say I'm changing something in sh.=C2=A0 Can I run the tests on the=
> compiled sh in /usr/obj, without having to install my potentially
> broken work into the system?=C2=A0 Running "make tests" in s= rc/bin/sh
> doesn't seem to actually test anything.

Generally speaking you can't.=C2=A0 This is one of the problematic thin= gs
about the current test framework.=C2=A0 The best you can do for something like sh where you really don't want to install a broken one is probably=
installing in a jail and running tests there.

For library tests, though, you can run the individual test just like= kyua
would, but all bets are off if it relies on anything other = than the code in
the binary (and associated shared libraries). Ev= en then, it's a royal
pain.

I usuall= y stop one step short of a jail when I've needed to do this:
= I just make installworld DESTDIR=3D$HOME/mumble and then do
sudo = chroot $HOME/mumble. Though it doesn't work at all well
for s= ome tests (they hate being run in a chroot), but they tend to
be = networking tests anyway... But the same tests that don't work
well in a chroot work even less well in a jail. There's a crazy lot
of them that require different /dev/ entries, which is why I don= 9;t do
the chroot thing that often...

tl= ;dr: It's easier not to test, and that's actually a problem.
<= div>
Warner
--000000000000525a9b0617439d65-- From nobody Tue Apr 30 19:07:09 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VTV7N5m9mz5JlQ2 for ; Tue, 30 Apr 2024 19:07:12 +0000 (UTC) (envelope-from concussious@runbox.com) Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [IPv6:2a0c:5a00:149::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VTV7N16sgz47hW for ; Tue, 30 Apr 2024 19:07:12 +0000 (UTC) (envelope-from concussious@runbox.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=runbox.com header.s=selector2 header.b=QR4K3517; dmarc=pass (policy=quarantine) header.from=runbox.com; spf=pass (mx1.freebsd.org: domain of concussious@runbox.com designates 2a0c:5a00:149::25 as permitted sender) smtp.mailfrom=concussious@runbox.com Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1s1soo-000b3p-CF for freebsd-hackers@FreeBSD.org; Tue, 30 Apr 2024 21:07:10 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=selector2; h=Message-Id:Date:Subject:To:From:MIME-Version: Content-Transfer-Encoding:Content-Type; bh=9h8mUZPN5LJFiW2JjLNyzOyI5bgo1ZroOIteY4nIt6Q=; b=QR4K3517G1tb0RngVCcysNyN7Z UNm4EEnxtzCJGQ/WnSKQLytCoxpPiutut9okjfQHyHHxGO/rJ6dlpmDjmJe3LMb8T5h0obQ9D7G9D NAr4FYwiJutlh92ui6H2t2kUzWuiFU4k2dGGqiFpFY5lSyr96BOtEGAapTTHmNj4u66WRalrUM6qd SqLkFK8F/+L2FzZdQzgzE6v+yJAwxSRXukwMnZyh0fGcGL9ryivcqq9+iXAwdnFBXJiOA9NjboGfQ H9+Ad+Zl9++1Du8/p+ST1cklMmbBuyRqklBRIQsWIpwXXPfAGIUHJ01Yg3UC3b8Yt3u7XkyGHojZk V1TvVpKg==; Received: from [10.9.9.129] (helo=rmmprod07.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1s1son-0008Ku-Ii for freebsd-hackers@FreeBSD.org; Tue, 30 Apr 2024 21:07:09 +0200 Received: from mail by rmmprod07.runbox with local (Exim 4.86_2) (envelope-from ) id 1s1son-0007im-H0 for freebsd-hackers@FreeBSD.org; Tue, 30 Apr 2024 21:07:09 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline 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 Received: from [Authenticated alias (960610)] by runbox.com with http (RMM6); for ; Tue, 30 Apr 2024 19:07:09 GMT From: "Alexander Ziaee" To: "freebsd-hackers" Subject: Re: FreeBSD hardware support Date: Tue, 30 Apr 2024 19:07:09 +0000 (UTC) X-RMM-Aliasid: 960610 X-Mailer: RMM6 Message-Id: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.05 / 15.00]; FAKE_REPLY(1.00)[]; DWL_DNSWL_LOW(-1.00)[runbox.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.95)[-0.954]; DMARC_POLICY_ALLOW(-0.50)[runbox.com,quarantine]; R_DKIM_ALLOW(-0.20)[runbox.com:s=selector2]; R_SPF_ALLOW(-0.20)[+ip6:2a0c:5a00:149::25]; RCVD_IN_DNSWL_LOW(-0.10)[2a0c:5a00:149::25:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[runbox.com]; FREEMAIL_FROM(0.00)[runbox.com]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[runbox.com:+] X-Rspamd-Queue-Id: 4VTV7N16sgz47hW Sir, The form is no longer accepting responses after 21 days. I think there are = others like me who would be interested in replying, but only read the maili= ng list archives once every few weeks. Would you be willing to reopen it? Thanks, Alexander Ziaee= From nobody Wed May 1 00:59:38 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VTdy760WKz5HmM7 for ; Wed, 1 May 2024 00:59:43 +0000 (UTC) (envelope-from grog@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 4VTdy75Wb3z4q35; Wed, 1 May 2024 00:59:43 +0000 (UTC) (envelope-from grog@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714525183; 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=KNefiwGAo17rmLnuefWpZL5ztiby7BdjV51Xs2rwnxk=; b=n3NjVNgq2LsPjResaJbTRmhd4i+3gEmIE8sH0dwBaxo0Te3fYicUB0C+30BjLFv/b6nssu SCl0GK6zKaaPgUwDOuGrBOjdaCRimRwYcLheKh/3Duvw+JyXskfprpqGnLIfRJuetNFYet znAPZk5yadYdp1EGXBs3Ayqgh/E1NnDyTVGr39McihvvgVBr6ArEYbbTvCRZTn/jb93o0z QDkACHv7kz+ryPRqVDNgSWVpgWmtRkS/3u22DctjH05dMOtg+Jpaeo+4UICkdO5NBpb4d8 FB5ez1H29v3VyTYZYdxjtF4AEPYDZi5h7R0XgVazAmwaFdoJAqXSPbBPArcZFQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1714525183; a=rsa-sha256; cv=none; b=C68AURg2XwWI0QTBNUByujjTs3P7gD3zVdm8oMH2MFF4MLyAQi9mNL9MDkitLgomCEd8D2 //A0egJvha9wg0UDciFZ7iI4avFvGtMz/nZZMcoSoBVLeAQ8aR3oNr8ynkPmqtB6nWuXfZ cjbs6I/ffQ9mSNnt22lUOYwpx9NI9D2dnw+1keMmsIklbCUCW9l8ZcrcH8v/WBLsGOGqKw bniw24UplrjrEGxcQKOd0+pXCZ68YWwB6i4gcjT0/XcR7npfLRMPOJ5J0uyBOA6GM/HefD twH6rFE64YOVjx36nmR9CyOSlZGGdl7WbjF+xR1LO+9iqdy0hHSK70Kj/MyADg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714525183; 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=KNefiwGAo17rmLnuefWpZL5ztiby7BdjV51Xs2rwnxk=; b=DikaOEoIrWZvpXVMyY1NQMbyInLacqDW8uYk/A6cGkzLaJkuuFCX0vhRFLLy6ZGKMgxpvA 0O+50J9JLI8/bmKWjLQZCuBdhzXexCQH3x95+5LSiZXNghaNcHV3hX9+tYud0mdHdSrn98 PfsxnybHYgQ8l0eNL7vGjZiQW+osX0D07U3WlmL25/yxtemlc4QXSdLDQ7vR+P1Tsg8Di4 qqqTnMdKo4Q40Ep9M+WmNAAskGyjCOlzipanV5i9/QZm1Q+GQ8MPNRaIcltVcj+KRJoNz4 yulvOZekhLr4gn2XekGz575MDBFtdGjRnd1vtkCLyKapdBVOATGHsCgvs5UOKw== Received: from hydra.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grog/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VTdy64LB3zGFy; Wed, 1 May 2024 00:59:42 +0000 (UTC) (envelope-from grog@freebsd.org) Date: Wed, 1 May 2024 10:59:38 +1000 From: Greg 'groggy' Lehey To: Alexander Ziaee Cc: freebsd-hackers Subject: Re: FreeBSD hardware support 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="31V1NBbo7hg51NS3" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 --31V1NBbo7hg51NS3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 30 April 2024 at 19:07:09 +0000, Alexander Ziaee wrote: > The form is no longer accepting responses after 21 days. I think > there are others like me who would be interested in replying, but > only read the mailing list archives once every few weeks. Would you > be willing to reopen it? Sorry, I don't know what you're talking about. There's no reference to anything, and it's not clear what you mean by "the form". If you want, reply just to me with more information and I'll see what I can do. I'll copy hackers@ if there's anything to interest the group. 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 --31V1NBbo7hg51NS3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSaG4ICvM64RvkvCawi5vKQUHpCIwUCZjGT+gAKCRAi5vKQUHpC I7zOAJwLDffODR3UNv4ExpEGkTgKW3SEswCfd+/mGNVQDWhFahAZfURz8tjPOV8= =jWFK -----END PGP SIGNATURE----- --31V1NBbo7hg51NS3-- From nobody Wed May 1 08:33:50 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VTr2H4VlGz5JSPL for ; Wed, 1 May 2024 08:33:59 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (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 4VTr2H1lT5z4YwB; Wed, 1 May 2024 08:33:58 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lorenzosalvadore.it; s=protonmail; t=1714552435; x=1714811635; bh=fSTeQ2uRXysHG2w7zDEe1BNraLo0qVFrnvQiS3j8drY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=qmcZI+VhnIAlMv9LnJ7LCrlPByGmGni6hFy7GXZ40QwWut+nhbkV8KvOTN0uiPbOO D25Eu3ronSPWb1bdsXBQ+pTS8NfVGxmr62PGh4vBqNn8vDxSsZt0IIt/kzkJKl0MYG +kI5e3DL5h8verujsT7G+TQ1V5OhAdX8d5ESdV1+ldYdZ4t5THCJRnnVaU6A6OR/eb hLAtvjz81TeJ5F/EzeT1j4glN34KtjY3Q0Pv5qLAMwplzO4tcNO9OmrVphNRDASjg3 ENtuhfASLqSR+3Nmw7MRC1bwauzCtamQSa8slRtSchnG1HVjQStP4ERYGZ/KWhSh1u pxNPLDOe0PzDw== Date: Wed, 01 May 2024 08:33:50 +0000 To: Greg 'groggy' Lehey From: Lorenzo Salvadore Cc: Alexander Ziaee , freebsd-hackers , "greg@freebsdfoundation.org" Subject: Re: FreeBSD hardware support Message-ID: In-Reply-To: References: Feedback-ID: 53711648:user:proton X-Pm-Message-ID: 521913167211ec48d933b8735022d19be2b00c3d 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-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Queue-Id: 4VTr2H1lT5z4YwB On Wednesday, May 1st, 2024 at 02:59, Greg 'groggy' Lehey wrote: >=20 >=20 > On Tuesday, 30 April 2024 at 19:07:09 +0000, Alexander Ziaee wrote: >=20 > > The form is no longer accepting responses after 21 days. I think > > there are others like me who would be interested in replying, but > > only read the mailing list archives once every few weeks. Would you > > be willing to reopen it? >=20 >=20 > Sorry, I don't know what you're talking about. There's no reference > to anything, and it's not clear what you mean by "the form". If you > want, reply just to me with more information and I'll see what I can > do. I'll copy hackers@ if there's anything to interest the group. >=20 > Greg I guess he is talking about this: https://lists.freebsd.org/archives/freebsd-hackers/2024-April/003151.html I am adding Greg Wallace to CC since he posted the first message in the thread. Cheers, Lorenzo Salvadore From nobody Wed May 1 10:48:53 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VTv2D1y3rz5Jdss for ; Wed, 1 May 2024 10:49:08 +0000 (UTC) (envelope-from greg@freebsdfoundation.org) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VTv2D092yz4mKW for ; Wed, 1 May 2024 10:49:08 +0000 (UTC) (envelope-from greg@freebsdfoundation.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1eca195a7c8so2268765ad.2 for ; Wed, 01 May 2024 03:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsdfoundation.org; s=gfnp-20170908; t=1714560546; x=1715165346; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2mWg5SrjkctirbCMZPwr1nmHyrgTdYMuWkfmX6wf72U=; b=YZXaF/KL1OqnU93lpmCS98jmg3KttkEt4qU2soo/Ec9jfu64pBLAdHUoyR9U69GWfA NhGZhs787i/thtswMf8xsFEzK++l+ODjMvAJTITHzEN32ubUbfa2N38JTQarQG2NnuDm dilrqcTuQCRoE6YP0gVN9gXGHZSf/qq+b2xHeiQnjnDKLx4KX0zHWrw0kXzoBU2OQClx TP5hpgQyXaWHDmkIBPnzLHXqbWwVO1aWr8jsUFm3inujn4iriUcUs2pzpeb26EZRihwP vMmUNXPihaqNjn5sJP8OCT8zSVg+BaPQ5zhIu0PVfKa7COmL3nu5q2OcwKnaWLE4ooWn 7Ejg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714560546; x=1715165346; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2mWg5SrjkctirbCMZPwr1nmHyrgTdYMuWkfmX6wf72U=; b=JI59gzGsdemlF5QIyFfYvNWCa9D8iQa1t/PFswGW1fYXkYdT9/D+m6GmBT+gN/A5qI BvBwfHdyNfhxPV3mnoXIHEPGgJcaR3pgAcGGVTWpl1xkGYdv+sKo9YFLaIVUg0Yeps4U x0a6ddWfPH7nSCJcPK6YSSGPm9ixNRzAB/ZRBVpKbNPTA6UCsXBcG7YWgHOYMk/kNGY7 r7wIAg4FLJoFWA/N0XQAkRmuOIMNdwLbvLHVWFsNtU5SV2BcjHtQHCpuETi1ePyO3KIc LGUUlILuhJebX90Seeqdh/862fIxnfhF8n9In1u6qvKZUQkGsULKkjYkzTz4HUQCIYSa t7yQ== X-Forwarded-Encrypted: i=1; AJvYcCWQ/dyq78w103LvXk8nbPvMOMQDSdq4UFn6yiIAemUGy1F1cDS2pHlHmNkknaJdT03gc10NITaCgVNEa8v8BCqrmcg0/NLUzaEGzpQ= X-Gm-Message-State: AOJu0YzIOGrhaABk5vE0rN+4u0w3xxtzso1R+qGDdBYi9L7/95CVONSx iyRAfKa6qbjXfpyzVFpnA0aNc92Y5aX8zVQjh44VA6XJnncCQVKrQYirYdapbVEDGhSaso7gkcb H1TQ5xYBy00qoBP7nJLgYRVwhxcO2LYyWBATVbZLb X-Google-Smtp-Source: AGHT+IHnzQJenFVWAj/4m6HPB6eHeLnLhIKqz+EbNU1sH3bZKcSVHV7BRNbFpGlupuAc+tszE9F/druF3PSPmjktBbw= X-Received: by 2002:a17:90b:344f:b0:2a4:b9db:acf5 with SMTP id lj15-20020a17090b344f00b002a4b9dbacf5mr1636636pjb.24.1714560545981; Wed, 01 May 2024 03:49:05 -0700 (PDT) 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: Greg Wallace Date: Wed, 1 May 2024 06:48:53 -0400 Message-ID: Subject: Re: FreeBSD hardware support To: Lorenzo Salvadore Cc: "Greg 'groggy' Lehey" , Alexander Ziaee , freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000004a237f0617623c1c" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4VTv2D092yz4mKW --0000000000004a237f0617623c1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks! I re-opened it =F0=9F=93=8A Greg On Wed, May 1, 2024, 4:33 AM Lorenzo Salvadore < developer@lorenzosalvadore.it> wrote: > On Wednesday, May 1st, 2024 at 02:59, Greg 'groggy' Lehey < > grog@freebsd.org> wrote: > > > > > > > On Tuesday, 30 April 2024 at 19:07:09 +0000, Alexander Ziaee wrote: > > > > > The form is no longer accepting responses after 21 days. I think > > > there are others like me who would be interested in replying, but > > > only read the mailing list archives once every few weeks. Would you > > > be willing to reopen it? > > > > > > Sorry, I don't know what you're talking about. There's no reference > > to anything, and it's not clear what you mean by "the form". If you > > want, reply just to me with more information and I'll see what I can > > do. I'll copy hackers@ if there's anything to interest the group. > > > > Greg > > I guess he is talking about this: > > https://lists.freebsd.org/archives/freebsd-hackers/2024-April/003151.html > > I am adding Greg Wallace to CC since he posted the first message in > the thread. > > Cheers, > > Lorenzo Salvadore > --0000000000004a237f0617623c1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks!

I re= -opened it=C2=A0 =F0=9F=93=8A

Greg

On Wed, May 1, 2024, 4:33 AM Lorenzo Salvadore <developer@lorenzosalvadore.it= > wrote:
On Wednesday, May 1st, = 2024 at 02:59, Greg 'groggy' Lehey <grog@freebsd.org> wrote= :

>
>
> On Tuesday, 30 April 2024 at 19:07:09 +0000, Alexander Ziaee wrote: >
> > The form is no longer accepting responses after 21 days. I think<= br> > > there are others like me who would be interested in replying, but=
> > only read the mailing list archives once every few weeks. Would y= ou
> > be willing to reopen it?
>
>
> Sorry, I don't know what you're talking about. There's no = reference
> to anything, and it's not clear what you mean by "the form&qu= ot;. If you
> want, reply just to me with more information and I'll see what I c= an
> do. I'll copy hackers@ if there's anything to interest the gro= up.
>
> Greg

I guess he is talking about this:

https://lists.fr= eebsd.org/archives/freebsd-hackers/2024-April/003151.html

I am adding Greg Wallace to CC since he posted the first message in
the thread.

Cheers,

Lorenzo Salvadore
--0000000000004a237f0617623c1c-- From nobody Wed May 1 23:00:53 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VVCGh4c3Cz5KCqy for ; Wed, 1 May 2024 23:01:00 +0000 (UTC) (envelope-from grog@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VVCGh490Gz4yG3; Wed, 1 May 2024 23:01:00 +0000 (UTC) (envelope-from grog@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714604460; 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; bh=vo0y1no6OpltSND6wvMFXpEDhRoHcIFYFqq2djfr4pE=; b=mWUyB90wmY5woro349/jrXPPa5dz5kRMiExVRcAhViFWiqVxewY8i8YPKyl6W3osjlERew +j+L2Zk8NoGdilP0cOTpR+Ms3KySrWVz2C6DOMMMPuV2JCh3DcrX759TZv71mFpVAi/lfR 3B95jXt8COw3x2KLUev+fRdeWxzj1eAKTXtUXeS8jGxfoJGNiIkvmNB0RcdPHnbtyghzWG 7h8sR+niAE0zhGrDtvaym3FGWxEP9mazplgYbCQAtKfrO9/bkNl1LJDzVBuMN5gQl/rqUu PTsJRAEfK+9+PsW4wEwXQSBdrazb8cU9wjm9+mzW8ZwPDt5TxVX0XcUu4P1wfw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1714604460; a=rsa-sha256; cv=none; b=KanXZIGu0NS+LJnvCTOLvKVNJKk2TH9CedpmJjp3O3TB87LP0Fnz4k8cdh7+HQwHyrYPl5 xKG3ACJYuW4DTIG4Iuueeet/8YMCY/s5LcLOaQ6wkooxEFOCiet5LhlyaFpSKjbpM87Zqg XjgDqupPDmgi1/WxdaBoEO1NnSJOyCCKCGhUjDTbpNDYh/mK+mAO0/pX6CEqx4P9p0Aebx shya8Bk9Z4s53IGgRNBXoHg+CRvENxvf7s5neDyGcGUI7kqSA11YBoVe3l9exas4aO9m+A EidpQFJyOnDRjmlS3Cz0VPDAh7OfS/hqDPZgxD5W+9AwZkawMwcy86jkLDzAdw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714604460; 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; bh=vo0y1no6OpltSND6wvMFXpEDhRoHcIFYFqq2djfr4pE=; b=ZReYZIsOjNUkKwjudBmSWlbpcGm74MKOB48JrQ46wNc7Zc4H6Mt/wxCVQCeU/N4i4XV/9l hDTt0v6udYjLd8n5kOug1RPbXJ2BrtcN38uTeQ8SFhLiO9E1Z9qqvemW8818yKZ87CGOwL zB61JQNFu65HcIEGfbhHOkfrtb3vrjNSYGaJ9Oa+x+PfA6UPLYhmL0QAJEpgZ0M4BwNI0m 09427XEODwaL5FLJoAYwVHT5Z22vHsVils6wj8cPPW8U3fr+xawiyNYRCov6RkTTpobrQ+ hwsOuEh3+U44iC2gqN+jrrnMvi5fOhuL6o/gSWnGmtMqt2wtyWD4Q5fdKOpfkg== Received: from hydra.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grog/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VVCGf6HbxzjTZ; Wed, 1 May 2024 23:00:58 +0000 (UTC) (envelope-from grog@freebsd.org) Date: Thu, 2 May 2024 09:00:53 +1000 From: Greg 'groggy' Lehey To: Lorenzo Salvadore , Greg Wallace Cc: Alexander Ziaee , freebsd-hackers Subject: Re: FreeBSD hardware support 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/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oe3y4LQCBfAZ4q8L" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 --oe3y4LQCBfAZ4q8L Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wednesday, 1 May 2024 at 8:33:50 +0000, Lorenzo Salvadore wrote: > On Wednesday, May 1st, 2024 at 02:59, Greg 'groggy' Lehey wrote: >> On Tuesday, 30 April 2024 at 19:07:09 +0000, Alexander Ziaee wrote: >> >>> The form is no longer accepting responses after 21 days. I think >>> there are others like me who would be interested in replying, but >>> only read the mailing list archives once every few weeks. Would you >>> be willing to reopen it? > > I guess he is talking about this: > > https://lists.freebsd.org/archives/freebsd-hackers/2024-April/003151.html Yes, that's right. We established it offline. > I am adding Greg Wallace to CC since he posted the first message in > the thread. On Wednesday, 1 May 2024 at 6:48:53 -0400, Greg Wallace wrote: > Thanks! > > I re-opened it =F0=9F=93=8A Oh. That must have been fast. I tried it, and "it worked for me". In any case, it seems that the matter is over. Thanks for the feedback. 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 --oe3y4LQCBfAZ4q8L Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSaG4ICvM64RvkvCawi5vKQUHpCIwUCZjLJpQAKCRAi5vKQUHpC I5A3AJ9TutwMKiEiMIDArpIFZPPQOsttggCgtYG+2dRL+/95QPI82i/NeC6X9cA= =FajV -----END PGP SIGNATURE----- --oe3y4LQCBfAZ4q8L-- From nobody Thu May 2 06:10:24 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VVNpV1W6kz5JMt4 for ; Thu, 2 May 2024 06:10:42 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (syn-024-097-005-251.biz.spectrum.com [24.97.5.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VVNpT2gFhz4L3k for ; Thu, 2 May 2024 06:10:41 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@crossfamilyweb.com designates 24.97.5.251 as permitted sender) smtp.mailfrom=david@crossfamilyweb.com X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from [10.1.7.155] (d155.p9.wifi.dcrosstech.com [10.1.7.155]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 4426AObR052951 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 2 May 2024 06:10:24 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d155.p9.wifi.dcrosstech.com [10.1.7.155] claimed to be [10.1.7.155] Message-ID: Date: Thu, 2 May 2024 02:10:24 -0400 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:102.0) Gecko/20100101 Thunderbird/102.15.0 Content-Language: en-US To: FreeBSD Hackers From: "David E. Cross" Subject: Review request (D45056) adding O_DIRECT support for ggated/ggatec Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.15 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.951]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US]; RCVD_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[david]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[crossfamilyweb.com]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4VVNpT2gFhz4L3k I wrote up a patch at: https://reviews.freebsd.org/D45056 for adding O_DIRECT support for ggated/ggatec. I have found it to be very useful when exporting poudriere build images from my NAS to not have it trash the fscache on the machine. (Would love to have it in 14.1) Thanks! From nobody Thu May 2 08:13:56 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VVRYR3fZ7z5JY7y; Thu, 2 May 2024 08:14:35 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 4VVRYQ53LBz4YK0; Thu, 2 May 2024 08:14:34 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=HrZwOD9D; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) smtp.mailfrom=marietto2008@gmail.com Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2b3374e08cfso870631a91.2; Thu, 02 May 2024 01:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714637673; x=1715242473; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZD8A6fWL1kBPGPCaQrxJsjZxlU+dEyIeItOEFk2lHBw=; b=HrZwOD9D5XWhqd79WvuSeF6AuOsV+iys4BqlNzPX5vKBYZDTdmEKDZimi4GbNqcv8p FvfR4Qcb1guZm4hfSyFaRzkAXUv/4oq5x/MjYt3IRliTC0FoG/2ioZgJaBgqN33Yow4f 0JVhsAYvcYlDnL3hRvjVBjIgBBOeG+yVs2tlNjcW+xL1TxfNRmVncnAYDezf5rl9Ad8X 64pmh9JaGKBmm5CgyCMoqaJ1Rpr+Q3DoqKXHYg6P2udivasWMq8wIaYvRRI8TboBCb0s qymSEI8tWvMSpMVv0a3u0jd1LCsQuyuP57HywaOqQMpQO563nvh8BFJy8K36UlEgEH5p zrTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714637673; x=1715242473; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZD8A6fWL1kBPGPCaQrxJsjZxlU+dEyIeItOEFk2lHBw=; b=bb3FsuA5KxqZcKTG4a9wZ6QRa+AuP4221hKcPU/E+PlrBgM0OWxPCLZ239dHHoQmI3 WImHfa5PcjiJckfJnnTvgCzLrGBjs1Ew+ZloRAy+9zEYrL6f4HXiJEPHu7B34Le0KAPL etBJZAyKNW93nANZSwBm5DQ6Jts8BKCycy0CfLnb/NQSEhaTSfGgcEYasukYfUHAFruq E2+EBPtz2blsiWDskTh2x2QPrIfr14wC7TAYD7FDghmosvQ+ls+1wPcDcTeN6hU/Et+u Z5LYkt4cxiXaZpQyD5I9G+6ER0qMVod/jBCHVyhIpDJQLKQ4e4gbErxhBN093Jwu5Tbh JVHg== X-Forwarded-Encrypted: i=1; AJvYcCXKAeEoHhNJZnxNAu8UynutXbBHVjRxY0LM0L51bEvvb8oY8jilBZaPKekR/4cyCTQBvjepiFaAFSsBGR+Q/Y9m6fPqzZtXRjzhAZgFSD2Xxd3Z5YzJuLA+IIGBsccxqKHTx7vDLGIXMX6k+pHX1gBtHJ0g7HY5VfBe7fWtdl3TAGqXynTP5EFvYOtK8U34u0mBUmkqaPvECRetqGnQYuoVLTPqV+IZYQ== X-Gm-Message-State: AOJu0YzTYPoC1vG+5Q83vPCtTPTkKZxrcWgXh5Be+xAimWN72y9sNFhQ c7FHBLei3msIT24u9i2QHhMTA24nhgr2jeFQf/1ruzyVgqlU110D7vqrTA+TAHi6u2wql+dL+hD Oe4uuwsKYZVyD1smxvSEJL5EcHCLSVeMFv/Alog== X-Google-Smtp-Source: AGHT+IF71bsubqvkmbYg2dhtTKk6iYUomrtDuoKJIHwNZS9oKLenUnMVZ7aI57BJih4puCPXqQCaPsBcuuCzzXv+sZE= X-Received: by 2002:a17:90b:4c4c:b0:2ac:f010:b1c0 with SMTP id np12-20020a17090b4c4c00b002acf010b1c0mr5189757pjb.22.1714637673241; Thu, 02 May 2024 01:14:33 -0700 (PDT) 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: Mario Marietto Date: Thu, 2 May 2024 10:13:56 +0200 Message-ID: Subject: Re: How to use Virtio GPU on FreeBSD as guest OS. To: Yusuf Khan Cc: freebsd-drivers@freebsd.org, freebsd-x11@freebsd.org, freebsd-hackers , FreeBSD Mailing List , FreeBSD virtualization Content-Type: multipart/alternative; boundary="0000000000006ea444061774319f" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102c:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-drivers@freebsd.org,freebsd-x11@freebsd.org,freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org,freebsd-virtualization@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4VVRYQ53LBz4YK0 --0000000000006ea444061774319f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What I find strange is that this configuration works on Windows 11 to virtualize FreeBSD using -device vmware-svga : I:\OS\vms\qemu\qemu-system-x86_64w.exe -accel whpx -machine q35 -cpu kvm64,hv_relaxed,hv_time,hv_synic -m 8G -device vmware-svga,id=3Dvideo0,vgamem_mb=3D16,bus=3Dpcie.0,addr=3D0x1 -audiodev dsound,id=3Dsnd0 -device ich9-intel-hda -device hda-duplex,audiodev=3Dsnd0 = -hda "I:\Backup\FreeBSD\FreeBSD-140-zfs.img" -device hda-duplex,audiodev=3Dsnd0 -drive file=3D\\.\PhysicalDrive4 -drive file=3D\\.\PhysicalDrive5 -drive file=3D\\.\PhysicalDrive6 -drive file=3D\\.\PhysicalDrive8 -drive file=3D\\.\PhysicalDrive12 -rtc base=3Dlocaltime -device usb-ehci,id=3Dusb,bus=3Dpcie.0,addr=3D0x3 -device usb-tablet -device usb-kb= d -smbios type=3D2 -nodefaults -netdev tap,id=3Dmynet0,ifname=3D"OpenVPN-TAP-Windows",script=3Dno,downscript=3Dno = -device e1000,netdev=3Dmynet0,mac=3D52:55:00:d1:55:01 -device ich9-ahci,id=3Dsata -= bios "I:\OS\vms\qemu\OVMF_combined.fd" One can think that it will work even on Linux for the same setup (qemu + hyper-V on Windows 11),but it does not. I'm experiencing a lot of problems when I add -accel whpx on a Debian VM. These problems go away if I remove it. Adding " -device vmware-svga,id=3Dvideo0,vgamem_mb=3D16,bus=3Dpcie.0,addr= =3D0x1" to the qemu / Debian parameters will cause it won't boot. So,this : I:\OS\vms>I:\OS\vms\qemu\qemu-system-x86_64.exe -machine q35 -cpu kvm64,hv_relaxed,hv_time,hv_synic -m 8G -device vmware-svga,id=3Dvideo0,vgamem_mb=3D16,bus=3Dpcie.0,addr=3D0x1 -audiodev dsound,id=3Dsnd0 -device ich9-intel-hda -device hda-duplex,audiodev=3Dsnd0 = -hda "I:\Backup\Linux\Debian.img" -drive file=3D\\.\PhysicalDrive5 -drive file=3D\\.\PhysicalDrive6 -drive file=3D\\.\PhysicalDrive8 -rtc base=3Dloca= ltime -device usb-ehci,id=3Dusb,bus=3Dpcie.0,addr=3D0x3 -device usb-tablet -devic= e usb-kbd -smbios type=3D2 -nodefaults -netdev user,id=3Dnet0 -device e1000,netdev=3Dnet0,id=3Dnet0,mac=3D52:54:00:11:22:33 -device ich9-ahci,id= =3Dsata -bios "I:\OS\vms\qemu\OVMF_combined.fd" will cause the Debian VM to freeze before reaching the login prompt. I don't know if Linux has the proper vmware-svga driver,I didn't find it. Regarding virtualizing Windows 7 on Windows 11 using the same setup,I can't add -accel whpx and most importantly,what I care more, the -device vmware-svga does not work. So,in this kind of setup, *FreeBSD is the winner because it supports everything (hyper-V and the vmware-svga 3D accelerated device.* On Sat, Apr 27, 2024 at 9:41=E2=80=AFPM Yusuf Khan wrote: > So your issue is that the performance is worse than Linux? > > There is no 3d graphics driver for virtio in mainline drm-kmod but > https://github.com/freebsd/drm-kmod/pull/119 has > experimental support, although that PR exists it seems to be > non-functional with a crash. > --=20 Mario. --0000000000006ea444061774319f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What I find strange is that this configuration works on Windo= ws 11 to virtualize FreeBSD using=20 -device vmware-svga :

I:\OS\vms\qemu\qemu-syst= em-x86_64w.exe -accel whpx -machine q35 -cpu kvm64,hv_relaxed,hv_time,hv_sy= nic -m 8G -device vmware-svga,id=3Dvideo0,vgamem_mb=3D16,bus=3Dpcie.0,addr= =3D0x1 -audiodev dsound,id=3Dsnd0 -device ich9-intel-hda -device=20 hda-duplex,audiodev=3Dsnd0 -hda "I:\Backup\FreeBSD\FreeBSD-140-zfs.img= " -device hda-duplex,audiodev=3Dsnd0 -drive file=3D\\.\PhysicalDrive4 -drive= =20 file=3D\\.\PhysicalDrive5 -drive file=3D\\.\PhysicalDrive6 -drive=20 file=3D\\.\PhysicalDrive8 -drive file=3D\\.\PhysicalDrive12 -rtc=20 base=3Dlocaltime -device usb-ehci,id=3Dusb,bus=3Dpcie.0,addr=3D0x3 -device = usb-tablet -device usb-kbd -smbios type=3D2 -nodefaults -netdev tap,id=3Dmy= net0,ifname=3D"OpenVPN-TAP-Windows",script=3Dno,downscript=3Dno -= device e1000,netdev=3Dmynet0,mac=3D52:55:00:d1:55:01 -device ich9-ahci,id= =3Dsata -bios "I:\OS\vms\qemu\OVMF_combined.fd"

One can think that it will work even on Linux for the same setup (qemu +=20 hyper-V on Windows 11),but it does not. I'm experiencing a lot of=20 problems when I add -accel whpx on a Debian VM. These problems go away=20 if I remove it.

Adding " -device vmware-svga,id=3Dvideo0,vgamem_mb=3D16,bus=3Dpcie.0,addr=3D0x1&quo= t; to the qemu / Debian parameters will cause it won't boot. So,this :<= /div>


I:\OS\vms>I:\OS\vms\qemu\qemu-sy= stem-x86_64.exe -machine q35 -cpu kvm64,hv_relaxed,hv_time,hv_synic -m 8G -= device vmware-svga,id=3Dvideo0,vgamem_mb=3D16,bus=3Dpcie.0,addr=3D0x1 -audiodev dsound,id=3Dsnd0 -device ich9-intel-hda -device=20 hda-duplex,audiodev=3Dsnd0 -hda "I:\Backup\Linux\Debian.img" -dri= ve=20 file=3D\\.\PhysicalDrive5 -drive file=3D\\.\PhysicalDrive6 -drive=20 file=3D\\.\PhysicalDrive8 -rtc base=3Dlocaltime -device=20 usb-ehci,id=3Dusb,bus=3Dpcie.0,addr=3D0x3 -device usb-tablet -device=20 usb-kbd -smbios type=3D2 -nodefaults -netdev user,id=3Dnet0 -device=20 e1000,netdev=3Dnet0,id=3Dnet0,mac=3D52:54:00:11:22:33 -device ich9-ahci,id= =3Dsata -bios "I:\OS\vms\qemu\OVMF_combined.fd"


will cause the Debian VM to freeze before reaching the login prompt. I=C2=A0=20 don't know if Linux has the proper vmware-svga driver,I didn't find= it.

Regarding virtualizing Windows 7 on Windows 11 using the same setup,I can't add -accel whpx and most= =20 importantly,what I care more, the=20 -device vmware-svga does not work. So,in this kind of setup,FreeBSD is= =20 the winner because it supports everything (hyper-V and the vmware-svga 3D a= ccelerated device.
<= /div>


On Sat, Apr 27, 2024 at 9:41=E2=80=AFPM Yusuf= Khan <yusisamerican@gmail.co= m> wrote:
So your issue is that the performance is worse than Linux?

There is no 3d graphics driver for virtio in mainline drm-kmod but
https://github.com/freebsd/drm-kmod/pull/119 has
experimental support, although that PR exists it seems to be
non-functional with a crash.


--
Mario.
--0000000000006ea444061774319f-- From nobody Sun May 5 15:38:51 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VXTGg27qrz5K92Z; Sun, 05 May 2024 15:38:51 +0000 (UTC) (envelope-from salvadore@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 4VXTGg1WFGz4pWr; Sun, 5 May 2024 15:38:51 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714923531; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nSdiKnkC3LQt7iFoMEGzkBmhnqhFIumekTHiIgdVbmQ=; b=gZwiuj07MaPIgDJRCUaGo8jQPYwkfi5Ls57hlRDBdxYZLfqFg4ucz3XPGQmEx/6c7H6+W7 n6ZMC7l1IBYttYcneKeJzh4V7TozqGJuo+xGB4bD7Ie/gPzKRs4h4DNmQ+r+oYgztcd+xy 0jevllB/XkG6hEPzjpLk/2pql58iLKu4mGesy9Z00qFh5N8V3eXS654lSVWNNC9LKTeZmn udLgBUyjWFlyv1kt74nK3AWJzg5sRXDUP9/5k2mxoYcRAMDSWlDdFIAodJ7+7Ck721iRJc 1U9VVZ5OtONkvZjVTQlQgCR1LB+aBiFr/l/6+EauMSX6XfdYA51UyrfkZSgbsA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1714923531; a=rsa-sha256; cv=none; b=NMlhYIWZEaVMSvwjyxzuzIWOUXkYCFQaoNngXASTHk500pe8SS9WwB2gbI7tL9AvgisTok wMTBwEZy7k5RIGV+uc/H7d0rsEOzPaumq1Pc8ZoUJCDuANm6N90LPyIAfeIyWAzkxLzlfA 9g4u0jMkhRlTGtrAY5PghcrVQIzmeglfnQ1DaIf4IyJeS3MvMK3rWu9xZublQx4B6W+1pu 0c/FIVs409YKpk5TQF25KFHO7VHNaRlkq0M68Ur0AXJYNcLM5WWCsqinx6zwt7xAIfls45 qwEBUwNI0hSnmej2Q838f2JPiMEx8p7p2ggFiWlViDUbthczqj8yDaUB6KhVBg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714923531; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nSdiKnkC3LQt7iFoMEGzkBmhnqhFIumekTHiIgdVbmQ=; b=APKLL0uOFiZe6fSvyCyup0YF/thvlOenM8H9Her5kYj+R5d25VtDJuSvRpSGTADO9EZrgc xMNIXo8SElH2M5ItAgQ8eL81J22ikQ6D+dKQToqDYl8LZydXCHTw1RBzoP/KCBNOc2FXXZ 3eHEui/TlGyRnQziIBDMWGQ9ofegBHXNBfxuOeafWngZNp/nalkCl/6dn4STsKxXLEUMCM Kirau++7BAt5CNzyiywlvUQUi1GfZitc13Apv2ItPDR9pL2MMx4/noYjPJgZrKSTbzI6tB jCFGgYeRSY+TplW2wkpmsO75fxLgcx2E9Q/v98G+Wf7xnBm1pywHKH2HqAZ1ZQ== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 20A3BD66F; Sun, 05 May 2024 15:38:51 +0000 (UTC) Date: Sun, 5 May 2024 15:38:51 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebd.org Subject: FreeBSD Status Report - First Quarter 2024 Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit FreeBSD Status Report First Quarter 2024 Here is the first 2024 status report, with 21 entries. The New Year brings us many new interesting projects, such as the new libsys that separates system calls from libc and libpthread or work on a graphical installer for FreeBSD, which will help making our OS more user-friendly. Of course, the usual projects keep going on, such as the work on cloud-init, OpenStack, or the GCC ports. As usual our main teams share their progress with us. Have a nice read. Lorenzo Salvadore, on behalf of the Status Team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2024-01-2024-03/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Cluster Administration Team □ Continuous Integration □ Ports Collection • Projects □ Audio Stack Improvements □ Bhyve Improvements □ Graphical Installer for FreeBSD • Userland □ libsys □ PackageKit backend for FreeBSD pkg • Kernel □ iwlwifi(4) and wireless for 13.3-RELEASE • Architectures □ Ten64, WHLE-LS1, and HoneyComb • Cloud □ FreeBSD on Microsoft HyperV and Azure □ FreeBSD as a Tier 1 cloud-init Platform □ OpenStack on FreeBSD • Documentation □ Documentation Engineering Team • Ports □ FreshPorts: Notification of new packages □ GCC on FreeBSD □ Valgrind: port to arm64 on its way • Third Party Projects □ Containers and FreeBSD: Pot, Potluck and Potman ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. 13.3-RELEASE FreeBSD 13.3 was released on March 5th, 2024. The release announcement is at: https://www.freebsd.org/releases/13.3R/announce/ Along the release engineering team, the project dedicates the 13.3-RELEASE to Glen Barber, with thanks for his many years of contributions as Release Engineer. Future of 32-bit platform support Core announced Future of 32-bit platform support in FreeBSD for deprecating 32-bit platforms over the next couple of major releases. Commit bits • Core approved the src commit bit for Bojan Novković • Core reactivated the src commit bits for Mark Peek, Mark Murray, and Lawrence Stewart ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://freebsdfoundation.org/ Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/ freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://freebsdfoundation.org/journal/ Foundation Events URL: https://freebsdfoundation.org/our-work/events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and worldwide community, and helping to advance the state of FreeBSD. We do this in both technical and non-technical ways. We are 100% supported by donations from individuals and corporations and those investments help us fund the: • Software development projects to implement features and functionality in FreeBSD • Sponsor and organize conferences and developer summits to provide collaborative opportunities and promote FreeBSD • Purchase and support of hardware to improve and maintain FreeBSD infrastructure • Resources to improve security, quality assurance, and continuous integration efforts • Materials and staff needed to promote, educate, and advocate for FreeBSD • Collaboration between commercial vendors and FreeBSD developers • Representation of the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity Operations We kicked off the new year with ambitious goals to help move the FreeBSD Project forward by identifying features and functionality to support in the operating system and increasing our advocacy efforts to increase and expand the visibility of FreeBSD. Stay tuned for a blog post that will provide more information on our 2024 goals and plans. We also published the 2024 Budget. In order to provide greater transparency about the budgeting process, we wrote a blog post that provides more details on how funding is allocated, new breakouts of some of the project expense categories, and more details on where the funding is going. OS Improvements During the first quarter of 2024, 180 src, 65 ports, and 18 doc tree commits identified The FreeBSD Foundation as a sponsor. Three new projects began this quarter. • Work began to improve FreeBSD’s audio stack and provide audio developers with useful tools and frameworks to make sound development on FreeBSD easier. Read more in Christos Margiolis Audio Stack Improvements report entry. • Olivier Certner began his second contract with the Foundation, and this time around, the main goal is to make unionfs stable and useful on FreeBSD. Other work may include revamping VFS lookups, improving out-of-memory handling, implementing a notification system for en-masse detection of filesystem changes such as inotify, and improving console usability. • This quarter, a new project to add hierarchical rate limits to the OpenZFS file system began. Pawel Dawidek will add support for limits that will be configurable, similar to quotas, but would limit the number of read/write operations and read/write bandwidth. Six projects continued this quarter. • You can read about the continued work to port OpenStack components to FreeBSD in Chih-Hsin Chang’s OpenStack on FreeBSD report entry. • Work continued to improve cloud-init support for FreeBSD. You can read about Mina Galić’s work in her FreeBSD as a Tier 1 cloud-init Platform report entry. • A new joint project began between Advanced Micro Devices (AMD) and The FreeBSD Foundation to develop a complete FreeBSD AMD IOMMU driver. This work will allow FreeBSD to fully support greater than 256 cores with features such as CPU mapping and will also include bhyve integration. For those interested in the technical details, follow Konstantin Belousov commits tagged with Sponsored by fields for Advanced Micro Devices (AMD) and The FreeBSD Foundation. • Refer to Pierre Pronchery’s Graphical Installer for FreeBSD report entry to read about the status of FreeBSD’s new graphical installer. • Work continues to port the Vector Packet Processor (VPP) to FreeBSD. VPP is an open-source, high-performance user space networking stack that provides fast packet processing suitable for software-defined networking and network function virtualization applications. Look for a pending article from the developer working on the project, Tom Jones, that details the experience of porting VPP to FreeBSD. • Björn Zeeb and Cheng Cui continue their wireless work. This quarter was mostly focused on bug fixes and stability improvements to LinuxKPI 802.11 and net80211. Much of this work made it into the 13.3 release. Here is a sampling of other Foundation-sponsored development completed over the first quarter of 2024: • FreeBSD was accepted in Google Summer of Code 2024 after receiving 22 contributor proposals; on May 1, we will learn how many projects we will be awarded • OpenSSH: update to 9.6p1 then 9.7p1 • Deprecate bsdlabel • Import the kernel parts of bhyve/arm64 • Various RISC-V improvements FreeBSD Infrastructure A contract was completed to set up a new cluster site at NYI Chicago. You can read about the details of that project on the Foundation’s blog. Continuous Integration and Workflow Improvement As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and the test infrastructure. The full update can be found within the quarterly status report. Partnerships and Research A focus of Partnerships this Quarter has been to educate the industry about the innovations in the FreeBSD community and the impact that FreeBSD continues to have as a cornerstone to our digital society. This is an ongoing priority, and one we invite (encourage) everyone using and working on FreeBSD to join us in. Greg Wallace, the Foundation Partnerships lead, is grateful for the opportunities he has had to meet with open source and industry leaders at Microsoft, Google, AWS, OpenSSF, Alpha-Omega, CISA, Eclipse Foundation, Open Source Initiative, Apache Software Foundation, Rust Foundation, Red Hat, Linux Foundation and many others to ensure they have visibility into the key role FreeBSD plays in the global digital infrastructure. This is a role FreeBSD has earned through its technical excellence, security by design, high availability, simplicity of operations, commitment to open source collaboration, and cohesiveness. One sees these characteristics of FreeBSD in the important ongoing funded development work such as porting VPP to FreeBSD, sponsored by RG Nets. Ensuring industry visibility to the excellence and impact of FreeBSD is vital to ensuring tier one support for FreeBSD across all key hardware and software platforms. As a community, every conversation we have with people outside the BSD communities, and every piece of content we publish, that attest to how FreeBSD powers our individual and corporate success, brings us one step closer. To this end, the Foundation is working on a FreeBSD Impact Report that will aggregate the core and often mission critical role FreeBSD plays in society, from embedded systems powered by QNX, to payments and check processing, to digital entertainment, internet and cybersecurity infrastructure. Our community is stepping up in innumerable ways, including to make sure FreeBSD supports industry-standard containerized workloads — check out the Open Container Initiative FreeBSD runtime extension working group. The recently opened hardware vendor support survey will feed into a hardware support guide that reflects the collective experience of all respondents that is intended to help everyone identify hardware vendors that prioritize FreeBSD; it will also help focus Partnerships' outreach on the priority vendors. To close, please TELL THE WORLD YOU USE FREEBSD AND WHY. There is no wrong way to do this — put it on your blog, on your favorite social media channel, list FreeBSD on your company’s Open Source page, contact the Foundation about a Case Study, etc. Stormshield, a leading cybersecurity company based in Europe, provides a great example of how vendors that use FreeBSD can do this. The footer of their blogs says: "A strong supporter of Open Source, Stormshield is an active member (and sponsor) of the FreeBSD community…​Whenever we modify Open Source software, make patches or add features, we offer them to the community for inclusion." Advocacy The first quarter of 2024 marked the beginning of a new era for the Foundation Advocacy team. We welcomed Kim McMahon in the role of Senior Director of Advocacy and Community and also brought on two new technical writers to help increase the frequency and depth of the FreeBSD-related content we produce. Just some of our expanded Q1 efforts to support FreeBSD are below. • Began work planning the on the May 2024 FreeBSD Developer Summit, co-located with BSDCan, taking place May 29-30, 2024 in Ottawa, Canada • Introduced FreeBSD to new and returning folks at State of Open Con 24 in London, UK, February 6-7, 2024 • Held an Introduction to FreeBSD half-day workshop and staffed a booth at SCaLE21x, which took place March 14-17, 2024 in Pasadena, CA. Thanks to Gordon Tetlow for his help with the workshop • The Foundation team also worked on a common message on the improvement and benefits of FreeBSD to ensure consistency between the FreeBSD Foundation and Core Team • Members of the Foundation team served as Administrators for the 2024 Google Summer of Code. This year marks the 20th anniversary of Google Summer of Code and the 20th year that the FreeBSD Project was accepted as a mentoring organization. The Project received 23 applications from prospective interns • Provided an overview of FreeBSD 13.x including the 13.3 release • Worked on the final report of the 2024 FreeBSD Community Survey. Be on the lookout for the report at the end of April • In partnership with Innovate UK and Digital Security by Design (DSbD), the Foundation held the first annual Digital Security by Design (DSbD) Ecosystem Beacon Awards to celebrate innovators working with and enhancing CheriBSD • Published numerous blogs including: □ What Makes the FreeBSD Governance Model Successful □ Guiding the future of FreeBSD releases: Colin Percival, the new Release Engineering Team Lead • Authored or participated in a number of Thought Leadership and News articles including: □ The Cybersecurity Battle Has Come to Hardware □ Ampere in the Wild: How FreeBSD Employs Ampere Arm64 Servers in the Data Center □ ISAs and the Dawning Hardware Security Revolution □ Published the March 2024 FreeBSD Update with a new look □ Released the November/December 2023 and January/February 2024 issues of the FreeBSD Journal now with HTML versions of the articles Fundraising Thank you to everyone who gave us a financial contribution last quarter to help fund our work to support the Project. 2024 started strong with a total of $250,855 raised this quarter. We are grateful for your investment in FreeBSD! Please consider supporting our efforts in 2024 by making a donation here: https://freebsdfoundation.org/donate/. Or, check out our Partnership opportunities here: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 13.3-RELEASE announcement URL: https://www.freebsd.org/releases/13.3R/announce/ FreeBSD 14.1-RELEASE schedule URL: https://www.freebsd.org/releases/14.1R/schedule/ FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the first quarter of the year, the Team managed 13.3-RELEASE, leading to the final RELEASE build and announcement in March. Planning has started for the upcoming 14.1-RELEASE cycle. The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronize its distributed work and communications. In this quarter, the team has worked on the following: • Regular support for FreeBSD.org user accounts. • Regular disk and parts support (and replacement) for all physical hosts and mirrors. • Set up a new mirror in Chicago. FreeBSD Official Mirrors Overview Current locations are Australia, Brazil, Germany, Japan (two full mirror sites), Malaysia, South Africa, Sweden, Taiwan, United Kingdom (full mirror site), United States of America — California, Chicago, New Jersey (primary site), and Washington. The hardware and network connection have been generously provided by: • Bytemark Hosting (being decommissioned) • Cloud and SDN Laboratory at BroadBand Tower, Inc • Department of Computer Science, National Yang Ming Chiao Tung University • Equinix • Internet Association of Australia • Internet Systems Consortium • INX-ZA • KDDI Web Communications Inc • Malaysian Research & Education Network • MetaPeer • New York Internet • NIC.br • Teleservice Skåne AB (new since 2023Q4) • Your.Org New official mirrors are always welcome. We have noted the benefits of hosting single mirrors at Internet Exchange Points globally, as evidenced by our existing mirrors in Australia, Brazil, and South Africa. If you are affiliated with or know of any organizations willing to sponsor a single mirror server, please contact us. We are particularly interested in locations on the United States West Coast and throughout Europe. See generic mirrored layout for full mirror site specs and tiny-mirror for a single mirror site. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI Tinderbox view URL: https://https://tinderbox.freebsd.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI 3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&email1=testing%40FreeBSD.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet In the first quarter of 2024, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD. Important completed tasks: • With help from clusteradm, the host running test VMs had disk and memory upgraded by reusing the parts of decommissioned machines. • Update the build environment of stable/13 jobs to 13.3-RELEASE. • Turn i386 build on main branch to use cross build on amd64. Work in progress tasks: • Merging https://reviews.freebsd.org/D43786 • Merging https://reviews.freebsd.org/D36257 • Adding new hardware purchased by the FreeBSD Foundation to the CI cluster • Designing and implementing pre-commit CI building and testing and pull/ merge-request based system (to support the workflow working group) • Proof of concept system is in progress. • Designing and implementing use of CI cluster to build release artifacts as release engineering does, starting with snapshot builds • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Redesigning the hardware test lab and adding more hardware for testing Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Planning to run ztest tests • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/# ports-contributing Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Tobias C. Berner Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. According to INDEX, there are currently 32,244 ports in the Ports Collection. There are currently ~3,300 open ports PRs. The last quarter saw 12,991 commits by 158 committers on the main branch and 888 commits by 61 committers on the 2024Q1 branch. Compared to last quarter, this means a large increase in the number of commits on the main branch (up from 9,424) and slightly more backports to the quarterly branch (up from 781). The number of ports also increased (up from 31,942). In Q1 there were around 14,127 commits to main: The most active committers were: • 2934 sunpoet • 2676 bofh • 1297 yuri • 748 eduardo • 545 jbeich • 347 arrowd • 233 diizzy • 195 yasu • 170 ehaupt • 164 wen A lot has happened in the ports tree in the last quarter, an excerpt of the major software upgrades are: • pkg 1.21.0 • New USES: ocaml • Default version of gcc switched to 13 • Default version of ruby switched to 3.2 • Default version of lazarus switched to 3.2.0 • Default version of go switched to 1.21 • Chromium updated to 123.0.6312.105 • Electron-28 updated to 28.2.10 • Electron-27 updated to 27.3.9 • Firefox updated to 124.0.2 • Firefox-esr updated to 115.9.1 • KDE updated to Frameworks 5 5.115, Frameworks 6 to 6.0.0 Plasma Desktop 5 to 5.27.11, Plasma Desktop 6 to 6.0.2 • Qt5 updated to 5.15.13 • Qt6 updated to 6.6.3 • Python updated to 3.11.9, 3.10.14 and 3.8.10 • Ruby updated to 3.2.3 • Rust updated to 1.77.0 • SDL updated to 2.30.2 • Sway updated to 1.9 • wlroots updated to 1.17.2 • Wine updated to 9.0 • Xorg server updated to 0.17.2 During the last quarter, FreeBSD Packages Management Team ran 17 exp-runs to test various ports upgrades, updates to default versions of ports, subpackage support and base system changes. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Audio Stack Improvements Contact: Christos Margiolis The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, since it has been left largely unmaintained, and, although high in quality, there is still room for improvement — from lack of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to touch on all those areas, and as such, is more of a general improvement project, than an implementation of a specific feature. So far, my focus has been towards the kernel side of the audio stack, with D43545 being probably the most requested and notable patch. I am also working on scrapping the rather outdated "snd_clone" audio device cloning framework of sound(4), and replacing it with DEVFS_CDEVPRIV(9) (D44411). Some of the future tasks include: • Attempt to find a better (ideally automatic) way to handle snd_hda(4) pin-patching. • Implement an oss(3) library and audio(8) utility, in similar fashion to mixer(3) and mixer(8). • Write a bluetooth device management utility. • Improve mixer(3) and mixer(8). • Improve documentation and test suite where needed. A more detailed description can be found here. You can also follow the development process in freebsd-multimedia@, where I post regular reports: • Report #1 • Report #2 • Report #3 • Report #4 • Report #5 • Report #6 • Report #7 • Report #8 Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Bhyve Improvements Links: bhyve production users calls URL: https://callfortesting.org FreeBSD Wiki - Enterprise Working Group URL: https://wiki.freebsd.org/EnterpriseWorkingGroup FreeBSD Wiki - EWG - bhyve and jails management tooling URL: https://wiki.freebsd.org/ChrisMoerz/bhyve_management Jan Bramkamp’s work on s6rc URL: http://static.bultmann.eu/s6-talk/ vmstated on GitHub URL: https://github.com/christian-moerz/vmstated YouTube - vmstated explained URL: https://www.youtube.com/watch?v=f60NCrunXyw Contact: Chris Moerz Bhyve I/O Performance Measurements Participants of the weekly bhyve production users calls recently discussed bhyve’s I/O performance. Various ways of measuring and comparing were brought up, however it was quickly clear that there is currently no formal analysis and report on this. So, we started this effort in the hopes of better understanding the various impacts of configuration options for a guest on its I/O performance. We created a set of shell scripts that harness a FreeBSD guest for running benchmarks/fio I/O performance measurements under various configurations. This allows us to compare multiple criteria like bandwidth, latency, IOPS, and more. So far, we are testing for • different storage backends (i.e. ahci-hd, nvme, virtio-blk) • different memory settings • different CPU pinning options • different block sizes for the backing storage • different block sizes for accessing virtual disks We are also pitting results for different CPU manufacturers against each other and contrasting guest vs host performance to better understand the performance impact of virtualization. We plan to continue discussing our results during Michael Dexter’s weekly bhyve production users call - come join us if you are interested. We also hope to be able to present the results at EuroBSDCon in Q3. Bhyve Virtual Machine Tooling Last year, Greg Wallace at the FreeBSD Foundation founded the Enterprise Working Group with the specific goal of addressing pain points of Enterprise users of FreeBSD. One of the work groups that emerged clustered around bhyve and jails management tooling. After collecting a set of desired features and functionality, one overarching key point for bhyve emerged: the desire to have configuration concepts and tooling for bhyve like the ones available for jails. While other desirable features were identified as well, i.e. TPM software emulation and snapshot/restore/host-migration, the conceptual tooling question won over those due to the lower degree of complexity and its clarity on goal and the path on how to take steps towards it. Technically, this means working out existing gaps around process supervision and virtual machine state management. First steps were taken by experimenting with existing frameworks (i.e. s6rc work by Jan Bramkamp) and eventually — through discussions in the weekly bhyve production user’s calls (organized by Michael Dexter) — this led to a proof-of-concept implementation of "vmstated". Started as an experiment to better understand the problem space of process supervision and virtual machine state handling, vmstated is constructed of a daemon and vmstatedctl management utility. It is built with base-only tooling and libraries and leverages FreeBSD specific constructs like kqueue to minimize its resource impact. vmstated is configured via a UCL configuration file (similar to jails.conf) and — in combination with a bhyve_config(5) configuration file — already provides highest flexibility in configuring virtual machines. vmstatedctl provides a jail-like command set to start, stop, and retrieve status information about guests. State transitions can easily be hooked via shell scripts and allow running additional commands for network or storage set up and tear down when relevant state changes occur. An initial release is already in ports as sysutils/vmstated and updates are pending commit; however, the newest version can be found on GitHub. We are considering expanding the work; we would also like to invite anyone interested to join us in this work! Patches, suggestions, feedback, etc. are all very much welcome! If you want to know more about our work, come join us at one of Michael Dexter’s weekly bhyve production users calls or reach me by email. Documentation We managed to update a few parts of the Handbook and Porter’s Handbook (thanks to Ed Maste, Joseph Mingrone, Pau Amma, and Rodney W. Grimes): • several improvements and expansions to the virtualization chapter in the FreeBSD Handbook □ using a bhyve_config(5) configuration file □ jailing bhyve □ experimental snapshot and restore feature □ setting up a Windows guest • we also have a review (D43940) up for an initial step to improving the bhyve man page □ this was intentionally started with a structural update first to separate the many -s flag options □ once this lands, we can move to a more widespread update to the overall content Feedback is obviously very welcome — on the existing content as well as any additional content we should be looking into! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Graphical Installer for FreeBSD Links: Slides from AsiaBSDCon 2024 URL: https://people.defora.org/~khorben/FreeBSD/bsdinstall/bsdinstall%20-%20Now%20with%20Graphics!%20-%20AsiaBSDCon%202024%20-%20WIP%20Session.pdf gbsddialog URL: https://github.com/khorben/gbsddialog preview video URL: https://youtu.be/jm6byc7N2O4 Contact: Pierre Pronchery The first hurdle to overcome when testing a new Operating System is to get it installed. What is more, the first impression new users gather from an Operating System is its installation process. The state of the art for Operating System installers nowadays definitely involves a graphical process. This is the case for mainstream systems but also for other UNIX systems comparable to FreeBSD: RedHat Enterprise Linux, Ubuntu, Debian GNU/Linux, or even Devuan GNU+Linux Regardless of the technical level of the actual user, this is how the platform will be compared in the public eye. In practice, FreeBSD has already been derived as a desktop-oriented Operating System by different projects. Of these, I only found GhostBSD as a maintained project offering a graphical procedure to install the system. The objective here was to consider a procedure that FreeBSD could adopt as part of its base system, in order to ship a graphical installer much like the current installer. However, GhostBSD’s installer relies on a Gtk+ interface driven with Python, implying a hefty footprint on the installation media when adopting FreeBSD’s usual image generation procedure. It would also imply importing and maintaining new projects into the ports tree. Instead, with knowledge of the current bsdinstall(8) and bsdconfig(8) utilities, I envisioned a BSD-licensed replacement for Xdialog(1). Just like when invoking bsdconfig with the -X switch for graphical mode, it could be dropped in instead of bsddialog(1) and allow graphical installation - while sharing the infrastructure of the current installer. To avoid confusion with the current implementation of Xdialog from the x11/xdialog port, I have named its replacement gbsddialog(1). It also has to be said that Xdialog is quite obsolete (latest release in 2006) and this shows visually too. After creating a Proof-of-Concept prototype past the 14.0 release, I was provided with a 2-months window by the FreeBSD Foundation, in order to complete a working implementation. Thanks to a few shortcuts, I was glad to present the outcome of this effort during the WIP session of AsiaBSDCon 2024, including a working graphical installer. Most of the necessary patches are already available for review in FreeBSD’s Phabricator: • D44279 bsdinstall: implement adduser with bsddialog • D44280 bsdinstall: implement rootpass with bsddialog • D44670 bsdinstall: implement timezone with bsddialog • D44671 bsdinstall: allow forcing a specific partitioning mode • D44672 bsdinstall: obtain the dialog binary from $DIALOG • D44673 bsdinstall: handle command-line options in targets • D44674 bsdinstall: add support for graphical mode I have tried to keep these patches in growing order of friction expected before integration. The most important objective of this project was to improve bsdinstall, regardless of the success of this integration. From the items above, it should be noted that D44279, D44280, D44670 are expecting to improve the general look & feel of the installer, even while in text mode. Similarly, D44671 and D44672 improve the overall versatility of the installer when scripted or customized. D44673 and D44674 bring it on par with bsdconfig -X, even allowing the graphical installation of jails. Some parts are still missing, or made use of shortcuts still unsuitable for integration: • The "fetchmissingdists" target was avoided by shipping every component on the installation media; • The "checksum" and "extract" targets had to be re-implemented with simpler code, degrading the user experience also with the regular installer; • Creation of the installation media generates an additional, heavy image (almost 8 GB), and is suspected to be hindered by a bug in makefs(8). The corresponding code can be found in my GitHub fork in the khorben/ bsdinstall-graphical4 branch. As can be guessed from the branch name, depending on the complexity of rebasing operations, combined with the (hopefully) progressive integration of the changes proposed, new branches may be added to keep track of the progress. (In fact a khorben/bsdinstall-graphical5 branch already exists.) Still, a lot needs to be done for the installer to reach a new level of maturity overall. While working on this project, I have received general complaints on the installer, and calls for a complete rewrite. It is true that the current code base suffers from a number of issues and limitations. The lack of a graphical installer is one of many symptoms, which range from the lack of recovery from errors, of navigability to previous steps, of a general vision of the installation progress, or of a network-based installer. In the meantime, this is the installer we have and are familiar with, and I think it can still be saved and improved. Special thanks go to Ed Maste and Joe Mingrone for the opportunity, and to Philippe Audeoud, Tobias C. Berner, Olivier Certner, Jessica Clarke, Olivier Cochard-Labbé, Baptiste Daroussin, Brad Davis, Michael Dexter, Li-Wen Hsu, Mateusz Piotrowski, Alfonso Siciliano, Emmanuel Vadot, and Robert Watson for the feedback, reviews, and encouragements. (If I missed anyone, you know I did not mean to!) Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. libsys Contact: Brooks Davis The libsys project removes direct system calls from libc.so and libpthread.so (aka libthr.so) to a separate libsys.so. This will: • Isolate language runtimes from the details of system call implementations. • Better support logging and replay frameworks for systems calls. • Support elimination of the ability to make system calls outside trusted code in the runtime linker and libsys. This work was initially inspired by a compartmentalization prototype in CheriBSD in 2016. Ali Mashtizadeh and Tal Garfinkel picked that work up and attempted to upstream it (D14609). Unfortunately we could not figure out how to review and land the massive reorganization required through a phabricator review so it languished. Last year the CHERI project once again found a need for system call separation in a new library-based compartmentalization framework in CheriBSD so I rebuilt the patch from scratch, committing dozens of libc cleanups along the way. I landed the first batch of changes on February 5th. Since then I have made a number of refinements to the way we link libsys as well as which symbols are provided in which library. Thanks to Konstantin Belousov for many rounds of review and feedback as well as runtime linker fixes. Thanks to Mark Johnston for runtime linker debugging and Dimitry Andric for sanitizer fixes. Thanks also to everyone who reported bugs and helped debug issues. Known issues (as of the end of the reporting period) • The libsys ABI is not yet considered stable (it is safe to assume __sys_foo () will be supported so language runtimes can use it now). • Programs using the address sanitizer must be linked with -lsys (resolved in base at publication time). TODO • Add a libsys.h. (See D44387 and other reviews in the stack.) • Update intro(2) for libsys. • Finalize the ABI. I am likely to reduce the set of _ (underscore) prefixed symbols we expose. • MFC the existence of libsys? It is not clear this is practical, but it might be possible to MFC something useful for language runtimes. Help wanted • Port language runtimes that do not use libc to use libsys for system calls rather than rolling their own interfaces. • Explore limitations on where system calls can be made similar to OpenBSD’s msyscall(2) (now obsolete) and pinsyscalls(2) (not an obvious match to our libsys). Sponsor: AFRL, DARPA ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PackageKit backend for FreeBSD pkg Contact: Gleb Popov PackageKit is a small D-Bus daemon program that serves as a backend for "application store" type of apps - most notably Plasma Discover and Gnome Software Center. The latest PackageKit release features a libpkg backend, which means that you can now use PackageKit-enabled programs on FreeBSD to manage software. Plasma Discover is already switched to using PackageKit, so you will get it working out of the box once you update your ports/packages. If you observe any crashes or bugs in PackageKit please let me know by opening an issue upstream. If you are interested in contributing, there is a lot of work to do too! Sponsor: Serenity Cybersecurity, LLC ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. iwlwifi(4) and wireless for 13.3-RELEASE Links: Categorised Wireless Problem Reports URL: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=0 Contact: Bjoern A. Zeeb Contact: The FreeBSD wireless mailing list In the first weeks of 2024 focus was on stability for 13.3-RELEASE to finally make iwlwifi(4) usable. The upcoming 14.1-RELEASE will benefit from this work too. The response has since generally been positive and iwlwifi(4) supporting chipsets up to BE200 seems mostly stable, yet still slow. A lot of testing was provided by the FreeBSD Foundation and by many users. Massive thanks to everyone who tested, reported back, updated PRs and helped other users. I have also slowly started to "categorise" more (old) wireless problem reports and will try to continue with some spring cleaning throughout the year. If you have questions or feedback please use the freebsd-wireless mailing list. That way everyone will see, be able to join in, and the answers will be publicly archived. Sponsor: minipci.biz (BE200 hardware) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Ten64, WHLE-LS1, and HoneyComb Links: My wiki page with links to some status URL: https://wiki.freebsd.org/BjoernZeeb / Contact: Bjoern A. Zeeb Solid-Run’s HoneyComb, Traverse Technologies’s Ten64 and some versions of Conclusive Engineering’s WHLE-LS1 all are NXP based platforms with the Data Path Acceleration Architecture Gen2 (DPAA2). Work has happened to support or improve support for peripherals on these boards. For DPAA2 I have local changes which will need review (or further discussion): • Cleanup of memac (MDIO) code reducing bus attachment (ACPI and FDT specific) code into more common code. • Cleanup of MC bus attachment code (again ACPI, FDT). • For reasons of mii_fdt.c support on some PHYs on FDT-based platforms restructure MAC/MII code and mostly migrate it out of the network interface (NI). • Improve Dmitry Salychev’s (dsl) initial SFF/SFP code, prototyping a bus similar to MII for SFP with the hope that with more work it can grow into a larger, general FreeBSD framework and hooked it up to DPMAC. • With this, minimal support (still fairly hacked up) for "managed" SFP+ mode (using the Ten64 terminology) is usable on FDT-based systems using DAC and fiber cables. • Add more sysctl statistics to DPMAC and NI. In short, I mostly cleaned up some of the mess I contributed to during the initial bring-up. For the LS1088a based WHLE-LS1 systems changes include: • device-tree file updates. • Added support for the PCA9546 I2C Switch (committed). • Added basic support for the PCAL6524 24-bit Fm+ I2C-bus/SMBus I/O expander. • Added basic support for the PCA9633 4-bit Fm+ I2C-bus LED driver to drive the status LEDs. • Added support to program the rgephy(4) LEDs (which needs to be validated). • Started testing the eMMC with MMCCAM and GENERIC but had trouble (needs further investigation, seemed fine from firmware for updates). • Tested one of three PCIe slots and USB fine. For the Ten64: • Most of the basic lifting happened a while ago and it has generally been usable. • Detecting the VSC8514 PHY as such went in end of last year. • Used as the default platform to test the DPAA2 changes and SFP/SFP+ code. In addition Pierre-Luc Drouin has overhauled the Vybrid I2C support now attaching and working on both FDT- and ACPI-based systems (committed). Sponsor: Traverse Technologies (Ten64 hardware a while ago, support) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Souradeep Chakrabarti Contact: Li-Wen Hsu In this quarter, we have solved all the blocking issues and published the 13.3-RELEASE on Azure Marketplace. Work in progress tasks: • Automating the image building and publishing process and merging to src/ release/. • Building and publishing snapshot builds to Azure community gallery. The above tasks are sponsored by The FreeBSD Foundation, with resources provided by Microsoft. Open tasks: • Update FreeBSD-related doc at Microsoft Learn • Support FreeBSD in Azure Pipelines • Update Azure agent port to the latest version • Upstream local modifications of Azure agent • Port Linux Virtual Machine Extensions for Azure Sponsor: Microsoft for people in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD as a Tier 1 cloud-init Platform Links: cloud-init Website URL: https://cloud-init.io/ cloud-init Documentation URL: https://cloudinit.readthedocs.io/en/latest/ Contact: Mina Galić cloud-init is the standard way of provisioning servers in the cloud. Over the past year and a half, thanks to this FreeBSD support has steadily improved. This year, together with cloud-init developers and the FreeBSD Foundation, we decided to explicitly focus on making improvements in FreeBSD itself, that will aid the cloud-init team to test future changes to FreeBSD code-paths themselves. To achieve this goal, I need to make FreeBSD run in LXD (and Incus), under the control of lxd-agent (or incus-agent). Here are some improvements from the recent weeks: • I have written a small testing-framework (in sh, and I’m slowly porting it to OpenTofu/Terraform), which installs the latest version of net/ cloud-init-devel or net/cloud-init and runs a couple of standard cloud-init tests. • To do this, I have created a dedicated public repository which contains the latest versions of net/cloud-init-devel and net/cloud-init for FreeBSD 13 and 14 on amd64 and aarch64. • I have ported Linux’s vsock testing framework to FreeBSD • I created a driver skeleton for a VirtIO Socket driver, based on the HyperV Socket driver. • In doing so, I made numerous improvements to HyperV sockets, some of which are accepted, others still need more work. • I have tested and released the latest 24.1 series cloud-init, where the cloud-init team and I have finally fixed some longstanding bugs, such as moving /run/cloud-init to /var/run/cloud-init on BSD, as well as fixing the homedir argument to user_groups to actually do something. • This release also sees numerous fixes to the OpenBSD code-paths from the community and not just me. • I have also started an official port for OpenBSD, but that work has stalled . The work to come, in broad strokes: • Finish the FreeBSD VirtIO Socket driver. • Fix Go’s runtime to support VirtIO on FreeBSD. • Port lxd-agent’s dependencies to FreeBSD. • Port lxd-agent to FreeBSD. That work will be interspersed with more improvements to cloud-init on BSDs, and more tests on different cloud providers. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OpenStack on FreeBSD Links: OpenStack URL: https://www.openstack.org/ OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd Contact: Chih-Hsin Chang Contact: Li-Wen Hsu The OpenStack on FreeBSD project aims to seamlessly integrate OpenStack cloud infrastructure with the FreeBSD operating system. It uses FreeBSD’s unique features while ensuring compatibility with OpenStack standards. In the first quarter of 2024, we made significant progress on the OpenStack on FreeBSD project. This included submitting a proposal for BSDCan 2024 and attending AsiaBSDCon 2024 to share our porting experiences and gain exposure for the project. The feedback received at AsiaBSDCon was particularly valuable and helped in refining the project’s direction. During this period, we also reviewed the project’s phase 1 tasks and made necessary adjustments. We also planned for phases 2 and 3, aligning them with the project’s long-term goals. One technical achievement was verifying the functionality of bhyve serial console over TCP, an important part of the project’s infrastructure. Additionally, we created a demo video showcasing the project’s progress and features. Looking ahead, our focus for the next quarter includes confirming the feasibility of implementing FreeBSD privilege-management user space tools leveraging mac(4) and priv(9), simplifying installation steps by transitioning to FreeBSD ports, and porting OpenStack Ironic to FreeBSD. These tasks will enhance the project’s capabilities and compatibility. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. Documentation Engineering Team Link: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ Link: FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/ Link: Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng Contact: FreeBSD Doceng Team The doceng team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. During the last quarter: Edward Tomasz Napierała's doc commit bit was taken for safekeeping. Tom Rhodes 's doc commit bit was taken for safekeeping. FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblateurl Link: FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/url Q1 2024 Status • 17 team languages • 189 registered users Three new translators joined Weblate: • piker3 in Polish team (pl) • chrislongros in Greek team (el) • grip in Italian team (it_IT) Languages • Chinese (Simplified) (zh-cn) (progress: 7%) • Chinese (Traditional) (zh-tw) (progress: 3%) • Dutch (nl) (progress: 1%) • French (fr) (progress: 1%) • German (de) (progress: 1%) • Greek (el) (progress: 1%) • Indonesian (id) (progress: 1%) • Italian (it) (progress: 5%) • Korean (ko) (progress: 32%) • Norwegian (nb-no) (progress: 1%) • Persian (fa-ir) (progress: 3%) • Polish (progress: 2%) • Portuguese (progress: 0%) • Portuguese (pt-br) (progress: 22%) • Spanish (es) (progress: 36%) • Turkish (tr) (progress: 2%) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. FreshPorts: Notification of new packages Links: FreshPorts URL: https://freshports.org/ FreshPorts blog URL: https://news.freshports.org/ Contact: Dan Langille FreshPorts and FreshSource have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port maintainers and port users. For example, https://www.freshports.org/security/acme.sh/#history shows the history of the security/acme.sh port, back to its creation in May 2017. Also available are dependencies, flavors, configuration options, and available packages. All of this is useful for both users and developers of ports. Notification: New Package Available One of the original features of FreshPorts is notification of ports updates. You can create a list of ports and receive notifications about those ports. This new feature can also notify when a new package is available for that port. The use case: a known security vulnerability has been patched. FreshPorts will tell you the port has been patched, and then you wait for the package. This new feature will tell you when that package is available. Details at: • https://github.com/FreshPorts/freshports/issues/542 Help Needed It has been over 23 years since FreshPorts started. Others must take over eventually. I have started that process recently. There are several aspects to FreshPorts: • FreeBSD admin (updating the OS and packages) • front end code (website - mostly PHP) • back end code (commit processing - Perl, Python, shell) • database design (PostgreSQL). The database does not change very often and requires little maintenance compared to the applications and OS. The website pretty much runs itself. From time to time, a change to the FreeBSD ports infrastructure breaks something or requires a modification, but there is rarely any urgency to fix that. This is not a huge time commitment. There is a lot of learning. While not a complex application, FreshPorts is also not trivial. To contribute, please join the https://lists.freshports.org/mailman/listinfo/freshports-coders mailing list and let us know what you would like to help with. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org/ GCC 10 release series URL: https://gcc.gnu.org/gcc-10/ GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ GCC 13 release series URL: https://gcc.gnu.org/gcc-13/ Contact: Lorenzo Salvadore Updating GCC default version to 13 is finally finished. Thanks to Antoine Brodin who ran the exp-runs and to all other developers and ports maintainers involved. As promised in the preceding report, the next goal is to reduce the number of open bugs for GCC ports. Some work on existing bugs has already started. In particular, lang/gcc14-devel has long stayed out of date due to some issues with building the port without any BOOTSTRAP option. Thanks to the help of other developers and contributors (a special thank to Mark Millard), I noticed that according to the official documentation building GCC without bootstrap requires a working GCC binary and thus I switched lang/gcc14-devel to require that a BOOTSTRAP option is set. However it has later been stated that bootstrapping GCC using clang and libc++ is officially supported. But it has also been stated that this is not a high priority. At the moment lang/gcc14-devel is the only GCC port requiring a BOOTSTRAP option to be set. The plan is to have all GCC ports for versions greater or equal than 14 (i.e. future GCC ports) to require such an option: even if building without bootstrap is more or less officially supported, being low priority for upstream it increases the burden of maintaining GCC ports for low results. In case lower versions start to have issues building without bootstrap, I am going to require bootstrap for those as well. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Valgrind: port to arm64 on its way Links: Valgrind Home Page URL: https://www.valgrind.org/ Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html arm64 port URL: https://github.com/paulfloyd/freebsdarm64_valgrind Contact: Paul Floyd The major news, as per the title, is that a port to FreeBSD arm64 (or aarch64) is now ready. The next steps are to get it reviewed and pushed upstream. Valgrind 3.23 is due out at the end of April 2024 and devel/valgrind will be updated shortly after that. devel/valgrind-devel will get an update as soon as I have pushed the changes for arm64. --track-fds=yes now checks for and warns about attempts to close a file descriptor more than once. Handling of closefrom has been improved to use this feature. There are some important fixes for FreeBSD 15, in particular handling the new libsys. Here is a list of smaller bugfixes: • Support for FreeBSD 13.3 has been added. • Added a redirect for reallocarray. • Several fixes for aio* functions. • Added a redirect for memccpy. • There is a fix for _umtx_op OP_ROBUST_LISTS. • Added redirects for C23 free_sized and free_aligned_sized. • Correctly propagate the ELF stack protection flags to the guest stack that Valgrind synthesizes. • Fixes for --sanity-level-3 and above (only used for Valgrind self-testing at runtime). • Several fixes to checking done for semctl. • Fixed argument checking for utrace. • Fixed argument checking for clock_nanosleep. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on GitHub URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Bretton Vine (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. Potluck aims to be to FreeBSD and Pot 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. During this quarter, there were no new Pot releases. Potluck saw quite some activity though. Not only have the images been rebuilt for FreeBSD 14, but also the new Adminer container has been submitted by first-time contributor Sidicer. Additionally a large number of additional features, updates and fixes have been committed to containers like HAProxy-Consul, Grafana, PostgreSQL-Patroni, or Prometheus. For the Mastodon container, a blog post has been published explaining how to use it to run your own instance. As always, feedback and patches are welcome. Sponsors: Nikulipe UAB, Honeyguide Group