NetBSD Wiki/
RecentChanges
Recent changes to this wiki:
Update for the 10.1 release
Index: wikisrc/ports.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports.mdwn,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- wikisrc/ports.mdwn 23 Jun 2024 22:41:14 -0000 1.32 +++ wikisrc/ports.mdwn 18 Dec 2024 19:51:01 -0000 1.33 @@ -20,15 +20,15 @@ [[!table data=""" Port |CPU |Machines |Latest Release -[[aarch64]] |aarch64 |64-bit ARM CPUs |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[amd64]] |x86_64 |64-bit x86-family machines with AMD and Intel CPUs |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[evbarm]] |arm |ARM evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[evbmips]] |mips |MIPS-based evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[evbppc]] |powerpc |PowerPC-based evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[hpcarm]] |arm |StrongARM based Windows CE PDA machines |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[i386]] |i386 |32-bit x86-family generic machines ("PC clones") |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[sparc64]] |sparc |Sun UltraSPARC (64-bit) |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[xen]] |i386, x86_64 |Xen Virtual Machine Monitor |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[aarch64]] |aarch64 |64-bit ARM CPUs |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[amd64]] |x86_64 |64-bit x86-family machines with AMD and Intel CPUs |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[evbarm]] |arm |ARM evaluation boards |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[evbmips]] |mips |MIPS-based evaluation boards |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[evbppc]] |powerpc |PowerPC-based evaluation boards |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[hpcarm]] |arm |StrongARM based Windows CE PDA machines |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[i386]] |i386 |32-bit x86-family generic machines ("PC clones") |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[sparc64]] |sparc |Sun UltraSPARC (64-bit) |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[xen]] |i386, x86_64 |Xen Virtual Machine Monitor |[10.1](http://www.NetBSD.org/releases/formal-10/) """]] @@ -45,56 +45,56 @@ [[!table data=""" Port |CPU |Machines |Latest Release -[[acorn32]] |arm |Acorn RiscPC/A7000/NC and compatibles |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[algor]] |mips |Algorithmics MIPS evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[alpha]] |alpha |Digital Alpha (64-bit) |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[amiga]] |m68k |Commodore Amiga, MacroSystem DraCo |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[amigappc]] |powerpc |PowerPC-based Amiga boards |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[arc]] |mips |Machines following the Advanced RISC Computing spec |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[atari]] |m68k |Atari TT030, Falcon, Hades |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[bebox]] |powerpc |Be Inc's BeBox |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[cats]] |arm |Chalice Technology's Strong Arm evaluation board |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[cesfic]] |m68k |CES's FIC8234 VME processor board |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[cobalt]] |mips |Cobalt Networks' Microservers |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[dreamcast]] |[[sh3]] |Sega Dreamcast game console |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[epoc32]] |arm |32bit PSION EPOC PDA |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[emips]] |mips |Machines based on "Extensible MIPS" |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[evbsh3]] |[[sh3]] |Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[ews4800mips]] |mips |NEC's MIPS based EWS4800 workstations |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[hp300]] |m68k |Hewlett-Packard 9000/300 and 400 series |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[hppa]] |hppa |Hewlett-Packard 9000/700 series |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[hpcmips]] |mips |MIPS based Windows CE PDA machines |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[hpcsh]] |[[sh3]] |Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[acorn32]] |arm |Acorn RiscPC/A7000/NC and compatibles |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[algor]] |mips |Algorithmics MIPS evaluation boards |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[alpha]] |alpha |Digital Alpha (64-bit) |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[amiga]] |m68k |Commodore Amiga, MacroSystem DraCo |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[amigappc]] |powerpc |PowerPC-based Amiga boards |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[arc]] |mips |Machines following the Advanced RISC Computing spec |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[atari]] |m68k |Atari TT030, Falcon, Hades |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[bebox]] |powerpc |Be Inc's BeBox |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[cats]] |arm |Chalice Technology's Strong Arm evaluation board |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[cesfic]] |m68k |CES's FIC8234 VME processor board |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[cobalt]] |mips |Cobalt Networks' Microservers |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[dreamcast]] |[[sh3]] |Sega Dreamcast game console |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[epoc32]] |arm |32bit PSION EPOC PDA |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[emips]] |mips |Machines based on "Extensible MIPS" |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[evbsh3]] |[[sh3]] |Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[ews4800mips]] |mips |NEC's MIPS based EWS4800 workstations |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[hp300]] |m68k |Hewlett-Packard 9000/300 and 400 series |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[hppa]] |hppa |Hewlett-Packard 9000/700 series |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[hpcmips]] |mips |MIPS based Windows CE PDA machines |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[hpcsh]] |[[sh3]] |Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines |[10.1](http://www.NetBSD.org/releases/formal-10/) [[ia64]] |itanium |Itanium family of processors |none -[[ibmnws]] |powerpc |IBM Network Station Series 1000 |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[iyonix]] |arm |Iyonix ARM pc |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[landisk]] |[[sh3]] |SH4 based NAS appliances by I-O DATA |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[luna68k]] |m68k |OMRON Tateisi Electronics' LUNA series |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[mac68k]] |m68k |Apple Macintosh |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[macppc]] |powerpc |Apple Power Macintosh and clones |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[mipsco]] |mips |Mips family of workstations and servers |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[mmeye]] |[[sh3]] |Brains' mmEye Multi Media Server |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[mvme68k]] |m68k |Motorola MVME 68k SBCs |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[mvmeppc]] |powerpc |Motorola MVME PowerPC SBCs |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[netwinder]] |arm |StrongARM based NetWinder machines |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[news68k]] |m68k |Sony's m68k based "NET WORK STATION" series |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[newsmips]] |mips |Sony's MIPS based "NET WORK STATION" series |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[next68k]] |m68k |NeXT 68k 'black' hardware |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[ofppc]] |powerpc |Generic OpenFirmware compliant PowerPC machines |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[pmax]] |mips |Digital MIPS-based DECstations and DECsystems |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[prep]] |powerpc |PReP (PowerPC Reference Platform) and CHRP machines |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[ibmnws]] |powerpc |IBM Network Station Series 1000 |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[iyonix]] |arm |Iyonix ARM pc |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[landisk]] |[[sh3]] |SH4 based NAS appliances by I-O DATA |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[luna68k]] |m68k |OMRON Tateisi Electronics' LUNA series |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[mac68k]] |m68k |Apple Macintosh |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[macppc]] |powerpc |Apple Power Macintosh and clones |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[mipsco]] |mips |Mips family of workstations and servers |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[mmeye]] |[[sh3]] |Brains' mmEye Multi Media Server |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[mvme68k]] |m68k |Motorola MVME 68k SBCs |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[mvmeppc]] |powerpc |Motorola MVME PowerPC SBCs |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[netwinder]] |arm |StrongARM based NetWinder machines |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[news68k]] |m68k |Sony's m68k based "NET WORK STATION" series |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[newsmips]] |mips |Sony's MIPS based "NET WORK STATION" series |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[next68k]] |m68k |NeXT 68k 'black' hardware |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[ofppc]] |powerpc |Generic OpenFirmware compliant PowerPC machines |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[pmax]] |mips |Digital MIPS-based DECstations and DECsystems |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[prep]] |powerpc |PReP (PowerPC Reference Platform) and CHRP machines |[10.1](http://www.NetBSD.org/releases/formal-10/) [[riscv]] |riscv |RISC-V |none -[[rs6000]] |powerpc |MCA-based IBM RS/6000 workstations |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[sandpoint]] |powerpc |Motorola Sandpoint reference platform |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[sbmips]] |mips |Broadcom SiByte evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[sgimips]] |mips |Silicon Graphics' MIPS-based workstations |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[shark]] |arm |Digital DNARD ("shark") |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[sparc]] |sparc |Sun SPARC (32-bit) |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[sun2]] |m68k |Sun 2 |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[sun3]] |m68k |Sun 3 and 3x |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[vax]] |vax |Digital VAX |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[x68k]] |m68k |Sharp X680x0 series |[10.0](http://www.NetBSD.org/releases/formal-10/) -[[zaurus]] |arm |Sharp C7x0/C860/C1000/C3x00 series PDA |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[rs6000]] |powerpc |MCA-based IBM RS/6000 workstations |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[sandpoint]] |powerpc |Motorola Sandpoint reference platform |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[sbmips]] |mips |Broadcom SiByte evaluation boards |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[sgimips]] |mips |Silicon Graphics' MIPS-based workstations |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[shark]] |arm |Digital DNARD ("shark") |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[sparc]] |sparc |Sun SPARC (32-bit) |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[sun2]] |m68k |Sun 2 |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[sun3]] |m68k |Sun 3 and 3x |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[vax]] |vax |Digital VAX |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[x68k]] |m68k |Sharp X680x0 series |[10.1](http://www.NetBSD.org/releases/formal-10/) +[[zaurus]] |arm |Sharp C7x0/C860/C1000/C3x00 series PDA |[10.1](http://www.NetBSD.org/releases/formal-10/) """]] Index: wikisrc/releng.mdwn =================================================================== RCS file: /cvsroot/wikisrc/releng.mdwn,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- wikisrc/releng.mdwn 30 Mar 2024 19:26:59 -0000 1.53 +++ wikisrc/releng.mdwn 18 Dec 2024 19:51:02 -0000 1.54 @@ -12,21 +12,16 @@ ### NetBSD 10.x -* Next minor release: NetBSD 10.1 (no schedule) +* Next minor release: NetBSD 10.2 (no schedule) + CVS branch tag: <code>netbsd-10</code> * [Current pull-up queue for the netbsd-10 branch](http://releng.netbsd.org/cgi-bin/req-10.cgi) ### NetBSD 9.x -* Next minor release: NetBSD 9.4 (scheduled for mid Apil 2024) +* Next minor release: NetBSD 9.5 (no schedule) + CVS branch tag: <code>netbsd-9</code> * [Current pull-up queue for the netbsd-9 branch](http://releng.netbsd.org/cgi-bin/req-9.cgi) -### NetBSD 8.x - -* Next minor release: NetBSD 8.3 (scheduled for end of April 2024, which also is end of support for this branch) - + CVS branch tag: <code>netbsd-8</code> -* [Current pull-up queue for the netbsd-8 branch](http://releng.netbsd.org/cgi-bin/req-8.cgi) ## Automated Status Information Index: wikisrc/ports/aarch64.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/aarch64.mdwn,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- wikisrc/ports/aarch64.mdwn 30 Mar 2024 19:27:00 -0000 1.17 +++ wikisrc/ports/aarch64.mdwn 18 Dec 2024 19:51:02 -0000 1.18 @@ -5,8 +5,8 @@ iso_image="true" future_rel="11.0" changes_future="11.0" -cur_rel="10.0" -changes_cur="10.0" +cur_rel="10.1" +changes_cur="10.1" pkg_rel="9.0" about=""" NetBSD/aarch64 is a port to Arm's 64-bit CPUs and other compatible Index: wikisrc/ports/algor.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/algor.mdwn,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- wikisrc/ports/algor.mdwn 30 Mar 2024 19:27:00 -0000 1.25 +++ wikisrc/ports/algor.mdwn 18 Dec 2024 19:51:02 -0000 1.26 @@ -1,9 +1,9 @@ [[!template id=port port="algor" (Diff truncated)
zig on aarch64
Index: wikisrc/languages.mdwn =================================================================== RCS file: /cvsroot/wikisrc/languages.mdwn,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- wikisrc/languages.mdwn 6 Apr 2022 17:18:23 -0000 1.9 +++ wikisrc/languages.mdwn 15 Dec 2024 21:39:09 -0000 1.10 @@ -19,7 +19,7 @@ Python | yes | yes | yes | yes | yes | yes | yes | yes | no Ruby | yes | yes | yes | yes | yes | yes | yes | yes | yes Rust | yes | yes | yes | yes | yes | yes | no | no | no -Zig | yes | no | no | no | no | no | no | no | no +Zig | yes | yes | no | no | no | no | no | no | no """]] Footnotes
add initial template for custom cgd root page
--- /dev/null 2024-12-13 13:14:02.978147957 +0000 +++ wikisrc/security/custom_cgdroot.mdwn 2024-12-13 13:14:48.855563655 +0000 @@ -0,0 +1,9 @@ +[[!meta title="Creating a custom CGD ramdisk"]] + +This page describes how to setup a special root disk loaded +via a USB stick to unlock a CGD root via a fido2 key and +a secret bound to that key via fidocrypt(1) from pkgsrc. + +The boot process +---------------- +
zfs: rototill known problems, add lockup caution
Index: wikisrc/zfs.mdwn =================================================================== RCS file: /cvsroot/wikisrc/zfs.mdwn,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- wikisrc/zfs.mdwn 21 Aug 2023 10:58:31 -0000 1.47 +++ wikisrc/zfs.mdwn 30 Nov 2024 15:33:25 -0000 1.48 @@ -16,23 +16,22 @@ This HOWTO errs on the side of saying things if they seem 90-95% true. Feel free to complain if you think something is wrong! -# Status of ZFS in NetBSD +As of 2024-11, multiple people report full-system lockups when using +zfs and pushing it hard. There are no reports of systems that are +pushed hard and stay up for months. -## NetBSD-8 +# Status of ZFS in NetBSD -NetBSD-8 has an old version of ZFS, and it is not recommended for use -at all. There is no evidence that anyone is interested in helping -with ZFS on 8. Those wishing to use ZFS on NetBSD 8 should therefore -update to NetBSD-9. This page therefore contains no useful status or -hints about 8. +NetBSD-8 and older are no longer supported, and hence not addressed. ## NetBSD-9 -NetBSD-9 has ZFS that is considered to work well. There have been -fixes since 9.0_RELEASE. As always, people running NetBSD-9 are -likely best served by the most recent version of the netbsd-9 stable -branch. This page assumes anyone using 9 is using 9.3 or netbsd-9 -after 9.3; issues fixed in earlier versions have been removed. +NetBSD-9 has ZFS that is considered to work well, except for lockups. +There have been fixes since 9.0_RELEASE. As always, people running +NetBSD-9 are likely best served by the most recent version of the +netbsd-9 stable branch. This page assumes anyone using 9 is using 9.3 +or netbsd-9 after 9.3; issues fixed in earlier versions have been +removed. Extended attributes are not supported. \todo Link to PR. @@ -63,8 +62,9 @@ In NetBSD-9, MAXPHYS is 64KB in most places, but because of xbd(4) it is set to 32KB for XEN kernels. Thus the standard zfs kernel modules do not work under xen. In NetBSD-10 and newer, xbd(4) supports 64 KB -MAXPHYS and this is no longer an issue. Xen and zfs on 10/current are -reported to work well together, as of 2021-02. +MAXPHYS and this is no longer an issue. Xen and zfs on 10 (and +post-10 current) work well (except for lockups, which happen without +Xen). ## Architectures @@ -75,35 +75,60 @@ sparc64. More or less, it is acceptable to commit enabling zfs on an -architecture when it is known to build and run reliably. (Of course, -anyone is welcome to build it and use it, and reports of success or -unexpected failure are welcome.) +architecture when it is known to build and run as reliably as it does +on amd64. (Of course, anyone is welcome to build it and use it, and +reports of success or unexpected failure are welcome.) ## Known Problems +See https://codeberg.org/gdt/netbsd-zfs/ for a patch to reduce ARC +usage and add debug output, scripts to monitor memory usage, and +scripts to stress zfs and memory. + +### Lockups + +zfs is prone to full-system lockups. They seem to be related to heavy +zfs activity, especially writing data or deleting files, while at the +same time there is memory pressure. It seems that the odds of a +lockup go up over time, suggesting a leak. Probably, the bug is in an +error or exception path. zfs works well, when it has not locked up. + +The /etc/daily script seems to provoke lockups. + +### Not enough sysctls + +Many things should be sysctls and aren't. + ### Excessive ARC usage The upstream code sets the max ARC size (and hence the initial target) to all but 1 GB. This results in consuming excessive amounts of memory on systems with less than about 8 GB, and systems of 4 GB and -lower have been observed to lock up. It seems likely that even -high-memory systems would have trouble if enough data were paged in. -Patches to change this behavior have been sent to `netbsd-users@`. +lower have been observed to lock up. It is far from clear that using +all spare RAM for ARC is the real cause. See the section "Memory Usage", below. -### Difficulty freeing metadata +### Difficulty freeing metadata, vnodes FreeBSD has a function `arc_dnlc_evicts_thread`. This has something to do with freeing objects not in ZFS that refer to metadata entries in the ARC, which keeps them from being evictable. A work item is to understand this and adapt it to NetBSD. -### Draining under memory pressure +In NetBSD, zfs vnodes have a 'dnode' associated with them. This +memory is from a pool, and is counted as being in the ARC, but it is +not actually a DVA/data tuple in the ARC. Reducing kern.maxvnodes seems to help keep this from causing problems. + +### Prefetching + +Prefetching is perhaps related to lockups. + +### Allocating memory in routines called under memory pressure -There should be a mechanism to shrink the ARC under memory pressure. -FreeBSD hooks in a drain procedure to do this. A work item is to -understand this and adapt it. +The NetBSD glue code allocates memory when asked to free memory. This +could be related to the lockup problem, but there is no clear evidence +so far. # Quick Start
root_on_zfs: Nix needs-update re boot.cfg fs command.
Apparently this text already uses the boot.cfg fs command, not sure
why I put the needs-update tag before.
Apparently this text already uses the boot.cfg fs command, not sure
why I put the needs-update tag before.
Members: root_on_zfs.mdwn:1.4->1.5 Index: wikisrc/root_on_zfs.mdwn =================================================================== RCS file: /cvsroot/wikisrc/root_on_zfs.mdwn,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- wikisrc/root_on_zfs.mdwn 23 Mar 2024 18:40:14 -0000 1.4 +++ wikisrc/root_on_zfs.mdwn 27 Nov 2024 02:04:56 -0000 1.5 @@ -1,9 +1,5 @@ [[!meta title="Root On ZFS"]] -[[!template id=needs-update reason=""" -the `fs ramdisk-zfsroot.fs` in [[!template id=man name="boot.cfg" section="5"]] obviates the need for a custom kernel module with the ramdisk embedded -"""]] - NetBSD-9 gained much improved ZFS support. However, one feature it's still missing is the ability to have your system root on ZFS.
push
Index: wikisrc/ports/cats.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/cats.mdwn,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- wikisrc/ports/cats.mdwn 22 Oct 2024 21:24:02 -0000 1.25 +++ wikisrc/ports/cats.mdwn 26 Oct 2024 09:05:08 -0000 1.26 @@ -27,7 +27,7 @@ ###Running NetBSD/cats in GXemul -See the [[NetBSD/cats in GXemul|cats/gxemul_cats]] page for instructions on how to run NetBSD/cats in GXemul. +See the [[NetBSD/cats in GXemul|gxemul_cats]] page for instructions on how to run NetBSD/cats in GXemul. """ ]]
push
Index: wikisrc/sandbox.mdwn =================================================================== RCS file: /cvsroot/wikisrc/sandbox.mdwn,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- wikisrc/sandbox.mdwn 26 Oct 2024 08:52:37 -0000 1.27 +++ wikisrc/sandbox.mdwn 26 Oct 2024 08:54:36 -0000 1.28 @@ -44,13 +44,3 @@ fnord again -really foo bar baz - -See the [[NetBSD/cats in GXemul|cats/gxemul_cats]] page for instructions on how -to run NetBSD/cats in GXemul. - -See the [NetBSD/cats in GXemul](cats/gxemul_cats) page for instructions on how -to run NetBSD/cats in GXemul. - -See the [NetBSD/cats in GXemul][cats/gxemul_cats] page for instructions on how -to run NetBSD/cats in GXemul.
push
Index: wikisrc/sandbox.mdwn =================================================================== RCS file: /cvsroot/wikisrc/sandbox.mdwn,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- wikisrc/sandbox.mdwn 26 Oct 2024 08:32:28 -0000 1.26 +++ wikisrc/sandbox.mdwn 26 Oct 2024 08:52:37 -0000 1.27 @@ -45,7 +45,12 @@ fnord again really foo bar baz -See the [[NetBSD/cats in GXemul|/cats/gxemul_cats]] page for instructions on how + +See the [[NetBSD/cats in GXemul|cats/gxemul_cats]] page for instructions on how to run NetBSD/cats in GXemul. -See the [NetBSD/cats in GXemul](/cats/gxemul_cats) page for instructions on how + +See the [NetBSD/cats in GXemul](cats/gxemul_cats) page for instructions on how +to run NetBSD/cats in GXemul. + +See the [NetBSD/cats in GXemul][cats/gxemul_cats] page for instructions on how to run NetBSD/cats in GXemul.
push
Index: wikisrc/sandbox.mdwn =================================================================== RCS file: /cvsroot/wikisrc/sandbox.mdwn,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- wikisrc/sandbox.mdwn 26 Oct 2024 08:29:21 -0000 1.25 +++ wikisrc/sandbox.mdwn 26 Oct 2024 08:32:28 -0000 1.26 @@ -47,3 +47,5 @@ really foo bar baz See the [[NetBSD/cats in GXemul|/cats/gxemul_cats]] page for instructions on how to run NetBSD/cats in GXemul. +See the [NetBSD/cats in GXemul](/cats/gxemul_cats) page for instructions on how +to run NetBSD/cats in GXemul.
push
Index: wikisrc/sandbox.mdwn =================================================================== RCS file: /cvsroot/wikisrc/sandbox.mdwn,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- wikisrc/sandbox.mdwn 26 Oct 2024 08:20:49 -0000 1.24 +++ wikisrc/sandbox.mdwn 26 Oct 2024 08:29:21 -0000 1.25 @@ -45,3 +45,5 @@ fnord again really foo bar baz +See the [[NetBSD/cats in GXemul|/cats/gxemul_cats]] page for instructions on how +to run NetBSD/cats in GXemul.
push
Index: wikisrc/sandbox.mdwn =================================================================== RCS file: /cvsroot/wikisrc/sandbox.mdwn,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- wikisrc/sandbox.mdwn 29 Jul 2016 07:32:25 -0000 1.23 +++ wikisrc/sandbox.mdwn 26 Oct 2024 08:20:49 -0000 1.24 @@ -43,3 +43,5 @@ Remember Cyrix: <img src="http://www.netbsd.org/images/ports/i386/header.gif" /> fnord again + +really foo bar baz
Link to GXemul docs from cats page.
Index: wikisrc/ports/cats.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/cats.mdwn,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- wikisrc/ports/cats.mdwn 30 Mar 2024 19:27:00 -0000 1.24 +++ wikisrc/ports/cats.mdwn 22 Oct 2024 21:24:02 -0000 1.25 @@ -24,6 +24,11 @@ Additionally, GXemul is a machine emulator which also can run the NetBSD/cats port. + +###Running NetBSD/cats in GXemul + +See the [[NetBSD/cats in GXemul|cats/gxemul_cats]] page for instructions on how to run NetBSD/cats in GXemul. + """ ]] [[!tag tier2port]]
Markdown fix.
Index: wikisrc/ports/cats/gxemul_cats.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/cats/gxemul_cats.mdwn,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- wikisrc/ports/cats/gxemul_cats.mdwn 22 Oct 2024 21:14:40 -0000 1.2 +++ wikisrc/ports/cats/gxemul_cats.mdwn 22 Oct 2024 21:18:21 -0000 1.3 @@ -15,6 +15,7 @@ $ gxemul -E cats -q -d c:NetBSD-10.0-cats.iso -d d:disk.img -j 'NETBSD.;1' Go through a standard NetBSD installation. At the end, when configuring the NetBSD, use the following settings: + * media type: autoselect * autoconfiguration: no * host name: up to you
Markdown fix
Index: wikisrc/ports/cats/gxemul_cats.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/cats/gxemul_cats.mdwn,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- wikisrc/ports/cats/gxemul_cats.mdwn 22 Oct 2024 21:11:05 -0000 1.1 +++ wikisrc/ports/cats/gxemul_cats.mdwn 22 Oct 2024 21:14:40 -0000 1.2 @@ -23,6 +23,7 @@ * IPv4 netmask: 0xff000000 * IPv4 gateway: 10.0.0.254 * name server: 10.0.0.254 + After you set a root password, reboot and GXemul will exit. # Running your NetBSD/cats installation
Add notes on running NetBSD/cats in GXemul
--- /dev/null 2024-10-22 21:12:03.188139820 +0000 +++ wikisrc/ports/cats/gxemul_cats.mdwn 2024-10-22 21:12:08.395189048 +0000 @@ -0,0 +1,33 @@ +[[!meta title="NetBSD/cats in GXemul"]] + +As of October 2024, GXemul runs all versions of NetBSD/cats, including all releases and -current. Note that at the time of this writing, the latest GXemul release (0.7.0) has a bug that prevents builds compiled with GCC 10 (NetBSD 10.0 and later releases and -current after June 2021 and) from booting. To run such a release either install GXemul from pkgsrc or apply the patch linked below. + +# Requirements +* GXemul from pkgsrc (otherwise make sure it contains [this patch](https://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/emulators/gxemul/patches/patch-src_cpus_cpu__arm__instr__dpi.c?rev=1.1;content-type=text%2Fplain) +* an installation .iso, e.g., [NetBSD-10.0-cats.iso](https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/iso/NetBSD-10.0-cats.iso) and corresponding [kernel](https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/cats/binary/kernel/netbsd-GENERIC.gz) + +# Creating a disk image + + $ dd if=/dev/zero of=hdd.img bs=1M count=1 seek=1023 + +# Installing NetBSD/cats in GXemul + + $ gxemul -E cats -q -d c:NetBSD-10.0-cats.iso -d d:disk.img -j 'NETBSD.;1' + +Go through a standard NetBSD installation. At the end, when configuring the NetBSD, use the following settings: +* media type: autoselect +* autoconfiguration: no +* host name: up to you +* DNS domain: up to you +* IPv4 address: 10.0.0.1 +* IPv4 netmask: 0xff000000 +* IPv4 gateway: 10.0.0.254 +* name server: 10.0.0.254 +After you set a root password, reboot and GXemul will exit. + +# Running your NetBSD/cats installation +Unlike when booting from CD, GXemul cannot load the kernel from inside the disk image, that is why we downloaded that earlier. + + $ gxemul -E cats -d d:disk.img netbsd-GENERIC.gz + +Note that the default networking is somewhat rudimentary. You can establish TCP connections to the outside world and ping destinations there (GXemul has NAT built in) and you can ping 10.0.0.254 (the "gateway"), but you cannot establish TCP connections to 10.0.0.254. In order to connect to the host via ssh, you need to connect to a "real" IP address on the host (not necessarily a public one - just not 10.0.0.254 or anything in 127/8).
update my stuff
--- wikisrc/users/cjep.mdwn 2024-10-18 15:03:47.870690240 +0000 +++ /dev/null 2024-10-18 15:03:02.493077496 +0000 @@ -1,10 +0,0 @@ -# Wiki page for Chris Pinnock (cjep) - -## Things of potential interest - -* Draft [Using Git with the NetBSD Packages Collection](http://wiki.netbsd.org/users/cjep/git4pkgsrc/) -* [Getting Tezos to work on NetBSD](http://wiki.netbsd.org/users/cjep/tezos-on-netbsd/) (WIP) - -* [Transitioning from a.out to ELF on NetBSD](https://chrispinnock.com/2022/08/20/netbsdaout/) -* [NetBSD/i386 from 1.0 to present](https://chrispinnock.com/2022/09/30/netbsdhist/) -* [Forking NetBSD](https://chrispinnock.com/2022/10/07/forkingnetbsd/) --- wikisrc/users/cjep/tezos-on-netbsd.mdwn 2024-10-18 15:03:47.914831434 +0000 +++ /dev/null 2024-10-18 15:03:02.493077496 +0000 @@ -1,135 +0,0 @@ -# Tezos on NetBSD - -Some notes on getting Octez to compile on NetBSD. Work in progress. - -## Problems with possible solutions - -1. Opam package doesn't include solver properly. - -Three ways: - -- Add lib-ext to targets and run before all (which isn't working for me) -- Is there another way to include the solver at runtime? -- Builds natively - accept that we have to do this outside of pkgsrc - -2. Once Opam is installed, it cannot compile OCaml on arm64 platforms (and -probably others). Amd64 is fine. - -OCaml builds in pkgsrc. Submit our pkgsrc patches back to OCaml team? - -``` -# [...] -# In file included from /usr/include/ctype.h:100, -# from sak.c:29: -# sak.c: In function 'add_stdlib_prefix': -# sak.c:126:26: warning: array subscript has type 'char' [-Wchar-subscripts] -# 126 | *name = toupper_os(*name); -# | ^ -# sak.c:126:15: note: in expansion of macro 'toupper_os' -# 126 | *name = toupper_os(*name); -# | ^~~~~~~~~~ -# gcc -O2 -fno-strict-aliasing -fwrapv -pthread -Wall -Wdeclaration-after-statement -fno-common -fexcess-precision=standard -g -Wl,-E -o sak sak.o -# gmake[1]: Leaving directory '/disc/tezos/_opam/.opam-switch/build/ocaml-base-compiler.4.14.1/runtime' -# Makefile:988: *** The native-code compiler is not supported on this platform. Stop. -``` - -3. HACL Star library explicitly excludes NetBSD -Patch done. FreeBSD settings work. Sent to vdum. - -4. GMP fix - -Cannot find GMP where it expects. - -``` -zen: {343} setenv CFLAGS -I/usr/pkg/include -zen: {344} opam install conf-gmp --verbose -zen: {345} eval `opam env` -``` - -5. Zarith 1.12 - -Zarith hackery 1.13 works out of the box. We seem to require 1.12? - -``` -cd ../ -mkdir zarith-1.12 -ftp -a https://github.com/ocaml/Zarith/archive/release-1.13.tar.gz -cd zarith-1.12/ -tar zxvf ../release-1.13.tar.gz -zen: {363} cd ../../tezos/ -zen: {364} pwd -/home/cjep/src/tezos -zen: {365} opam install ../zarith-1.12/Zarith-release-1.13 -``` - -mirage-crypto-rng - __FreeBSD__ definition line in sources - needs __NetBSD__ too! - Add -D__FreeBSD__ as a workaround - -pringo.1.3 - popcount function conflicts with native one - I worked around by renaming it - what is the best way normally? - -pyml - pyml_arch.ml.c checks for unix. We have __unix__ - Pull request submitted to pyml - https://github.com/thierry-martinez/pyml/pull/99 - -parsexp - SEG FAULT - -tezos-rust-libs.1.6 - -1. disc space error in /tmp. - /tmp needs at least 906M free - drwxrwxrwt 6 root wheel 384 Jan 27 15:32 tmp - -2. error[E0412]: cannot find type `QueryIter` in module `os` - --> /home/cjep/src/tezos/_opam/.opam-switch/build/tezos-rust-libs.1.6/vendor/region/src/qu -ery.rs:7:24 - | -7 | iterator: Option<os::QueryIter>, - | ^^^^^^^^^ not found in `os` - | -help: consider importing this struct - -Repeatedly wanting to install autoconf. Has to be a path issue - -## Process - -I will update this as I go. - -0. Make sure /tmp has at least 1G available otherwise tezos-rust-libs -cannot start to compile. On older machines /tmp is often in RAM to speed up. - -1. Install prerequisites -pkgin install gmake ocaml-opam jq git libev libhidapi autoconf - -2. Get Rust - -3. Get the Tezos sources - -setenv C_INCLUDE_PATH /usr/pkg/include:/usr/pkg/include/ev -setenv LIBRARY_PATH /usr/pkg/lib:/usr/pkg/lib/ev -#setenv CFLAGS "-I/usr/pkg/include -D__FreeBSD__ -fPIC" -setenv CFLAGS -I/usr/pkg/include - -4. init --bare -gmake build-deps - -Fix ups: -opam install ../fixed up -- hacl-star-raw needs the patch -- pringo function fix -- pyml -- mirage-crypto-rng -D__FreeBSD__ -- zarith (install 13 instead of 12) - -gmake build-deps - -- class_group_vdf ** Cannot find gmpxx.h library ** -- p -- tezos-rust-lib - - -
remove some TODO
Index: wikisrc/ports/evbarm/raspberry_pi.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/evbarm/raspberry_pi.mdwn,v retrieving revision 1.155 retrieving revision 1.156 diff -u -r1.155 -r1.156 --- wikisrc/ports/evbarm/raspberry_pi.mdwn 18 Feb 2024 18:32:33 -0000 1.155 +++ wikisrc/ports/evbarm/raspberry_pi.mdwn 10 Oct 2024 11:06:18 -0000 1.156 @@ -25,7 +25,7 @@ While NetBSD 8 is of historic interest only, we document what was working in 8. - RPI1, RPI2, RPI2-1.2, RPI3, RPI3+ (except RPI3 builtin WiFi and bluetooth) - - RPI0 and RPI0W are expected to work (without WiFi, and one needs fdt files \todo where from?) + - RPI0 and RPI0W are expected to work - multiple processors on RPI2/RPI3 - boots normally to multiuser, with FAT32 boot partition on uSD - root filesystem can be uSD or USB-attached mass storage @@ -50,7 +50,7 @@ ## NetBSD 10 - - RPI4 general support (but there are issues) + - RPI4 general support (UEFI firmware required) - RPI4 ethernet (Broadcom GENETv5) (but the man page for genet(4) is missing) - RPI3/RPI4 audio with aarch64 kernels (Previously the driver was only included with 32-bit (ARMv7/ARMv6) kernels, and now works [due to dma-ranges](//mail-index.NetBSD.org/source-changes-d/2021/01/22/msg013133.html). - builtin bluetooth on RPI3 (RPI0W? RPI4?) @@ -59,7 +59,7 @@ ## NetBSD current - - \todo Is anything supported in current that doesn't work in 10? +- RPI5 general support (UEFI firmware required) ## What needs documenting if it works
Fix link for wifi driver state matrix
Index: wikisrc/tutorials.mdwn =================================================================== RCS file: /cvsroot/wikisrc/tutorials.mdwn,v retrieving revision 1.50 retrieving revision 1.51 diff -u -r1.50 -r1.51 --- wikisrc/tutorials.mdwn 23 Mar 2024 18:09:10 -0000 1.50 +++ wikisrc/tutorials.mdwn 8 Oct 2024 11:43:26 -0000 1.51 @@ -44,7 +44,7 @@ * [[Testing new wifi]] * [[Converting drivers to the new wifi stack]] * [[Converting USB drivers to usbwifi(9)]] -* (Current state of wifi drivers)[../wifi driver state matrix] +* [Current state of wifi drivers](../wifi_driver_state_matrix) ### Testing * [[atf]]
note stability
Index: wikisrc/ports/riscv.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/riscv.mdwn,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- wikisrc/ports/riscv.mdwn 29 Sep 2024 07:26:52 -0000 1.8 +++ wikisrc/ports/riscv.mdwn 29 Sep 2024 13:18:16 -0000 1.9 @@ -6,7 +6,8 @@ NetBSD/riscv is a nascent port of NetBSD to RISC-V. Interested individuals can subscribe to the port-riscv mailing list. -NetBSD/riscv64 now works under qemu. +RISC-V support is only available as part of NetBSD-CURRENT and has not +yet been published in a stable release. [[!toc levels=3]] """ @@ -32,6 +33,9 @@ * StarFive VisionFive 2 ### QEMU + +NetBSD/riscv64 now works under qemu. + See the [[NetBSD/riscv under QEMU|qemu_riscv]] page for instructions on how to get started with QEMU. """
some boards that boot
Index: wikisrc/ports/riscv.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/riscv.mdwn,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- wikisrc/ports/riscv.mdwn 30 Mar 2024 19:27:00 -0000 1.7 +++ wikisrc/ports/riscv.mdwn 29 Sep 2024 07:26:52 -0000 1.8 @@ -22,6 +22,15 @@ Most RISC-V boards require a board-specific U-Boot image. A list of supported boards will appear here. +#### Allwinner D1-based devices + +* MangoPi MQ Pro + +#### StarFive JH71XX-based devices + +* BeagleBoard BeagleV +* StarFive VisionFive 2 + ### QEMU See the [[NetBSD/riscv under QEMU|qemu_riscv]] page for instructions on how to get started with QEMU. """
xen-drmkms: Update for PVH heading for normal
Index: wikisrc/projects/project/xen-drmkms.mdwn =================================================================== RCS file: /cvsroot/wikisrc/projects/project/xen-drmkms.mdwn,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- wikisrc/projects/project/xen-drmkms.mdwn 11 Aug 2019 13:35:19 -0000 1.2 +++ wikisrc/projects/project/xen-drmkms.mdwn 20 Sep 2024 17:35:43 -0000 1.3 @@ -16,12 +16,16 @@ description=""" Abstract: -Make the dom0 kernel use and provide drm(4) support. This enable -gui use of dom0. +Make the dom0 kernel use and provide drm(4) support. +This will enable 3d acceleration within of dom0, making it more +reasonable to run a dom0 instead of GENERIC for a workstation that +also supports domUs. + Deliverables: -Functioning X server using native kernel style drmkms support. +Functioning X server using native kernel-style drmkms support. +This must function at least in a PVH style dom0 kernel. Implementation:
xen-domU-pv-on-hvm done
Index: wikisrc/projects/project/xen-domU-pv-on-hvm.mdwn =================================================================== RCS file: /cvsroot/wikisrc/projects/project/xen-domU-pv-on-hvm.mdwn,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- wikisrc/projects/project/xen-domU-pv-on-hvm.mdwn 19 Aug 2015 00:12:08 -0000 1.1 +++ wikisrc/projects/project/xen-domU-pv-on-hvm.mdwn 20 Sep 2024 17:24:06 -0000 1.2 @@ -9,6 +9,8 @@ mentors=""" """ +done_by="" + category="kernel" difficulty="hard" duration="48 hours"
xen-dom0-smp: Mark done
Index: wikisrc/projects/project/xen-dom0-smp.mdwn =================================================================== RCS file: /cvsroot/wikisrc/projects/project/xen-dom0-smp.mdwn,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- wikisrc/projects/project/xen-dom0-smp.mdwn 15 Feb 2018 00:40:11 -0000 1.2 +++ wikisrc/projects/project/xen-dom0-smp.mdwn 20 Sep 2024 17:21:38 -0000 1.3 @@ -9,6 +9,8 @@ mentors=""" """ +done_by="" + category="kernel" difficulty="medium" duration="64 hours"
xen: improve pvh dom0
Thanks to jnemeth@ and bouyer@ for on-list comments.
Thanks to jnemeth@ and bouyer@ for on-list comments.
Members: ports/xen/howto.mdwn:1.267->1.268 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.267 retrieving revision 1.268 diff -u -r1.267 -r1.268 --- wikisrc/ports/xen/howto.mdwn 19 Sep 2024 23:32:28 -0000 1.267 +++ wikisrc/ports/xen/howto.mdwn 20 Sep 2024 17:07:43 -0000 1.268 @@ -71,9 +71,9 @@ [[!table data=""" Style of guest |dom0 can be? |dom0 can support? |domU can be? |needs Hardware Virtualization Support PV |yes |yes |yes |no -PVH |not yet |10/current |10/current |yes +PVH |10+(exp) |10+ |10+ |yes HVM |N/A |yes |yes |yes -PVHVM |N/A |yes |10/current |yes +PVHVM |N/A |yes |10+ |yes """]] In PV (paravirtualized) mode, the guest OS does not attempt to access @@ -176,9 +176,8 @@ NetBSD 8 and later as a dom0 supports running HVM domUs. -NetBSD 10 and later as a domU can be run in PVH and PVHVM modes. - -NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP +NetBSD 10 and later as a domU can be run in PVH and PVHVM modes, and +s a dom0 can (experimentally) be run in PVH mode.etBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP (due to inadequate locking). NetBSD 10 supports SMP in dom0, and XEN3_DOM0 includes "options MULTIPROCESSOR". @@ -286,23 +285,45 @@ First, get a PV dom0 working following the instructions above. -Then, create a copy of the boot line, adding `dom0=pvh` near -`dom0_mem`, and instead of loading a `XEN3_DOM0` kernel, load a -generic kernel with modifications: - - disable i915drmkms, radeon and nouveau (probably, not necessarily?) - - probably include [[!template id=programlisting text=""" +While GENERIC works as a PV guest, it does not have DOM0 support +(which is present in XEN3_DOM0, but that's reduced to be PV only). +Prepare a GENERIC kernel with the additions necessary to be a DOM0, +which consists of code to deal with DOM0 requests, and PV drivers for +the dom0 part of events, network interfaces, and disks. +[[!template id=programlisting text=""" options DOM0OPS pseudo-device xenevt pseudo-device xvif pseudo-device xbdback +# Likely only necessary if you have these devices and booting with them crashes. +no i915drmkms* at pci? +no radeon* at pci? +no nouveau* at pci? +no options DRM_LEGACY + no options DDB_COMMANDONENTER #options DDB_COMMANDONENTER="trace" """]] -\todo Explain whether the DOM0OPS and xen pseudodevices are necessary, -and if so why they aren't in GENERIC (or why there isn't a -XEN3_DOM0PVH). +As an alternative to disabling graphic devices in the kernel, add to /boot.cfg: +[[!template id=programlisting text=""" +userconf=disable i915drmkms* +userconf=disable nouveau* +userconf=disable radeon* +"""]] + +Then, create a copy of the boot line, adding `dom0=pvh` near +`dom0_mem`, and instead of loading a `XEN3_DOM0` kernel, load the +modified GENERIC. + +GENERIC with DOM0OPS and the extra dom0-side PV drivers should work +fine on bare metal and if not it's a bug -- but so far we have no +reports either way. In the glorious future, it will be normal to run +a dom0 as PVH (because it's faster), and to run a domU as PVH or PVHVM +(because it's faster), and thus: - DOM00PS and xenevt, xvif, and +xbdback will be in GENERIC - XEN3_DOM* kernels will be non-preferred +and perhaps not used much \todo Validate that these instructions are correct, and that they work.
xen howto: minor improvements
- add to netbsd dom0 pvh
- explain "ROOT." feature of fstab(5)
- add to netbsd dom0 pvh
- explain "ROOT." feature of fstab(5)
Members: ports/xen/howto.mdwn:1.266->1.267 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.266 retrieving revision 1.267 diff -u -r1.266 -r1.267 --- wikisrc/ports/xen/howto.mdwn 14 Sep 2024 23:08:44 -0000 1.266 +++ wikisrc/ports/xen/howto.mdwn 19 Sep 2024 23:32:28 -0000 1.267 @@ -819,7 +819,14 @@ is to keep "type" lines near "kernel" lines, as they tend to require being changed aat the same time. +## Varying drivers in the domU +For a NetBSD domU using PV drivers (PV, PVH, PVHVM), the disks will +appear as xbdN. For one using emulated drivers (HVM), the disks will +appear as wdN. See fstab(5) which explains how to use "ROOT." instead +of xbd0/wd0. enabling switching modes without changing /etc/fstab. + +\todo Explain if there is a similar approach for network interfaces. ## Creating a NetBSD PV domU @@ -922,8 +929,10 @@ ## Creating a NetBSD PVH dom0 -\todo This might or might not work in current. -\todo The following instructions are likely wrong. +\todo Expand to say NetBSD 10 and later. + +\todo Include needing to add DOM0 OPS and the dom0-flavored +psuedodevices to GENERIC. In boot.cfg, add dom0=pvh (dom0=pv is the default). Configure GENERIC instead of XEN3_DOM0.
projects: rm two projects as completed
Per a discussion today on port-xen, remove two projects as no longer
having work to do. PVH on domU basically works, and works enough on
dom0 that a project would be "test it and fix problems", not
"implement it".
Per a discussion today on port-xen, remove two projects as no longer
having work to do. PVH on domU basically works, and works enough on
dom0 that a project would be "test it and fix problems", not
"implement it".
Members: projects/project/xen-dom0-pvh.mdwn:1.1->1.2(DEAD) projects/project/xen-domU-pvops-pvh.mdwn:1.1->1.2(DEAD) --- wikisrc/projects/project/xen-dom0-pvh.mdwn 2024-09-14 23:13:26.108199717 +0000 +++ /dev/null 2024-09-14 23:13:03.356880356 +0000 @@ -1,48 +0,0 @@ -[[!template id=project - -title="Dom0 hvm container support (PVH)" - -contact=""" -[port-xen](mailto:port-xen@NetBSD.org) -""" - -mentors=""" -""" - -category="kernel" -difficulty="hard" -duration="32 hours" - -description=""" -Abstract: - -NetBSD Dom0 kernels currently operate in fully PV mode. -On amd64, this has the same performance drawbacks as for PV -mode in domU. -Instead, PVH mode provides a HVM container over pagetable -management, while virtualising everything else. This mode is -available on dom0, we attempt to support it. - -Note: Xen/Linux is moving to this dom0 pvh support model. - -Deliverables: PVH mode dom0 operation. - -Implementation: - -This project depends on the domU pvops/pvh -project. The main work is in configuration and -testing related (bringing in native device drivers as -well as backend ones). - -The bootstrap path may need to be tweaked for dom0 -specific things. - -Dependencies: This project depends on completion of the domU -pvops/pvh project. -This project can enable the NetBSD/Xen/ARM dom0 port. - -See <http://wiki.xenproject.org/wiki/Xen_Project_Hypervisor_Roadmap/4.6> -""" - -]] - --- wikisrc/projects/project/xen-domU-pvops-pvh.mdwn 2024-09-14 23:13:26.148771010 +0000 +++ /dev/null 2024-09-14 23:13:03.356880356 +0000 @@ -1,46 +0,0 @@ -[[!template id=project - -title="pvops/pvh - Runtime Paravirtualised/Native Boot with PV drivers in an HVM container in PVH mode" - -contact=""" -[port-xen](mailto:port-xen@NetBSD.org) -""" - -mentors=""" -""" - -category="kernel" -difficulty="hard" -duration="48 hours" - -description=""" -Abstract: This is the final step towards PVH mode. This is relevant -only for DomU. -Xen is moving to this eventual dom0 pvh support model. -This project depends on completion of pv-on-hvm. - -Deliverables: - -* operational interrupt (event) handling -* PV only drivers. - -Implementation: - -Following on from the pv-on-hvm project, this project removes all -remaining dependencies on native drivers. All drivers are PV -only. Interrupt setup and handling is via the "event" mechanism. - -Scope (Timelines): - -This project has some uncertainty based on the change in the interrupt -mechanism. Since the interrupt mechanism moves from apic + IDT based, -to event based, there's room for debug/testing spillover. - -Further, private APIs may need to be developed to parition the pv and -native setup and management code for both mechanisms. - -See: <http://wiki.xenproject.org/wiki/Virtualization_Spectrum#Almost_fully_PV:_PVH_mode> -""" - -]] -
xen: add pvh dom0 caution harder
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.265 retrieving revision 1.266 diff -u -r1.265 -r1.266 --- wikisrc/ports/xen/howto.mdwn 14 Sep 2024 23:01:55 -0000 1.265 +++ wikisrc/ports/xen/howto.mdwn 14 Sep 2024 23:08:44 -0000 1.266 @@ -280,6 +280,9 @@ [caveats](https://xenbits.xen.org/docs/4.19-testing/SUPPORT.html#x86pvh), notably that SR-IOV is missing and PCI passthrough does not work. +Note that while Xen upstream calls it experimental, the NetBSD/xen +community seems to have one person who has gotten it to work and one +who is trying but so far not succeeded. This is a clue! First, get a PV dom0 working following the instructions above.
xen: refine pvh instructions based on bouyer@ email
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.264 retrieving revision 1.265 diff -u -r1.264 -r1.265 --- wikisrc/ports/xen/howto.mdwn 14 Sep 2024 17:51:35 -0000 1.264 +++ wikisrc/ports/xen/howto.mdwn 14 Sep 2024 23:01:55 -0000 1.265 @@ -271,14 +271,35 @@ trouble at some point, and keeping an up-to-date GENERIC for use in fixing problems is the standard prudent approach. -### Setting up PVH +### Setting up the dom0 as PVH -A PVH dom0 is currently experimental. First, get a PV dom0 working -following the instructions above. +A PVH dom0 is currently experimental, as of Xen 4.18. For 4.19 and +later, not yet in pkgsrc, it is +[supported](https://xenbits.xen.org/docs/unstable/support-matrix.html +) with +[caveats](https://xenbits.xen.org/docs/4.19-testing/SUPPORT.html#x86pvh), +notably that SR-IOV is missing and PCI passthrough does not work. + + +First, get a PV dom0 working following the instructions above. Then, create a copy of the boot line, adding `dom0=pvh` near `dom0_mem`, and instead of loading a `XEN3_DOM0` kernel, load a -generic kernel. +generic kernel with modifications: + - disable i915drmkms, radeon and nouveau (probably, not necessarily?) + - probably include [[!template id=programlisting text=""" +options DOM0OPS +pseudo-device xenevt +pseudo-device xvif +pseudo-device xbdback + +no options DDB_COMMANDONENTER +#options DDB_COMMANDONENTER="trace" +"""]] + +\todo Explain whether the DOM0OPS and xen pseudodevices are necessary, +and if so why they aren't in GENERIC (or why there isn't a +XEN3_DOM0PVH). \todo Validate that these instructions are correct, and that they work.
amd64: adjust markup
Index: wikisrc/ports/amd64.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/amd64.mdwn,v retrieving revision 1.39 retrieving revision 1.40 diff -u -r1.39 -r1.40 --- wikisrc/ports/amd64.mdwn 14 Sep 2024 22:35:21 -0000 1.39 +++ wikisrc/ports/amd64.mdwn 14 Sep 2024 22:48:08 -0000 1.40 @@ -31,9 +31,11 @@ multiprocessor (SMP) Opteron configurations. Since the <a class="ulink" href="http://www.NetBSD.org/releases/formal-2.0/NetBSD-2.0.html" target="_top">release of NetBSD 2.0</a>, it is a completely supported platform. +### Running NetBSD/amd64 on Cloud Services + Links to pages about running NetBSD on cloud services: - - https://www.netmeister.org/blog/netbsd-on-linode.html - - https://cloudbsd.xyz/main/ + * https://www.netmeister.org/blog/netbsd-on-linode.html + * https://cloudbsd.xyz/main/ See also the [xen HOWTO](../xen/howto.mdwn) which discusses several xen-based VPS providers.
amd64: Cope with confusing template
Index: wikisrc/ports/amd64.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/amd64.mdwn,v retrieving revision 1.38 retrieving revision 1.39 diff -u -r1.38 -r1.39 --- wikisrc/ports/amd64.mdwn 14 Sep 2024 22:31:54 -0000 1.38 +++ wikisrc/ports/amd64.mdwn 14 Sep 2024 22:35:21 -0000 1.39 @@ -30,7 +30,6 @@ The port is fully functional. It has been tested on single-CPU and multiprocessor (SMP) Opteron configurations. Since the <a class="ulink" href="http://www.NetBSD.org/releases/formal-2.0/NetBSD-2.0.html" target="_top">release of NetBSD 2.0</a>, it is a completely supported platform. -""" Links to pages about running NetBSD on cloud services: - https://www.netmeister.org/blog/netbsd-on-linode.html @@ -38,5 +37,6 @@ See also the [xen HOWTO](../xen/howto.mdwn) which discusses several xen-based VPS providers. +""" ]] [[!tag tier1port]]
amd64: Add link to linode and generic linux replacement instructions
Index: wikisrc/ports/amd64.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/amd64.mdwn,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- wikisrc/ports/amd64.mdwn 30 Mar 2024 19:27:00 -0000 1.37 +++ wikisrc/ports/amd64.mdwn 14 Sep 2024 22:31:54 -0000 1.38 @@ -32,5 +32,11 @@ it is a completely supported platform. """ +Links to pages about running NetBSD on cloud services: + - https://www.netmeister.org/blog/netbsd-on-linode.html + - https://cloudbsd.xyz/main/ + +See also the [xen HOWTO](../xen/howto.mdwn) which discusses several +xen-based VPS providers. ]] [[!tag tier1port]]
xen howto: Move examples to 4.18.
add description of pvh dom0, marked experimental.
add description of pvh dom0, marked experimental.
Members: ports/xen/howto.mdwn:1.263->1.264 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.263 retrieving revision 1.264 diff -u -r1.263 -r1.264 --- wikisrc/ports/xen/howto.mdwn 9 Sep 2024 14:47:25 -0000 1.263 +++ wikisrc/ports/xen/howto.mdwn 14 Sep 2024 17:51:35 -0000 1.264 @@ -216,14 +216,14 @@ ### Building Xen Use the most recent version of Xen in pkgsrc, unless the DESCR says -that it is not suitable. Therefore, choose 4.15. In the dom0, -install xenkernel415 and xentools415 from pkgsrc. +that it is not suitable. Therefore, choose 4.18. In the dom0, +install xenkernel418 and xentools418 from pkgsrc. Once this is done, copy the Xen kernel from where pkgsrc puts it to where the boot process will be able to find it: [[!template id=programlisting text=""" -# cp -p /usr/pkg/xen413-kernel/xen.gz / +# cp -p /usr/pkg/xen418-kernel/xen.gz / """]] Then, place a NetBSD XEN3_DOM0 kernel in the `/` directory. Such @@ -231,7 +231,7 @@ manually, or downloaded from the NetBSD FTP, for example at: [[!template id=programlisting text=""" -ftp.netbsd.org/pub/NetBSD/NetBSD-9.1/amd64/binary/kernel/netbsd-XEN3_DOM0.gz +ftp.netbsd.org/pub/NetBSD/NetBSD-10.0/amd64/binary/kernel/netbsd-XEN3_DOM0.gz """]] ### Configuring booting @@ -271,6 +271,17 @@ trouble at some point, and keeping an up-to-date GENERIC for use in fixing problems is the standard prudent approach. +### Setting up PVH + +A PVH dom0 is currently experimental. First, get a PV dom0 working +following the instructions above. + +Then, create a copy of the boot line, adding `dom0=pvh` near +`dom0_mem`, and instead of loading a `XEN3_DOM0` kernel, load a +generic kernel. + +\todo Validate that these instructions are correct, and that they work. + ### Selecting the console for the boot blocks See boot_console(8). Understand that you should start from a place of
xen howto: Add info about GDS/XSA-435 and AVX2 crashes
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.262 retrieving revision 1.263 diff -u -r1.262 -r1.263 --- wikisrc/ports/xen/howto.mdwn 8 Sep 2024 16:32:52 -0000 1.262 +++ wikisrc/ports/xen/howto.mdwn 9 Sep 2024 14:47:25 -0000 1.263 @@ -398,6 +398,16 @@ indirect branch tracking was disabled, via the "cet=no-ibt" xen boot argument. +In 2024-09, on an Intel i7-12700K under Xen 4.18.0, AVX2 instructions +resulted in a privileged opcode fault. ccache in particular tries to +use AVX2 if the flag is set in cpufeatures. See +[XSA-435](https://xenbits.xen.org/xsa/advisory-435.html). Adding +`spec-ctrl=gds-mit=no` or `spec-ctrl=no-gds-mit` did not help; ccache +still crashed. Adding (an unreasonably large hammer) `spec-ctrl=no` +did not help either. This seems like a bug as Xen loads microcode +which should have the mitigation. However, our Xen 4.18 is at .0, vs +.3. + ### rc.conf Ensure that the boot scripts installed in
xen howto: adust ram, cet=no-ibt
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.261 retrieving revision 1.262 diff -u -r1.261 -r1.262 --- wikisrc/ports/xen/howto.mdwn 8 Sep 2024 13:11:30 -0000 1.261 +++ wikisrc/ports/xen/howto.mdwn 8 Sep 2024 16:32:52 -0000 1.262 @@ -202,10 +202,6 @@ NetBSD system, and then pivots the install to a dom0 install by changing the kernel and boot configuration. -In 2018-05, trouble booting a dom0 was reported with 256M of RAM: with -512M it worked reliably. This does not make sense, but if you see -"not ELF" after Xen boots, try increasing dom0 RAM. - ## Installation of NetBSD [Install NetBSD/amd64](/guide/inst/) just as you would if you were not @@ -252,13 +248,14 @@ menu=Xen single user:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=wd0a console=pc -s;multiboot /xen.gz dom0_mem=1024M """]] -"dom0_mem" is mandatory. This example specifies that the dom0 should -have 1024MB of ram, leaving the rest to be allocated for domUs. Do -not start out with a very low value, because diagnosing too-low dom0 -RAM is difficult, and it may be that a dom0 will fail with an amount -of RAM that would hav been ok on a physical machine. 512 MB is -probably ok; 256M is probably not. (Data points and wisdom should be -sent to port-xen@.) +The dom0_mem parameter specifies how much RAM should be seen by the +dom0 kernel, with the rest (less Xen overhead) available for domU use. +If not given, almost all or all memory will be assigned to the dom0. +Do not start out with a very low value, because diagnosing too-low +dom0 RAM is difficult. In 2018-05, trouble booting a dom0 was +reported with 256M of RAM: with 512M it worked reliably. This does +not make sense, but if you see "not ELF" after Xen boots, try +increasing dom0 RAM. "bootdev" (or the earlier form "root") is also in general required, because the boot device from /boot is not passed via Xen to the dom0 @@ -316,7 +313,7 @@ Xen can be configured to explicitly use only a serial port console, e.g. [[!template id=filecontent name="/boot.cfg" text=""" -menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=512M console=com1 +menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=1024M console=com1 """]] On Xen's console, one can type the escape character (default ^A) three @@ -341,7 +338,7 @@ default xencons(4) for NetBSD and force Xen to serial only: [[!template id=filecontent name="/boot.cfg" text=""" -menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=512M console=com1 +menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=1024M console=com1 """]] To have NetBSD use VGA for a console, add "console=pc" to the NetBSD @@ -349,7 +346,7 @@ VGA only. [[!template id=filecontent name="/boot.cfg" text=""" -menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0 console=pc; multiboot /xen.gz dom0_mem=512M console=vga +menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0 console=pc; multiboot /xen.gz dom0_mem=1024M console=vga """]] If using serial console with Xen, the default of xencons will be @@ -358,7 +355,7 @@ input from the serial port to NetBSD, except for commands for the hypervisor. Thus configure - menu=Xen:load /netbsd-XEN3_DOM0.gz bootdev=sd0; multiboot /xen.gz console=com1 dom0_mem=512M + menu=Xen:load /netbsd-XEN3_DOM0.gz bootdev=sd0; multiboot /xen.gz console=com1 dom0_mem=1024M to force Xen to use serial only, and for NetBSD implicitly to use xencons(4). @@ -397,11 +394,9 @@ until it boots and then removing disable statements to find the minimal set. -On an Intel i7-12700K, Xen crashed until CET was disabled. On the -same CPU, x2apic was perhaps troublesome, but the crash could have -been due to CET. - -\todo Give boot line with max disabled, and the minimal one. +In 2024-09, on an Intel i7-12700K, Xen 4.18 crashed on boot, until CET +indirect branch tracking was disabled, via the "cet=no-ibt" xen boot +argument. ### rc.conf
xen howto: dom0 ram, debugging xen crashes
Change example for dom0 to 1024M. (If you can't allocate 1024M to
dom0, your machine isn't really big enough for Xen.)
Add mention of CET and how to debug crashes.
Change example for dom0 to 1024M. (If you can't allocate 1024M to
dom0, your machine isn't really big enough for Xen.)
Add mention of CET and how to debug crashes.
Add mention of CET and how to debug crashes. Members: ports/xen/howto.mdwn:1.260->1.261 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.260 retrieving revision 1.261 diff -u -r1.260 -r1.261 --- wikisrc/ports/xen/howto.mdwn 5 Sep 2024 22:53:31 -0000 1.260 +++ wikisrc/ports/xen/howto.mdwn 8 Sep 2024 13:11:30 -0000 1.261 @@ -248,12 +248,17 @@ adjusting for your root filesystem: [[!template id=filecontent name="/boot.cfg" text=""" -menu=Xen:load /netbsd-XEN3_DOM0.gz bootdev=wd0a rndseed=/var/db/entropy-file console=pc;multiboot /xen.gz dom0_mem=512M -menu=Xen single user:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=wd0a console=pc -s;multiboot /xen.gz dom0_mem=512M +menu=Xen:load /netbsd-XEN3_DOM0.gz bootdev=wd0a rndseed=/var/db/entropy-file console=pc;multiboot /xen.gz dom0_mem=1024M +menu=Xen single user:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=wd0a console=pc -s;multiboot /xen.gz dom0_mem=1024M """]] -"dom0_mem" is mandatory. This example specifies that the dom0 should -have 512MB of ram, leaving the rest to be allocated for domUs. +"dom0_mem" is mandatory. This example specifies that the dom0 should +have 1024MB of ram, leaving the rest to be allocated for domUs. Do +not start out with a very low value, because diagnosing too-low dom0 +RAM is difficult, and it may be that a dom0 will fail with an amount +of RAM that would hav been ok on a physical machine. 512 MB is +probably ok; 256M is probably not. (Data points and wisdom should be +sent to port-xen@.) "bootdev" (or the earlier form "root") is also in general required, because the boot device from /boot is not passed via Xen to the dom0 @@ -358,17 +363,16 @@ to force Xen to use serial only, and for NetBSD implicitly to use xencons(4). -### Early NetBSD 9 - -When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen -4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line. -(See /src/sys/arch/x86/x86/pmap.c revision 1.410.) - -### Tuning +### Xen Options Related to NetBSD Versions See xen-command-line.html(7), but other than dom0 memory and max_vcpus, tuning options are not generally necessary. +When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen +4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line. +(See /src/sys/arch/x86/x86/pmap.c revision 1.410.) However, no one +should be running early NetBSD 9 in 2024 or later, so fix that instead. + With NetBSD 9 and below, one could add `dom0_max_vcpus=1 dom0_vcpus_pin`, to force only one vcpu to be provided and to pin that vcpu to a physical CPU. \todo Explain if anyone has ever actually @@ -377,6 +381,28 @@ With NetBSD 10 and up, there does not seem to be an argument that pinning or limiting CPUs is a good idea. +From discussion on port-xen@, some machines have problems with +timekeeping, and sometimes having one CPU, and further pinned, seems +to help. + +### Xen Options Related to CPU Features + +In general, Xen detects CPU features and uses them, as upstream judges +prudent. Occasionally this goes not go well. Mostly it works, and in +general one should enable "virtualization support" (often VMX) in the +BIOS, as well as VT-d. The general strategy if Xen crashes on boot is +to use a serial console, and if not possible/practical, record +high-speed video of the vga console. Even with that, the reason for a +crash may not be apparent, leading to disabling everything one can, +until it boots and then removing disable statements to find the +minimal set. + +On an Intel i7-12700K, Xen crashed until CET was disabled. On the +same CPU, x2apic was perhaps troublesome, but the crash could have +been due to CET. + +\todo Give boot line with max disabled, and the minimal one. + ### rc.conf Ensure that the boot scripts installed in
xen: tweak cpufeatures text
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.259 retrieving revision 1.260 diff -u -r1.259 -r1.260 --- wikisrc/ports/xen/howto.mdwn 25 Aug 2024 13:47:06 -0000 1.259 +++ wikisrc/ports/xen/howto.mdwn 5 Sep 2024 22:53:31 -0000 1.260 @@ -46,6 +46,17 @@ There are many choices one can make; the HOWTO recommends the standard approach and limits discussion of alternatives in many cases. +## CPU Architecture + +Xen runs on x86_64 hardware (the NetBSD amd64 port). + +There is a concept of Xen running on arm32 and aarch64, but there are +thus far no reports of this working with NetBSD. + +The dom0 system must be amd64. + +The domU can be i386 PAE or amd64. It can be various operating systems. + ## Guest Styles Xen supports different styles of guests. See @@ -75,7 +86,6 @@ AMD's support is called AMD-V and denoted by the cpuflag SVM. While these features are not identical, Xen can use either. - There have been two PVH modes: original PVH and PVHv2. Original PVH was based on PV mode and is no longer relevant at all. Therefore PVHv2 is written as PVH, here and elsewhere. PVH is basically @@ -88,7 +98,13 @@ With a CPU having the EPT feature, PVH is substantially more efficient than PV because it uses hardware-assisted virtualization. Without EPT, benchmarking results posted in 2024-08 indicate that it is slower -for x86_64 guests. (The EPT feature might be VT-d in cpufeatures.) +for x86_64 guests. + +Some CPUs have a feature Hardware-Assisted Paging (HAP). \todo +Explain how to tell and what it is used for. + +Some Intel CPUs support VT-d, also referred to as IOMMU. This can +allow the hardware to mediate PCI passthrough efficiently and safely. In HVM (Hardware Virtual Machine) mode, guest operating systems with no knowledge of or accomodation for Xen can be run. The dom0 runs @@ -112,17 +128,6 @@ summarize benchmark results more acccurately, once there are a few more. -## CPU Architecture - -Xen runs on x86_64 hardware (the NetBSD amd64 port). - -There is a concept of Xen running on arm32 and aarch64, but there are -thus far no reports of this working with NetBSD. - -The dom0 system must be amd64. - -The domU can be i386 PAE or amd64. It can be various operating systems. - ## Xen Versions In NetBSD, Xen is provided in pkgsrc, via matching pairs of packages
xen howto: Improve PVH/HVM efficiency discussion
Informed by recent benchmarks, and the huge impact of EPT.
Informed by recent benchmarks, and the huge impact of EPT.
Members: ports/xen/howto.mdwn:1.258->1.259 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.258 retrieving revision 1.259 diff -u -r1.258 -r1.259 --- wikisrc/ports/xen/howto.mdwn 26 Jul 2024 00:08:18 -0000 1.258 +++ wikisrc/ports/xen/howto.mdwn 25 Aug 2024 13:47:06 -0000 1.259 @@ -52,10 +52,6 @@ https://wiki.xenproject.org/wiki/Virtualization_Spectrum for a discussion. -Some kinds of guests need hardware support for virtualization. This -support is called "VT-X" by Intel, and is denoted by the cpuflag VMX. -AMD's support is called AMD-V and denoted by the cpuflag SVM. While -these features are not identical, Xen can use either. This table shows the styles, if a NetBSD dom0 can run in that style, if a NetBSD dom0 can support that style of guest in a domU, and @@ -74,12 +70,12 @@ guests must be specifically coded for Xen. See [PV](https://wiki.xen.org/wiki/Paravirtualization_(PV\)). -For various PVH/HVM modes, hardware support is required, such as VT-x -on Intel CPUs and SVM on AMD CPUs to assist with the processor -emulation. +Various PVH/HVM modes need hardware support for virtualization. This +support is called "VT-X" by Intel, and is denoted by the cpuflag VMX. +AMD's support is called AMD-V and denoted by the cpuflag SVM. While +these features are not identical, Xen can use either. + -PVH is substantially more efficient than PV because it uses -hardware-assisted virtualization. There have been two PVH modes: original PVH and PVHv2. Original PVH was based on PV mode and is no longer relevant at all. Therefore PVHv2 is written as PVH, here and elsewhere. PVH is basically @@ -89,6 +85,11 @@ config files use pvh -- these refer to PVHv2. See [PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu). +With a CPU having the EPT feature, PVH is substantially more efficient +than PV because it uses hardware-assisted virtualization. Without +EPT, benchmarking results posted in 2024-08 indicate that it is slower +for x86_64 guests. (The EPT feature might be VT-d in cpufeatures.) + In HVM (Hardware Virtual Machine) mode, guest operating systems with no knowledge of or accomodation for Xen can be run. The dom0 runs qemu to emulate hardware other than the processor. It is therefore @@ -103,6 +104,14 @@ kernel stored in the domU's filesystem. This can be useful in VPS situations where the owner of the domU has no access to the dom0. +With a CPU having the EPT feature, and perhaps HAP and IOMMU, (PV)HVM +appears more efficient than PV. With an older CPU lacking these +features, it can be very slow. + +\todo Explain more about features and how to tell (xl dmesg), and +summarize benchmark results more acccurately, once there are a few +more. + ## CPU Architecture Xen runs on x86_64 hardware (the NetBSD amd64 port).
package upgrading: Bring up to date and light editing
Things have changed a bit in the 2.5 years since this page was
available. Adjust text to present. Add pbulk! Note mk/bulk as
historic.
Things have changed a bit in the 2.5 years since this page was
available. Adjust text to present. Add pbulk! Note mk/bulk as
historic.
Members: pkgsrc/how_to_upgrade_packages.mdwn:1.11->1.12 Index: wikisrc/pkgsrc/how_to_upgrade_packages.mdwn =================================================================== RCS file: /cvsroot/wikisrc/pkgsrc/how_to_upgrade_packages.mdwn,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- wikisrc/pkgsrc/how_to_upgrade_packages.mdwn 23 Aug 2024 13:17:35 -0000 1.11 +++ wikisrc/pkgsrc/how_to_upgrade_packages.mdwn 23 Aug 2024 13:46:17 -0000 1.12 @@ -50,10 +50,21 @@ # Methods that build packages from source -**Note: Be sure you have an updated "pkgsrc" directory. It is recommended that you don't update just parts of the pkgsrc directory.** +pkgsrc is developed and tested with a consistent source tree. While +you can do partial updates, doing so crosses into undefined behavior. +Thus, you should be up to date with respect to the repository, either +on HEAD, a quarterly branch, or much less likely, a specific date on HEAD. + +That said, it is often necessary to update a particular package to an +older date to work around broken updates. This risks difficulty but +can be reasonable for those who can cope. + +Among the options below, the mainstream/popular options are pkg_rolling-replace, and sandbox/separate-computer, and pbulk, which have been listed in (roughly) order of both increasing setup difficulty and increasing reliability. ## make update +Note that there has been little recent discussion of experiences with make update; this is a clue that few are using it, because it is extremely unlikely that people are using it without problems. + 'make update', invoked in a pkgsrc package directory, will remove the package and all packages that depend on it, keeping a list of such packages. It will then attempt to rebuild and install the package and all the packages that were removed. It is possible, and in the case of updating a package with hundreds of dependencies, arguably even likely that the process will fail at some point. One can fix problems and resume the update by typing make update in the original directory, but the system can have unusuable packages for a prolonged period of time. Thus, many people find 'make update' too dangerous, particularly for something like glib on a system using gnome. @@ -62,16 +73,17 @@ To enable manual rollback one can keep binary packages. One method is to always use 'make package', and to have "DEPENDS_TARGET=package" in /etc/mk.conf. Another is to use pkg_tarup to save packages before starting. - ## make replace -The make replace target should only be used by those who understand that there may be ABI issues and can deal with fixing the resulting problems. It is possible that a replaced package will have a different binary interface and thus packages that depend on the replaced packages may not work correctly. This can be because of a shlib (shared library) version bump, where depending package binaries will no longer run, or something more subtle. In these cases, the correct fix is to 'make replace' the problematic depending package. The careful reader will note that this process can in theory require all packages that depend (recursively) on a replaced package to be replaced. See the pkg_rolling-replace section for a way to automate this process. +'make replace' builds a new package and substitutes it, without changing the packages that depend on it. This is good, because large numbers of packages are not removed in the hope they can be rebuilt. It is bad, because depending packages may find ABI breaks, because a shlib major version changed, or something else more subtle, such as changed behavior of a program invoked by another program. If there is an ABI change, the correct approach is to 'make replace' the depending package. The careful reader will note that this process can in theory require all packages that depend (recursively) on a replaced package to be replaced. See the pkg_rolling-replace section for a way to automate this process. -The "make replace" target preserves the existing +REQUIRED_BY file, uninstalls the currently installed package, installs the newly built package, reinstalls the +REQUIRED_BY file, and changes depending packages to reference the new package instead. It also marks such depending packages with the "unsafe_depends" build variable, set to YES. +The "make replace" target preserves the existing +REQUIRED_BY file, uninstalls the currently installed package, installs the newly built package, reinstalls the +REQUIRED_BY file, and changes depending packages to reference the new package instead. It also marks such depending packages with the "unsafe_depends" build variable, set to YES, if the package version changes, and "unsafe_depends_strict" is set in all cases. -It also uses the pkg_tarup tool to create a tarball package for the the currently installed package first, just in case there is a problem. +It can use the pkg_tarup tool to create a tarball package for the the currently installed package first, just in case there is a problem (\todo Check this; it doesn't seem to happen in 2024.) -make replace should preserve the "automatic" build variable, but does not. +### advice to be reconsidered + +\todo Explain this better and perhaps prune; gdt hasn't found any reason to set this, and not any related to make replace. If you are an expert (and don't plan to share your packages publically), you can also use in your mk.conf: @@ -79,11 +91,11 @@ This is for ignoring the ABI dependency recommendations and just use the required DEPENDS. +### Problems occuring during make replace -### Problems with make replace - -Besides ABI changes (for which pkg_rolling-replace is a good solution), make replace can fail if packages are named or split. A particularly tricky case is when package foo is installed, but in pkgsrc has been split into foo and foo-libs. In this case, make replace will try to build the new foo (while the old monolithic foo is installed). The foo package depends on foo-libs, and so pkgsrc will go to build and install foo-libs. This will fail because foo-libs will conflict with the old foo. There are three approaches: +Besides ABI changes (for which pkg_rolling-replace is a good solution), make replace can fail if packages are named or split. A particularly tricky case is when package foo is installed, but in pkgsrc has been split into foo and foo-libs. In this case, make replace will try to build the new foo (while the old monolithic foo is installed). The foo package depends on foo-libs, and so pkgsrc will go to build and install foo-libs. This will fail because foo-libs will conflict with the old foo. There are multiple approaches: + * Use pkg_delete -f, and then make install. This loses dependency information. Run "pkg_admin rebuild-tree". Perhaps do make replace on depending packages. * manually save the foo +REQUIRED_BY file, pkg_delete foo, and then make package of the new foo. Put back the +REQUIRED_BY, and pkg_admin set unsafe_depends=YES all packages in the +REQUIRED_BY. * pkg_delete -r foo, and make package on everything you still want. Or do make update. Note that this could delete a lot. * Automating the first option would be a useful contribution to pkgsrc. @@ -103,7 +115,7 @@ You can set UPDATE_TARGET=package in /etc/mk.conf and specify the -b flag, so that the results of compilation work are saved for later use, and binary packages are used if they are not outdated or dependent on outdated packages. -The main problem with pkg_chk, is that it deinstalls all to-be-upgraded candidates before reinstalling then. However a failure is not fatal, because the current state of packages is saved in a pkg_chk* file at the root of the pkgsrc directory. +The main problem with pkg_chk, is that it deinstalls all to-be-upgraded candidates before reinstalling then. However a failure is not entirely fatal, because the current state of packages is saved in a pkg_chk* file at the root of the pkgsrc directory. But, if new ones can't be built, it is still quite problematic. ## pkg_rolling-replace @@ -112,12 +124,14 @@ Because pkg_rolling-replace just invokes make replace, the problems of ABI changes with make replace apply to pkg_rolling-replace, and the system will be in a state which might be inconsistent while pkg_rolling-replace is executing. But, by the time pkg_rolling-replace has successfully finished, the system will be consistent because every package that has a depending package 'make replaced' out from under it will be marked unsafe_depends, and then replaced itself. This replace "rolls" up the dependency tree because pkg_rolling-replace sorts the packages by dependency and replaces the earliest needing-rebuild package first. -See the pkg_rolling-replace man page (installed by the pkg) for further details. +Also, some "make replace" operations might fail due to new packages having conflicts with old packages (newly split packages, moving files between packages, etc.). These need the same manual intervention. + +See the pkg_rolling-replace man page (installed by the pkg) for further details. Note that it asks that problems with pkg_rolling-replace itself be separated from problems with make replace operations that pkg_rolling-replace chose to do (when the choice was reasonable), and specifically that underlying package build failures not be reported as pkg_rolling-replace problems. ### Example -Find essentials package, that we would rather update manually: +As an example of running pkg_rolling-replace and excluding packages marked not for deletion, perhaps for separate manual updating: cd /var/db/pkg find . -name "+PRESERVE" | awk -F/ '{print $2}' @@ -127,6 +141,8 @@ pkg_rolling-replace -rsuvX bmake,bootstrap-mk-files,pax,pkg_install +(Experience does not suggest that this is necessary; pkg_rolling-replace without these exclusions has not been reported to be problematic. And if so, the problem is almost certainly an underlying issue with the specific package.) + ### Real-world experience with pkg_rolling-replace Even if a lot of packages need to be updated, make replace usually works very well if the interval from the last 'pkg_rolling-replace -u' run is not that long (a month or so). With a longer interval, like a year or two, the odds of package renaming/splitting are higher. Still, for those who can resolve the issues, this is a fairly low-pain and reliable way to update. @@ -165,9 +181,13 @@ An alternative way to choose the packages you want installed is to create your own custom meta-package. A meta-package doesn't install any files itself, but just depends on other packages (usually within a similar topic or need). Have a look at pkgsrc/meta-pkgs category for various examples. If your new meta-package is generic enough and useful for others, please be sure to share it. +## different computer + +One can use another computer (or a VM) and build packages on it, and then e.g. use pkgin. That computer can use any of the methods, with the benefit that until you have a complete set of packages (relative to what you need), you can refrain from changing the operational systems. + ## chroot environment -Nothing special here. This is really basically the same as just having a another physical system to build packages. +This is basically the same as using another computer, except that a chroot is lighter weight than a VM. Manually setup a directory containing your base operating system (including compilers, libraries, shells, etc). Put a copy of your pkgsrc tree and distfiles into there or use mount to mount shared directories containing these. Then use the "chroot" command to chroot into that new directory. You can even switch users from root to a regular user in the new environment. @@ -175,9 +195,13 @@ Then use other technique from this list to install from these packages (built in chroot). -Or instead of using this manual method, use pkg_comp's chroot. +Or instead of using this manual method, use pkgtools/mksandbox, or (older) pkg_comp's chroot. -## pkg_comp's chroot +## pbulk + +See pkgtools/pbulk. This is the standard approach for building packages in bulk. It can be configured to build only packages you want, rather than all of them; building all of them can take between most of 24h, if you have an enormously powerful machine, to 6 months, if you are retrocomputing. + +## pkg_comp Apart from the examples in the man page, it's necessary supply a list of packages you want to build. The command 'pkg_info -u -Q PKGPATH' will produce a list of packages you explicitly requested be installed; in some strong sense, it's what you want to rebuild. @@ -194,6 +218,8 @@ ## bulk build framework +NB: This section is historical and probably should be deleted; see pbulk above. + Use the scripts in pkgsrc/mk/bulk/, e.g. as pointed out in <http://www.netbsd.org/Documentation/pkgsrc/binary.html#bulkbuild>. To go easy on the existing pkgsrc installation, creating a sandbox (automated chroot environment) is highly recommended here: <http://www.netbsd.org/Documentation/pkgsrc/binary.html#setting-up-a-sandbox>. @@ -204,9 +230,9 @@ Or upload them on a www-site and pkg_add <http://www.site/packages/All/><pkg> -## wip/distbb - distributed bulk builds +## wip/distbb-git - distributed bulk builds -Using wip/distbb you may build packages in parallel using several machines and/or chroots. Read PREFIX/share/doc/distbb/README file for the instructions. +Using wip/distbb-git you may build packages in parallel using several machines and/or chroots. Read PREFIX/share/doc/distbb/README file for the instructions. ## pkgdepgraph
Revert vandalism from March of 2022.
Index: wikisrc/pkgsrc/how_to_upgrade_packages.mdwn =================================================================== RCS file: /cvsroot/wikisrc/pkgsrc/how_to_upgrade_packages.mdwn,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- wikisrc/pkgsrc/how_to_upgrade_packages.mdwn 12 Mar 2022 18:27:22 -0000 1.10 +++ wikisrc/pkgsrc/how_to_upgrade_packages.mdwn 23 Aug 2024 13:17:35 -0000 1.11 @@ -1,9 +1,225 @@ -NetBSD consists of a core base system and any third-party software you install -on top. The NetBSD base system can be upgraded in numerous ways, including -booting a new installer image, using the sysupgrade tool, or building from -source. For more information, see -[the NetBSD guide](//www.netbsd.org/docs/guide/en/chap-upgrading.html#using-sysupgrade). - -NetBSD uses [pkgsrc](//www.pkgsrc.org) for managing third-party software. The instructions -for [upgrading pkgsrc packages](//www.NetBSD.org/docs/pkgsrc/using.html#using-pkg) -have moved to the pkgsrc guide. +There are various techniques for upgrading packages either by using pre-built binary package tarballs or by building new packages via pkgsrc build system. This wiki page hopefully will summarize all of the different ways this can be done, with examples and pointing you to further information. + +**Contents** + +[[!toc levels=2]] + +# Methods using only binary packages + + +## pkgin + +The recommended way to manage your system with binary packages is by using [pkgtools/pkgin](http://pkgsrc.se/pkgtools/pkgin). + + pkg_add pkgin + +Then configure your binary repository from which you want to install packages in /usr/pkg/etc/pkgin/repositories.conf. +Run 'pkgin update' to get the list of available packages. You can then install packages using 'pkgin install firefox'. + +To update all installed packages, just run + + pkgin update + pkgin upgrade + + +## pkg_add -uu + +pkg_add's -u option is used to update a package. Basically: it saves the package's current list of packages that depend on it (+REQUIRED_BY), installs the new package, and replaces that list of dependencies. + +By using the -uu (option used twice), it will attempt to update prerequisite packages also. + +See the manual page, [[!template id=man name="pkg_add" section="1"]], for details. + + +## pkg_chk -b + +Use "-b -P URL" where URL is where the binary packages are (e.g. <ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.1/All/>). + +For example, to update any missing packages by using binary packages: + + pkg_chk -b -P URL -u + +Or to automatically add any missing packages using just binary packages: + + pkg_chk -b -P URL -a -C pkg_chk.conf + +If both -b and -P are given, no pkgsrc tree is used. If packages are on the local machine, they are scanned directly, otherwise the pkg_summary database is fetched. (Using pkg_summary for local packages is on the TODO list.) + +(pkg_chk is also covered below.) + + +# Methods that build packages from source + +**Note: Be sure you have an updated "pkgsrc" directory. It is recommended that you don't update just parts of the pkgsrc directory.** + +## make update + +'make update', invoked in a pkgsrc package directory, will remove the package and all packages that depend on it, keeping a list of such packages. It will then attempt to rebuild and install the package and all the packages that were removed. + +It is possible, and in the case of updating a package with hundreds of dependencies, arguably even likely that the process will fail at some point. One can fix problems and resume the update by typing make update in the original directory, but the system can have unusuable packages for a prolonged period of time. Thus, many people find 'make update' too dangerous, particularly for something like glib on a system using gnome. + +To use binary packages if available with "make update", use "UPDATE_TARGET=bin-install". If package tarball is not available in ${PACKAGES} locally or at URLs (defined with BINPKG_SITES), it will build a package from source. + +To enable manual rollback one can keep binary packages. One method is to always use 'make package', and to have "DEPENDS_TARGET=package" in /etc/mk.conf. Another is to use pkg_tarup to save packages before starting. + + +## make replace + +The make replace target should only be used by those who understand that there may be ABI issues and can deal with fixing the resulting problems. It is possible that a replaced package will have a different binary interface and thus packages that depend on the replaced packages may not work correctly. This can be because of a shlib (shared library) version bump, where depending package binaries will no longer run, or something more subtle. In these cases, the correct fix is to 'make replace' the problematic depending package. The careful reader will note that this process can in theory require all packages that depend (recursively) on a replaced package to be replaced. See the pkg_rolling-replace section for a way to automate this process. + +The "make replace" target preserves the existing +REQUIRED_BY file, uninstalls the currently installed package, installs the newly built package, reinstalls the +REQUIRED_BY file, and changes depending packages to reference the new package instead. It also marks such depending packages with the "unsafe_depends" build variable, set to YES. + +It also uses the pkg_tarup tool to create a tarball package for the the currently installed package first, just in case there is a problem. + +make replace should preserve the "automatic" build variable, but does not. + +If you are an expert (and don't plan to share your packages publically), you can also use in your mk.conf: + + USE_ABI_DEPENDS?=no + +This is for ignoring the ABI dependency recommendations and just use the required DEPENDS. + + +### Problems with make replace + +Besides ABI changes (for which pkg_rolling-replace is a good solution), make replace can fail if packages are named or split. A particularly tricky case is when package foo is installed, but in pkgsrc has been split into foo and foo-libs. In this case, make replace will try to build the new foo (while the old monolithic foo is installed). The foo package depends on foo-libs, and so pkgsrc will go to build and install foo-libs. This will fail because foo-libs will conflict with the old foo. There are three approaches: + + * manually save the foo +REQUIRED_BY file, pkg_delete foo, and then make package of the new foo. Put back the +REQUIRED_BY, and pkg_admin set unsafe_depends=YES all packages in the +REQUIRED_BY. + * pkg_delete -r foo, and make package on everything you still want. Or do make update. Note that this could delete a lot. + * Automating the first option would be a useful contribution to pkgsrc. + +In addition, any problem that can occur with building a package can occur with make replace. Usually, the solution is not make replace specific + + +## pkg_chk + +See all packages which need upgrading: + + pkg_chk -u -q + +Update packages from sources: + + pkg_chk -u -s + +You can set UPDATE_TARGET=package in /etc/mk.conf and specify the -b flag, so that the results of compilation work are saved for later use, and binary packages are used if they are not outdated or dependent on outdated packages. + +The main problem with pkg_chk, is that it deinstalls all to-be-upgraded candidates before reinstalling then. However a failure is not fatal, because the current state of packages is saved in a pkg_chk* file at the root of the pkgsrc directory. + + +## pkg_rolling-replace + +[pkgtools/pkg_rolling-replace](http://pkgsrc.se/pkgtools/pkg_rolling-replace) is a shell script available via pkgsrc. It makes a list of all packages that need updating, and sorts them in dependency order. Then, it invokes "make replace" on the first one, and repeats. A package needs updating if it is marked unsafe_depends or if it is marked rebuild (=YES). If pkg_rolling-replace is invoked with -u, a package needs updating if [pkgtools/pkg_chk](http://pkgsrc.se/pkgtools/pkg_chk) reports that the installed version differs from the source version. On error, pkg_rolling-replace exits. The user should remove all working directories and fix the reported problem. This can be tricky, but the same process that is appropriate for a make replace should be followed. + +Because pkg_rolling-replace just invokes make replace, the problems of ABI changes with make replace apply to pkg_rolling-replace, and the system will be in a state which might be inconsistent while pkg_rolling-replace is executing. But, by the time pkg_rolling-replace has successfully finished, the system will be consistent because every package that has a depending package 'make replaced' out from under it will be marked unsafe_depends, and then replaced itself. This replace "rolls" up the dependency tree because pkg_rolling-replace sorts the packages by dependency and replaces the earliest needing-rebuild package first. + +See the pkg_rolling-replace man page (installed by the pkg) for further details. + + +### Example + +Find essentials package, that we would rather update manually: + + cd /var/db/pkg + find . -name "+PRESERVE" | awk -F/ '{print $2}' + +Update everything except the packages above: + + pkg_rolling-replace -rsuvX bmake,bootstrap-mk-files,pax,pkg_install + + +### Real-world experience with pkg_rolling-replace + +Even if a lot of packages need to be updated, make replace usually works very well if the interval from the last 'pkg_rolling-replace -u' run is not that long (a month or so). With a longer interval, like a year or two, the odds of package renaming/splitting are higher. Still, for those who can resolve the issues, this is a fairly low-pain and reliable way to update. + + +## Delete everything + +If you don't have a production environment or don't care if your packages will be missing for a while, you can just delete everything and reinstall. + +This method is the easiest: + + # pkg_delete -Rr '*-*' + +-or- + + # pkg_delete -ff '*-*' + +This expands to all packages, and deletes all packages without caring about dependencies. The second version of the command should be faster, as it does not perform any dependency recursion. (The quotes around the wildcards are so it doesn't get expanded by the shell first.) + +Here is one idea (from posting on pkgsrc-users): + +Get a list of packages installed: + + # pkg_info -Q PKGPATH -a > pkgs_i_want_to_have + +Remove all the packages: + + # pkg_info -a | sed 's/ .*//' | tail -r | while read p ; do pkg_delete $p ; done + +(There are many ways to do this.) + +Then edit your "pkgs_i_want_to_have" (created above) as needed. And reinstall just those from it: + + # cat pkgs_i_want_to_have | (while read pp ; do cd /usr/pkgsrc/$pp ; make && make install ; done) + +An alternative way to choose the packages you want installed is to create your own custom meta-package. A meta-package doesn't install any files itself, but just depends on other packages (usually within a similar topic or need). Have a look at pkgsrc/meta-pkgs category for various examples. If your new meta-package is generic enough and useful for others, please be sure to share it. + + +## chroot environment + +Nothing special here. This is really basically the same as just having a another physical system to build packages. + +Manually setup a directory containing your base operating system (including compilers, libraries, shells, etc). Put a copy of your pkgsrc tree and distfiles into there or use mount to mount shared directories containing these. Then use the "chroot" command to chroot into that new directory. You can even switch users from root to a regular user in the new environment. + +Then build and remove packages as you wish with out affecting your real production system. Be sure to create packages for everything. + +Then use other technique from this list to install from these packages (built in chroot). + +Or instead of using this manual method, use pkg_comp's chroot. + +## pkg_comp's chroot + +Apart from the examples in the man page, it's necessary supply a list of packages you want to build. The command 'pkg_info -u -Q PKGPATH' will produce a list of packages you explicitly requested be installed; in some strong sense, it's what you want to rebuild. (Diff truncated)
link to NetBSD/evbarm 10.x images
Index: wikisrc/amazon_ec2/bsdec2_image_upload.mdwn =================================================================== RCS file: /cvsroot/wikisrc/amazon_ec2/bsdec2_image_upload.mdwn,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- wikisrc/amazon_ec2/bsdec2_image_upload.mdwn 16 Jul 2021 09:36:07 -0000 1.2 +++ wikisrc/amazon_ec2/bsdec2_image_upload.mdwn 18 Aug 2024 19:55:41 -0000 1.3 @@ -16,7 +16,9 @@ ### Arm * NetBSD -current: <http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz> -* NetBSD 9.x: <http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz> +* NetBSD 10.0 (official release): <https://ftp.netbsd.org/pub/NetBSD/NetBSD-10.0/evbarm-aarch64/binary/gzimg/arm64.img.gz> +* NetBSD 10.x (latest): <http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz> +* NetBSD 9.x (latest): <http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz> ## Prerequisites
Index: wikisrc/laptops.mdwn =================================================================== RCS file: /cvsroot/wikisrc/laptops.mdwn,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- wikisrc/laptops.mdwn 26 Jul 2024 09:13:06 -0000 1.37 +++ wikisrc/laptops.mdwn 6 Aug 2024 18:35:28 -0000 1.38 @@ -158,14 +158,8 @@ * Ethernet is supported through the [[!template id=man name="wm" section="4"]] driver. * WiFi is supported through the [[!template id=man name="iwm" section="4"]] driver. * Extra trackpoint buttons: run at least 9.0_STABLE for fixes to the Synaptics driver. -* Brightness buttons do not work in 9.0 by default. You can bind them to - xrandr in your window manager. -* Webcam will depend on upcoming xhci isochronous pipe support. +* Webcam works. * To record from the internal mic, set `mixerctl -w record.source=ADC02` -* Some spam from [[!template id=man name="hdaudio" section="4"]] on some - reboots, the chip doesn't seem to reset properly. Disappears and boots - normally after a few seconds. - [[!template id=pr number=51734]] * Suspend and resume work. ## ThinkPad X260 @@ -175,10 +169,21 @@ * Ethernet is supported through the [[!template id=man name="wm" section="4"]] driver. * WiFi is supported through the [[!template id=man name="iwm" section="4"]] driver. * Extra trackpoint buttons: run at least 9.0_STABLE for fixes to the Synaptics driver. -* Webcam will depend on upcoming xhci isochronous pipe support. +* Webcam works. * Suspend and resume work. * Bluetooth works. +## ThinkPad X270 + +Hardware is very similar to the X260. + +## ThinkPad A475 + +* GPU acceleration works with the amdgpu driver in NetBSD 10 (not built into the default kernel, though) +* WiFi may not be supported, consider a [[!template id=man name="urtwn" section="4"]] dongle. +* Ethernet is supported through the [[!template id=man name="re" section="4"]] driver. +* Suspend/resume almost fully works - the USB3 ports stop working after resume. + --- # Asus
netbsd 10 audio selection fun
Index: wikisrc/laptops.mdwn =================================================================== RCS file: /cvsroot/wikisrc/laptops.mdwn,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- wikisrc/laptops.mdwn 3 May 2024 12:45:37 -0000 1.36 +++ wikisrc/laptops.mdwn 26 Jul 2024 09:13:06 -0000 1.37 @@ -85,6 +85,11 @@ [[!template id=man name="mixerctl" section="1"]] variable can be modified. +Since NetBSD 10, it's possible that the kernel may prefer +to use HDMI audio over the internal chip - +use [[!template id=man name="audiocfg" section="1"]] to change +its preference. + ## Sensors Regardless of whether the system is ACPI, NetBSD will
add link to tutorial.
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.257 retrieving revision 1.258 diff -u -r1.257 -r1.258 --- wikisrc/ports/xen/howto.mdwn 25 Jul 2024 23:00:31 -0000 1.257 +++ wikisrc/ports/xen/howto.mdwn 26 Jul 2024 00:08:18 -0000 1.258 @@ -21,6 +21,10 @@ not, it is best to ask on port-xen and if you are correct to file a PR. +See also an [earlier Xen tutorial] +(http://wiki.netbsd.org/tutorials/how_to_set_up_a_guest_os_using_xen3/) +which should perhaps be folded into this HOWTO. + [[!toc]] # Overview @@ -555,6 +559,10 @@ power-press event and do a clean shutdown. Shutting down the dom0 will trigger controlled shutdowns of all configured domUs. +## Logs + +Look in /var/log/xen/* for logs written at creation time. + ## CPU and memory A domain is provided with some number of vcpus; any domain can have up @@ -580,6 +588,24 @@ [upstream documentation] (https://xenbits.xenproject.org/docs/4.18-testing/man/xl-disk-configuration.5.html). +Read the man page carefully. Note that NetBSD has a culture of using +deprecated positional syntax. This HOWTO is converting to keyword +syntax. + +One big hint is that vdev= must precede target, despite the order in +which keywords are documented, and despite the fact that obviously +keywords may be in any order. \todo Check and maybe file a bug. + +A second hint is that for a target in PV mode, one must give a block +device. But for a target in HVM mode, one must give the raw device. +If passing a block device, xen tries to transform it and adds a +suprious r. \todo Check and maybe file a bug. + +A third is that vdev can be 0x0 in PV mode but must be something like +hda in HVM mode. + +\todo Fold in or gc the following. + For key-value pairs: \todo For 3-tuples: @@ -627,6 +653,9 @@ configurations. We focus on two common and useful cases for which there are existing scripts: bridging and NAT. +See the [upstream documentation] +(https://xenbits.xen.org/docs/unstable/man/xl-network-configuration.5.html). + With bridging (in the example above), the domU perceives itself to be on the same network as the dom0. For server virtualization, this is usually best. Bridging is accomplished by creating a bridge(4) device
xen: minor formatting
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.256 retrieving revision 1.257 diff -u -r1.256 -r1.257 --- wikisrc/ports/xen/howto.mdwn 25 Jul 2024 19:56:23 -0000 1.256 +++ wikisrc/ports/xen/howto.mdwn 25 Jul 2024 23:00:31 -0000 1.257 @@ -576,8 +576,9 @@ ## Virtual disks In domU config files, disks can be defined by key-value pairs or as a -sequence of 3-tuples. See the [upstream -documentation](https://xenbits.xenproject.org/docs/4.18-testing/man/xl-disk-configuration.5.html).q +sequence of 3-tuples. See the +[upstream documentation] +(https://xenbits.xenproject.org/docs/4.18-testing/man/xl-disk-configuration.5.html). For key-value pairs: \todo @@ -880,7 +881,7 @@ disk = [ 'phy:/dev/wd0e,0x1,w' ] does matter to Linux. It wants a Linux device number here (e.g. 0x300 -for hda). Linux builds device numbers as: (major \<\< 8 + minor). +for hda). Linux builds device numbers as: (major << 8 + minor). So, hda1 which has major 3 and minor 1 on a Linux system will have device number 0x301. Alternatively, devices names can be used (hda, hdb, ...) as xentools has a table to map these names to devices
pvh nits
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.255 retrieving revision 1.256 diff -u -r1.255 -r1.256 --- wikisrc/ports/xen/howto.mdwn 14 Jul 2024 17:18:50 -0000 1.255 +++ wikisrc/ports/xen/howto.mdwn 25 Jul 2024 19:56:23 -0000 1.256 @@ -311,7 +311,7 @@ XEN3_DOM0 uses xencons(4) as its console. It will use vga if console=pc has been passed. -Using xencons(4) is only sensible if Xen is using appp serial console, +Using xencons(4) is only sensible if Xen is using a serial console, because Xen will have relinquished the vga console. NetBSD will connect its console(4) device to xencons(4) and console I/O will happen there, and thus on the console Xen is using. To use the @@ -802,12 +802,13 @@ from Xen 4.15 to 4.18, the only change needed for an i386 domU is the two lines above. -It seems that this use of pvh (for i386 guests) works ok even on -systems that lack VT-X/SVM. +This use of pvh (for i386 guests) worked ok even on a system that +lacked VMX (Intel E5700). -There is 1 data point that it seems to work for amd64 PV guests on a -system without VT-X/SVM, but with abysmal performance (at least 100x -slowdown). \todo Confirm speed issue, file a PR, and explain. +There is 1 data point that it seems to work for amd64 PV guests (on a +system with VMX, and one without), but with abysmal performance (on +the order of 100x slowdown). \todo Get confirmation from someone +else, and decide what to do. ## Creating a NetBSD PVH dom0 @@ -851,9 +852,9 @@ ## Creating a NetBSD PVHVM domU -Exactly as HVM, except don't disable the PV drivers. +Exactly as HVM, except allow the PV drivers that are in GENERIC to remain. -When a PVHVM guest attaches hypervisor0, which happens, before regular +When a PVHVM guest attaches hypervisor0, which happens before regular devices, code in sys/arch/xen/xen/hypervisor.c:hypervisor_attach() asks the hypervisor to disable emulated disks and network. Thus, despite the guest's kernel supporting emulated disks, and the
abi: New stub page for ABI documentation and references.
--- /dev/null 2024-07-25 14:32:03.549279250 +0000 +++ wikisrc/abi.mdwn 2024-07-25 14:32:34.917187900 +0000 @@ -0,0 +1,25 @@ +# NetBSD ABI: Application Binary Interface + +Documentation and references for the NetBSD ABI. + +## ELF + +XXX + +## Thread-local storage + +XXX + +## Exception handling and unwinding + +XXX + +## Processor supplements + +XXX + +## Library versioning and compatibility + +XXX + +[XXX symbol versioning|symbol_versions]
xen howto: explain how PVHVM avoids seeing emulated disks/networking
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.254 retrieving revision 1.255 diff -u -r1.254 -r1.255 --- wikisrc/ports/xen/howto.mdwn 14 Jul 2024 15:54:07 -0000 1.254 +++ wikisrc/ports/xen/howto.mdwn 14 Jul 2024 17:18:50 -0000 1.255 @@ -829,8 +829,8 @@ Use type='hvm'. Use a GENERIC kernel within the disk image, or an INSTALL cd image. The disk image should have bootblocks, as if it -were a real machine. Note that because GENERIC has PV drivers, this -will be PVHVM if you dno't remove them. +were a real machine. (Note that because GENERIC has PV drivers, this +will be PVHVM, unless you remove or disable them.) Perhaps configure serial="pty" to gain access to the domUs first serial port (and hence console?). @@ -853,8 +853,12 @@ Exactly as HVM, except don't disable the PV drivers. -\todo Explain if declaring pvhvm vs hvm causes disk/networking to -appear as PV instead of emulated, or ? +When a PVHVM guest attaches hypervisor0, which happens, before regular +devices, code in sys/arch/xen/xen/hypervisor.c:hypervisor_attach() +asks the hypervisor to disable emulated disks and network. Thus, +despite the guest's kernel supporting emulated disks, and the +hypervisor supporting them, such a guest will only see PV disks -- +which is the point of PVHVM vs HVM. ## Creating a FreeBSD domU
xen: add link to bouyer@ scripts
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.253 retrieving revision 1.254 diff -u -r1.253 -r1.254 --- wikisrc/ports/xen/howto.mdwn 13 Jul 2024 14:27:46 -0000 1.253 +++ wikisrc/ports/xen/howto.mdwn 14 Jul 2024 15:54:07 -0000 1.254 @@ -173,7 +173,10 @@ significantly and because renaming it would not be useful. See also -[NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/). +[NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/) +for automated tests of various domU styles and the +[scripts to run the tests](https://ftp.netbsd.org/pub/NetBSD/misc/bouyer/nbsd-tests/) +as a source of configuration hints. # Creating a NetBSD dom0 @@ -706,6 +709,8 @@ is to keep "type" lines near "kernel" lines, as they tend to require being changed aat the same time. + + ## Creating a NetBSD PV domU See the earlier config file, and adjust memory. Decide on how much
xen howto: typos
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.252 retrieving revision 1.253 diff -u -r1.252 -r1.253 --- wikisrc/ports/xen/howto.mdwn 13 Jul 2024 14:15:58 -0000 1.252 +++ wikisrc/ports/xen/howto.mdwn 13 Jul 2024 14:27:46 -0000 1.253 @@ -53,8 +53,8 @@ AMD's support is called AMD-V and denoted by the cpuflag SVM. While these features are not identical, Xen can use either. -This table shows the styles, and if a NetBSD dom0 can run in that -style, if a NetBSD dom0 can sypport that style of guest in a domU, and +This table shows the styles, if a NetBSD dom0 can run in that +style, if a NetBSD dom0 can support that style of guest in a domU, and if NetBSD as a domU can support that style. [[!table data="""
xen howto: enhance grub
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.251 retrieving revision 1.252 diff -u -r1.251 -r1.252 --- wikisrc/ports/xen/howto.mdwn 13 Jul 2024 13:13:20 -0000 1.251 +++ wikisrc/ports/xen/howto.mdwn 13 Jul 2024 14:15:58 -0000 1.252 @@ -654,19 +654,9 @@ xendomains="domU-netbsd domU-linux" """]] -# domU setup for specific systems - -Creating domUs is almost entirely independent of operating system. We -have already presented the basics of config files in the previous system. +# domU general setup -Of course, this section presumes that you have a working dom0. - -Many of the following examples advise adding lines to config files. -While it (mostly?) doesn't matter how lines are ordered, best practice -is to keep "type" lines near "kernel" lines, as they tend to require -being changed aat the same time. - -## PV/PVh kernels +## PV/PVH kernels For PV/PVH, one specifies the domU's kernel as a file in the dom0 filesystem. The kernel must support PV, and can be either @@ -696,11 +686,25 @@ There have been multiple flavors of grub that can be used this way over the years, and the situation is a little confusing. -\todo It remains to describe it properly. -See the sections below about Panix and Tornado VPS. +See [Xen's Booting Overview](https://wiki.xenproject.org/wiki/Booting_Overview). +and the more detailed [pvgrub2 page](https://wiki.xenproject.org/wiki/PvGrub2). + +See [Debian's pvgrub page](https://wiki.debian.org/PvGrub). -See the [Xen Project's pvgrub2 page](https://wiki.xenproject.org/wiki/PvGrub2). +For information about how specific provider's address booting, +see the sections below about Panix and Tornado VPS. +See also [Bitfolk's Booting page](https://tools.bitfolk.com/wiki/Booting). + +The pkgsrc xentools418 package has pygrub, which is very old. There +are no recent reports of anyone using it. + +# domU setup for specific systems + +Many of the following examples advise adding lines to config files. +While it (mostly?) doesn't matter how lines are ordered, best practice +is to keep "type" lines near "kernel" lines, as they tend to require +being changed aat the same time. ## Creating a NetBSD PV domU
howto: adjust hw virtualization names to reality
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.250 retrieving revision 1.251 diff -u -r1.250 -r1.251 --- wikisrc/ports/xen/howto.mdwn 12 Jul 2024 14:34:30 -0000 1.250 +++ wikisrc/ports/xen/howto.mdwn 13 Jul 2024 13:13:20 -0000 1.251 @@ -48,12 +48,17 @@ https://wiki.xenproject.org/wiki/Virtualization_Spectrum for a discussion. +Some kinds of guests need hardware support for virtualization. This +support is called "VT-X" by Intel, and is denoted by the cpuflag VMX. +AMD's support is called AMD-V and denoted by the cpuflag SVM. While +these features are not identical, Xen can use either. + This table shows the styles, and if a NetBSD dom0 can run in that style, if a NetBSD dom0 can sypport that style of guest in a domU, and if NetBSD as a domU can support that style. [[!table data=""" -Style of guest |dom0 can be? |dom0 can support? |domU can be? |needs VT-X/SVM +Style of guest |dom0 can be? |dom0 can support? |domU can be? |needs Hardware Virtualization Support PV |yes |yes |yes |no PVH |not yet |10/current |10/current |yes HVM |N/A |yes |yes |yes @@ -69,8 +74,8 @@ on Intel CPUs and SVM on AMD CPUs to assist with the processor emulation. -PVH is substantially more efficient than PV because it uses hardware -assisted virtualization. +PVH is substantially more efficient than PV because it uses +hardware-assisted virtualization. There have been two PVH modes: original PVH and PVHv2. Original PVH was based on PV mode and is no longer relevant at all. Therefore PVHv2 is written as PVH, here and elsewhere. PVH is basically @@ -661,20 +666,50 @@ is to keep "type" lines near "kernel" lines, as they tend to require being changed aat the same time. +## PV/PVh kernels + +For PV/PVH, one specifies the domU's kernel as a file in the dom0 +filesystem. The kernel must support PV, and can be either +uncompressed or compressed (ending in .gz). + ## Stub domains Xen has a concept of stub domains, where the qemu part of HVM is in a domU. \todo Explain better, and once understood, migrate this section to where it belongs. +## Boot mechanisms + +For PV and PVH domUs, the kernel is specified in the config file and +taken from the dom0 filesystem. + +For HVM (and PVHVM) domUs, the boot code on the domUs disk is +executed. + +Sometimes, one wants to run a PV or PVH system but have the kernel +obtained from within the domU. This is particularly important when +the domU administrator lacks privileges on the dom0, such as VPS +setups. In these cases, the domU can be configured to load a +bootloader, typically grub, instead of the real kernel. Xen then runs +the bootloader, which can read the disk, find the real kernel, and +then load and run it. + +There have been multiple flavors of grub that can be used this way +over the years, and the situation is a little confusing. +\todo It remains to describe it properly. + +See the sections below about Panix and Tornado VPS. + +See the [Xen Project's pvgrub2 page](https://wiki.xenproject.org/wiki/PvGrub2). + ## Creating a NetBSD PV domU See the earlier config file, and adjust memory. Decide on how much storage you will provide, and prepare it (file or LVM). -While the kernel will be obtained from the dom0 file system, the same -file should be present in the domU as /netbsd so that tools like -savecore(8) can work. (This is helpful but not necessary.) +While the kernel will be obtained from the dom0 file system, it is +helpful but not necessary for the same kernel to be present in the +domU as /netbsd so that tools like savecore(8) can work. The kernel must be specifically built for Xen, to use PV interfaces as a domU. NetBSD release builds provide the following kernels: @@ -691,12 +726,12 @@ and can load sets from the network. To do this, copy the INSTALL kernel to / and change the kernel line in the config file to: - kernel = "/home/bouyer/netbsd-INSTALL_XEN3_DOMU" + kernel = "/netbsd-INSTALL_XEN3_DOMU" Then, start the domain as "xl create -c configfile". -Alternatively, if you want to install NetBSD/Xen with a CDROM image, the following -line should be used in the config file. +Alternatively, if you want to install NetBSD/Xen with a physical +CDROM, the following line should be used in the config file. disk = [ 'phy:/dev/wd0e,0x1,w', 'phy:/dev/cd0a,0x2,r' ]
clarify pvhvm vs hvm
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.249 retrieving revision 1.250 diff -u -r1.249 -r1.250 --- wikisrc/ports/xen/howto.mdwn 12 Jul 2024 14:12:22 -0000 1.249 +++ wikisrc/ports/xen/howto.mdwn 12 Jul 2024 14:34:30 -0000 1.250 @@ -785,7 +785,8 @@ Use type='hvm'. Use a GENERIC kernel within the disk image, or an INSTALL cd image. The disk image should have bootblocks, as if it -were a real machine. +were a real machine. Note that because GENERIC has PV drivers, this +will be PVHVM if you dno't remove them. Perhaps configure serial="pty" to gain access to the domUs first serial port (and hence console?). @@ -806,10 +807,10 @@ ## Creating a NetBSD PVHVM domU -Probably just like HVM, except ensure that GENERIC has PV drivers also. +Exactly as HVM, except don't disable the PV drivers. \todo Explain if declaring pvhvm vs hvm causes disk/networking to -appear as PV instead of emulated. +appear as PV instead of emulated, or ? ## Creating a FreeBSD domU
xen howto
- update vps providers
- udpate pvh/hvm config from Manuel's test runs
- clean up pre-9 references
- simplify language in various places
- update vps providers
- udpate pvh/hvm config from Manuel's test runs
- clean up pre-9 references
- simplify language in various places
Members: ports/xen/howto.mdwn:1.248->1.249 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.248 retrieving revision 1.249 diff -u -r1.248 -r1.249 --- wikisrc/ports/xen/howto.mdwn 12 Jul 2024 13:36:19 -0000 1.248 +++ wikisrc/ports/xen/howto.mdwn 12 Jul 2024 14:12:22 -0000 1.249 @@ -148,29 +148,27 @@ versions has been pruned. Xen has been supported in NetBSD for a long time, at least since 2005. -Initially Xen was PV only. +NetBSD Xen has always supported PV (originally, Xen simply was PV), in +both dom0 and domU. -NetBSD Xen has always supported PV, in both dom0 and domU. -NetBSD 8 and later as a dom0 supports HVM mode in domUs. +NetBSD 8 and later as a dom0 supports running HVM domUs. -Support for PVH and PVHVM is available in NetBSD 10; this is currently -somewhat experimental, although PVHVM appears reasonably solid. +NetBSD 10 and later as a domU can be run in PVH and PVHVM modes. -NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP. -Even if one added "options MULTIPROCESSOR" and configured multiple -vcpus, the kernel is likely to crash because of drivers without -adequate locking. NetBSD 10 supports SMP in dom0, and XEN3_DOM0 -includes "options MULTIPROCESSOR". - -NetBSD (since NetBSD 6), when run as a domU, can run SMP, using -multiple CPUs if provided. The XEN3_DOMU kernel is built -with "options MULITPROCESSOR". +NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP +(due to inadequate locking). NetBSD 10 supports SMP in dom0, and +XEN3_DOM0 includes "options MULTIPROCESSOR". + +NetBSD 6 and later, when run as a domU, can run SMP, using multiple +CPUs if provided. The XEN3_DOMU kernel is built with "options +MULITPROCESSOR". Note that while the current version of Xen is 4.X, the kernel support is still called XEN3, because the hypercall interface has not changed significantly and because renaming it would not be useful. -See also [NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/). +See also +[NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/). # Creating a NetBSD dom0 @@ -777,20 +775,21 @@ ## Creating a NetBSD PVH domU -\todo Check/fix these instructions. - -This is only supported for NetBSD 10 and up as the guest. - Use type='pvh'. Configure a GENERIC kernel instead of XEN3_DOMU. There is a PR about i386 PVH guests, but they work fine during daily tests. See [PR 57199](https://gnats.netbsd.org/57199). +See [NetBSD daily tests](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/). ## Creating a NetBSD HVM domU -Use a GENERIC kernel within the disk image. Use bootblocks, as if it +Use type='hvm'. Use a GENERIC kernel within the disk image, or an +INSTALL cd image. The disk image should have bootblocks, as if it were a real machine. +Perhaps configure serial="pty" to gain access to the domUs first +serial port (and hence console?). + This config snippet was stolen from a port-xen post. It might not quite work, as it was in the context of debugging issues apparently from zvol usage. @@ -865,7 +864,7 @@ ## Creating a Solaris domU -See possibly outdated +See the very outdated [Solaris domU instructions](/ports/xen/howto-solaris/). ## PCI passthrough: Using PCI devices in guest domains @@ -1093,18 +1092,15 @@ The intent is to list providers only if they document support for running NetBSD, and to point to their resources briefly. - ### panix.com [Panix](http://www.panix.com/) provides NetBSD as an OS option. See their [Colocated Virtual Servers](https://www.panix.com/v-colo/) page -for more information. NetBSD 9 is available in PV mode, -straightforwardly for amd64 and using the pvh/pvshim=1 technique -described above for i386. NetBSD 10 amd64 is available to customers -in PVHVM mode, enabling booting a kernel from the VPS's filesystem. -(NetBSD 10 also runs in PV and PVH mode on Panix's infrastructure, but -PVHVM mode is preferred because it allows easy user control over the -kernel.) +for more information. NetBSD 9 is available in PV mode, (pvh/pvshim=1 +for i386). NetBSD 10 amd64 is available to customers in PVHVM mode, +enabling booting a kernel from the VPS's filesystem. (NetBSD 10 also +runs in PV and PVH mode on Panix's infrastructure, but PVHVM mode is +preferred because it allows easy user control over the kernel.) ### tornadovps.com @@ -1114,9 +1110,9 @@ /boot). See the [tornadovps.com NetBSD instructions](https://tornadovps.com/documentation/netbsd). -The main path for NetBSD is PV mode, but HVM modes might also work. +The main path for NetBSD is PV mode; HVM modes are experimental. -As of 2023-12, NetBSD 10 kernels booting in PV mode crash during booting. +See the "Grant Table Hypervisor Bug" above. ### precedence.co.uk
xen howto: Merge in comments from bouyer@
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.247 retrieving revision 1.248 diff -u -r1.247 -r1.248 --- wikisrc/ports/xen/howto.mdwn 12 Jul 2024 11:35:09 -0000 1.247 +++ wikisrc/ports/xen/howto.mdwn 12 Jul 2024 13:36:19 -0000 1.248 @@ -55,9 +55,9 @@ [[!table data=""" Style of guest |dom0 can be? |dom0 can support? |domU can be? |needs VT-X/SVM PV |yes |yes |yes |no -PVH |not yet |10/current |10/current |no +PVH |not yet |10/current |10/current |yes HVM |N/A |yes |yes |yes -PVHVM |N/A |yes |10/current |\todo probably +PVHVM |N/A |yes |10/current |yes """]] In PV (paravirtualized) mode, the guest OS does not attempt to access @@ -94,12 +94,12 @@ kernel stored in the domU's filesystem. This can be useful in VPS situations where the owner of the domU has no access to the dom0. - ## CPU Architecture Xen runs on x86_64 hardware (the NetBSD amd64 port). -There is a concept of Xen running on ARM, but there are no reports of this working with NetBSD. +There is a concept of Xen running on arm32 and aarch64, but there are +thus far no reports of this working with NetBSD. The dom0 system must be amd64. @@ -122,20 +122,25 @@ 4.18 |xenkernel418 |x86_64 |2026-11-16 |2025-05-16 | """]] -As of December 2023, 4.15 has been working well on NetBSD 9 through -current with both i386 and amd64 guests. - -4.18 works well, when the dom0 is NetBSD 10 and has had some testing -on NetBSD-current. It is not clear if 4.18 will run well or not on -NetBSD 9 as a dom0. Note that i386 PV guests are no longer directly -supported; see the "PVH shim" section below for the required -adjustment. - -The standard approach is thus blurred between 4.15 and 4.18. - -\todo Describe i386 and amd64 PVH and HVM guest status. - -See also the [Xen Security Advisory page](http://xenbits.xen.org/xsa/). +See also the +[Xen Support Matrix page](https://xenbits.xen.org/docs/unstable/support-matrix.html) +and the +[Xen Security Advisory page](http://xenbits.xen.org/xsa/). + +As of July 2024, both 4.15 and 4.18 generally work well on NetBSD 9 +through current with i386 and amd64 guests. The standard approach is +4.18. +However, there is a timekeeping issue on some systems with 4.18; see +"Timekeeping Woes" below. + +Note that with 4.18, i386 PV guests are no longer directly supported; +see the "Creating a NetBSD PV Shim domU" section below for the +required minor adjustment. + +As of July 2024, there are no efforts to package 4.19 (not yet +released), and there are hints that 4.20 (not even listed on the +support matrix page yet) might be packaged. Note that 4.18 is the +current stable release of Xen; pkgsrc is not behind. ## NetBSD versions @@ -148,16 +153,14 @@ NetBSD Xen has always supported PV, in both dom0 and domU. NetBSD 8 and later as a dom0 supports HVM mode in domUs. -Support for PVHVM and PVH is available in NetBSD 10; this is currently +Support for PVH and PVHVM is available in NetBSD 10; this is currently somewhat experimental, although PVHVM appears reasonably solid. NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP. Even if one added "options MULTIPROCESSOR" and configured multiple vcpus, the kernel is likely to crash because of drivers without -adequate locking. - -NetBSD 10 supports SMP in dom0, and XEN3_DOM0 includes "options -MULTIPROCESSOR". +adequate locking. NetBSD 10 supports SMP in dom0, and XEN3_DOM0 +includes "options MULTIPROCESSOR". NetBSD (since NetBSD 6), when run as a domU, can run SMP, using multiple CPUs if provided. The XEN3_DOMU kernel is built @@ -167,15 +170,14 @@ is still called XEN3, because the hypercall interface has not changed significantly and because renaming it would not be useful. +See also [NetBSD Xen daily test results](https://largo.lip6.fr/~bouyer/NetBSD-tests/xen/). + # Creating a NetBSD dom0 In order to install a NetBSD as a dom0, one first installs a normal NetBSD system, and then pivots the install to a dom0 install by changing the kernel and boot configuration. -NB: As of 2021-04, you must arrange to have the system use BIOS boot, -not EFI boot. - In 2018-05, trouble booting a dom0 was reported with 256M of RAM: with 512M it worked reliably. This does not make sense, but if you see "not ELF" after Xen boots, try increasing dom0 RAM. @@ -748,10 +750,6 @@ Xen 4.18. For them, performance seems similar to regular PV with older Xen. -There is 1 data point that it seems to work for amd64 PV guests, but -with abysmal performance (at least 100x slowdown). \todo Confirm -speed issue, file a PR, and explain. - Configure as for pv, but add type="pvh" @@ -762,6 +760,13 @@ from Xen 4.15 to 4.18, the only change needed for an i386 domU is the two lines above. +It seems that this use of pvh (for i386 guests) works ok even on +systems that lack VT-X/SVM. + +There is 1 data point that it seems to work for amd64 PV guests on a +system without VT-X/SVM, but with abysmal performance (at least 100x +slowdown). \todo Confirm speed issue, file a PR, and explain. + ## Creating a NetBSD PVH dom0 \todo This might or might not work in current. @@ -778,7 +783,7 @@ Use type='pvh'. Configure a GENERIC kernel instead of XEN3_DOMU. -Operation of i386 PVH guests is not reliable. +There is a PR about i386 PVH guests, but they work fine during daily tests. See [PR 57199](https://gnats.netbsd.org/57199). ## Creating a NetBSD HVM domU @@ -956,6 +961,8 @@ http://gnats.netbsd.org/58395 +This has so far only been reported at tornadovps, believed to be running 4.14.0.88.g1d1d1f53. + ## Timekeeping Woes As of 2024-07, there has been extensive recent discussion about
xen howto: prune old hvm example
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.246 retrieving revision 1.247 diff -u -r1.246 -r1.247 --- wikisrc/ports/xen/howto.mdwn 12 Jul 2024 00:10:24 -0000 1.246 +++ wikisrc/ports/xen/howto.mdwn 12 Jul 2024 11:35:09 -0000 1.247 @@ -786,19 +786,9 @@ Use a GENERIC kernel within the disk image. Use bootblocks, as if it were a real machine. -This config snippet was stolen from a port-xen post. It uses older -directives and is likely not appropriate for modern xen. Complaints -should be accompanied by a better example! - -[[!template id=programlisting text=""" -kernel = "/usr/pkg/lib/xen/boot/hvmloader" -builder='hvm' -device_model_version="qemu-xen-traditional" -boot='c' -"""]] - -This config snippet was also stolen from a port-xen post. This uses -current config, but may not work. +This config snippet was stolen from a port-xen post. It might not +quite work, as it was in the context of debugging issues apparently +from zvol usage. [[!template id=programlisting text=""" type = "hvm" @@ -807,10 +797,9 @@ vcpus = 2 vif = [ 'mac=00:01:02:ab:cd:ef, bridge=bridge0' ] disk = [ 'format=raw, vdev=hda, access=rw, -target=phy:/dev/zvol/dsk/tank/foo' ] + target=phy:/dev/zvol/dsk/tank/foo' ] """]] - ## Creating a NetBSD PVHVM domU Probably just like HVM, except ensure that GENERIC has PV drivers also.
xen howto: add another hvm example
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.245 retrieving revision 1.246 diff -u -r1.245 -r1.246 --- wikisrc/ports/xen/howto.mdwn 12 Jul 2024 00:05:37 -0000 1.245 +++ wikisrc/ports/xen/howto.mdwn 12 Jul 2024 00:10:24 -0000 1.246 @@ -797,6 +797,20 @@ boot='c' """]] +This config snippet was also stolen from a port-xen post. This uses +current config, but may not work. + +[[!template id=programlisting text=""" +type = "hvm" +name = "foo" +memory = 2048 +vcpus = 2 +vif = [ 'mac=00:01:02:ab:cd:ef, bridge=bridge0' ] +disk = [ 'format=raw, vdev=hda, access=rw, +target=phy:/dev/zvol/dsk/tank/foo' ] +"""]] + + ## Creating a NetBSD PVHVM domU Probably just like HVM, except ensure that GENERIC has PV drivers also.
xen howto: fix hvm example description
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.244 retrieving revision 1.245 diff -u -r1.244 -r1.245 --- wikisrc/ports/xen/howto.mdwn 11 Jul 2024 23:29:30 -0000 1.244 +++ wikisrc/ports/xen/howto.mdwn 12 Jul 2024 00:05:37 -0000 1.245 @@ -786,11 +786,9 @@ Use a GENERIC kernel within the disk image. Use bootblocks, as if it were a real machine. -This config snippet was stolen from a port-xen post. - -\todo Explain about builder vs type. - -\todo Confirm and fix text. +This config snippet was stolen from a port-xen post. It uses older +directives and is likely not appropriate for modern xen. Complaints +should be accompanied by a better example! [[!template id=programlisting text=""" kernel = "/usr/pkg/lib/xen/boot/hvmloader" @@ -803,7 +801,7 @@ Probably just like HVM, except ensure that GENERIC has PV drivers also. -\todo Explain if the type/builder= define causes disk/networking to +\todo Explain if declaring pvhvm vs hvm causes disk/networking to appear as PV instead of emulated. ## Creating a FreeBSD domU
rototill pvh and hvm instructions
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.243 retrieving revision 1.244 diff -u -r1.243 -r1.244 --- wikisrc/ports/xen/howto.mdwn 11 Jul 2024 23:01:59 -0000 1.243 +++ wikisrc/ports/xen/howto.mdwn 11 Jul 2024 23:29:30 -0000 1.244 @@ -726,9 +726,9 @@ One should also run `powerd` in a domU, but this should not need configuring. With powerd, the domain will run a controlled shutdown if `xl shutdown -R` or `xl shutdown -H` is used on the dom0, via -receiving a synthetic `power button pressed` signal. In 9 and -current, `powerd` is run by default under Xen kernels (or if ACPI is -present), and it can be added to rc.conf if not. +receiving a synthetic `power button pressed` signal. In NetBSD 9 and +later, `powerd` is enabled by default under Xen (or if ACPI is +present). It is not strictly necessary to have a kernel (as /netbsd) in the domU file system. However, various programs (e.g. netstat) will use that @@ -745,37 +745,66 @@ This is like a PV domU, but has a second copy of xen (shim) between dom0 and domU. Note that this is necessary for i386 PV guests with -Xen 4.18. It also works for amd64 PV guests, but there are no known -reasons to favor PV shim over normal PV. +Xen 4.18. For them, performance seems similar to regular PV with +older Xen. + +There is 1 data point that it seems to work for amd64 PV guests, but +with abysmal performance (at least 100x slowdown). \todo Confirm +speed issue, file a PR, and explain. Configure as for pv, but add type="pvh" pvshim=1 -The domU system itself is unchanged; it still uses a PV (XEN3_DOMU or XEN3PAE_DOMU) kernel, -and still sees the same devices. +The domU system itself is unchanged; it still uses a PV (XEN3_DOMU or +XEN3PAE_DOMU) kernel, and still sees the same devices. When upgrading +from Xen 4.15 to 4.18, the only change needed for an i386 domU is the +two lines above. + +## Creating a NetBSD PVH dom0 + +\todo This might or might not work in current. +\todo The following instructions are likely wrong. + +In boot.cfg, add dom0=pvh (dom0=pv is the default). Configure GENERIC +instead of XEN3_DOM0. ## Creating a NetBSD PVH domU +\todo Check/fix these instructions. + This is only supported for NetBSD 10 and up as the guest. -Use type='pvh'. Configure GENERIC instead of XEN3_DOMU. In boot.cfg, -add dom0=pvh. (dom0=pv is the default, which is why this expression -has not been previously discussed.) +Use type='pvh'. Configure a GENERIC kernel instead of XEN3_DOMU. Operation of i386 PVH guests is not reliable. See [PR 57199](https://gnats.netbsd.org/57199). ## Creating a NetBSD HVM domU -Use type='hvm', probably. Use a GENERIC kernel within the disk image. +Use a GENERIC kernel within the disk image. Use bootblocks, as if it +were a real machine. + +This config snippet was stolen from a port-xen post. + +\todo Explain about builder vs type. + \todo Confirm and fix text. +[[!template id=programlisting text=""" +kernel = "/usr/pkg/lib/xen/boot/hvmloader" +builder='hvm' +device_model_version="qemu-xen-traditional" +boot='c' +"""]] + ## Creating a NetBSD PVHVM domU -Use type='pvhvm', guessing wildly. Use a GENERIC kernel within the disk image. -\todo Confirm and fix text. +Probably just like HVM, except ensure that GENERIC has PV drivers also. + +\todo Explain if the type/builder= define causes disk/networking to +appear as PV instead of emulated. ## Creating a FreeBSD domU @@ -788,8 +817,7 @@ Creating unprivileged Linux domains isn't much different from unprivileged NetBSD domains, but there are some details to know. -NOTE: This is old text, and aparently Linux no longer supports PV. -Instead, use pvh. +\todo Confirm/rototill. First, the second parameter passed to the disk declaration (the '0x1' in the example below)
xen howto: mention pvh for amd64
and say there is no known reason to do it
and say there is no known reason to do it
Members: ports/xen/howto.mdwn:1.242->1.243 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.242 retrieving revision 1.243 diff -u -r1.242 -r1.243 --- wikisrc/ports/xen/howto.mdwn 11 Jul 2024 22:57:54 -0000 1.242 +++ wikisrc/ports/xen/howto.mdwn 11 Jul 2024 23:01:59 -0000 1.243 @@ -745,7 +745,8 @@ This is like a PV domU, but has a second copy of xen (shim) between dom0 and domU. Note that this is necessary for i386 PV guests with -Xen 4.18. +Xen 4.18. It also works for amd64 PV guests, but there are no known +reasons to favor PV shim over normal PV. Configure as for pv, but add
xen howto: declare that pvh doesn't need hardware support
based on booting on an old CPU without VT-X.
based on booting on an old CPU without VT-X.
Members: ports/xen/howto.mdwn:1.241->1.242 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.241 retrieving revision 1.242 diff -u -r1.241 -r1.242 --- wikisrc/ports/xen/howto.mdwn 11 Jul 2024 19:37:36 -0000 1.241 +++ wikisrc/ports/xen/howto.mdwn 11 Jul 2024 22:57:54 -0000 1.242 @@ -55,9 +55,9 @@ [[!table data=""" Style of guest |dom0 can be? |dom0 can support? |domU can be? |needs VT-X/SVM PV |yes |yes |yes |no +PVH |not yet |10/current |10/current |no HVM |N/A |yes |yes |yes PVHVM |N/A |yes |10/current |\todo probably -PVH |not yet |10/current |10/current |\todo probably """]] In PV (paravirtualized) mode, the guest OS does not attempt to access @@ -69,6 +69,17 @@ on Intel CPUs and SVM on AMD CPUs to assist with the processor emulation. +PVH is substantially more efficient than PV because it uses hardware +assisted virtualization. +There have been two PVH modes: original PVH and PVHv2. Original PVH +was based on PV mode and is no longer relevant at all. Therefore +PVHv2 is written as PVH, here and elsewhere. PVH is basically +lightweight HVM with PV drivers. A critical feature of it is that +qemu is not needed; the hypervisor can do the emulation that is +required. Thus, a dom0 can be PVH. The source code uses PVH and +config files use pvh -- these refer to PVHv2. See +[PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu). + In HVM (Hardware Virtual Machine) mode, guest operating systems with no knowledge of or accomodation for Xen can be run. The dom0 runs qemu to emulate hardware other than the processor. It is therefore @@ -83,16 +94,6 @@ kernel stored in the domU's filesystem. This can be useful in VPS situations where the owner of the domU has no access to the dom0. -PVH is substantially more efficient than PV because it uses hardware -assisted virtualization. -There have been two PVH modes: original PVH and PVHv2. Original PVH -was based on PV mode and is no longer relevant at all. Therefore -PVHv2 is written as PVH, here and elsewhere. PVH is basically -lightweight HVM with PV drivers. A critical feature of it is that -qemu is not needed; the hypervisor can do the emulation that is -required. Thus, a dom0 can be PVH. The source code uses PVH and -config files use pvh -- these refer to PVHv2. See -[PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu). ## CPU Architecture
xen howto: request timekeeping woes PR
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.240 retrieving revision 1.241 diff -u -r1.240 -r1.241 --- wikisrc/ports/xen/howto.mdwn 11 Jul 2024 19:35:16 -0000 1.240 +++ wikisrc/ports/xen/howto.mdwn 11 Jul 2024 19:37:36 -0000 1.241 @@ -331,7 +331,7 @@ to force Xen to use serial only, and for NetBSD implicitly to use xencons(4). -### Early NetBSD 90 +### Early NetBSD 9 When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen 4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line. @@ -925,6 +925,14 @@ http://gnats.netbsd.org/58395 +## Timekeeping Woes + +As of 2024-07, there has been extensive recent discussion about +timekeeping problems on dom0 and domU NetBSD systems, perhaps worse +with 4.18. + +\todo Add link to crisp PR summarizing what we know, after someone(tm) files one. + ## Configuration of non-NetBSD dom0s to run NetBSD domUs Apparently one must have "pv-linear-pt=true" in the dom0 circumstances
xen howto: misc minor edits
- typos
- more netbsd 8 and netbsd 5 pruning
- map current to "10 and current"
- add link to PR about grant table hypervisor bug as seen on
tornadovps
- typos
- more netbsd 8 and netbsd 5 pruning
- map current to "10 and current"
- add link to PR about grant table hypervisor bug as seen on
tornadovps
Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.239 retrieving revision 1.240 diff -u -r1.239 -r1.240 --- wikisrc/ports/xen/howto.mdwn 11 Jul 2024 19:09:28 -0000 1.239 +++ wikisrc/ports/xen/howto.mdwn 11 Jul 2024 19:35:16 -0000 1.240 @@ -118,7 +118,7 @@ [[!table data=""" Xen Version |Package Name |Xen CPU Support |Security EOL |Feature EOL | 4.15 |xenkernel415 |x86_64 |2024-04-08 |2022-10-08 | -4.18 |xenkernel415 |x86_64 |2026-11-16 |2025-05-16 | +4.18 |xenkernel418 |x86_64 |2026-11-16 |2025-05-16 | """]] As of December 2023, 4.15 has been working well on NetBSD 9 through @@ -331,14 +331,11 @@ to force Xen to use serial only, and for NetBSD implicitly to use xencons(4). -### Older NetBSD kernels +### Early NetBSD 90 -When the dom0 kernel is NetBSD 8 and earlier, or NetBSD 9 before -2021-04-17 (9.3 is ok), Xen 4.15 and later require -"dom0=msr-relaxed=1" on the boof.cfg line. (See -/src/sys/arch/x86/x86/pmap.c revision 1.410.) - -(NetBSD 5 domUs appear to be troubled with recent Xen and NetBSD dom0.) +When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen +4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line. +(See /src/sys/arch/x86/x86/pmap.c revision 1.410.) ### Tuning @@ -420,8 +417,8 @@ One is that through NetBSD 9 the module ABI is different because some of the #defines change, so there are separate sets of modules in /stand. (Further, zfs in Xen is troubled because of differing -MAXPHYS; see the zfs howto for more.) In NetBSD-current, there is -only one set of modules. +MAXPHYS; see the zfs howto for more.) In NetBSD 10 and later, there +is only one set of modules. The other difference is that XEN3_DOM0 does not have exactly the same options as GENERIC. While this is roughly agreed to be in large part @@ -437,7 +434,7 @@ Note the previous advice to maintain a working and tested boot config into GENERIC without Xen. -Updating Xen in a dom0 consists of updating the xnekernel and xentools +Updating Xen in a dom0 consists of updating the xenkernel and xentools packages, along with copying the xen.gz into place, and of course rebooting. @@ -456,7 +453,7 @@ likelihood of trouble is increased. Therefore, 'make replace' of xentools on a dom0 with running domUs is not recommended. A shutdown on all domUs before replacing xentools is likely sufficient. A safer -appraoch is to boot into GENERIC to replace the packages, as then no +approach is to boot into GENERIC to replace the packages, as then no Xen code will be running. Single user is another option. ## Updating NetBSD in a dom0 @@ -746,7 +743,8 @@ ## Creating a NetBSD PV Shim domU This is like a PV domU, but has a second copy of xen (shim) between -dom0 and domU. +dom0 and domU. Note that this is necessary for i386 PV guests with +Xen 4.18. Configure as for pv, but add @@ -767,9 +765,6 @@ Operation of i386 PVH guests is not reliable. See [PR 57199](https://gnats.netbsd.org/57199). -\todo Verify if one can have netbsd-10 PVH domU on a 9 dom0, and -adjust the dom0 pvh text. - ## Creating a NetBSD HVM domU Use type='hvm', probably. Use a GENERIC kernel within the disk image. @@ -921,6 +916,15 @@ https://wiki.xenproject.org/wiki/Grant_Table +## Grant Table Hypervisor Bug + +Some Xen versions return bad values for the 33rd grant table entry. +This affects NetBSD 10 always, because it pre-acquires grant table +entries. It affects earlier NetBSD and Linux if the 33rd is +requested. + +http://gnats.netbsd.org/58395 + ## Configuration of non-NetBSD dom0s to run NetBSD domUs Apparently one must have "pv-linear-pt=true" in the dom0 circumstances
xen howto: gc NetBSD 8
- update PVH slightly
- dedup VT-X/SVM about PVH/HVM
- reorder guest styles to match history
- drop comment about xm
- update PVH slightly
- dedup VT-X/SVM about PVH/HVM
- reorder guest styles to match history
- drop comment about xm
Members: ports/xen/howto.mdwn:1.238->1.239 Index: wikisrc/ports/xen/howto.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v retrieving revision 1.238 retrieving revision 1.239 diff -u -r1.238 -r1.239 --- wikisrc/ports/xen/howto.mdwn 13 Jan 2024 20:13:55 -0000 1.238 +++ wikisrc/ports/xen/howto.mdwn 11 Jul 2024 19:09:28 -0000 1.239 @@ -35,6 +35,10 @@ and how to deal with having a domU in a Xen environment run by someone else and/or not running NetBSD. +At system boot, the dom0 kernel is loaded as a module with Xen as the +kernel. The dom0 can start one or more domUs. (Booting is explained +in detail in the dom0 section.) + There are many choices one can make; the HOWTO recommends the standard approach and limits discussion of alternatives in many cases. @@ -49,11 +53,11 @@ if NetBSD as a domU can support that style. [[!table data=""" -Style of guest |dom0 can be? |dom0 can support? |domU can be? -PV |yes |yes |yes -HVM |N/A |yes |yes -PVHVM |N/A |yes |10/current -PVH |not yet |10/current |10/current +Style of guest |dom0 can be? |dom0 can support? |domU can be? |needs VT-X/SVM +PV |yes |yes |yes |no +HVM |N/A |yes |yes |yes +PVHVM |N/A |yes |10/current |\todo probably +PVH |not yet |10/current |10/current |\todo probably """]] In PV (paravirtualized) mode, the guest OS does not attempt to access @@ -61,25 +65,16 @@ guests must be specifically coded for Xen. See [PV](https://wiki.xen.org/wiki/Paravirtualization_(PV\)). -PVH is substantially more efficient than PV because it uses hardware -assisted virtualization. -There have been two PVH modes: original PVH and PVHv2. Original PVH -was based on PV mode and is no longer relevant at all. Therefore -PVHv2 is written as PVH, here and elsewhere. PVH is basically -lightweight HVM with PV drivers. A critical feature of it is that -qemu is not needed; the hypervisor can do the emulation that is -required. Thus, a dom0 can be PVH. The source code uses PVH and -config files use pvh -- these refer to PVHv2. See -[PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu). +For various PVH/HVM modes, hardware support is required, such as VT-x +on Intel CPUs and SVM on AMD CPUs to assist with the processor +emulation. In HVM (Hardware Virtual Machine) mode, guest operating systems with -no knowledge of or accomodation for Xen can be run. However, hardware -support is required, such as VT-x on Intel CPUs and SVM on AMD CPUs to -assist with the processor emulation. The dom0 runs qemu to emulate -hardware other than the processor. It is therefore non-sensical to -have an HVM dom0, because there is no underlying system to provide -emulation. HVM can be useful to work around bugs even if some other -mode could be used. +no knowledge of or accomodation for Xen can be run. The dom0 runs +qemu to emulate hardware other than the processor. It is therefore +non-sensical to have an HVM dom0, because there is no underlying +system to provide emulation. HVM can be useful to work around bugs +even if some other mode could be used. In PVHVM mode, the guest runs as HVM, but additionally uses PV drivers for efficiency. Therefore it is non-sensical for to have a PVHVM @@ -88,9 +83,16 @@ kernel stored in the domU's filesystem. This can be useful in VPS situations where the owner of the domU has no access to the dom0. -At system boot, the dom0 kernel is loaded as a module with Xen as the -kernel. The dom0 can start one or more domUs. (Booting is explained -in detail in the dom0 section.) +PVH is substantially more efficient than PV because it uses hardware +assisted virtualization. +There have been two PVH modes: original PVH and PVHv2. Original PVH +was based on PV mode and is no longer relevant at all. Therefore +PVHv2 is written as PVH, here and elsewhere. PVH is basically +lightweight HVM with PV drivers. A critical feature of it is that +qemu is not needed; the hypervisor can do the emulation that is +required. Thus, a dom0 can be PVH. The source code uses PVH and +config files use pvh -- these refer to PVHv2. See +[PVH(v2)](https://wiki.xenproject.org/wiki/PVH_(v2\)_Domu). ## CPU Architecture @@ -119,39 +121,34 @@ 4.18 |xenkernel415 |x86_64 |2026-11-16 |2025-05-16 | """]] -As of December 2023, 4.15 has been working well on NetBSD 8 through -current with both i386 and amd64 guests and is the standard approach. +As of December 2023, 4.15 has been working well on NetBSD 9 through +current with both i386 and amd64 guests. 4.18 works well, when the dom0 is NetBSD 10 and has had some testing -on NetBSD-current. It runs a NetBSD 9 PV domU well. Note that i386 -PV guests are no longer supported; see the "PVH shim" section below -for the required adjustment. +on NetBSD-current. It is not clear if 4.18 will run well or not on +NetBSD 9 as a dom0. Note that i386 PV guests are no longer directly +supported; see the "PVH shim" section below for the required +adjustment. -\todo Describe i386 and amd64 PVH and HVM guest status. +The standard approach is thus blurred between 4.15 and 4.18. -It is not clear if 4.18 will run well or not on NetBSD 9 as a dom0. -It is likely to be troubled on NetBSD 8 as a dom0 (which is expected -to be no longer relevant very soon). +\todo Describe i386 and amd64 PVH and HVM guest status. See also the [Xen Security Advisory page](http://xenbits.xen.org/xsa/). -Extremely old Xen had a python-based management tool called xm; this -has long since been replaced by xl and is not discussed further. - ## NetBSD versions +This HOWTO addresses NetBSD 9 and later; information about EOL NetBSD +versions has been pruned. + Xen has been supported in NetBSD for a long time, at least since 2005. Initially Xen was PV only. -NetBSD Xen has always supported PV, in both dom0 and domU -- this used -to be the only way. NetBSD 8 and later as a dom0 supports HVM mode in domUs. +NetBSD Xen has always supported PV, in both dom0 and domU. +NetBSD 8 and later as a dom0 supports HVM mode in domUs. Support for PVHVM and PVH is available in NetBSD 10; this is currently -somewhat experimental, although PVHVM appears reasonably solid. Note -that these require newer CPU features than just PV, but as of 2023 -most hardware that one intends to actually use with Xen is likely to -have support. \todo Describe the CPU flags or provide a link to -upstream. +somewhat experimental, although PVHVM appears reasonably solid. NetBSD up to and including NetBSD 9 as a dom0 cannot safely run SMP. Even if one added "options MULTIPROCESSOR" and configured multiple
Fix two typos.
Reported by Ray Phillips in PR 58415.
Reported by Ray Phillips in PR 58415.
Members: amazon_ec2/first_steps.mdwn:1.4->1.5 Index: wikisrc/amazon_ec2/first_steps.mdwn =================================================================== RCS file: /cvsroot/wikisrc/amazon_ec2/first_steps.mdwn,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- wikisrc/amazon_ec2/first_steps.mdwn 8 Oct 2019 11:03:51 -0000 1.4 +++ wikisrc/amazon_ec2/first_steps.mdwn 11 Jul 2024 10:29:44 -0000 1.5 @@ -14,18 +14,18 @@ These can be created through the [Security Credentials](https://aws-portal.amazon.com/gp/aws/developer/account/index.html?ie=UTF8&action=access-key) page (also accessible from the [Account](http://aws.amazon.com/account/) page): 1. create the access key. Keep a secured copy of the ID and its associated secret value. These will be used by various scripts later on to perform certain EC2 actions. -1. note down your account number (different from your access key ID!). This identifier can usually be obtained in the right top part of the page; it is a serie of numbers, separated with dashes: XXXX-XXXX-XXXX. +1. note down your account number (different from your access key ID!). This identifier can usually be obtained in the right top part of the page; it is a series of numbers, separated with dashes: XXXX-XXXX-XXXX. 1. create, or upload, a X.509 certificate, in PEM format. Keep the private key in a safe place. 1. lastly, generate Amazon EC2 key pairs that will be used for SSH access. This step will be performed through the [Amazon Management Console](https://console.aws.amazon.com/ec2/home). Note down the SSH Key Pair Name you chose. ### Keep your credentials! -The different credentials created above will be used in various places of EC2, and by a myriad of commands. You are advised to keep them easily accessible, while still reasonably secure regarding their access. Most EC2 tools expect them to be find through a set of environment variables. +The different credentials created above will be used in various places of EC2, and by a myriad of commands. You are advised to keep them easily accessible, while still reasonably secure regarding their access. Most EC2 tools expect them to be found through a set of environment variables. For convenience, you could store them under a *.ec2* directory inside your *$HOME*: [[!template id=programlisting text=""" -$ ls .ec2/ +$ ls .ec2/ cert-SOMERANDOMKEY.pem # the X.509 certificate id_rsa.ec2 # private RSA SSH key id_rsa.ec2.pub # public RSA SSH key
Add direct kernel boot with hardware accelerated virtualization on a Linux host
Index: wikisrc/ports/evbarm/qemu_arm.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/evbarm/qemu_arm.mdwn,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- wikisrc/ports/evbarm/qemu_arm.mdwn 14 Mar 2022 07:22:29 -0000 1.11 +++ wikisrc/ports/evbarm/qemu_arm.mdwn 25 Jun 2024 11:58:47 -0000 1.12 @@ -34,6 +34,17 @@ -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \ -bios QEMU_EFI.fd -nographic +# Booting the system (arm64) directly into the kernel with hardware accelerated virtualization on a Linux host + + $ qemu-system-aarch64 -M virt,accel=kvm -cpu host -m 256 \ + -drive if=none,file=arm64.img,id=hd0 -device virtio-blk-device,drive=hd0 \ + -device virtio-rng-pci -kernel netbsd-GENERIC64.img -append "root=NAME=netbsd-root" \ + -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \ + -display none -serial stdio + +* As of today, a regular ELF kernel won't boot, use `netbsd-GENERIC64.img` (`.img` suffix) +* `-device virtio-rng-pci` is needed for the boot not to hang on `Waiting for entropy...` + # Booting the system (armv7) $ qemu-system-arm -M virt -cpu cortex-a15 -smp 4 -m 2g \
acorn32 last release is also 10.0
Index: wikisrc/ports.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports.mdwn,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- wikisrc/ports.mdwn 2 Jun 2024 23:26:56 -0000 1.31 +++ wikisrc/ports.mdwn 23 Jun 2024 22:41:14 -0000 1.32 @@ -45,7 +45,7 @@ [[!table data=""" Port |CPU |Machines |Latest Release -[[acorn32]] |arm |Acorn RiscPC/A7000/NC and compatibles |[8.1](http://www.NetBSD.org/releases/formal-8/) +[[acorn32]] |arm |Acorn RiscPC/A7000/NC and compatibles |[10.0](http://www.NetBSD.org/releases/formal-10/) [[algor]] |mips |Algorithmics MIPS evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) [[alpha]] |alpha |Digital Alpha (64-bit) |[10.0](http://www.NetBSD.org/releases/formal-10/) [[amiga]] |m68k |Commodore Amiga, MacroSystem DraCo |[10.0](http://www.NetBSD.org/releases/formal-10/)
ports/i386: Note math coprocessor is mandatory.
It has been _formally_ mandatory since NetBSD 7 when dsl@ made the
`npx' option a mandatory component in i386 kernels.
But it has been _practically_ mandatory since support for the
original i386 was removed some years prior -- not sure exactly when.
It has been _formally_ mandatory since NetBSD 7 when dsl@ made the
`npx' option a mandatory component in i386 kernels.
But it has been _practically_ mandatory since support for the
original i386 was removed some years prior -- not sure exactly when.
But it has been _practically_ mandatory since support for the original i386 was removed some years prior -- not sure exactly when. Members: ports/i386.mdwn:1.27->1.28 Index: wikisrc/ports/i386.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/i386.mdwn,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- wikisrc/ports/i386.mdwn 30 Mar 2024 19:27:00 -0000 1.27 +++ wikisrc/ports/i386.mdwn 19 Jun 2024 19:06:36 -0000 1.28 @@ -9,7 +9,7 @@ changes_future="11.0" thumbnail="//www.netbsd.org/images/ports/i386/header.gif" about=""" -NetBSD/i386 is the port of NetBSD to generic machines ("PC clones") with 32-bit x86-family processors. It runs on PCI-Express, PCI, and CardBus systems, as well as older hardware with PCMCIA, VL-bus, EISA, MCA, and ISA (AT-bus) interfaces, with or without math coprocessors. +NetBSD/i386 is the port of NetBSD to generic machines ("PC clones") with 32-bit x86-family processors. It runs on PCI-Express, PCI, and CardBus systems, as well as older hardware with PCMCIA, VL-bus, EISA, MCA, and ISA (AT-bus) interfaces, with x87 math coprocessors. Any i486 or better CPU should work - genuine Intel or a compatible such as Cyrix, AMD, or NexGen.
Index: wikisrc/gitsofar.mdwn =================================================================== RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- wikisrc/gitsofar.mdwn 4 Jun 2024 11:57:06 -0000 1.14 +++ wikisrc/gitsofar.mdwn 4 Jun 2024 12:03:59 -0000 1.15 @@ -70,6 +70,9 @@ [In 2019, FreeBSD core team has appointed a WG to explore transition from Subversion to Git.](https://www.freebsd.org/news/status/report-2019-04-2019-06.html#FreeBSD-Core-Team) +[FreeBSD has moved to git](http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html) +[More FreeBSD git docs](https://docs.freebsd.org/en/articles/committers-guide/#git-primer) + ### how to install git should fit into NetBSD src/tools easily. I have not personally tested @@ -107,7 +110,7 @@ ### how to convert -https://github.com/netbsd/ +[NetBSD on github](https://github.com/netbsd/) This has been working for years. @@ -146,7 +149,7 @@ ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos. -[[RCS $Id: gitsofar.mdwn,v 1.14 2024/06/04 11:57:06 wiki Exp $ and more|https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion]] addresses RDS Id expansion specifically but consider not doing this in a 1:1 way in the future. These problems are likely solved by DragonflyBSD or FreeBSD already. +[RCS Id and more)[https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion] addresses RDS Id expansion specifically but consider not doing this in a 1:1 way in the future. These problems are likely solved by DragonflyBSD or FreeBSD already. Very few systems should be relying on CVS _internals_ and should, generally, be able to replace a `cvs checkout` with `git clone` and that will be the extent of it. It's not a major concern but can't be done until decisions are made.
Index: wikisrc/gitsofar.mdwn =================================================================== RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- wikisrc/gitsofar.mdwn 4 Jun 2024 11:37:55 -0000 1.13 +++ wikisrc/gitsofar.mdwn 4 Jun 2024 11:57:06 -0000 1.14 @@ -142,9 +142,13 @@ 3. cvs is turned off 4. git is made available over ssh -### future considerations & misc +### future considerations, internal tooling, & misc -ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos +ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos. + +[[RCS $Id: gitsofar.mdwn,v 1.14 2024/06/04 11:57:06 wiki Exp $ and more|https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion]] addresses RDS Id expansion specifically but consider not doing this in a 1:1 way in the future. These problems are likely solved by DragonflyBSD or FreeBSD already. + +Very few systems should be relying on CVS _internals_ and should, generally, be able to replace a `cvs checkout` with `git clone` and that will be the extent of it. It's not a major concern but can't be done until decisions are made. ### Addressing specific workflow concerns
Index: wikisrc/gitsofar.mdwn =================================================================== RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- wikisrc/gitsofar.mdwn 4 Jun 2024 11:36:04 -0000 1.12 +++ wikisrc/gitsofar.mdwn 4 Jun 2024 11:37:55 -0000 1.13 @@ -148,7 +148,7 @@ ### Addressing specific workflow concerns -The ability for CVS to checkout subdirectories appears to be a frequently requested feature. Git provides a way to do this using [sparse checkouts|https://git-scm.com/docs/git-sparse-checkout]. Let's demonstrate another neat feature [worktrees|https://git-scm.com/docs/git-worktree] so we can have multiple parallel branches checked out of `/bin/sh` +The ability for CVS to checkout subdirectories appears to be a frequently requested feature. Git provides a way to do this using [[sparse checkouts|https://git-scm.com/docs/git-sparse-checkout]]. Let's demonstrate another neat feature [[worktrees|https://git-scm.com/docs/git-worktree]] so we can have multiple parallel branches checked out of `/bin/sh` doing parallel development of a specific tool efficiently. Repeat this into as many worktrees as you want.
Index: wikisrc/gitsofar.mdwn =================================================================== RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- wikisrc/gitsofar.mdwn 4 Jun 2024 01:06:44 -0000 1.11 +++ wikisrc/gitsofar.mdwn 4 Jun 2024 11:36:04 -0000 1.12 @@ -101,6 +101,10 @@ Try to references named branches/tags instead of sha-1's Also using the dates for commits instead of commit id's +The only rules I know about git commit messages are that the first line is treated specially insomuch that it is shown in `git log --oneline` output. + +Special commit messages you might have seen around "Closes CORE-1234" etc are commands being sent to commit hooks to interact with other systems (like bug trackers). + ### how to convert https://github.com/netbsd/ @@ -138,8 +142,47 @@ 3. cvs is turned off 4. git is made available over ssh -### future considerations +### future considerations & misc ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos +### Addressing specific workflow concerns + +The ability for CVS to checkout subdirectories appears to be a frequently requested feature. Git provides a way to do this using [sparse checkouts|https://git-scm.com/docs/git-sparse-checkout]. Let's demonstrate another neat feature [worktrees|https://git-scm.com/docs/git-worktree] so we can have multiple parallel branches checked out of `/bin/sh` + +doing parallel development of a specific tool efficiently. Repeat this into as many worktrees as you want. + + +``` +cd netbsd.git #my clone + +#make a new worktree and branch named new2 +git worktree add -b new2 --no-checkout ../new2 +cd ../new2 #only contains a .git/ dir + +#--no-cone avoids grabbing top-level files +git sparse-checkout set --no-cone bin/sh + +#check on things +git sparse-checkout list +#output +# bin/sh + +#get the files +git checkout new2 + +#did it work? +find ./ -type d +./ +./bin +./bin/sh +./bin/sh/funcs +./bin/sh/USD.doc +./bin/sh/bltin + +git status +On branch new3 +You are in a sparse checkout with 1% of tracked files present. +nothing to commit, working tree clean +```
Index: wikisrc/gitsofar.mdwn =================================================================== RCS file: /cvsroot/wikisrc/gitsofar.mdwn,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- wikisrc/gitsofar.mdwn 3 Sep 2019 01:16:05 -0000 1.10 +++ wikisrc/gitsofar.mdwn 4 Jun 2024 01:06:44 -0000 1.11 @@ -48,13 +48,15 @@ See above for CVS server provided if ongoing conversion is really desired. -### existing cvs dependencies +### existing cvs dependencies & server setup is there a list of these? build systems? -The entire build infrastructure of NetBSD should (even without giti) change into a "jobs"-oriented workflow instead of a "server"-oriented workflow. +The entire build infrastructure of NetBSD should (even without git) change into a "jobs"-oriented workflow instead of a "server"-oriented workflow. Very recent (summer 2017) events have shown that the ability to move things around is very important. +ivanova (cvs.netbsd.org) will become git.netbsd.org already for pkgsrc. Our restricted shell has a hook for git* commands to be passed to git-shell. + ### How should NetBSD be setup @@ -88,6 +90,9 @@ A non-developer could also post a pull request to github or host his git repo for a friendly developer to add as an origin and pull his branch. +Pull Requests using mailing lists https://patchwork.readthedocs.io/en/latest/ + + (git origin add future-developer http://example.com/~greatguy/src.git) @@ -100,6 +105,8 @@ https://github.com/netbsd/ +This has been working for years. + ### No lock-in I am unable to anticipate the next generation of SCM. @@ -131,3 +138,8 @@ 3. cvs is turned off 4. git is made available over ssh +### future considerations + +ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos + +
link to 10.0 points to formal-9, reported by vulp on activitypub
Index: wikisrc/ports.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports.mdwn,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- wikisrc/ports.mdwn 30 Mar 2024 19:26:59 -0000 1.30 +++ wikisrc/ports.mdwn 2 Jun 2024 23:26:56 -0000 1.31 @@ -1,5 +1,5 @@ [[!meta title="Platforms supported by NetBSD"]] -NetBSD calls a supported architecture a 'port'. Most ports run on generic hardware and emulators, although some [commercial hardware](http://www.netbsd.org/gallery/hardware.html) also exists. The NetBSD Ports History page details the inclusion date for each port. +NetBSD calls a supported architecture a 'port'. Most ports run on generic hardware and emulators, although some [commercial hardware](http://www.NetBSD.org/gallery/hardware.html) also exists. The NetBSD Ports History page details the inclusion date for each port. Ports are classified into three 'tiers' based on the current importance of the architecture and the level of community activity. Summarizing, the tiers can be viewed to represent ports that NetBSD will support, ports that NetBSD does its best to support, and ports which may be desupported soon. The tier for each port may change over time and is decided by <core@NetBSD.org> based on input from users and developers. @@ -20,15 +20,15 @@ [[!table data=""" Port |CPU |Machines |Latest Release -[[aarch64]] |aarch64 |64-bit ARM CPUs |[10.0](http://www.netbsd.org/releases/formal-9/) -[[amd64]] |x86_64 |64-bit x86-family machines with AMD and Intel CPUs |[10.0](http://www.netbsd.org/releases/formal-9/) -[[evbarm]] |arm |ARM evaluation boards |[10.0](http://www.netbsd.org/releases/formal-9/) -[[evbmips]] |mips |MIPS-based evaluation boards |[10.0](http://www.netbsd.org/releases/formal-9/) -[[evbppc]] |powerpc |PowerPC-based evaluation boards |[10.0](http://www.netbsd.org/releases/formal-9/) -[[hpcarm]] |arm |StrongARM based Windows CE PDA machines |[10.0](http://www.netbsd.org/releases/formal-9/) -[[i386]] |i386 |32-bit x86-family generic machines ("PC clones") |[10.0](http://www.netbsd.org/releases/formal-9/) -[[sparc64]] |sparc |Sun UltraSPARC (64-bit) |[10.0](http://www.netbsd.org/releases/formal-9/) -[[xen]] |i386, x86_64 |Xen Virtual Machine Monitor |[10.0](http://www.netbsd.org/releases/formal-9/) +[[aarch64]] |aarch64 |64-bit ARM CPUs |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[amd64]] |x86_64 |64-bit x86-family machines with AMD and Intel CPUs |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[evbarm]] |arm |ARM evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[evbmips]] |mips |MIPS-based evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[evbppc]] |powerpc |PowerPC-based evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[hpcarm]] |arm |StrongARM based Windows CE PDA machines |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[i386]] |i386 |32-bit x86-family generic machines ("PC clones") |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[sparc64]] |sparc |Sun UltraSPARC (64-bit) |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[xen]] |i386, x86_64 |Xen Virtual Machine Monitor |[10.0](http://www.NetBSD.org/releases/formal-10/) """]] @@ -45,56 +45,56 @@ [[!table data=""" Port |CPU |Machines |Latest Release -[[acorn32]] |arm |Acorn RiscPC/A7000/NC and compatibles |[8.1](http://www.netbsd.org/releases/formal-8/) -[[algor]] |mips |Algorithmics MIPS evaluation boards |[10.0](http://www.netbsd.org/releases/formal-9/) -[[alpha]] |alpha |Digital Alpha (64-bit) |[10.0](http://www.netbsd.org/releases/formal-9/) -[[amiga]] |m68k |Commodore Amiga, MacroSystem DraCo |[10.0](http://www.netbsd.org/releases/formal-9/) -[[amigappc]] |powerpc |PowerPC-based Amiga boards |[10.0](http://www.netbsd.org/releases/formal-9/) -[[arc]] |mips |Machines following the Advanced RISC Computing spec |[10.0](http://www.netbsd.org/releases/formal-9/) -[[atari]] |m68k |Atari TT030, Falcon, Hades |[10.0](http://www.netbsd.org/releases/formal-9/) -[[bebox]] |powerpc |Be Inc's BeBox |[10.0](http://www.netbsd.org/releases/formal-9/) -[[cats]] |arm |Chalice Technology's Strong Arm evaluation board |[10.0](http://www.netbsd.org/releases/formal-9/) -[[cesfic]] |m68k |CES's FIC8234 VME processor board |[10.0](http://www.netbsd.org/releases/formal-9/) -[[cobalt]] |mips |Cobalt Networks' Microservers |[10.0](http://www.netbsd.org/releases/formal-9/) -[[dreamcast]] |[[sh3]] |Sega Dreamcast game console |[10.0](http://www.netbsd.org/releases/formal-9/) -[[epoc32]] |arm |32bit PSION EPOC PDA |[10.0](http://www.netbsd.org/releases/formal-9/) -[[emips]] |mips |Machines based on "Extensible MIPS" |[10.0](http://www.netbsd.org/releases/formal-9/) -[[evbsh3]] |[[sh3]] |Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs |[10.0](http://www.netbsd.org/releases/formal-9/) -[[ews4800mips]] |mips |NEC's MIPS based EWS4800 workstations |[10.0](http://www.netbsd.org/releases/formal-9/) -[[hp300]] |m68k |Hewlett-Packard 9000/300 and 400 series |[10.0](http://www.netbsd.org/releases/formal-9/) -[[hppa]] |hppa |Hewlett-Packard 9000/700 series |[10.0](http://www.netbsd.org/releases/formal-9/) -[[hpcmips]] |mips |MIPS based Windows CE PDA machines |[10.0](http://www.netbsd.org/releases/formal-9/) -[[hpcsh]] |[[sh3]] |Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines |[10.0](http://www.netbsd.org/releases/formal-9/) +[[acorn32]] |arm |Acorn RiscPC/A7000/NC and compatibles |[8.1](http://www.NetBSD.org/releases/formal-8/) +[[algor]] |mips |Algorithmics MIPS evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[alpha]] |alpha |Digital Alpha (64-bit) |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[amiga]] |m68k |Commodore Amiga, MacroSystem DraCo |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[amigappc]] |powerpc |PowerPC-based Amiga boards |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[arc]] |mips |Machines following the Advanced RISC Computing spec |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[atari]] |m68k |Atari TT030, Falcon, Hades |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[bebox]] |powerpc |Be Inc's BeBox |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[cats]] |arm |Chalice Technology's Strong Arm evaluation board |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[cesfic]] |m68k |CES's FIC8234 VME processor board |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[cobalt]] |mips |Cobalt Networks' Microservers |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[dreamcast]] |[[sh3]] |Sega Dreamcast game console |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[epoc32]] |arm |32bit PSION EPOC PDA |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[emips]] |mips |Machines based on "Extensible MIPS" |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[evbsh3]] |[[sh3]] |Evaluation boards with Renesas (Hitachi) Super-H SH3 and SH4 CPUs |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[ews4800mips]] |mips |NEC's MIPS based EWS4800 workstations |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[hp300]] |m68k |Hewlett-Packard 9000/300 and 400 series |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[hppa]] |hppa |Hewlett-Packard 9000/700 series |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[hpcmips]] |mips |MIPS based Windows CE PDA machines |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[hpcsh]] |[[sh3]] |Renesas (Hitachi) SH3 and SH4 based Windows CE PDA machines |[10.0](http://www.NetBSD.org/releases/formal-10/) [[ia64]] |itanium |Itanium family of processors |none -[[ibmnws]] |powerpc |IBM Network Station Series 1000 |[10.0](http://www.netbsd.org/releases/formal-9/) -[[iyonix]] |arm |Iyonix ARM pc |[10.0](http://www.netbsd.org/releases/formal-9/) -[[landisk]] |[[sh3]] |SH4 based NAS appliances by I-O DATA |[10.0](http://www.netbsd.org/releases/formal-9/) -[[luna68k]] |m68k |OMRON Tateisi Electronics' LUNA series |[10.0](http://www.netbsd.org/releases/formal-9/) -[[mac68k]] |m68k |Apple Macintosh |[10.0](http://www.netbsd.org/releases/formal-9/) -[[macppc]] |powerpc |Apple Power Macintosh and clones |[10.0](http://www.netbsd.org/releases/formal-9/) -[[mipsco]] |mips |Mips family of workstations and servers |[10.0](http://www.netbsd.org/releases/formal-9/) -[[mmeye]] |[[sh3]] |Brains' mmEye Multi Media Server |[10.0](http://www.netbsd.org/releases/formal-9/) -[[mvme68k]] |m68k |Motorola MVME 68k SBCs |[10.0](http://www.netbsd.org/releases/formal-9/) -[[mvmeppc]] |powerpc |Motorola MVME PowerPC SBCs |[10.0](http://www.netbsd.org/releases/formal-9/) -[[netwinder]] |arm |StrongARM based NetWinder machines |[10.0](http://www.netbsd.org/releases/formal-9/) -[[news68k]] |m68k |Sony's m68k based "NET WORK STATION" series |[10.0](http://www.netbsd.org/releases/formal-9/) -[[newsmips]] |mips |Sony's MIPS based "NET WORK STATION" series |[10.0](http://www.netbsd.org/releases/formal-9/) -[[next68k]] |m68k |NeXT 68k 'black' hardware |[10.0](http://www.netbsd.org/releases/formal-9/) -[[ofppc]] |powerpc |Generic OpenFirmware compliant PowerPC machines |[10.0](http://www.netbsd.org/releases/formal-9/) -[[pmax]] |mips |Digital MIPS-based DECstations and DECsystems |[10.0](http://www.netbsd.org/releases/formal-9/) -[[prep]] |powerpc |PReP (PowerPC Reference Platform) and CHRP machines |[10.0](http://www.netbsd.org/releases/formal-9/) +[[ibmnws]] |powerpc |IBM Network Station Series 1000 |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[iyonix]] |arm |Iyonix ARM pc |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[landisk]] |[[sh3]] |SH4 based NAS appliances by I-O DATA |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[luna68k]] |m68k |OMRON Tateisi Electronics' LUNA series |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[mac68k]] |m68k |Apple Macintosh |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[macppc]] |powerpc |Apple Power Macintosh and clones |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[mipsco]] |mips |Mips family of workstations and servers |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[mmeye]] |[[sh3]] |Brains' mmEye Multi Media Server |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[mvme68k]] |m68k |Motorola MVME 68k SBCs |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[mvmeppc]] |powerpc |Motorola MVME PowerPC SBCs |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[netwinder]] |arm |StrongARM based NetWinder machines |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[news68k]] |m68k |Sony's m68k based "NET WORK STATION" series |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[newsmips]] |mips |Sony's MIPS based "NET WORK STATION" series |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[next68k]] |m68k |NeXT 68k 'black' hardware |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[ofppc]] |powerpc |Generic OpenFirmware compliant PowerPC machines |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[pmax]] |mips |Digital MIPS-based DECstations and DECsystems |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[prep]] |powerpc |PReP (PowerPC Reference Platform) and CHRP machines |[10.0](http://www.NetBSD.org/releases/formal-10/) [[riscv]] |riscv |RISC-V |none -[[rs6000]] |powerpc |MCA-based IBM RS/6000 workstations |[10.0](http://www.netbsd.org/releases/formal-9/) -[[sandpoint]] |powerpc |Motorola Sandpoint reference platform |[10.0](http://www.netbsd.org/releases/formal-9/) -[[sbmips]] |mips |Broadcom SiByte evaluation boards |[10.0](http://www.netbsd.org/releases/formal-9/) -[[sgimips]] |mips |Silicon Graphics' MIPS-based workstations |[10.0](http://www.netbsd.org/releases/formal-9/) -[[shark]] |arm |Digital DNARD ("shark") |[10.0](http://www.netbsd.org/releases/formal-9/) -[[sparc]] |sparc |Sun SPARC (32-bit) |[10.0](http://www.netbsd.org/releases/formal-9/) -[[sun2]] |m68k |Sun 2 |[10.0](http://www.netbsd.org/releases/formal-9/) -[[sun3]] |m68k |Sun 3 and 3x |[10.0](http://www.netbsd.org/releases/formal-9/) -[[vax]] |vax |Digital VAX |[10.0](http://www.netbsd.org/releases/formal-9/) -[[x68k]] |m68k |Sharp X680x0 series |[10.0](http://www.netbsd.org/releases/formal-9/) -[[zaurus]] |arm |Sharp C7x0/C860/C1000/C3x00 series PDA |[10.0](http://www.netbsd.org/releases/formal-9/) +[[rs6000]] |powerpc |MCA-based IBM RS/6000 workstations |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[sandpoint]] |powerpc |Motorola Sandpoint reference platform |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[sbmips]] |mips |Broadcom SiByte evaluation boards |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[sgimips]] |mips |Silicon Graphics' MIPS-based workstations |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[shark]] |arm |Digital DNARD ("shark") |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[sparc]] |sparc |Sun SPARC (32-bit) |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[sun2]] |m68k |Sun 2 |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[sun3]] |m68k |Sun 3 and 3x |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[vax]] |vax |Digital VAX |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[x68k]] |m68k |Sharp X680x0 series |[10.0](http://www.NetBSD.org/releases/formal-10/) +[[zaurus]] |arm |Sharp C7x0/C860/C1000/C3x00 series PDA |[10.0](http://www.NetBSD.org/releases/formal-10/) """]]
Revert previous
Index: wikisrc/users/wiz/pkgsrc-migration.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- wikisrc/users/wiz/pkgsrc-migration.mdwn 31 May 2024 09:23:37 -0000 1.19 +++ wikisrc/users/wiz/pkgsrc-migration.mdwn 1 Jun 2024 18:02:13 -0000 1.20 @@ -92,7 +92,7 @@ where they do the `-` version looks better. So clean up the other ones: `git branch -al | grep _ | grep -v pkg_install-renovation | while read a; do echo git branch -d "$a"; done` - - `pkgsrc` is a misbranch of `pkgsrc-2017Q3`, delete it: + - `pkgsrc-` is a misbranch of `pkgsrc-2017Q3`, delete it: `git branch -d pkgsrc` - `pkgsrc-pkgsrc-2019Q4` is a misbranch of `pkgsrc-2019Q4`, delete it:
fix small typo
Index: wikisrc/users/wiz/pkgsrc-migration.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- wikisrc/users/wiz/pkgsrc-migration.mdwn 9 May 2024 10:42:55 -0000 1.18 +++ wikisrc/users/wiz/pkgsrc-migration.mdwn 31 May 2024 09:23:37 -0000 1.19 @@ -92,7 +92,7 @@ where they do the `-` version looks better. So clean up the other ones: `git branch -al | grep _ | grep -v pkg_install-renovation | while read a; do echo git branch -d "$a"; done` - - `pkgsrc-` is a misbranch of `pkgsrc-2017Q3`, delete it: + - `pkgsrc` is a misbranch of `pkgsrc-2017Q3`, delete it: `git branch -d pkgsrc` - `pkgsrc-pkgsrc-2019Q4` is a misbranch of `pkgsrc-2019Q4`, delete it:
ironically fix a byte missing in an off by one description...
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- wikisrc/users/cjep/git4pkgsrc.mdwn 27 May 2024 08:28:19 -0000 1.12 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 30 May 2024 22:00:25 -0000 1.13 @@ -223,7 +223,7 @@ The commit hash can be found in the output of ```git commit```: ``` -$ git commit -m "ix off-by-one security problem in lang/nawk." -a +$ git commit -m "fix off-by-one security problem in lang/nawk." -a [main ba3116fda897] spurious change 1 file changed, 1 insertion(+) ```
obscure host at request
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- wikisrc/users/cjep/git4pkgsrc.mdwn 26 May 2024 18:06:37 -0000 1.11 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 27 May 2024 08:28:19 -0000 1.12 @@ -42,9 +42,10 @@ Use ```git clone``` to obtain the source tree via ```git``` as follows: ``` -git clone nyftp.netbsd.org:/home/git/pkgsrc.git +git clone xxxhosttbaxxx.netbsd.org:/home/git/pkgsrc.git ``` + Set up your user and e-mail address. Please use your pkgsrc.org e-mail address and not your netbsd.org one. ```
Fix typo, add a missing step.
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 19:51:21 -0000 1.10 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 26 May 2024 18:06:37 -0000 1.11 @@ -142,7 +142,7 @@ git config pull.rebase true ``` -If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, re-add the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to readd the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail. +If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, re-add the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to re-add the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail. ``` $ git commit -m "mychange" test @@ -188,8 +188,9 @@ $ git add patches/p* $ cd .. # add "SUBDIR+=pkgname" line to the parent Makefile -$ vi Makefile +$ vi Makefile $ git commit -m "category/pkgname: add new package" Makefile pkgname +$ cd pkgname $ make CTYPE=Added PKG_DEVELOPER=yes commit-changes-entry $ git push ```
tezos stuff
Index: wikisrc/users/cjep.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep.mdwn,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- wikisrc/users/cjep.mdwn 25 May 2024 15:32:11 -0000 1.2 +++ wikisrc/users/cjep.mdwn 26 May 2024 09:27:42 -0000 1.3 @@ -3,6 +3,7 @@ ## Things of potential interest * Draft [Using Git with the NetBSD Packages Collection](http://wiki.netbsd.org/users/cjep/git4pkgsrc/) +* [Getting Tezos to work on NetBSD](http://wiki.netbsd.org/users/cjep/tezos-on-netbsd/) (WIP) * [Transitioning from a.out to ELF on NetBSD](https://chrispinnock.com/2022/08/20/netbsdaout/) * [NetBSD/i386 from 1.0 to present](https://chrispinnock.com/2022/09/30/netbsdhist/) --- /dev/null 2024-05-29 13:24:18.037339641 +0000 +++ wikisrc/users/cjep/hacl-star-raw-patch.txt 2024-05-29 13:35:04.039101151 +0000 @@ -0,0 +1,38 @@ +diff -ur hacl-star-raw-0.7.1/hacl-star-raw/Makefile hacl-star-raw-new/hacl-star-raw/Makefile +--- hacl-star-raw-0.7.1/hacl-star-raw/Makefile 2023-06-01 13:29:49.000000000 +0000 ++++ hacl-star-raw-new/hacl-star-raw/Makefile 2024-01-27 13:32:29.252198742 +0000 +@@ -33,6 +33,10 @@ + SO = so + OCAML_SO = so + CFLAGS += -fPIC ++else ifeq ($(UNAME),NetBSD) ++ SO = so ++ OCAML_SO = so ++ CFLAGS += -fPIC + endif + + STATIC_C_LIB_NAME=hacl_static +diff -ur hacl-star-raw-0.7.1/hacl-star-raw.opam hacl-star-raw-new/hacl-star-raw.opam +--- hacl-star-raw-0.7.1/hacl-star-raw.opam 2023-06-01 13:29:49.000000000 +0000 ++++ hacl-star-raw-new/hacl-star-raw.opam 2024-01-27 19:48:16.065305017 +0000 +@@ -26,7 +26,7 @@ + ] + available: [ + arch != "ppc64" & arch != "ppc32" & arch != "arm32" & +- (os = "freebsd" | os-family != "bsd") ++ ( os = "freebsd" | os = "netbsd" | os-family != "bsd") + ] + build: [ + [make "-C" "hacl-star-raw" "build-c"] +diff -ur hacl-star-raw-0.7.1/hacl-star.opam hacl-star-raw-new/hacl-star.opam +--- hacl-star-raw-0.7.1/hacl-star.opam 2023-06-01 13:29:49.000000000 +0000 ++++ hacl-star-raw-new/hacl-star.opam 2024-01-27 19:48:31.031026498 +0000 +@@ -25,7 +25,7 @@ + "odoc" {with-doc} + ] + available: [ +- os = "freebsd" | os-family != "bsd" ++ os = "freebsd" | os = "netbsd" | os-family != "bsd" + ] + build: [ + ["dune" "subst"] {dev} --- /dev/null 2024-05-29 13:24:18.037339641 +0000 +++ wikisrc/users/cjep/tezos-on-netbsd.mdwn 2024-05-29 13:35:04.070143015 +0000 @@ -0,0 +1,135 @@ +# Tezos on NetBSD + +Some notes on getting Octez to compile on NetBSD. Work in progress. + +## Problems with possible solutions + +1. Opam package doesn't include solver properly. + +Three ways: + +- Add lib-ext to targets and run before all (which isn't working for me) +- Is there another way to include the solver at runtime? +- Builds natively - accept that we have to do this outside of pkgsrc + +2. Once Opam is installed, it cannot compile OCaml on arm64 platforms (and +probably others). Amd64 is fine. + +OCaml builds in pkgsrc. Submit our pkgsrc patches back to OCaml team? + +``` +# [...] +# In file included from /usr/include/ctype.h:100, +# from sak.c:29: +# sak.c: In function 'add_stdlib_prefix': +# sak.c:126:26: warning: array subscript has type 'char' [-Wchar-subscripts] +# 126 | *name = toupper_os(*name); +# | ^ +# sak.c:126:15: note: in expansion of macro 'toupper_os' +# 126 | *name = toupper_os(*name); +# | ^~~~~~~~~~ +# gcc -O2 -fno-strict-aliasing -fwrapv -pthread -Wall -Wdeclaration-after-statement -fno-common -fexcess-precision=standard -g -Wl,-E -o sak sak.o +# gmake[1]: Leaving directory '/disc/tezos/_opam/.opam-switch/build/ocaml-base-compiler.4.14.1/runtime' +# Makefile:988: *** The native-code compiler is not supported on this platform. Stop. +``` + +3. HACL Star library explicitly excludes NetBSD +Patch done. FreeBSD settings work. Sent to vdum. + +4. GMP fix + +Cannot find GMP where it expects. + +``` +zen: {343} setenv CFLAGS -I/usr/pkg/include +zen: {344} opam install conf-gmp --verbose +zen: {345} eval `opam env` +``` + +5. Zarith 1.12 + +Zarith hackery 1.13 works out of the box. We seem to require 1.12? + +``` +cd ../ +mkdir zarith-1.12 +ftp -a https://github.com/ocaml/Zarith/archive/release-1.13.tar.gz +cd zarith-1.12/ +tar zxvf ../release-1.13.tar.gz +zen: {363} cd ../../tezos/ +zen: {364} pwd +/home/cjep/src/tezos +zen: {365} opam install ../zarith-1.12/Zarith-release-1.13 +``` + +mirage-crypto-rng + __FreeBSD__ definition line in sources - needs __NetBSD__ too! + Add -D__FreeBSD__ as a workaround + +pringo.1.3 + popcount function conflicts with native one + I worked around by renaming it - what is the best way normally? + +pyml + pyml_arch.ml.c checks for unix. We have __unix__ + Pull request submitted to pyml + https://github.com/thierry-martinez/pyml/pull/99 + +parsexp + SEG FAULT + +tezos-rust-libs.1.6 + +1. disc space error in /tmp. + /tmp needs at least 906M free + drwxrwxrwt 6 root wheel 384 Jan 27 15:32 tmp + +2. error[E0412]: cannot find type `QueryIter` in module `os` + --> /home/cjep/src/tezos/_opam/.opam-switch/build/tezos-rust-libs.1.6/vendor/region/src/qu +ery.rs:7:24 + | +7 | iterator: Option<os::QueryIter>, + | ^^^^^^^^^ not found in `os` + | +help: consider importing this struct + +Repeatedly wanting to install autoconf. Has to be a path issue + +## Process + +I will update this as I go. + +0. Make sure /tmp has at least 1G available otherwise tezos-rust-libs +cannot start to compile. On older machines /tmp is often in RAM to speed up. + +1. Install prerequisites +pkgin install gmake ocaml-opam jq git libev libhidapi autoconf + +2. Get Rust + +3. Get the Tezos sources + +setenv C_INCLUDE_PATH /usr/pkg/include:/usr/pkg/include/ev +setenv LIBRARY_PATH /usr/pkg/lib:/usr/pkg/lib/ev +#setenv CFLAGS "-I/usr/pkg/include -D__FreeBSD__ -fPIC" +setenv CFLAGS -I/usr/pkg/include + +4. init --bare +gmake build-deps + +Fix ups: +opam install ../fixed up +- hacl-star-raw needs the patch +- pringo function fix +- pyml +- mirage-crypto-rng -D__FreeBSD__ +- zarith (install 13 instead of 12) + +gmake build-deps + +- class_group_vdf ** Cannot find gmpxx.h library ** +- p +- tezos-rust-lib + + +
another typo.
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 16:54:49 -0000 1.9 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 19:51:21 -0000 1.10 @@ -16,7 +16,7 @@ # Initial Setup -Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details +Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will need to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details ``` # From pkgsrc
went to another dev
Index: wikisrc/donations.mdwn =================================================================== RCS file: /cvsroot/wikisrc/donations.mdwn,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- wikisrc/donations.mdwn 18 Jan 2023 21:02:24 -0000 1.5 +++ wikisrc/donations.mdwn 25 May 2024 17:06:19 -0000 1.6 @@ -20,5 +20,4 @@ Equipment | Location | Shipping | Contact ----------|----------|----------|-------- -Mac PowerPC G5 | London, UK | Can be delivered within the UK; possibly to continental Europe | Chris Pinnock (<cjep@n.o>) - +| | |
fix typo
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 14:33:58 -0000 1.8 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 16:54:49 -0000 1.9 @@ -142,7 +142,7 @@ git config pull.rebase true ``` -If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, readd the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to readd the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail. +If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, re-add the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to readd the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail. ``` $ git commit -m "mychange" test
link to git project
Index: wikisrc/users/cjep.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep.mdwn,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- wikisrc/users/cjep.mdwn 25 May 2024 11:53:39 -0000 1.1 +++ wikisrc/users/cjep.mdwn 25 May 2024 15:32:11 -0000 1.2 @@ -2,6 +2,8 @@ ## Things of potential interest +* Draft [Using Git with the NetBSD Packages Collection](http://wiki.netbsd.org/users/cjep/git4pkgsrc/) + * [Transitioning from a.out to ELF on NetBSD](https://chrispinnock.com/2022/08/20/netbsdaout/) * [NetBSD/i386 from 1.0 to present](https://chrispinnock.com/2022/09/30/netbsdhist/) * [Forking NetBSD](https://chrispinnock.com/2022/10/07/forkingnetbsd/)
Extract svg to a file
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:54:22 -0000 1.7 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 14:33:58 -0000 1.8 @@ -10,41 +10,7 @@ A key difference between Git and CVS is that your machine maintains a full local copy of the source code repository. Changes are maintained locally and are *pushed* back to the remote repository. Changes from the remote repository can be *pulled* and merged with your local copy. -<!-- XXX does not work on our wiki -<svg width="1000" height="100" xmlns="http://www.w3.org/2000/svg"> - <defs> - <marker id='head' orient='auto' markerWidth='2' markerHeight='4' refX='0.1' refY='2'> - <path d='M0,0 V4 L2,2 Z' fill='black' /> - </marker> - </defs> - <g> - <rect x="0" y="0" width="180" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> - <text x="10" y="55" font-family="Verdana" font-size="24" fill="black" lengthAdjust="spacingAndGlyphs">Working tree</text> - </g> - <g> - <text x="200" y="15" font-family="Verdana" font-size="16" fill="black">commit</text> -<path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M180,25 290,25' /> - <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M300,75 190,75' /> - <text x="200" y="92" font-family="Verdana" font-size="16" fill="black">update</text> - </g> - <g> - <rect x="300" y="0" width="220" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> - <text x="310" y="55" font-family="Verdana" font-size="24" fill="black">Local repository</text> - </g> - <g> - <text x="570" y="15" font-family="Verdana" font-size="16" fill="black">push</text> - <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M520,25 640,25' /> - <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M650,75 530,75' /> - <text x="570" y="92" font-family="Verdana" font-size="16" fill="black">pull</text> - </g> - <g> - <rect x="650" y="0" width="240" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> - <text x="660" y="55" font-family="Verdana" font-size="24" fill="black">Remote repository</text> - </g> - </svg> - - </para> ---> +[[!img repositories.svg size=490x align=right]] Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#index10h1). --- /dev/null 2024-05-29 13:24:18.037339641 +0000 +++ wikisrc/users/cjep/repositories.svg 2024-05-29 13:35:05.499126543 +0000 @@ -0,0 +1,32 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<svg width="1000" height="100" xmlns="http://www.w3.org/2000/svg"> + <defs> + <marker id='head' orient='auto' markerWidth='2' markerHeight='4' refX='0.1' refY='2'> + <path d='M0,0 V4 L2,2 Z' fill='black' /> + </marker> + </defs> + <g> + <rect x="0" y="0" width="180" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> + <text x="10" y="55" font-family="Verdana" font-size="24" fill="black" lengthAdjust="spacingAndGlyphs">Working tree</text> + </g> + <g> + <text x="200" y="15" font-family="Verdana" font-size="16" fill="black">commit</text> +<path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M180,25 290,25' /> + <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M300,75 190,75' /> + <text x="200" y="92" font-family="Verdana" font-size="16" fill="black">update</text> + </g> + <g> + <rect x="300" y="0" width="220" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> + <text x="310" y="55" font-family="Verdana" font-size="24" fill="black">Local repository</text> + </g> + <g> + <text x="570" y="15" font-family="Verdana" font-size="16" fill="black">push</text> + <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M520,25 640,25' /> + <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M650,75 530,75' /> + <text x="570" y="92" font-family="Verdana" font-size="16" fill="black">pull</text> + </g> + <g> + <rect x="650" y="0" width="240" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> + <text x="660" y="55" font-family="Verdana" font-size="24" fill="black">Remote repository</text> + </g> + </svg>
ikiwiki internal links & contents
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:24:44 -0000 1.6 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:54:22 -0000 1.7 @@ -46,7 +46,7 @@ </para> --> -Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitting-patches). +Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#index10h1). # Initial Setup @@ -87,7 +87,7 @@ git config --local user.email "myuserid@pkgsrc.org" ``` -We only allow "rebasing" (see [Syncing with the remote repository](#syncing-with-the-remote-repository) below). Please set this in your local configuration: +We only allow "rebasing" (see [Syncing with the remote repository](#index5h1) below). Please set this in your local configuration: ``` git config pull.rebase true
ikiwiki
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:21:34 -0000 1.5 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:24:44 -0000 1.6 @@ -1,11 +1,10 @@ - -# Using Git with the NetBSD Packages Collection +[[!meta title="Using Git with the NetBSD Packages Collection"]] *This document is a proposed draft. Please feel free to send comments to cjep@*. [[!toc ]] -## Background +# Background In April 2024, the [NetBSD Packages Collection](https://pkgsrc.org) management team (pkgsrc-pmc) decided to migrate from [CVS](https://www.nongnu.org/cvs/) to [Git](https://git-scm.com/) for managing the source code of the NetBSD Packages Collection. This document covers the basic commands to manipulate the sources using Git. @@ -49,7 +48,7 @@ Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitting-patches). -## Initial Setup +# Initial Setup Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details @@ -94,7 +93,7 @@ git config pull.rebase true ``` -## Basic usage +# Basic usage To add, remove or move files: @@ -111,7 +110,7 @@ git status ``` -## Committing changes +# Committing changes New files need to be added with ```git add```. @@ -144,7 +143,7 @@ git commit -m "Make lots of cool changes at once" file1 file2 file3 dir1 ``` -## Syncing with the remote repository +# Syncing with the remote repository You can synchronise your current branch from the remote repository with ```git pull```. To synchronise your local repository fully with the remote repository use ```git fetch```. You can submit your local changes to the remote repository with ```git push```. @@ -208,7 +207,7 @@ $ git push ``` -## Adding a new package +# Adding a new package To add a new package, ensure that your tree is up to date. The process is similar to the one using CVS. @@ -229,11 +228,11 @@ $ git push ``` -## Branches +# Branches Any changes you make with git are done to the current branch in your local copy of the repository. The *main* branch is essentially the trunk of the repository. Although you can make local branches, you will not be able to push them to the remote repository. We will only use branches to maintain quarterly releases. Pkgsrc developers should continue to commit to *main* in the same way they have been committing to *head* with CVS. -## Quarterly Releases +# Quarterly Releases The NetBSD Packages Collection has [quarterly stable releases](http://www.pkgsrc.org/quarterly/). The release comprises of a branch so that a consistent set of packages can be built and managed. The naming convention of the branch is ```pkgsrc-YYYYQN``` where *YYYY* is the year and *N* is the quarter number. @@ -246,7 +245,7 @@ Never commit directly onto a release branch. Always commit onto *main*. If you need a change in a release branch please refer to the next section. -## Submitting a pull-up request to a release branch +# Submitting a pull-up request to a release branch Please refer to the [developer's pull-up guide](https://www.netbsd.org/developers/releng/pullups.html). Pull-ups for pkgsrc should be sent to the ```pullup-pkgsrc``` e-mail group. You can send a pull-up request either by: @@ -298,7 +297,7 @@ $ git push ``` -## Submitting patches +# Submitting patches We are in the early stages of our migration to Git. We expect to offer public pullup requests at some point in the future. But for now, if you do not have access to the NetBSD Packages Collection source tree directly, you can still submit patches. For example:
toc
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:18:44 -0000 1.4 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:21:34 -0000 1.5 @@ -1,6 +1,10 @@ # Using Git with the NetBSD Packages Collection +*This document is a proposed draft. Please feel free to send comments to cjep@*. + +[[!toc ]] + ## Background In April 2024, the [NetBSD Packages Collection](https://pkgsrc.org) management team (pkgsrc-pmc) decided to migrate from [CVS](https://www.nongnu.org/cvs/) to [Git](https://git-scm.com/) for managing the source code of the NetBSD Packages Collection. This document covers the basic commands to manipulate the sources using Git.
remove image for now; fix interlink nits
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:11:18 -0000 1.3 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:18:44 -0000 1.4 @@ -7,6 +7,7 @@ A key difference between Git and CVS is that your machine maintains a full local copy of the source code repository. Changes are maintained locally and are *pushed* back to the remote repository. Changes from the remote repository can be *pulled* and merged with your local copy. +<!-- XXX does not work on our wiki <svg width="1000" height="100" xmlns="http://www.w3.org/2000/svg"> <defs> <marker id='head' orient='auto' markerWidth='2' markerHeight='4' refX='0.1' refY='2'> @@ -40,12 +41,13 @@ </svg> </para> +--> -Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitpatches). +Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitting-patches). ## Initial Setup -Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first]](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details +Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details ``` # From pkgsrc @@ -82,7 +84,7 @@ git config --local user.email "myuserid@pkgsrc.org" ``` -Also we will only be allowing "rebasing" (see Syncing with the remote repository below). Please set this in your local configuration: +We only allow "rebasing" (see [Syncing with the remote repository](#syncing-with-the-remote-repository) below). Please set this in your local configuration: ``` git config pull.rebase true @@ -204,6 +206,9 @@ ## Adding a new package +To add a new package, ensure that your tree is up to date. The process +is similar to the one using CVS. + ``` $ git pull $ cd .../pkgsrc/category @@ -290,7 +295,6 @@ ``` ## Submitting patches -{#submitpatches} We are in the early stages of our migration to Git. We expect to offer public pullup requests at some point in the future. But for now, if you do not have access to the NetBSD Packages Collection source tree directly, you can still submit patches. For example:
remove XXX
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:06:33 -0000 1.2 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:11:18 -0000 1.3 @@ -41,7 +41,7 @@ </para> -Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see XXX insert web link later XXX: +Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see [below](#submitpatches). ## Initial Setup @@ -71,7 +71,7 @@ Use ```git clone``` to obtain the source tree via ```git``` as follows: ``` -git clone nyftp.netbsd.org:/home/git/pkgsrc.git # XXX Change link XXX +git clone nyftp.netbsd.org:/home/git/pkgsrc.git ``` Set up your user and e-mail address. Please use your pkgsrc.org e-mail address and not your netbsd.org one. @@ -290,6 +290,7 @@ ``` ## Submitting patches +{#submitpatches} We are in the early stages of our migration to Git. We expect to offer public pullup requests at some point in the future. But for now, if you do not have access to the NetBSD Packages Collection source tree directly, you can still submit patches. For example:
changes from wiz and gdt
Index: wikisrc/users/cjep/git4pkgsrc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/cjep/git4pkgsrc.mdwn,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 11:56:58 -0000 1.1 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 25 May 2024 12:06:33 -0000 1.2 @@ -107,25 +107,15 @@ ## Committing changes -```git commit``` on its own will tell you which files have been modified and which files are not yet part of the repository: +New files need to be added with ```git add```. ``` -$ git commit -On branch main -Your branch is ahead of 'origin/main' by 1 commit. - (use "git push" to publish your local commits) - -Changes not staged for commit: - (use "git add <file>..." to update what will be committed) - (use "git restore <file>..." to discard changes in working directory) - modified: README.md - -Untracked files: - (use "git add <file>..." to include in what will be committed) - newfile +git add newfile +# next commit will automatically include newfile +git commit ``` -New files need to be added with ```git add```. You can either add existing files with ```git add``` to stage them for the commit or specify them on the command line: +You can either stage existing files with ```git add``` for your next commit or specify them on the command line: ``` git add README.md @@ -141,17 +131,19 @@ git commit -m "Make cool changes to the documentation" README.md ``` -You can stage and commit all changes with ```-a```: +You can stage and commit all changes with ```-a``` but the preferred method +is to specify the filenames explicitly. ``` -git commit -m "Make lots of cool changes at once" -a +git commit -m "Make lots of cool changes at once" file1 file2 file3 dir1 ``` ## Syncing with the remote repository -You can synchronise your current branch from the remote repository with ```git pull```. +You can synchronise your current branch from the remote repository with ```git pull```. To synchronise your local repository fully with the remote repository use ```git fetch```. You can submit your local changes to the remote repository with ```git push```. -To synchronise your local repository fully with the remote repository use ```git fetch```. + +Before you use ```git push```, you can examine the change that will be pushed with ```git log -p upstream/main```. When you ```git pull```, you may have to resolve conflicts between the remote changes and your local changes before continuing. Additionally when you ```git push```, the remote repository may have changes that you do not have. You will need to ```git pull``` first. @@ -220,11 +212,10 @@ # setup DESCR, Makefile, PLIST, distinfo, etc and add them $ git add DESCR Makefile PLIST distinfo buildlink3.mk $ git add patches/p* -$ git commit -m "Adding new package pkgname" . $ cd .. # add "SUBDIR+=pkgname" line to the parent Makefile $ vi Makefile -$ git commit -m "Adding new package pkgname" Makefile +$ git commit -m "category/pkgname: add new package" Makefile pkgname $ make CTYPE=Added PKG_DEVELOPER=yes commit-changes-entry $ git push ``` @@ -250,14 +241,14 @@ Please refer to the [developer's pull-up guide](https://www.netbsd.org/developers/releng/pullups.html). Pull-ups for pkgsrc should be sent to the ```pullup-pkgsrc``` e-mail group. You can send a pull-up request either by: -- Sending a commit hase to ```git cherry-pick``` +- Sending a commit hash to ```git cherry-pick``` - Sending a unified diff file if a more complicated patch is required. The commit hash can be found in the output of ```git commit```: ``` $ git commit -m "ix off-by-one security problem in lang/nawk." -a -[main ba3116fda897] spurois change +[main ba3116fda897] spurious change 1 file changed, 1 insertion(+) ```
initial commit of work in progress Git process
--- /dev/null 2024-05-29 13:24:18.037339641 +0000 +++ wikisrc/users/cjep/git4pkgsrc.mdwn 2024-05-29 13:35:07.534970073 +0000 @@ -0,0 +1,313 @@ + +# Using Git with the NetBSD Packages Collection + +## Background + +In April 2024, the [NetBSD Packages Collection](https://pkgsrc.org) management team (pkgsrc-pmc) decided to migrate from [CVS](https://www.nongnu.org/cvs/) to [Git](https://git-scm.com/) for managing the source code of the NetBSD Packages Collection. This document covers the basic commands to manipulate the sources using Git. + +A key difference between Git and CVS is that your machine maintains a full local copy of the source code repository. Changes are maintained locally and are *pushed* back to the remote repository. Changes from the remote repository can be *pulled* and merged with your local copy. + +<svg width="1000" height="100" xmlns="http://www.w3.org/2000/svg"> + <defs> + <marker id='head' orient='auto' markerWidth='2' markerHeight='4' refX='0.1' refY='2'> + <path d='M0,0 V4 L2,2 Z' fill='black' /> + </marker> + </defs> + <g> + <rect x="0" y="0" width="180" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> + <text x="10" y="55" font-family="Verdana" font-size="24" fill="black" lengthAdjust="spacingAndGlyphs">Working tree</text> + </g> + <g> + <text x="200" y="15" font-family="Verdana" font-size="16" fill="black">commit</text> +<path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M180,25 290,25' /> + <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M300,75 190,75' /> + <text x="200" y="92" font-family="Verdana" font-size="16" fill="black">update</text> + </g> + <g> + <rect x="300" y="0" width="220" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> + <text x="310" y="55" font-family="Verdana" font-size="24" fill="black">Local repository</text> + </g> + <g> + <text x="570" y="15" font-family="Verdana" font-size="16" fill="black">push</text> + <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M520,25 640,25' /> + <path marker-end='url(#head)' stroke-width='3' fill='none' stroke='black' d='M650,75 530,75' /> + <text x="570" y="92" font-family="Verdana" font-size="16" fill="black">pull</text> + </g> + <g> + <rect x="650" y="0" width="240" height="100" fill="white" style="stroke-width:3;stroke:rgb(0,0,0)"></rect> + <text x="660" y="55" font-family="Verdana" font-size="24" fill="black">Remote repository</text> + </g> + </svg> + + </para> + +Initially the repository will be accessible via SSH by NetBSD developers only. To submit patches please see XXX insert web link later XXX: + +## Initial Setup + +Install ```pkgsrc/devel/git-base``` for a minimal installation of ```git```. To do this from source, you will need to [download pkgsrc first]](http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.xz). For non-NetBSD platforms you will beed to bootstrap - please see [the documentation](http://www.pkgsrc.org/#index1h1) for more details + +``` +# From pkgsrc +cd pkgsrc/devel/git-base +make install + +# From pkgsrc on non-NetBSD platforms +cd pkgsrc/devel/git-base +bmake install + +# Or pkgin +pkgin install git-base +``` + +Alternatively use ```pkgsrc/devel/git``` for ```git```, it's documentation and other contributed tools. + +Move your existing ```pkgsrc``` directory out of the way. + +``` +mv pkgsrc pkgsrc.old +``` + +Use ```git clone``` to obtain the source tree via ```git``` as follows: + +``` +git clone nyftp.netbsd.org:/home/git/pkgsrc.git # XXX Change link XXX +``` + +Set up your user and e-mail address. Please use your pkgsrc.org e-mail address and not your netbsd.org one. + +``` +cd pkgsrc +git config --local user.name "My Name" +git config --local user.email "myuserid@pkgsrc.org" +``` + +Also we will only be allowing "rebasing" (see Syncing with the remote repository below). Please set this in your local configuration: + +``` +git config pull.rebase true +``` + +## Basic usage + +To add, remove or move files: + +``` +git add new-file.c +git rm old-file.c +git mv old-file.c new-file.c +``` + +To inspect the state of your tree or examine changes since the last commit: + +``` +git diff +git status +``` + +## Committing changes + +```git commit``` on its own will tell you which files have been modified and which files are not yet part of the repository: + +``` +$ git commit +On branch main +Your branch is ahead of 'origin/main' by 1 commit. + (use "git push" to publish your local commits) + +Changes not staged for commit: + (use "git add <file>..." to update what will be committed) + (use "git restore <file>..." to discard changes in working directory) + modified: README.md + +Untracked files: + (use "git add <file>..." to include in what will be committed) + newfile +``` + +New files need to be added with ```git add```. You can either add existing files with ```git add``` to stage them for the commit or specify them on the command line: + +``` +git add README.md +git commit + +# or +git commit README.md +``` + +```git``` will open your file editor to edit the commit message. However it can be specified directly on the command line: + +``` +git commit -m "Make cool changes to the documentation" README.md +``` + +You can stage and commit all changes with ```-a```: + +``` +git commit -m "Make lots of cool changes at once" -a +``` + +## Syncing with the remote repository + +You can synchronise your current branch from the remote repository with ```git pull```. +You can submit your local changes to the remote repository with ```git push```. +To synchronise your local repository fully with the remote repository use ```git fetch```. + +When you ```git pull```, you may have to resolve conflicts between the remote changes and your local changes before continuing. Additionally when you ```git push```, the remote repository may have changes that you do not have. You will need to ```git pull``` first. + +Git will attempt to include the changes from the remote repository. You may receive this error message the first time you use ```git pull``` if you have not set up git already: + + +``` +warning: Pulling without specifying how to reconcile divergent branches is +discouraged. You can squelch this message by running one of the following +commands sometime before your next pull: + + git config pull.rebase false # merge (the default strategy) + git config pull.rebase true # rebase + git config pull.ff only # fast-forward only + +You can replace "git config" with "git config --global" to set a default +preference for all repositories. You can also pass --rebase, --no-rebase, +or --ff-only on the command line to override the configured default per +invocation. +``` + +The ```rebase``` and ```merge``` methods are ways of integrating changes from divergent branches. Please see the git-merge(1) and git-rebase(1) manual pages for more details. The "Fast-Forward only" method is useful if you are just following the remote repository but are not making local changes. We use (and enforce) the ```rebase``` method for the NetBSD Packages Collection. You can set this as follows: + +``` +git config pull.rebase true +``` + +If the local repository and branch contain conflicting changes, you will need to fix the conflicts by hand, readd the files and commit them to the local repository. For example, here we make a local change that conflicts when we attempt to push our repository. We fetch the changes, resolve the conflicts and push our changes again. The ```rebase``` method requires us to readd the conflicting files and use ```git rebase --continue```. Please see the git-rebase(1) manual page for the detail. + +``` +$ git commit -m "mychange" test +[master a013462] mychange + 1 file changed, 1 insertion(+) +$ git push +... +error: failed to push some refs to 'githut.co.uk:randomrepo/repo.git' +hint: Updates were rejected because the remote contains work that you do +hint: not have locally. This is usually caused by another repository pushing +hint: to the same ref. You may want to first integrate the remote changes +hint: (e.g., 'git pull ...') before pushing again. +hint: See the 'Note about fast-forwards' in 'git push --help' for details. +$ git pull + (Diff truncated)
add page for me
--- /dev/null 2024-05-29 13:24:18.037339641 +0000 +++ wikisrc/users/cjep.mdwn 2024-05-29 13:35:07.820008631 +0000 @@ -0,0 +1,7 @@ +# Wiki page for Chris Pinnock (cjep) + +## Things of potential interest + +* [Transitioning from a.out to ELF on NetBSD](https://chrispinnock.com/2022/08/20/netbsdaout/) +* [NetBSD/i386 from 1.0 to present](https://chrispinnock.com/2022/09/30/netbsdhist/) +* [Forking NetBSD](https://chrispinnock.com/2022/10/07/forkingnetbsd/)
smaller image
Index: wikisrc/ports/evbmips/images/edgerouter4.jpg =================================================================== RCS file: /cvsroot/wikisrc/ports/evbmips/images/edgerouter4.jpg,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 Binary files /tmp/cvsSZi1qq and /tmp/cvstJBNL2 differ
add wii
Index: wikisrc/ports/evbppc.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/evbppc.mdwn,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- wikisrc/ports/evbppc.mdwn 30 Mar 2024 19:27:00 -0000 1.29 +++ wikisrc/ports/evbppc.mdwn 22 May 2024 09:23:45 -0000 1.30 @@ -8,10 +8,13 @@ changes_future="11.0" thumbnail="//www.netbsd.org/images/ports/evbppc/405gp.gif" about=""" -NetBSD/evbppc is intended to be a port of NetBSD to various PowerPC-based -evaluation boards and appliances. +NetBSD/evbppc is a port of NetBSD to various PowerPC-based evaluation +boards and appliances. """ supported_hardware=""" + +### Nintendo Wii + ### Artesyn's PM/PPC board The following devices are supported:
fix url
Index: wikisrc/ports/evbmips.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/evbmips.mdwn,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- wikisrc/ports/evbmips.mdwn 22 May 2024 09:20:19 -0000 1.30 +++ wikisrc/ports/evbmips.mdwn 22 May 2024 09:21:34 -0000 1.31 @@ -10,7 +10,7 @@ future_rel="11.0" changes_cur="10.0" changes_future="11.0" -thumbnail="//wiki.netbsd.org/ports/evbarm/images/edgerouter4.jpg" +thumbnail="//wiki.netbsd.org/ports/evbmips/images/edgerouter4.jpg" about=""" NetBSD/evbmips is a port of NetBSD to various MIPS-based evaluation boards and SoCs.
modernize evbmips page a bit
Index: wikisrc/ports/evbmips.mdwn =================================================================== RCS file: /cvsroot/wikisrc/ports/evbmips.mdwn,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- wikisrc/ports/evbmips.mdwn 30 Mar 2024 19:27:00 -0000 1.29 +++ wikisrc/ports/evbmips.mdwn 22 May 2024 09:20:19 -0000 1.30 @@ -10,10 +10,10 @@ future_rel="11.0" changes_cur="10.0" changes_future="11.0" -thumbnail="//www.netbsd.org/images/ports/evbmips/malta.gif" +thumbnail="//wiki.netbsd.org/ports/evbarm/images/edgerouter4.jpg" about=""" -NetBSD/evbmips is intended to be a port of NetBSD to various MIPS-based -evaluation boards. +NetBSD/evbmips is a port of NetBSD to various MIPS-based evaluation +boards and SoCs. """ supported_hardware=""" * [MIPS Malta evaluation board](http://www.mips.com/products/development-kits/malta/) with either the [4Kc](http://www.mips.com/ProductCatalog/P_MIPS324KFamily/productBrief) (MIPS32) or [5Kc](http://www.mips.com/ProductCatalog/P_MIPS645KFamily/productBrief) (MIPS64) CPU board (running in 32-bit mode only). @@ -24,6 +24,11 @@ * Plat'Home OpenMicroServer (OMSAL-400) * [[Loongson|loongson]] MIPS64 based devices +### Cavium Octeon based designs + + * [Ubiquiti EdgeRouter 4](https://dl.ubnt.com/guides/edgemax/EdgeRouter_ER-4__QSG.pdf) + * [Ubiquiti EdgeRouter Lite (ERLite-3)](https://dl.ubnt.com/datasheets/edgemax/EdgeRouter_Lite_DS.pdf) + ### Atheros AR531x based designs * [Atheros AR5001AP](http://www.atheros.com/pt/ar5001AP.html) @@ -31,6 +36,10 @@ * [Linksys WRT55AG](http://www.linksys.com/) * [Meraki Mini](http://www.meraki.net/mini.html) * [Senao/Engenius 5354AP1 Aries2](http://datacom.engeniustech.com/products_detail.php?name=35&cat=Wireless%20AP/Client%20Bridge/Router) + +### Virtual hardware + + * [MIPSSIM](https://qemu.readthedocs.io/en/v7.2.9/system/target-mips.html) (QEMU) """ additional=""" * [Running NetBSD on emulated hardware](http://www.NetBSD.org/ports/emulators.html) --- /dev/null 2024-05-29 13:24:18.037339641 +0000 +++ wikisrc/ports/evbmips/images/edgerouter4.jpg 2024-05-29 13:35:09.001883934 +0000 @@ -0,0 +1,161 @@ +ÿØÿà + + + + +ÿÛ +I ÎPõ^s¸ä@ +ISh¹å09YÊN\f +*X\ß5 PyçtSät¤gèè/8áädÜ7ÅÊÈ +õiïÚ¯É8=Nu9õA¸u1È4Ë*X3g6d*a,nf©¥3&caÈ +J¿±/ZÞ +¹ÞfÜÝ\ÃáÐ;ëxHøB^q*ú·#ÜÕGÖéÔ;n¡[\¨Ú·NʦÞiäþ9xÔvË*o¶ãw¥H*¬ù«v(vÖqYÛXÍ~ØîÅcÖ¬y]|!.¸^MGìm[wê éºÔh£ë]3 GZ?>%¹Þ¾ý<ó¥©j$n¬ù«8 +5ð µÃµÄßY9ûsÇ +ï;G¸píIKÉ +¨îÐ=¨¨ýIE1®ô˦-Êß9?/zö$Z¸\æ\ßÏ¢Àlâ·yvÀNêå$ ÄXaâ$¤î®+Øàn® +SÕÊk Öà+¬ñ·m~Ðî&½«ìøhÖwàFBAÆ7e]ÁIî ¤¥<çà´«yÜ?/iúEÆ1®Ó"*6ºÔ%¥KMGê.q0õáøÆéÔÍ÷_MJp¨æ³Y¬Ök>J«ÂÞsKmÅÛkV6o®T 7ø +È@Æ<áA_µ;°1ÚO$8Bæ·$' +*c JO#ØíP$Ðí¯Ë¯º³ß-Uv¤mÊs)ä,z{PóÈRY;àTMaa1:yBbõ&Úº¬ôÄÂÛ<èïºÊ×f«Ö¥¹^_òP9'ç&°d×µî9òVq\Öí£Ì´ò¨4R +Uää`¸¬òkrRÊ¥dà¥Y.جdní «¼ò ïRÀ'6 eJʱÝA@#j£¸òóõ";¥Èú®÷1ú}j£õ&!µ¾#Ë-yu½[lÌßµÝÆçN?JQ*PÜsä¬àãÓµ5Î3À¬ùk$s;R>ÆW°úæ³ZUÝ>Ó÷v&\ÞÎÓè½j'®ç4ÔU© ¦ÈS)Pð(RY9 Ð=½¨J¹®R¢ îPâÜÉBÈ*îÁ +J²~ÉÜ¥|§q +çÈ n kãFR¯º·(,grBC¢y°¨ºí1z~eqú®´Óæ-Æß8|¯Èb+Wî¢Ô¹¯Êunæ½) Qï¬æ¹¡ÐV+®@ &ugâPV+3´y +!@`¤öá!'¹? +!{p¤À\IÀ£ÜARVw6á%'½8Å£YRâa(õ éÝÖ%hMQ6ò令ÖÐ4ã]Ar½º¯%(]©®B~Åguci)ÞAÍ{W8&½ ci#ÈA$ý©9¬¥ÈÛ^GyQ¸,(%æÔ<éÚ5çlVi+ZWQãêYvófrUÂólI nmò"^,q©V¹ðÝ9IùO ´ÒW ÄÑmÀ°q@e>èÂBN{мe^Ä ã § ÚVrB¯u`¥HÂR{Ó¸$!åÇÒIrIéÿ +Kt>õHBëÆ7}9MxÜE`ûDAɬíQ)ZSË@¨i;[CÒJÔÛInöúö=1þ{éÕÔÿ +ñ¸¬pÇbG;8_ 4@¥s_ +Ê{¹ÆM ÄmøÉIÛ´GµJç¿È5¥<Í¿´AØ¢>GK@!N©nV{ÆG§nÓÅ~Ö=:Åÿ +Ý íÂÚuõ~NÊCg+tѬä9¯ÌWM,²bGôëýϼ³&èêÚ(òÝÞ·?"u¸=bÛ'ÍK¬ºÂþdµ¸,PUo&À¤ÊtRg9_U`x\¢ÎêRU_ +Ô2 ®ìw ÐíPÝIÆ=ÂyOhO;NÀåc"[V¤¬à ¥T076mo{N)é%e¶Òqº' c +÷VAüß+Fôÿ +¼÷ç±â«x¤¼E&c¢êK°Ô ¥§¸ mÁ*¥v©cug#¸+ +Æ×täÒ6×8Ê~$«i ¡j%A!o*ABR÷4¢ +U9ÏÛö`¨°Ë²Ñº «?Ü{Ôý-§nfoI4ûÕ7¤WÖ*nÔÖñ÷bàØ.¼/Ñ%C¸|º;ý鬬öç.W¹³î1v[´ÛL*H)÷m*D'#¨¤ñ¦°¬åA;ù¯*&K¤ÍtWÖ0TGÅÇi¬m¤æÜw-)ÁIÆÜ/få¶Í|*P¦ÚÂu-¤©r·£¸ +%@ý§QmßVë|ˬ½'£¡é¶~öuÑsºY¥¥ ý¸!7 ªÉu§X_Î\lÉ.j¾] q©5ô&ÔÞ·àJÐú¶å¨ÎãUBõ Ò;[t~¶ê·^ý$oª+mæ« ÖÔÑAÇvíüoPù¤»L§E ¼Ñ]BÔZVVYÂÔ9ݵDm^H¯e¦m-ÓÒÐN*êí/ãÇM«á¨féÝ5oÓPÿ +Ü3´Ø3µa9P;ÆBëʺM%õ +L·këR) +h ìñ)5ì + @zF) óè§30sIMi}'?SÉ´Ú Y!NãM¼úJ\LþÛÖgô³TD3¬j½þfqakôDÿ + Ý*×íÒô>¯¸j7ç«ÑI!@ újW¢>p>*VéâaÂ%À=¹ý5ÒsªáÑÕUç:¶y»©^uWSΦÞuZê8´~HRúst«TK²ËÓcúíòÝ24øíÛÖÚ©UtÆ3Ño]Ü8u)ÈâQÌ9Pö¥z#áùoeG&l¡#iôþãM<úIÜîAYÒÝUͳ]ªÈ?"ÑÒ#Üb<Ïzrlz7Q®HB¯ÚéJÒúçZOH«NLüÝäwⶩ"ÊÕ>ÁíJôGÃèÅZíSït®¦#~$@5?Ii«NéêÒMA¦émIn +@\á½BÒç-Ü^mÆ!Í)6ÛVжÔÙÕczVZ;¦bääèÁ½:>üúuG¢¦{£ï¨â~>÷¶RpÏt ++`:ñ¢+[ÞfR«Æ¿ºM&XÚSÀ7@¥ Î7Ü6zömC57®[F5Ä̲·éÇÙASráEv°òàC#!Ôác°½<z+Ì<à+½»SÚmW6mÛ<L«´Ç¬ÖíJüÐ8C®5³)ÕP¹X<1Y¬C¨q¬&nÃöÑê X£"¶ªh8B$²á»Gf4T²±«jì³M;É/oÝ1¤;L +¾$TA:ð*ßEï*ìJÀõWÂÑ£5±güµ»'ö\\uÝA-Äb±QÓ°ÃÀ2¡¢ÛÈÞrÄ@õEí°óY´ßt@À4PÁâL<ky^ÍÐTF4W>fQ&ÁêÛëdä³Ê ,òãî¡õ¾jÌ¡ãºep=Æ¿ñ5Ã×£JûÂÜ®fTä:4·'ø±Ìçg¬©cü<èåù¥L÷ÛÃËþ´¦×LcÆ$Ð UDAé:T!èª0SÖEpÀ +!«¸QG8VðpÖc GT+ð'i¬v +Çõk×Vÿ +ªÅ\V·o´GÍ+j:ãC°î + ñ"aôÌPûè¾òÐ{îĬP5|¦¶,ÿ +8ëÄvqÄôPºîêõ1Ç°}µÌº¢0ük§\xªÂZ=TrPÒÞ-¥^à þ*×è ÃjOéÑ(°µýÖñ 1Ô¸ÇBjªL|EzéwÇ° TW¤ë®,¨º®_XãçpöVÌÈ)ùÆn>£ü¤=ãlÈÃÐÁPBøÄa×C¶Ýä£lËnÁ: 3§1°+eN7 #ºCÝQ²Ä×BGÃ0ä¨4`ÕðÏól¬ê¦ êÍKí1ÔYHOFõáJ¬aèK \h·7d[t65ÏÛÛÁ: 1XG·0¬":¡[lô¢½cêeGdb¦5s]å»X5nf¤©®{0áÓB^Q³~¼´Öå5êyúcªaëÑ_Û¯¶Öò9,ÏñJfì7T3¼ÛË0ÅþeÏÏbwªnF _&jºù©û£IFúÎh|Òÿ +´9@q]½¦èjöAÑJãX¤[ÑSܸEcÚð¢§QѸÃ0 +!&½© ´>¶É}¦·ëÐ`¸3áoÃ@ +ò¢ÃxþË 46¦öY@Ñ^¨Ü~1º0¨$Íܨ÷ËÀÇöª,¹\E¸½aýAÁ¼tÒX¿ÍHÆQ÷9ïAë V·¾]Hge%&ÎöùLifKçìܵ-ùÄk×HÈfz¶¥÷¨}s3RÏÓ,Áøeâ''«JûÂܦfTäm[÷»Üþ`${¨1fðÒ2qÊeÎS¶Þ'®,|µ1qUhrÕ¬. CÒ+âG®ÕLQjþñ\DÇXuB¶Ø-a«¿N Ú8ÞfÞb[:ãV[®*ª¤CÄÚÏ5eSQÕEpÚ+ñÆ訣à{e£ì5wòÕµ'mE«rÅöV8ý'~yb«ÄRä[S/;RÖ=1Ç·ÙÜÀç×¢°*ÛV.VN^@ÑUDzOÉ¿ÂT¯I¸ø?)[!mÂ$Ûèê D[³ÜQ/KÉÒ J'»d +´z+Ö«Cá4zè)"ølËVEïÙÙÁzEX»vAùincEy+`ìüLúïneðÆÖ'¦£2YðÂÄøáP}§4¯ÃÀÐíÍììÀJ·¼ñ{ f?ÌW¶cgÁ·[u/².µV5tÙmoö>êÛÚðøxÀ VÊrÇ´÷a¦·e~qÚ+ÉXUçï(Dî¥öEIñ«§!>Rà){Èð¬ ó~!LTEíÓÝÝ=5ÞØNó8Öñ.ZǺǫ̀<óà³_y÷ã +¶säóKäÒÊ?(0þ;ÌÓ\ªÿ +ÝgUm£ËV²À6Y·ÀËRéCÉ E¾'HV®V Zìê·¦3¸·¢¥°Ä9 +,Wg³ÒÜÖÝ l>H£=T¹MýòÜ%ÌPëí©S'μËÍ jÞjQHóNk8IÆfe½\¿ kyÙyÒºóÇ¢]*¹9 +þd|EmK¡½]=%¦2¦bÜCP*ËÓÚ4BÜùrÕ°Ãâ`Ñ¡xh +w¶·x_Fá×°¬Nª- XzØø2©«£\Ĩx®;ÇPpènÙoÀÖóù`àÌÂj$0»Î*ªÐcËPdm/²*ÖÚ#)Xí¨`κ +ºiLÈ_Ø@JÆa|ÃÝØ »ä«¢Ç¬Â¢uà+y?¡|ªÕŶ¢SgË+ü¿¿3åiyd¹ÕnHMÍKÊÍiR?áLÆ´:kì¹G£#enײhm5°ÅU6j»ÀàåpdVÀr×dÐU@¬ò:1*¼pg$¯ 5¼+¬Ç]GT+aÊ©Ä5Ñ' Ôp¯û,MmBâkw¡ª#@µ×^êÐõXúáE Ë\×ÅuaëPÌ*Ñdmpf,D<æéºØbPѸZÐJFý&¶ÕñH\MºîËV<´7L{¨O+ho)Wµ 5|Uaî¬=cpvhØN=æ,D<¢ãNc®$xõOÔ5×å®eú-ר[Þ& ö\{MD¬Ëf_95Ñ»J1g0C~âé<á[Édir/6îÇþXEæô$~j\ɸp$ÿ +;JÞ" +HAØEh塼+hññ·¶ß Xí 4w@øÀ%öÑÐÐjà ¸Ök¯õ,`~rë½õz Dí[I A×÷ÂôS "(¸-×W©Véºðè«%Ç^èÃÕÝbÉPRâ_C_Ë[p*8PÆ£9b¿A£×@³û Z¹xü0VÝѵ7·´@µ [OñJÑ nä1·´÷ÓFXbv¢£o®·R5â|ª:&¡,ÁFÕ +ÙKVÐöWÒÂuo¼¿.Y¼òj?þPÊÄ"¿ìüß:N#R¬uñ<jTãØpÜ:zdÆq³\ÖÎ9Ì´¼¹r¦å]ÒÜAóÇNËe³ùlôä2¥MøìÓ_®áe3lWyòTÅ@ºa$»¤[Ã*F~n~L¸Y¹|&1b¸b8\#@Î÷wWydq׿ÉÍÝKeolÙ'Æ3''6d¹ÕdDã ¶]MwÃxÛÈcCyÃH-¼º:Zó<ûµÃ1ÔTU W,F>Èô¦:ây*تêërÖ0-¿e£[aÕt+rPHÛ袶-ËP7u-ÐøÛÛ<e){jé ÅD+Mëp$©W,´r +Çø¸UÊâ_¤/Ehi[Ìnñ««Làοen1ûhD¶¡<jéã(_òFqo:ÀP1µ0#ø°¥½`; ÑB=îÊùaPÏ÷L*lô÷åÉ·ü·ûGèHçyÊ7ô?AääsÓd¤ÎðSRwYÉÃêí|¡~Þ`PÊO+510jKÔu3óù)¿["ÂÒȲÝöóOeI2sùu&ÚÂt¶WÆx|1¶}UÌf9ÂWÖfO²À÷Y.¶¶ +õÙ%bo}×Áz E@i¶Ë¶KúËB (í»µ¸(í5 w+Î01é«)/´ +ây(F*º¡»Ü´7Êu!õÂ?ªX5ì ÕΦcpu§q¡XmÍàìÉkm¯îFÕíÌey*Ù ~÷{ëf¥v¶Jã»a¯7KØ¡°ùF?Gx +ÞOè_*Ämm9þ(bݦòÂvÛ¢¡ÝN?Å E»½ô°¡«ÑYÿ +ÔX8Aþ äK^ÂPÕÓÓgáÙuÈ¿³-ZxPi{îÄmä¯NoWÓ ÖS½6øufÃå±1zÞL75Y/Ç¢ÃvðÂ/m¼ð¬vPr¶´4«ç m·dyaD1ÇÑÂY5;sR_Ö +ýÞXAçzL°Â¡'lÕ×[Gweÿ +ây+ÑAÝ +ÝîZñl¾ +V=|Ì<4EuU²ðN'Î A%¢ÂÏ5ÄÖ§zO½TB¬v½`75õÒe²ÒdÙÔE±¤ç.v7?ª®«#ï¯÷Ó>sò®í«µ¹F4NK3Êù¯Q˶Ég²¹¡×dôcï¨æù4 qU¼r¬yʲÄúÆhë²³¤ýKn,²¶ÍÃCQSFc)õQ5Ä"êúYÓ?tÖk"ùÖnJC¡´´0©ÜàÓ7s&µÍº$ +|öJNyÖ¹´[â½ÓLæÜÞc,ÀD+âý´2IFdçkUW¡":î3kÉSd+y\>Ê ¦¤²èàëí¨ vhãQ+VÖËVÔ¬_Ñ5³;ó +ÅC~ ÓÖó+LÒÞÜcW#!é2Öí.Ç·t}ôm@=7aljÙ$ ÖøÝõV¤³ÞnéapQ©"ë Z¾®_ÛQq»Ä2ây(A;¶ÝËWL"\®Ljé ÛðÄ47¶¯ÃX5vaXþ®¡@¹S7²¡«K±Ð[uµ½ú \ƶ°O/:Ãä{³ÓZ]3ÙÑ°âcµåFÓÆæ¦ zëh@c&Cä³à<ÏUoZ³Î=dï.¥êýô9ÃrÙüI`Ñúºf2mç*l~ôh·6s´ÇÎRÑ/7æÍQÆGö.5»-¥·¢â÷KÊ|Á +æó'2í>CýOÀÔù³gÜÓLêö|³W¶l¹#f¤sI¬ù¶'åæó½ãµ\å6Ám$,8FêÍ6vdôysU¥4 !×SsYxIRågËà:×ì¯U2DßÑÈa^»/6_é!¨4pÖp®ª.1Ö°jÚE5:ôÆ»êÞ8VÜ£ÑXÐÃvðèð« oqFÍo&£¼{mÚÓF +Á{ìR!zEzs8ª¾µ&NìOƶ v:Á¢¶B<î,VÜ*ÉEúqºÚÇS k¯äÞåò8Êéò0hj +v}.1ËÇß[cv|ñ«/ +<¼ó&ì±×öWÕ²ktÆþlæïL?õÃýÏsÊI³1mDdY½,»öi쫹«c1/ý¡öVÎ@fÒàû n³ÙIÙv: ¨V<¿»È¬+5¸r êwE0ÎoÁàeÃÈþ0öÕ¹^tøÃÖ/Ëϧ³5JÆ@ãîaYQÿ +71ÌË,2Rãtcx,xTþq'0¦ùklq<µS9vÓeÑuä¢Ù<æ[7ËonÚ?ÝËÆ[÷U§8Ò£çP (*5w!ú&ãÒ+²Þ½bè¦Ýµ·y¹¢<KÆ·rŪ{A±¢ +c\¾m8næA¹sü×n¥¥yt5ÒYÒ\£¡°Ô±³<~µbyjÞ{þÎÉüJ÷ýµê³3ù½úÉÃ"¦æ2\ç/5/1.Ñl<ük.îÁ@ÍO¥É¬Òò¥f §ÒƹÛÏÔ}ã\ñõÁtªf{°héDIH/È&HòØvÀÔéÙ¬ÃÎ;Dá0W:Ll-¡áun¹«ë9<Ýã)ã¾èÿ +ÞFè:$ß/ÃhQ\Ï9n¦Ý³pÙ"̾vFif6ÊÊ´±ä¬¼²L7¤>B<êõ|Ù)a³/í=T2|ß*ÃÞ|ÏøÌ9Ãò³úÞX'¿ºýg$ß«pþ¨ÕÜÙιyÿ +û4öUÜÕÏCô3ÿ +ª3¦X,ÅM · ePÊp>Ë74GÁA6ÈÌÌEñt,5t[Î8h¬y{6 +ZÈüú +ü86Mt«\xÎ/B½9nZ©z»àh.ùÌÃ2Gê«VU² +çR~ÀEHø²¸`opÏÝ0(EÈÉ2V±äDÉg˸µCxbÌI`×"û«YàP`å?¹ë à²Þ!d-aí$CsaäË`uI8ÁnEVCâ-'Äúë$Ø`;}ÎT5%â*@zÜW"&ãçÄBÒ'Z¦ÉÂ!Rw*Î"-Ë*>ä'üÑPË_Ô\äë){ÍÔsV_Üü~mXèàú +7äQcé<ÄH4ëH{¦tyèabÜà¦R'ñdh~ì$èÓ²iT!ÎC|Åe9·°8ýeÇ$6Aõá@w'GÇÉÍ +ÏÐ¥àãAäÕ,fã)RÓÕó¥Ëç< +ÔØMä²` +&bñ@ì ¹×.Jç BrÂÞi°b»ç6éã6·é«å +%ðâ4±æ)XI0L¢¥bÐ;¨m ØÌøO3u,¤fÖ? MÄ æy°ØC&j¹àXÐg Áfið#Ó]ìG¼åsYqrN\2XÈe}³ifC»Ãs5XrqHǯ!bh S<KMÇ0ú¡ÒKάPÐè ,|ÌNÆKÝHG ñ0Ù +û Ê9þ¡üØU 0î.k_jî +nIÂ>æX«ñNÂ|°ÌE¶BæaH¼eûÐV8KÃÛzÄt<t¿j¹lW"÷Á©ëâqe$ Vm<UoÝÚyÿ +0¢DÝıNKÞjƲì4º§ VúMp!cÐæI¢Iðk0hëéå +2F«/*] oo(ó8}b£W|ÄÙó>©ºBÇ|ÿ +3(<Ù +PúOð?¨x®YÐÒÌ:üê²G($k$¯ýÄ7²xö)=Q1±ÜGäXqSÄÔÖ§ÆV5äÀZ ,`ßY®ªËÁ *cDr«\@Âok©¥ ²¡[(ß&uÂ\BȤx4ðj©êlYyk,i!ÞÍÄÝlÙ³ø6lõrÅy8M++h'8Se|º@uHб@1íX(t×Á5&Éé9Mb¶ý¼á¨`ä@&á"¬ÒmOG(6 +ì¯)ÍîÖvÐg<4 +´´{ì +ºõis%'4;Èü¿òecÑçñ6jÚ)Æ,DçF5Î"Ì >f©÷[w<[PO¥T +ÝS8<@]>xe÷b2x>´¸õæ"ê³áÍ<uÂY«¦Äi¢ª¸Mn£yV8Á"^å-!÷d¡\ÅÅ;yÄ(Ä&Þd4ðÂÙÿ +*ëhKÁ%:Üt§¨©¶«èæ¦î$Ur¤0&ÍY£°²9±.´4¿Âl¿%¡«Kfø*0²Þ&21Óþþî©w6¹FSªë¼ú¸=÷õ[èß÷fÑ ¿Þê±t/õ~Do?öñ#¿b**¿õÍ%á¹å'|WãÝ/ºëA$ ÃÕMBrñ®Ê +ã ä IAäc öÕ:ï%+<A|YrâHÉTQÓX-eátk6 .8í·J +9´6óu÷· +zAßÉv9-ç¹õX¥BÐ07¤âðnººÓÓeþ÷OÐ@¡FMLаÙb<Oìÿ +GôÖ!Ñ +»G ĹÌz(PÑÒ²*P +t*hÇBÑb0Ì[¿C'ånLL»éR +ÔPFÍ3É\»w(V +ñõkàIe''¾ººRdb¬%ðkrømXÌ.LÇQÕ/× #ð +>¿Òâªé+$Â\á«"ãMῳ\¾¯ìýß"&q»ÕÁø¢*½½í¦îµ]ZªjlfIf¯á£´?ÉpKªMveW¥cÃÛ¿áÁü(?û@M£Qo\Ííª÷Qº^`k¢4Îs4tÅÁRäÔ% ~Ú\þOrÏtWopæO[Ô Îâdù¹äuÒå¯u°@cl´éN''Lëã´ÿ +oc³öwLÀ@ðmçÙæó<ÙÛY ÏZTÍ'Ùõu`´_±ô¸/âkö½«RN®O÷OÀ²Aèà9ö Ô¶qÓM®>¨tüêÇ4Á4Ía0rd$ÕÑÍ.càþi(ÚÀþÿ +§ø·$ZîO)eD2p2GóJÇ×2r}¾oï(ZÈÅÂ4CXórKD°µ® +wz!ÿ +I$ á A +ÝfqyI <ÍXÆ0 åXtTÑÉ£uØ(×8V]o.÷EW¡¦÷ÂŦyMqÇÈÞç7ÇÀ +Å õ¥ÆC^¤à|´>Oý *°fc'#D"ÄXh´ùÀöÄ&ÉÓ¥Àg^¨%TÍ@¤ÝÑy`®4xÏMÐMÁR¢bOé0ÀÂY+=w«4ØäH7~n{HcgÅ8Ð0êÇ}ÓB±þ!ç9ëº/[r=÷Õ;÷mâ4mÄáñLD ÐbAí;æÍR|°ðQ,b^ybf5¤ÈìRJèßbÞÀpÂÅÛÂqdL¼É¸xsÙÃä¦4=³ï¿Î0,;Õ +H fY°x´$9#Nä;fÏÂUU®O¬Ý°3YA+åuLwDà§ÂãÉî:¥½lÈ +{ý/BS4Ê7']t?¿F|up9ÛI²1ßTºS?jD,#Ó8ÙåÕG©fâÊ4s@oNL©fºêÈdÌ ÏÓñqPÈ2úf:ÝÊàkZ ~1dje¤ÅCçï5Ãm>£ÙßUiá%Þ'¾ê·I×!R¥Iæ(yPÕ0Ç=jÐ}U5$1Ͳìbd ýú®Àè0GðóÌØ8ÄÀàóª$F"Hyÿ +ßXÈܦµûY|·Ó³Í*ØËç`¼AêÆYñ$Ìs8³¼C3e¡ñNªJó7Ý*«BáL3%&¶ +p9iÀÝ®,D´:<ÖK\ào}ÖsÃÌ¢SÃbüÎlÕ7IÇt!ÔácQÕÃx×7úM\Kax! >:²n¡, þw*°,h¢!£µ$õúW%T#&G¯w1 N÷M®\écõ§%@x$,c¨ÉFj¤É`&L=^uHÝáK +B98ÌuHh<Ù¹¶~PYÁBK´}ÎüUÐ`¦Hüy°ßjÌ(JI#ô}w@pÓ³À/OÅw@P`~Ýù¢@?ÌiÜÝX)ÐS%\ýsæ +&6ÌâÍUO¡z¡îö4G·ÅwU!dlÉdí6>l!<Éûý÷ª¥é<BT:ëv".!'xûªé½ +!®dRa|~´Gh{x'SÁQ 7yE1 +Cº` ÉÚÄRÔ¬2ã53s x>)ðâ1$tî{y°²Áº/¦2ü4ó^Zf2ÖÈÏ»¸»QjsûR*È:æCç»R"Èò& qêÌÌ\äõ¯< `k¸¤ >xËÕk};LS´\ªD\³óëNÕL zÓðòR®ì}p +=¹Îj >8Àó¼øª,ÑYwÇíyhåJ¡CÛµéÿ +DËø(CO!ÅvñÞ«<ñ6tñDI¾þD"w®éì²ûB÷g¦-,#óÍ4~¨¢3-S÷» +XLfâðØ´É*N ÂNWy×5NJ÷a'Ç î-<sÉ@ÈQ%ÄÙ-'rÂÏÝCñ@Q«Ç6I<ÓZÑþÁ¥/WÜë×Çm=Åt¿_½³^V¸â¢KeÎ{ó×vv3`µÂh0 +a??;Á¼S?¸S+>rÉÔrpc4Á84Þ¥ÅÛ# +Ø=qfïgæ¥Ð¹dyê©ED¸ü7<¸æãWU¡ìºDÏ8v$3ýh&4ØÊD0Þi4/pZÍd L £"rß}VB!]ÌBþµ*Q<4a÷ÍIÂ(Lpe QYVT¡ßë5CØr.@ðcCÍ0éµT_A2dB:"oÍ !jäEÙ*2óví¨bå ¼¡»nòèM'þàB;b1\²àà ÐÀr¹BX4ªâ,eîþIIðâ[21òÂ!5Ⱦ ÓÕ¬ñºÒ!óÝ×ÙBâuø¬ºÛ% óÏT BNw¾ä¥h~7Õl<PDÆêæ +G¸pÇßUy´ÔÙ ¢Á|GXw5]$È-;üWD¶ô$Îìê¹^Ù?»Pó·jäø,#1¤êÏBÇOò§8| T/ÃæèøÉ}Ê3Z|ÕÔZ¤ã\ÅËe¸(3MF#a÷çu)H4 â¾±GåBÅ^¿æ<Ù6½©¢¹*)ù* Z Ø¥@Î<µG+Oe= ¦i!g59ðÑ»Ï7, óaÝÒ§Äâº:èQòe§ÅôÂøé"lúï²á8TÂÈÇlV1 +sP{ÖtàK3Ûâ +§ÄLµ°þòTâ qζP#`N|NdÃö`üú¤¹Ø1ú¸Çâq ò¾WäyOpÌõÝ+0 +CÅò¨¶Æøÿ +ξ«YÑ8¼ef7ÕL¦déôÒ'y;î 2ÜåßVage·÷ë0¿..ÂñÜóqC<¤õXÏÍE/ñ6ø|4lâ@¾g`þi\ÃÚYË 8×}Ôôy$ /qeÂŶ>;§ Â{Ïv*Ìå=VëâORÅ).ÅÙT}9×Y¹LD³:ù,²læÌP"{Ê×-*Éq{±³Ùä4bAýÀ¤Ýº!¤/URøÆÁÖw +gòG -/Á5$|f#$ÔÅóÝ/¬g#¬Æn àÂftÎ*àêÓ`Ç XhÂ4D¸õQ¹Åðd¥ fAékp!¥?|´X"Lv'è¹z9÷J +Anl±LgÓJÎs|´òû (P)×9=º£_j"9ûkòPÑJyßï\óPÜM9ÿ +sù¸yL;¸dOîª §2±ÉóY;ph±3Ǥ¶<f9)«*¾Añõõø!|2>9+¡h¯å'0bSLò,NÃHYEå'sB9$£Ø*m8%×66Ò]HÀìµò¹lÊNG0XíaG¬Ï +ªà§½ñ[p<¤µ×ê3 uv¼b Ì®hz¦k+¬½îhoo2ÜhÇÉ`)H>ÿ +%Åld4áæ7TGÖSÌfgóâ©ÑrYÆ×à01» +A32ȹßésQ.QÁ¼MÞ¢¦d)ÿ +1<!Ïú¥1/ùkö¶dª4Ö£VAäÌAâ¦Fhw¬~õ¶ñC)fÐsø©ÝP×4jy§ÐP"'u3 ýQHOiZpÏóµØçä¥ -!ÃüÞhj'ؤ̮ æ`va½R)myßùO)Û¤N +K6D2#3aR£&!ï7`3Ä +'B0UA +á½ Y_vaÑÀzbJDÆb^xÌtÔìºnõ⦠ÁÇ8Yú§,èy=Ô2øÅÇE>'²ÊTÌÔNÒxyyM1vÅeJÿ +x¨è:£ev¸µÝp,!Qk|Pä±SÜC¦ËcÞߢ`¸FÖ}~XFð#ÀåÔØ|!k$àE=? ¼J$>ôµËÊðÎÙg62'IZ!Q?²@:GCîj×:\¼*eú¦8ò«ø±H¬êòøx³Ü0&P,p?x¤¤Ã;~ÉÂ$$éäêâ°h§cåeÓD0óäønuf"=y LHjaý?ÉsñËü9¨c%ÂñÉ&uÏ/8WVi4^nÖ|RÕÔH¡È+±R§j»|Ùo¥ ¿ð/ cÃaÆz×çw@æÃ% +¤W/ùöRýÙ}ÙñEä°8!ÄѲaðâÌ +ä6÷NW¼µnOóµòÙVIä?n|XA¹ö£â¦pBcô®!Â?ÄÄ{Ä{¥s`uüÔC +9m +ÂGëODG°¸0¶1ÚâRô÷Ã{cê¤êÆn÷þG:®ÈÃe¨àæw +´<ïv3Ý,ÓÕqs6DÎ/ýèÈXà *g®7dǪ5ÛÀ:E<% 6êF&p4+O)ù ]$<×&^ç!ªCÉÈܾ+ Þ¥ñÍ +m$<ÒÜ>+á~t(O ò¿Õð|õ +/î,Éñ\¤ÆÑOæo!:F§ex0Ðx +Ý©DN¦rl¦!2¼ÐsPg'`8þU4±»²d}\êiCº`K4r£^¬' +2fTTfYÝDº'I_*6lfP'GWJK{0½!g¦Jy²BAeáÈB +kô. +Û@áo;¥N(wÄ`èåtÜ#$û?Á¨ìEeFJB+Dâ{ªÕD`q³O|æÁ¡²"Fë×¥Ly'TÉÕÊång) lεW© +¢®M5}°´¨®Xíæû§z ¦öç$AE.ìòaÒIñxÔ±?u°0O(ßn½¦ôþ'íA6>ã$Jau ¹pk¶I¼³aäP $"T@: (Diff truncated)
Index: wikisrc/matrix.mdwn =================================================================== RCS file: /cvsroot/wikisrc/matrix.mdwn,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- wikisrc/matrix.mdwn 6 Jun 2021 13:49:51 -0000 1.3 +++ wikisrc/matrix.mdwn 12 May 2024 23:53:04 -0000 1.4 @@ -6,14 +6,9 @@ NetBSD on Matrix ================ -NetBSD has a [Space](https://matrix.to/#/#netbsd-space:nil.im) on Matrix. However, since Spaces are [still in beta](https://matrix.org/blog/2021/05/17/the-matrix-space-beta), you can currently only see the rooms you already joined. Here is a list of all current NetBSD rooms: - -* [NetBSD space](https://matrix.to/#/#netbsd-space:nil.im) -* [NetBSD main room](https://matrix.to/#/#netbsd:nil.im) -* [pkgsrc main room](https://matrix.to/#/#pkgsrc:nil.im) -* [Bridged #netbsd IRC channel](https://matrix.to/#/#netbsd:libera.chat) -* [Bridged #pkgsrc IRC channel](https://matrix.to/#/#pkgsrc:libera.chat) -* [Bridged #netbsd-code IRC channel](https://matrix.to/#/#netbsd-code:libera.chat) +* [NetBSD space](https://matrix.to/#/#space:netbsd.org) +* [NetBSD main room](https://matrix.to/#/#netbsd:netbsd.org) +* [pkgsrc main room](https://matrix.to/#/#pkgsrc:netbsd.org) How do I join? ==============
More retro delights
Index: wikisrc/attic_museum.mdwn =================================================================== RCS file: /cvsroot/wikisrc/attic_museum.mdwn,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- wikisrc/attic_museum.mdwn 8 May 2024 11:19:03 -0000 1.26 +++ wikisrc/attic_museum.mdwn 10 May 2024 11:20:55 -0000 1.27 @@ -1,6 +1,6 @@ [[!meta title="The Attic Museum"]] -Over time, several kernel components were removed from NetBSD, often because +Over time, several components were removed from NetBSD, often because they were too hard to maintain, not always functional, and because the features they implemented were not particularly wanted anymore. @@ -18,14 +18,22 @@ [[!table data=""" Component |Category |Removed Since |Most Functional Version |References - +vinum |Utility |02/2006 | |[Commit](https://mail-index.netbsd.org/source-changes/2006/02/25/msg198055.html) +netns |Network Protocol |08/2006 | |[Commit](https://mail-index.netbsd.org/source-changes/2006/08/26/msg172577.html) +netccit |Network Protocol |08/2006 | |[Commit](https://mail-index.netbsd.org/source-changes/2006/08/26/msg172578.html) +sh5, evbsh5 |Port |04/2007 | |[Commit](https://mail-index.netbsd.org/source-changes/2007/04/08/msg184091.html) I386_CPU |80386 CPU support |11/2007 |NetBSD 2 |[Commit](https://mail-index.netbsd.org/source-changes/2007/11/15/msg193018.html) systrace |Monitoring framework |12/2007 |NetBSD 3.0.1 |[Commit](https://mail-index.netbsd.org/source-changes/2007/12/31/msg195466.html) compat_hpux |Compatibility Layer |12/2007 |NetBSD 1.3 |[Commit](https://mail-index.netbsd.org/source-changes/2007/12/31/msg195459.html) pc532 |Port |01/2008 |NetBSD 2 |[Commit](https://mail-index.netbsd.org/source-changes/2008/01/10/msg000637.html) +esl |Audio Driver |09/2008 |NetBSD 1.6 |[Commit](https://mail-index.netbsd.org/source-changes/2008/09/30/msg210849.html) +playstation2 |Port |12/2009 | |[Commit](https://mail-index.netbsd.org/source-changes/2009/12/05/msg003960.html) +tn3270 |Utility |01/2010 | |[Commit](https://mail-index.netbsd.org/source-changes/2010/01/16/msg005468.html) compat_darwin |Compatibility Layer |04/2011 | |[Commit](https://mail-index.netbsd.org/source-changes/2011/04/26/msg021404.html) compat_irix |Compatibility Layer |04/2011 |NetBSD 1.6 |[Commit](https://mail-index.netbsd.org/source-changes/2011/04/26/msg021405.html) compat_pecoff |Compatibility Layer |04/2011 | |[Commit](https://mail-index.netbsd.org/source-changes/2011/04/26/msg021406.html) +xbox (i386) |Port |11/2011 |NetBSD 5 |[Commit](https://mail-index.netbsd.org/source-changes/2011/11/18/msg029016.html) +window |Utility |02/2012 | |[Commit](https://mail-index.netbsd.org/source-changes/2012/02/16/msg031827.html) netiso |Network Protocol |03/2013 | |[Commit](https://mail-index.netbsd.org/source-changes/2013/03/01/msg041917.html) vm86 |x86 CPU Mode |08/2017 |NetBSD 7 |Many, was widespread, not reinstatable acorn26 |Port |01/2018 |NetBSD 7 |[Commit](https://mail-index.netbsd.org/source-changes/2018/01/24/msg091429.html)
A change I wish to commit.
Index: wikisrc/users/schmonz/testing_chdir_bugfix.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/schmonz/testing_chdir_bugfix.mdwn,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- wikisrc/users/schmonz/testing_chdir_bugfix.mdwn 28 Jan 2013 11:41:04 -0000 1.3 +++ wikisrc/users/schmonz/testing_chdir_bugfix.mdwn 10 May 2024 11:18:58 -0000 1.4 @@ -2,3 +2,5 @@ warnings about `chdir()` to a nonexistent or empty-named directory. Seems like [this commit](https://github.com/schmonz/ikiwiki/commit/b30cacdf8da07f40af03f1b26021d8ec4d8b8b4c) helps. + +Is this still one of the problems?
add pkgsrc guide details
Index: wikisrc/users/wiz/pkgsrc-migration.mdwn =================================================================== RCS file: /cvsroot/wikisrc/users/wiz/pkgsrc-migration.mdwn,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- wikisrc/users/wiz/pkgsrc-migration.mdwn 9 May 2024 10:40:54 -0000 1.17 +++ wikisrc/users/wiz/pkgsrc-migration.mdwn 9 May 2024 10:42:55 -0000 1.18 @@ -54,6 +54,10 @@ Documentation === - pkgsrc-specific documentation for developers and git + - pkgsrc guide sections + - 23.3. General notes when adding, updating, or removing packages + - 23.5. Committing: Adding a package to CVS + - 23.8. Moving a package in pkgsrc - update branch-cutting instructions - update releng instructions
Add a comment