NetBSD Planet


September 25, 2021

DragonFly BSD Digest In Other BSDs for 2021/09/25

I forgot to link to BSD Now 421: ZFS eats CPU on Thursday!


September 24, 2021

UnitedBSD NetBSD Kernel/Driver Development

Hello all,
I have been into programming for some years, and would like to contirbute to the NetBSD project.
Anyway I still don't understand how I could start writing drivers for NEtBSD.

Does anyone here have any suggestion/recommendation to start contributing on the low level stuff?

Thanks

Frederic Cambus OpenBSD on the Vortex86DX CPU

This is the OpenBSD counterpart of my article about running NetBSD on the Vortex86DX CPU, and its purpose is mostly to archive a dmesg entry and various benchmarks for this machine. I should note that with only 256MB of RAM, the machine is too constrained to do kernel and libraries relinking in a timely manner, due to swapping.

For more information and background about the hardware, please refer to my other article.

Here is the result of a quick md5 -t benchmark:

MD5 time trial.  Processing 10000 10000-byte blocks...
Digest = 52e5f9c9e6f656f3e1800dfa5579d089
Time   = 2.398437 seconds
Speed  = 41693819.766790 bytes/second

Here is the result of the sha1 -t benchmark:

SHA1 time trial.  Processing 10000 10000-byte blocks...
Digest = 74a57b897cc581defa5b3a359fa762a1b83a60e8
Time   = 5.648437 seconds
Speed  = 17704012.632167 bytes/second

For the record, LibreSSL speed benchmark results are available here.

System message buffer (dmesg output):

OpenBSD 7.0 (GENERIC) #203: Wed Sep 22 19:24:38 MDT 2021
    [email protected]:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 267927552 (255MB)
avail mem = 246661120 (235MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 10/29/10, BIOS32 rev. 0 @ 0xf0010
pcibios0 at bios0: rev 3.0 @ 0xf0000/0x10000
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3a80/224 (12 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x17f3 product 0x6031
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc0000/0x8000 0xe9400/0x200!
cpu0 at mainbus0: (uniprocessor)
cpu0: Vortex86 SoC  (586-class) 1.01 GHz, 05-02-02
cpu0: FPU,TSC,CX8
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "RDC R6021 Host" rev 0x02
vga1 at pci0 dev 3 function 0 "XGI Technology Volari Z7" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 "RDC R6031 ISA" rev 0x02
vte0 at pci0 dev 8 function 0 "RDC R6040 Ethernet" rev 0x00: irq 10, address 00:1b:eb:22:16:5c
rdcphy0 at vte0 phy 1: R6040 10/100 PHY, rev. 1
ohci0 at pci0 dev 10 function 0 "RDC R6060 USB" rev 0x12: irq 11, version 1.0, legacy support
ehci0 at pci0 dev 10 function 1 "RDC R6061 USB2" rev 0x03: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "RDC EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at pci0 dev 11 function 0 "RDC R6060 USB" rev 0x12: irq 11, version 1.0, legacy support
ehci1 at pci0 dev 11 function 1 "RDC R6061 USB2" rev 0x03: irq 11
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "RDC EHCI root hub" rev 2.00/1.00 addr 1
pciide0 at pci0 dev 12 function 0 "RDC R1011 IDE" rev 0x01: DMA (unsupported), channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 ignored (not responding; disabled or no drives?)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "RDC OHCI root hub" rev 1.00/1.00 addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "RDC OHCI root hub" rev 1.00/1.00 addr 1
dt: 445 probes
umass0 at uhub1 port 2 configuration 1 interface 0 "SanDisk Cruzer Switch" rev 2.00/1.27 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: <SanDisk, Cruzer Switch, 1.27> removable serial.07815572120302108502
sd0: 7633MB, 512 bytes/sector, 15633408 sectors
uhidev0 at uhub2 port 1 configuration 1 interface 0 "Lenovo ThinkPad Compact USB Keyboard with TrackPoint" rev 2.00/3.30 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub2 port 1 configuration 1 interface 1 "Lenovo ThinkPad Compact USB Keyboard with TrackPoint" rev 2.00/3.30 addr 2
uhidev1: iclass 3/1, 22 report ids
ums0 at uhidev1 reportid 1: 5 buttons, Z and W dir
wsmouse0 at ums0 mux 0
ucc0 at uhidev1 reportid 16: 573 usages, 18 keys, array
wskbd2 at ucc0 mux 1
wskbd2: connecting to wsdisplay0
uhid0 at uhidev1 reportid 17: input=2, output=0, feature=0
uhid1 at uhidev1 reportid 19: input=8, output=8, feature=8
uhid2 at uhidev1 reportid 21: input=2, output=0, feature=0
uhid3 at uhidev1 reportid 22: input=2, output=0, feature=0
uaudio0 at uhub2 port 2 configuration 1 interface 1 "ABC C-Media USB Audio Device" rev 1.10/1.00 addr 3
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls
audio0 at uaudio0
uhidev2 at uhub2 port 2 configuration 1 interface 3 "ABC C-Media USB Audio Device" rev 1.10/1.00 addr 3
uhidev2: iclass 3/0
ucc1 at uhidev2: 11 usages, 3 keys, enum
wskbd3 at ucc1 mux 1
wskbd3: connecting to wsdisplay0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (779fe8066eed6ce5.a) swap on sd0b dump on sd0b

There are no sensors available on this machine.

PCI device data:

# pcidump
Domain /dev/pci0:
 0:0:0: RDC R6021 Host
 0:3:0: XGI Technology Volari Z7
 0:7:0: RDC R6031 ISA
 0:8:0: RDC R6040 Ethernet
 0:10:0: RDC R6060 USB
 0:10:1: RDC R6061 USB2
 0:11:0: RDC R6060 USB
 0:11:1: RDC R6061 USB2
 0:12:0: RDC R1011 IDE

September 23, 2021

Pullup 9 [pullup-9 #1348] PR/54564: Jan Schaumann: cp of a fifo yields an empty file

September 22, 2021

Pullup 8 [pullup-8 #1697] PR bin/56398 mkdir change for -8
Pullup 9 [pullup-9 #1347] PR bin/56398 mkdir change for -9

September 20, 2021

NetBSD Package System (pkgsrc) on DaemonForums pkg_add pkgin error
#PKG_PATH=http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/$/i386/$/9.1/All/
# export PKG_PATH
# pkg_add pkgin
# pkg_add: Cant process file.....

pkg_add http://ftp.netbsd.org/pub/pkgsrc/pac...20.12.1nb1.tgz

pkg_add: cant process, pkg_add: no pkg found for, pkg_add: 1 package addition failed

Ping works

September 17, 2021

DragonFly BSD Digest BSD Now 420: OpenBSD makes life better

This week’s BSD Now thankfully skips the pun that might go with the episode number, and talks about various OpenBSD and NetBSD articles.


September 15, 2021

NetBSD General on DaemonForums ImfRgbaFile.h: No such file or directory whyle installing KDE4 on NetBSD 9.2
Hello.

I'm trying to install kde4 on NetBSD 9.2 but right now unsuccesfully. I tried to do that using two methods :

1)

Code:

netbsd-marietto# pkgin install kde4

kde4 is not available in the repository

calculating dependencies...done.

nothing to do.


2)


Code:

cd /usr/pkgsrc/meta-pkgs/kde4

make

......

[ 91%] Building CXX object kimgio/CMakeFiles/kimg_exr.dir/exr.cpp.o

/usr/pkgsrc/x11/kdelibs4/work/kdelibs-4.14.38/kimgio/exr.cpp:15:10: fatal error: ImfRgbaFile.h: No such file or directory

#include <ImfRgbaFile.h>

^~~~~~~~~~~~~~~

compilation terminated.

gmake[2]: *** [kimgio/CMakeFiles/kimg_exr.dir/build.make:90: kimgio/CMakeFiles/kimg_exr.dir/exr.cpp.o] Error 1

gmake[1]: *** [CMakeFiles/Makefile2:27312: kimgio/CMakeFiles/kimg_exr.dir/all] Error 2

gmake: *** [Makefile:166: all] Error 2


it seems that it wants that I copy all the *.h files from


/usr/pkg/include/OpenEXR/

TO

/usr/pkgsrc/x11/kdelibs4/work/kdelibs-4.14.38/kimgio/


So ok. I've copied all the *.h files there,but the compilation wasn't succesfull anyway :


Code:

.....

[ 91%] Building CXX object kimgio/CMakeFiles/kimg_exr.dir/exr.cpp.o

[ 91%] Linking CXX shared module ../lib/kimg_exr.so

ld: cannot find -lImath

ld: cannot find -lIlmImf

ld: cannot find -lIex

ld: cannot find -lHalf

ld: cannot find -lIlmThread

gmake[2]: *** [kimgio/CMakeFiles/kimg_exr.dir/build.make:122: lib/kimg_exr.so] Error 1

gmake[1]: *** [CMakeFiles/Makefile2:27312: kimgio/CMakeFiles/kimg_exr.dir/all] Error 2

gmake: *** [Makefile:166: all] Error 2

NetBSD General on DaemonForums How to mount a Linux / Ubuntu ext4 partition on NetBSD
Hello to everyone.


I'm a new netBSD user. I'm trying to understand how to mount my Ubuntu / ext4 partitions directly in NetBSD. We are talking about this disk :


Code:

dmesg :


[ 3.081318] wd0 at atabus1 drive 0

[ 3.081318] wd0: <CT500MX500SSD4>

[ 3.081318] wd0: drive supports 1-sector PIO transfers, LBA48 addressing

[ 3.081318] wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors (0 bytes/physsect; first aligned sector: 8)

[ 3.081318] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags)

[ 3.081318] wd0(ahcisata0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags)

netbsd-marietto# gpt show wd0


Code:

GPT not found, displaying data from MBR.


start size index contents

0 1 MBR

1 2047 Unused

2048 976765625 1 MBR part 131 (active)

976767673 5495 Unused


netbsd-marietto# disklabel wd0


Code:

# /dev/rwd0:

type: ESDI

disk: wd0

label: fictitious

flags:

bytes/sector: 512

sectors/track: 63

tracks/cylinder: 16

sectors/cylinder: 1008

cylinders: 969021

total sectors: 976773168

rpm: 3600

interleave: 1

trackskew: 0

cylinderskew: 0

headswitch: 0 # microseconds

track-to-track seek: 0 # microseconds

drivedata: 0


5 partitions:


# size offset fstype [fsize bsize cpg/sgs]

d: 976773168 0 unused 0 0 # (Cyl. 0 - 969020)

e: 976765625 2048 Linux Ext2 0 0 # (Cyl. 2*- 969015*)

disklabel: boot block size 0

disklabel: super block size 0

I tried to mount it in two ways but none of them worked :


Code:

netbsd-marietto# mount -r -t ext2fs /dev/rwd0e /mnt/CT500-wd0-ext4

mount_ext2fs: /dev/rwd0e on /mnt/CT500-wd0-ext4: Block device required


netbsd-marietto# mount -r -t ext2fs /dev/wd0e /mnt/CT500-wd0-ext4

mount_ext2fs: /dev/wd0e on /mnt/CT500-wd0-ext4: incorrect super block


netbsd-marietto# mount -r -t ext4fs /dev/wd0e /mnt/CT500-wd0-ext4

mount: exec mount_ext4fs for /mnt/CT500-wd0-ext4: mount_ext4fs: No such file or directory


netbsd-marietto# mount -r -t ext4fs /dev/rwd0e /mnt/CT500-wd0-ext4

mount: exec mount_ext4fs for /mnt/CT500-wd0-ext4: mount_ext4fs: No such file or directory

Pullup 8 [pullup-8 #1696] ixgbe update

September 14, 2021

Stack Overflow ImportError: No module named libvirt error whyle trying to install python for libvirt on NetBSD 9.2

I've just installed virt-manager with pkgin on NetBSD 9.2 just because I want to emulate the virtual machines with qemu + nvmm on NetBSD 9.2. The installation of virt-manager went ok. But,when I ran it,an error came up :

netbsd-marietto# virt-manager

Traceback (most recent call last):

File "/usr/pkg/share/virt-manager/virt-manager.py", line 386, in <module>

main()

File "/usr/pkg/share/virt-manager/virt-manager.py", line 247, in main

from virtManager import cli

File "/usr/pkg/share/virt-manager/virtManager/cli.py", line 29, in <module>

import libvirt

ImportError: No module named libvirt

Googling a little bit maybe I've found the solution here :

https://www.unitedbsd.com/d/285-linux-user-and-netbsd-enthusiast-hoping-to-migrate-some-day

where "kim" said :

Looking at pkgsrc/sysutils/libvirt/PLIST it doesn't look like the package provides any Python bindings -- which is what the "ImportError: No module named libvirt" error message is about. You could try py-libvirt from pkgsrc-wip and see how that works out.

I tried to start the compilation like this :

netbsd-marietto# cd /home/mario/Desktop/pkgsrc-wip/py-libvirt
netbsd-marietto# make

but I've got this error :

make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 15: Could not find ../../wip/libvirt/buildlink3.mk
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 16: Could not find ../../lang/python/distutils.mk
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 17: Could not find ../../mk/bsd.pkg.mk
make: Fatal errors encountered -- cannot continue

If u want to see the content of the Makefile,it is :

gedit /home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile

#$NetBSD: Makefile,v 1.32 2018/11/30 09:59:40 adam Exp $

PKGNAME= ${PYPKGPREFIX}-${DISTNAME:S/-python//}
DISTNAME= libvirt-python-5.8.0
CATEGORIES= sysutils python
MASTER_SITES= https://libvirt.org/sources/python/

MAINTAINER= [email protected]
HOMEPAGE= https://libvirt.org/sources/python/
COMMENT= libvirt python library
LICENSE= gnu-lgpl-v2

USE_TOOLS+= pkg-config

.include "../../wip/libvirt/buildlink3.mk"
.include "../../lang/python/distutils.mk"
.include "../../mk/bsd.pkg.mk"

Can someone help me to fix the error ? very thanks.


September 13, 2021

Pullup 9 [pullup-9 #1346] ixgbe update

September 10, 2021

UnitedBSD Trying to install the driver for my main GPU,the Intel UHD Graphics 630.(i915)

Hello to everyone.

I'm a new net-bsd user. I'm learning and trying this OS. The first step is to configure correctly the resolution of my screen. On my PC I have 3 graphic cards :

1) 000:02:0: Intel UHD Graphics 630 (VGA display, revision 0x02)

2) 001:00:0: NVIDIA product 1e04 (VGA display, revision 0xa1) : (NVIDIA RTX 2080ti)

3) 002:00:0: NVIDIA GeForce GTX 1060 3GB (VGA display, revision 0xa1)

Good. On the BIOS I have configured the Intel UHD Graphics 630 as primary GPU device. In addition I have installed XFCE4. The problem that I have is that I can't increase the default resolution that have been chosen automatically,that's 1024x768. Probably I haven't installed the correct driver,I don't know. Below u can see all the hardware specs of my PC :

netbsd-marietto# pcictl pci0 list

000:00:0: Intel Xeon E (S, Desktop) Host Bridge, DRAM (host bridge, revision 0x0d)

000:01:0: Intel Core 6G PCIe x16 (PCI bridge, revision 0x0d)

000:01:1: Intel Core 6G PCIe x8 (PCI bridge, revision 0x0d)

000:02:0: Intel UHD Graphics 630 (VGA display, revision 0x02)

000:18:0: Intel 300 Series Thermal (miscellaneous DASP, revision 0x10)

000:20:0: Intel 300 Series USB 3.1 xHCI (USB serial bus, xHCI, revision 0x10)

000:20:2: Intel 300 Series Shared SRAM (RAM memory, revision 0x10)

000:22:0: Intel 300 Series MEI (miscellaneous communications, revision 0x10)

000:23:0: Intel 300 Series SATA (AHCI) desktop (SATA mass storage, AHCI 1.0, revision 0x10)

000:27:0: Intel 300 Series PCIe (PCI bridge, revision 0xf0)

000:28:0: Intel 300 Series PCIe (PCI bridge, revision 0xf0)

000:28:5: Intel 300 Series PCIe (PCI bridge, revision 0xf0)

000:29:0: Intel 300 Series PCIe (PCI bridge, revision 0xf0)

000:31:0: Intel Z390 LPC (ISA bridge, revision 0x10)

000:31:3: Intel 300 Series cAVS (mixed mode multimedia, revision 0x10)

000:31:4: Intel 300 Series SMBus (SMBus serial bus, revision 0x10)

000:31:5: Intel 300 Series SPI (FLASH) (miscellaneous serial bus, revision 0x10)

000:31:6: Intel I219-V Ethernet Connection (ethernet network, revision 0x10)

001:00:0: NVIDIA product 1e04 (VGA display, revision 0xa1)

001:00:1: NVIDIA product 10f7 (mixed mode multimedia, revision 0xa1)

001:00:2: NVIDIA product 1ad6 (USB serial bus, xHCI, revision 0xa1)

001:00:3: NVIDIA product 1ad7 (miscellaneous serial bus, revision 0xa1)

002:00:0: NVIDIA GeForce GTX 1060 3GB (VGA display, revision 0xa1)

002:00:1: NVIDIA product 10f1 (mixed mode multimedia, revision 0xa1)

003:00:0: Micron/Crucial Technology product 5403 (Flash mass storage, NVMe, revision 0x03)

005:00:0: Renesas Technologies uPD720201 USB 3.0 Host Controller (USB serial bus, xHCI, revision 0x03)

netbsd-marietto# dmesg

[ 15.871239] wsdisplay0: screen 1 added (default, vt100 emulation)

[ 15.871239] wsdisplay0: screen 2 added (default, vt100 emulation)

[ 15.871239] wsdisplay0: screen 3 added (default, vt100 emulation)

[ 15.871239] wsdisplay0: screen 4 added (default, vt100 emulation)

I've installed this server Xorg :

modular-xorg-server-1.20.11 Modular X11 server from modular X.org

At the moment I've installed these drivers with the command pkgin install : (please be patient if I made some mistake,I'm experimenting / learning)

**intel-vaapi-driver-2.4.0 VA-API user mode driver for Intel GEN Graphics family

xf86-video-intel-2.99.917.20200515 Modular Xorg Intel video driver**

Probably one some of them shouldn't be installed ?

And I'm not using any xorg.conf file because the one that I have generated with the command : Xorg -configure does not work at all,so I have removed it. I mean the one that u see below :

https://pastebin.ubuntu.com/p/9bSCXjnZZm/

Below u can read the Xorg log file :

https://pastebin.ubuntu.com/p/9PnxYmkqxH/

It's all. I would like to understand how to configure correctly my Intel graphic integrated chipset. Very thanks.

Ruben Schade Comparing FreeBSD GELI and OpenZFS encrypted pools with keys

I have a confession. As opposed to a professioion? WHOA, is that how that works? Don’t answer that.

I’ve mentioned many times how excited I was for OpenZFS in FreeBSD 13, due in no small part to its inline encryption capabilities. I’d used the closed-source equivalent on the last Solaris, and had made some proof of concepts on the -CURRENT branch, but I hadn’t used it for any real world data. I also didn’t feel as compelled to rush out and replace my GELI encrypted volumes as I first thought. It still works, and will for the foreseeable future.

A shiny new set of drives for my home server finally gave me the kick up the proverbial posterior to give it a shot with some prod data that definitely isn’t a Plex server for anime. This was my story. DUN DUN.

The existing GELI approach

We’ve always been able to encrypt ZFS on FreeBSD, albeit with an intermediate layer performing the encryption before our data hits the disk. GELI was the most recent and accepted tool to achieve this, akin to cgd on NetBSD, or LUKS on Linux. It’s proven, well tested, and secure, like my hat. Wait, what?

Here’s an example of a typical encrypted ZFS volume using GELI. We create a new GPT layout, label it (you’ll be glad you did), create a key, create a new virtual GELI encrypted block device, then build our ZFS pool on top. Note in the final step we reference the virtual encrypted device:

# _LABEL="12TB-IronWolf-SERIALNO"
# _KEY="/root/example.key"
	
# gpart -s create gpt /dev/ada5
# gpart add -t freebsd-zfs -l "$_LABEL" /dev/ada5
	
# openssl rand -hex 32 | tee "$_KEY"
# geli init -P -K "$_KEY" "/dev/gpt/$_LABEL"
# geli attach -pk "$_KEY" "/dev/gpt/$_LABEL"
	
# zpool create pool "/dev/gpt/${_LABEL}.eli"
# zfs create pool/tank

This uses a plain disk, but you could just as easily build this on top of an iSCSI mount, or a HAST volume. When you restart, you perform the geli attach then zpool import as normal.

The key here is you’re encrypting the entire partition beneath ZFS. GELI is device and file-system agnostic, and ZFS is unaware (AFAIK) that it’s operating within a virtual encrypted device. This may still be preferable in some circumstances, as we’ll get to in a moment.

OpenZFS inline encryption

By contrast, is a phrase with two words. OpenZFS’s native encryption operates at the dataset level, negating the need for a GELI device that has to be mounted separately. What’s even cooler is that all of ZFS’s data integrity, deduping, compression, exports, and other features can operate on these encrypted datasets, even if they’re not imported/mounted. Cray!

You can prepare your drive with gpart(8) and create a key as per above. After that, we create a zpool(8), which has the encryption feature available by default on FreeBSD 13:

# zpool create pool "/dev/gpt/$_LABEL"
	
# zpool get [email protected] pool
==> pool [email protected] active local

Then create a new encrypted volume. You can also verify the operation and check the encryption scheme used with zfs-get(8):

# zfs create -o encryption=on -o keyformat=hex \
	-o keylocation=file:///root/example.key pool/tank 
   
# zfs get encryption,keylocation,keyformat pool/tank
==> NAME       PROPERTY     VALUE                     SOURCE
==> pool/tank  encryption   aes-256-gcm               -
==> pool/tank  keylocation  file:///root/example.key  local
==> pool/tank  keyformat    hex

Wait, hold on, that’s it? Yes! How cool is that!?

Gotchas

I had initially assumed that using keys would result in the zfs datasets automounting when the zpool is imported, which is not the case. Even if their key is available, you must import them first before the zfs dataset is mounted and ready to use (it looks like an rc.d service was written and reviewed to facilitate doing this on boot, which I’ll need to investigate).

The easiest way to do this is with the lowercase L option in zpool(8) import, which retrieves all the keys it can before mounting your encrypted datasets:

# zpool import pool -l

Or you can load all available keys with zfs(8) load-key:

# zpool import pool
# zfs load-key -a

Refer to the linked man pages for more details. Even if you don’t need more details, and just want to marvel at what well-documented software looks like. The GNU people could learn a lesson or two (or three).

Considerations

As I eluded to above, there are a couple of caveats. GELI encrypts whatever data is handed to it, whereas OpenZFS necessarily stores metadata about the datasets in order to use them. This includes dataset and snapshot names. Bear (bare?) that in mind when you’re naming and structuring your datasets.

This is speculation on my part, but I’d also think there’d be a chance for plausible deniability in a device that’s been completely encrypted with GELI, just as any device that uses whole drive encryption. By contrast, OpenZFS dataset metadata makes it obvious that they contain encrypted data, and the scheme with which the data was encrypted. I could be wrong here though.

Overall, is an item of clothing. OpenZFS encryption makes the system administrator’s life easier, and those caveats don’t concern me for how I store my data. I’ll be using it for everything going forward.

Allan Jude and Kyle Kneisl’s FreeBSD Journal article from last year is a great resource if you’d like to learn more about the implementation of OpenZFS’s encryption system. I also found Jim Salter’s article useful in Ars Technica for learning about key management; once you block all the irrelevant autoplaying videos. #ModernWeb

DISCLAIMER: Cryptography is critical to get right, or it’s not worth doing. Always read and follow the official documentation over someone’s blog, even if the blog has a cute anime mascot and is written by someone with the best of intentions and an awesome hat.

By Ruben Schade in Sydney, 2021-09-11.

Pullup 8 [pullup-8 #1695] build.sh support for git/hg
Pullup 9 [pullup-9 #1345] build.sh support for git/hg
Pullup pkgsrc [pullup-pkgsrc #6499] [[email protected]: CVS commit: pkgsrc/www/firefox78]
Pullup pkgsrc [pullup-pkgsrc #6498] [[email protected]: CVS commit: pkgsrc/www/firefox78-l10n]

September 09, 2021

Pullup pkgsrc [pullup-pkgsrc #6497] [[email protected]: CVS commit: pkgsrc/audio/libsndfile]

September 07, 2021

Pullup 8 [pullup-8 #1694] [[email protected]: CVS commit: src/distrib/sets]
Pullup 9 [pullup-9 #1344] [[email protected]: CVS commit: src/distrib/sets]
Pullup pkgsrc [pullup-pkgsrc #6496] [[email protected]: CVS commit: pkgsrc/chat/weechat]
Server Fault ssh tunnel refusing connections with "channel 2: open failed"

All of a sudden (read: without changing any parameters) my netbsd virtualmachine started acting oddly. The symptoms concern ssh tunneling.

From my laptop I launch:

$ ssh -L 7000:localhost:7000 [email protected] -N -v

Then, in another shell:

$ irssi -c localhost -p 7000

The ssh debug says:

debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3

I tried also with localhost:80 to connect to the (remote) web server, with identical results.

The remote host runs NetBSD:

bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov  4 16:56:31 MET 2011  [email protected]:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386

I am a bit lost. I tried running tcpdump on the remote host, and I spotted these 'bad chksum':

09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>

I tried restarting the ssh daemon to no avail. I haven't rebooted yet - perhaps somebody here can suggest other diagnostics. I think it might either be the virtual network card driver, or somebody rooted our ssh.

Ideas..?


September 06, 2021

Ruben Schade Feedback on my “not sure if UNIX won” post

I wrote a post back in May saying I wasn’t sure that UNIX won, as so many media outlets were claiming. I said I was on the fence, but that I saw Linux continue to depart from UNIX’s legacy in meaningful ways. It’s since been picked up and circulated on the usual news aggregator sites and social media, most of which have generated relevant, tactful comments that swayed my opinion and… nah, got you!

Nobody that I could see challenged the post’s premise that UNIX didn’t win (which for certain Linux and BSD folks was seen as a bad thing for the ongoing project of cross-platform compatibility and good system design, or fabulous by others who claimed it freed their systems from perceived UNIX baggage).

Great, end of the post then, time for a beer! Wait, what do you mean it’s Tuesday morning?

Play Spanish Flea

By Ruben Schade in Sydney, 2021-09-07.

UnitedBSD Allow emails only with authorized addresses or domains

Can we restrict Incoming emails to specific or contact book of emails only? Any GUI client for this features in pkgsrc ?
https://support.google.com/a/answer/2640542?hl=en#zippy=%2Cstep-optional-create-a-customized-rejection-notice%2Cstep-optional-bypass-this-setting-for-internal-messages

UnitedBSD NetBSD on Lenovo X1 Carbon -- Problems!

Guys, I've been waiting all week for my Lenovo X1 Carbon to arrive. Finally FedEx dropped it off today. First thing I did, is I attempted to upgrade the SSD and realized that the gen2 doesn't support NVMe flash. Bummer. No electronics store in my area has an M.2 SATA SSD. That's ok, I'll go ahead and install NetBSD anyways.

So now I have some issues. I was very much looking forward to NetBSD on this laptop, but I feel a bit disappointed thus far.

First issue, I'm absolutely addicted to two finger scrolling on the touchpad. It's a MUST have for me. Unfortunately, that doesn't seem to work. I've not been able to find any sysctl or other tuning I can do to make that work.

I also cannot control my brightness. No matter what method I try. The buttons do not work (which I've seen others say online). That's fine, I'll use xbacklight. Except it returns an error "No outputs have backlight property." Hmm, ok. So I try to set hw.acpi.acpiout0.brightness to a value other than 100, but it doesn't work. It doesn't return an error, and the output looks like it actually changes the brightness, but if I check the value immediately afterwards, it's still 100.

xfce also can't read the battery status. I see also many people complain about that online, and it seems as though that's due to xfce attempting to use apm instead of envstat. Ok fine, no big deal, I can check my battery via other means, and as mentioned this is actually an xfce problem rather than a NetBSD problem. I'm trying to think of a hackish way I can make it work, but at the end of the day I may need to sit down and try to come up with a patch to submit upstream to xfce.

I'm running 9.2-stable (dated 9/3). I can update to -head but I'm not super confident it'll do much, but it couldn't hurt I suppose.

Also, there's no screen saver config panel in xfce, strange. I can't seem to find it anywhere.

Any help/suggestions would be greatly appreciated! I can also post necessary output as needed, wasn't sure what to include at this point.


September 04, 2021

DragonFly BSD Digest In Other BSDs for 2021/09/04

Note the last link; BSD and M1.

 

 


August 30, 2021

Pullup 8 [pullup-8 #1693] fix vte(4) on Vortex86DX3
UnitedBSD NetBSD and SSDs

Hello all! After some consideration, I just ordered a ThinkPad X1 Carbon (2nd gen) off eBay, and expect it to arrive this week. My intention is to install NetBSD on it.

I haven't been able to turn up much info yet, but wanted to get some thoughts on if any special considerations need to be done to tune NetBSD to running on SSDs. My current primary machine is a ThinkPad T420 running Endeavour (Arch-based Linux distro) and I recall having to tune some things so it wouldn't aggressively wear out the drive. Just trying to get a feel for if that's necessary on NetBSD or not.

I also have an old Lenovo Flex 3-1120 that I installed OpenBSD on last week. Aside from the fact that this particular hardware is very slow (also has a spinning hard drive), I've been impressed with OpenBSD so far in terms of it just working with very little tuning needed.

Thanks in advance!


August 28, 2021

DragonFly BSD Digest In Other BSDs for 2021/08/28

Longer reading this week.

Pullup pkgsrc [pullup-pkgsrc #6495] [[email protected]: CVS commit: pkgsrc/www/firefox78-l10n]

August 26, 2021

NetBSD Blog wifi project status update

After initial work on the wifi renewal branch went quite fast and smooth, things have slowed down a bit in the last few months.

Most of the slow down was due to me not being available for this type of work for unexpectedly long times - a problem that should be fixed now.

However, there were other obstacles and unexpected issues on the way:

The current state of driver conversion and what drivers are still open are listed in the wifi driver conversion matrix.

Next steps ahead are:

Currently it is not clear if this branch can be merged to HEAD before branching for netbsd-10. We will not delay the netbsd-10 branch for this.


August 21, 2021

DragonFly BSD Digest In Other BSDs for 2021/08/21

I have some barely-BSD links this week but I don’t think you’ll mind.


August 17, 2021

NetBSD General on DaemonForums GOP mode in /boot.cfg
Hi there,

for a better Xorg-resolution I use the wsfb driver in NetBSD 9.2 running on an Intel NUC. I do this cause the i915 driver is not working.
So I use the wsfb. However even this driver gives a bad resolution of 1024x768.
So additionally I changed the GOP mode at the bootprompt simply with "gop 0", which now allows a 1280x1024 resolution - much better.

No I tried to make this permanent in /etc/boot.fg. I tried gop 0, gop=0, gop= mode 0 - but nothing works. Only when I enter the UEFI menu and type my gop 0 at the boot prompt it works.

Can anybody give me a hint for the correct syntax writing the gop command into boot.cfg? That would be nice.

Regards
Berni

August 08, 2021

Ruben Schade Troubleshooting netatalk3 in a FreeBSD jail

Netatalk3 is a file server for exporting storage to Macs. Samba has long been considered its replacement, but to this day Netatalk still handles file labels and other Mac-specific metadata more reliably and with greater performance. One day I’ll properly try replicating this in Samba.

I installed it in a new FreeBSD jail:

# pkg install net/netatalk3

Then configured it largely the same as I did on FreeBSD in 2014, and on NetBSD last year. Only this time, all the Macs in the house refused to talk to it.

I tail’d /var/log/daemon.log in the jail and was inundated with afpd(8) spam:

netatalk[34758]: Restarting 'afpd' (restarts: 7)
afpd[42393]: dsi_tcp_init(*): getaddrinfo: Name does not resolve
afpd[42393]: No suitable network config for TCP socket
afpd[42393]: no suitable network address found, use "afp listen" or "afp interfaces"
afpd[42393]: main: no servers configured

I followed the error’s advice and added the IP address of the jail to the [Global] section of my /usr/local/etc/afp.conf file:

afp listen = <IP Address>

It worked, and I was able to log in, as shown in the logs:

afpd[88524]: Netatalk AFP/TCP listening on <IP Address>:548

I don’t recall ever having to add a specific interface or IP address to an afp.conf file before on a FreeBSD or NetBSD host. My hunch is it has something to do with the jail environment, and dsi_tcp_init not being able to autodetect or initialise the jail’s virtual network interface. Please correct me if you have more details!

By Ruben Schade in Sydney, 2021-08-08.


August 02, 2021

Ruben Schade Expanding our FreeBSD home file server

This is what I’d call a thinking out loud about personal circumstances post, rather than anything prescriptive or useful for discerning computators general. You’ve been warned!

Clara and I are running low on drive space on our OpenZFS file server, once again. We have a running joke that driveageddon seems to rear its fragmented head every August. Maybe it’s a self-fulfilling prophecy, though it’s files doing all the filling on these implausibly-fast spinning platters of metal.

(Has someone made a discus anime?)

Our FreeBSD server is the centre of our world. It uses a combination of NetBSD and Debian VMs running in Xen (to be replaced with bhyve at some point) and FreeBSD jails to serve and delegate anything we can offload from our personal and work machines. I have other boxes for tinkering and testing, but this one runs the latest -RELEASE with as unexotic a configuration as I can make it. Vim is saying unexotic isn’t a word. It’s probably right.

My attitude for at least the last six years (possibly longer) has been to buy a pair of the largest drives I can afford, and to cycle out the oldest pair. 2019 was the year I finally said goodbye to a pair of HGST 3 TB units that had performed flawlessly for almost a decade. They’re now in anti-static bags in a safe-deposit box, acting as a cold backup for our most critical family photos and documents.

There’s a thought there that I haven’t had to replace a hard drive due to outright failure in a long time, but I’d dare not mention that here lest I invoke the wrath of Murphys Law. Good thing I didn’t.

But here’s the thing. This time I’m not faced with the same space or chipset constraints, so I could add more drives instead of swapping. Last year I replaced our workhorse HPE Microserver with a refurbished Supermicro workstation board with 8× SATA and 2× NVMe (albeit one on a PCI-E daughterboard) and an old Antec 300 case with 8 LFF drive bays. I even considered getting an additional RAID controller, provided I could use it in JBOD mode for ZFS. That was an unconscionable number of abbreviations and acronyms, and I’m not even a network engineer.

You could argue the timing is great. Chia has driven up the cost of drives, meaning this year I won’t be getting as much of a capacity jump as I have in previous years. Granted going from 4 to 10 would be nice, but it’s still only 6 TB of effective extra space for many hundreds of dollars; not to mention that I insist on using ZFS mirrors for redundancy and ease of replacements/upgrades. Adding drives instead will give me all the extra capacity.

It all makes sense, but my main concerns are still noise and heat. Clara and I live in a one-bedroom apartment now, which is much nicer than sleeping in a studio while the computer in the other end of the room loudly seeks and scrubs its ZFS pools on a recurring basis. But we work from home now, and I have experience with specific WD drives in my bedroom growing up that I don’t want to inadvertently repeat. I’d likely tolerate it, but it’s not fair to Clara having something clicking and buzzing away within earshot all day.

We’ve lucked out thus far with our current HGST, WDs, and Seagates. The read/write heads on the SSDs are also so silent as to be practically non-existent (cough)! But I’ve read reviews of current larger drives of people complaining about noise; the WD Golds and Toshibas seem to frequently cause people ire.

This post was as open-ended as the bag of kettle chips I regret eating. Maybe I need to do some Acoustic Research.

By Ruben Schade in Sydney, 2021-08-03.


July 22, 2021

Ruben Schade Comparing PC all-in-ones to the iMac

I love that colours are back with the iMacs, though their soldered storage makes them a non-starter for me. Still, I thought I would be an interesting experiement to see if PC makers care at all to compete with Apple in the AiO market segment, or whether they’re saddled with PC Screen Syndrome.

I checked a few Australian online stores this morning, and the results were as surprising as discovering that I’m a bit awkward in real life:

I’m seeing more IPS panels, which is fantastic! Some even have touch screens, something I consider a bit of a gimmick but that Apple doesn’t ship with. But these specs and prices simply don’t compete with a 24-inch iMac with a 4.5K display for $1,900, and a 27-inch 5K iMac for $2,700. You could fit four of those AiO computer screens into one iMac, and the price is barely different!

Apple have sold Retina/HiDPI screen iMacs for years, yet PC makers continue to ship displays with a lower resolution than your phone. Yes I sound like a broken record here, but it’s only because it continues to flabbergast me! That’s a word, right?

You might think the all-in-one desktop segment makes no sense. They don’t for my use cases, either. But the fact PC makers are fine ceding technical superiority to Apple in the interest of pushing 1080p panels that were outdated a decade and a half ago, and for the same money, makes as much sense as enlisting me for your basketball team. Sure I have the height, but my hand-eye coordination is off on account of looking at crappy screens!

Focus, Ruben.

This leads me to something I’ve been mulling over for a while now. Why have PC makers lost that spark? Is it margins? Has the mindshare and innovation moved on to phones? Is it Microsoft failing to provide compelling updates for Wintel boxes that would make effective use of the new tech? Are the bean counters in charge of engineering? It seems gaming rigs are the only place where innovation is happening anymore, and have you seen some of those designs? Even teenage Ruben would look at those RGBs and say “that’s a bit much, innit?”

I still remember a time when PC makers could tout the fact that while Apple computers looked better and arguably had a better OS, they had better tech for a cheaper price. All they can claim now in an M1 world is wider compatibility, and even then the industry seems to be moving towards ARM at break arm speed. Get it, instead of break neck speed, because it’s called… oh shut up.

I’ve never exclusively been a Mac user. I’ve tended to use the Mac as my primary desktop/laptop, but delegate as much as I can to a tower and home servers running FreeBSD, NetBSD, and/or Debian Linux as required. The former gave me the best desktop experience to run work applications, and the latter let me tinker and build to an exact specification and price. I haven’t been in the market for a pre-built PC for years, but it’s been grim every time I’ve looked.

The tech is there, PC makers. Please lift your game!

By Ruben Schade in Sydney, 2021-07-22.


July 14, 2021

The NetBSD Foundation New Security Advisory: NetBSD-SA2021-002

July 05, 2021

OS News First ‘new VAX’ in 30 years, 64-bit extensions proposed

Anders Magnusson, writing on the Port-vax NetBSD mailing list:

Some time ago I ended up in an architectural discussion (risc vs cisc etc…) and started to think about vax. Even though the vax is considered the “ultimate cisc” I wondered if its cleanliness and nice instruction set still could be implemented efficient enough. Well, the only way to know would be to try to implement it 🙂 I had an 15-year-old demo board with a small low-end FPGA (Xilinx XC3S400), so I just had to learn Verilog and try to implement something. And it just passed EVKAA.EXE:

Along with the development of a VAX implementation in an FPGA, discussions arose about possible 64-bit extensions:

For userspace; the vax architecture itself leave the door open for expanding the word size. The instructions are all defined to use only the part of a register it needs, so adding a bunch of ‘Q’ instructions are a no-brainer. Argument reference will work as before. The JMP/JSR/RET/… might need a Q counterpart, since it suddenly store/require 8 bytes instead of 4. Kernel; the hardware structures (SCB, PCB, …) must all be expanded. Memory management changed (but the existing leave much to wish for anyway). All this is probably a quite simple update to the architecture.

It’s nice to see people still putting work and effort into what is nearly a half-century old, and otherwise obsolete, instruction set.


July 01, 2021

The NetBSD Foundation New Developer in June 2021

June 16, 2021

NetBSD Installation and Upgrading on DaemonForums Is building from source the only option?
After using OpenBSD for a few years now, and FreeBSD on and off, I decided I should give NetBSD a try. Please don't take my question as a complaint, it is not. I am liking what I have seen so far. Completely fabulous on my X230. Pkgsrc is awesome, and the system is pretty intuitive to me.

As far as applying system updates to stable, is building from source the only option?

I have been searching around and that is the only option I see in their documentation. If so, how do people solve upgrading for smaller devices like the Pi, or a Beaglebone? Surely they are not building on those devices?

I assume on would build on another device and then install with sysupgrade, but wanted to check in case I was making more work for myself than necessary.

June 10, 2021

NetBSD Blog Support for chdir(2) in posix_spawn(3)

This post was written by Piyush Sachdeva:

What really happens when you double click an icon on your desktop?

Support for chdir(2) in posix_spawn(3)

Processes are the bread and butter of your operating system. The moment you double click an icon, that particular program gets loaded in your Random Access Memory (RAM) and your operating system starts to run it. At this moment the program becomes a process. Though you can only see the execution of your process, the operating system (the Kernel) is always running a lot of processes in the background to facilitate you.

From the moment you hit that power button, everything that happens on the screen is the result of some or the other process. In this post we are going to talk about one such interface which helps in creation of your programs.

The fork() & exec() shenanigans

The moment a computer system comes alive, it launches a bunch of processes. For the purpose of this blog let’s call them, ‘the master processes’. These processes run in perpetuity, provided the computer is switched on. One such process is init/systemd/launchd (depending on your OS). This ‘init’ master process owns all the other processes in the computer, either directly or indirectly.

Operating systems are elegant, majestic software that work seamlessly under the hood. They do so much without even breaking a sweat (unless it’s Windows). Let's consider a scenario where you have decided to take a trip down memory lane and burst open those old photos. The ‘init master process’ just can’t terminate itself and let you look at your photos. What if you unknowingly open a malicious file, which corrupts all your data? So init doesn’t just exit, rather it employs fork() and exec() to start a new process. The fork() function is used to create child processes which are an exact copy of their parents. Whichever process calls fork, gets duplicated. The newly created process becomes the child of the original running process and the original running process is called the parent. Just how parents look after their kids, the parent process makes sure that the child process doesn't do any mischief. So now you have two exactly similar processes running in your computer.

One might think that the newly created child process doesn’t really help us. But actually, it does. Now exec() comes into the picture. What exec() does is, it replaces any process which calls it. So what if we replace the child process, the one we just thought to be useless, with our photos? That's exactly what we are going to do indeed. This will result in replacement of the fork() created child process with your photos. Therefore, the master init process is still running and you can also enjoy your photos with no threat to your data.

“Neither abstraction nor simplicity is a substitute for getting it right. Sometimes, you just have to do the right thing, and when you do, it is way better than the alternatives. There are lots of ways to design APIs for process creation; however, the combination of fork() and exec() is simple and immensely powerful. Here, the UNIX designers simply got it right.” Lampson’s Law - Getting it Right

Now you could ask me, `But what about the title, some ‘posix_spawn()’ thing?´ Don’t worry, that’s next.

posix_spawn()

posix_spawn() is an alternative to the fork() + exec() routine. It implements fork() and exec(), but not directly (as that would make it slow, and we all need everything to be lightning fast). What actually happens is that posix_spawn() only implements the functionality of the fork() + exec() routines, but in one single call. However, because fork() + exec() is a combination of two different calls, there is a lot of room for customization. Whatever software you are running on your computer, calls these routines on its own and does the necessary. Meanwhile a lot is cooking in the background. Between the call to fork() and exec() there is plenty of leeway for tweaking different aspects of the exec-ing process. But posix_spawn doesn’t bear this flexibility and therefore has a lot of limitations. It does take a lot of parameters to give the caller some flexibility, but it is not enough.

Now the question before us is, “If fork() + exec() is so much more powerful, then why have, or use the posix_spawn() routine?” The answer to that is, that fork() and exec() are UNIX system routines. They are not present in operating systems that are not a derivative of UNIX. Eg- Windows implements a family of spawn functions.
There is another issue with fork() (not exec() ), which in reality is one of the biggest reasons behind the growth of posix_spawn(). The outline of the issue is that, creating child processes in multi-threaded programs is a whole another ball game altogether.

Concurrency is one of those disciplines in operating systems where the order in which the cards are going to unravel is not always how you expect them to. Multi-threading in a program is a way to do different and independent tasks of a program simultaneously, to save time. No matter how jazzy or intelligent the above statement looks, multi-threaded programs require an eagle’s eye as they can often have a lot of holes. Though the “tasks” are different and independent, they often share a few common attributes. When these different tasks due to concurrency start running in parallel, a data race begins to access those shared attributes. To not wreak havoc, there are mechanisms through which, when modifying/accessing these common attributes (Critical Section) we can provide a sort of mutual exclusion (locks/conditional variables) - only letting one of the processes modify the shared attribute at a time. Here when things are already so intricate due to multithreading, and to top it off, we start creating child processes. Complications are bound to arise. When one of the threads from the multi-threaded program calls fork() to create a child process, fork() does clone everything (variables, their states, functions, etc) but it fails to clone other threads (though this is not required at all times).

The child process now knows only about that one thread which called fork(). But all the other attributes of the child that were inherited from the parent (locks, mutexes) are set from the parent’s address space (considering multiple threads). So there is no way for the child process to know which attributes conform to which parts of the parent. Also, those mechanisms that we used to provide mutual exclusion, like locks and conditional variables, need to be reset. This reset step is essential in letting the parent access it’s attributes. Failing this reset can cause deadlocks. To put it simply, you can see how difficult things have become all of a sudden. The posix_spawn() call is free from these limitations of fork() encountered in multi-threaded programs. However, as mentioned by me earlier, there needs to be enough rope to meet all the requirements before posix_spawn() does the implicit exec().

About my Project

Hi, I am Piyush Sachdeva and I am going to start a project which will focus on relaxing one limitation of posix_spawn - changing the current directory of the child process, before the said call to exec() is made. This is not going to restrict it to the parent’s current working directory. Just passing the new directory as one of the parameters will do the trick. Resolving all the impediments would definitely be marvelous. Alas! That is not possible. Every attempt to resolve even a single hindrance can create plenty of new challenges.

As already mentioned by me, posix_spawn() is a POSIX standard. Hence the effect of my project will probably be reflected in the next POSIX release. I came across this project through Google Summer of Code 2021. It was being offered by The NetBSD Foundation Inc. However, as the slots for Google Summer of Code were numbered, my project didn’t make the selection. Nevertheless, the Core Team at The NetBSD Foundation offered me to work on the project and even extended a handsome stipend. I will forever be grateful to The NetBSD Foundation for this opportunity.

Notes

References

  1. Operating Systems: Three Easy Pieces by Andrea C. Arpaci-Dusseau and Remzi H. Arpaci-Dusseau.
  2. Advanced Programming in the UNIX Environment by W. Richard Stevens and Stephen A. Rago.
  3. UNIX and Linux System Administration Handbook by Evi Nemeth, Garth Synder, Trent R. Hein, Ben Whaley and Dan Mackin.

June 08, 2021

Frederic Cambus Diving into toolchains

I've been wanting to learn more about compilers and toolchains in general for a while now. In June 2016, I asked about recommended readings on lexers and parsers on Twitter. However, I have to confess that I didn't go forward with reading the Dragon Book.

Instead, I got involved as a developer in the OpenBSD and NetBSD projects, and witnessing the evolution of toolchains within those systems played a big role in maintaining my interest and fascination in the topic. In retrospect, it now becomes apparent that the work I did on porting and packaging software for those systems really helped to put in perspective how the different parts of the toolchains interact together to produce binaries.

Approximately one year ago, I asked again on Twitter whether I knew anyone having worked on compilers and toolchains professionally to get real world advice on how to gain expertise in the field. I got several interesting answers and started to collect and read more resources on the topic. Some of the links I collected ended up on toolchains.net, a collection of toolchain resources which I put online in February.

But the answer that resonate the most with me was Howard's advice to learn by doing. Because I seem to be the kind of person who need to see some concrete results in order to keep motivated, that's exactly what I decided to do.

I started by doing some cleanups in the binutils package in NetBSD's pkgsrc, which resulted in a series of commits:

Meanwhile, I also got the opportunity to update our package and apply security fixes:

I eventually took maintainership of binutils in Pkgsrc.

Building it repeatedly with different compilers exposed different warnings, and I've also run builds through Clang's static analyzer.

All of this resulted in the opportunity to contribute to binutils itself:

Most recently, I also wrote a couple of blog posts on the topic:

And the journey continues. I'm following a different path from traditional compiler courses starting with lexers and parsers, and doing the opposite curriculum somehow, starting from binaries instead. I will be focusing on the final stages of the pipeline for now: compiling assembly to machine code and producing binaries.

My next steps are to read the full ELF specification, followed by the Linkers and Loader book, and then refresh my ASM skills. My favorite course at university was the computer architecture one and especially its MIPS assembly part, so I'm looking to revisit the subject but with ARM64 assembly this time.


June 07, 2021

OS News FreeBSD from a NetBSD user’s perspective

I’ve been a NetBSD developer for three years and it’s been my primary operating system for a long time too – on everything: routers, laptops, Raspberry Pis, PowerPC mac minis, Vortex86 embedded boards, and servers.

I’ve recently been using FreeBSD a lot at work. We have a lot of servers and embedded boards running it, and I was given the option of installing anything I wanted on my workstation. I chose FreeBSD to maintain a separation of BSDs between my work and home life 😉

I thought I’d write a little bit about some differences that stand out to me. Since everyone that knows me well knows that typical use cases like web hosting aren’t really my jam, and I’m more of an embedded, audio, and graphics person, maybe I can offer a more uncommon perspective.

It’s always nice to read perspectives like this.


June 03, 2021

Frederic Cambus NetBSD on the Vortex86DX CPU

I'm not exactly sure how I first heard about the Vortex86 CPUs, I think it was either when seeing the demonstration video on KolibriOS project site showcasing the system running on a DMP EBOX machine, or when skimming NetBSD's identcpu.c code. Or did the discovery of the machine prompted me to check if the CPU would be correctly probed by the NetBSD's kernel?

For those interested, Wikipedia has an article retracing the history of the Vortex86 from its birth at Rise to our days.

Several DMP EBOX machines are available for sale at various specialized vendors, but new devices cost several hundreds of dollars which is prohibitive for such low spec systems. However, I was recently able to acquire a boxed older model on a local auction site for about $25: the EBOX 3300A-H, with a 1GHz CPU and 256MB of RAM, no less.

As I already mentioned, those machines are quite slow but they still do have a few things going for them:

I used a power meter to do measurements, and an idle system consumes 5.3W. Power consumption peaked at 6.4W when running the OpenSSL speed benchmark.

There is space for a 2.5" hard drive in the enclosure, but I don't have any IDE drives anymore so I opted to use old CompactFlash cards I had laying around. As a side note, it's actually exquisite to use those cards like glorified floppies :-)

For this post, I used a 1GB CompactFlash card and selected a minimal installation in sysinst.

The installed system takes 212M:

Filesystem         Size       Used      Avail %Cap Mounted on
/dev/wd0a          919M       212M       661M  24% /
kernfs             1.0K       1.0K         0B 100% /kern
ptyfs              1.0K       1.0K         0B 100% /dev/pts
procfs             4.0K       4.0K         0B 100% /proc
tmpfs               64M         0B        64M   0% /var/shm

On a freshly booted system, 15 processes are running and 26M of RAM are used:

load averages:  0.01,  0.00,  0.00;               up 0+00:48:26        14:48:28
16 processes: 15 sleeping, 1 on CPU
CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Memory: 26M Act, 6460K Exec, 12M File, 195M Free
Swap: 

  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
    0 root      96    0     0K   26M usbevt     0:01  0.00%  0.00% [system]
  795 root      43    0  6160K 1628K CPU        0:00  0.00%  0.00% top
  555 root      85    0    12M 3472K wait       0:00  0.00%  0.00% login
  630 postfix   85    0    13M 3220K kqueue     0:00  0.00%  0.00% qmgr
  599 postfix   85    0    12M 3172K kqueue     0:00  0.00%  0.00% pickup
  575 root      85    0    13M 2304K kqueue     0:00  0.00%  0.00% master
  196 root      85    0  9780K 1960K kqueue     0:00  0.00%  0.00% syslogd
  583 root      85    0  6788K 1824K wait       0:00  0.00%  0.00% sh
  710 root      85    0  6276K 1448K nanoslp    0:00  0.00%  0.00% cron
  733 root      85    0  6108K 1396K ttyraw     0:00  0.00%  0.00% getty
  730 root      85    0  5720K 1392K ttyraw     0:00  0.00%  0.00% getty
  633 root      85    0  6104K 1388K ttyraw     0:00  0.00%  0.00% getty
  211 root      85    0  7316K 1360K kqueue     0:00  0.00%  0.00% dhcpcd
    1 root      85    0  6600K 1340K wait       0:00  0.00%  0.00% init
  689 root      85    0  5700K 1184K kqueue     0:00  0.00%  0.00% inetd
  402 root      84    0  5920K 1140K kqueue     0:00  0.00%  0.00% powerd

Here is the result of running cat /proc/cpuinfo on this device:

processor	: 0
vendor_id	: Vortex86 SoC
cpu family	: 5
model		: 2
model name	: Vortex86DX
stepping	: 2
cpu MHz		: 1000.05
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu tsc cx8 
clflush size	: 0

For the record, OpenSSL speed benchmark results are available here.

System message buffer (dmesg output):

[     1.000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
[     1.000000]     2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
[     1.000000]     2018, 2019, 2020 The NetBSD Foundation, Inc.  All rights reserved.
[     1.000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[     1.000000]     The Regents of the University of California.  All rights reserved.

[     1.000000] NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021
[     1.000000] 	[email protected]:/usr/src/sys/arch/i386/compile/GENERIC
[     1.000000] total memory = 255 MB
[     1.000000] avail memory = 231 MB
[     1.000000] rnd: seeded with 66 bits
[     1.000000] timecounter: Timecounters tick every 10.000 msec
[     1.000000] Kernelized RAIDframe activated
[     1.000000] running cgd selftest aes-xts-256 aes-xts-512 done
[     1.000000] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
[     1.000003] Generic PC
[     1.000003] mainbus0 (root)
[     1.000003] Firmware Error (ACPI): A valid RSDP was not found (20190405/tbxfroot-261)
[     1.000003] autoconfiguration error: acpi_probe: failed to initialize tables
[     1.000003] ACPI Error: Could not remove SCI handler (20190405/evmisc-312)
[     1.000003] cpu0 at mainbus0
[     1.000003] cpu0: Vortex86DX, id 0x522
[     1.000003] cpu0: package 0, core 0, smt 0
[     1.000003] pci0 at mainbus0 bus 0: configuration mode 1
[     1.000003] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
[     1.000003] pchb0 at pci0 dev 0 function 0: vendor 17f3 product 6021 (rev. 0x02)
[     1.000003] vga0 at pci0 dev 3 function 0: vendor 18ca product 0020 (rev. 0x00)
[     1.000003] wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
[     1.000003] wsmux1: connecting to wsdisplay0
[     1.000003] drm at vga0 not configured
[     1.000003] rdcpcib0 at pci0 dev 7 function 0: vendor 17f3 product 6031 (rev. 0x02)
[     1.000003] rdcpcib0: watchdog timer configured.
[     1.000003] vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
[     1.000003] vte0: Ethernet address 00:1b:eb:22:16:5c
[     1.000003] vte0: interrupting at irq 10
[     1.000003] rdcphy0 at vte0 phy 1: R6040 10/100 media interface, rev. 1
[     1.000003] rdcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[     1.000003] ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x12)
[     1.000003] ohci0: interrupting at irq 11
[     1.000003] ohci0: OHCI version 1.0, legacy support
[     1.000003] usb0 at ohci0: USB revision 1.0
[     1.000003] ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x03)
[     1.000003] ehci0: interrupting at irq 11
[     1.000003] ehci0: BIOS has given up ownership
[     1.000003] ehci0: EHCI version 1.0
[     1.000003] ehci0: 1 companion controller, 2 ports: ohci0
[     1.000003] usb1 at ehci0: USB revision 2.0
[     1.000003] ohci1 at pci0 dev 11 function 0: vendor 17f3 product 6060 (rev. 0x12)
[     1.000003] ohci1: interrupting at irq 11
[     1.000003] ohci1: OHCI version 1.0, legacy support
[     1.000003] usb2 at ohci1: USB revision 1.0
[     1.000003] ehci1 at pci0 dev 11 function 1: vendor 17f3 product 6061 (rev. 0x03)
[     1.000003] ehci1: interrupting at irq 11
[     1.000003] ehci1: BIOS has given up ownership
[     1.000003] ehci1: EHCI version 1.0
[     1.000003] ehci1: 1 companion controller, 2 ports: ohci1
[     1.000003] usb3 at ehci1: USB revision 2.0
[     1.000003] rdcide0 at pci0 dev 12 function 0: RDC R1011 IDE controller (rev. 0x01)
[     1.000003] rdcide0: bus-master DMA support present
[     1.000003] rdcide0: primary channel configured to compatibility mode
[     1.000003] rdcide0: primary channel interrupting at irq 14
[     1.000003] atabus0 at rdcide0 channel 0
[     1.000003] rdcide0: secondary channel configured to compatibility mode
[     1.000003] rdcide0: secondary channel interrupting at irq 15
[     1.000003] atabus1 at rdcide0 channel 1
[     1.000003] isa0 at rdcpcib0
[     1.000003] pckbc0 at isa0 port 0x60-0x64
[     1.000003] attimer0 at isa0 port 0x40-0x43
[     1.000003] pcppi0 at isa0 port 0x61
[     1.000003] midi0 at pcppi0: PC speaker
[     1.000003] sysbeep0 at pcppi0
[     1.000003] isapnp0 at isa0 port 0x279
[     1.000003] attimer0: attached to pcppi0
[     1.000003] isapnp0: no ISA Plug 'n Play devices found
[     1.000003] timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
[     1.064509] uhub0 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
[     1.064509] uhub0: 2 ports with 2 removable, self powered
[     1.064509] uhub1 at usb2: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
[     1.064509] uhub1: 2 ports with 2 removable, self powered
[     1.064509] uhub2 at usb3: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
[     1.064509] uhub2: 2 ports with 2 removable, self powered
[     1.064509] uhub3 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
[     1.064509] uhub3: 2 ports with 2 removable, self powered
[     1.064509] IPsec: Initialized Security Association Processing.
[     3.914550] uaudio0 at uhub3 port 2 configuration 1 interface 0
[     3.914550] uaudio0: vendor 0d8c (0xd8c) C-Media USB Audio Device (0x08), rev 1.10/1.00, addr 2
[     3.934546] uaudio0: audio rev 1.00
[     3.934546] audio0 at uaudio0: playback, capture, full duplex, independent
[     3.934546] audio0: slinear_le:16 2ch 48000Hz, blk 11520 bytes (60ms) for playback
[     3.934546] audio0: slinear_le:16 1ch 48000Hz, blk 6000 bytes (62.5ms) for recording
[     3.934546] uhidev0 at uhub3 port 2 configuration 1 interface 3
[     3.934546] uhidev0: vendor 0d8c (0xd8c) C-Media USB Audio Device (0x08), rev 1.10/1.00, addr 2, iclass 3/0
[     3.944550] uhid0 at uhidev0: input=4, output=4, feature=0
[     4.054550] wd0 at atabus1 drive 0
[     4.054550] wd0: <Hitachi XX.V.3.5.0.0>
[     4.054550] wd0: drive supports 1-sector PIO transfers, LBA addressing
[     4.054550] wd0: 977 MB, 1987 cyl, 16 head, 63 sec, 512 bytes/sect x 2002896 sectors
[     4.064551] wd0: 32-bit data port
[     4.064551] wd0: drive supports PIO mode 4
[     4.064551] wd0(rdcide0:1:0): using PIO mode 4
[     4.084559] WARNING: 1 error while detecting hardware; check system log.
[     4.084559] boot device: wd0
[     4.084559] root on wd0a dumps on wd0b
[     4.094550] root file system type: ffs
[     4.094550] kern.module.path=/stand/i386/9.2/modules
[    20.764808] wsdisplay0: screen 1 added (80x25, vt100 emulation)
[    20.784809] wsdisplay0: screen 2 added (80x25, vt100 emulation)
[    20.794810] wsdisplay0: screen 3 added (80x25, vt100 emulation)
[    20.804812] wsdisplay0: screen 4 added (80x25, vt100 emulation)

May 30, 2021

NetBSD Blog Public NetBSD IRC chat channels moved to Libera

Hi everyone,

Due to the unfortunate situation regarding changes in administration on freenode.net, and the resulting chaos, we have decided to move the public NetBSD IRC chat channels from freenode to irc.libera.chat.

This includes:

You can find information on connecting to Libera at https://libera.chat/


May 18, 2021

Chris Pinnock OpenBSD on AWS

For the last few weeks, I’ve been doing lots of testing of NetBSD‘s build.sh cross-build system on lots of different platforms. Linux is readily available on AWS, as is FreeBSD. You will find NetBSD and OpenBSD in some AWS locations. It’s more difficult to get the BSDs onto AWS because the standard upload tools detect the filesystems and if they are not on the list, the image is not allowed. The BSD FFS and variants are not on the list.

Fortunately there are other tools and other ways to build images. It’s a little protracted. You need to first build a VM, convert it to VMDK, upload it to S3, create a snapshot and then convert it to an AMI.

This set of scripts (by Antoine Jacoutot) does the hard work for you and works for OpenBSD 6.5 up to 6.8. Last night, I created my own fork here which also works for 6.9. Essentially the difference is that the OpenBSD install kernel is compressed and the script now decompresses it and recompresses it where needed.

So as a result on AWS eu-west-2 (London), there are are AMIs for OpenBSD 6.5 through to 6.9. Just search for OpenBSD when you want to launch an image.

There are NetBSD images out there but I’m hoping to get around to producing some too.

Stack Overflow GNU as ld flags for assembly on NetBSD for arm

I am trying to assemble a simple Hello World program with the GNU assembler (as) on a Raspberry Pi 3 B+ running NetBSD 9.1
What flags do I need to add to as or ld to make them assemble the code correctly for the architecture I am using?

$ as -o hllwrld.o hllwrld.s
$ ld -o hllwrld hllwrld.o
$ ./hllwrld
-sh: Cannot execute ELF binary ./hllwrld

$ uname -a
NetBSD rpi 9.1 NetBSD 9.1 (RPI) #0: Sun Oct 18 19:24:30 UTC 2020  [email protected]:/usr/src/sys/arch/evbarm/compile/RPI evbarm

Is this aarch64 or arm64?

I know there are man pages but I am just learning assembly so I have no idea what configurations/flags/arguments I even need to be looking for.

Thanks for any help.


May 17, 2021

OS News NetBSD 9.2 released

The NetBSD Project is pleased to announce NetBSD 9.2, the second update of the NetBSD 9 release branch.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.1 in October 2020, as well some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0.

I’m not even remotely well-versed enough in NetBSD to make heads or tails of the changelog, but it seems like there’s quite a few notable ones in there.

NetBSD Blog NetBSD 9.2 released

The NetBSD Project is pleased to announce NetBSD 9.2 "Nakatomi Socrates", the second update of the NetBSD 9 release branch.

As well as the usual bug, stability, and security fixes, this release includes: support for exporting ZFS filesystems over NFS, various updates to the bozotic HTTP daemon, improvements to ARM 32-bit and Linux compatibility, fread() performance improvements, support for the TP-Link TL-WN821N V6 wireless adapter, support for the Allwinner H5 cryptographic accelerator, Pinebook Pro display brightness fixes, new defaults for kern.maxfiles, and accessibility improvements for the default window manager configuration.

Release notes and download links for NetBSD 9.2

The NetBSD Foundation NetBSD 9.2 release

May 12, 2021

Frederic Cambus Speedbuilding LLVM/Clang in 2 minutes on ARM

This post is the AArch64 counterpart of my "Speedbuilding LLVM/Clang in 5 minutes" article.

After publishing and sharing the previous post URL with some friends on IRC, I was asked if I wanted to try doing the same on a 160 cores ARM machine. Finding out what my answer was is left as an exercise to the reader :-)

The system I'm using for this experiment is a BM.Standard.A1.160 bare-metal machine from Oracle Cloud, which has a dual-socket motherboard with two 80 cores Ampere Altra CPUs, for a total 160 cores, and 1024 GB of RAM. This is to the best of my knowledge the fastest AArch64 server machine available at this time.

The system is running Oracle Linux Server 8.3 with up-to-date packages and kernel.

The full result of cat /proc/cpuinfo is available here.

uname -a
Linux benchmarks 5.4.17-2102.201.3.el8uek.aarch64 #2 SMP Fri Apr 23 09:42:46 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux

Let's start by installing required packages:

dnf in clang git lld

Unfortunately the CMake version available in the packages repository (3.11.4) is too old to build the main branch of the LLVM Git repository, and Ninja is not available either.

Let's bootstrap Pkgsrc to build and install them:

git clone https://github.com/NetBSD/pkgsrc.git
cd pkgsrc/bootstrap
./bootstrap --make-jobs=160 --unprivileged

===> bootstrap started: Wed May 12 12:23:34 GMT 2021
===> bootstrap ended:   Wed May 12 12:26:08 GMT 2021

We then need to add ~pkg/bin and ~pkg/sbin to the path:

export PATH=$PATH:$HOME/pkg/bin:$HOME/pkg/sbin

For faster Pkgsrc builds, we can edit ~/pkg/etc/mk.conf and add:

MAKE_JOBS=              160

Let's build and install CMake and Ninja:

cd ~/pkgsrc/devel/cmake
bmake install package clean clean-depends

cd ~/pkgsrc/devel/ninja-build
bmake install package clean clean-depends

The compiler used for the builds is Clang 10.0.1:

clang --version
clang version 10.0.1 (Red Hat 10.0.1-1.0.1.module+el8.3.0+7827+89335dbf)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /bin

Regarding linkers, we are using GNU ld and GNU Gold from binutils 2.30, and LLD 10.0.1.

GNU ld version 2.30-79.0.1.el8
GNU gold (version 2.30-79.0.1.el8) 1.15
LLD 10.0.1 (compatible with GNU linkers)

For all the following runs, I'm building from the Git repository main branch commit cf4610d27bbb5c3a744374440e2fdf77caa12040. The build directory is of course fully erased between each run.

commit cf4610d27bbb5c3a744374440e2fdf77caa12040
Author: Victor Huang <[email protected]>
Date:   Wed May 12 10:56:54 2021 -0500

I'm not sure what the underlying storage is, but with 1 TB of RAM there is no reason not to use a ramdisk.

mkdir /mnt/ramdisk
mount -t tmpfs -o size=32g tmpfs /mnt/ramdisk
cd /mnt/ramdisk

To get a baseline, let's do a full release build on this machine:

cd llvm-project
mkdir build
cd build

cmake   -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_PROJECTS=clang \
        ../llvm

time make -j160
real    7m3.226s
user    403m28.362s
sys     6m41.331s

By default, CMake generates Makefiles. As documented in the "Getting Started with the LLVM System" tutorial, most LLVM developers use Ninja.

Let's switch to generating Ninja build files, and using ninja to build:

cmake   -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_PROJECTS=clang \
        -GNinja ../llvm

time ninja
[4182/4182] Linking CXX executable bin/c-index-test

real    4m20.403s
user    427m27.118s
sys     7m2.320s

htop

By default, GNU ld is used for linking. Let's switch to using gold:

cmake   -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_PROJECTS=clang \
        -DLLVM_USE_LINKER=gold \
        -GNinja ../llvm

time ninja
[4182/4182] Linking CXX executable bin/c-index-test

real    4m1.062s
user    427m1.648s
sys     6m58.282s

LLD has been a viable option for some years now. Let's use it:

cmake   -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_PROJECTS=clang \
        -DLLVM_USE_LINKER=lld \
        -GNinja ../llvm

time ninja
[4182/4182] Linking CXX executable bin/clang-scan-deps

real    3m58.476s
user    428m3.807s
sys     7m14.418s

Using GNU gold instead of GNU ld results in noticeably faster builds, and switching to LLD shaves a few mores seconds from the build.

If we want to build faster, we can make some compromises and start stripping the build by removing some components.

Let's start by disabling additional architecture support:

cmake   -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_PROJECTS=clang \
        -DLLVM_USE_LINKER=lld \
        -DLLVM_TARGETS_TO_BUILD="AArch64" \
        -GNinja ../llvm

time ninja
[3195/3195] Linking CXX executable bin/c-index-test

real    3m10.312s
user    326m54.898s
sys     5m24.770s

We can verify the resulting Clang binary only supports AArch64 targets:

bin/clang --print-targets
  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)

Let's go further and disable the static analyzer and the ARC Migration Tool:

cmake   -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_PROJECTS=clang \
        -DLLVM_USE_LINKER=lld \
        -DLLVM_TARGETS_TO_BUILD="AArch64" \
        -DCLANG_ENABLE_STATIC_ANALYZER=OFF \
        -DCLANG_ENABLE_ARCMT=OFF \
        -GNinja ../llvm

time ninja
[3146/3146] Creating library symlink lib/libclang-cpp.so

real    3m6.474s
user    319m25.914s
sys     5m20.924s

Let's disable building some LLVM tools and utils:

cmake   -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_PROJECTS=clang \
        -DLLVM_USE_LINKER=lld \
        -DLLVM_TARGETS_TO_BUILD="AArch64" \
        -DCLANG_ENABLE_STATIC_ANALYZER=OFF \
        -DCLANG_ENABLE_ARCMT=OFF \
        -DLLVM_BUILD_TOOLS=OFF \
        -DLLVM_BUILD_UTILS=OFF \
        -GNinja ../llvm

time ninja
[2879/2879] Creating library symlink lib/libclang-cpp.so

real    2m59.659s
user    298m47.482s
sys     4m57.430s

Compared to the previous build, the following binaries were not built: FileCheck, count, lli-child-target, llvm-jitlink-executor, llvm-PerfectShuffle, not, obj2yaml, yaml2obj, and yaml-bench.

We are reaching the end of our journey here. At this point, we are done stripping out things.

Let's disable optimizations and do a last run:

cmake   -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_PROJECTS=clang \
        -DLLVM_USE_LINKER=lld \
        -DLLVM_TARGETS_TO_BUILD="AArch64" \
        -DCLANG_ENABLE_STATIC_ANALYZER=OFF \
        -DCLANG_ENABLE_ARCMT=OFF \
        -DLLVM_BUILD_TOOLS=OFF \
        -DLLVM_BUILD_UTILS=OFF \
        -DCMAKE_CXX_FLAGS_RELEASE="-O0" \
        -GNinja ../llvm

time ninja
[2879/2879] Linking CXX executable bin/c-index-test

real    2m37.003s
user    231m53.133s
sys     4m56.675s

So this is it, this machine can build a full LLVM/Clang release build in a bit less than four minutes, and a stripped down build with optimizations disabled in two minutes. Two minutes. This is absolutely mind-blowing… The future is now!

Benny Siegert More Go modules in pkgsrc
This weekend, I made a series of somewhat unusual changes to pkgsrc. I removed a bunch of Go packages. Why? Because of Go modules. What are Go modules? Since my series of design-ish blog posts(part 1, part 2), Go module builds have fully landed in pkgsrc, to the point that they are now the preferred way to build Go packages. To recap: There are two ways to use the go tool to build Go code.
NetBSD Blog aiomixer, X/Open Curses and ncurses, and other news

aiomixer is an application that I've been maintaining outside of NetBSD for a few years. It was available as a package, and was a "graphical" (curses, terminal-based) mixer for NetBSD's audio API, inspired by programs like alsamixer. For some time I've thought that it should be integrated into the NetBSD base system - it's small and simple, very useful, and many developers and users had it installed (some told me that they would install it on all of their machines that needed audio output). For my particular use case, as well as my NetBSD laptop, I have some small NetBSD machines around the house plugged into speakers that I play music from. Sometimes I like to SSH into them to adjust the playback volume, and it's often easier to do visually than with mixerctl(1).

However, there was one problem: when I first wrote aiomixer 2 years ago, I was intimidated by the curses API, so opted to use the Curses Development Kit instead. This turned out to be a mistake, as not only was CDK inflexible for an application like aiomixer, it introduced a hard dependency on ncurses.

X/Open Curses and ncurses

Many people think ncurses is the canonical way to develop terminal-based applications for Unix, but it's actually an implementation of the X/Open Curses specification. There's a few other Curses implementations:

NetBSD curses is descended from the original BSD curses, but contains many useful extensions from ncurses as well. We use it all over the base system, and for most packages in pkgsrc. It's also been ported to other operating systems, including Linux. As far as I'm aware, NetBSD is one of the last operating systems left that doesn't primarily depend on ncurses.

There's one crucial incompatibility, however: ncurses exposes its internal data structures, NetBSD libcurses keeps them opaque. Since CDK development is very tied to ncurses development (they have the same maintainer), CDK peeks into those structures, and can't be used with NetBSD libcurses. There are also a few places where ncurses breaks with X/Open Curses, like this case I recently fixed in irssi.

Rewriting aiomixer

I was able to rewrite aiomixer in a few days using only my free time and NetBSD libcurses. It's now been imported to the base system. It was a good lesson in why Curses isn't actually that intimidating - while there are many functions, they're mostly variations on the same thing. Using Curses directly resulted in a much lighter and more usable application, and provided a much better fit for the types of widgets I needed.

Many people also provided testing, and I learned a lot about how different terminal attributes should be used in the process. NetBSD is probably one of the few communities where you'll get easy and direct feedback on how to not only make your software work well in a variety of terminal emulators, but also old school hardware terminals. During development, I was also able to find a strange bug in the curses library's window resizing function.

The API support was also improved, and the new version of aiomixer should work better with a wider variety of sound hardware drivers.

Other happenings

Since I'm done plugging my own work, I thought I might talk a bit about some other recent changes to CURRENT.


April 25, 2021

Benny Siegert NetBSD VM on bhyve (on TrueNAS)
My new NAS at home is running TrueNAS Core. So far, it has been excellent, however I struggled a bit setting up a NetBSD VM on it. Part of the problem is that a lot of the docs and how-tos I found are stale, and the information in it no longer applies. TrueNAS Core allows running VMs using bhyve, which is FreeBSD’s hypervisor. NetBSD is not an officially supported OS, at least according to the guest OS chooser in the TrueNAS web UI :) But since the release of NetBSD 9 a while ago, things have become far simpler than they used to be – with one caveat (see below).

April 10, 2021

Super User Wait for process to start on linux/(net)bsd

I'm attempting to make a script which tracks how many times you execute a specific process. I want to detect when the process starts and then log it.

The psuedo-code would be something like this:

while (true) if (process started) then log(process)

Is there an easy way to do this (preferably in shell but C is also fine) on either Linux or NetBSD?


April 09, 2021

Frederic Cambus The state of toolchains in NetBSD

While FreeBSD and OpenBSD both switched to using LLVM/Clang as their base system compiler, NetBSD picked a different path and remained with GCC and binutils regardless of the license change to GPLv3. However, it doesn't mean that the NetBSD project endorses this license, and the NetBSD Foundation's has issued a statement about its position on the subject.

Realistically, NetBSD is more or less tied to GCC, as it supports more architectures than the other BSDs, some of which will likely never be supported in LLVM.

As of NetBSD 9.1, the latest released version, all supported platforms have recent versions of GCC (7.5.0) and binutils (2.31.1) in the base system. Newer (and older!) versions of GCC can be installed via Pkgsrc, and the following packages are available, going all the way back to GCC 3.3.6:

+---------+------------+-------------------+
| Package | Version    |      Release date |
+---------+------------+-------------------+
| gcc10   | GCC 10.2.0 |     July 23, 2020 |
| gcc9    | GCC  9.3.0 |    March 12, 2020 |
| gcc8    | GCC  8.4.0 |     March 4, 2020 |
| gcc7    | GCC  7.5.0 | November 14, 2019 |
| gcc6    | GCC  6.5.0 |  October 26, 2018 |
| gcc5    | GCC  5.5.0 |  October 10, 2017 |
| gcc49   | GCC  4.9.4 |    August 3, 2016 |
| gcc48   | GCC  4.8.5 |     June 23, 2015 |
| gcc3    | GCC  3.3.6 |       May 3, 2005 |
+---------+------------+-------------------+

The focus on GCC doesn't mean that the GNU and LLVM toolchains cannot coexist within NetBSD, and work has in fact been done during the last decade to make it happen.

Despite currently not being built by default in official NetBSD releases, LLVM has been imported in the NetBSD source tree in 2013. Daily images are built from NetBSD-current for selected platforms (at least amd64, i386 and evbarm) with the MKLLVM and HAVE_LLVM build options enabled, and contain LLVM and Clang.

Moreover, NetBSD has invested a lot of work on LLVM during the past few years, including funding some developer contracts for Kamil Rytarowski ([email protected]) and Michał Górny ([email protected]), which allowed them to work on various parts of the LLVM toolchain to add and enhance support for sanitizers, and to improve LLDB support.

They both published several dozen articles on the NetBSD blog along the way, retracing their journey. Kamil's final report about upstreaming support to LLVM sanitizers summarizes the work accomplished. Thanks to this work, sanitizer support on NetBSD is mature and mostly on par with Linux. As a result, because LLVM is upstream for GCC sanitizers, they are also available in GCC on NetBSD. Similarly, Michał's final report on his LLDB work details the achievements on the debuggers front.

As always, work continues towards keeping the toolchains up to date, and upstreaming local changes whenever possible.


April 01, 2021

The NetBSD Foundation New Developer in March 2021

March 29, 2021

Stack Overflow Turn a BSD .zip file into an installable version

I'm working on a distro of NetBSD, and the code builds without any problems. However, now I have the .zip file and I don't know what to do with it. How can I turn it into an installable image. I've tried using a chroot.

Azure Pipelines GitHub